From nobody Sun Mar 2 15:46:13 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA4C1A0B4C for ; Sun, 2 Mar 2014 15:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsZej52W-sbm for ; Sun, 2 Mar 2014 15:46:10 -0800 (PST) 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 DA7811A0B40 for ; Sun, 2 Mar 2014 15:46:10 -0800 (PST) Received: from [130.129.153.101] by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WKG59-0001t5-Ly for manet@ietf.org; Sun, 02 Mar 2014 18:46:07 -0500 Message-ID: <5313C2BB.8080409@computer.org> Date: Sun, 02 Mar 2014 15:46:03 -0800 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mobile Ad Hoc Networks mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866d9b26d479d41620e3b6b9b9a8602265350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.153.101 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Sc6CwRLDQ2rg79Tjg9OQmsvje0Q Subject: [manet] When does a "timed route" have to be expunged? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 23:46:12 -0000 Hello folks, The following language is currently found Section 6.3 of the AODVv2 draft: o A route MUST be expunged if (Current_Time - Route.LastUsed) >= MAX_SEQNUM_LIFETIME. o A route MUST be expunged if Current_Time >= Route.ExpirationTime This is not terrible, but it seems inconsistent with the apparent meaning of the following language in Section 8.1, which does not mandate expunging the route: If Current_Time > Route.ExpirationTime, the route table entry has expired, and cannot be used for forwarding. The background is that the current language was crafted so that "timed routes" would be expunged when they expired, but that is probably too restrictive. Keeping an expired route enables better comparisons against sequence numbers, and so it's better to avoid expunging routes that might be useful in the future until Current_Time - Route.LastUsed > MAX_SEQNUM_LIFETIME. Roughly speaking, the following semantics are desired: o An Active route MUST NOT be expunged. o An Idle route SHOULD NOT be expunged. o A route MUST be considered Expired if Current_Time >= Route.ExpirationTime o An Expired route MAY be expunged (least recently used first). o A route MUST be expunged if (Current_Time - Route.LastUsed) >= MAX_SEQNUM_LIFETIME. and with the proviso that Route.ExpirationTime == MAXTIME is the usual situation for Active and Idle routes (i.e., they do not have any specific Expiration Time yet). Comments on this matter are solicited, and I hope to have proposed text within the next week or so. However it is resolved, AODVv2 should not mandate a lot of extra timeout management. So, for instance, it would be bad to update the timeout for Route.ExpirationTime every time an Active route is used to forward another data packet. Regards, Charlie P. -- Regards, Charlie P. From nobody Mon Mar 3 03:48:09 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDD31A000D for ; Mon, 3 Mar 2014 03:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id is9LQ41fsl2r for ; Mon, 3 Mar 2014 03:48:06 -0800 (PST) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B7D881A0007 for ; Mon, 3 Mar 2014 03:48:06 -0800 (PST) Received: by mail-yh0-f46.google.com with SMTP id v1so3372102yhn.33 for ; Mon, 03 Mar 2014 03:48:03 -0800 (PST) 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=AGIyAW6Ig3h7+6vezE2GnYwdzzejyG4MkR83sWTvJmU=; b=afchhk6uHif+8w7tcSwdpobC/Ni/croDTJkSRD/qDsoF2Gzp6KOEzcyLmoYATIifLh rCWHioYZRZk2hx43yffL1HGcPRXRW+k3DaWorzfjLDW94NkO15cW/jDeWEDfd40VuhJN Do8qPwLAiImAj27Mk5iXIdHK+OfEzgpqqoBMZWZ+RdwVAQTiyxu0/Eal9iJbVCPUq4wL dSiz1xOFtMfttnb9KsPjO1VEFQf2hhMkGg2WQYU92Jj98pQ1afVjsQ9XDRtsKjp95r/t JSYC5cgfyA45RhrFbs9iw/6dcPdYFaAYaYVnIvy48+c+q3T72GXATCGOjkTTtbH5gbQC KU+g== MIME-Version: 1.0 X-Received: by 10.236.113.115 with SMTP id z79mr21590269yhg.8.1393847283691; Mon, 03 Mar 2014 03:48:03 -0800 (PST) Received: by 10.170.202.7 with HTTP; Mon, 3 Mar 2014 03:48:03 -0800 (PST) In-Reply-To: References: <603F5FD847B5174CBDA37A9DC00532FB0B4E6FD2@SUCNPTEXM02.com.ad.uk.ds.corp> Date: Mon, 3 Mar 2014 12:48:03 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/DWYn-yFS0Bs1x9twYlNgDCKV3x4 Cc: "manet@ietf.org" , "Dowdell, John" Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:48:09 -0000 Hi Chris, I did not want to join the DT, and still not getting their report, but I want to discuss within WG list. I beleive editors should follow the WG participants text amending, and follow consensus. I look forward to comment on the DLEP on the list and in this meeting. Comments below, Regards AB On 11/12/13, Dearlove, Christopher (UK) wrote: > Wrong I'm afraid, both procedurally and practically. WGs can't write > documents, that just isn't a viable approach. Documents are written by > authors, or sometimes editors. The WG can reject a document. But that's not > the same as writing one. > I meant to say that DLEP draft is changing from using UDP to use TCP without enough discussion on the WG list or final consensus. If editors make the change in the draft which they already did, that will affect the fairness of the final consensus and also the WG discussions. I feel now after the editors have made their decisions with the DT, now I am forced to not discuss, or I am forced to be in a discouraged position. It seems now it is better for me to leave the flow go into DT decisions, and hopefully not all drafts take the same direction in future, > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 12 November 2013 16:30 > To: Dowdell, John > Cc: manet@ietf.org > Subject: Re: [manet] DLEP DT summary > > Hi John > > I have been very interested and was regular posting and reviewing the work > but should not be excluded (there are others ). However, I thank you and the > members of DT for your contributions, and always want to speed the process > for DLEP but with best practices and awareness. In the last two meeting > there were comments from the community that the DT should follow. The WG did > not decide to give its job to the DT. > > I don't agree that the DT makes changes to the DLEP draft, the DT should > report its recommendations to this list, so the WG decides and discusses > what to do. > > AB > > On Tuesday, November 12, 2013, Dowdell, John wrote: > For the avoidance of doubt, please understand that I asked for an informal > meeting at Berlin IETF that half way through became the Design Team. The > meeting attendees were drawn from those who had regularly posted on DLEP > since the 00 draft, and therefore were deemed to be most interested in > getting to an RFC, as I was. Kindly lay off the lead author of DLEP. I am also, but big changes like using TCP need consensus, now with draft changed I feel I have no interest in giving even a humm voice. > > In the meantime, if anyone else is actively developing with DLEP (router or > modem side) and is willing to directly contribute to the speedy and > successful development of the draft, please post on the manet list and we > will be in touch. One person joined the team since the first meeting in > Berlin. I did not join the team, because I think it is with enough capacity, and if me and other join it will become another MANET WG list. > > For timescales and upcoming work, please listen to the DLEP presentation in > the early part of the manet WG meeting at Vancouver. > I agree that all to listen to each other, so community listen and then the community to be listened to as well, From nobody Mon Mar 3 05:09:23 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5B01A00C5 for ; Mon, 3 Mar 2014 05:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klyunrmbJdj7 for ; Mon, 3 Mar 2014 05:09:16 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D4B9B1A00CB for ; Mon, 3 Mar 2014 05:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4616; q=dns/txt; s=iport; t=1393852153; x=1395061753; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JMsEClg07Whzz13oQuijJsk8C/ev3qiqTWnBAbnvFIM=; b=PWmClDU4+77V+pzCzVT62qfo1aOQME2fZq3hGdo57K9wCuk+KulFzCBs QZ2SVuD3D+6xmnPK+W2Qk3ibJzYHHyIe2JZxawcbVYjXciE2+6ajkFnlo 7O59yZWCjr4KrblsSvLenCQWYRJJBKVAUowr/RjB5RnfWPCqyPS100g2S 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFALt+FFOtJXHA/2dsb2JhbABagwY7V8BPgSMWdIIlAQEBAwEBAQFrCwULAgEIEQQBAQEnByEGCxQJCAEBBA4FFIdRAwkIDcUhDYcdEwSMQ4EzMDMHgySBFASWT4FtjGOFSIMtgio X-IronPort-AV: E=Sophos;i="4.97,577,1389744000"; d="scan'208";a="307617749" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 03 Mar 2014 13:08:49 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s23D8nA5022699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 13:08:49 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 07:08:48 -0600 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] DLEP DT summary Thread-Index: Ac7epLQRuQcQJFH9okar7MIy/pXlQgABJ/8uAD/G+lAVy4DfWgAPY6WA Date: Mon, 3 Mar 2014 13:08:48 +0000 Message-ID: References: <603F5FD847B5174CBDA37A9DC00532FB0B4E6FD2@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.17] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NZ9lRnfburbeInBEtmc44mQoiMo Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Dowdell, John" Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:09:21 -0000 On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun = wrote: > Hi Chris, >=20 > I did not want to join the DT, and still not getting their report, but > I want to discuss within WG list. I beleive editors should follow the > WG participants text amending, and follow consensus. I look forward to > comment on the DLEP on the list and in this meeting. Comments below, >=20 > Regards > AB >=20 > On 11/12/13, Dearlove, Christopher (UK) w= rote: >> Wrong I'm afraid, both procedurally and practically. WGs can't write >> documents, that just isn't a viable approach. Documents are written by >> authors, or sometimes editors. The WG can reject a document. But that's = not >> the same as writing one. >>=20 >=20 > I meant to say that DLEP draft is changing from using UDP to use TCP > without enough discussion on the WG list or final consensus. If > editors make the change in the draft which they already did, that will > affect the fairness of the final consensus and also the WG > discussions. I changed DLEP 05 to use TCP because the people on the design team wanted T= CP. I appreciate that you have expressed dissent. But so far, your dissent = is only one I've seen. If there are other working group participants that b= elieve moving to TCP is a bad thing, I hope they will express that view her= e on the list. Otherwise, it looks like you are "in the rough" on this one.= =20 Heck, I'd even change the transport to IPX if it would help get DLEP to rat= ification. When we (the co-authors) first floated this draft, we were under= the (obviously naive) impression that DLEP would be a "project". I'm not s= ure how, or why, it has morphed into a "career path". *Sigh*=85 That said, = i'd really like to get this draft to WGLC before my grandchildren have gran= dchildren... Regards, Stan >=20 > I feel now after the editors have made their decisions with the DT, > now I am forced to not discuss, or I am forced to be in a discouraged > position. It seems now it is better for me to leave the flow go into > DT decisions, and hopefully not all drafts take the same direction in > future, >=20 >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f >> Abdussalam Baryun >> Sent: 12 November 2013 16:30 >> To: Dowdell, John >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP DT summary >>=20 >> Hi John >>=20 >> I have been very interested and was regular posting and reviewing the wo= rk >> but should not be excluded (there are others ). However, I thank you and= the >> members of DT for your contributions, and always want to speed the proce= ss >> for DLEP but with best practices and awareness. In the last two meeting >> there were comments from the community that the DT should follow. The WG= did >> not decide to give its job to the DT. >>=20 >> I don't agree that the DT makes changes to the DLEP draft, the DT should >> report its recommendations to this list, so the WG decides and discusses >> what to do. >>=20 >> AB >>=20 >=20 >> On Tuesday, November 12, 2013, Dowdell, John wrote: >> For the avoidance of doubt, please understand that I asked for an inform= al >> meeting at Berlin IETF that half way through became the Design Team. The >> meeting attendees were drawn from those who had regularly posted on DLEP >> since the 00 draft, and therefore were deemed to be most interested in >> getting to an RFC, as I was. Kindly lay off the lead author of DLEP. >=20 > I am also, but big changes like using TCP need consensus, now with > draft changed I feel I have no interest in giving even a humm voice. >=20 >>=20 >> In the meantime, if anyone else is actively developing with DLEP (router= or >> modem side) and is willing to directly contribute to the speedy and >> successful development of the draft, please post on the manet list and w= e >> will be in touch. One person joined the team since the first meeting in >> Berlin. >=20 > I did not join the team, because I think it is with enough capacity, > and if me and other join it will become another MANET WG list. >=20 >>=20 >> For timescales and upcoming work, please listen to the DLEP presentation= in >> the early part of the manet WG meeting at Vancouver. >>=20 >=20 > I agree that all to listen to each other, so community listen and then > the community to be listened to as well, >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon Mar 3 06:22:00 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679C21A01AE for ; Mon, 3 Mar 2014 06:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhAzxndijVlh for ; Mon, 3 Mar 2014 06:21:50 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8CB1A01AD for ; Mon, 3 Mar 2014 06:21:50 -0800 (PST) Received: by mail-yk0-f178.google.com with SMTP id 79so10640444ykr.9 for ; Mon, 03 Mar 2014 06:21:47 -0800 (PST) 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=0s4xpnu3EUcNRJ5Uq87wqwfKxYMO1U9gSK7DkL/YTbg=; b=MzhSivox8aEQv5kqIs2+HvL7oxcKoxvYneNS0TxUD6MDJC+7Nqq7ZpBrTx0JVLiJRy ixEf0VjIGDFl1iRw8U7JndXvosuXmcN/ZkqyIJXvDzxIVl5GP6Ag9RLeAEDQSKU4qMlk PHK5/nKoJ1cPEH3P4/zvcjunrKvEppqGGt5gXMjlpDHWf/bB9liFdxeSwyd2eRjafODl 11krYv1udHh0Nun9RYE4Q3syVn3z7D4ijgEWGmw2Dk9IzZvsH7HiMx5Lqu4eZW04vH17 ABn0e52oT4KfiF6S4hkNa9/oUYxR5S6ZTmhTHMkVODrc47AQKHrrRswFWoSXB60RFovY y1jA== MIME-Version: 1.0 X-Received: by 10.236.151.198 with SMTP id b46mr22306310yhk.3.1393856507460; Mon, 03 Mar 2014 06:21:47 -0800 (PST) Received: by 10.170.202.7 with HTTP; Mon, 3 Mar 2014 06:21:47 -0800 (PST) In-Reply-To: References: <603F5FD847B5174CBDA37A9DC00532FB0B4E6FD2@SUCNPTEXM02.com.ad.uk.ds.corp> Date: Mon, 3 Mar 2014 15:21:47 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=20cf301cc5aafec14204f3b48110 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/g1GWC5uXUReXmughuGs71g3Imoo Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Dowdell, John" Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:21:58 -0000 --20cf301cc5aafec14204f3b48110 Content-Type: text/plain; charset=ISO-8859-1 Hi Stan, Thanks for you email, i want this draft to go ahead to WGLC with 04 draft, the 05 had not change only few word, but big changing of performance. I don't totally disagree with the authors because I see they are doing big effort to make the draft go forward which I agree and understand. However, I will prepare my comments with good reason why not TCP and there were inputs from WG before questioning and don't think the discussion ended. I think the reasons for going to TCP was not enough but the authors chosen before UDP and WG adopted that. I will prepare why not TCP, but I think DT should answer in its report first why not UDP then why TCP is with better performance. The only reason I notice from DT was design issues. @DT Please report : why not UDP in performance of DLEP as comparing TCP and UDP when using DLEP performance. I understand design purposes but would think of DLEP overall performance as well. AB On Monday, March 3, 2014, Stan Ratliff (sratliff) wrote: > > On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun > > wrote: > > > Hi Chris, > > > > I did not want to join the DT, and still not getting their report, but > > I want to discuss within WG list. I beleive editors should follow the > > WG participants text amending, and follow consensus. I look forward to > > comment on the DLEP on the list and in this meeting. Comments below, > > > > Regards > > AB > > > > On 11/12/13, Dearlove, Christopher (UK) > > wrote: > >> Wrong I'm afraid, both procedurally and practically. WGs can't write > >> documents, that just isn't a viable approach. Documents are written by > >> authors, or sometimes editors. The WG can reject a document. But that's > not > >> the same as writing one. > >> > > > > I meant to say that DLEP draft is changing from using UDP to use TCP > > without enough discussion on the WG list or final consensus. If > > editors make the change in the draft which they already did, that will > > affect the fairness of the final consensus and also the WG > > discussions. > > I changed DLEP 05 to use TCP because the people on the design team wanted > TCP. I appreciate that you have expressed dissent. But so far, your dissent > is only one I've seen. If there are other working group participants that > believe moving to TCP is a bad thing, I hope they will express that view > here on the list. Otherwise, it looks like you are "in the rough" on this > one. > > Heck, I'd even change the transport to IPX if it would help get DLEP to > ratification. When we (the co-authors) first floated this draft, we were > under the (obviously naive) impression that DLEP would be a "project". I'm > not sure how, or why, it has morphed into a "career path". *Sigh*... That > said, i'd really like to get this draft to WGLC before my grandchildren > have grandchildren... > > Regards, > Stan > > > > > > I feel now after the editors have made their decisions with the DT, > > now I am forced to not discuss, or I am forced to be in a discouraged > > position. It seems now it is better for me to leave the flow go into > > DT decisions, and hopefully not all drafts take the same direction in > > future, > > > >> From: manet-bounces@ietf.org [mailto: > manet-bounces@ietf.org ] On Behalf Of > >> Abdussalam Baryun > >> Sent: 12 November 2013 16:30 > >> To: Dowdell, John > >> Cc: manet@ietf.org > >> Subject: Re: [manet] DLEP DT summary > >> > >> Hi John > >> > >> I have been very interested and was regular posting and reviewing the > work > >> but should not be excluded (there are others ). However, I thank you > and the > >> members of DT for your contributions, and always want to speed the > process > >> for DLEP but with best practices and awareness. In the last two meeting > >> there were comments from the community that the DT should follow. The > WG did > >> not decide to give its job to the DT. > >> > >> I don't agree that the DT makes changes to the DLEP draft, the DT should > >> report its recommendations to this list, so the WG decides and discusses > >> what to do. > >> > >> AB > >> > > > >> On Tuesday, November 12, 2013, Dowdell, John wrote: > >> For the avoidance of doubt, please understand that I asked for an > informal > >> meeting at Berlin IETF that half way through became the Design Team. The > >> meeting attendees were drawn from those who had regularly posted on DLEP > >> since the 00 draft, and therefore were deemed to be most interested in > >> getting to an RFC, as I was. Kindly lay off the lead author of DLEP. > > > > I am also, but big changes like using TCP need consensus, now with > > draft changed I feel I have no interest in giving even a humm voice. > > > >> > >> In the meantime, if anyone else is actively developing with DLEP > (router or > >> modem side) and is willing to directly contribute to the speedy and > >> successful development of the draft, please post on the manet list and > we > >> will be in touch. One person joined the team since the first meeting in > >> Berlin. > > > > I did not join the team, because I think it is with enough capacity, > > and if me and other join it will become another MANET WG list. > > > >> > >> For timescales and upcoming work, please listen to the DLEP > presentation in > >> the early part of the manet WG meeting at Vancouver. > >> > > > > I agree that all to listen to each other, so community listen and then > > the community to be listened to as well, > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > --20cf301cc5aafec14204f3b48110 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Stan,

Thanks for you email, i want this draft to go a= head to WGLC with 04 draft, the 05 had not change only few word, but b= ig changing of performance.

 I don't tota= lly disagree with the authors because I see they are doing big effort to ma= ke the draft go forward which I agree and understand. However, I will = prepare my comments with good reason why not TCP and there were inputs from= WG before questioning and don't think the discussion ended. 

I think the reasons for going to TCP was not enough but= the authors chosen before UDP and WG adopted that. I will prepare why= not TCP, but I think DT should answer in its report first w= hy not UDP then why TCP is with better performance. The only reason I notic= e from DT was design issues. 

@DT
Please report : why not UDP in perfo= rmance of DLEP as comparing TCP and UDP when using DLEP performan= ce. I understand design purposes but would think of DLEP overall perfo= rmance as well. 

AB

On Monday, March 3, 2014, Stan Ratliff (sratl= iff) wrote:

On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

> Hi Chris,
>
> I did not want to join the DT, and still not getting their report, but=
> I want to discuss within WG list. I beleive editors should follow the<= br> > WG participants text amending, and follow consensus. I look forward to=
> comment on the DLEP on the list and in this meeting. Comments below, >
> Regards
> AB
>
> On 11/12/13, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>> Wrong I'm afraid, both procedurally and practically. WGs can&#= 39;t write
>> documents, that just isn't a viable approach. Documents are wr= itten by
>> authors, or sometimes editors. The WG can reject a document. But t= hat's not
>> the same as writing one.
>>
>
> I meant to say that DLEP draft is changing from using UDP to use TCP > without enough discussion on the WG list or final consensus. If
> editors make the change in the draft which they already did, that will=
> affect the fairness of the final consensus and also the WG
> discussions.

I changed DLEP 05 to use TCP because the people on the design team wanted T= CP. I appreciate that you have expressed dissent. But so far, your dissent = is only one I've seen. If there are other working group participants th= at believe moving to TCP is a bad thing, I hope they will express that view= here on the list. Otherwise, it looks like you are "in the rough"= ; on this one.

Heck, I'd even change the transport to IPX if it would help get DLEP to= ratification. When we (the co-authors) first floated this draft, we were u= nder the (obviously naive) impression that DLEP would be a "project&qu= ot;. I'm not sure how, or why, it has morphed into a "career path&= quot;. *Sigh*… That said, i'd really like to get this draft to W= GLC before my grandchildren have grandchildren...

Regards,
Stan


>
> I feel now after the editors have made their decisions with the DT, > now I am forced to not discuss, or I am forced to be in a discouraged<= br> > position. It seems now it is better for me to leave the flow go into > DT decisions, and hopefully not all drafts take the same direction in<= br> > future,
>
>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
>> Abdussalam Baryun
>> Sent: 12 November 2013 16:30
>> To: Dowdell, John
>> Cc: manet@ietf.org
>> Subject: Re: [manet] DLEP DT summary
>>
>> Hi John
>>
>> I have been very interested and was regular posting and reviewing = the work
>> but should not be excluded (there are others ). However, I thank y= ou and the
>> members of DT for your contributions, and always want to speed the= process
>> for DLEP but with best practices and awareness. In the last two me= eting
>> there were comments from the community that the DT should follow. = The WG did
>> not decide to give its job to the DT.
>>
>> I don't agree that the DT makes changes to the DLEP draft, the= DT should
>> report its recommendations to this list, so the WG decides and dis= cusses
>> what to do.
>>
>> AB
>>
>
>> On Tuesday, November 12, 2013, Dowdell, John wrote:
>> For the avoidance of doubt, please understand that I asked for an = informal
>> meeting at Berlin IETF that half way through became the Design Tea= m. The
>> meeting attendees were drawn from those who had regularly posted o= n DLEP
>> since the 00 draft, and therefore were deemed to be most intereste= d in
>> getting to an RFC, as I was. Kindly lay off the lead author of DLE= P.
>
> I am also, but big changes like using TCP need consensus, now with
> draft changed I feel I have no interest in giving even a humm voice. >
>>
>> In the meantime, if anyone else is actively developing with DLEP (= router or
>> modem side) and is willing to directly contribute to the speedy an= d
>> successful development of the draft, please post on the manet list= and we
>> will be in touch. One person joined the team since the first meeti= ng in
>> Berlin.
>
> I did not join the team, because I think it is with enough capacity, > and if me and other join it will become another MANET WG list.
>
>>
>> For timescales and upcoming work, please listen to the DLEP presen= tation in
>> the early part of the manet WG meeting at Vancouver.
>>
>
> I agree that all to listen to each other, so community listen and then=
> the community to be listened to as well,
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--20cf301cc5aafec14204f3b48110-- From nobody Mon Mar 3 06:30:47 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066EC1A00DA for ; Mon, 3 Mar 2014 06:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzsXBgu9nb65 for ; Mon, 3 Mar 2014 06:30:44 -0800 (PST) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF711A0002 for ; Mon, 3 Mar 2014 06:30:44 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id x13so3733877qcv.19 for ; Mon, 03 Mar 2014 06:30:41 -0800 (PST) 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=W4FblrBecGopsy1E+Q1TAc8aFQAl7NovT2S4rBbxNWc=; b=TUFAkiHLoo1JrPoVTwv/7zWoX6NZTShamnYKJUVAjCqvyrdv4zbVwXcwijh9UuW6Mt KZNCsx2rqR2S1rr5yNNnNTKgQxMP4KSZua0vUSZIw/LI5woHc3B/jWHZz5iwtphLfXA+ KwsOGk3yYLG9I/8QQGikyq/me7J9jw8WtPyXY8u0BLad4LBKOUtRNydR2EsHRSR8jnWL cuTGKMd0gnjDWaoorri0gnO1OVx+zbZ2hsoPq3t1zeoL6LUCF5tBpHUnn7RoR7kzDmhE wsJj9AudPa+qqdEVBZnvtSMxKH4mWKxngfLPzue5gAnL5TOJ50Zzgi00f2DTgnlKt82V vOPw== X-Received: by 10.140.34.231 with SMTP id l94mr23000597qgl.85.1393857041540; Mon, 03 Mar 2014 06:30:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.130.2 with HTTP; Mon, 3 Mar 2014 06:30:21 -0800 (PST) In-Reply-To: References: <603F5FD847B5174CBDA37A9DC00532FB0B4E6FD2@SUCNPTEXM02.com.ad.uk.ds.corp> From: Henning Rogge Date: Mon, 3 Mar 2014 14:30:21 +0000 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/f3B_WfmLxg4p-pxWta8bHFH7Arg Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Dowdell, John" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:30:47 -0000 The reason for TCP instead of UDP is very simple. The WG decided quite some time ago that we follow a "stateful DLEP" approach. DLEP contains ACK messages, which means that you have three options: 1) You can implement DLEP as "stop and wait", which means a sender can only a single packet that has to be acknowledged and then waits for the ACK before sending another one. 2) You can implement a whole bunch of "sequence number", "sliding window" and "ack/retransmission" mechanisms. In fact this is a step towards reinventing the wheel depending how clever you want to do this. 3) You can switch to a reliable transport protocol. We decided to use option 3) for DLEP-05 because its the easiest to implement and does not kill performance like a "stop and wait" strategy. Henning Rogge On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun wrote: > Hi Stan, > > Thanks for you email, i want this draft to go ahead to WGLC with 04 draft, > the 05 had not change only few word, but big changing of performance. > > I don't totally disagree with the authors because I see they are doing big > effort to make the draft go forward which I agree and understand. However, I > will prepare my comments with good reason why not TCP and there were inputs > from WG before questioning and don't think the discussion ended. > > I think the reasons for going to TCP was not enough but the authors chosen > before UDP and WG adopted that. I will prepare why not TCP, but I think DT > should answer in its report first why not UDP then why TCP is with better > performance. The only reason I notice from DT was design issues. > > @DT > Please report : why not UDP in performance of DLEP as comparing TCP and UDP > when using DLEP performance. I understand design purposes but would think of > DLEP overall performance as well. > > AB > > > On Monday, March 3, 2014, Stan Ratliff (sratliff) wrote: >> >> >> On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun >> wrote: >> >> > Hi Chris, >> > >> > I did not want to join the DT, and still not getting their report, but >> > I want to discuss within WG list. I beleive editors should follow the >> > WG participants text amending, and follow consensus. I look forward to >> > comment on the DLEP on the list and in this meeting. Comments below, >> > >> > Regards >> > AB >> > >> > On 11/12/13, Dearlove, Christopher (UK) >> > wrote: >> >> Wrong I'm afraid, both procedurally and practically. WGs can't write >> >> documents, that just isn't a viable approach. Documents are written by >> >> authors, or sometimes editors. The WG can reject a document. But that's >> >> not >> >> the same as writing one. >> >> >> > >> > I meant to say that DLEP draft is changing from using UDP to use TCP >> > without enough discussion on the WG list or final consensus. If >> > editors make the change in the draft which they already did, that will >> > affect the fairness of the final consensus and also the WG >> > discussions. >> >> I changed DLEP 05 to use TCP because the people on the design team wanted >> TCP. I appreciate that you have expressed dissent. But so far, your dissent >> is only one I've seen. If there are other working group participants that >> believe moving to TCP is a bad thing, I hope they will express that view >> here on the list. Otherwise, it looks like you are "in the rough" on this >> one. >> >> Heck, I'd even change the transport to IPX if it would help get DLEP to >> ratification. When we (the co-authors) first floated this draft, we were >> under the (obviously naive) impression that DLEP would be a "project". I'm >> not sure how, or why, it has morphed into a "career path". *Sigh*... That >> said, i'd really like to get this draft to WGLC before my grandchildren have >> grandchildren... >> >> Regards, >> Stan >> >> >> > >> > I feel now after the editors have made their decisions with the DT, >> > now I am forced to not discuss, or I am forced to be in a discouraged >> > position. It seems now it is better for me to leave the flow go into >> > DT decisions, and hopefully not all drafts take the same direction in >> > future, >> > >> >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >> >> Of >> >> Abdussalam Baryun >> >> Sent: 12 November 2013 16:30 >> >> To: Dowdell, John >> >> Cc: manet@ietf.org >> >> Subject: Re: [manet] DLEP DT summary >> >> >> >> Hi John >> >> >> >> I have been very interested and was regular posting and reviewing the >> >> work >> >> but should not be excluded (there are others ). However, I thank you >> >> and the >> >> members of DT for your contributions, and always want to speed the >> >> process >> >> for DLEP but with best practices and awareness. In the last two meeting >> >> there were comments from the community that the DT should follow. The >> >> WG did >> >> not decide to give its job to the DT. >> >> >> >> I don't agree that the DT makes changes to the DLEP draft, the DT >> >> should >> >> report its recommendations to this list, so the WG decides and >> >> discusses >> >> what to do. >> >> >> >> AB >> >> >> > >> >> On Tuesday, November 12, 2013, Dowdell, John wrote: >> >> For the avoidance of doubt, please understand that I asked for an >> >> informal >> >> meeting at Berlin IETF that half way through became the Design Team. >> >> The >> >> meeting attendees were drawn from those who had regularly posted on >> >> DLEP >> >> since the 00 draft, and therefore were deemed to be most interested in >> >> getting to an RFC, as I was. Kindly lay off the lead author of DLEP. >> > >> > I am also, but big changes like using TCP need consensus, now with >> > draft changed I feel I have no interest in giving even a humm voice. >> > >> >> >> >> In the meantime, if anyone else is actively developing with DLEP >> >> (router or >> >> modem side) and is willing to directly contribute to the speedy and >> >> successful development of the draft, please post on the manet list and >> >> we >> >> will be in touch. One person joined the team since the first meeting in >> >> Berlin. >> > >> > I did not join the team, because I think it is with enough capacity, >> > and if me and other join it will become another MANET WG list. >> > >> >> >> >> For timescales and upcoming work, please listen to the DLEP >> >> presentation in >> >> the early part of the manet WG meeting at Vancouver. >> >> >> > >> > I agree that all to listen to each other, so community listen and then >> > the community to be listened to as well, >> > >> > _______________________________________________ >> > 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 nobody Mon Mar 3 07:32:10 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D87B1A01BC for ; Mon, 3 Mar 2014 07:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuhO1SbLQ-SQ for ; Mon, 3 Mar 2014 07:32:02 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id EEFE81A0190 for ; Mon, 3 Mar 2014 07:32:01 -0800 (PST) Received: by mail-yh0-f50.google.com with SMTP id t59so3633506yho.23 for ; Mon, 03 Mar 2014 07:31:59 -0800 (PST) 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=hu9qcQCjz6Djthrbb3m8SiXA17QgihJG3HArYlDT6zw=; b=vN6MCyqB4cAj2s7//L1EDTCgQ3DzfEFS+B8kkBLUtgD6Pb8zr4eD19ZtEw2J/MfF08 5xbubgdpsiSiEWverpFr1MlN+0MBhGx5Ho1x36y8PTO75sZfkWxk60w9bAaRsm+BAwnl FBIY+Q5+KfVkxcs7DfIApEXsw4uKp3C3JsYXtLm7Gk2JlI7QhBU6MqMfn/JdH3QXO2aJ o3sE5/YkrzVD6dyNKBEkpo11W27B4HET29Y4ggAXFyqZUI5RDKcA6wHYL+RPG319kR13 Vs7U+GciXD+g4/H4/cTlw9+C1EehpfJ8taPChCvVtPfm9XXyWzr/vrydXcVyMouajafI R6oQ== MIME-Version: 1.0 X-Received: by 10.236.150.164 with SMTP id z24mr2526601yhj.75.1393860718860; Mon, 03 Mar 2014 07:31:58 -0800 (PST) Received: by 10.170.202.7 with HTTP; Mon, 3 Mar 2014 07:31:58 -0800 (PST) Date: Mon, 3 Mar 2014 16:31:58 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=20cf303b3c93039e3804f3b57dde Archived-At: http://mailarchive.ietf.org/arch/msg/manet/FWVpG8zXzUjAVLDkSs7zEqBlt2k Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Dowdell, John" , "Stan Ratliff \(sratliff\)" Subject: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:32:06 -0000 --20cf303b3c93039e3804f3b57dde Content-Type: text/plain; charset=ISO-8859-1 Hi Henning, Do you mean if the DLEP ACK messages are dropped then DLEP performance will be below 70 percent and 30 percent losses? MANET protocols always have percentages of errors. So do I understand that if there is ACK messages in any MANET protocol (which uses transport layer) then there are only three options as below. I think AODV is already has option of ACK message but still it works perfect with UDP, AB On Monday, March 3, 2014, Henning Rogge wrote: > The reason for TCP instead of UDP is very simple. > > The WG decided quite some time ago that we follow a "stateful DLEP" > approach. > > DLEP contains ACK messages, which means that you have three options: > > 1) You can implement DLEP as "stop and wait", which means a sender can > only a single packet that has to be acknowledged and then waits for > the ACK before sending another one. > > 2) You can implement a whole bunch of "sequence number", "sliding > window" and "ack/retransmission" mechanisms. In fact this is a step > towards reinventing the wheel depending how clever you want to do > this. > > 3) You can switch to a reliable transport protocol. > > We decided to use option 3) for DLEP-05 because its the easiest to > implement and does not kill performance like a "stop and wait" > strategy. > > Henning Rogge > > On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun > > wrote: > > Hi Stan, > > > > Thanks for you email, i want this draft to go ahead to WGLC with 04 > draft, > > the 05 had not change only few word, but big changing of performance. > > > > I don't totally disagree with the authors because I see they are doing > big > > effort to make the draft go forward which I agree and understand. > However, I > > will prepare my comments with good reason why not TCP and there were > inputs > > from WG before questioning and don't think the discussion ended. > > > > I think the reasons for going to TCP was not enough but the authors > chosen > > before UDP and WG adopted that. I will prepare why not TCP, but I think > DT > > should answer in its report first why not UDP then why TCP is with better > > performance. The only reason I notice from DT was design issues. > > > > @DT > > Please report : why not UDP in performance of DLEP as comparing TCP and > UDP > > when using DLEP performance. I understand design purposes but would > think of > > DLEP overall performance as well. > > > > AB > > > > > > On Monday, March 3, 2014, Stan Ratliff (sratliff) wrote: > >> > >> > >> On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com > > >> wrote: > >> > >> > Hi Chris, > >> > > >> > I did not want to join the DT, and still not getting their report, but > >> > I want to discuss within WG list. I beleive editors should follow the > >> > WG participants text amending, and follow consensus. I look forward to > >> > comment on the DLEP on the list and in this meeting. Comments below, > >> > > >> > Regards > >> > AB > >> > > >> > On 11/12/13, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com > > >> > wrote: > >> >> Wrong I'm afraid, both procedurally and practically. WGs can't write > >> >> documents, that just isn't a viable approach. Documents are written > by > >> >> authors, or sometimes editors. The WG can reject a document. But > that's > >> >> not > >> >> the same as writing one. > >> >> > >> > > >> > I meant to say that DLEP draft is changing from using UDP to use TCP > >> > without enough discussion on the WG list or final consensus. If > >> > editors make the change in the draft which they already did, that will > >> > affect the fairness of the final consensus and also the WG > >> > discussions. > >> > >> I changed DLEP 05 to use TCP because the people on the design team > wanted > >> TCP. I appreciate that you have expressed dissent. But so far, your > dissent > >> is only one I've seen. If there are other working group participants > that > >> believe moving to TCP is a bad thing, I hope they will express that view > >> here on the list. Otherwise, it looks like you are "in the rough" on > this > >> one. > >> > >> Heck, I'd even change the transport to IPX if it would help get DLEP to > >> ratification. When we (the co-authors) first floated this draft, we were > >> under the (obviously naive) impression that DLEP would be a "project". > I'm > >> not sure how, or why, it has morphed into a "career path". *Sigh*... > That > >> said, i'd really like to get this draft to WGLC before my grandchildren > have > >> grandchildren... > >> > >> Regards, > >> Stan > >> > >> > >> > > >> > I feel now after the editors have made their decisions with the DT, > >> > now I am forced to not discuss, or I am forced to be in a discouraged > >> > position. It seems now it is better for me to leave the flow go into > >> > DT decisions, and hopefully not all drafts take the same direction in > >> > future, > >> > > >> >> From: manet-bounces@ietf.org [mailto: > manet-bounces@ietf.org ] On Behalf > >> >> Of > >> >> Abdussalam Baryun > >> >> Sent: 12 November 2013 16:30 > >> >> To: Dowdell, John > >> >> Cc: manet@ietf.org > >> >> Subject: Re: [manet] DLEP DT summary > >> >> > >> >> Hi John > >> >> > >> >> I have been very interested and was regular posting and reviewing the > >> >> work > >> >> but should not be excluded (there are others ). However, I thank you > >> >> and the > >> >> members of DT for your contributions, and always want to speed the > >> >> process > >> >> for DLEP but with best practices and awareness. In the last two > meeting > >> >> there were comments from the community that the DT should follow. The > >> >> WG did > >> >> not decide to give its job to the DT. > >> >> > >> >> I don't agree that the DT makes changes to the DLEP draft, the DT > >> >> should > >> >> report its recommendations to this list, so the WG decides and > >> >> discusses > >> >> what to do. > >> >> > >> >> AB > >> >> > >> > > >> >> On Tuesday, November 12, 2013, Dowdell, John wrote: > >> >> For the avoidance of doubt, please understand that I asked for an > >> >> informal > >> >> meeting at Berlin IETF that half way through became the Design Team. > >> >> The > >> >> meeting attendees were drawn from those who had regularly posted on > >> >> DLEP > >> >> since the 00 draft, and therefore were deemed to be most interested > in > >> >> getting to an RFC, as I was. Kindly lay off the lead author of DLEP. > >> > > >> > I am also, but big changes like using TCP need consensus, now with > >> > draft changed I feel I have no interest in giving even a humm voice. > >> > > >> >> > >> >> In the meantime, if anyone else is actively developing with DLEP > >> >> (router or > >> >> modem side) and is willing to directly contribute to the speedy and > >> >> successful development of the draft, please post on the manet list > and > >> >> we > >> >> will be in touch. One person joined the team since the first meeting > in > >> >> Berlin. > >> > > >> > I did not join the team, because I think it is with enough capacity, > >> > and if me and other join it will become another MANET WG list. > >> > > >> >> > >> >> For timescales and upcoming work, please listen to the DLEP > >> >> presentation in > >> >> the early part of the manet WG meeting at Vancouver. > >> >> > >> > > >> > I agree that all to listen to each other, so community listen and then > >> > the community to be listened to as well, > >> > > >> > _______________________________________________ > >> > 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 > > > --20cf303b3c93039e3804f3b57dde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Henning,

Do you mean if the DLEP ACK messages are dro= pped then DLEP performance will be below 70 percent and 30 percent losses?= =A0MANET protocols always have percentages of errors.=A0

So do I=A0understand that if there is ACK messages in any MANET protoc= ol (which uses transport layer)=A0then there are only three options as belo= w. I think AODV is already has=A0option of ACK message but still it works p= erfect with UDP,

AB

On Monday, March 3, 2014, Henning Rogge wrot= e:
The reason for TCP instead of UDP is v= ery simple.

The WG decided quite some time ago that we follow a "stateful DLEP&quo= t; approach.

DLEP contains ACK messages, which means that you have three options:

1) You can implement DLEP as "stop and wait", which means a sende= r can
only a single packet that has to be acknowledged and then waits for
the ACK before sending another one.

2) You can implement a whole bunch of "sequence number", "sl= iding
window" and "ack/retransmission" mechanisms. In fact this is= a step
towards reinventing the wheel depending how clever you want to do
this.

3) You can switch to a reliable transport protocol.

We decided to use option 3) for DLEP-05 because its the easiest to
implement and does not kill performance like a "stop and wait" strategy.

Henning Rogge

On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> Hi Stan,
>
> Thanks for you email, i want this draft to go ahead to WGLC with 04 dr= aft,
> the 05 had not change only few word, but big changing of performance.<= br> >
> =A0I don't totally disagree with the authors because I see they ar= e doing big
> effort to make the draft go forward which I agree and understand. Howe= ver, I
> will prepare my comments with good reason why not TCP and there were i= nputs
> from WG before questioning and don't think the discussion ended. >
> I think the reasons for going to TCP was not enough but the authors ch= osen
> before UDP and WG adopted that. I will prepare why not TCP, but I thin= k DT
> should answer in its report first why not UDP then why TCP is with bet= ter
> performance. The only reason I notice from DT was design issues.
>
> @DT
> Please report : why not UDP in performance of DLEP as comparing TCP an= d UDP
> when using DLEP performance. I understand design purposes but would th= ink of
> DLEP overall performance as well.
>
> AB
>
>
> On Monday, March 3, 2014, Stan Ratliff (sratliff) wrote:
>>
>>
>> On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun <abdussalambaryun@gmail.com>
>> wrote:
>>
>> > Hi Chris,
>> >
>> > I did not want to join the DT, and still not getting their re= port, but
>> > I want to discuss within WG list. I beleive editors should fo= llow the
>> > WG participants text amending, and follow consensus. I look f= orward to
>> > comment on the DLEP on the list and in this meeting. Comments= below,
>> >
>> > Regards
>> > AB
>> >
>> > On 11/12/13, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>
>> > wrote:
>> >> Wrong I'm afraid, both procedurally and practically. = WGs can't write
>> >> documents, that just isn't a viable approach. Documen= ts are written by
>> >> authors, or sometimes editors. The WG can reject a docume= nt. But that's
>> >> not
>> >> the same as writing one.
>> >>
>> >
>> > I meant to say that DLEP draft is changing from using UDP to = use TCP
>> > without enough discussion on the WG list or final consensus. = If
>> > editors make the change in the draft which they already did, = that will
>> > affect the fairness of the final consensus and also the WG >> > discussions.
>>
>> I changed DLEP 05 to use TCP because the people on the design team= wanted
>> TCP. I appreciate that you have expressed dissent. But so far, you= r dissent
>> is only one I've seen. If there are other working group partic= ipants that
>> believe moving to TCP is a bad thing, I hope they will express tha= t view
>> here on the list. Otherwise, it looks like you are "in the ro= ugh" on this
>> one.
>>
>> Heck, I'd even change the transport to IPX if it would help ge= t DLEP to
>> ratification. When we (the co-authors) first floated this draft, w= e were
>> under the (obviously naive) impression that DLEP would be a "= project". I'm
>> not sure how, or why, it has morphed into a "career path"= ;. *Sigh*... That
>> said, i'd really like to get this draft to WGLC before my gran= dchildren have
>> grandchildren...
>>
>> Regards,
>> Stan
>>
>>
>> >
>> > I feel now after the editors have made their decisions with t= he DT,
>> > now I am forced to not discuss, or I am forced to be in a dis= couraged
>> > position. It seems now it is better for me to leave the flow = go into
>> > DT decisions, and hopefully not all drafts take the same dire= ction in
>> > future,
>> >
>> >> From: manet-bounces@ietf.org [m= ailto:manet-bounces@ietf.org] On Behalf
>> >> Of
>> >> Abdussalam Baryun
>> >> Sent: 12 November 2013 16:30
>> >> To: Dowdell, John
>> >> Cc: manet@ietf.org
>> >> Subject: Re: [manet] DLEP DT summary
>> >>
>> >> Hi John
>> >>
>> >> I have been very interested and was regular posting and r= eviewing the
>> >> work
>> >> but should not be excluded (there are others ). However, = I thank you
>> >> and the
>> >> members of DT for your contributions, and always want to = speed the
>> >> process
>> >> for DLEP but with best practices and awareness. In the la= st two meeting
>> >> there were comments from the community that the DT should= follow. The
>> >> WG did
>> >> not decide to give its job to the DT.
>> >>
>> >> I don't agree that the DT makes changes to the DLEP d= raft, the DT
>> >> should
>> >> report its recommendations to this list, so the WG decide= s and
>> >> discusses
>> >> what to do.
>> >>
>> >> AB
>> >>
>> >
>> >> On Tuesday, November 12, 2013, Dowdell, John wrote:
>> >> For the avoidance of doubt, please understand that I aske= d for an
>> >> informal
>> >> meeting at Berlin IETF that half way through became the D= esign Team.
>> >> The
>> >> meeting attendees were drawn from those who had regularly= posted on
>> >> DLEP
>> >> since the 00 draft, and therefore were deemed to be most = interested in
>> >> getting to an RFC, as I was. Kindly lay off the lead auth= or of DLEP.
>> >
>> > I am also, but big changes like using TCP need consensus, now= with
>> > draft changed I feel I have no interest in giving even a humm= voice.
>> >
>> >>
>> >> In the meantime, if anyone else is actively developing wi= th DLEP
>> >> (router or
>> >> modem side) and is willing to directly contribute to the = speedy and
>> >> successful development of the draft, please post on the m= anet list and
>> >> we
>> >> will be in touch. One person joined the team since the fi= rst meeting in
>> >> Berlin.
>> >
>> > I did not join the team, because I think it is with enough ca= pacity,
>> > and if me and other join it will become another MANET WG list= .
>> >
>> >>
>> >> For timescales and upcoming work, please listen to the DL= EP
>> >> presentation in
>> >> the early part of the manet WG meeting at Vancouver.
>> >>
>> >
>> > I agree that all to listen to each other, so community listen= and then
>> > the community to be listened to as well,
>> >
>> > _______________________________________________
>> > 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
>
--20cf303b3c93039e3804f3b57dde-- From nobody Mon Mar 3 07:34:49 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C59C1A004A for ; Mon, 3 Mar 2014 07:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbHptSC8RNz8 for ; Mon, 3 Mar 2014 07:34:44 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 55F361A01D4 for ; Mon, 3 Mar 2014 07:34:42 -0800 (PST) Received: by mail-yh0-f50.google.com with SMTP id t59so3667771yho.37 for ; Mon, 03 Mar 2014 07:34:39 -0800 (PST) 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=S4Cssy6zMSToo2MPf3UJd7WIZjYZgpwwjmP/zG736cE=; b=FxJvzy4R2voYqky08diEtwKfQdWj+37OBCmgw8N2DsLbOOInrV/xFqi3KSOmRFC0DR R1Nph2RK6bpRfVyagEDjMUE1QDFbqUOyW/li/OF4Is8QRhS4ub3JUdvUc0q5q4BG0UKd MdjbxRI8+DRHoVDckkHstBhwWkwCvpProd1xZ3syd/XK5qdUiAb+0DeqORCt7q/l0VD9 7eyrd2LGb199r3ySuVgX3Cos3R8W9UqbU9HSKLM/a1bE1HQK0Z+zja5FY28NaJ8/YwR7 PqfgYqJxEKkCirpDdtlmJMNeLdfCTmeJpJNjWe2RfDz5CrDMZbuAn2kcHjEPyM09sLOV Xx9Q== MIME-Version: 1.0 X-Received: by 10.236.135.15 with SMTP id t15mr21654208yhi.35.1393860879372; Mon, 03 Mar 2014 07:34:39 -0800 (PST) Received: by 10.170.202.7 with HTTP; Mon, 3 Mar 2014 07:34:39 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Mar 2014 16:34:39 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=14dae9d7c1f094d49804f3b58626 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8IZ1xRRtShhGVDVc43TUW5GSWcc Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Dowdell, John" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:34:48 -0000 --14dae9d7c1f094d49804f3b58626 Content-Type: text/plain; charset=ISO-8859-1 Sorry, the question meant to consider if dropped acks messages were about 10-30 percent error. AB On Monday, March 3, 2014, Abdussalam Baryun wrote: > Hi Henning, > > Do you mean if the DLEP ACK messages are dropped then DLEP performance > will be below 70 percent and 30 percent losses? MANET protocols always have > percentages of errors. > > So do I understand that if there is ACK messages in any MANET protocol > (which uses transport layer) then there are only three options as below. I > think AODV is already has option of ACK message but still it works perfect > with UDP, > > AB > > On Monday, March 3, 2014, Henning Rogge wrote: > >> The reason for TCP instead of UDP is very simple. >> >> The WG decided quite some time ago that we follow a "stateful DLEP" >> approach. >> >> DLEP contains ACK messages, which means that you have three options: >> >> 1) You can implement DLEP as "stop and wait", which means a sender can >> only a single packet that has to be acknowledged and then waits for >> the ACK before sending another one. >> >> 2) You can implement a whole bunch of "sequence number", "sliding >> window" and "ack/retransmission" mechanisms. In fact this is a step >> towards reinventing the wheel depending how clever you want to do >> this. >> >> 3) You can switch to a reliable transport protocol. >> >> We decided to use option 3) for DLEP-05 because its the easiest to >> implement and does not kill performance like a "stop and wait" >> strategy. >> >> Henning Rogge >> >> On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun >> wrote: >> > Hi Stan, >> > >> > Thanks for you email, i want this draft to go ahead to WGLC with 04 >> draft, >> > the 05 had not change only few word, but big changing of performance. >> > >> > I don't totally disagree with the authors because I see they are doing >> big >> > effort to make the draft go forward which I agree and understand. >> However, I >> > will prepare my comments with good reason why not TCP and there were >> inputs >> > from WG before questioning and don't think the discussion ended. >> > >> > I think the reasons for going to TCP was not enough but the authors >> chosen >> > before UDP and WG adopted that. I will prepare why not TCP, but I think >> DT >> > should answer in its report first why not UDP then why TCP is with >> better >> > performance. The only reason I notice from DT was design issues. >> > >> > @DT >> > Please report : why not UDP in performance of DLEP as comparing TCP and >> UDP >> > when using DLEP performance. I understand design purposes but would >> think of >> > DLEP overall performance as well. >> > >> > AB >> > >> > >> > On Monday, March 3, 2014, Stan Ratliff (sratliff) wrote: >> >> >> >> >> >> On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun < >> abdussalambaryun@gmail.com> >> >> wrote: >> >> >> >> > Hi Chris, >> >> > >> >> > I did not want to join the DT, and still not getting their report, >> but >> >> > I want to discuss within WG list. I beleive editors should follow the >> >> > WG participants text amending, and follow consensus. I look forward >> to >> >> > comment on the DLEP on the list and in this meeting. Comments below, >> >> > >> >> > Regards >> >> > AB >> >> > >> >> > On 11/12/13, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> >> >> > wrote: >> >> >> Wrong I'm afraid, both procedurally and practically. WGs can't write >> >> >> documents, that just isn't a viable approach. Documents are written >> by >> >> >> authors, or sometimes editors. The WG can reject a document. But >> that's >> >> >> not >> >> >> the same as writing one. >> >> >> >> >> > >> >> > I meant to say that DLEP draft is changing from using UDP to use TCP >> >> > without enough discussion on the WG list or final consensus. If >> >> > editors make the change in the draft which they already did, that >> will >> >> > affect the fairness of the final consensus and also the WG >> >> > discussions. >> >> >> >> I changed DLEP 05 to use TCP because the people on the design team >> wanted >> >> TCP. I appreciate that you have expressed dissent. But so far, your >> dissent >> >> is only one I've seen. If there are other working group participants >> that >> >> believe moving to TCP is a bad thing, I hope they will express that >> view >> >> here on the list. Otherwise, it looks like you are "in the rough" on >> this >> >> one. >> >> >> >> Heck, I'd even change the transport to IPX if it would help get DLEP to >> >> ratification. When we (the co-authors) first floated this draft, we >> were >> >> under the (obviously naive) impression that DLEP would be a "project". >> I'm >> >> not sure how, or why, it has morphed into a "career path". *Sigh*... >> That >> >> said, i'd really like to get this draft to WGLC before my >> grandchildren have >> >> grandchildren... >> >> >> >> Regards, >> >> Stan >> >> >> >> >> >> > >> >> > I feel now after the editors have made their decisions with the DT, >> >> > now I am forced to not discuss, or I am forced to be in a discouraged >> >> > position. It seems now it is better for me to leave the flow go into >> >> > DT decisions, and hopefully not all drafts take the same direction in >> >> > future, >> >> > >> >> >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >> Behalf >> >> >> Of >> >> >> Abdussalam Baryun >> >> >> Sent: 12 November 2013 16:30 >> >> >> To: Dowdell, John >> >> >> Cc: manet@ietf.org >> >> >> Subject: Re: [manet] DLEP DT summary >> >> >> >> >> >> Hi John >> >> >> >> >> >> I have been very interested and was regular posting and reviewing >> the >> >> >> work >> >> >> but should not be excluded (there are others ). However, I thank you >> >> >> and the >> >> >> members of DT for your contributions, and always want to speed the >> >> >> process >> >> >> for DLEP but with best practices and awareness. In the last two >> meeting >> >> >> there were comments from the community that the DT should follow. >> The >> >> >> WG did >> >> >> not decide to give its job to the DT. >> >> >> >> >> >> I don't agree that the DT makes changes to the DLEP draft, the DT >> >> >> should >> >> >> report its recommendations to this list, so the WG decides and >> >> >> discusses >> >> >> what to do. >> >> >> >> >> >> AB >> >> >> >> >> > >> >> >> On Tuesday, November 12, 2013, Dowdell, John wrote: >> >> >> For the avoidance of doubt, please understand that I asked for an >> >> >> informal >> >> >> meeting at Berlin IETF that half way through became the Design Team. >> >> >> The >> >> >> meeting attendees were drawn from those who had regularly posted on >> >> >> DLEP >> >> >> since the 00 draft, and therefore were deemed to be most interested >> in >> >> >> getting to an RFC, as I was. Kindly lay off the lead author of DLEP. >> >> > >> >> > I am also, but big changes like using TCP need consensus, now with >> >> > draft changed I feel I have no interest in giving even a humm voice. >> >> > >> >> >> >> >> >> In the meantime, if anyone else is actively developing with DLEP >> >> >> (router or >> >> >> modem side) and is willing to directly contribute to the speedy and >> >> >> successful development of the draft, please post on the manet list >> and >> >> >> we >> >> >> will be in touch. One person joined the team since the first >> meeting in >> >> >> Berlin. >> >> > >> >> > I did not join the team, because I think it is with enough capacity, >> >> > and if me and other join it will become another MANET WG list. >> >> > >> >> >> >> >> >> For timescales and upcoming work, please listen to the DLEP >> >> >> presentation in >> >> >> the early part of the manet WG meeting at Vancouver. >> >> >> >> >> > >> >> > I agree that all to listen to each other, so community listen and >> then >> >> > the community to be listened to as well, >> >> > >> >> > _______________________________________________ >> >> > 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 >> > >> > --14dae9d7c1f094d49804f3b58626 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, the question meant to consider=A0if dropped acks messages were=A0abo= ut 10-30 percent error.=A0

AB

On Monday, March 3,= 2014, Abdussalam Baryun wrote:
Hi Henning,

Do you mean if the DLEP ACK messages are dro= pped then DLEP performance will be below 70 percent and 30 percent losses?= =A0MANET protocols always have percentages of errors.=A0

So do I=A0understand that if there is ACK messages in any MANET protoc= ol (which uses transport layer)=A0then there are only three options as belo= w. I think AODV is already has=A0option of ACK message but still it works p= erfect with UDP,

AB

On Monday, March 3, 2014, Henning Rogge wrot= e:
The reason for TCP instead of UDP is v= ery simple.

The WG decided quite some time ago that we follow a "stateful DLEP&quo= t; approach.

DLEP contains ACK messages, which means that you have three options:

1) You can implement DLEP as "stop and wait", which means a sende= r can
only a single packet that has to be acknowledged and then waits for
the ACK before sending another one.

2) You can implement a whole bunch of "sequence number", "sl= iding
window" and "ack/retransmission" mechanisms. In fact this is= a step
towards reinventing the wheel depending how clever you want to do
this.

3) You can switch to a reliable transport protocol.

We decided to use option 3) for DLEP-05 because its the easiest to
implement and does not kill performance like a "stop and wait" strategy.

Henning Rogge

On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> Hi Stan,
>
> Thanks for you email, i want this draft to go ahead to WGLC with 04 dr= aft,
> the 05 had not change only few word, but big changing of performance.<= br> >
> =A0I don't totally disagree with the authors because I see they ar= e doing big
> effort to make the draft go forward which I agree and understand. Howe= ver, I
> will prepare my comments with good reason why not TCP and there were i= nputs
> from WG before questioning and don't think the discussion ended. >
> I think the reasons for going to TCP was not enough but the authors ch= osen
> before UDP and WG adopted that. I will prepare why not TCP, but I thin= k DT
> should answer in its report first why not UDP then why TCP is with bet= ter
> performance. The only reason I notice from DT was design issues.
>
> @DT
> Please report : why not UDP in performance of DLEP as comparing TCP an= d UDP
> when using DLEP performance. I understand design purposes but would th= ink of
> DLEP overall performance as well.
>
> AB
>
>
> On Monday, March 3, 2014, Stan Ratliff (sratliff) wrote:
>>
>>
>> On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun <abdussalambar= yun@gmail.com>
>> wrote:
>>
>> > Hi Chris,
>> >
>> > I did not want to join the DT, and still not getting their re= port, but
>> > I want to discuss within WG list. I beleive editors should fo= llow the
>> > WG participants text amending, and follow consensus. I look f= orward to
>> > comment on the DLEP on the list and in this meeting. Comments= below,
>> >
>> > Regards
>> > AB
>> >
>> > On 11/12/13, Dearlove, Christopher (UK) <chris.dearlove= @baesystems.com>
>> > wrote:
>> >> Wrong I'm afraid, both procedurally and practically. = WGs can't write
>> >> documents, that just isn't a viable approach. Documen= ts are written by
>> >> authors, or sometimes editors. The WG can reject a docume= nt. But that's
>> >> not
>> >> the same as writing one.
>> >>
>> >
>> > I meant to say that DLEP draft is changing from using UDP to = use TCP
>> > without enough discussion on the WG list or final consensus. = If
>> > editors make the change in the draft which they already did, = that will
>> > affect the fairness of the final consensus and also the WG >> > discussions.
>>
>> I changed DLEP 05 to use TCP because the people on the design team= wanted
>> TCP. I appreciate that you have expressed dissent. But so far, you= r dissent
>> is only one I've seen. If there are other working group partic= ipants that
>> believe moving to TCP is a bad thing, I hope they will express tha= t view
>> here on the list. Otherwise, it looks like you are "in the ro= ugh" on this
>> one.
>>
>> Heck, I'd even change the transport to IPX if it would help ge= t DLEP to
>> ratification. When we (the co-authors) first floated this draft, w= e were
>> under the (obviously naive) impression that DLEP would be a "= project". I'm
>> not sure how, or why, it has morphed into a "career path"= ;. *Sigh*... That
>> said, i'd really like to get this draft to WGLC before my gran= dchildren have
>> grandchildren...
>>
>> Regards,
>> Stan
>>
>>
>> >
>> > I feel now after the editors have made their decisions with t= he DT,
>> > now I am forced to not discuss, or I am forced to be in a dis= couraged
>> > position. It seems now it is better for me to leave the flow = go into
>> > DT decisions, and hopefully not all drafts take the same dire= ction in
>> > future,
>> >
>> >> From: manet-bounces@ietf.org [mailto:manet-boun= ces@ietf.org] On Behalf
>> >> Of
>> >> Abdussalam Baryun
>> >> Sent: 12 November 2013 16:30
>> >> To: Dowdell, John
>> >> Cc: manet@ietf.org
>> >> Subject: Re: [manet] DLEP DT summary
>> >>
>> >> Hi John
>> >>
>> >> I have been very interested and was regular posting and r= eviewing the
>> >> work
>> >> but should not be excluded (there are others ). However, = I thank you
>> >> and the
>> >> members of DT for your contributions, and always want to = speed the
>> >> process
>> >> for DLEP but with best practices and awareness. In the la= st two meeting
>> >> there were comments from the community that the DT should= follow. The
>> >> WG did
>> >> not decide to give its job to the DT.
>> >>
>> >> I don't agree that the DT makes changes to the DLEP d= raft, the DT
>> >> should
>> >> report its recommendations to this list, so the WG decide= s and
>> >> discusses
>> >> what to do.
>> >>
>> >> AB
>> >>
>> >
>> >> On Tuesday, November 12, 2013, Dowdell, John wrote:
>> >> For the avoidance of doubt, please understand that I aske= d for an
>> >> informal
>> >> meeting at Berlin IETF that half way through became the D= esign Team.
>> >> The
>> >> meeting attendees were drawn from those who had regularly= posted on
>> >> DLEP
>> >> since the 00 draft, and therefore were deemed to be most = interested in
>> >> getting to an RFC, as I was. Kindly lay off the lead auth= or of DLEP.
>> >
>> > I am also, but big changes like using TCP need consensus, now= with
>> > draft changed I feel I have no interest in giving even a humm= voice.
>> >
>> >>
>> >> In the meantime, if anyone else is actively developing wi= th DLEP
>> >> (router or
>> >> modem side) and is willing to directly contribute to the = speedy and
>> >> successful development of the draft, please post on the m= anet list and
>> >> we
>> >> will be in touch. One person joined the team since the fi= rst meeting in
>> >> Berlin.
>> >
>> > I did not join the team, because I think it is with enough ca= pacity,
>> > and if me and other join it will become another MANET WG list= .
>> >
>> >>
>> >> For timescales and upcoming work, please listen to the DL= EP
>> >> presentation in
>> >> the early part of the manet WG meeting at Vancouver.
>> >>
>> >
>> > I agree that all to listen to each other, so community listen= and then
>> > the community to be listened to as well,
>> >
>> > _______________________________________________
>> > 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
>
--14dae9d7c1f094d49804f3b58626-- From nobody Mon Mar 3 07:37:15 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD171A01E9 for ; Mon, 3 Mar 2014 07:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tuS0srEUMpr for ; Mon, 3 Mar 2014 07:37:10 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E92261A01E8 for ; Mon, 3 Mar 2014 07:37:09 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id e16so3799624qcx.6 for ; Mon, 03 Mar 2014 07:37:07 -0800 (PST) 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=vje2aU0h//R4o2p96WnNjTWWCPfQnkJLbOTgff7B0TM=; b=pafjwk6DZV+WL+fdQksxBKryY4y6zrpY2Bc6PK3dxQ0rxzXNSMPsRZxwIfIGlyASdQ Y5ENMDbNwbOTOAkkATqLBeKb1iSQzhwtYQ810Z/DnsKbViTG7Db0uB1m63zGKBgNWR0L VF1MwzHm03NzBlp5l96wtf0QaajvDgxNvukxmyR3+CTmd+1dC/QOMnUZXwUq1WJ1GcUY UYiuSV1P7amlTj8k01FCdVZKRInS15+add8CIqcG4ro26+npB2pazTk1a8Qa7WZlFlsQ cfzntIRaUPTiEzOIa4VpkGbUQVTDV4A7pLT/PeJ9uFJhlSuBPkhyrWxDKN9xEsfl6s3G 1HkQ== MIME-Version: 1.0 X-Received: by 10.224.171.200 with SMTP id i8mr3185826qaz.96.1393861026912; Mon, 03 Mar 2014 07:37:06 -0800 (PST) Received: by 10.224.130.2 with HTTP; Mon, 3 Mar 2014 07:37:06 -0800 (PST) Received: by 10.224.130.2 with HTTP; Mon, 3 Mar 2014 07:37:06 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Mar 2014 15:37:06 +0000 Message-ID: From: Henning Rogge To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=001a11c2ca88601d8004f3b58fbf Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PKZOsv8xNP-h_ACr7zRkBYwfMwU Cc: "Dearlove, Christopher \(UK\)" , MANET IETF , "Dowdell, John" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:37:14 -0000 --001a11c2ca88601d8004f3b58fbf Content-Type: text/plain; charset=ISO-8859-1 What you write make no sense at all. I am not even sure it has much to do with my answer. DLEP is not an "over the air" protocol... I also recommend to look up "stop and wait" protocol. Henning On Mar 3, 2014 4:31 PM, "Abdussalam Baryun" wrote: > Hi Henning, > > Do you mean if the DLEP ACK messages are dropped then DLEP performance > will be below 70 percent and 30 percent losses? MANET protocols always have > percentages of errors. > > So do I understand that if there is ACK messages in any MANET protocol > (which uses transport layer) then there are only three options as below. I > think AODV is already has option of ACK message but still it works perfect > with UDP, > > AB > > On Monday, March 3, 2014, Henning Rogge wrote: > >> The reason for TCP instead of UDP is very simple. >> >> The WG decided quite some time ago that we follow a "stateful DLEP" >> approach. >> >> DLEP contains ACK messages, which means that you have three options: >> >> 1) You can implement DLEP as "stop and wait", which means a sender can >> only a single packet that has to be acknowledged and then waits for >> the ACK before sending another one. >> >> 2) You can implement a whole bunch of "sequence number", "sliding >> window" and "ack/retransmission" mechanisms. In fact this is a step >> towards reinventing the wheel depending how clever you want to do >> this. >> >> 3) You can switch to a reliable transport protocol. >> >> We decided to use option 3) for DLEP-05 because its the easiest to >> implement and does not kill performance like a "stop and wait" >> strategy. >> >> Henning Rogge >> >> On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun >> wrote: >> > Hi Stan, >> > >> > Thanks for you email, i want this draft to go ahead to WGLC with 04 >> draft, >> > the 05 had not change only few word, but big changing of performance. >> > >> > I don't totally disagree with the authors because I see they are doing >> big >> > effort to make the draft go forward which I agree and understand. >> However, I >> > will prepare my comments with good reason why not TCP and there were >> inputs >> > from WG before questioning and don't think the discussion ended. >> > >> > I think the reasons for going to TCP was not enough but the authors >> chosen >> > before UDP and WG adopted that. I will prepare why not TCP, but I think >> DT >> > should answer in its report first why not UDP then why TCP is with >> better >> > performance. The only reason I notice from DT was design issues. >> > >> > @DT >> > Please report : why not UDP in performance of DLEP as comparing TCP and >> UDP >> > when using DLEP performance. I understand design purposes but would >> think of >> > DLEP overall performance as well. >> > >> > AB >> > >> > >> > On Monday, March 3, 2014, Stan Ratliff (sratliff) wrote: >> >> >> >> >> >> On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun < >> abdussalambaryun@gmail.com> >> >> wrote: >> >> >> >> > Hi Chris, >> >> > >> >> > I did not want to join the DT, and still not getting their report, >> but >> >> > I want to discuss within WG list. I beleive editors should follow the >> >> > WG participants text amending, and follow consensus. I look forward >> to >> >> > comment on the DLEP on the list and in this meeting. Comments below, >> >> > >> >> > Regards >> >> > AB >> >> > >> >> > On 11/12/13, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> >> >> > wrote: >> >> >> Wrong I'm afraid, both procedurally and practically. WGs can't write >> >> >> documents, that just isn't a viable approach. Documents are written >> by >> >> >> authors, or sometimes editors. The WG can reject a document. But >> that's >> >> >> not >> >> >> the same as writing one. >> >> >> >> >> > >> >> > I meant to say that DLEP draft is changing from using UDP to use TCP >> >> > without enough discussion on the WG list or final consensus. If >> >> > editors make the change in the draft which they already did, that >> will >> >> > affect the fairness of the final consensus and also the WG >> >> > discussions. >> >> >> >> I changed DLEP 05 to use TCP because the people on the design team >> wanted >> >> TCP. I appreciate that you have expressed dissent. But so far, your >> dissent >> >> is only one I've seen. If there are other working group participants >> that >> >> believe moving to TCP is a bad thing, I hope they will express that >> view >> >> here on the list. Otherwise, it looks like you are "in the rough" on >> this >> >> one. >> >> >> >> Heck, I'd even change the transport to IPX if it would help get DLEP to >> >> ratification. When we (the co-authors) first floated this draft, we >> were >> >> under the (obviously naive) impression that DLEP would be a "project". >> I'm >> >> not sure how, or why, it has morphed into a "career path". *Sigh*... >> That >> >> said, i'd really like to get this draft to WGLC before my >> grandchildren have >> >> grandchildren... >> >> >> >> Regards, >> >> Stan >> >> >> >> >> >> > >> >> > I feel now after the editors have made their decisions with the DT, >> >> > now I am forced to not discuss, or I am forced to be in a discouraged >> >> > position. It seems now it is better for me to leave the flow go into >> >> > DT decisions, and hopefully not all drafts take the same direction in >> >> > future, >> >> > >> >> >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >> Behalf >> >> >> Of >> >> >> Abdussalam Baryun >> >> >> Sent: 12 November 2013 16:30 >> >> >> To: Dowdell, John >> >> >> Cc: manet@ietf.org >> >> >> Subject: Re: [manet] DLEP DT summary >> >> >> >> >> >> Hi John >> >> >> >> >> >> I have been very interested and was regular posting and reviewing >> the >> >> >> work >> >> >> but should not be excluded (there are others ). However, I thank you >> >> >> and the >> >> >> members of DT for your contributions, and always want to speed the >> >> >> process >> >> >> for DLEP but with best practices and awareness. In the last two >> meeting >> >> >> there were comments from the community that the DT should follow. >> The >> >> >> WG did >> >> >> not decide to give its job to the DT. >> >> >> >> >> >> I don't agree that the DT makes changes to the DLEP draft, the DT >> >> >> should >> >> >> report its recommendations to this list, so the WG decides and >> >> >> discusses >> >> >> what to do. >> >> >> >> >> >> AB >> >> >> >> >> > >> >> >> On Tuesday, November 12, 2013, Dowdell, John wrote: >> >> >> For the avoidance of doubt, please understand that I asked for an >> >> >> informal >> >> >> meeting at Berlin IETF that half way through became the Design Team. >> >> >> The >> >> >> meeting attendees were drawn from those who had regularly posted on >> >> >> DLEP >> >> >> since the 00 draft, and therefore were deemed to be most interested >> in >> >> >> getting to an RFC, as I was. Kindly lay off the lead author of DLEP. >> >> > >> >> > I am also, but big changes like using TCP need consensus, now with >> >> > draft changed I feel I have no interest in giving even a humm voice. >> >> > >> >> >> >> >> >> In the meantime, if anyone else is actively developing with DLEP >> >> >> (router or >> >> >> modem side) and is willing to directly contribute to the speedy and >> >> >> successful development of the draft, please post on the manet list >> and >> >> >> we >> >> >> will be in touch. One person joined the team since the first >> meeting in >> >> >> Berlin. >> >> > >> >> > I did not join the team, because I think it is with enough capacity, >> >> > and if me and other join it will become another MANET WG list. >> >> > >> >> >> >> >> >> For timescales and upcoming work, please listen to the DLEP >> >> >> presentation in >> >> >> the early part of the manet WG meeting at Vancouver. >> >> >> >> >> > >> >> > I agree that all to listen to each other, so community listen and >> then >> >> > the community to be listened to as well, >> >> > >> >> > _______________________________________________ >> >> > 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 >> > >> > --001a11c2ca88601d8004f3b58fbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

What you write make no sense at all. I am not even sure it h= as much to do with my answer.

DLEP is not an "over the air" protocol... I also r= ecommend to look up "stop and wait" protocol.

Henning

On Mar 3, 2014 4:31 PM, "Abdussalam Baryun&= quot; <abdussalambaryun@gm= ail.com> wrote:
Hi Henning,

Do you mean if the DLEP ACK messages are dro= pped then DLEP performance will be below 70 percent and 30 percent losses?= =A0MANET protocols always have percentages of errors.=A0

So do I=A0understand that if there is ACK messages in any MANET protoc= ol (which uses transport layer)=A0then there are only three options as belo= w. I think AODV is already has=A0option of ACK message but still it works p= erfect with UDP,

AB

On Monday, March 3, 2014, Henning Rogge wrot= e:
The reason for TCP instead of UDP is v= ery simple.

The WG decided quite some time ago that we follow a "stateful DLEP&quo= t; approach.

DLEP contains ACK messages, which means that you have three options:

1) You can implement DLEP as "stop and wait", which means a sende= r can
only a single packet that has to be acknowledged and then waits for
the ACK before sending another one.

2) You can implement a whole bunch of "sequence number", "sl= iding
window" and "ack/retransmission" mechanisms. In fact this is= a step
towards reinventing the wheel depending how clever you want to do
this.

3) You can switch to a reliable transport protocol.

We decided to use option 3) for DLEP-05 because its the easiest to
implement and does not kill performance like a "stop and wait" strategy.

Henning Rogge

On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> Hi Stan,
>
> Thanks for you email, i want this draft to go ahead to WGLC with 04 dr= aft,
> the 05 had not change only few word, but big changing of performance.<= br> >
> =A0I don't totally disagree with the authors because I see they ar= e doing big
> effort to make the draft go forward which I agree and understand. Howe= ver, I
> will prepare my comments with good reason why not TCP and there were i= nputs
> from WG before questioning and don't think the discussion ended. >
> I think the reasons for going to TCP was not enough but the authors ch= osen
> before UDP and WG adopted that. I will prepare why not TCP, but I thin= k DT
> should answer in its report first why not UDP then why TCP is with bet= ter
> performance. The only reason I notice from DT was design issues.
>
> @DT
> Please report : why not UDP in performance of DLEP as comparing TCP an= d UDP
> when using DLEP performance. I understand design purposes but would th= ink of
> DLEP overall performance as well.
>
> AB
>
>
> On Monday, March 3, 2014, Stan Ratliff (sratliff) wrote:
>>
>>
>> On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun <abdussalambar= yun@gmail.com>
>> wrote:
>>
>> > Hi Chris,
>> >
>> > I did not want to join the DT, and still not getting their re= port, but
>> > I want to discuss within WG list. I beleive editors should fo= llow the
>> > WG participants text amending, and follow consensus. I look f= orward to
>> > comment on the DLEP on the list and in this meeting. Comments= below,
>> >
>> > Regards
>> > AB
>> >
>> > On 11/12/13, Dearlove, Christopher (UK) <chris.dearlove= @baesystems.com>
>> > wrote:
>> >> Wrong I'm afraid, both procedurally and practically. = WGs can't write
>> >> documents, that just isn't a viable approach. Documen= ts are written by
>> >> authors, or sometimes editors. The WG can reject a docume= nt. But that's
>> >> not
>> >> the same as writing one.
>> >>
>> >
>> > I meant to say that DLEP draft is changing from using UDP to = use TCP
>> > without enough discussion on the WG list or final consensus. = If
>> > editors make the change in the draft which they already did, = that will
>> > affect the fairness of the final consensus and also the WG >> > discussions.
>>
>> I changed DLEP 05 to use TCP because the people on the design team= wanted
>> TCP. I appreciate that you have expressed dissent. But so far, you= r dissent
>> is only one I've seen. If there are other working group partic= ipants that
>> believe moving to TCP is a bad thing, I hope they will express tha= t view
>> here on the list. Otherwise, it looks like you are "in the ro= ugh" on this
>> one.
>>
>> Heck, I'd even change the transport to IPX if it would help ge= t DLEP to
>> ratification. When we (the co-authors) first floated this draft, w= e were
>> under the (obviously naive) impression that DLEP would be a "= project". I'm
>> not sure how, or why, it has morphed into a "career path"= ;. *Sigh*... That
>> said, i'd really like to get this draft to WGLC before my gran= dchildren have
>> grandchildren...
>>
>> Regards,
>> Stan
>>
>>
>> >
>> > I feel now after the editors have made their decisions with t= he DT,
>> > now I am forced to not discuss, or I am forced to be in a dis= couraged
>> > position. It seems now it is better for me to leave the flow = go into
>> > DT decisions, and hopefully not all drafts take the same dire= ction in
>> > future,
>> >
>> >> From: manet-bounces@ietf.org [mailto:manet-boun= ces@ietf.org] On Behalf
>> >> Of
>> >> Abdussalam Baryun
>> >> Sent: 12 November 2013 16:30
>> >> To: Dowdell, John
>> >> Cc: manet@ietf.org
>> >> Subject: Re: [manet] DLEP DT summary
>> >>
>> >> Hi John
>> >>
>> >> I have been very interested and was regular posting and r= eviewing the
>> >> work
>> >> but should not be excluded (there are others ). However, = I thank you
>> >> and the
>> >> members of DT for your contributions, and always want to = speed the
>> >> process
>> >> for DLEP but with best practices and awareness. In the la= st two meeting
>> >> there were comments from the community that the DT should= follow. The
>> >> WG did
>> >> not decide to give its job to the DT.
>> >>
>> >> I don't agree that the DT makes changes to the DLEP d= raft, the DT
>> >> should
>> >> report its recommendations to this list, so the WG decide= s and
>> >> discusses
>> >> what to do.
>> >>
>> >> AB
>> >>
>> >
>> >> On Tuesday, November 12, 2013, Dowdell, John wrote:
>> >> For the avoidance of doubt, please understand that I aske= d for an
>> >> informal
>> >> meeting at Berlin IETF that half way through became the D= esign Team.
>> >> The
>> >> meeting attendees were drawn from those who had regularly= posted on
>> >> DLEP
>> >> since the 00 draft, and therefore were deemed to be most = interested in
>> >> getting to an RFC, as I was. Kindly lay off the lead auth= or of DLEP.
>> >
>> > I am also, but big changes like using TCP need consensus, now= with
>> > draft changed I feel I have no interest in giving even a humm= voice.
>> >
>> >>
>> >> In the meantime, if anyone else is actively developing wi= th DLEP
>> >> (router or
>> >> modem side) and is willing to directly contribute to the = speedy and
>> >> successful development of the draft, please post on the m= anet list and
>> >> we
>> >> will be in touch. One person joined the team since the fi= rst meeting in
>> >> Berlin.
>> >
>> > I did not join the team, because I think it is with enough ca= pacity,
>> > and if me and other join it will become another MANET WG list= .
>> >
>> >>
>> >> For timescales and upcoming work, please listen to the DL= EP
>> >> presentation in
>> >> the early part of the manet WG meeting at Vancouver.
>> >>
>> >
>> > I agree that all to listen to each other, so community listen= and then
>> > the community to be listened to as well,
>> >
>> > _______________________________________________
>> > 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
>
--001a11c2ca88601d8004f3b58fbf-- From nobody Mon Mar 3 07:42:32 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB5B1A01E2 for ; Mon, 3 Mar 2014 07:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_xg_6vQZMYs for ; Mon, 3 Mar 2014 07:42:30 -0800 (PST) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8D1A01DF for ; Mon, 3 Mar 2014 07:42:29 -0800 (PST) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,578,1389762000"; d="scan'208";a="8381100" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport.idirect.net with ESMTP; 03 Mar 2014 10:42:26 -0500 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 10:42:26 -0500 From: "Snyder, Brian" To: "manet@ietf.org" Thread-Topic: Any DLEP hands on Training courses (Pay or online?) Thread-Index: AQHPNvct0vIN0iIK+EqFU/naPCqLYg== Date: Mon, 3 Mar 2014 15:42:14 +0000 Message-ID: <9B87E05D-BE04-499E-BE2F-2736C7664CC1@idirect.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JzUM79GtQ5ZI1KtAMFiiBCIIyGE Subject: [manet] Any DLEP hands on Training courses (Pay or online?) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:42:31 -0000 Hi all, I am just getting started learning and understanding the MANET tech= nology (DLEP). I was wondering if there are any good hands on training clas= ses or online resources one can study? I have the RFC and IETF docs, but I = find a good walkthrough helps it sink into my brain a little better=85.. = =20 Thanks, Brian= From nobody Mon Mar 3 08:16:01 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFE51A0199 for ; Mon, 3 Mar 2014 08:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDWXtA5uTY3W for ; Mon, 3 Mar 2014 08:15:58 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5E30C1A014A for ; Mon, 3 Mar 2014 08:15:58 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so1714901iec.23 for ; Mon, 03 Mar 2014 08:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MzE3o7R/dW+o2V+HYy6Ph5OsKArJGb7hsHHqnOWjZHM=; b=jLOQMdbILif27k5TJg2gU3AqQe58p/6CssZYDH2jPQi/tqM/RmCayQ6m/R9xDneRB3 CYk3qjAB/udIjAvR1LU0FuwtL2HLe5QkrIhIAJmow1HqHhYlXFFBF5MLZ39eACF3lkkK FyCqC2tMGt7uAFiudh3bTqgXgef3zKkOCblZ0zP1SEbx8Wl2VTn9XG2cy6FOvVjrM+Ta yMs4PsJXesMItIpgWmETd1t44AQRLO96FTUE+ouus6J8SKrkldjbtVZbFgHN6PvPqM5P XsCP8MxX193lWWB997pFEU7nCA+vFUKKTes/I75DBcAVPwei2wt+UCP0r/XnneT3k0sF +OWA== X-Received: by 10.50.103.101 with SMTP id fv5mr22827732igb.2.1393863355406; Mon, 03 Mar 2014 08:15:55 -0800 (PST) Received: from [192.168.1.10] (dynamic-acs-24-112-216-41.zoominternet.net. [24.112.216.41]) by mx.google.com with ESMTPSA id mi2sm40577458igb.3.2014.03.03.08.15.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 08:15:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shawn Jury In-Reply-To: Date: Mon, 3 Mar 2014 11:15:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6C784DEC-3D82-4EFA-B14B-88906CE7336B@gmail.com> References: To: manet@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/g5XrHI3wQqA6W8GBisOCuzMOsPE Cc: Shawn Jury Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 16:16:00 -0000 AB,=20 I'm not sure your following where TCP is being used in DLEP. The = draft defines TCP between the routing device and the radio. This is = normally a fairly stable connection (ethernet in the radios I have seen, = but could be serial or anything really). Because of this, the normal = issues with Manet networks do not apply. This is just to support = Henning's reply of DLEP is not "over the air". If you still have concerns, it might be a better idea that you tell = us what your concerns are as opposed to us convincing you of why it was = changed. I think that might allow us to address your concerns quicker = as opposed to you waiting for us to tell you something and you cherry = picking what you want out of it. Hope this helps, Shawn On Mar 3, 2014, at 10:37 AM, manet-request@ietf.org wrote: >=20 > What you write make no sense at all. I am not even sure it has much to = do > with my answer. >=20 > DLEP is not an "over the air" protocol... I also recommend to look up = "stop > and wait" protocol. >=20 > Henning > On Mar 3, 2014 4:31 PM, "Abdussalam Baryun" = > wrote: >=20 >> Hi Henning, >>=20 >> Do you mean if the DLEP ACK messages are dropped then DLEP = performance >> will be below 70 percent and 30 percent losses? MANET protocols = always have >> percentages of errors. >>=20 >> So do I understand that if there is ACK messages in any MANET = protocol >> (which uses transport layer) then there are only three options as = below. I >> think AODV is already has option of ACK message but still it works = perfect >> with UDP, >>=20 >> AB >=20 From nobody Mon Mar 3 10:01:15 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687F21A02F3 for ; Mon, 3 Mar 2014 10:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRwT0BENHM5L for ; Mon, 3 Mar 2014 10:01:11 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 783501A023E for ; Mon, 3 Mar 2014 10:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2438; q=dns/txt; s=iport; t=1393869669; x=1395079269; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TubrVuMd1xA6jKDWanzWuF3wkKFo4l9PGU5y9kzfEM0=; b=fRK4+UEB//3+Q+EJnv/4MsK1Sgly0VqoFpJllOFD7ygAWUOmyX1OGqcg nC+Pt+8sbQy78pPQEoskRN3bxMpILrYXsVaTOLrAKT2kBK2pW3MjXSAzk yISCQtGdfaG2BUWlhFApBRNz39miwLpapvTlzptOax+/Wzs3ZXKP62oVs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAOvCFFOtJV2a/2dsb2JhbABagwY7V8BTgSQWdIIlAQEBAwEBAQE3NAsFCwIBCBgeECEGCyUCBA4Fh2UDCQgNxUwNhlwTBIxDgWMzB4MkgRQElk+BbYxjhUiDLYIq X-IronPort-AV: E=Sophos;i="4.97,579,1389744000"; d="scan'208";a="24551284" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 03 Mar 2014 18:00:46 +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 s23I0kO0028969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 18:00:46 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 12:00:45 -0600 From: "Stan Ratliff (sratliff)" To: Shawn Jury Thread-Topic: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary Thread-Index: AQHPNvviXOG9tsGmIEy09evK5lBMqprQC5sA Date: Mon, 3 Mar 2014 18:00:45 +0000 Message-ID: <71401F55-0E30-4DA5-B36B-733495A0A80E@cisco.com> References: <6C784DEC-3D82-4EFA-B14B-88906CE7336B@gmail.com> In-Reply-To: <6C784DEC-3D82-4EFA-B14B-88906CE7336B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.247.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <3EA893A585A12149B80119D0CD858F9A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Vo24S8RZ-c6inI1TVZW_4TgX7KM Cc: "" Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:01:13 -0000 On Mar 3, 2014, at 11:15 AM, Shawn Jury wrote: > AB,=20 >=20 > I'm not sure your following where TCP is being used in DLEP. The draf= t defines TCP between the routing device and the radio. This is normally a= fairly stable connection (ethernet in the radios I have seen, but could be= serial or anything really). Because of this, the normal issues with Manet= networks do not apply. This is just to support Henning's reply of DLEP is= not "over the air". >=20 > If you still have concerns, it might be a better idea that you tell us= what your concerns are as opposed to us convincing you of why it was chang= ed. I think that might allow us to address your concerns quicker as oppose= d to you waiting for us to tell you something and you cherry picking what y= ou want out of it. >=20 > Hope this helps, >=20 > Shawn > On Mar 3, 2014, at 10:37 AM, manet-request@ietf.org wrote: >=20 >>=20 >> What you write make no sense at all. I am not even sure it has much to d= o >> with my answer. >>=20 >> DLEP is not an "over the air" protocol... I also recommend to look up "s= top >> and wait" protocol. >>=20 >> Henning >> On Mar 3, 2014 4:31 PM, "Abdussalam Baryun" >> wrote: >>=20 >>> Hi Henning, >>>=20 >>> Do you mean if the DLEP ACK messages are dropped then DLEP performance >>> will be below 70 percent and 30 percent losses? MANET protocols always = have >>> percentages of errors. I want to emphasize what Henning and Shawn have already said - DLEP is spec= ified *between a router and its locally-attached radio*. There is NO "over = the air" signaling specified in DLEP. Discovery of remote MAC (and Layer 3)= IP addresses *implies* some sort of proprietary OTR signaling, but those s= pecifications are not in DLEP. As such, the DLEP protocol will typically be= running over a local Ethernet connection, and should be stable (with low e= rror rates).=20 Regards, Stan >>>=20 >>> So do I understand that if there is ACK messages in any MANET protocol >>> (which uses transport layer) then there are only three options as below= . I >>> think AODV is already has option of ACK message but still it works perf= ect >>> with UDP, >>>=20 >>> AB >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon Mar 3 12:06:46 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEAC1A0353 for ; Mon, 3 Mar 2014 12:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9FlZpisabpf for ; Mon, 3 Mar 2014 12:06:42 -0800 (PST) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA3A1A031E for ; Mon, 3 Mar 2014 12:06:41 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id x48so3725679wes.21 for ; Mon, 03 Mar 2014 12:06:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=qx1iyRHiBNdVCBsUeZ4y/0z35//9Inpi0KHBf+gOHzY=; b=U9BUAgDJiIgj0hJ0cLMWQf+H86xGuXc8YxP4IkWUq0FvNcRGRqmJ9sOtGLWHLytRyv /zy0f6TKsXbgwRHbifCVNSNdSD15nNNmAgApaqkur8ibzxzseoABIO8hEzxY2noNBCW+ JW8dEcqe4p0qqYE71YpHEGvxh7a91/NJkRVvEUQ3G5ZiBQaECwQ6h9ayOw5MuswARaLS AKOvPLLUVVZ3L4Tha2H2qxYXM9/AdpfQSnfMZlUEJDqsGRPUQdb8mtOMIbUBLn0n8eN+ qgK02qBz+agqd4gmMZwCMJMKug/XtV4XxJD5nlF1gd1Q3S8oYm+oEmmFKgoB0XhTbEDp GmFg== X-Gm-Message-State: ALoCoQlDHjMM2UhlqS79rBV0jkQutgWPPk3tq/eCYJRbVAAJ+SrjsRO+nlaFpLUfdFTF6pPNasOA X-Received: by 10.194.60.16 with SMTP id d16mr20919025wjr.46.1393877198345; Mon, 03 Mar 2014 12:06:38 -0800 (PST) Received: from dhcp-a727.meeting.ietf.org (dhcp-a727.meeting.ietf.org. [31.133.167.39]) by mx.google.com with ESMTPSA id ux5sm40288479wjc.6.2014.03.03.12.06.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 12:06:37 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Teco Boot In-Reply-To: <71401F55-0E30-4DA5-B36B-733495A0A80E@cisco.com> Date: Mon, 3 Mar 2014 21:06:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9D14D222-6874-4291-8B90-F5F46AA2E021@inf-net.nl> References: <6C784DEC-3D82-4EFA-B14B-88906CE7336B@gmail.com> <71401F55-0E30-4DA5-B36B-733495A0A80E@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/b7XekoxMU6eETwDuw6k4cwRHwUY Cc: "" Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 20:06:44 -0000 Op 3 mrt. 2014, om 19:00 heeft Stan Ratliff (sratliff) = het volgende geschreven: //skipped// > Discovery of remote MAC (and Layer 3) IP addresses *implies* some = sort of proprietary OTR signaling, but those specifications are not in = DLEP. I don=92t think any proprietary OTR signaling is needed. The modem just = provide transparent 802.1D bridging. How to implement such bridge = service is up to implementer. The Layer 3 IP address service is optional and is not standards based. = It may speed up ARP/NDP address resolving, although there are other ways = to do that without over the air messages (e.g. L2 header snooping from = routing protocol messages). Teco= From nobody Mon Mar 3 15:09:18 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518491A0268 for ; Mon, 3 Mar 2014 15:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVFUWXUGq1uI for ; Mon, 3 Mar 2014 15:09:11 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.106]) by ietfa.amsl.com (Postfix) with ESMTP id B1E191A0249 for ; Mon, 3 Mar 2014 15:09:10 -0800 (PST) Received: from [193.109.255.147:4631] by server-2.bemta-14.messagelabs.com id 21/6A-01236-39B05135; Mon, 03 Mar 2014 23:09:07 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-72.messagelabs.com!1393888132!12335898!5 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28028 invoked from network); 3 Mar 2014 23:09:06 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-14.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 3 Mar 2014 23:09:06 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Mon, 3 Mar 2014 23:09:00 +0000 From: To: , Date: Mon, 3 Mar 2014 23:06:18 +0000 Thread-Topic: [manet] DLEP DT summary Thread-Index: Ac7epLQRuQcQJFH9okar7MIy/pXlQgABJ/8uAD/G+lAVy4DfWgAPY6WAAAhLdc8= Message-ID: <290E20B455C66743BE178C5C84F1240847E6334745@EXMB01CMS.surrey.ac.uk> References: <603F5FD847B5174CBDA37A9DC00532FB0B4E6FD2@SUCNPTEXM02.com.ad.uk.ds.corp> , In-Reply-To: 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/cEkLJPODpE1TdEVqBYL-YoCvP4Q Cc: chris.dearlove@baesystems.com, manet@ietf.org, John.Dowdell@cassidian.com Subject: Re: [manet] DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 23:09:15 -0000 > When we (the co-authors) first floated this draft, we were under the (obv= iously naive) impression > that DLEP would be a "project". I'm not sure how, or why, it has morphed = into a "career path". > *Sigh*=85 That said, i'd really like to get this draft to WGLC before my = grandchildren have grandchildren... I honestly can't see that happening. Lloyd Wood http://sat-net.com/L.Wood/router-modem-integration/ ________________________________________ From: manet [manet-bounces@ietf.org] On Behalf Of Stan Ratliff (sratliff) [= sratliff@cisco.com] Sent: 03 March 2014 13:08 To: Abdussalam Baryun Cc: Dearlove, Christopher (UK); manet@ietf.org; Dowdell, John Subject: Re: [manet] DLEP DT summary On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun = wrote: > Hi Chris, > > I did not want to join the DT, and still not getting their report, but > I want to discuss within WG list. I beleive editors should follow the > WG participants text amending, and follow consensus. I look forward to > comment on the DLEP on the list and in this meeting. Comments below, > > Regards > AB > > On 11/12/13, Dearlove, Christopher (UK) w= rote: >> Wrong I'm afraid, both procedurally and practically. WGs can't write >> documents, that just isn't a viable approach. Documents are written by >> authors, or sometimes editors. The WG can reject a document. But that's = not >> the same as writing one. >> > > I meant to say that DLEP draft is changing from using UDP to use TCP > without enough discussion on the WG list or final consensus. If > editors make the change in the draft which they already did, that will > affect the fairness of the final consensus and also the WG > discussions. I changed DLEP 05 to use TCP because the people on the design team wanted T= CP. I appreciate that you have expressed dissent. But so far, your dissent = is only one I've seen. If there are other working group participants that b= elieve moving to TCP is a bad thing, I hope they will express that view her= e on the list. Otherwise, it looks like you are "in the rough" on this one. Heck, I'd even change the transport to IPX if it would help get DLEP to rat= ification. When we (the co-authors) first floated this draft, we were under= the (obviously naive) impression that DLEP would be a "project". I'm not s= ure how, or why, it has morphed into a "career path". *Sigh*=85 That said, = i'd really like to get this draft to WGLC before my grandchildren have gran= dchildren... Regards, Stan > > I feel now after the editors have made their decisions with the DT, > now I am forced to not discuss, or I am forced to be in a discouraged > position. It seems now it is better for me to leave the flow go into > DT decisions, and hopefully not all drafts take the same direction in > future, > >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f >> Abdussalam Baryun >> Sent: 12 November 2013 16:30 >> To: Dowdell, John >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP DT summary >> >> Hi John >> >> I have been very interested and was regular posting and reviewing the wo= rk >> but should not be excluded (there are others ). However, I thank you and= the >> members of DT for your contributions, and always want to speed the proce= ss >> for DLEP but with best practices and awareness. In the last two meeting >> there were comments from the community that the DT should follow. The WG= did >> not decide to give its job to the DT. >> >> I don't agree that the DT makes changes to the DLEP draft, the DT should >> report its recommendations to this list, so the WG decides and discusses >> what to do. >> >> AB >> > >> On Tuesday, November 12, 2013, Dowdell, John wrote: >> For the avoidance of doubt, please understand that I asked for an inform= al >> meeting at Berlin IETF that half way through became the Design Team. The >> meeting attendees were drawn from those who had regularly posted on DLEP >> since the 00 draft, and therefore were deemed to be most interested in >> getting to an RFC, as I was. Kindly lay off the lead author of DLEP. > > I am also, but big changes like using TCP need consensus, now with > draft changed I feel I have no interest in giving even a humm voice. > >> >> In the meantime, if anyone else is actively developing with DLEP (router= or >> modem side) and is willing to directly contribute to the speedy and >> successful development of the draft, please post on the manet list and w= e >> will be in touch. One person joined the team since the first meeting in >> Berlin. > > I did not join the team, because I think it is with enough capacity, > and if me and other join it will become another MANET WG list. > >> >> For timescales and upcoming work, please listen to the DLEP presentation= in >> the early part of the manet WG meeting at Vancouver. >> > > I agree that all to listen to each other, so community listen and then > the community to be listened to as well, > > _______________________________________________ > 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 nobody Tue Mar 4 00:39:01 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357271A0413; Tue, 4 Mar 2014 00:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEwxMauN8Xif; Tue, 4 Mar 2014 00:38:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5821A0423; Tue, 4 Mar 2014 00:38:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140304083849.27194.15099.idtracker@ietfa.amsl.com> Date: Tue, 04 Mar 2014 00:38:49 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Qy_fdBocj6VsoDB9JmBbNdWkE-g Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-tlv-extension-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 08:38:59 -0000 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 : Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-olsrv2-tlv-extension-04.txt Pages : 17 Date : 2014-03-04 Abstract: This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP), to increase their abilities to accommodate protocol extensions. This document updates OLSRv2 and RFC6130. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-tlv-extension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-olsrv2-tlv-extension-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-olsrv2-tlv-extension-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 4 02:36:17 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45DD1A049D for ; Tue, 4 Mar 2014 02:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rf284HgZ7BD1 for ; Tue, 4 Mar 2014 02:36:08 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB3A1A03AC for ; Tue, 4 Mar 2014 02:36:08 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s24Aa43Q021021 for ; Tue, 4 Mar 2014 10:36:04 GMT Received: from 950129200 (dhcp-b5b1.meeting.ietf.org [31.133.181.177]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s24AZvQZ020837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Mar 2014 10:36:02 GMT From: "Adrian Farrel" To: Date: Tue, 4 Mar 2014 10:35:57 -0000 Message-ID: <011901cf3795$8b2905d0$a17b1170$@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: Ac83lRjdvO+0SrMvS1qX1Im8xkX7Ww== Content-language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/manet/4mwIGILhyeCWBOYEITNyKHYkqQE Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-tlv-extension-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 04 Mar 2014 10:36:14 -0000 Hi, The authors and I have been working with IANA to make their actions clear to them in this document. This results in a major rewrite of section 5 with absolutely no change of content. Thanks to the authors for their patience. Adrian > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 04 March 2014 08:39 > To: i-d-announce@ietf.org > Cc: manet@ietf.org > Subject: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-tlv-extension-04.txt > > > 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 : Optimized Link State Routing Protocol version 2 (OLSRv2) and > MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs > Authors : Christopher Dearlove > Thomas Heide Clausen > Filename : draft-ietf-manet-nhdp-olsrv2-tlv-extension-04.txt > Pages : 17 > Date : 2014-03-04 > > Abstract: > This specification describes extensions to definitions of TLVs used > by the Optimized Link State Routing Protocol version 2 (OLSRv2) and > the MANET Neighborhood Discovery Protocol (NHDP), to increase their > abilities to accommodate protocol extensions. This document updates > OLSRv2 and RFC6130. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-tlv-extension/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-nhdp-olsrv2-tlv-extension-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-olsrv2-tlv-extension-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 From nobody Tue Mar 4 02:47:50 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3DF1A02CE; Tue, 4 Mar 2014 02:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeBndMgzrHng; Tue, 4 Mar 2014 02:47:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C45701A06B4; Tue, 4 Mar 2014 02:47:37 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140304104737.16616.25207.idtracker@ietfa.amsl.com> Date: Tue, 04 Mar 2014 02:47:37 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/81ME-HbJvhPm8OMHb7BnLQZx_EQ Cc: manet chair , manet mailing list , RFC Editor Subject: [manet] Protocol Action: 'Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs' to Proposed Standard (draft-ietf-manet-nhdp-olsrv2-tlv-extension-04.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 10:47:48 -0000 The IESG has approved the following document: - 'Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs' (draft-ietf-manet-nhdp-olsrv2-tlv-extension-04.txt) as Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-tlv-extension/ Technical Summary This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP), to increase their abilities to accommodate protocol extensions. This document updates OLSRv2 and RFC6130. Working Group Summary There was consensus to publish the document. Document Quality There is a number of independent implementations this extension to OLSRv2. Those listed below have, explicitly, consented to be mentioned: o Ecole Polytechnique, France (Contact: Thomas Clausen) o BAE Systems Advanced Technology Centre, UK (Contact Christopher Dearlove) Personnel The Document Shepherd is Ulrich Herberg (ulrich@herberg.name) The responsible Area Director is Adrian Farrel. RFC Editor Note Please note that this document formally Updates draft-ietf-manet-olsrv2 which is in the RFC editor Queue at the time of processing this document. From nobody Tue Mar 4 02:49:25 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C911A06BF for ; Tue, 4 Mar 2014 02:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUOuqTJmXZox for ; Tue, 4 Mar 2014 02:49:22 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4671F1A066D for ; Tue, 4 Mar 2014 02:49:22 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id x13so3548184wgg.26 for ; Tue, 04 Mar 2014 02:49:18 -0800 (PST) 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:from:subject:date:to; bh=YMTOqfkndxcse/zSdKlBYd4AlXB1Bw/wtm48Fh91YAg=; b=yvLn5qv6U51IhtE5xPlN3COf7dChNsNRZe87vRN1Ztb7g/lWVZrCCIS/b+TRDqkQ/M lqtr5htnbXPZBezDYdjtXM/bYGRPOGJAsg9CrEzHAoEavZAnLLPgNuVdnE3cPHGyMarK fxq/+XDIsnzQ7DtUBwPnqBVFxBwqi4FtLfd1n4IHXzeoOtwEvURfYkWOYNTltmr9saG7 qmjDa2Rfsui4e6bVK7aMeLU1UtI+bVL4D+eX0nUeyHa0UK5kssLxhRf6wj0cmLNCokbe UO/QNf0mZ+vXLo2z4lvbL0wzUdr02QPGqDi0j2ot+o8M7WU/Gl9ojivOGx2/Pfkcqo1K brdA== X-Received: by 10.194.94.162 with SMTP id dd2mr14779576wjb.66.1393930158684; Tue, 04 Mar 2014 02:49:18 -0800 (PST) Received: from ?IPv6:2001:67c:370:176:ad95:fca5:ff53:9fa7? ([2001:67c:370:176:ad95:fca5:ff53:9fa7]) by mx.google.com with ESMTPSA id uq2sm50117052wjc.5.2014.03.04.02.49.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 02:49:18 -0800 (PST) References: <011901cf3795$8b2905d0$a17b1170$@olddog.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <011901cf3795$8b2905d0$a17b1170$@olddog.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B651) From: Christopher Dearlove Date: Tue, 4 Mar 2014 10:49:16 +0000 To: "adrian@olddog.co.uk" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kah63mYzGEMWVJ3fNQle9O5Jq-k Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-tlv-extension-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 10:49:24 -0000 We've also spoken to the IANA representatives here, who have indicated they a= re happy with this. --=20 Christopher Dearlove christopher.dearlove@gmail.com > On 4 Mar 2014, at 10:35, "Adrian Farrel" wrote: >=20 > Hi, >=20 > The authors and I have been working with IANA to make their actions clear t= o > them in this document. > This results in a major rewrite of section 5 with absolutely no change of > content. >=20 > Thanks to the authors for their patience. >=20 > Adrian >=20 >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: 04 March 2014 08:39 >> To: i-d-announce@ietf.org >> Cc: manet@ietf.org >> Subject: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-tlv-extension-0= 4.txt >>=20 >>=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 t= he >> IETF. >>=20 >> Title : Optimized Link State Routing Protocol version 2 > (OLSRv2) and >> MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs >> Authors : Christopher Dearlove >> Thomas Heide Clausen >> Filename : draft-ietf-manet-nhdp-olsrv2-tlv-extension-04.txt >> Pages : 17 >> Date : 2014-03-04 >>=20 >> Abstract: >> This specification describes extensions to definitions of TLVs used >> by the Optimized Link State Routing Protocol version 2 (OLSRv2) and >> the MANET Neighborhood Discovery Protocol (NHDP), to increase their >> abilities to accommodate protocol extensions. This document updates >> OLSRv2 and RFC6130. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-tlv-extensi= on/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-nhdp-olsrv2-tlv-extension-04 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-olsrv2-tlv-exten= sion-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submiss= ion >> until the htmlized version and diff are available at tools.ietf.org. >>=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 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Mar 4 03:06:01 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EF71A06BF for ; Tue, 4 Mar 2014 03:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egBlkI6Md0bL for ; Tue, 4 Mar 2014 03:05:56 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id ECB191A06E5 for ; Tue, 4 Mar 2014 03:05:55 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 10so13890180ykt.4 for ; Tue, 04 Mar 2014 03:05:52 -0800 (PST) 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=qrCCM+46wM9mWgCue9bQH7inH+x6bM0yP5vDTVsJdHs=; b=i7pyB4xQuwlrMUBi8TF0mP7lYPCzUhGZU7t0zS1p/WRzwr86W5j1Qg9wHkmjYdz1Cv GyBIr7Yxy46VSOxBEYrur5ptzJazB8kBFxJ9Lu3JOxWbBhtj9I6g8ivBe4kLZ9jlsdcM 4oex10T06re+ZzGvKBy8AHycClcZmaXbEheTxM/JLakyU1o0rnBOtkDQld/LJvPE0KxD p+KOUb+8kO0PRhaeaPNXOff/FXUm5DxCpsUVJ4E+ZS3G1Uy29gJIy8cVKlJHmIgCOiyO huuJEpUHqgcYTbhX5wJRCnUOGQtM+/MSqEkUGBxQlvtDscJwe4mfrGbKgjVfD8zPTIOw u5Jw== MIME-Version: 1.0 X-Received: by 10.236.121.194 with SMTP id r42mr7798280yhh.82.1393931152704; Tue, 04 Mar 2014 03:05:52 -0800 (PST) Received: by 10.170.202.7 with HTTP; Tue, 4 Mar 2014 03:05:52 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Mar 2014 12:05:52 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RHFzuldADZ7kEbInfk3pNluFWl4 Cc: "Dearlove, Christopher \(UK\)" , MANET IETF , "Dowdell, John" , "Stan Ratliff \(sratliff\)" Subject: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:06:00 -0000 Hi Henning, I am not sure if there were consensus on to have stateful communication of DLEP (did I miss that, not sure, please advise). I think DLEP is abstract approach agreed on as -04. I think DLEP is flexible bidirectional communication ( I will read draft-5/draft-4 again to make sure). However, I agree with DLEP-04 but still thinking why must DLEP-05 and why not draft-04. My comments below, On Monday, March 3, 2014, Kenning Rogge wrote: > > What you write make no sense at all. I am not even sure it has much to do with my answer. It is related that you gave alternatives to DLEP communication with router because of DLEP's ACK messages. TCP also has ACKs, and flow control, so overloading channel. In any protocol ACKs are used for loss or error possibilities. > > DLEP is not an "over the air" protocol... I also recommend to look up "stop and wait" protocol. Yes, it is mentioned that in discussions, but still losses or errors may occur in MANET scenarios of D2D (devices comm) or do you mean there will be no drops/losses. I interested in ack/retransmit technique or sequence numbers technique (ready no need to invint any thing) as in AODV communication. So your alternative (2) is my choice to make better DLEP performance as in DLEP-04. Why is TCP better than UDP while we use ACKs, is it because possible high loss percentage in channel? However, I agree that my discuss may not be clear (sorry for this, but I am motivated and happy to discuss) and I will have to organise my comment better after finish my overall review of the DLEP change including its performance. See you tomorrow, Best regards, AB > > Henning > > On Mar 3, 2014 4:31 PM, "Abdussalam Baryun" wrote: >> >> Hi Henning, >> >> Do you mean if the DLEP ACK messages are dropped then DLEP performance will be below 70 percent and 30 percent losses? MANET protocols always have percentages of errors. >> >> So do I understand that if there is ACK messages in any MANET protocol (which uses transport layer) then there are only three options as below. I think AODV is already has option of ACK message but still it works perfect with UDP, >> >> AB >> >> On Monday, March 3, 2014, Henning Rogge wrote: >>> >>> The reason for TCP instead of UDP is very simple. >>> >>> The WG decided quite some time ago that we follow a "stateful DLEP" approach. >>> >>> DLEP contains ACK messages, which means that you have three options: >>> >>> 1) You can implement DLEP as "stop and wait", which means a sender can >>> only a single packet that has to be acknowledged and then waits for >>> the ACK before sending another one. >>> >>> 2) You can implement a whole bunch of "sequence number", "sliding >>> window" and "ack/retransmission" mechanisms. In fact this is a step >>> towards reinventing the wheel depending how clever you want to do >>> this. Yes IMHO, this option gives more flexibility, more independent and more performance. >>> >>> 3) You can switch to a reliable transport protocol. >>> >>> We decided to use option 3) for DLEP-05 because its the easiest to >>> implement and does not kill performance like a "stop and wait" >>> strategy. >>> >>> Henning Rogge >>> >>> On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun >>> wrote: >>> > Hi Stan, >>> > >>> > Thanks for you email, i want this draft to go ahead to WGLC with 04 draft, >>> > the 05 had not change only few word, but big changing of performance. >>> > >>> > I don't totally disagree with the authors because I see they are doing big >>> > effort to make the draft go forward which I agree and understand. However, I >>> > will prepare my comments with good reason why not TCP and there were inputs >>> > from WG before questioning and don't think the discussion ended. >>> > >>> > I think the reasons for going to TCP was not enough but the authors chosen >>> > before UDP and WG adopted that. I will prepare why not TCP, but I think DT >>> > should answer in its report first why not UDP then why TCP is with better >>> > performance. The only reason I notice from DT was design issues. >>> > >>> > @DT >>> > Please report : why not UDP in performance of DLEP as comparing TCP and UDP >>> > when using DLEP performance. I understand design purposes but would think of >>> > DLEP overall performance as well. >>> > >>> > AB >>> > >>> From nobody Tue Mar 4 03:54:50 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C161A074D for ; Tue, 4 Mar 2014 03:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf56exKc1EOo for ; Tue, 4 Mar 2014 03:54:43 -0800 (PST) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 544781A074B for ; Tue, 4 Mar 2014 03:54:43 -0800 (PST) Received: by mail-yh0-f51.google.com with SMTP id f10so4379992yha.10 for ; Tue, 04 Mar 2014 03:54:40 -0800 (PST) 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=OB26XsPIKgUDvCqLeNs0eWact03DW5okdghUaS2DE3Y=; b=upu1/i3FuCO/qIlNM+42Mx5iHvB6TuzFJzxwLSnrV+mtwp8dWm2mXLEtxs3FYdKf7n tpYaqBukbHJCW6hjpZLmQWF18vdpQ7nJbOd5dsjQHees++npkrcw/IU15kAYx9qklJyV C/2i/EHWl+FjylW3V/h9orLkoPg75Z8yDUvKpsschjugXWkWT5PYBRe8avM9wdmF4A8J sZ7IU/MiSburpndB7IRe1BQYj0tmpWifWc9cmcc0Bf8QbWlKN7fDuaLNvwwx6yaFi9vB JmeLP0rVT2FTZfWxO+wj3Xuzgs9VeiQtMGLhTaO0uzHHUMWT9tYnNqQwQDluQe8m5CLr d5qw== MIME-Version: 1.0 X-Received: by 10.236.101.18 with SMTP id a18mr13646604yhg.65.1393934080076; Tue, 04 Mar 2014 03:54:40 -0800 (PST) Received: by 10.170.202.7 with HTTP; Tue, 4 Mar 2014 03:54:40 -0800 (PST) In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> Date: Tue, 4 Mar 2014 12:54:40 +0100 Message-ID: From: Abdussalam Baryun To: "Dowdell, John" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/oghY0D-l9vunaiQn2zT5rtw790U Cc: "Dearlove, Christopher \(UK\)" , MANET IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:54:47 -0000 Hi John, So you mean low possibility of loss, so why not UDP? that is not answered, the only answer was because DLEP is stateful and it has ACK messages. So why not DLEP-04 while I am using realiable PHY as you describe. In addition, even if there are reliability in PHY there may be losses in other layers under MANET applicabilities, so that is why DLEP-04 has ACKs, which I agree, but don't understand the TCP importance in such communication scenarios. AB On 3/4/14, Dowdell, John wrote: > Abdussalam > > May I re-iterate the points already made. > > DLEP is NOT an over the air protocol. DLEP works along the physical medium > (copper, fibre, whatever) between the radio and its local router. Thus the > Design Team consider there is a very low probability of loss of messages > over this medium. How the radios exchange the relevant information with each > other, and overcome the losses expected on any air interface, is for the > radio manufacturer to decide and is generally referred to in the design team > as "radio magic". The Design Team discussed this topic long and hard and the > draft represents the consensus of the Design Team. Whether the manet working > group will reach consensus on this matter is for the working group to > decide, but it seems by far the most sensible direction to the Design Team. > > John > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 04 March 2014 11:06 > To: Henning Rogge > Cc: MANET IETF; Dearlove, Christopher (UK); Stan Ratliff (sratliff); > Dowdell, John > Subject: DLEP performance with and without TCP (was Re: DLEP DT summary > > Hi Henning, > > I am not sure if there were consensus on to have stateful > communication of DLEP (did I miss that, not sure, please advise). I > think DLEP is abstract approach agreed on as -04. I think DLEP is > flexible bidirectional communication ( I will read draft-5/draft-4 > again to make sure). However, I agree with DLEP-04 but still thinking > why must DLEP-05 and why not draft-04. My comments below, > > On Monday, March 3, 2014, Kenning Rogge wrote: >> >> What you write make no sense at all. I am not even sure it has much to do >> with my answer. > > It is related that you gave alternatives to DLEP communication with > router because of DLEP's ACK messages. TCP also has ACKs, and flow > control, so overloading channel. In any protocol ACKs are used for > loss or error possibilities. > >> >> DLEP is not an "over the air" protocol... I also recommend to look up >> "stop and wait" protocol. > > Yes, it is mentioned that in discussions, but still losses or errors > may occur in MANET scenarios of D2D (devices comm) or do you mean > there will be no drops/losses. I interested in ack/retransmit > technique or sequence numbers technique (ready no need to invint any > thing) as in AODV communication. So your alternative (2) is my choice > to make better DLEP performance as in DLEP-04. Why is TCP better than > UDP while we use ACKs, is it because possible high loss percentage in > channel? > > However, I agree that my discuss may not be clear (sorry for this, but > I am motivated and happy to discuss) and I will have to organise my > comment better after finish my overall review of the DLEP change > including its performance. See you tomorrow, > > Best regards, > > AB >> >> Henning >> >> On Mar 3, 2014 4:31 PM, "Abdussalam Baryun" >> wrote: >>> >>> Hi Henning, >>> >>> Do you mean if the DLEP ACK messages are dropped then DLEP performance >>> will be below 70 percent and 30 percent losses? MANET protocols always >>> have percentages of errors. >>> >>> So do I understand that if there is ACK messages in any MANET protocol >>> (which uses transport layer) then there are only three options as below. >>> I think AODV is already has option of ACK message but still it works >>> perfect with UDP, >>> >>> AB >>> >>> On Monday, March 3, 2014, Henning Rogge wrote: >>>> >>>> The reason for TCP instead of UDP is very simple. >>>> >>>> The WG decided quite some time ago that we follow a "stateful DLEP" >>>> approach. >>>> >>>> DLEP contains ACK messages, which means that you have three options: >>>> >>>> 1) You can implement DLEP as "stop and wait", which means a sender can >>>> only a single packet that has to be acknowledged and then waits for >>>> the ACK before sending another one. >>>> >>>> 2) You can implement a whole bunch of "sequence number", "sliding >>>> window" and "ack/retransmission" mechanisms. In fact this is a step >>>> towards reinventing the wheel depending how clever you want to do >>>> this. > > Yes IMHO, this option gives more flexibility, more independent and > more performance. > >>>> >>>> 3) You can switch to a reliable transport protocol. >>>> >>>> We decided to use option 3) for DLEP-05 because its the easiest to >>>> implement and does not kill performance like a "stop and wait" >>>> strategy. >>>> >>>> Henning Rogge >>>> >>>> On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun >>>> wrote: >>>> > Hi Stan, >>>> > >>>> > Thanks for you email, i want this draft to go ahead to WGLC with 04 >>>> > draft, >>>> > the 05 had not change only few word, but big changing of performance. >>>> > >>>> > I don't totally disagree with the authors because I see they are >>>> > doing big >>>> > effort to make the draft go forward which I agree and understand. >>>> > However, I >>>> > will prepare my comments with good reason why not TCP and there were >>>> > inputs >>>> > from WG before questioning and don't think the discussion ended. >>>> > >>>> > I think the reasons for going to TCP was not enough but the authors >>>> > chosen >>>> > before UDP and WG adopted that. I will prepare why not TCP, but I >>>> > think DT >>>> > should answer in its report first why not UDP then why TCP is with >>>> > better >>>> > performance. The only reason I notice from DT was design issues. >>>> > >>>> > @DT >>>> > Please report : why not UDP in performance of DLEP as comparing TCP >>>> > and UDP >>>> > when using DLEP performance. I understand design purposes but would >>>> > think of >>>> > DLEP overall performance as well. >>>> > >>>> > AB >>>> > >>>> > 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, part of the Airbus Defence and Space > division. Registered Office: Quadrant House, Celtic Springs, Coedkernew, > Newport , NP10 8FZ. Registered in England and Wales under company number > 04191036 > From nobody Tue Mar 4 05:21:44 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514331A00B2 for ; Tue, 4 Mar 2014 05:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHdjg-fbenzZ for ; Tue, 4 Mar 2014 05:21:34 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BD5721A00A3 for ; Tue, 4 Mar 2014 05:21:34 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id uq10so4768393igb.1 for ; Tue, 04 Mar 2014 05:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zbh7+QdHvmiiaJl7zNb/3D8kuttpWZohfyhiBknU7lE=; b=qSCpOPOSrrA2yM/OdZE+gmnuC6n6fOWUKnoNOyTWq7218Z9qlCn+sgLoWNs4iEL0BO abhgzSAjjC+SsIPY+Yq6npUp3kvUxRFQ7Ron2SCRe+yXWAsZP8xLALtoZrq0tFhI5zgD NwMvoqkvX2L9f0a93IAPj8Jw7wONeW0yZ3hQWHzsvfmzWIiPGP/ZxA4eGc4QFE9G/OGe SkdyB0LW2wXXXNuypzBCR/72kbMPbvHAOwgddKgRkuT5CmYyB6ObGl5HoLnYVd6Wzy1b UOd1uPaiwh8Cu4RVUZrcdDBS4RwBMnmis7gi9HE7dgGR4WBRvXiwZaZFegwNDuze6oSn GDEg== X-Received: by 10.50.43.165 with SMTP id x5mr29192077igl.40.1393939291551; Tue, 04 Mar 2014 05:21:31 -0800 (PST) Received: from [192.168.1.10] (dynamic-acs-24-112-216-41.zoominternet.net. [24.112.216.41]) by mx.google.com with ESMTPSA id r6sm49927408igg.10.2014.03.04.05.21.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 05:21:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shawn Jury In-Reply-To: Date: Tue, 4 Mar 2014 08:21:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/OQ46tVKvQtNt1c-jSXtWKwIJ4kI Cc: MANET IETF Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 13:21:39 -0000 Hello AB, Here we are again with you stating you dislike something, but not = telling us why you dislike it. You are just asking us to explain the = change to you. =20 I'll tell you that I wasn't part of the DT for DLEP, but I can see = the benefit of using TCP. Just some of the benefits: * No need to recreate a complex state machine in DLEP that would mimic = TCP's behavior. =20 * TCP is an already existing reliable transport protocol (readily = available).=20 * Simplifies the overall implementation of the protocol. * Addresses earlier concerns about how DLEP was a "stop and wait" = protocol. With that said, please explain why you do not like TCP for DLEP. You = seem to agree that a reliable transport is needed (ACKs and SeqNums in = -04), but just state that you don't like TCP and are in favor of = creating a protocol that "gives more flexibility, more independent and = more performance". TCP meets the needs that are required for our = purpose. Unless you can produce a valid argument of why you don't like it, = I'm at a point where I'll just attribute your objections to white noise = as there doesn't seem to be any substance behind them, nor much support = from others on the list. If you have a technical argument of why we shouldn't use TCP, please = send it to the list.=20 Shawn On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: > Hi John, >=20 > So you mean low possibility of loss, so why not UDP? that is not > answered, the only answer was because DLEP is stateful and it has ACK > messages. So why not DLEP-04 while I am using realiable PHY as you > describe. In addition, even if there are reliability in PHY there may > be losses in other layers under MANET applicabilities, so that is why > DLEP-04 has ACKs, which I agree, but don't understand the TCP > importance in such communication scenarios. >=20 > AB >=20 > On 3/4/14, Dowdell, John wrote: >> Abdussalam >>=20 >> May I re-iterate the points already made. >>=20 >> DLEP is NOT an over the air protocol. DLEP works along the physical = medium >> (copper, fibre, whatever) between the radio and its local router. = Thus the >> Design Team consider there is a very low probability of loss of = messages >> over this medium. How the radios exchange the relevant information = with each >> other, and overcome the losses expected on any air interface, is for = the >> radio manufacturer to decide and is generally referred to in the = design team >> as "radio magic". The Design Team discussed this topic long and hard = and the >> draft represents the consensus of the Design Team. Whether the manet = working >> group will reach consensus on this matter is for the working group to >> decide, but it seems by far the most sensible direction to the Design = Team. >>=20 >> John >> -----Original Message----- >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> Sent: 04 March 2014 11:06 >> To: Henning Rogge >> Cc: MANET IETF; Dearlove, Christopher (UK); Stan Ratliff (sratliff); >> Dowdell, John >> Subject: DLEP performance with and without TCP (was Re: DLEP DT = summary >>=20 >> Hi Henning, >>=20 >> I am not sure if there were consensus on to have stateful >> communication of DLEP (did I miss that, not sure, please advise). I >> think DLEP is abstract approach agreed on as -04. I think DLEP is >> flexible bidirectional communication ( I will read draft-5/draft-4 >> again to make sure). However, I agree with DLEP-04 but still thinking >> why must DLEP-05 and why not draft-04. My comments below, >>=20 >> On Monday, March 3, 2014, Kenning Rogge wrote: >>>=20 >>> What you write make no sense at all. I am not even sure it has much = to do >>> with my answer. >>=20 >> It is related that you gave alternatives to DLEP communication with >> router because of DLEP's ACK messages. TCP also has ACKs, and flow >> control, so overloading channel. In any protocol ACKs are used for >> loss or error possibilities. >>=20 >>>=20 >>> DLEP is not an "over the air" protocol... I also recommend to look = up >>> "stop and wait" protocol. >>=20 >> Yes, it is mentioned that in discussions, but still losses or errors >> may occur in MANET scenarios of D2D (devices comm) or do you mean >> there will be no drops/losses. I interested in ack/retransmit >> technique or sequence numbers technique (ready no need to invint any >> thing) as in AODV communication. So your alternative (2) is my choice >> to make better DLEP performance as in DLEP-04. Why is TCP better than >> UDP while we use ACKs, is it because possible high loss percentage in >> channel? >>=20 >> However, I agree that my discuss may not be clear (sorry for this, = but >> I am motivated and happy to discuss) and I will have to organise my >> comment better after finish my overall review of the DLEP change >> including its performance. See you tomorrow, >>=20 >> Best regards, >>=20 >> AB >>>=20 >>> Henning >>>=20 >>> On Mar 3, 2014 4:31 PM, "Abdussalam Baryun" = >>> wrote: >>>>=20 >>>> Hi Henning, >>>>=20 >>>> Do you mean if the DLEP ACK messages are dropped then DLEP = performance >>>> will be below 70 percent and 30 percent losses? MANET protocols = always >>>> have percentages of errors. >>>>=20 >>>> So do I understand that if there is ACK messages in any MANET = protocol >>>> (which uses transport layer) then there are only three options as = below. >>>> I think AODV is already has option of ACK message but still it = works >>>> perfect with UDP, >>>>=20 >>>> AB >>>>=20 >>>> On Monday, March 3, 2014, Henning Rogge wrote: >>>>>=20 >>>>> The reason for TCP instead of UDP is very simple. >>>>>=20 >>>>> The WG decided quite some time ago that we follow a "stateful = DLEP" >>>>> approach. >>>>>=20 >>>>> DLEP contains ACK messages, which means that you have three = options: >>>>>=20 >>>>> 1) You can implement DLEP as "stop and wait", which means a sender = can >>>>> only a single packet that has to be acknowledged and then waits = for >>>>> the ACK before sending another one. >>>>>=20 >>>>> 2) You can implement a whole bunch of "sequence number", "sliding >>>>> window" and "ack/retransmission" mechanisms. In fact this is a = step >>>>> towards reinventing the wheel depending how clever you want to do >>>>> this. >>=20 >> Yes IMHO, this option gives more flexibility, more independent and >> more performance. >>=20 >>>>>=20 >>>>> 3) You can switch to a reliable transport protocol. >>>>>=20 >>>>> We decided to use option 3) for DLEP-05 because its the easiest to >>>>> implement and does not kill performance like a "stop and wait" >>>>> strategy. >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun >>>>> wrote: >>>>>> Hi Stan, >>>>>>=20 >>>>>> Thanks for you email, i want this draft to go ahead to WGLC with = 04 >>>>>> draft, >>>>>> the 05 had not change only few word, but big changing of = performance. >>>>>>=20 >>>>>> I don't totally disagree with the authors because I see they are >>>>>> doing big >>>>>> effort to make the draft go forward which I agree and understand. >>>>>> However, I >>>>>> will prepare my comments with good reason why not TCP and there = were >>>>>> inputs >>>>>> from WG before questioning and don't think the discussion ended. >>>>>>=20 >>>>>> I think the reasons for going to TCP was not enough but the = authors >>>>>> chosen >>>>>> before UDP and WG adopted that. I will prepare why not TCP, but I >>>>>> think DT >>>>>> should answer in its report first why not UDP then why TCP is = with >>>>>> better >>>>>> performance. The only reason I notice from DT was design issues. >>>>>>=20 >>>>>> @DT >>>>>> Please report : why not UDP in performance of DLEP as comparing = TCP >>>>>> and UDP >>>>>> when using DLEP performance. I understand design purposes but = would >>>>>> think of >>>>>> DLEP overall performance as well. >>>>>>=20 >>>>>> AB >>>>>>=20 >>>>>=20 >> 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, part of the Airbus Defence and Space >> division. Registered Office: Quadrant House, Celtic Springs, = Coedkernew, >> Newport , NP10 8FZ. Registered in England and Wales under company = number >> 04191036 >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Mar 4 07:01:44 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7141A01A8 for ; Tue, 4 Mar 2014 07:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lK8KJqJF0HH8 for ; Tue, 4 Mar 2014 07:01:39 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 283B01A0125 for ; Tue, 4 Mar 2014 07:01:39 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id f73so5111998yha.28 for ; Tue, 04 Mar 2014 07:01:35 -0800 (PST) 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=fs5Ug3fAIgycyhM/DzVvR7J7c9mUrPciy+GDei7AGcc=; b=HroqHMpw7gRe51hIg+CUIVpu3F+72aNeOGFAt09OT9hw/PXY+iW85RxK9VGQt9c+Nn Uieov4HIblY+MtQkGQBmnSdU/Jj9j0kapjdExmWScuWzQLrmDYdvOACywpzm1O/ZPlo3 m0eeOVNt7mHmf5VPzBXnuIvIKQQlSAGNvDmfm8Y89vK9YRkx7GmPcCLWr4R9wMej8Lzz NwvzSBGwO6/2ZJnzfG+O3IYcorJKdvNOezb1fN/ywQvdStd2VRH5DiHuy6pY4tud2UPv gzDbH58Ddyrb6MESDavJBSkyH5Du1NLqXcH5dUwrzyICCAqL82zfaDyjAhdhNoSK9VDN UdGg== MIME-Version: 1.0 X-Received: by 10.236.191.130 with SMTP id g2mr128749yhn.160.1393945295718; Tue, 04 Mar 2014 07:01:35 -0800 (PST) Received: by 10.170.202.7 with HTTP; Tue, 4 Mar 2014 07:01:35 -0800 (PST) In-Reply-To: References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> Date: Tue, 4 Mar 2014 16:01:35 +0100 Message-ID: From: Abdussalam Baryun To: Shawn Jury Content-Type: multipart/alternative; boundary=20cf30563d57300db604f3c92e5a Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BMVWDhLVSzFLfQLDHrEj2KXofKE Cc: MANET IETF Subject: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:01:42 -0000 --20cf30563d57300db604f3c92e5a Content-Type: text/plain; charset=ISO-8859-1 Hi Shawn, Usually, the DT should report why TCP and not UDP, and IMHO, WG still did not confirm its decision. Your reasons does not include any performance issue comparing both transports or comparing both docs draft-04 and draft-05. My concerns are DLEP speed, overhead, and management. The beauty of draft-04 is that it's link speed between devices should not always be with high capacity, but for draft-05 there should be including that in the draft to show its performance limits. Usually, you see thread subject DLEP with TCP in last Aug, I am not alone wanting UDP (don't forget authors started with UDP, Duke and Juliusz) regarding change problems see point below, which made me say IMHO discussion was not enough. http://www.ietf.org/mail-archive/web/manet/current/msg15566.html http://www.ietf.org/mail-archive/web/manet/current/msg15568.html I hope that answers some of my thoughts. Regards AB On Tuesday, March 4, 2014, Shawn Jury wrote: > Hello AB, > > Here we are again with you stating you dislike something, but not > telling us why you dislike it. You are just asking us to explain the > change to you. If I say I like I mean I want or think is better, not totally sure. > > I'll tell you that I wasn't part of the DT for DLEP, but I can see the > benefit of using TCP. Just some of the benefits: > > * No need to recreate a complex state machine in DLEP that would mimic > TCP's behavior. > * TCP is an already existing reliable transport protocol (readily > available). > * Simplifies the overall implementation of the protocol. > * Addresses earlier concerns about how DLEP was a "stop and wait" > protocol. > > With that said, please explain why you do not like TCP for DLEP. You > seem to agree that a reliable transport is needed (ACKs and SeqNums in > -04), but just state that you don't like TCP and are in favor of creating a > protocol that "gives more flexibility, more independent and more > performance". TCP meets the needs that are required for our purpose. > > Unless you can produce a valid argument of why you don't like it, I'm > at a point where I'll just attribute your objections to white noise as > there doesn't seem to be any substance behind them, nor much support from > others on the list. > > If you have a technical argument of why we shouldn't use TCP, please > send it to the list. > > Shawn > > On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: > > > Hi John, > > > > So you mean low possibility of loss, so why not UDP? that is not > > answered, the only answer was because DLEP is stateful and it has ACK > > messages. So why not DLEP-04 while I am using realiable PHY as you > > describe. In addition, even if there are reliability in PHY there may > > be losses in other layers under MANET applicabilities, so that is why > > DLEP-04 has ACKs, which I agree, but don't understand the TCP > > importance in such communication scenarios. > > > > AB > > --20cf30563d57300db604f3c92e5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shawn,

Usually, the DT should report why TCP and not = UDP, and IMHO,=A0WG still did not confirm its decision. Your reasons does n= ot include any performance issue comparing both transports or comparing bot= h docs draft-04 and draft-05.=A0

My concerns are DLEP speed,=A0overhead, and=A0managemen= t. The beauty of draft-04 is that it's=A0link speed betwee= n devices should not always be with high capacity, but for draft-05 there s= hould be including that in the draft to show its performance=A0limits.=A0Us= ually, you see thread subject DLEP with TCP in last Aug,=A0I am=A0not alone= wanting UDP (don't forget authors started with UDP, Duke and Juliusz)= =A0regarding change=A0problems see point below, which made me say IMHO=A0di= scussion was not enough.=A0


I hope that answers some of my thoughts.=A0
=
Regards
AB

On Tuesday, March 4, 2014, Shawn Jury wro= te:
Hello AB,

=A0 =A0 =A0Here we are again with you stating you dislike something, but no= t telling us why you dislike it. =A0You are just asking us to explain the c= hange to you.

If I say I like I mean I want= or think is better, not totally sure.=A0=A0

=A0 =A0 I'll tell you that I wasn't part of the DT for DLEP, but I = can see the benefit of using TCP. =A0Just some of the benefits:

* =A0No need to recreate a complex state machine in DLEP that would mimic T= CP's behavior.
* =A0TCP is an already existing reliable transport protocol (readily availa= ble).
* =A0Simplifies the overall implementation of the protocol.
* =A0Addresses earlier concerns about how DLEP was a "stop and wait&qu= ot; protocol.

=A0 =A0With that said, please explain why you do not like TCP for DLEP. =A0= You seem to agree that a reliable transport is needed (ACKs and SeqNums in = -04), but just state that you don't like TCP and are in favor of creati= ng a protocol that "gives more flexibility, more independent and more = performance". =A0TCP meets the needs that are required for our purpose= .

=A0 =A0 Unless you can produce a valid argument of why you don't like i= t, I'm at a point where I'll just attribute your objections to whit= e noise as there doesn't seem to be any substance behind them, nor much= support from others on the list.

=A0 =A0 If you have a technical argument of why we shouldn't use TCP, p= lease send it to the list.

Shawn

On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote:

> Hi John,
>
> So you mean low possibility of loss, so why not UDP? that is not
> answered, the only answer was because DLEP is stateful and it has ACK<= br> > messages. So why not DLEP-04 while I am using realiable PHY as you
> describe. In addition, even if there are reliability in PHY there may<= br> > be losses in other layers under MANET applicabilities, so that is why<= br> > DLEP-04 has ACKs, which I agree, but don't understand the TCP
> importance in such communication scenarios.
>
> AB

--20cf30563d57300db604f3c92e5a-- From nobody Tue Mar 4 07:52:47 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450761A00AD for ; Tue, 4 Mar 2014 07:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC1lS-nQvV9G for ; Tue, 4 Mar 2014 07:52:39 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3631A0117 for ; Tue, 4 Mar 2014 07:52:39 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id rl12so4434953iec.4 for ; Tue, 04 Mar 2014 07:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Au/asETaHerJZG/wLLwa7VdRfld8D04wf7pWt2tUefc=; b=ctjULf5bxI0GHi0ABLwAmLRUn1g1q45RK82k1ONHkc3hiU8pNFAinnJZ3VYvPBQZVq d3miEX/b2ftXEJhvB+dHfzsJckuaDS509HuyB7kRlzrxDuZ2PVLUG5v7jczIjN00PMdc h0aUfUBAPQv5gss1yaKoWKXXHzTmhV5g8/K+97BqrZr5jnAmDJJKYsqYR0Pu81SEozVn qFXo/QJFtotx05t9VG8LllzooMPFpn4NkST7vcS+5/Ev5VigYJXqxFwqtpY5G1Un+ckt QwilDHQneQ2BPZC8RXo9gfeuQQG8xPcWkmY3dG0Xd7SDynGXLgDUldMH58+2NVZGFUL3 971Q== X-Received: by 10.50.56.109 with SMTP id z13mr4057369igp.6.1393948355885; Tue, 04 Mar 2014 07:52:35 -0800 (PST) Received: from [192.168.1.10] (dynamic-acs-24-112-216-41.zoominternet.net. [24.112.216.41]) by mx.google.com with ESMTPSA id u1sm3720748igm.8.2014.03.04.07.52.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 07:52:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Shawn Jury In-Reply-To: Date: Tue, 4 Mar 2014 10:52:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/x_FgKZp0TcVDyAZrpmSKNUEjSLA Cc: MANET IETF Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:52:42 -0000 AB, As a co-author of the draft, there were many discussions prior to = submission on UDP vs TCP. Our decision of UDP was because we truly = believed this paragraph from the draft (which stated UDP prior to -05): This document specifies an implementation of the DLEP messages and data items running over the TCP transport, utilizing a well-known TCP Port number. It is assumed that DLEP running over other transport mechanisms would be documented separately. If there are situations where another transport protocols would be = better, then an extension could be written (or whatever the best = practice is for IETF drafts in this case). Based upon what I read in the old messages (to refresh my memory), = there is just as much push for TCP as there was for UDP. IMHO, there was = more for TCP. You even linked a message where Teco was pushing for TCP = in your reply to me. I've spent the better part of the last 8 years working with different = radio vendors on a way to get a protocol like this to work. Not once = did anyone ever complain about which transport protocol was being used, = nor did they ever talk about the connection between the router/radio = being limited. All the issues I have run into have been with radios = that have a slightly different implementation and doesn't quite fit into = a specific area (as recent as yesterday). Of course, there are also so = many waiting on the final draft from this working group, I'm wondering = if they will ever get to implement anything. Please, continue pushing for justification on the transport protocol = as I'm sure you believe it is very important. Thanks for your discussion. I'll sit back again and watch as this = becomes more and more of a career path :) Shawn On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: > Hi Shawn, >=20 > Usually, the DT should report why TCP and not UDP, and IMHO, WG still = did not confirm its decision. Your reasons does not include any = performance issue comparing both transports or comparing both docs = draft-04 and draft-05.=20 >=20 > My concerns are DLEP speed, overhead, and management. The beauty of = draft-04 is that it's link speed between devices should not always be = with high capacity, but for draft-05 there should be including that in = the draft to show its performance limits. Usually, you see thread = subject DLEP with TCP in last Aug, I am not alone wanting UDP (don't = forget authors started with UDP, Duke and Juliusz) regarding change = problems see point below, which made me say IMHO discussion was not = enough.=20 >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg15566.html >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg15568.html >=20 > I hope that answers some of my thoughts.=20 > Regards > AB >=20 > On Tuesday, March 4, 2014, Shawn Jury wrote: > Hello AB, >=20 > Here we are again with you stating you dislike something, but not = telling us why you dislike it. You are just asking us to explain the = change to you. >=20 > If I say I like I mean I want or think is better, not totally sure. =20= >=20 > I'll tell you that I wasn't part of the DT for DLEP, but I can see = the benefit of using TCP. Just some of the benefits: >=20 > * No need to recreate a complex state machine in DLEP that would = mimic TCP's behavior. > * TCP is an already existing reliable transport protocol (readily = available). > * Simplifies the overall implementation of the protocol. > * Addresses earlier concerns about how DLEP was a "stop and wait" = protocol. >=20 > With that said, please explain why you do not like TCP for DLEP. = You seem to agree that a reliable transport is needed (ACKs and SeqNums = in -04), but just state that you don't like TCP and are in favor of = creating a protocol that "gives more flexibility, more independent and = more performance". TCP meets the needs that are required for our = purpose. >=20 > Unless you can produce a valid argument of why you don't like it, = I'm at a point where I'll just attribute your objections to white noise = as there doesn't seem to be any substance behind them, nor much support = from others on the list. >=20 > If you have a technical argument of why we shouldn't use TCP, = please send it to the list. >=20 > Shawn >=20 > On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: >=20 > > Hi John, > > > > So you mean low possibility of loss, so why not UDP? that is not > > answered, the only answer was because DLEP is stateful and it has = ACK > > messages. So why not DLEP-04 while I am using realiable PHY as you > > describe. In addition, even if there are reliability in PHY there = may > > be losses in other layers under MANET applicabilities, so that is = why > > DLEP-04 has ACKs, which I agree, but don't understand the TCP > > importance in such communication scenarios. > > > > AB >=20 From nobody Tue Mar 4 08:14:00 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCDD1A0141 for ; Tue, 4 Mar 2014 08:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wttSbwdMvlQb for ; Tue, 4 Mar 2014 08:13:54 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 874651A00B9 for ; Tue, 4 Mar 2014 08:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7961; q=dns/txt; s=iport; t=1393949631; x=1395159231; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zEp1buKqGk2RO90EaeXK97roonunPLrxnzrlfFamVic=; b=GHvmVEV0FjoCbqhbA8UlV29JDp0p2vOa0nrN6lBW2QMCrRjvyBRxS79N vHZL+Xuq8uVovO+vzAa7nfo62ZBi88hvbkx+qAV5sM+Eu5PTUgRZsUo0N d4Qv++mpiqjs99eJ3QhhjVqu41YJIJluNCz5k+xn/7MkVODHopwo7cEe7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAN/6FVOtJV2d/2dsb2JhbABagwY7V8BvgR0WdIIlAQEBAwEBAQE3NAsFCwIBCBgVCRAhBgslAgQOBQmHXAMJCA3FcQ2GXBeMPIE9BwEBHDMCBQqDGoEUBJRRgX6BbYxjhUiDLYFoBwIXIg X-IronPort-AV: E=Sophos;i="4.97,585,1389744000"; d="scan'208";a="308052241" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 04 Mar 2014 16:13:50 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s24GDo3i011511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 16:13:50 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 10:13:50 -0600 From: "Stan Ratliff (sratliff)" To: Shawn Jury Thread-Topic: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary Thread-Index: AQHPN7qpXUPevqa53k2qvBd+CExt2prReKEAgAAF8oA= Date: Tue, 4 Mar 2014 16:13:50 +0000 Message-ID: <47285CC7-BFFF-4BC0-9B58-5DB582D35BA0@cisco.com> References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> In-Reply-To: <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.77] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/61bldVWMzXmiwcifhL_vK9PC6EM Cc: MANET IETF Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:13:57 -0000 All,=20 I also note that Martin Duke wound up contributing quite a bit to the desig= n team effort; I do not recall any dissent from him at the time of the 05 d= raft.=20 Now to address another couple of AB's comments:=20 >>=20 >> Usually, the DT should report why TCP and not UDP, and IMHO, WG still di= d not confirm its decision. I'm not entirely sure what you mean here. The MANET WG has pretty much been= , for as long as I've been involved, a group where (1) first an author (or = a group of authors) submits a draft, and then (2) the WG comments (or 'conf= irms') that iteration of the draft. The Design Team acted in the role of "a= really interested and active subset of the working group that committed to= additional effort in order to enlighten the authors, and thereby, hopefull= y proceed the draft through an iteration or two faster than it has been goi= ng". The design team effort (along with that of the co-authors) has produce= d DLEP-05. Having the WG 'confirm' (or discuss) the 05 draft is what is hap= pening right now. >> Your reasons does not include any performance issue comparing both trans= ports or comparing both docs draft-04 and draft-05.=20 >>=20 We've tried to explain on multiple occasions - there are *no* performance c= onsiderations. None. There are *no* packet loss considerations. None. This = is because the protocol is completely bounded on a local Ethernet segment b= etween a router and an "external modem". This is also because the protocol = does not, in any way, shape, or form, touch the data plane. Data packets th= rough the modem based network flow *exactly* as they would without DLEP run= ning - that is, a packet would egress the router's Ethernet interface, be p= icked up by the external modem, and then transmitted over-the-air to a rece= iving station. So performance was considered, and declared to be a non-issu= e due to the design and implementation of the protocol. Which means we're b= ack to Shawn's enumerated list below on why a TCP-based implementation is a= ctually simpler than a UDP-based implementation. Yes, the ACKs flow, but th= ey are TCP ACKs. Not something the DLEP protocol has to take into account, = process, etc etc.=20 Long story short - I'm in agreement with Shawn. So far, I haven't seen any = technical justification for reconsidering the move to TCP. AB, you said: >>=20 >> My concerns are DLEP speed, overhead, and management. I share those concerns. I just don't see how a move to TCP adversely impact= s them. You'll need to provide more information to enlighten me.=20 Regards, Stan On Mar 4, 2014, at 10:52 AM, Shawn Jury wrote: > AB, >=20 > As a co-author of the draft, there were many discussions prior to subm= ission on UDP vs TCP. Our decision of UDP was because we truly believed t= his paragraph from the draft (which stated UDP prior to -05): >=20 > This document specifies an implementation of the DLEP messages and > data items running over the TCP transport, utilizing a well-known TCP > Port number. It is assumed that DLEP running over other transport > mechanisms would be documented separately. >=20 > If there are situations where another transport protocols would be bett= er, then an extension could be written (or whatever the best practice is fo= r IETF drafts in this case). >=20 > Based upon what I read in the old messages (to refresh my memory), ther= e is just as much push for TCP as there was for UDP. IMHO, there was more f= or TCP. You even linked a message where Teco was pushing for TCP in your r= eply to me. >=20 > I've spent the better part of the last 8 years working with different r= adio vendors on a way to get a protocol like this to work. Not once did an= yone ever complain about which transport protocol was being used, nor did t= hey ever talk about the connection between the router/radio being limited. = All the issues I have run into have been with radios that have a slightly = different implementation and doesn't quite fit into a specific area (as rec= ent as yesterday). Of course, there are also so many waiting on the final = draft from this working group, I'm wondering if they will ever get to imple= ment anything. >=20 > Please, continue pushing for justification on the transport protocol as= I'm sure you believe it is very important. >=20 > Thanks for your discussion. I'll sit back again and watch as this beco= mes more and more of a career path :) >=20 > Shawn >=20 > On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: >=20 >> Hi Shawn, >>=20 >> Usually, the DT should report why TCP and not UDP, and IMHO, WG still di= d not confirm its decision. Your reasons does not include any performance i= ssue comparing both transports or comparing both docs draft-04 and draft-05= .=20 >>=20 >> My concerns are DLEP speed, overhead, and management. The beauty of draf= t-04 is that it's link speed between devices should not always be with high= capacity, but for draft-05 there should be including that in the draft to = show its performance limits. Usually, you see thread subject DLEP with TCP = in last Aug, I am not alone wanting UDP (don't forget authors started with = UDP, Duke and Juliusz) regarding change problems see point below, which mad= e me say IMHO discussion was not enough.=20 >=20 >>=20 >> http://www.ietf.org/mail-archive/web/manet/current/msg15566.html >>=20 >> http://www.ietf.org/mail-archive/web/manet/current/msg15568.html >>=20 >> I hope that answers some of my thoughts.=20 >> Regards >> AB >>=20 >> On Tuesday, March 4, 2014, Shawn Jury wrote: >> Hello AB, >>=20 >> Here we are again with you stating you dislike something, but not te= lling us why you dislike it. You are just asking us to explain the change = to you. >>=20 >> If I say I like I mean I want or think is better, not totally sure. =20 >>=20 >> I'll tell you that I wasn't part of the DT for DLEP, but I can see th= e benefit of using TCP. Just some of the benefits: >>=20 >> * No need to recreate a complex state machine in DLEP that would mimic = TCP's behavior. >> * TCP is an already existing reliable transport protocol (readily avail= able). >> * Simplifies the overall implementation of the protocol. >> * Addresses earlier concerns about how DLEP was a "stop and wait" proto= col. >>=20 >> With that said, please explain why you do not like TCP for DLEP. You = seem to agree that a reliable transport is needed (ACKs and SeqNums in -04)= , but just state that you don't like TCP and are in favor of creating a pro= tocol that "gives more flexibility, more independent and more performance".= TCP meets the needs that are required for our purpose. >>=20 >> Unless you can produce a valid argument of why you don't like it, I'm= at a point where I'll just attribute your objections to white noise as the= re doesn't seem to be any substance behind them, nor much support from othe= rs on the list. >>=20 >> If you have a technical argument of why we shouldn't use TCP, please = send it to the list. >>=20 >> Shawn >>=20 >> On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: >>=20 >>> Hi John, >>>=20 >>> So you mean low possibility of loss, so why not UDP? that is not >>> answered, the only answer was because DLEP is stateful and it has ACK >>> messages. So why not DLEP-04 while I am using realiable PHY as you >>> describe. In addition, even if there are reliability in PHY there may >>> be losses in other layers under MANET applicabilities, so that is why >>> DLEP-04 has ACKs, which I agree, but don't understand the TCP >>> importance in such communication scenarios. >>>=20 >>> AB >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Mar 4 08:49:59 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB0F1A022B for ; Tue, 4 Mar 2014 08:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCcQCIw3dUWX for ; Tue, 4 Mar 2014 08:49:53 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 931751A01EE for ; Tue, 4 Mar 2014 08:49:53 -0800 (PST) Received: by mail-yk0-f170.google.com with SMTP id 9so14902618ykp.1 for ; Tue, 04 Mar 2014 08:49:50 -0800 (PST) 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=d+bwjLYxRJFxTWRdINiNF9HKybhnBaNPELUxvZGlK3U=; b=GGHOxt/caO/Fx6x2TOmnbjXG83pdOCjJQ/t+Hj9mI0cC6KIg0B7qC6oaQ1pUdzxx30 a5dk50uroJl8Ak+y9xjGmlLdvJZcQiThqzZn6Av/zqnR8/jYncMex2vUlTCmyOh/mnUb nZhe8J/xGSqlwK0geHJifi4nmw51/4O5hBDuFc8MfToeHT+BvuBkOvayoN/7E+W/N2xN fEOUUknTs4xnt+V8Plfpcg3n0SaLTOPBig9W06GzM9a3WivVqoXLOajYuEEQPRtKaxSn 2P5KfWy5jfFTCzPYmw77dguvw60TtLdHBEk6C8DHVfiJ7PqQT++f5fAO4/g+jIWly63i gjIA== MIME-Version: 1.0 X-Received: by 10.236.124.193 with SMTP id x41mr719968yhh.54.1393951790208; Tue, 04 Mar 2014 08:49:50 -0800 (PST) Received: by 10.170.202.7 with HTTP; Tue, 4 Mar 2014 08:49:50 -0800 (PST) In-Reply-To: <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> Date: Tue, 4 Mar 2014 17:49:50 +0100 Message-ID: From: Abdussalam Baryun To: Shawn Jury Content-Type: multipart/alternative; boundary=20cf303a36454a1a0304f3cab11a Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-Iy0N9W7RkCFKSfugv5k-aAsrec Cc: MANET IETF Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:49:57 -0000 --20cf303a36454a1a0304f3cab11a Content-Type: text/plain; charset=ISO-8859-1 Hi Shawn, If the WG wants draft 05 as DT decide to pass it instead of draft-04, I will not argue, but I would ask if possible the WG adopts (and the authors may continue authoring) the UDP DLEP as draft-04 for renew draft-00, as you mentioned that separate DLEP documents. Thanks, AB On Tuesday, March 4, 2014, Shawn Jury wrote: > AB, > > As a co-author of the draft, there were many discussions prior to > submission on UDP vs TCP. Our decision of UDP was because we truly > believed this paragraph from the draft (which stated UDP prior to -05): > > This document specifies an implementation of the DLEP messages and > data items running over the TCP transport, utilizing a well-known TCP > Port number. It is assumed that DLEP running over other transport > mechanisms would be documented separately. > > If there are situations where another transport protocols would be > better, then an extension could be written (or whatever the best practice > is for IETF drafts in this case). > > Based upon what I read in the old messages (to refresh my memory), > there is just as much push for TCP as there was for UDP. IMHO, there was > more for TCP. You even linked a message where Teco was pushing for TCP in > your reply to me. > > I've spent the better part of the last 8 years working with different > radio vendors on a way to get a protocol like this to work. Not once did > anyone ever complain about which transport protocol was being used, nor did > they ever talk about the connection between the router/radio being limited. > All the issues I have run into have been with radios that have a slightly > different implementation and doesn't quite fit into a specific area (as > recent as yesterday). Of course, there are also so many waiting on the > final draft from this working group, I'm wondering if they will ever get to > implement anything. > > Please, continue pushing for justification on the transport protocol as > I'm sure you believe it is very important. > > Thanks for your discussion. I'll sit back again and watch as this > becomes more and more of a career path :) > > Shawn > > On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: > > > Hi Shawn, > > > > Usually, the DT should report why TCP and not UDP, and IMHO, WG still > did not confirm its decision. Your reasons does not include any performance > issue comparing both transports or comparing both docs draft-04 and > draft-05. > > > > My concerns are DLEP speed, overhead, and management. The beauty of > draft-04 is that it's link speed between devices should not always be with > high capacity, but for draft-05 there should be including that in the draft > to show its performance limits. Usually, you see thread subject DLEP with > TCP in last Aug, I am not alone wanting UDP (don't forget authors started > with UDP, Duke and Juliusz) regarding change problems see point below, > which made me say IMHO discussion was not enough. > > > > > http://www.ietf.org/mail-archive/web/manet/current/msg15566.html > > > > http://www.ietf.org/mail-archive/web/manet/current/msg15568.html > > > > I hope that answers some of my thoughts. > > Regards > > AB > > > > On Tuesday, March 4, 2014, Shawn Jury wrote: > > Hello AB, > > > > Here we are again with you stating you dislike something, but not > telling us why you dislike it. You are just asking us to explain the > change to you. > > > > If I say I like I mean I want or think is better, not totally sure. > > > > I'll tell you that I wasn't part of the DT for DLEP, but I can see > the benefit of using TCP. Just some of the benefits: > > > > * No need to recreate a complex state machine in DLEP that would mimic > TCP's behavior. > > * TCP is an already existing reliable transport protocol (readily > available). > > * Simplifies the overall implementation of the protocol. > > * Addresses earlier concerns about how DLEP was a "stop and wait" > protocol. > > > > With that said, please explain why you do not like TCP for DLEP. You > seem to agree that a reliable transport is needed (ACKs and SeqNums in > -04), but just state that you don't like TCP and are in favor of creating a > protocol that "gives more flexibility, more independent and more > performance". TCP meets the needs that are required for our purpose. > > > > Unless you can produce a valid argument of why you don't like it, > I'm at a point where I'll just attribute your objections to white noise as > there doesn't seem to be any substance behind them, nor much support from > others on the list. > > > > If you have a technical argument of why we shouldn't use TCP, please > send it to the list. > > > > Shawn > > > > On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: > > > > > Hi John, > > > > > > So you mean low possibility of loss, so why not UDP? that is not > > > answered, the only answer was because DLEP is stateful and it has ACK > > > messages. So why not DLEP-04 while I am using realiable PHY as you > > > describe. In addition, even if there are reliability in PHY there may > > > be losses in other layers under MANET applicabilities, so that is why > > > DLEP-04 has ACKs, which I agree, but don't understand the TCP > > > importance in such communication scenarios. > > > > > > AB > > > > --20cf303a36454a1a0304f3cab11a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shawn,

If the WG wants draft 05 as DT decide=A0to pas= s it=A0instead of draft-04,=A0I will not argue,=A0but I=A0would ask if poss= ible=A0the WG adopts (and the authors may=A0continue authoring)=A0the UDP D= LEP as=A0draft-04 for renew draft-00, as you mentioned that separate DLEP= =A0documents. Thanks,

AB

On Tuesday, March 4, 2014, Shawn Jury wrote:=
AB,

=A0 =A0 As a co-author of the draft, there were many discussions prior to s= ubmission on UDP vs TCP. =A0Our decision of UDP was =A0because we truly bel= ieved this paragraph from the draft (which stated UDP prior to -05):

=A0 =A0This document specifies an implementation of the DLEP messages and =A0 =A0data items running over the TCP transport, utilizing a well-known TC= P
=A0 =A0Port number. It is assumed that DLEP running over other transport =A0 =A0mechanisms would be documented separately.

=A0 =A0If there are situations where another transport protocols would be b= etter, then an extension could be written (or whatever the best practice is= for IETF drafts in this case).

=A0 =A0Based upon what I read in the old messages (to refresh my memory), t= here is just as much push for TCP as there was for UDP. IMHO, there was mor= e for TCP. =A0You even linked a message where Teco was pushing for TCP in y= our reply to me.

=A0 =A0I've spent the better part of the last 8 years working with diff= erent radio vendors on a way to get a protocol like this to work. =A0Not on= ce did anyone ever complain about which transport protocol was being used, = nor did they ever talk about the connection between the router/radio being = limited. =A0All the issues I have run into have been with radios that have = a slightly different implementation and doesn't quite fit into a specif= ic area (as recent as yesterday). =A0Of course, there are also so many wait= ing on the final draft from this working group, I'm wondering if they w= ill ever get to implement anything.

=A0 =A0Please, continue pushing for justification on the transport protocol= as I'm sure you believe it is very important.

=A0 =A0Thanks for your discussion. =A0I'll sit back again and watch as = this becomes more and more of a career path :)

Shawn

On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote:

> Hi Shawn,
>
> Usually, the DT should report why TCP and not UDP, and IMHO, WG still = did not confirm its decision. Your reasons does not include any performance= issue comparing both transports or comparing both docs draft-04 and draft-= 05.
>
> My concerns are DLEP speed, overhead, and management. The beauty of dr= aft-04 is that it's link speed between devices should not always be wit= h high capacity, but for draft-05 there should be including that in the dra= ft to show its performance limits. Usually, you see thread subject DLEP wit= h TCP in last Aug, I am not alone wanting UDP (don't forget authors sta= rted with UDP, Duke and Juliusz) regarding change problems see point below,= which made me say IMHO discussion was not enough.

>
> http://www.ietf.org/mail-archive/web/manet/current= /msg15566.html
>
> http://www.ietf.org/mail-archive/web/manet/current= /msg15568.html
>
> I hope that answers some of my thoughts.
> Regards
> AB
>
> On Tuesday, March 4, 2014, Shawn Jury wrote:
> Hello AB,
>
> =A0 =A0 =A0Here we are again with you stating you dislike something, b= ut not telling us why you dislike it. =A0You are just asking us to explain = the change to you.
>
> If I say I like I mean I want or think is better, not totally sure. >
> =A0 =A0 I'll tell you that I wasn't part of the DT for DLEP, b= ut I can see the benefit of using TCP. =A0Just some of the benefits:
>
> * =A0No need to recreate a complex state machine in DLEP that would mi= mic TCP's behavior.
> * =A0TCP is an already existing reliable transport protocol (readily a= vailable).
> * =A0Simplifies the overall implementation of the protocol.
> * =A0Addresses earlier concerns about how DLEP was a "stop and wa= it" protocol.
>
> =A0 =A0With that said, please explain why you do not like TCP for DLEP= . =A0You seem to agree that a reliable transport is needed (ACKs and SeqNum= s in -04), but just state that you don't like TCP and are in favor of c= reating a protocol that "gives more flexibility, more independent and = more performance". =A0TCP meets the needs that are required for our pu= rpose.
>
> =A0 =A0 Unless you can produce a valid argument of why you don't l= ike it, I'm at a point where I'll just attribute your objections to= white noise as there doesn't seem to be any substance behind them, nor= much support from others on the list.
>
> =A0 =A0 If you have a technical argument of why we shouldn't use T= CP, please send it to the list.
>
> Shawn
>
> On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote:
>
> > Hi John,
> >
> > So you mean low possibility of loss, so why not UDP? that is not<= br> > > answered, the only answer was because DLEP is stateful and it has= ACK
> > messages. So why not DLEP-04 while I am using realiable PHY as yo= u
> > describe. In addition, even if there are reliability in PHY there= may
> > be losses in other layers under MANET applicabilities, so that is= why
> > DLEP-04 has ACKs, which I agree, but don't understand the TCP=
> > importance in such communication scenarios.
> >
> > AB
>

--20cf303a36454a1a0304f3cab11a-- From nobody Tue Mar 4 09:06:10 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCB71A0232 for ; Tue, 4 Mar 2014 09:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ_KqymilKt7 for ; Tue, 4 Mar 2014 09:06:05 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id EFD851A01DC for ; Tue, 4 Mar 2014 09:06:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0C8B7240CFD; Tue, 4 Mar 2014 09:06:02 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6BDE9240735; Tue, 4 Mar 2014 09:06:01 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: <47285CC7-BFFF-4BC0-9B58-5DB582D35BA0@cisco.com> Date: Tue, 4 Mar 2014 18:05:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> <47285CC7-BFFF-4BC0-9B58-5DB582D35BA0@cisco.com> To: "Stan Ratliff (sratliff)" , Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wOKmhbGPWm7Oe9Um1PeYWGOqPRg Cc: MANET IETF Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:06:09 -0000 To abuse two metaphors at once: I have no horses in this fight....but let me= stick my nose out anyways, and start with an anecdote.... I had some concerns with the initial design of an early version of DLEP, spe= cifically how it used in a way I thought wrong. I explained in great details to the= authors why I thought it wrong: my concerns, my reasoning, and the (uninten= ded) consequences that I saw with that element of the DLEP design. The autho= rs went away, came back after having thought it through, with an updated des= ign that satisfied me. Not the design that *I* would have made, mind you, bu= t a design that satisfied my concerns as I had articulated them. That's real= ly all anyone can ask. Now, the authors could do that *only* because they were fed sufficiently pre= cise details, reasons, source material, and technical arguments that they ha= d something to work with, and a reasonable expectation that they'd be able t= o estimate if the outcome would be satisfying. I'm 200% sure that had I been= wrong on this issue, they would have come back with a - just as precise (an= d polite) - rebuttal, which also would have satisfied me by educating me as t= o how I was wrong. Again, for a rebuttal, they would have needed *precise*, d= etailed *technical* arguments from me to work with and rebut. Had I just said "I don't like your design", I'd simply have been ignored - o= r asked to "put up the arguments - or shut up". And, reasonably so, I might= add.=20 If *I* dislike something, then it's *my* job to identify what and why, and a= rticulate that in ways that are actionable by those who I ask to take action= . This may be the authors, and by the WG - or (if taking things further) by t= he chairs, AD, the IESG or the IAB. In this concrete case, Abdussalam doesn't like the choice of TCP in DLEP. I t= hink we all understand that - but that's not actionable. The WG needs precis= e details, reasons, source materials and technical arguments to work with. Once the we, the WG, has those, and only then, can action be taken, either i= n form of a rebuttal or a changed design. It's Abdussalam's job to provide t= hose precise details, reasons, source materials and technical arguments. The= WG (nor the DLEP authors nor any design team) can - nor should - try to gue= ss what they may be. My personal opinion is, that Stan and the others have done an admirable job o= f *trying* to guess and try to provide an explanation and a rebuttal. If the= y have failed to do so to Abdussalam's satisfaction, then it's *not* their f= ault - it's because they do not have precise details, reasons, source materi= als and technical arguments to work with and rebut (or take action on). I am 200% sure that if Abdussalam (or anyone else) do provides such details,= reasons, source materials and technical arguments, then these matters will g= et the attentive ears of the authors and design team. If not, then - and onl= y then - is there a case to make to the WG or to the ADs or the IESG or the I= AB.=20 Until then, or absent that, there's little point in continuing this discussi= on since there's no chance of making constructive progress. Best, Thomas Sent from my iPad > On 4 mars 2014, at 17:13, "Stan Ratliff (sratliff)" w= rote: >=20 > All,=20 >=20 > I also note that Martin Duke wound up contributing quite a bit to the desi= gn team effort; I do not recall any dissent from him at the time of the 05 d= raft.=20 >=20 > Now to address another couple of AB's comments:=20 >>>=20 >>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still di= d not confirm its decision. >=20 > I'm not entirely sure what you mean here. The MANET WG has pretty much bee= n, for as long as I've been involved, a group where (1) first an author (or a= group of authors) submits a draft, and then (2) the WG comments (or 'confir= ms') that iteration of the draft. The Design Team acted in the role of "a re= ally interested and active subset of the working group that committed to add= itional effort in order to enlighten the authors, and thereby, hopefully pro= ceed the draft through an iteration or two faster than it has been going". T= he design team effort (along with that of the co-authors) has produced DLEP-= 05. Having the WG 'confirm' (or discuss) the 05 draft is what is happening r= ight now. >=20 >=20 >>> Your reasons does not include any performance issue comparing both trans= ports or comparing both docs draft-04 and draft-05. >=20 > We've tried to explain on multiple occasions - there are *no* performance c= onsiderations. None. There are *no* packet loss considerations. None. This i= s because the protocol is completely bounded on a local Ethernet segment bet= ween a router and an "external modem". This is also because the protocol doe= s not, in any way, shape, or form, touch the data plane. Data packets throug= h the modem based network flow *exactly* as they would without DLEP running -= that is, a packet would egress the router's Ethernet interface, be picked u= p by the external modem, and then transmitted over-the-air to a receiving st= ation. So performance was considered, and declared to be a non-issue due to t= he design and implementation of the protocol. Which means we're back to Shaw= n's enumerated list below on why a TCP-based implementation is actually simp= ler than a UDP-based implementation. Yes, the ACKs flow, but they are TCP AC= Ks. Not something the DLEP protocol has to take into account, process, etc e= t > c.=20 >=20 > Long story short - I'm in agreement with Shawn. So far, I haven't seen any= technical justification for reconsidering the move to TCP. AB, you said: >>>=20 >>> My concerns are DLEP speed, overhead, and management. >=20 > I share those concerns. I just don't see how a move to TCP adversely impac= ts them. You'll need to provide more information to enlighten me.=20 >=20 > Regards, > Stan >=20 >=20 >=20 > On Mar 4, 2014, at 10:52 AM, Shawn Jury > wrote: >=20 >> AB, >>=20 >> As a co-author of the draft, there were many discussions prior to submi= ssion on UDP vs TCP. Our decision of UDP was because we truly believed thi= s paragraph from the draft (which stated UDP prior to -05): >>=20 >> This document specifies an implementation of the DLEP messages and >> data items running over the TCP transport, utilizing a well-known TCP >> Port number. It is assumed that DLEP running over other transport >> mechanisms would be documented separately. >>=20 >> If there are situations where another transport protocols would be bette= r, then an extension could be written (or whatever the best practice is for I= ETF drafts in this case). >>=20 >> Based upon what I read in the old messages (to refresh my memory), there= is just as much push for TCP as there was for UDP. IMHO, there was more for= TCP. You even linked a message where Teco was pushing for TCP in your repl= y to me. >>=20 >> I've spent the better part of the last 8 years working with different ra= dio vendors on a way to get a protocol like this to work. Not once did anyo= ne ever complain about which transport protocol was being used, nor did they= ever talk about the connection between the router/radio being limited. All= the issues I have run into have been with radios that have a slightly diffe= rent implementation and doesn't quite fit into a specific area (as recent as= yesterday). Of course, there are also so many waiting on the final draft f= rom this working group, I'm wondering if they will ever get to implement any= thing. >>=20 >> Please, continue pushing for justification on the transport protocol as I= 'm sure you believe it is very important. >>=20 >> Thanks for your discussion. I'll sit back again and watch as this becom= es more and more of a career path :) >>=20 >> Shawn >>=20 >>> On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: >>>=20 >>> Hi Shawn, >>>=20 >>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still di= d not confirm its decision. Your reasons does not include any performance is= sue comparing both transports or comparing both docs draft-04 and draft-05.=20= >>>=20 >>> My concerns are DLEP speed, overhead, and management. The beauty of draf= t-04 is that it's link speed between devices should not always be with high c= apacity, but for draft-05 there should be including that in the draft to sho= w its performance limits. Usually, you see thread subject DLEP with TCP in l= ast Aug, I am not alone wanting UDP (don't forget authors started with UDP, D= uke and Juliusz) regarding change problems see point below, which made me sa= y IMHO discussion was not enough. >>=20 >>>=20 >>> http://www.ietf.org/mail-archive/web/manet/current/msg15566.html >>>=20 >>> http://www.ietf.org/mail-archive/web/manet/current/msg15568.html >>>=20 >>> I hope that answers some of my thoughts.=20 >>> Regards >>> AB >>>=20 >>> On Tuesday, March 4, 2014, Shawn Jury wrote: >>> Hello AB, >>>=20 >>> Here we are again with you stating you dislike something, but not tel= ling us why you dislike it. You are just asking us to explain the change to= you. >>>=20 >>> If I say I like I mean I want or think is better, not totally sure. =20 >>>=20 >>> I'll tell you that I wasn't part of the DT for DLEP, but I can see the= benefit of using TCP. Just some of the benefits: >>>=20 >>> * No need to recreate a complex state machine in DLEP that would mimic T= CP's behavior. >>> * TCP is an already existing reliable transport protocol (readily avail= able). >>> * Simplifies the overall implementation of the protocol. >>> * Addresses earlier concerns about how DLEP was a "stop and wait" proto= col. >>>=20 >>> With that said, please explain why you do not like TCP for DLEP. You s= eem to agree that a reliable transport is needed (ACKs and SeqNums in -04), b= ut just state that you don't like TCP and are in favor of creating a protoco= l that "gives more flexibility, more independent and more performance". TCP= meets the needs that are required for our purpose. >>>=20 >>> Unless you can produce a valid argument of why you don't like it, I'm a= t a point where I'll just attribute your objections to white noise as there d= oesn't seem to be any substance behind them, nor much support from others on= the list. >>>=20 >>> If you have a technical argument of why we shouldn't use TCP, please s= end it to the list. >>>=20 >>> Shawn >>>=20 >>>> On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: >>>>=20 >>>> Hi John, >>>>=20 >>>> So you mean low possibility of loss, so why not UDP? that is not >>>> answered, the only answer was because DLEP is stateful and it has ACK >>>> messages. So why not DLEP-04 while I am using realiable PHY as you >>>> describe. In addition, even if there are reliability in PHY there may >>>> be losses in other layers under MANET applicabilities, so that is why >>>> DLEP-04 has ACKs, which I agree, but don't understand the TCP >>>> importance in such communication scenarios. >>>>=20 >>>> AB >>=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 nobody Tue Mar 4 09:24:21 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276C91A0202 for ; Tue, 4 Mar 2014 09:24:19 -0800 (PST) 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=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa3tFhbpTzQP for ; Tue, 4 Mar 2014 09:24:14 -0800 (PST) Received: from mail.tropicalstormsoftware.com (unknown [188.94.42.120]) by ietfa.amsl.com (Postfix) with ESMTP id B98201A0232 for ; Tue, 4 Mar 2014 09:24:12 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 4 Mar 2014 17:23:35 +0000 From: Rick Taylor To: Thomas Heide Clausen , "Stan Ratliff (sratliff)" , Abdussalam Baryun Thread-Topic: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary Thread-Index: AQHPN8TCN1GdvroDlkiWyOslyjSc6JrRKH2AgAABZKw= Date: Tue, 4 Mar 2014 17:23:34 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98FA6C514B@tss-server1.home.tropicalstormsoftware.com> References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> <47285CC7-BFFF-4BC0-9B58-5DB582D35BA0@cisco.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/dfm9ZoXmZexKEm5EYtA4MkvmdT8 Cc: MANET IETF Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:24:19 -0000 Thank you Thomas,=0A= =0A= I was going to bite and had a long reply ready, but I will hold off as I th= ink you may have summarized the difficulties some of us are having second g= uessing AB's objection.=0A= =0A= I do not however think it is sensible to attempt a fork of DLEP-04 resultin= g in DLEP-05-TCP and DLEP-04-UDP. Because: =0A= =0A= A) In the considered opinion of the authors, the design team, and the major= ity of the active participants of the WG, simplifying the protocol by using= TCP will ease the development of many implementations, increasing it's lik= elyhood of becoming a popular standard.=0A= =0A= B) The authors and end-user community only have time and inclination to imp= lement 1 standard.=0A= =0A= AB, if you are in London, please come and find me after the MANET WG meetin= g tomorrow and I will try to explain why the authors and DT decided on TCP.= I believe you may have some gaps in your understanding that I am perfectl= y happy to try to fill.=0A= =0A= Also, may I kindly remind you that it is the authors who are presenting the= ir proposal for the DLEP protocol to the MANET WG. They are not beholden t= o the members of the DT, or WG, or the IETF. We may raise concerns, but th= is is a forum for constructive criticism, and there is nothing to prevent S= tan et.al. from picking up their protocol and going home with it.=0A= =0A= Rick Taylor=0A= =0A= Who has bitten after all...=0A= =0A= ________________________________________=0A= From: manet [manet-bounces@ietf.org] on behalf of Thomas Heide Clausen [iet= f@thomasclausen.org]=0A= Sent: 04 March 2014 17:05=0A= To: Stan Ratliff (sratliff); Abdussalam Baryun=0A= Cc: MANET IETF=0A= Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT= summary=0A= =0A= To abuse two metaphors at once: I have no horses in this fight....but let m= e stick my nose out anyways, and start with an anecdote....=0A= =0A= I had some concerns with the initial design of an early version of DLEP, sp= ecifically how it used in a way I thought wrong. I explained in great details to = the authors why I thought it wrong: my concerns, my reasoning, and the (uni= ntended) consequences that I saw with that element of the DLEP design. The = authors went away, came back after having thought it through, with an updat= ed design that satisfied me. Not the design that *I* would have made, mind = you, but a design that satisfied my concerns as I had articulated them. Tha= t's really all anyone can ask.=0A= =0A= Now, the authors could do that *only* because they were fed sufficiently pr= ecise details, reasons, source material, and technical arguments that they = had something to work with, and a reasonable expectation that they'd be abl= e to estimate if the outcome would be satisfying. I'm 200% sure that had I = been wrong on this issue, they would have come back with a - just as precis= e (and polite) - rebuttal, which also would have satisfied me by educating = me as to how I was wrong. Again, for a rebuttal, they would have needed *pr= ecise*, detailed *technical* arguments from me to work with and rebut.=0A= =0A= Had I just said "I don't like your design", I'd simply have been ignored - = or asked to "put up the arguments - or shut up". And, reasonably so, I mig= ht add.=0A= =0A= If *I* dislike something, then it's *my* job to identify what and why, and = articulate that in ways that are actionable by those who I ask to take acti= on. This may be the authors, and by the WG - or (if taking things further) = by the chairs, AD, the IESG or the IAB.=0A= =0A= In this concrete case, Abdussalam doesn't like the choice of TCP in DLEP. I= think we all understand that - but that's not actionable. The WG needs pre= cise details, reasons, source materials and technical arguments to work wit= h.=0A= =0A= Once the we, the WG, has those, and only then, can action be taken, either = in form of a rebuttal or a changed design. It's Abdussalam's job to provide= those precise details, reasons, source materials and technical arguments. = The WG (nor the DLEP authors nor any design team) can - nor should - try to= guess what they may be.=0A= =0A= My personal opinion is, that Stan and the others have done an admirable job= of *trying* to guess and try to provide an explanation and a rebuttal. If = they have failed to do so to Abdussalam's satisfaction, then it's *not* th= eir fault - it's because they do not have precise details, reasons, source = materials and technical arguments to work with and rebut (or take action on= ).=0A= =0A= I am 200% sure that if Abdussalam (or anyone else) do provides such details= , reasons, source materials and technical arguments, then these matters wil= l get the attentive ears of the authors and design team. If not, then - and= only then - is there a case to make to the WG or to the ADs or the IESG or= the IAB.=0A= =0A= Until then, or absent that, there's little point in continuing this discuss= ion since there's no chance of making constructive progress.=0A= =0A= Best,=0A= =0A= Thomas=0A= =0A= Sent from my iPad=0A= =0A= > On 4 mars 2014, at 17:13, "Stan Ratliff (sratliff)" = wrote:=0A= >=0A= > All,=0A= >=0A= > I also note that Martin Duke wound up contributing quite a bit to the des= ign team effort; I do not recall any dissent from him at the time of the 05= draft.=0A= >=0A= > Now to address another couple of AB's comments:=0A= >>>=0A= >>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still d= id not confirm its decision.=0A= >=0A= > I'm not entirely sure what you mean here. The MANET WG has pretty much be= en, for as long as I've been involved, a group where (1) first an author (o= r a group of authors) submits a draft, and then (2) the WG comments (or 'co= nfirms') that iteration of the draft. The Design Team acted in the role of = "a really interested and active subset of the working group that committed = to additional effort in order to enlighten the authors, and thereby, hopefu= lly proceed the draft through an iteration or two faster than it has been g= oing". The design team effort (along with that of the co-authors) has produ= ced DLEP-05. Having the WG 'confirm' (or discuss) the 05 draft is what is h= appening right now.=0A= >=0A= >=0A= >>> Your reasons does not include any performance issue comparing both tran= sports or comparing both docs draft-04 and draft-05.=0A= >=0A= > We've tried to explain on multiple occasions - there are *no* performance= considerations. None. There are *no* packet loss considerations. None. Thi= s is because the protocol is completely bounded on a local Ethernet segment= between a router and an "external modem". This is also because the protoco= l does not, in any way, shape, or form, touch the data plane. Data packets = through the modem based network flow *exactly* as they would without DLEP r= unning - that is, a packet would egress the router's Ethernet interface, be= picked up by the external modem, and then transmitted over-the-air to a re= ceiving station. So performance was considered, and declared to be a non-is= sue due to the design and implementation of the protocol. Which means we're= back to Shawn's enumerated list below on why a TCP-based implementation is= actually simpler than a UDP-based implementation. Yes, the ACKs flow, but = they are TCP ACKs. Not something the DLEP protocol has to take into account= , process, etc et=0A= > c.=0A= >=0A= > Long story short - I'm in agreement with Shawn. So far, I haven't seen an= y technical justification for reconsidering the move to TCP. AB, you said:= =0A= >>>=0A= >>> My concerns are DLEP speed, overhead, and management.=0A= >=0A= > I share those concerns. I just don't see how a move to TCP adversely impa= cts them. You'll need to provide more information to enlighten me.=0A= >=0A= > Regards,=0A= > Stan=0A= >=0A= >=0A= >=0A= > On Mar 4, 2014, at 10:52 AM, Shawn Jury =0A= > wrote:=0A= >=0A= >> AB,=0A= >>=0A= >> As a co-author of the draft, there were many discussions prior to subm= ission on UDP vs TCP. Our decision of UDP was because we truly believed t= his paragraph from the draft (which stated UDP prior to -05):=0A= >>=0A= >> This document specifies an implementation of the DLEP messages and=0A= >> data items running over the TCP transport, utilizing a well-known TCP= =0A= >> Port number. It is assumed that DLEP running over other transport=0A= >> mechanisms would be documented separately.=0A= >>=0A= >> If there are situations where another transport protocols would be bett= er, then an extension could be written (or whatever the best practice is fo= r IETF drafts in this case).=0A= >>=0A= >> Based upon what I read in the old messages (to refresh my memory), ther= e is just as much push for TCP as there was for UDP. IMHO, there was more f= or TCP. You even linked a message where Teco was pushing for TCP in your r= eply to me.=0A= >>=0A= >> I've spent the better part of the last 8 years working with different r= adio vendors on a way to get a protocol like this to work. Not once did an= yone ever complain about which transport protocol was being used, nor did t= hey ever talk about the connection between the router/radio being limited. = All the issues I have run into have been with radios that have a slightly = different implementation and doesn't quite fit into a specific area (as rec= ent as yesterday). Of course, there are also so many waiting on the final = draft from this working group, I'm wondering if they will ever get to imple= ment anything.=0A= >>=0A= >> Please, continue pushing for justification on the transport protocol as= I'm sure you believe it is very important.=0A= >>=0A= >> Thanks for your discussion. I'll sit back again and watch as this beco= mes more and more of a career path :)=0A= >>=0A= >> Shawn=0A= >>=0A= >>> On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote:=0A= >>>=0A= >>> Hi Shawn,=0A= >>>=0A= >>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still d= id not confirm its decision. Your reasons does not include any performance = issue comparing both transports or comparing both docs draft-04 and draft-0= 5.=0A= >>>=0A= >>> My concerns are DLEP speed, overhead, and management. The beauty of dra= ft-04 is that it's link speed between devices should not always be with hig= h capacity, but for draft-05 there should be including that in the draft to= show its performance limits. Usually, you see thread subject DLEP with TCP= in last Aug, I am not alone wanting UDP (don't forget authors started with= UDP, Duke and Juliusz) regarding change problems see point below, which ma= de me say IMHO discussion was not enough.=0A= >>=0A= >>>=0A= >>> http://www.ietf.org/mail-archive/web/manet/current/msg15566.html=0A= >>>=0A= >>> http://www.ietf.org/mail-archive/web/manet/current/msg15568.html=0A= >>>=0A= >>> I hope that answers some of my thoughts.=0A= >>> Regards=0A= >>> AB=0A= >>>=0A= >>> On Tuesday, March 4, 2014, Shawn Jury wrote:=0A= >>> Hello AB,=0A= >>>=0A= >>> Here we are again with you stating you dislike something, but not te= lling us why you dislike it. You are just asking us to explain the change = to you.=0A= >>>=0A= >>> If I say I like I mean I want or think is better, not totally sure.=0A= >>>=0A= >>> I'll tell you that I wasn't part of the DT for DLEP, but I can see th= e benefit of using TCP. Just some of the benefits:=0A= >>>=0A= >>> * No need to recreate a complex state machine in DLEP that would mimic= TCP's behavior.=0A= >>> * TCP is an already existing reliable transport protocol (readily avai= lable).=0A= >>> * Simplifies the overall implementation of the protocol.=0A= >>> * Addresses earlier concerns about how DLEP was a "stop and wait" prot= ocol.=0A= >>>=0A= >>> With that said, please explain why you do not like TCP for DLEP. You = seem to agree that a reliable transport is needed (ACKs and SeqNums in -04)= , but just state that you don't like TCP and are in favor of creating a pro= tocol that "gives more flexibility, more independent and more performance".= TCP meets the needs that are required for our purpose.=0A= >>>=0A= >>> Unless you can produce a valid argument of why you don't like it, I'm= at a point where I'll just attribute your objections to white noise as the= re doesn't seem to be any substance behind them, nor much support from othe= rs on the list.=0A= >>>=0A= >>> If you have a technical argument of why we shouldn't use TCP, please = send it to the list.=0A= >>>=0A= >>> Shawn=0A= >>>=0A= >>>> On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote:=0A= >>>>=0A= >>>> Hi John,=0A= >>>>=0A= >>>> So you mean low possibility of loss, so why not UDP? that is not=0A= >>>> answered, the only answer was because DLEP is stateful and it has ACK= =0A= >>>> messages. So why not DLEP-04 while I am using realiable PHY as you=0A= >>>> describe. In addition, even if there are reliability in PHY there may= =0A= >>>> be losses in other layers under MANET applicabilities, so that is why= =0A= >>>> DLEP-04 has ACKs, which I agree, but don't understand the TCP=0A= >>>> importance in such communication scenarios.=0A= >>>>=0A= >>>> AB=0A= >>=0A= >> _______________________________________________=0A= >> manet mailing list=0A= >> manet@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= =0A= _______________________________________________=0A= manet mailing list=0A= manet@ietf.org=0A= https://www.ietf.org/mailman/listinfo/manet=0A= From nobody Tue Mar 4 09:36:37 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0443E1A0262 for ; Tue, 4 Mar 2014 09:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyWBNxBHpgcd for ; Tue, 4 Mar 2014 09:36:13 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 32D9A1A0257 for ; Tue, 4 Mar 2014 09:36:13 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id z12so5426535wgg.29 for ; Tue, 04 Mar 2014 09:36:09 -0800 (PST) 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:from:subject:date:to; bh=O71JWE/xXdv8gbqk2yFvnkYxzZUZPgaDC2mA1LUb9i8=; b=wZrjVIxGjMrCi7TEIUAbVgSOf9tpkeT3rXO1UnWJEqPESdOLmfMvRTtmMhEN/BfmJh 33kJ8o8wpMRYeVGdKmlSjsqFOzCBcCpAnahPkeFJJsiFN+7r9sVcsn0lZKWMfbjxhY6B 66zNmK0Kq7Za+bWQHACPCp/ryFdZI+HV8daPCDvLpfT4vKlvvGeoD8s7RWfklEIlAC2f WkYjz39YO7Z7kEQ/LMjI26sX8873iSk8YGt2HQ3p8kx3w3zo7uNQ9ERKbm66D04X+3/o vs2bRj82ytcO7k86vznnHPSyK87/PNNyVktK9iZrQosmp4LdDdQaxolhut37ey567mAt gTbQ== X-Received: by 10.194.87.163 with SMTP id az3mr999796wjb.63.1393954569496; Tue, 04 Mar 2014 09:36:09 -0800 (PST) Received: from ?IPv6:2001:67c:370:176:107a:f104:16e9:5534? ([2001:67c:370:176:107a:f104:16e9:5534]) by mx.google.com with ESMTPSA id xt1sm55508438wjb.17.2014.03.04.09.36.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 09:36:08 -0800 (PST) References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> <47285CC7-BFFF-4BC0-9B58-5DB582D35BA0@cisco.com> <38A5475DE83986499AEACD2CFAFC3F98FA6C514B@tss-server1.home.tropicalstormsoftware.com> Mime-Version: 1.0 (1.0) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98FA6C514B@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3CDC0647-052A-44E6-B8E9-D67864260A3D@gmail.com> X-Mailer: iPhone Mail (11B651) From: Christopher Dearlove Date: Tue, 4 Mar 2014 17:36:06 +0000 To: Rick Taylor Archived-At: http://mailarchive.ietf.org/arch/msg/manet/jIUHwd6_HmtErN8Dx6AR2fpP0Jw Cc: MANET IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:36:17 -0000 I'm not sure I've ever seen a forked protocol. There are cases like OSPF whe= re v3 has not replaced v2 but lives alongside it. But they have an important= difference, as well as being many years apart. However two separate protocols alongside each other doing the same thing bot= h trying to get through the IESG? I think most of us who have pushed protoco= ls through the process would estimate the chances of success for both as clo= se enough to zero to consider it that. And it would both reduce the probabil= ity and increase the delay of one. Which makes it about the most unattractiv= e proposition that could be offered to the authors. -- =20 Christopher Dearlove christopher.dearlove@gmail.com > On 4 Mar 2014, at 17:23, Rick Taylor wrot= e: >=20 > Thank you Thomas, >=20 > I was going to bite and had a long reply ready, but I will hold off as I t= hink you may have summarized the difficulties some of us are having second g= uessing AB's objection. >=20 > I do not however think it is sensible to attempt a fork of DLEP-04 resulti= ng in DLEP-05-TCP and DLEP-04-UDP. Because:=20 >=20 > A) In the considered opinion of the authors, the design team, and the majo= rity of the active participants of the WG, simplifying the protocol by using= TCP will ease the development of many implementations, increasing it's like= lyhood of becoming a popular standard. >=20 > B) The authors and end-user community only have time and inclination to im= plement 1 standard. >=20 > AB, if you are in London, please come and find me after the MANET WG meeti= ng tomorrow and I will try to explain why the authors and DT decided on TCP.= I believe you may have some gaps in your understanding that I am perfectly= happy to try to fill. >=20 > Also, may I kindly remind you that it is the authors who are presenting th= eir proposal for the DLEP protocol to the MANET WG. They are not beholden t= o the members of the DT, or WG, or the IETF. We may raise concerns, but thi= s is a forum for constructive criticism, and there is nothing to prevent Sta= n et.al. from picking up their protocol and going home with it. >=20 > Rick Taylor >=20 > Who has bitten after all... >=20 > ________________________________________ > From: manet [manet-bounces@ietf.org] on behalf of Thomas Heide Clausen [ie= tf@thomasclausen.org] > Sent: 04 March 2014 17:05 > To: Stan Ratliff (sratliff); Abdussalam Baryun > Cc: MANET IETF > Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP D= T summary >=20 > To abuse two metaphors at once: I have no horses in this fight....but let m= e stick my nose out anyways, and start with an anecdote.... >=20 > I had some concerns with the initial design of an early version of DLEP, s= pecifically how it used in a way I thought wrong. I explained in great details to t= he authors why I thought it wrong: my concerns, my reasoning, and the (unint= ended) consequences that I saw with that element of the DLEP design. The aut= hors went away, came back after having thought it through, with an updated d= esign that satisfied me. Not the design that *I* would have made, mind you, b= ut a design that satisfied my concerns as I had articulated them. That's rea= lly all anyone can ask. >=20 > Now, the authors could do that *only* because they were fed sufficiently p= recise details, reasons, source material, and technical arguments that they h= ad something to work with, and a reasonable expectation that they'd be able t= o estimate if the outcome would be satisfying. I'm 200% sure that had I been= wrong on this issue, they would have come back with a - just as precise (an= d polite) - rebuttal, which also would have satisfied me by educating me as t= o how I was wrong. Again, for a rebuttal, they would have needed *precise*, d= etailed *technical* arguments from me to work with and rebut. >=20 > Had I just said "I don't like your design", I'd simply have been ignored -= or asked to "put up the arguments - or shut up". And, reasonably so, I mig= ht add. >=20 > If *I* dislike something, then it's *my* job to identify what and why, and= articulate that in ways that are actionable by those who I ask to take acti= on. This may be the authors, and by the WG - or (if taking things further) b= y the chairs, AD, the IESG or the IAB. >=20 > In this concrete case, Abdussalam doesn't like the choice of TCP in DLEP. I= think we all understand that - but that's not actionable. The WG needs prec= ise details, reasons, source materials and technical arguments to work with.= >=20 > Once the we, the WG, has those, and only then, can action be taken, either= in form of a rebuttal or a changed design. It's Abdussalam's job to provide= those precise details, reasons, source materials and technical arguments. T= he WG (nor the DLEP authors nor any design team) can - nor should - try to g= uess what they may be. >=20 > My personal opinion is, that Stan and the others have done an admirable jo= b of *trying* to guess and try to provide an explanation and a rebuttal. If t= hey have failed to do so to Abdussalam's satisfaction, then it's *not* thei= r fault - it's because they do not have precise details, reasons, source mat= erials and technical arguments to work with and rebut (or take action on). >=20 > I am 200% sure that if Abdussalam (or anyone else) do provides such detail= s, reasons, source materials and technical arguments, then these matters wil= l get the attentive ears of the authors and design team. If not, then - and o= nly then - is there a case to make to the WG or to the ADs or the IESG or th= e IAB. >=20 > Until then, or absent that, there's little point in continuing this discus= sion since there's no chance of making constructive progress. >=20 > Best, >=20 > Thomas >=20 > Sent from my iPad >=20 >> On 4 mars 2014, at 17:13, "Stan Ratliff (sratliff)" w= rote: >>=20 >> All, >>=20 >> I also note that Martin Duke wound up contributing quite a bit to the des= ign team effort; I do not recall any dissent from him at the time of the 05 d= raft. >>=20 >> Now to address another couple of AB's comments: >>>>=20 >>>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still d= id not confirm its decision. >>=20 >> I'm not entirely sure what you mean here. The MANET WG has pretty much be= en, for as long as I've been involved, a group where (1) first an author (or= a group of authors) submits a draft, and then (2) the WG comments (or 'conf= irms') that iteration of the draft. The Design Team acted in the role of "a r= eally interested and active subset of the working group that committed to ad= ditional effort in order to enlighten the authors, and thereby, hopefully pr= oceed the draft through an iteration or two faster than it has been going". T= he design team effort (along with that of the co-authors) has produced DLEP-= 05. Having the WG 'confirm' (or discuss) the 05 draft is what is happening r= ight now. >>=20 >>=20 >>>> Your reasons does not include any performance issue comparing both tran= sports or comparing both docs draft-04 and draft-05. >>=20 >> We've tried to explain on multiple occasions - there are *no* performance= considerations. None. There are *no* packet loss considerations. None. This= is because the protocol is completely bounded on a local Ethernet segment b= etween a router and an "external modem". This is also because the protocol d= oes not, in any way, shape, or form, touch the data plane. Data packets thro= ugh the modem based network flow *exactly* as they would without DLEP runnin= g - that is, a packet would egress the router's Ethernet interface, be picke= d up by the external modem, and then transmitted over-the-air to a receiving= station. So performance was considered, and declared to be a non-issue due t= o the design and implementation of the protocol. Which means we're back to S= hawn's enumerated list below on why a TCP-based implementation is actually s= impler than a UDP-based implementation. Yes, the ACKs flow, but they are TCP= ACKs. Not something the DLEP protocol has to take into account, process, et= c et >> c. >>=20 >> Long story short - I'm in agreement with Shawn. So far, I haven't seen an= y technical justification for reconsidering the move to TCP. AB, you said: >>>>=20 >>>> My concerns are DLEP speed, overhead, and management. >>=20 >> I share those concerns. I just don't see how a move to TCP adversely impa= cts them. You'll need to provide more information to enlighten me. >>=20 >> Regards, >> Stan >>=20 >>=20 >>=20 >> On Mar 4, 2014, at 10:52 AM, Shawn Jury >> wrote: >>=20 >>> AB, >>>=20 >>> As a co-author of the draft, there were many discussions prior to submi= ssion on UDP vs TCP. Our decision of UDP was because we truly believed thi= s paragraph from the draft (which stated UDP prior to -05): >>>=20 >>> This document specifies an implementation of the DLEP messages and >>> data items running over the TCP transport, utilizing a well-known TCP >>> Port number. It is assumed that DLEP running over other transport >>> mechanisms would be documented separately. >>>=20 >>> If there are situations where another transport protocols would be bette= r, then an extension could be written (or whatever the best practice is for I= ETF drafts in this case). >>>=20 >>> Based upon what I read in the old messages (to refresh my memory), there= is just as much push for TCP as there was for UDP. IMHO, there was more for= TCP. You even linked a message where Teco was pushing for TCP in your repl= y to me. >>>=20 >>> I've spent the better part of the last 8 years working with different ra= dio vendors on a way to get a protocol like this to work. Not once did anyo= ne ever complain about which transport protocol was being used, nor did they= ever talk about the connection between the router/radio being limited. All= the issues I have run into have been with radios that have a slightly diffe= rent implementation and doesn't quite fit into a specific area (as recent as= yesterday). Of course, there are also so many waiting on the final draft f= rom this working group, I'm wondering if they will ever get to implement any= thing. >>>=20 >>> Please, continue pushing for justification on the transport protocol as I= 'm sure you believe it is very important. >>>=20 >>> Thanks for your discussion. I'll sit back again and watch as this becom= es more and more of a career path :) >>>=20 >>> Shawn >>>=20 >>>> On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: >>>>=20 >>>> Hi Shawn, >>>>=20 >>>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still d= id not confirm its decision. Your reasons does not include any performance i= ssue comparing both transports or comparing both docs draft-04 and draft-05.= >>>>=20 >>>> My concerns are DLEP speed, overhead, and management. The beauty of dra= ft-04 is that it's link speed between devices should not always be with high= capacity, but for draft-05 there should be including that in the draft to s= how its performance limits. Usually, you see thread subject DLEP with TCP in= last Aug, I am not alone wanting UDP (don't forget authors started with UDP= , Duke and Juliusz) regarding change problems see point below, which made me= say IMHO discussion was not enough. >>>=20 >>>>=20 >>>> http://www.ietf.org/mail-archive/web/manet/current/msg15566.html >>>>=20 >>>> http://www.ietf.org/mail-archive/web/manet/current/msg15568.html >>>>=20 >>>> I hope that answers some of my thoughts. >>>> Regards >>>> AB >>>>=20 >>>> On Tuesday, March 4, 2014, Shawn Jury wrote: >>>> Hello AB, >>>>=20 >>>> Here we are again with you stating you dislike something, but not tel= ling us why you dislike it. You are just asking us to explain the change to= you. >>>>=20 >>>> If I say I like I mean I want or think is better, not totally sure. >>>>=20 >>>> I'll tell you that I wasn't part of the DT for DLEP, but I can see the= benefit of using TCP. Just some of the benefits: >>>>=20 >>>> * No need to recreate a complex state machine in DLEP that would mimic= TCP's behavior. >>>> * TCP is an already existing reliable transport protocol (readily avai= lable). >>>> * Simplifies the overall implementation of the protocol. >>>> * Addresses earlier concerns about how DLEP was a "stop and wait" prot= ocol. >>>>=20 >>>> With that said, please explain why you do not like TCP for DLEP. You s= eem to agree that a reliable transport is needed (ACKs and SeqNums in -04), b= ut just state that you don't like TCP and are in favor of creating a protoco= l that "gives more flexibility, more independent and more performance". TCP= meets the needs that are required for our purpose. >>>>=20 >>>> Unless you can produce a valid argument of why you don't like it, I'm a= t a point where I'll just attribute your objections to white noise as there d= oesn't seem to be any substance behind them, nor much support from others on= the list. >>>>=20 >>>> If you have a technical argument of why we shouldn't use TCP, please s= end it to the list. >>>>=20 >>>> Shawn >>>>=20 >>>>> On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>> Hi John, >>>>>=20 >>>>> So you mean low possibility of loss, so why not UDP? that is not >>>>> answered, the only answer was because DLEP is stateful and it has ACK >>>>> messages. So why not DLEP-04 while I am using realiable PHY as you >>>>> describe. In addition, even if there are reliability in PHY there may >>>>> be losses in other layers under MANET applicabilities, so that is why >>>>> DLEP-04 has ACKs, which I agree, but don't understand the TCP >>>>> importance in such communication scenarios. >>>>>=20 >>>>> AB >>>=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 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Mar 4 09:41:11 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD731A028C for ; Tue, 4 Mar 2014 09:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WTABTXRklOE for ; Tue, 4 Mar 2014 09:40:43 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id D62321A0271 for ; Tue, 4 Mar 2014 09:40:41 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id m5so4504575qaj.21 for ; Tue, 04 Mar 2014 09:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yXNq1ubZ7hQTGea8uTaHKkdUnmJy0jXTartfDqqkwoo=; b=lflwuqUB/36Tdow1Ro55r5SXsB4Cy5UG526PmVRQJ33kHVzXdm3PTlVo+juyyRen4J lHFVuaBSsWYuZH4ck6UjPcUi4hB+Acjqt5TSkZ3pXgJ3knXAJrekae02YuCjN8yCLzGx 37TgoH7GpMkSs94FIx1W2UkkPs0go6W2urUiV8n80qQTx0JpOlQTSMdS4TkmbwKs/jVx VkRBNItWle1zpwt5czNcmsGavqVOh3QWYE8UeRLtvKlS28TY1fxt1vqRlfMLUJGKdPxu +M/G369gGLUgPa4dM1e509/4xIjouOoORXbWyIVxQF2kyuHwHcqXWmNcloc4iKOJvWEC vNdA== X-Received: by 10.224.87.193 with SMTP id x1mr1225104qal.70.1393954838360; Tue, 04 Mar 2014 09:40:38 -0800 (PST) Received: from [192.168.1.114] (c-69-140-151-4.hsd1.md.comcast.net. [69.140.151.4]) by mx.google.com with ESMTPSA id r40sm20912886qga.23.2014.03.04.09.40.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 09:40:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Joe Macker In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98FA6C514B@tss-server1.home.tropicalstormsoftware.com> Date: Tue, 4 Mar 2014 12:40:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <67973D50-B9EA-4BA2-9A8F-F901CF1928AA@gmail.com> References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> <47285CC7-BFFF-4BC0-9B58-5DB582D35BA0@cisco.com>, <38A5475DE83986499AEACD2CFAFC3F98FA6C514B@tss-server1.home.tropicalstormsoftware.com> To: Rick Taylor X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3xsxp5RQ3TwbCZXfpdSZ_1kJeWE Cc: MANET IETF , Stan Ratliff Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:40:46 -0000 Thank you all for taking the time to provide your observations/opinions. In my observation as co-chair there was a strong consensus among the = developers and authors to go with TCP as the requirement in the present = instantiation of the DLEP specification. As many have mentioned this is = not an over-the-air protocol. This decision was reported out at the = last Vancouver WG meeting in slides and minutes in a clear manner you = can go back and check. The authors have provided rationale for their = decision. Moving forward with one specification is my strong recommendation. I am = not a fan of forking off a separate specification at this point. I = think the WG and the DT is beyond this design point. -Joe=20 On Mar 4, 2014, at 12:23 PM, Rick Taylor = wrote: > Thank you Thomas, >=20 > I was going to bite and had a long reply ready, but I will hold off as = I think you may have summarized the difficulties some of us are having = second guessing AB's objection. >=20 > I do not however think it is sensible to attempt a fork of DLEP-04 = resulting in DLEP-05-TCP and DLEP-04-UDP. Because:=20 >=20 > A) In the considered opinion of the authors, the design team, and the = majority of the active participants of the WG, simplifying the protocol = by using TCP will ease the development of many implementations, = increasing it's likelyhood of becoming a popular standard. >=20 > B) The authors and end-user community only have time and inclination = to implement 1 standard. >=20 > AB, if you are in London, please come and find me after the MANET WG = meeting tomorrow and I will try to explain why the authors and DT = decided on TCP. I believe you may have some gaps in your understanding = that I am perfectly happy to try to fill. >=20 > Also, may I kindly remind you that it is the authors who are = presenting their proposal for the DLEP protocol to the MANET WG. They = are not beholden to the members of the DT, or WG, or the IETF. We may = raise concerns, but this is a forum for constructive criticism, and = there is nothing to prevent Stan et.al. from picking up their protocol = and going home with it. >=20 > Rick Taylor >=20 > Who has bitten after all... >=20 > ________________________________________ > From: manet [manet-bounces@ietf.org] on behalf of Thomas Heide Clausen = [ietf@thomasclausen.org] > Sent: 04 March 2014 17:05 > To: Stan Ratliff (sratliff); Abdussalam Baryun > Cc: MANET IETF > Subject: Re: [manet] DLEP performance with and without TCP (was Re: = DLEP DT summary >=20 > To abuse two metaphors at once: I have no horses in this fight....but = let me stick my nose out anyways, and start with an anecdote.... >=20 > I had some concerns with the initial design of an early version of = DLEP, specifically how it used = in = a way I thought wrong. I explained in great details to the authors why I = thought it wrong: my concerns, my reasoning, and the (unintended) = consequences that I saw with that element of the DLEP design. The = authors went away, came back after having thought it through, with an = updated design that satisfied me. Not the design that *I* would have = made, mind you, but a design that satisfied my concerns as I had = articulated them. That's really all anyone can ask. >=20 > Now, the authors could do that *only* because they were fed = sufficiently precise details, reasons, source material, and technical = arguments that they had something to work with, and a reasonable = expectation that they'd be able to estimate if the outcome would be = satisfying. I'm 200% sure that had I been wrong on this issue, they = would have come back with a - just as precise (and polite) - rebuttal, = which also would have satisfied me by educating me as to how I was = wrong. Again, for a rebuttal, they would have needed *precise*, detailed = *technical* arguments from me to work with and rebut. >=20 > Had I just said "I don't like your design", I'd simply have been = ignored - or asked to "put up the arguments - or shut up". And, = reasonably so, I might add. >=20 > If *I* dislike something, then it's *my* job to identify what and why, = and articulate that in ways that are actionable by those who I ask to = take action. This may be the authors, and by the WG - or (if taking = things further) by the chairs, AD, the IESG or the IAB. >=20 > In this concrete case, Abdussalam doesn't like the choice of TCP in = DLEP. I think we all understand that - but that's not actionable. The WG = needs precise details, reasons, source materials and technical arguments = to work with. >=20 > Once the we, the WG, has those, and only then, can action be taken, = either in form of a rebuttal or a changed design. It's Abdussalam's job = to provide those precise details, reasons, source materials and = technical arguments. The WG (nor the DLEP authors nor any design team) = can - nor should - try to guess what they may be. >=20 > My personal opinion is, that Stan and the others have done an = admirable job of *trying* to guess and try to provide an explanation and = a rebuttal. If they have failed to do so to Abdussalam's satisfaction, = then it's *not* their fault - it's because they do not have precise = details, reasons, source materials and technical arguments to work with = and rebut (or take action on). >=20 > I am 200% sure that if Abdussalam (or anyone else) do provides such = details, reasons, source materials and technical arguments, then these = matters will get the attentive ears of the authors and design team. If = not, then - and only then - is there a case to make to the WG or to the = ADs or the IESG or the IAB. >=20 > Until then, or absent that, there's little point in continuing this = discussion since there's no chance of making constructive progress. >=20 > Best, >=20 > Thomas >=20 > Sent from my iPad >=20 >> On 4 mars 2014, at 17:13, "Stan Ratliff (sratliff)" = wrote: >>=20 >> All, >>=20 >> I also note that Martin Duke wound up contributing quite a bit to the = design team effort; I do not recall any dissent from him at the time of = the 05 draft. >>=20 >> Now to address another couple of AB's comments: >>>>=20 >>>> Usually, the DT should report why TCP and not UDP, and IMHO, WG = still did not confirm its decision. >>=20 >> I'm not entirely sure what you mean here. The MANET WG has pretty = much been, for as long as I've been involved, a group where (1) first an = author (or a group of authors) submits a draft, and then (2) the WG = comments (or 'confirms') that iteration of the draft. The Design Team = acted in the role of "a really interested and active subset of the = working group that committed to additional effort in order to enlighten = the authors, and thereby, hopefully proceed the draft through an = iteration or two faster than it has been going". The design team effort = (along with that of the co-authors) has produced DLEP-05. Having the WG = 'confirm' (or discuss) the 05 draft is what is happening right now. >>=20 >>=20 >>>> Your reasons does not include any performance issue comparing both = transports or comparing both docs draft-04 and draft-05. >>=20 >> We've tried to explain on multiple occasions - there are *no* = performance considerations. None. There are *no* packet loss = considerations. None. This is because the protocol is completely bounded = on a local Ethernet segment between a router and an "external modem". = This is also because the protocol does not, in any way, shape, or form, = touch the data plane. Data packets through the modem based network flow = *exactly* as they would without DLEP running - that is, a packet would = egress the router's Ethernet interface, be picked up by the external = modem, and then transmitted over-the-air to a receiving station. So = performance was considered, and declared to be a non-issue due to the = design and implementation of the protocol. Which means we're back to = Shawn's enumerated list below on why a TCP-based implementation is = actually simpler than a UDP-based implementation. Yes, the ACKs flow, = but they are TCP ACKs. Not something the DLEP protocol has to take into = account, process, etc et >> c. >>=20 >> Long story short - I'm in agreement with Shawn. So far, I haven't = seen any technical justification for reconsidering the move to TCP. AB, = you said: >>>>=20 >>>> My concerns are DLEP speed, overhead, and management. >>=20 >> I share those concerns. I just don't see how a move to TCP adversely = impacts them. You'll need to provide more information to enlighten me. >>=20 >> Regards, >> Stan >>=20 >>=20 >>=20 >> On Mar 4, 2014, at 10:52 AM, Shawn Jury >> wrote: >>=20 >>> AB, >>>=20 >>> As a co-author of the draft, there were many discussions prior to = submission on UDP vs TCP. Our decision of UDP was because we truly = believed this paragraph from the draft (which stated UDP prior to -05): >>>=20 >>> This document specifies an implementation of the DLEP messages and >>> data items running over the TCP transport, utilizing a well-known = TCP >>> Port number. It is assumed that DLEP running over other transport >>> mechanisms would be documented separately. >>>=20 >>> If there are situations where another transport protocols would be = better, then an extension could be written (or whatever the best = practice is for IETF drafts in this case). >>>=20 >>> Based upon what I read in the old messages (to refresh my memory), = there is just as much push for TCP as there was for UDP. IMHO, there was = more for TCP. You even linked a message where Teco was pushing for TCP = in your reply to me. >>>=20 >>> I've spent the better part of the last 8 years working with = different radio vendors on a way to get a protocol like this to work. = Not once did anyone ever complain about which transport protocol was = being used, nor did they ever talk about the connection between the = router/radio being limited. All the issues I have run into have been = with radios that have a slightly different implementation and doesn't = quite fit into a specific area (as recent as yesterday). Of course, = there are also so many waiting on the final draft from this working = group, I'm wondering if they will ever get to implement anything. >>>=20 >>> Please, continue pushing for justification on the transport protocol = as I'm sure you believe it is very important. >>>=20 >>> Thanks for your discussion. I'll sit back again and watch as this = becomes more and more of a career path :) >>>=20 >>> Shawn >>>=20 >>>> On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: >>>>=20 >>>> Hi Shawn, >>>>=20 >>>> Usually, the DT should report why TCP and not UDP, and IMHO, WG = still did not confirm its decision. Your reasons does not include any = performance issue comparing both transports or comparing both docs = draft-04 and draft-05. >>>>=20 >>>> My concerns are DLEP speed, overhead, and management. The beauty of = draft-04 is that it's link speed between devices should not always be = with high capacity, but for draft-05 there should be including that in = the draft to show its performance limits. Usually, you see thread = subject DLEP with TCP in last Aug, I am not alone wanting UDP (don't = forget authors started with UDP, Duke and Juliusz) regarding change = problems see point below, which made me say IMHO discussion was not = enough. >>>=20 >>>>=20 >>>> http://www.ietf.org/mail-archive/web/manet/current/msg15566.html >>>>=20 >>>> http://www.ietf.org/mail-archive/web/manet/current/msg15568.html >>>>=20 >>>> I hope that answers some of my thoughts. >>>> Regards >>>> AB >>>>=20 >>>> On Tuesday, March 4, 2014, Shawn Jury wrote: >>>> Hello AB, >>>>=20 >>>> Here we are again with you stating you dislike something, but not = telling us why you dislike it. You are just asking us to explain the = change to you. >>>>=20 >>>> If I say I like I mean I want or think is better, not totally sure. >>>>=20 >>>> I'll tell you that I wasn't part of the DT for DLEP, but I can see = the benefit of using TCP. Just some of the benefits: >>>>=20 >>>> * No need to recreate a complex state machine in DLEP that would = mimic TCP's behavior. >>>> * TCP is an already existing reliable transport protocol (readily = available). >>>> * Simplifies the overall implementation of the protocol. >>>> * Addresses earlier concerns about how DLEP was a "stop and wait" = protocol. >>>>=20 >>>> With that said, please explain why you do not like TCP for DLEP. = You seem to agree that a reliable transport is needed (ACKs and SeqNums = in -04), but just state that you don't like TCP and are in favor of = creating a protocol that "gives more flexibility, more independent and = more performance". TCP meets the needs that are required for our = purpose. >>>>=20 >>>> Unless you can produce a valid argument of why you don't like it, = I'm at a point where I'll just attribute your objections to white noise = as there doesn't seem to be any substance behind them, nor much support = from others on the list. >>>>=20 >>>> If you have a technical argument of why we shouldn't use TCP, = please send it to the list. >>>>=20 >>>> Shawn >>>>=20 >>>>> On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>> Hi John, >>>>>=20 >>>>> So you mean low possibility of loss, so why not UDP? that is not >>>>> answered, the only answer was because DLEP is stateful and it has = ACK >>>>> messages. So why not DLEP-04 while I am using realiable PHY as you >>>>> describe. In addition, even if there are reliability in PHY there = may >>>>> be losses in other layers under MANET applicabilities, so that is = why >>>>> DLEP-04 has ACKs, which I agree, but don't understand the TCP >>>>> importance in such communication scenarios. >>>>>=20 >>>>> AB >>>=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 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Mar 4 10:11:12 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5981A0227 for ; Tue, 4 Mar 2014 10:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBfsOJ9bnp_t for ; Tue, 4 Mar 2014 10:11:03 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id A39A31A0284 for ; Tue, 4 Mar 2014 10:10:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B468024096A; Tue, 4 Mar 2014 10:10:54 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D2AB72408BF; Tue, 4 Mar 2014 10:10:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: <3CDC0647-052A-44E6-B8E9-D67864260A3D@gmail.com> Date: Tue, 4 Mar 2014 19:10:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86ED9DD3-3346-4000-88F9-21D49CD695FD@thomasclausen.org> References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> <47285CC7-BFFF-4BC0-9B58-5DB582D35BA0@cisco.com> <38A5475DE83986499AEACD2CFAFC3F98FA6C514B@tss-server1.home.tropicalstormsoftware.com> <3CDC0647-052A-44E6-B8E9-D67864260A3D@gmail.com> To: Christopher Dearlove Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_OY0p0Ip1iyVz7LOaW-u2KnUqGo Cc: MANET IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:11:09 -0000 > On 4 mars 2014, at 18:36, Christopher Dearlove wrote: >=20 > I'm not sure I've ever seen a forked protocol. There are cases like OSPF w= here v3 has not replaced v2 but lives alongside it. But they have an importa= nt difference, as well as being many years apart. >=20 > However two separate protocols alongside each other doing the same thing b= oth trying to get through the IESG? I think most of us who have pushed proto= cols through the process would estimate the chances of success for both as c= lose enough to zero to consider it that. And it would both reduce the probab= ility and increase the delay of one. Which makes it about the most unattract= ive proposition that could be offered to the authors. >=20 There is that process issue, and Chris is entirely right about that.=20 If the WG decides to go down that path, then we are back with needing to mak= e the case to the IESG as to why we need two protocols for the same thing...= and for that, were back at needing sufficiently precise details, reasons, so= urce material, and technical arguments that the IESG (who, generally speakin= g, are a bunch of smart - but overworked - cookies) will understand and agre= e with. Thomas > -- =20 > Christopher Dearlove > christopher.dearlove@gmail.com >=20 >> On 4 Mar 2014, at 17:23, Rick Taylor wro= te: >>=20 >> Thank you Thomas, >>=20 >> I was going to bite and had a long reply ready, but I will hold off as I t= hink you may have summarized the difficulties some of us are having second g= uessing AB's objection. >>=20 >> I do not however think it is sensible to attempt a fork of DLEP-04 result= ing in DLEP-05-TCP and DLEP-04-UDP. Because:=20 >>=20 >> A) In the considered opinion of the authors, the design team, and the maj= ority of the active participants of the WG, simplifying the protocol by usin= g TCP will ease the development of many implementations, increasing it's lik= elyhood of becoming a popular standard. >>=20 >> B) The authors and end-user community only have time and inclination to i= mplement 1 standard. >>=20 >> AB, if you are in London, please come and find me after the MANET WG meet= ing tomorrow and I will try to explain why the authors and DT decided on TCP= . I believe you may have some gaps in your understanding that I am perfectl= y happy to try to fill. >>=20 >> Also, may I kindly remind you that it is the authors who are presenting t= heir proposal for the DLEP protocol to the MANET WG. They are not beholden t= o the members of the DT, or WG, or the IETF. We may raise concerns, but thi= s is a forum for constructive criticism, and there is nothing to prevent Sta= n et.al. from picking up their protocol and going home with it. >>=20 >> Rick Taylor >>=20 >> Who has bitten after all... >>=20 >> ________________________________________ >> From: manet [manet-bounces@ietf.org] on behalf of Thomas Heide Clausen [i= etf@thomasclausen.org] >> Sent: 04 March 2014 17:05 >> To: Stan Ratliff (sratliff); Abdussalam Baryun >> Cc: MANET IETF >> Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP D= T summary >>=20 >> To abuse two metaphors at once: I have no horses in this fight....but let= me stick my nose out anyways, and start with an anecdote.... >>=20 >> I had some concerns with the initial design of an early version of DLEP, s= pecifically how it used in a way I thought wrong. I explained in great details to t= he authors why I thought it wrong: my concerns, my reasoning, and the (unint= ended) consequences that I saw with that element of the DLEP design. The aut= hors went away, came back after having thought it through, with an updated d= esign that satisfied me. Not the design that *I* would have made, mind you, b= ut a design that satisfied my concerns as I had articulated them. That's rea= lly all anyone can ask. >>=20 >> Now, the authors could do that *only* because they were fed sufficiently p= recise details, reasons, source material, and technical arguments that they h= ad something to work with, and a reasonable expectation that they'd be able t= o estimate if the outcome would be satisfying. I'm 200% sure that had I been= wrong on this issue, they would have come back with a - just as precise (an= d polite) - rebuttal, which also would have satisfied me by educating me as t= o how I was wrong. Again, for a rebuttal, they would have needed *precise*, d= etailed *technical* arguments from me to work with and rebut. >>=20 >> Had I just said "I don't like your design", I'd simply have been ignored -= or asked to "put up the arguments - or shut up". And, reasonably so, I mig= ht add. >>=20 >> If *I* dislike something, then it's *my* job to identify what and why, an= d articulate that in ways that are actionable by those who I ask to take act= ion. This may be the authors, and by the WG - or (if taking things further) b= y the chairs, AD, the IESG or the IAB. >>=20 >> In this concrete case, Abdussalam doesn't like the choice of TCP in DLEP.= I think we all understand that - but that's not actionable. The WG needs pr= ecise details, reasons, source materials and technical arguments to work wit= h. >>=20 >> Once the we, the WG, has those, and only then, can action be taken, eithe= r in form of a rebuttal or a changed design. It's Abdussalam's job to provid= e those precise details, reasons, source materials and technical arguments. T= he WG (nor the DLEP authors nor any design team) can - nor should - try to g= uess what they may be. >>=20 >> My personal opinion is, that Stan and the others have done an admirable j= ob of *trying* to guess and try to provide an explanation and a rebuttal. If= they have failed to do so to Abdussalam's satisfaction, then it's *not* th= eir fault - it's because they do not have precise details, reasons, source m= aterials and technical arguments to work with and rebut (or take action on).= >>=20 >> I am 200% sure that if Abdussalam (or anyone else) do provides such detai= ls, reasons, source materials and technical arguments, then these matters wi= ll get the attentive ears of the authors and design team. If not, then - and= only then - is there a case to make to the WG or to the ADs or the IESG or t= he IAB. >>=20 >> Until then, or absent that, there's little point in continuing this discu= ssion since there's no chance of making constructive progress. >>=20 >> Best, >>=20 >> Thomas >>=20 >> Sent from my iPad >>=20 >>> On 4 mars 2014, at 17:13, "Stan Ratliff (sratliff)" = wrote: >>>=20 >>> All, >>>=20 >>> I also note that Martin Duke wound up contributing quite a bit to the de= sign team effort; I do not recall any dissent from him at the time of the 05= draft. >>>=20 >>> Now to address another couple of AB's comments: >>>>>=20 >>>>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still d= id not confirm its decision. >>>=20 >>> I'm not entirely sure what you mean here. The MANET WG has pretty much b= een, for as long as I've been involved, a group where (1) first an author (o= r a group of authors) submits a draft, and then (2) the WG comments (or 'con= firms') that iteration of the draft. The Design Team acted in the role of "a= really interested and active subset of the working group that committed to a= dditional effort in order to enlighten the authors, and thereby, hopefully p= roceed the draft through an iteration or two faster than it has been going".= The design team effort (along with that of the co-authors) has produced DLE= P-05. Having the WG 'confirm' (or discuss) the 05 draft is what is happening= right now. >>>=20 >>>=20 >>>>> Your reasons does not include any performance issue comparing both tra= nsports or comparing both docs draft-04 and draft-05. >>>=20 >>> We've tried to explain on multiple occasions - there are *no* performanc= e considerations. None. There are *no* packet loss considerations. None. Thi= s is because the protocol is completely bounded on a local Ethernet segment b= etween a router and an "external modem". This is also because the protocol d= oes not, in any way, shape, or form, touch the data plane. Data packets thro= ugh the modem based network flow *exactly* as they would without DLEP runnin= g - that is, a packet would egress the router's Ethernet interface, be picke= d up by the external modem, and then transmitted over-the-air to a receiving= station. So performance was considered, and declared to be a non-issue due t= o the design and implementation of the protocol. Which means we're back to S= hawn's enumerated list below on why a TCP-based implementation is actually s= impler than a UDP-based implementation. Yes, the ACKs flow, but they are TCP= ACKs. Not something the DLEP protocol has to take into account, process, et= c et >>> c. >>>=20 >>> Long story short - I'm in agreement with Shawn. So far, I haven't seen a= ny technical justification for reconsidering the move to TCP. AB, you said: >>>>>=20 >>>>> My concerns are DLEP speed, overhead, and management. >>>=20 >>> I share those concerns. I just don't see how a move to TCP adversely imp= acts them. You'll need to provide more information to enlighten me. >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>=20 >>> On Mar 4, 2014, at 10:52 AM, Shawn Jury >>> wrote: >>>=20 >>>> AB, >>>>=20 >>>> As a co-author of the draft, there were many discussions prior to submi= ssion on UDP vs TCP. Our decision of UDP was because we truly believed thi= s paragraph from the draft (which stated UDP prior to -05): >>>>=20 >>>> This document specifies an implementation of the DLEP messages and >>>> data items running over the TCP transport, utilizing a well-known TCP >>>> Port number. It is assumed that DLEP running over other transport >>>> mechanisms would be documented separately. >>>>=20 >>>> If there are situations where another transport protocols would be bett= er, then an extension could be written (or whatever the best practice is for= IETF drafts in this case). >>>>=20 >>>> Based upon what I read in the old messages (to refresh my memory), ther= e is just as much push for TCP as there was for UDP. IMHO, there was more fo= r TCP. You even linked a message where Teco was pushing for TCP in your rep= ly to me. >>>>=20 >>>> I've spent the better part of the last 8 years working with different r= adio vendors on a way to get a protocol like this to work. Not once did any= one ever complain about which transport protocol was being used, nor did the= y ever talk about the connection between the router/radio being limited. Al= l the issues I have run into have been with radios that have a slightly diff= erent implementation and doesn't quite fit into a specific area (as recent a= s yesterday). Of course, there are also so many waiting on the final draft f= rom this working group, I'm wondering if they will ever get to implement any= thing. >>>>=20 >>>> Please, continue pushing for justification on the transport protocol as= I'm sure you believe it is very important. >>>>=20 >>>> Thanks for your discussion. I'll sit back again and watch as this beco= mes more and more of a career path :) >>>>=20 >>>> Shawn >>>>=20 >>>>> On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>> Hi Shawn, >>>>>=20 >>>>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still d= id not confirm its decision. Your reasons does not include any performance i= ssue comparing both transports or comparing both docs draft-04 and draft-05.= >>>>>=20 >>>>> My concerns are DLEP speed, overhead, and management. The beauty of dr= aft-04 is that it's link speed between devices should not always be with hig= h capacity, but for draft-05 there should be including that in the draft to s= how its performance limits. Usually, you see thread subject DLEP with TCP in= last Aug, I am not alone wanting UDP (don't forget authors started with UDP= , Duke and Juliusz) regarding change problems see point below, which made me= say IMHO discussion was not enough. >>>>=20 >>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/manet/current/msg15566.html >>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/manet/current/msg15568.html >>>>>=20 >>>>> I hope that answers some of my thoughts. >>>>> Regards >>>>> AB >>>>>=20 >>>>> On Tuesday, March 4, 2014, Shawn Jury wrote: >>>>> Hello AB, >>>>>=20 >>>>> Here we are again with you stating you dislike something, but not tel= ling us why you dislike it. You are just asking us to explain the change to= you. >>>>>=20 >>>>> If I say I like I mean I want or think is better, not totally sure. >>>>>=20 >>>>> I'll tell you that I wasn't part of the DT for DLEP, but I can see the= benefit of using TCP. Just some of the benefits: >>>>>=20 >>>>> * No need to recreate a complex state machine in DLEP that would mimi= c TCP's behavior. >>>>> * TCP is an already existing reliable transport protocol (readily ava= ilable). >>>>> * Simplifies the overall implementation of the protocol. >>>>> * Addresses earlier concerns about how DLEP was a "stop and wait" pro= tocol. >>>>>=20 >>>>> With that said, please explain why you do not like TCP for DLEP. You s= eem to agree that a reliable transport is needed (ACKs and SeqNums in -04), b= ut just state that you don't like TCP and are in favor of creating a protoco= l that "gives more flexibility, more independent and more performance". TCP= meets the needs that are required for our purpose. >>>>>=20 >>>>> Unless you can produce a valid argument of why you don't like it, I'm a= t a point where I'll just attribute your objections to white noise as there d= oesn't seem to be any substance behind them, nor much support from others on= the list. >>>>>=20 >>>>> If you have a technical argument of why we shouldn't use TCP, please s= end it to the list. >>>>>=20 >>>>> Shawn >>>>>=20 >>>>>> On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: >>>>>>=20 >>>>>> Hi John, >>>>>>=20 >>>>>> So you mean low possibility of loss, so why not UDP? that is not >>>>>> answered, the only answer was because DLEP is stateful and it has ACK= >>>>>> messages. So why not DLEP-04 while I am using realiable PHY as you >>>>>> describe. In addition, even if there are reliability in PHY there may= >>>>>> be losses in other layers under MANET applicabilities, so that is why= >>>>>> DLEP-04 has ACKs, which I agree, but don't understand the TCP >>>>>> importance in such communication scenarios. >>>>>>=20 >>>>>> AB >>>>=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 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From nobody Tue Mar 4 10:11:56 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C571A02FF for ; Tue, 4 Mar 2014 10:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZpRpRZyGpPa for ; Tue, 4 Mar 2014 10:11:29 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA421A02D5 for ; Tue, 4 Mar 2014 10:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15229; q=dns/txt; s=iport; t=1393956680; x=1395166280; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=igT8wrVBafeNd5V+Aai6uVhbqAsP2hhK6I/aIQpvAVk=; b=e2G5MFxQTAokqaBLvY+gHlDzBcBENzIEqpkmQgiGDzjLsEgQ1eF53cZa m197njFR8dH/6Nr07DxYDCjawK6cvZMLaJxdvSi2LJlXn4VRPzxKdukT8 ehCyZs33+YwBvA4IXxAWJPnTOP13pDpKG/QqLJ0TCS5TQiFJdqW50PI4H Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABIWFlOtJXG9/2dsb2JhbABQCoMGO1eodZd4gR4WdIIlAQEBAwEBAQFrCwULAgEIDgMEAQEBFRkhBgsdCAIEDgUJC4dRAwkIDcYEDYZ0F4w8gTkEBAMBARwzAgUGBIMagRQElFGBfoFtjGOFSIMtgWgHAhci X-IronPort-AV: E=Sophos;i="4.97,586,1389744000"; d="scan'208";a="24852278" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-1.cisco.com with ESMTP; 04 Mar 2014 18:11:19 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s24IBJmU028831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 18:11:19 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 12:11:19 -0600 From: "Stan Ratliff (sratliff)" To: Joe Macker Thread-Topic: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary Thread-Index: AQHPN8wHNL8xEMLiMUyz8wcgovaR4JrRke0AgAAEwoCAAAiSAA== Date: Tue, 4 Mar 2014 18:11:18 +0000 Message-ID: References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> <47285CC7-BFFF-4BC0-9B58-5DB582D35BA0@cisco.com>, <38A5475DE83986499AEACD2CFAFC3F98FA6C514B@tss-server1.home.tropicalstormsoftware.com> <67973D50-B9EA-4BA2-9A8F-F901CF1928AA@gmail.com> In-Reply-To: <67973D50-B9EA-4BA2-9A8F-F901CF1928AA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.216.24] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7024E829E9732F43937437AC64A68198@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/N1esqULRBvhdyAZJxJ3jvm6yfEM Cc: MANET IETF Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:11:44 -0000 =85 I can't help it=85. > I am not a fan of forking off a separate specification at this point.=20 I'll be a bit stronger: It would be a forking mess.=20 There, I said it.=20 Regards, Stan On Mar 4, 2014, at 12:40 PM, Joe Macker wrote: > Thank you all for taking the time to provide your observations/opinions. >=20 > In my observation as co-chair there was a strong consensus among the deve= lopers and authors to go with TCP as the requirement in the present instant= iation of the DLEP specification. As many have mentioned this is not an ove= r-the-air protocol. This decision was reported out at the last Vancouver W= G meeting in slides and minutes in a clear manner you can go back and check= . The authors have provided rationale for their decision. >=20 > Moving forward with one specification is my strong recommendation. I am n= ot a fan of forking off a separate specification at this point. I think th= e WG and the DT is beyond this design point. >=20 > -Joe=20 >=20 > On Mar 4, 2014, at 12:23 PM, Rick Taylor = wrote: >=20 >> Thank you Thomas, >>=20 >> I was going to bite and had a long reply ready, but I will hold off as I= think you may have summarized the difficulties some of us are having secon= d guessing AB's objection. >>=20 >> I do not however think it is sensible to attempt a fork of DLEP-04 resul= ting in DLEP-05-TCP and DLEP-04-UDP. Because:=20 >>=20 >> A) In the considered opinion of the authors, the design team, and the ma= jority of the active participants of the WG, simplifying the protocol by us= ing TCP will ease the development of many implementations, increasing it's = likelyhood of becoming a popular standard. >>=20 >> B) The authors and end-user community only have time and inclination to = implement 1 standard. >>=20 >> AB, if you are in London, please come and find me after the MANET WG mee= ting tomorrow and I will try to explain why the authors and DT decided on T= CP. I believe you may have some gaps in your understanding that I am perfe= ctly happy to try to fill. >>=20 >> Also, may I kindly remind you that it is the authors who are presenting = their proposal for the DLEP protocol to the MANET WG. They are not beholde= n to the members of the DT, or WG, or the IETF. We may raise concerns, but= this is a forum for constructive criticism, and there is nothing to preven= t Stan et.al. from picking up their protocol and going home with it. >>=20 >> Rick Taylor >>=20 >> Who has bitten after all... >>=20 >> ________________________________________ >> From: manet [manet-bounces@ietf.org] on behalf of Thomas Heide Clausen [= ietf@thomasclausen.org] >> Sent: 04 March 2014 17:05 >> To: Stan Ratliff (sratliff); Abdussalam Baryun >> Cc: MANET IETF >> Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP= DT summary >>=20 >> To abuse two metaphors at once: I have no horses in this fight....but le= t me stick my nose out anyways, and start with an anecdote.... >>=20 >> I had some concerns with the initial design of an early version of DLEP,= specifically how it used in a way I thought wrong. I explained in great details = to the authors why I thought it wrong: my concerns, my reasoning, and the (= unintended) consequences that I saw with that element of the DLEP design. T= he authors went away, came back after having thought it through, with an up= dated design that satisfied me. Not the design that *I* would have made, mi= nd you, but a design that satisfied my concerns as I had articulated them. = That's really all anyone can ask. >>=20 >> Now, the authors could do that *only* because they were fed sufficiently= precise details, reasons, source material, and technical arguments that th= ey had something to work with, and a reasonable expectation that they'd be = able to estimate if the outcome would be satisfying. I'm 200% sure that had= I been wrong on this issue, they would have come back with a - just as pre= cise (and polite) - rebuttal, which also would have satisfied me by educati= ng me as to how I was wrong. Again, for a rebuttal, they would have needed = *precise*, detailed *technical* arguments from me to work with and rebut. >>=20 >> Had I just said "I don't like your design", I'd simply have been ignored= - or asked to "put up the arguments - or shut up". And, reasonably so, I = might add. >>=20 >> If *I* dislike something, then it's *my* job to identify what and why, a= nd articulate that in ways that are actionable by those who I ask to take a= ction. This may be the authors, and by the WG - or (if taking things furthe= r) by the chairs, AD, the IESG or the IAB. >>=20 >> In this concrete case, Abdussalam doesn't like the choice of TCP in DLEP= . I think we all understand that - but that's not actionable. The WG needs = precise details, reasons, source materials and technical arguments to work = with. >>=20 >> Once the we, the WG, has those, and only then, can action be taken, eith= er in form of a rebuttal or a changed design. It's Abdussalam's job to prov= ide those precise details, reasons, source materials and technical argument= s. The WG (nor the DLEP authors nor any design team) can - nor should - try= to guess what they may be. >>=20 >> My personal opinion is, that Stan and the others have done an admirable = job of *trying* to guess and try to provide an explanation and a rebuttal. = If they have failed to do so to Abdussalam's satisfaction, then it's *not*= their fault - it's because they do not have precise details, reasons, sour= ce materials and technical arguments to work with and rebut (or take action= on). >>=20 >> I am 200% sure that if Abdussalam (or anyone else) do provides such deta= ils, reasons, source materials and technical arguments, then these matters = will get the attentive ears of the authors and design team. If not, then - = and only then - is there a case to make to the WG or to the ADs or the IESG= or the IAB. >>=20 >> Until then, or absent that, there's little point in continuing this disc= ussion since there's no chance of making constructive progress. >>=20 >> Best, >>=20 >> Thomas >>=20 >> Sent from my iPad >>=20 >>> On 4 mars 2014, at 17:13, "Stan Ratliff (sratliff)" wrote: >>>=20 >>> All, >>>=20 >>> I also note that Martin Duke wound up contributing quite a bit to the d= esign team effort; I do not recall any dissent from him at the time of the = 05 draft. >>>=20 >>> Now to address another couple of AB's comments: >>>>>=20 >>>>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still= did not confirm its decision. >>>=20 >>> I'm not entirely sure what you mean here. The MANET WG has pretty much = been, for as long as I've been involved, a group where (1) first an author = (or a group of authors) submits a draft, and then (2) the WG comments (or '= confirms') that iteration of the draft. The Design Team acted in the role o= f "a really interested and active subset of the working group that committe= d to additional effort in order to enlighten the authors, and thereby, hope= fully proceed the draft through an iteration or two faster than it has been= going". The design team effort (along with that of the co-authors) has pro= duced DLEP-05. Having the WG 'confirm' (or discuss) the 05 draft is what is= happening right now. >>>=20 >>>=20 >>>>> Your reasons does not include any performance issue comparing both tr= ansports or comparing both docs draft-04 and draft-05. >>>=20 >>> We've tried to explain on multiple occasions - there are *no* performan= ce considerations. None. There are *no* packet loss considerations. None. T= his is because the protocol is completely bounded on a local Ethernet segme= nt between a router and an "external modem". This is also because the proto= col does not, in any way, shape, or form, touch the data plane. Data packet= s through the modem based network flow *exactly* as they would without DLEP= running - that is, a packet would egress the router's Ethernet interface, = be picked up by the external modem, and then transmitted over-the-air to a = receiving station. So performance was considered, and declared to be a non-= issue due to the design and implementation of the protocol. Which means we'= re back to Shawn's enumerated list below on why a TCP-based implementation = is actually simpler than a UDP-based implementation. Yes, the ACKs flow, bu= t they are TCP ACKs. Not something the DLEP protocol has to take into accou= nt, process, etc et >>> c. >>>=20 >>> Long story short - I'm in agreement with Shawn. So far, I haven't seen = any technical justification for reconsidering the move to TCP. AB, you said= : >>>>>=20 >>>>> My concerns are DLEP speed, overhead, and management. >>>=20 >>> I share those concerns. I just don't see how a move to TCP adversely im= pacts them. You'll need to provide more information to enlighten me. >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>=20 >>> On Mar 4, 2014, at 10:52 AM, Shawn Jury >>> wrote: >>>=20 >>>> AB, >>>>=20 >>>> As a co-author of the draft, there were many discussions prior to subm= ission on UDP vs TCP. Our decision of UDP was because we truly believed t= his paragraph from the draft (which stated UDP prior to -05): >>>>=20 >>>> This document specifies an implementation of the DLEP messages and >>>> data items running over the TCP transport, utilizing a well-known TCP >>>> Port number. It is assumed that DLEP running over other transport >>>> mechanisms would be documented separately. >>>>=20 >>>> If there are situations where another transport protocols would be bet= ter, then an extension could be written (or whatever the best practice is f= or IETF drafts in this case). >>>>=20 >>>> Based upon what I read in the old messages (to refresh my memory), the= re is just as much push for TCP as there was for UDP. IMHO, there was more = for TCP. You even linked a message where Teco was pushing for TCP in your = reply to me. >>>>=20 >>>> I've spent the better part of the last 8 years working with different = radio vendors on a way to get a protocol like this to work. Not once did a= nyone ever complain about which transport protocol was being used, nor did = they ever talk about the connection between the router/radio being limited.= All the issues I have run into have been with radios that have a slightly= different implementation and doesn't quite fit into a specific area (as re= cent as yesterday). Of course, there are also so many waiting on the final= draft from this working group, I'm wondering if they will ever get to impl= ement anything. >>>>=20 >>>> Please, continue pushing for justification on the transport protocol a= s I'm sure you believe it is very important. >>>>=20 >>>> Thanks for your discussion. I'll sit back again and watch as this bec= omes more and more of a career path :) >>>>=20 >>>> Shawn >>>>=20 >>>>> On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>> Hi Shawn, >>>>>=20 >>>>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still= did not confirm its decision. Your reasons does not include any performanc= e issue comparing both transports or comparing both docs draft-04 and draft= -05. >>>>>=20 >>>>> My concerns are DLEP speed, overhead, and management. The beauty of d= raft-04 is that it's link speed between devices should not always be with h= igh capacity, but for draft-05 there should be including that in the draft = to show its performance limits. Usually, you see thread subject DLEP with T= CP in last Aug, I am not alone wanting UDP (don't forget authors started wi= th UDP, Duke and Juliusz) regarding change problems see point below, which = made me say IMHO discussion was not enough. >>>>=20 >>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/manet/current/msg15566.html >>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/manet/current/msg15568.html >>>>>=20 >>>>> I hope that answers some of my thoughts. >>>>> Regards >>>>> AB >>>>>=20 >>>>> On Tuesday, March 4, 2014, Shawn Jury wrote: >>>>> Hello AB, >>>>>=20 >>>>> Here we are again with you stating you dislike something, but not te= lling us why you dislike it. You are just asking us to explain the change = to you. >>>>>=20 >>>>> If I say I like I mean I want or think is better, not totally sure. >>>>>=20 >>>>> I'll tell you that I wasn't part of the DT for DLEP, but I can see th= e benefit of using TCP. Just some of the benefits: >>>>>=20 >>>>> * No need to recreate a complex state machine in DLEP that would mim= ic TCP's behavior. >>>>> * TCP is an already existing reliable transport protocol (readily av= ailable). >>>>> * Simplifies the overall implementation of the protocol. >>>>> * Addresses earlier concerns about how DLEP was a "stop and wait" pr= otocol. >>>>>=20 >>>>> With that said, please explain why you do not like TCP for DLEP. You= seem to agree that a reliable transport is needed (ACKs and SeqNums in -04= ), but just state that you don't like TCP and are in favor of creating a pr= otocol that "gives more flexibility, more independent and more performance"= . TCP meets the needs that are required for our purpose. >>>>>=20 >>>>> Unless you can produce a valid argument of why you don't like it, I'm= at a point where I'll just attribute your objections to white noise as the= re doesn't seem to be any substance behind them, nor much support from othe= rs on the list. >>>>>=20 >>>>> If you have a technical argument of why we shouldn't use TCP, please = send it to the list. >>>>>=20 >>>>> Shawn >>>>>=20 >>>>>> On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: >>>>>>=20 >>>>>> Hi John, >>>>>>=20 >>>>>> So you mean low possibility of loss, so why not UDP? that is not >>>>>> answered, the only answer was because DLEP is stateful and it has AC= K >>>>>> messages. So why not DLEP-04 while I am using realiable PHY as you >>>>>> describe. In addition, even if there are reliability in PHY there ma= y >>>>>> be losses in other layers under MANET applicabilities, so that is wh= y >>>>>> DLEP-04 has ACKs, which I agree, but don't understand the TCP >>>>>> importance in such communication scenarios. >>>>>>=20 >>>>>> AB >>>>=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 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From nobody Tue Mar 4 10:31:42 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD1E1A02D3 for ; Tue, 4 Mar 2014 10:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP3LAsQWwKFx for ; Tue, 4 Mar 2014 10:31:34 -0800 (PST) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A8EE51A02EE for ; Tue, 4 Mar 2014 10:31:34 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id x13so5708498qcv.19 for ; Tue, 04 Mar 2014 10:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FytTVlISWjP7G0fj8dNpj+qxhkXTcVIwb0jZE6l1K9g=; b=rMISEGHXJWgnX4xtMzWlH9g9sLQ/hk5UF32kOalt2EJsBZmzsv7jyZpqTy5betiUaM 6KWh5aRDH2BwPgm05eIrPn7HDZGDokWiGUDLtj9VrycprtfWXXfhKk6UHGjh4cB/owfD EYS9LG2LMEM+Jx669XwIybjyf+xm8Qlhx8MlWQqrbtpzI8x+rXhBoBi7DeX2KCIXuIhZ s7/fkmBYuMZ05Qbnc30MYF8u5dn3Hkzshh2/6VO+jHxcc91IzNcIuT16/oR2zhs5O3GU PVF37WAklPu/jlff3YYD4sUvvcHJWrCFwX11obVEh7znfZ9CSCpFmTTRmWqG7DpYuKkf EzdA== X-Received: by 10.140.94.113 with SMTP id f104mr1398360qge.64.1393957408785; Tue, 04 Mar 2014 10:23:28 -0800 (PST) Received: from vpn217206.nrl.navy.mil (vpn217206.nrl.navy.mil. [132.250.217.206]) by mx.google.com with ESMTPSA id y71sm21059334qgd.3.2014.03.04.10.23.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 10:23:28 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Joe Macker In-Reply-To: Date: Tue, 4 Mar 2014 13:23:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2E063D02-7C60-489B-BD25-9D29E3CF1E7F@gmail.com> References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> <47285CC7-BFFF-4BC0-9B58-5DB582D35BA0@cisco.com>, <38A5475DE83986499AEACD2CFAFC3F98FA6C514B@tss-server1.home.tropicalstormsoftware.com> <67973D50-B9EA-4BA2-9A8F-F901CF1928AA@gmail.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/O5btStgf2dBUMjPqat-Po0F0e4Q Cc: MANET IETF Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:31:38 -0000 Yeah good one Stan..;-) Let me be clearer on two points: (1) I will not support any such proposal to work on two documents at = this point!=20 (2) Also I am satisfied the authors and the DT have historically = discussed at length the issues and decided on a consensus strategy. We will move forward with one specification. -Joe On Mar 4, 2014, at 1:11 PM, Stan Ratliff (sratliff) = wrote: > =85 I can't help it=85. >=20 >> I am not a fan of forking off a separate specification at this point.=20= >=20 > I'll be a bit stronger: It would be a forking mess.=20 >=20 > There, I said it.=20 >=20 > Regards, > Stan >=20 >=20 >=20 > On Mar 4, 2014, at 12:40 PM, Joe Macker wrote: >=20 >> Thank you all for taking the time to provide your = observations/opinions. >>=20 >> In my observation as co-chair there was a strong consensus among the = developers and authors to go with TCP as the requirement in the present = instantiation of the DLEP specification. As many have mentioned this is = not an over-the-air protocol. This decision was reported out at the = last Vancouver WG meeting in slides and minutes in a clear manner you = can go back and check. The authors have provided rationale for their = decision. >>=20 >> Moving forward with one specification is my strong recommendation. I = am not a fan of forking off a separate specification at this point. I = think the WG and the DT is beyond this design point. >>=20 >> -Joe=20 >>=20 >> On Mar 4, 2014, at 12:23 PM, Rick Taylor = wrote: >>=20 >>> Thank you Thomas, >>>=20 >>> I was going to bite and had a long reply ready, but I will hold off = as I think you may have summarized the difficulties some of us are = having second guessing AB's objection. >>>=20 >>> I do not however think it is sensible to attempt a fork of DLEP-04 = resulting in DLEP-05-TCP and DLEP-04-UDP. Because:=20 >>>=20 >>> A) In the considered opinion of the authors, the design team, and = the majority of the active participants of the WG, simplifying the = protocol by using TCP will ease the development of many implementations, = increasing it's likelyhood of becoming a popular standard. >>>=20 >>> B) The authors and end-user community only have time and inclination = to implement 1 standard. >>>=20 >>> AB, if you are in London, please come and find me after the MANET WG = meeting tomorrow and I will try to explain why the authors and DT = decided on TCP. I believe you may have some gaps in your understanding = that I am perfectly happy to try to fill. >>>=20 >>> Also, may I kindly remind you that it is the authors who are = presenting their proposal for the DLEP protocol to the MANET WG. They = are not beholden to the members of the DT, or WG, or the IETF. We may = raise concerns, but this is a forum for constructive criticism, and = there is nothing to prevent Stan et.al. from picking up their protocol = and going home with it. >>>=20 >>> Rick Taylor >>>=20 >>> Who has bitten after all... >>>=20 >>> ________________________________________ >>> From: manet [manet-bounces@ietf.org] on behalf of Thomas Heide = Clausen [ietf@thomasclausen.org] >>> Sent: 04 March 2014 17:05 >>> To: Stan Ratliff (sratliff); Abdussalam Baryun >>> Cc: MANET IETF >>> Subject: Re: [manet] DLEP performance with and without TCP (was Re: = DLEP DT summary >>>=20 >>> To abuse two metaphors at once: I have no horses in this = fight....but let me stick my nose out anyways, and start with an = anecdote.... >>>=20 >>> I had some concerns with the initial design of an early version of = DLEP, specifically how it used = in = a way I thought wrong. I explained in great details to the authors why I = thought it wrong: my concerns, my reasoning, and the (unintended) = consequences that I saw with that element of the DLEP design. The = authors went away, came back after having thought it through, with an = updated design that satisfied me. Not the design that *I* would have = made, mind you, but a design that satisfied my concerns as I had = articulated them. That's really all anyone can ask. >>>=20 >>> Now, the authors could do that *only* because they were fed = sufficiently precise details, reasons, source material, and technical = arguments that they had something to work with, and a reasonable = expectation that they'd be able to estimate if the outcome would be = satisfying. I'm 200% sure that had I been wrong on this issue, they = would have come back with a - just as precise (and polite) - rebuttal, = which also would have satisfied me by educating me as to how I was = wrong. Again, for a rebuttal, they would have needed *precise*, detailed = *technical* arguments from me to work with and rebut. >>>=20 >>> Had I just said "I don't like your design", I'd simply have been = ignored - or asked to "put up the arguments - or shut up". And, = reasonably so, I might add. >>>=20 >>> If *I* dislike something, then it's *my* job to identify what and = why, and articulate that in ways that are actionable by those who I ask = to take action. This may be the authors, and by the WG - or (if taking = things further) by the chairs, AD, the IESG or the IAB. >>>=20 >>> In this concrete case, Abdussalam doesn't like the choice of TCP in = DLEP. I think we all understand that - but that's not actionable. The WG = needs precise details, reasons, source materials and technical arguments = to work with. >>>=20 >>> Once the we, the WG, has those, and only then, can action be taken, = either in form of a rebuttal or a changed design. It's Abdussalam's job = to provide those precise details, reasons, source materials and = technical arguments. The WG (nor the DLEP authors nor any design team) = can - nor should - try to guess what they may be. >>>=20 >>> My personal opinion is, that Stan and the others have done an = admirable job of *trying* to guess and try to provide an explanation and = a rebuttal. If they have failed to do so to Abdussalam's satisfaction, = then it's *not* their fault - it's because they do not have precise = details, reasons, source materials and technical arguments to work with = and rebut (or take action on). >>>=20 >>> I am 200% sure that if Abdussalam (or anyone else) do provides such = details, reasons, source materials and technical arguments, then these = matters will get the attentive ears of the authors and design team. If = not, then - and only then - is there a case to make to the WG or to the = ADs or the IESG or the IAB. >>>=20 >>> Until then, or absent that, there's little point in continuing this = discussion since there's no chance of making constructive progress. >>>=20 >>> Best, >>>=20 >>> Thomas >>>=20 >>> Sent from my iPad >>>=20 >>>> On 4 mars 2014, at 17:13, "Stan Ratliff (sratliff)" = wrote: >>>>=20 >>>> All, >>>>=20 >>>> I also note that Martin Duke wound up contributing quite a bit to = the design team effort; I do not recall any dissent from him at the time = of the 05 draft. >>>>=20 >>>> Now to address another couple of AB's comments: >>>>>>=20 >>>>>> Usually, the DT should report why TCP and not UDP, and IMHO, WG = still did not confirm its decision. >>>>=20 >>>> I'm not entirely sure what you mean here. The MANET WG has pretty = much been, for as long as I've been involved, a group where (1) first an = author (or a group of authors) submits a draft, and then (2) the WG = comments (or 'confirms') that iteration of the draft. The Design Team = acted in the role of "a really interested and active subset of the = working group that committed to additional effort in order to enlighten = the authors, and thereby, hopefully proceed the draft through an = iteration or two faster than it has been going". The design team effort = (along with that of the co-authors) has produced DLEP-05. Having the WG = 'confirm' (or discuss) the 05 draft is what is happening right now. >>>>=20 >>>>=20 >>>>>> Your reasons does not include any performance issue comparing = both transports or comparing both docs draft-04 and draft-05. >>>>=20 >>>> We've tried to explain on multiple occasions - there are *no* = performance considerations. None. There are *no* packet loss = considerations. None. This is because the protocol is completely bounded = on a local Ethernet segment between a router and an "external modem". = This is also because the protocol does not, in any way, shape, or form, = touch the data plane. Data packets through the modem based network flow = *exactly* as they would without DLEP running - that is, a packet would = egress the router's Ethernet interface, be picked up by the external = modem, and then transmitted over-the-air to a receiving station. So = performance was considered, and declared to be a non-issue due to the = design and implementation of the protocol. Which means we're back to = Shawn's enumerated list below on why a TCP-based implementation is = actually simpler than a UDP-based implementation. Yes, the ACKs flow, = but they are TCP ACKs. Not something the DLEP protocol has to take into = account, process, etc et >>>> c. >>>>=20 >>>> Long story short - I'm in agreement with Shawn. So far, I haven't = seen any technical justification for reconsidering the move to TCP. AB, = you said: >>>>>>=20 >>>>>> My concerns are DLEP speed, overhead, and management. >>>>=20 >>>> I share those concerns. I just don't see how a move to TCP = adversely impacts them. You'll need to provide more information to = enlighten me. >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>>=20 >>>>=20 >>>> On Mar 4, 2014, at 10:52 AM, Shawn Jury >>>> wrote: >>>>=20 >>>>> AB, >>>>>=20 >>>>> As a co-author of the draft, there were many discussions prior to = submission on UDP vs TCP. Our decision of UDP was because we truly = believed this paragraph from the draft (which stated UDP prior to -05): >>>>>=20 >>>>> This document specifies an implementation of the DLEP messages and >>>>> data items running over the TCP transport, utilizing a well-known = TCP >>>>> Port number. It is assumed that DLEP running over other transport >>>>> mechanisms would be documented separately. >>>>>=20 >>>>> If there are situations where another transport protocols would be = better, then an extension could be written (or whatever the best = practice is for IETF drafts in this case). >>>>>=20 >>>>> Based upon what I read in the old messages (to refresh my memory), = there is just as much push for TCP as there was for UDP. IMHO, there was = more for TCP. You even linked a message where Teco was pushing for TCP = in your reply to me. >>>>>=20 >>>>> I've spent the better part of the last 8 years working with = different radio vendors on a way to get a protocol like this to work. = Not once did anyone ever complain about which transport protocol was = being used, nor did they ever talk about the connection between the = router/radio being limited. All the issues I have run into have been = with radios that have a slightly different implementation and doesn't = quite fit into a specific area (as recent as yesterday). Of course, = there are also so many waiting on the final draft from this working = group, I'm wondering if they will ever get to implement anything. >>>>>=20 >>>>> Please, continue pushing for justification on the transport = protocol as I'm sure you believe it is very important. >>>>>=20 >>>>> Thanks for your discussion. I'll sit back again and watch as this = becomes more and more of a career path :) >>>>>=20 >>>>> Shawn >>>>>=20 >>>>>> On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: >>>>>>=20 >>>>>> Hi Shawn, >>>>>>=20 >>>>>> Usually, the DT should report why TCP and not UDP, and IMHO, WG = still did not confirm its decision. Your reasons does not include any = performance issue comparing both transports or comparing both docs = draft-04 and draft-05. >>>>>>=20 >>>>>> My concerns are DLEP speed, overhead, and management. The beauty = of draft-04 is that it's link speed between devices should not always be = with high capacity, but for draft-05 there should be including that in = the draft to show its performance limits. Usually, you see thread = subject DLEP with TCP in last Aug, I am not alone wanting UDP (don't = forget authors started with UDP, Duke and Juliusz) regarding change = problems see point below, which made me say IMHO discussion was not = enough. >>>>>=20 >>>>>>=20 >>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg15566.html >>>>>>=20 >>>>>> http://www.ietf.org/mail-archive/web/manet/current/msg15568.html >>>>>>=20 >>>>>> I hope that answers some of my thoughts. >>>>>> Regards >>>>>> AB >>>>>>=20 >>>>>> On Tuesday, March 4, 2014, Shawn Jury wrote: >>>>>> Hello AB, >>>>>>=20 >>>>>> Here we are again with you stating you dislike something, but not = telling us why you dislike it. You are just asking us to explain the = change to you. >>>>>>=20 >>>>>> If I say I like I mean I want or think is better, not totally = sure. >>>>>>=20 >>>>>> I'll tell you that I wasn't part of the DT for DLEP, but I can = see the benefit of using TCP. Just some of the benefits: >>>>>>=20 >>>>>> * No need to recreate a complex state machine in DLEP that would = mimic TCP's behavior. >>>>>> * TCP is an already existing reliable transport protocol = (readily available). >>>>>> * Simplifies the overall implementation of the protocol. >>>>>> * Addresses earlier concerns about how DLEP was a "stop and = wait" protocol. >>>>>>=20 >>>>>> With that said, please explain why you do not like TCP for DLEP. = You seem to agree that a reliable transport is needed (ACKs and SeqNums = in -04), but just state that you don't like TCP and are in favor of = creating a protocol that "gives more flexibility, more independent and = more performance". TCP meets the needs that are required for our = purpose. >>>>>>=20 >>>>>> Unless you can produce a valid argument of why you don't like it, = I'm at a point where I'll just attribute your objections to white noise = as there doesn't seem to be any substance behind them, nor much support = from others on the list. >>>>>>=20 >>>>>> If you have a technical argument of why we shouldn't use TCP, = please send it to the list. >>>>>>=20 >>>>>> Shawn >>>>>>=20 >>>>>>> On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: >>>>>>>=20 >>>>>>> Hi John, >>>>>>>=20 >>>>>>> So you mean low possibility of loss, so why not UDP? that is not >>>>>>> answered, the only answer was because DLEP is stateful and it = has ACK >>>>>>> messages. So why not DLEP-04 while I am using realiable PHY as = you >>>>>>> describe. In addition, even if there are reliability in PHY = there may >>>>>>> be losses in other layers under MANET applicabilities, so that = is why >>>>>>> DLEP-04 has ACKs, which I agree, but don't understand the TCP >>>>>>> importance in such communication scenarios. >>>>>>>=20 >>>>>>> AB >>>>>=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 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From nobody Tue Mar 4 12:33:38 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C711A02D2 for ; Tue, 4 Mar 2014 12:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlQYNZlHF5eG for ; Tue, 4 Mar 2014 12:33:33 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3161A0214 for ; Tue, 4 Mar 2014 12:33:30 -0800 (PST) Received: from [195.245.231.67:4826] by server-15.bemta-5.messagelabs.com id 3F/35-24395-79836135; Tue, 04 Mar 2014 20:33:27 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-4.tower-82.messagelabs.com!1393965206!32077219!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20268 invoked from network); 4 Mar 2014 20:33:26 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-4.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 4 Mar 2014 20:33:26 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Tue, 4 Mar 2014 20:33:26 +0000 From: To: , Date: Tue, 4 Mar 2014 20:33:25 +0000 Thread-Topic: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary Thread-Index: Ac83wc7ill/rBYOASGqvY0+GxJc4uwAJkTLI Message-ID: <290E20B455C66743BE178C5C84F1240847E6334748@EXMB01CMS.surrey.ac.uk> References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> , <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> In-Reply-To: <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.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 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/sGlWoOFrnp4SRG6nHXpiwIvGYdk Cc: manet@ietf.org Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 20:33:37 -0000 Worth noting that things that in theory can have multiple transports in pra= ctice often don't. BEEP? only TCP use is defined and used in a profile. Bundle protocol is pre= tty much over TCP. Efforts to move http over other transports like sctp have gone nowhere much= . Some things like NFS do exist in more than one flavour, for good dataplane = reasons - but it's rare. (I vocally loathed PPPoE as a transport, back in the day. still do.) Lloyd Wood http://about.me/lloydwood ________________________________________ From: manet [manet-bounces@ietf.org] On Behalf Of Shawn Jury [shawn.jury@gm= ail.com] Sent: 04 March 2014 15:52 To: Abdussalam Baryun Cc: MANET IETF Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT= summary AB, As a co-author of the draft, there were many discussions prior to submi= ssion on UDP vs TCP. Our decision of UDP was because we truly believed th= is paragraph from the draft (which stated UDP prior to -05): This document specifies an implementation of the DLEP messages and data items running over the TCP transport, utilizing a well-known TCP Port number. It is assumed that DLEP running over other transport mechanisms would be documented separately. If there are situations where another transport protocols would be bette= r, then an extension could be written (or whatever the best practice is for= IETF drafts in this case). Based upon what I read in the old messages (to refresh my memory), there= is just as much push for TCP as there was for UDP. IMHO, there was more fo= r TCP. You even linked a message where Teco was pushing for TCP in your re= ply to me. I've spent the better part of the last 8 years working with different ra= dio vendors on a way to get a protocol like this to work. Not once did any= one ever complain about which transport protocol was being used, nor did th= ey ever talk about the connection between the router/radio being limited. = All the issues I have run into have been with radios that have a slightly d= ifferent implementation and doesn't quite fit into a specific area (as rece= nt as yesterday). Of course, there are also so many waiting on the final d= raft from this working group, I'm wondering if they will ever get to implem= ent anything. Please, continue pushing for justification on the transport protocol as = I'm sure you believe it is very important. Thanks for your discussion. I'll sit back again and watch as this becom= es more and more of a career path :) Shawn On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: > Hi Shawn, > > Usually, the DT should report why TCP and not UDP, and IMHO, WG still did= not confirm its decision. Your reasons does not include any performance is= sue comparing both transports or comparing both docs draft-04 and draft-05. > > My concerns are DLEP speed, overhead, and management. The beauty of draft= -04 is that it's link speed between devices should not always be with high = capacity, but for draft-05 there should be including that in the draft to s= how its performance limits. Usually, you see thread subject DLEP with TCP i= n last Aug, I am not alone wanting UDP (don't forget authors started with U= DP, Duke and Juliusz) regarding change problems see point below, which made= me say IMHO discussion was not enough. > > http://www.ietf.org/mail-archive/web/manet/current/msg15566.html > > http://www.ietf.org/mail-archive/web/manet/current/msg15568.html > > I hope that answers some of my thoughts. > Regards > AB > > On Tuesday, March 4, 2014, Shawn Jury wrote: > Hello AB, > > Here we are again with you stating you dislike something, but not te= lling us why you dislike it. You are just asking us to explain the change = to you. > > If I say I like I mean I want or think is better, not totally sure. > > I'll tell you that I wasn't part of the DT for DLEP, but I can see th= e benefit of using TCP. Just some of the benefits: > > * No need to recreate a complex state machine in DLEP that would mimic T= CP's behavior. > * TCP is an already existing reliable transport protocol (readily availa= ble). > * Simplifies the overall implementation of the protocol. > * Addresses earlier concerns about how DLEP was a "stop and wait" protoc= ol. > > With that said, please explain why you do not like TCP for DLEP. You = seem to agree that a reliable transport is needed (ACKs and SeqNums in -04)= , but just state that you don't like TCP and are in favor of creating a pro= tocol that "gives more flexibility, more independent and more performance".= TCP meets the needs that are required for our purpose. > > Unless you can produce a valid argument of why you don't like it, I'm= at a point where I'll just attribute your objections to white noise as the= re doesn't seem to be any substance behind them, nor much support from othe= rs on the list. > > If you have a technical argument of why we shouldn't use TCP, please = send it to the list. > > Shawn > > On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: > > > Hi John, > > > > So you mean low possibility of loss, so why not UDP? that is not > > answered, the only answer was because DLEP is stateful and it has ACK > > messages. So why not DLEP-04 while I am using realiable PHY as you > > describe. In addition, even if there are reliability in PHY there may > > be losses in other layers under MANET applicabilities, so that is why > > DLEP-04 has ACKs, which I agree, but don't understand the TCP > > importance in such communication scenarios. > > > > AB > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From nobody Tue Mar 4 14:52:18 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1501A002F for ; Tue, 4 Mar 2014 14:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVGsvvLqD5gO for ; Tue, 4 Mar 2014 14:52:08 -0800 (PST) Received: from mail3.nrl.navy.mil (mail3.nrl.navy.mil [IPv6:2001:480:20:404::465:27]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABD11A001A for ; Tue, 4 Mar 2014 14:52:08 -0800 (PST) Received: from [192.168.1.109] (c-76-21-150-94.hsd1.md.comcast.net [76.21.150.94]) (authenticated bits=0) by mail3.nrl.navy.mil (8.14.5/8.14.5) with ESMTP id s24Mq07t019309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 17:52:01 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Adamson In-Reply-To: <290E20B455C66743BE178C5C84F1240847E6334748@EXMB01CMS.surrey.ac.uk> Date: Tue, 4 Mar 2014 17:52:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <139B3B67-2EA5-4B67-9B41-35C25872E0ED@nrl.navy.mil> References: <2448574f-33ef-4f73-ad37-b2d683bb464a@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB0B4FFF49@SUCNPTEXM02.com.ad.uk.ds.corp> , <68708768-5D20-4D9A-BC6D-DF46B054477E@gmail.com> <290E20B455C66743BE178C5C84F1240847E6334748@EXMB01CMS.surrey.ac.uk> To: L.Wood@surrey.ac.uk X-Mailer: Apple Mail (2.1510) X-Scanned-By: MIMEDefang 2.72 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5SZmbTPGK7PI0t07DQ2Z_7CY8sI Cc: manet@ietf.org Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 22:52:13 -0000 I think TCP can work fine for many DLEP usecases. And, as an idea, if = there are some deployment cases where the DLEP connection needs service = a little different than out-of-the-box TCP behavior, there are = relatively straightforward approaches that can be used to "wrap" around = the TCP connection the endpoints see. For example, we (NRL) have = implemented a SOCKS-based proxy for TCP connections that morphs them = into NORM unicast flows (a reliable UDP protocol (RFC 5740) that does = unicast as well as multicast) and can even provide pre-provisioned = fixed-rate operation (thus avoid TCP slow start delays, etc) with = reliable data delivery to the TCP connection content. No changes are = required on the endpoints =85 they just experience a nice speedy = connection. Others have done similar work to proxy TCP flows in various = ways for various purposes. So I don't think the DLEP spec would need to = be mucked up. It would be a matter of system configuration to provide = the proxy support. Compatibility with SOCKS (RFC 1928) could be = suggested as an enabler for this sort of thing, but if it's a = straightforward TCP usage, then that pretty much comes for free =85 cheers, Brian On Mar 4, 2014, at 3:33 PM, L.Wood@surrey.ac.uk wrote: >=20 > Worth noting that things that in theory can have multiple transports = in practice often don't. >=20 > BEEP? only TCP use is defined and used in a profile. Bundle protocol = is pretty much over TCP. > Efforts to move http over other transports like sctp have gone nowhere = much. >=20 > Some things like NFS do exist in more than one flavour, for good = dataplane reasons - but it's rare. >=20 > (I vocally loathed PPPoE as a transport, back in the day. still do.) >=20 > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: manet [manet-bounces@ietf.org] On Behalf Of Shawn Jury = [shawn.jury@gmail.com] > Sent: 04 March 2014 15:52 > To: Abdussalam Baryun > Cc: MANET IETF > Subject: Re: [manet] DLEP performance with and without TCP (was Re: = DLEP DT summary >=20 > AB, >=20 > As a co-author of the draft, there were many discussions prior to = submission on UDP vs TCP. Our decision of UDP was because we truly = believed this paragraph from the draft (which stated UDP prior to -05): >=20 > This document specifies an implementation of the DLEP messages and > data items running over the TCP transport, utilizing a well-known = TCP > Port number. It is assumed that DLEP running over other transport > mechanisms would be documented separately. >=20 > If there are situations where another transport protocols would be = better, then an extension could be written (or whatever the best = practice is for IETF drafts in this case). >=20 > Based upon what I read in the old messages (to refresh my memory), = there is just as much push for TCP as there was for UDP. IMHO, there was = more for TCP. You even linked a message where Teco was pushing for TCP = in your reply to me. >=20 > I've spent the better part of the last 8 years working with = different radio vendors on a way to get a protocol like this to work. = Not once did anyone ever complain about which transport protocol was = being used, nor did they ever talk about the connection between the = router/radio being limited. All the issues I have run into have been = with radios that have a slightly different implementation and doesn't = quite fit into a specific area (as recent as yesterday). Of course, = there are also so many waiting on the final draft from this working = group, I'm wondering if they will ever get to implement anything. >=20 > Please, continue pushing for justification on the transport protocol = as I'm sure you believe it is very important. >=20 > Thanks for your discussion. I'll sit back again and watch as this = becomes more and more of a career path :) >=20 > Shawn >=20 > On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote: >=20 >> Hi Shawn, >>=20 >> Usually, the DT should report why TCP and not UDP, and IMHO, WG still = did not confirm its decision. Your reasons does not include any = performance issue comparing both transports or comparing both docs = draft-04 and draft-05. >>=20 >> My concerns are DLEP speed, overhead, and management. The beauty of = draft-04 is that it's link speed between devices should not always be = with high capacity, but for draft-05 there should be including that in = the draft to show its performance limits. Usually, you see thread = subject DLEP with TCP in last Aug, I am not alone wanting UDP (don't = forget authors started with UDP, Duke and Juliusz) regarding change = problems see point below, which made me say IMHO discussion was not = enough. >=20 >>=20 >> http://www.ietf.org/mail-archive/web/manet/current/msg15566.html >>=20 >> http://www.ietf.org/mail-archive/web/manet/current/msg15568.html >>=20 >> I hope that answers some of my thoughts. >> Regards >> AB >>=20 >> On Tuesday, March 4, 2014, Shawn Jury wrote: >> Hello AB, >>=20 >> Here we are again with you stating you dislike something, but not = telling us why you dislike it. You are just asking us to explain the = change to you. >>=20 >> If I say I like I mean I want or think is better, not totally sure. >>=20 >> I'll tell you that I wasn't part of the DT for DLEP, but I can see = the benefit of using TCP. Just some of the benefits: >>=20 >> * No need to recreate a complex state machine in DLEP that would = mimic TCP's behavior. >> * TCP is an already existing reliable transport protocol (readily = available). >> * Simplifies the overall implementation of the protocol. >> * Addresses earlier concerns about how DLEP was a "stop and wait" = protocol. >>=20 >> With that said, please explain why you do not like TCP for DLEP. = You seem to agree that a reliable transport is needed (ACKs and SeqNums = in -04), but just state that you don't like TCP and are in favor of = creating a protocol that "gives more flexibility, more independent and = more performance". TCP meets the needs that are required for our = purpose. >>=20 >> Unless you can produce a valid argument of why you don't like it, = I'm at a point where I'll just attribute your objections to white noise = as there doesn't seem to be any substance behind them, nor much support = from others on the list. >>=20 >> If you have a technical argument of why we shouldn't use TCP, = please send it to the list. >>=20 >> Shawn >>=20 >> On Mar 4, 2014, at 6:54 AM, Abdussalam Baryun wrote: >>=20 >>> Hi John, >>>=20 >>> So you mean low possibility of loss, so why not UDP? that is not >>> answered, the only answer was because DLEP is stateful and it has = ACK >>> messages. So why not DLEP-04 while I am using realiable PHY as you >>> describe. In addition, even if there are reliability in PHY there = may >>> be losses in other layers under MANET applicabilities, so that is = why >>> DLEP-04 has ACKs, which I agree, but don't understand the TCP >>> importance in such communication scenarios. >>>=20 >>> AB >>=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 nobody Tue Mar 4 23:47:11 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D7D1A035D for ; Tue, 4 Mar 2014 23:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npv7JF4tp_5r for ; Tue, 4 Mar 2014 23:47:05 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7736E1A035A for ; Tue, 4 Mar 2014 23:47:05 -0800 (PST) Received: by mail-yk0-f174.google.com with SMTP id 20so1806296yks.5 for ; Tue, 04 Mar 2014 23:47:01 -0800 (PST) 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=Cj54Vh79gvfJcboGYpU7ds9XCKI/8I/Q2ATVdzGHi0A=; b=FLKTETZM282IKbVbH46CzmSkMckaRyu2mTs3VfYWua9IEiYzEeVomc+H35l4zWlRH9 +B/Mma2FgZ/Kft2+/SRcc0DocFR20wUjqFjmO76cEHbf0DQv4XXhAcf97tkMggPVLq7r Wk341teWzlty2WXjL2ghn+iIyiqvLcjtYltN2+w8oAw9nQkvMTjYG5/H0qOG2+Wos3y5 18OOg2JFz37QY45DdHNdjJeeQrz/HD9dRWFmyJQJ4y7MxI1Ft8Nc5+Dl+L1wz4DnmeD6 teEXB7juNcEzy0j/k0ONQeZ+IU7U7IttJlWpkIoUmTtxokKynVcYvFoy4WQQyGrZ7XfD +dvg== MIME-Version: 1.0 X-Received: by 10.236.122.99 with SMTP id s63mr5029377yhh.19.1394005621873; Tue, 04 Mar 2014 23:47:01 -0800 (PST) Received: by 10.170.202.7 with HTTP; Tue, 4 Mar 2014 23:47:01 -0800 (PST) In-Reply-To: References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <508641F2.9050100@fkie.fraunhofer.de> <5088E2B5.60102@fkie.fraunhofer.de> Date: Wed, 5 Mar 2014 08:47:01 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=20cf301af335e8212b04f3d73997 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/A9bidLotzM8uiD72P8QHOreREtA Subject: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 07:47:08 -0000 --20cf301af335e8212b04f3d73997 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Will and Henning, I am not sure of the work in progress related to draft-ivancic and draft-rogge mentioned below. However, I think they are interesting to be consider by the WG. Was there a decision made on the drafts by the authors or was it to be submitted else where. Please help. Thanking you, AB On Monday, October 22, 2012, Ivancic, William D. (GRC-RHN0) wrote: > A few months ago (time flies), the authors of modemLPA have been in di= scussion 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-mobop= ts-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 t= he manet group the right place? I really don't know if this is the right g= roup 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 > On Monday, November 5, 2012, Henning Rogge wrote: > On Thu, Oct 25, 2012 at 8:56 AM, Henning Rogge > 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. > > Now that the submission block period is over, I have also uploaded the > draft properly to the IETF as a personal draft: > > https://datatracker.ietf.org/doc/draft-rogge-stateless-rfc5444-dlep/ > > 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 > --20cf301af335e8212b04f3d73997 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Will and Henning,

I am not sure of the work in=A0progress relate= d to=A0draft-ivancic and draft-rogge=A0mentioned below. However, I think th= ey are interesting to be=A0consider by the WG. Was=A0there a decision made = on the drafts by the authors or was it=A0to be submitted else where. Please= help. Thanking you,

AB


On Monday, October 22, 2012, Ivancic, Willia= m D. (GRC-RHN0)=A0wrote:
   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 docum=
ent was originally submitted=A0to the IRTF=A0mobopts research group as an i=
ndividual submission draft-ivancic-mobopts-modemlpa-01.  That research grou=
p as recently closed down.  I am looking for a new place to put updates unt=
il 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 b=
e more appropriate.  I see no other working groups or research groups reall=
y 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/
<= pre>
I am currently planning on attending the IETF meetings i=
n Atlanta.
- Will Ivancic


On M= onday, November 5, 2012, Henning Rogge wrote:
On Thu, Oct 25, 2012 at 8: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.

Now that the submission block period is over, I have also uploaded the
draft properly to the IETF as a personal draft:

https://datatracker.ietf.org/doc/draft-rogge-statel= ess-rfc5444-dlep/

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
--20cf301af335e8212b04f3d73997-- From nobody Wed Mar 5 02:49:31 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B593F1A0408 for ; Wed, 5 Mar 2014 02:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfaD_ZrCbb8K for ; Wed, 5 Mar 2014 02:49:28 -0800 (PST) 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 03ED11A03D9 for ; Wed, 5 Mar 2014 02:49:27 -0800 (PST) Received: from [31.133.162.164] by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WL9O4-0006L3-7f; Wed, 05 Mar 2014 05:49:20 -0500 Message-ID: <5317012F.60701@computer.org> Date: Wed, 05 Mar 2014 02:49:19 -0800 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mobile Ad Hoc Networks mailing list Content-Type: multipart/alternative; boundary="------------060701000804020805040407" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867a365a4f03c8348d3dd6013a9ca21a68350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.162.164 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/H-nBbYe36uNokSLpL9MDCthxKes Subject: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 10:49:31 -0000 This is a multi-part message in MIME format. --------------060701000804020805040407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello folks, Here is the passage referred to in this morning's complaint: >> A multitude of MANET protocols have been designed to use RFC5444, >> including reactive protocols, without any problems. >> >> It's extremely easy, even, once one understands RFC5444. > > See the above. If I am challenged to get testimonials to the > contrary from other people, then I'll have to wait. I'm not at > all interested in arguing about it, especially right now! I will > at least say that other software developers seem more willing > to accept feedback. > In context, it is clear that I meant that I was not interested in arguing about whether or not using RFC 5444 was "easy". Since we are mandated to use RFC 5444, it wasn't (and right not is still not) very important to argue about whether it is "easy" to use RFC 5444. This does not in any way imply that I am uninterested in discussing issues affecting the AODVv2 specification, and should never be interpreted that way. -- Regards, Charlie P. --------------060701000804020805040407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello folks,

Here is the passage referred to in this morning's complaint:

A multitude of MANET protocols have been designed to use RFC5444, including reactive protocols, without any problems.

It's extremely easy, even, once one understands RFC5444.

See the above.  If I am challenged to get testimonials to the
contrary from other people, then I'll have to wait.   I'm not at
all interested in arguing about it, especially right now!   I will
at least say that other software developers seem more willing
to accept feedback.

In context, it is clear that I meant that I was not interested in
arguing about whether or not using RFC 5444 was "easy".
Since we are mandated to use RFC 5444, it wasn't (and right
not is still not) very important to argue about whether it is
"easy" to use RFC 5444.

This does not in any way imply that I am uninterested in
discussing issues affecting the AODVv2 specification, and
should never be interpreted that way.
-- 
Regards,
Charlie P.
--------------060701000804020805040407-- From nobody Wed Mar 5 02:58:05 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962151A0410 for ; Wed, 5 Mar 2014 02:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSD1ISq7PYsz for ; Wed, 5 Mar 2014 02:58:03 -0800 (PST) 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 6C1011A03C9 for ; Wed, 5 Mar 2014 02:58:03 -0800 (PST) Received: from [31.133.162.164] by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WL9WR-0003VK-M3 for manet@ietf.org; Wed, 05 Mar 2014 05:57:59 -0500 Message-ID: <53170334.2020908@computer.org> Date: Wed, 05 Mar 2014 02:57:56 -0800 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mobile Ad Hoc Networks mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867715e94ed83f29b4d8eb6ffc56c44e65350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.162.164 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/OaAFIj79WspRQ4fj8H1BFKh_i_M Subject: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 10:58:04 -0000 Hello folks, Part of the job of finishing the AODVv2 specification will be to comb the mailing list for issues that are still not resolved. If there are any specific issues that have not been gotten proper attention, I hope to find them -- but if anyone would like to help by bringing them up here on the mailing list, that will be appreciated. -- Regards, Charlie P. From nobody Wed Mar 5 03:12:44 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF51E1A03EF for ; Wed, 5 Mar 2014 03:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbYzj2Fbuhrg for ; Wed, 5 Mar 2014 03:12:39 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E20931A03ED for ; Wed, 5 Mar 2014 03:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=255; q=dns/txt; s=iport; t=1394017945; x=1395227545; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=R302clFWLEg11IjqKCS2Y1kMG3pRz6Ry6mSUdqM3KBg=; b=aXFcSa3T/EqCrZCfRuFgd58CV64mfQkWQ5xqmfE1ZBRbq/uWd/L2xlEj 0uCgG51bOiHkLSdD0JdJkma4tBnJMtYYY7HDXmj1tDDE8v7MrFtI16CCE mfWwRMvj5RqiAf067z9Oov/r8YCgHmYSWDNIMpe5QZmY9xIKcuu74N8zh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP0FF1OtJXG9/2dsb2JhbABagwaBEsIkFnSCLDpRAT5CJwSIDJ1/r2gXkXyBFASYPZIrgy2CKg X-IronPort-AV: E=Sophos;i="4.97,592,1389744000"; d="scan'208";a="308194083" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 05 Mar 2014 11:12:25 +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 s25BCPGN027245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 11:12:25 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.172]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 05:12:25 -0600 From: "Stan Ratliff (sratliff)" To: MANET IETF Thread-Topic: draft-rogge-baccelli-olsrv2-ett-metric Thread-Index: AQHPOGPJiA8bCyFNB0iARcfb9cD77g== Date: Wed, 5 Mar 2014 11:12:24 +0000 Message-ID: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.216.67] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tN7XLrIqLRDkoPGSPLuQIhCyOfY Subject: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:12:42 -0000 Working Group Participants,=20 The consensus in the room this morning at IETF 89 is to accept this as a wo= rking group document. If there is opposition to this action, please respond= on the list no later than March 7, 2014.=20 Regards, Stan= From nobody Wed Mar 5 03:18:07 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A221A0250 for ; Wed, 5 Mar 2014 03:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLJMLkuc6Rj7 for ; Wed, 5 Mar 2014 03:18:03 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2699C1A049F for ; Wed, 5 Mar 2014 03:18:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id ED4FB2404A7; Wed, 5 Mar 2014 03:17:59 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [31.133.182.20] (dhcp-b614.meeting.ietf.org [31.133.182.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 87E43240455; Wed, 5 Mar 2014 03:17:59 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-DD5FD402-9C51-4FC6-8460-48FDA4750CF7 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: <5317012F.60701@computer.org> Date: Wed, 5 Mar 2014 12:17:58 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <5317012F.60701@computer.org> To: "Charles E. Perkins" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ZynlVMFwbs_sW3TUQVkOeC2mzLY Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:18:05 -0000 --Apple-Mail-DD5FD402-9C51-4FC6-8460-48FDA4750CF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 5 mars 2014, at 11:49, "Charles E. Perkins" wro= te: >=20 >=20 > Hello folks, >=20 > Here is the passage referred to in this morning's complaint: >=20 >>=20 >>> A multitude of MANET protocols have been designed to use RFC5444, includ= ing reactive protocols, without any problems. >>>=20 >>> It's extremely easy, even, once one understands RFC5444. >>=20 >> See the above. If I am challenged to get testimonials to the >> contrary from other people, then I'll have to wait. I'm not at >> all interested in arguing about it, especially right now! I will >> at least say that other software developers seem more willing >> to accept feedback. >=20 > In context, it is clear that I meant that I was not interested in > arguing about whether or not using RFC 5444 was "easy". > Since we are mandated to use RFC 5444, it wasn't (and right > not is still not) very important to argue about whether it is > "easy" to use RFC 5444. >=20 > This does not in any way imply that I am uninterested in > discussing issues affecting the AODVv2 specification, and > should never be interpreted that way. Even if that is the case, the fact that the author group has not folded in, o= r addressed, reviews and comments that have been repeated on the list over a= nd over most certainly can be interpreted in only that way..... I have reviewed the latest iteration of this specification prior to the Lond= on IETF.=20 To my disappointment, the issues that I raised during the Maastricht IETF, n= ow many moons ago, and which have been repeated and echoed several times ove= r on the list (by me and others, and even recently) have *still* been neithe= r reflected in the document, nor have they been rebutted by its authors.=20 I observe that the same is true for reviews and comments made by others, als= o. I note that this was raised as an issue at, at the very least, the two previ= ous IETF meetings, as well as on the list - alas, to no avail. Respectfully, Thomas= --Apple-Mail-DD5FD402-9C51-4FC6-8460-48FDA4750CF7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 5 mars 2014, at 11:4= 9, "Charles E. Perkins" <charlie= p@computer.org> wrote:

=20 =20 =20
Hello folks,

Here is the passage referred to in this morning's complaint:

A multitude of MANET protocols have been designed to use RFC5444, including reactive protocols, without any problems.

It's extremely easy, even, once one understands RFC5444.

See the above.  If I= am challenged to get testimonials to the
contrary from other people, then I'll have to wait.   I'm not at
all interested in arguing about it, especially right now!   I will=
at least say that other software developers seem more willing
to accept feedback.

In context, it is clear that I meant that I was not interested in
arguing about whether or not using RFC 5444 was "easy".
Since we are mandated to use RFC 5444, it wasn't (and right
not is still not) very important to argue about whether it is
"easy" to use RFC 5444.

This does not in any way imply that I am uninterested in
discussing issues affecting the AODVv2 specification, and
should never be interpreted that way.

Even if that is the case, the fac= t that the author group has not folded in, or addressed, reviews and comment= s that have been repeated on the list over and over most certainly can be in= terpreted in only that way.....

I have reviewed the= latest iteration of this specification prior to the London IETF. 

To my disappointment, the issues that I raised during t= he Maastricht IETF, now many moons ago, and which have been repeated and ech= oed several times over on the list (by me and others, and even recently) hav= e *still* been neither reflected in the document, nor have they been rebutte= d by its authors. 

I observe that the same is t= rue for reviews and comments made by others, also.

= I note that this was raised as an issue at, at the very least, the two previ= ous IETF meetings, as well as on the list - alas, to no avail.
Respectfully,

Thomas
= --Apple-Mail-DD5FD402-9C51-4FC6-8460-48FDA4750CF7-- From nobody Wed Mar 5 03:22:13 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FA81A0502 for ; Wed, 5 Mar 2014 03:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8umrb5tyTDjj for ; Wed, 5 Mar 2014 03:22:03 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id AE59F1A04F8 for ; Wed, 5 Mar 2014 03:22:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 820EE240527; Wed, 5 Mar 2014 03:22:00 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [31.133.182.20] (dhcp-b614.meeting.ietf.org [31.133.182.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4D1C12404A7; Wed, 5 Mar 2014 03:22:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> Date: Wed, 5 Mar 2014 12:21:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54D785F8-E283-48F0-8659-1E462A8B0099@thomasclausen.org> References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> To: "Stan Ratliff (sratliff)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/FyWAWnhFg1nXihbWAIxtubE_HPk Cc: MANET IETF Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:22:07 -0000 > On 5 mars 2014, at 12:12, "Stan Ratliff (sratliff)" w= rote: >=20 > Working Group Participants,=20 >=20 > The consensus in the room this morning at IETF 89 is to accept this as a w= orking group document. If there is opposition to this action, please respond= on the list no later than March 7, 2014.=20 >=20 I'd like to respond with STRONG SUPPORT for this document being adopted by t= he WG.=20 I believe that it's interesting, is needed, and is quite readable. I've foun= d a few nits and issues, and a few things were raised at the mike today that= probably should be developed in the document - but I am quite confident th= at the authors will be able to hammer those out quickly, once the document i= s adopted. Let's do it! Thomas > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Mar 5 03:23:08 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3605B1A055D for ; Wed, 5 Mar 2014 03:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEEofuOPkwIo for ; Wed, 5 Mar 2014 03:23:05 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 16A271A0545 for ; Wed, 5 Mar 2014 03:23:04 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id b13so1034118wgh.32 for ; Wed, 05 Mar 2014 03:23:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=NLffFyqb2zBaDtaITkjd1OUU2Mt7Po8CorKLOqBD9u0=; b=De7zBcj9GKX0ZIoY3Gi/795wr2DHX9f1v0j0aaPZjpUKISQYi3ZprKzzzfRBS048++ F7iFYq/WoK/t1F8UrdbqEtQv0ojM0YsDqNDql74NwGS6KmOrVeChuJEgTu4nsF5RyWSc lm1QKQMRtBa0Rv+dAjoh7NdeRNcsujuEOWDgfXPoizr+ZtacJxLNpuBlWj3nTbBn3Yt8 9BtI6xyi9fCBvzsjPr5SQPeqLpVDIinRwViRYookHReU8yeW34AGwJuqYqmluCTe2H3i MbDa8JcIlKNkGA2OkfnL7xohsbh6Ni+525hDAvSMEitavS/MkpJQddoK3b/G2TDp+BVt /1qw== X-Gm-Message-State: ALoCoQmSIdxpcA7N3sUmhuh6tipa9LhN2YdIm22hpjKyfS/aGb44Gem/19NyKZ/NTP6+Lk3lncGp X-Received: by 10.194.60.103 with SMTP id g7mr7624384wjr.37.1394018580713; Wed, 05 Mar 2014 03:23:00 -0800 (PST) Received: from dhcp-a727.meeting.ietf.org (dhcp-a727.meeting.ietf.org. [31.133.167.39]) by mx.google.com with ESMTPSA id h13sm10263046wjr.22.2014.03.05.03.22.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 03:22:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Teco Boot In-Reply-To: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> Date: Wed, 5 Mar 2014 12:23:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UVZ5XzBlgoqjFagMjZ2SALaLjS8 Cc: MANET IETF Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:23:07 -0000 May I suggest to rename to draft-manet-olsrv2-dat-metric? Teco Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) = het volgende geschreven: > Working Group Participants,=20 >=20 > The consensus in the room this morning at IETF 89 is to accept this as = a working group document. If there is opposition to this action, please = respond on the list no later than March 7, 2014.=20 >=20 > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Mar 5 03:25:28 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238531A0458 for ; Wed, 5 Mar 2014 03:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08HwfiP12Yx1 for ; Wed, 5 Mar 2014 03:25:25 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 90D071A0406 for ; Wed, 5 Mar 2014 03:25:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 626F12408BE; Wed, 5 Mar 2014 03:25:22 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [31.133.182.20] (dhcp-b614.meeting.ietf.org [31.133.182.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 28DD9240527; Wed, 5 Mar 2014 03:25:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Wed, 5 Mar 2014 12:25:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> To: Teco Boot Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YiHaKfE96uAY-G0mrF_9L1PUT6o Cc: MANET IETF , Stan Ratliff Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:25:27 -0000 > On 5 mars 2014, at 12:23, Teco Boot wrote: >=20 > May I suggest to rename to draft-manet-olsrv2-dat-metric? >=20 That's actually not a bad suggestion, seconded. Also, while we're listing things, I think that the most important missing bi= t is "a section discussing the experiments intended" to be developed. Best, Thomas > Teco >=20 >> Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) het volgende geschreven: >>=20 >> Working Group Participants,=20 >>=20 >> The consensus in the room this morning at IETF 89 is to accept this as a w= orking group document. If there is opposition to this action, please respond= on the list no later than March 7, 2014.=20 >>=20 >> Regards, >> Stan >> _______________________________________________ >> 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 nobody Wed Mar 5 03:51:51 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946631A040C for ; Wed, 5 Mar 2014 03:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzBEmlycBBXP for ; Wed, 5 Mar 2014 03:51:45 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9EE1A0400 for ; Wed, 5 Mar 2014 03:51:45 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 10so2369829ykt.4 for ; Wed, 05 Mar 2014 03:51:42 -0800 (PST) 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=PRcueKDNLyIz4tryPR/bBsscrhGFWmipeQ199gP5cgw=; b=WB5K0f9fYb2Ka73fAPE5lPihTkpxi2x6J3eHcWY6oj+t6VsPtVulR9txOzmeIL9Tfz z1Y1rAI/fsBVlt2moct1edrsbJsRMf9xjk2/tpqouNPIdYy4PJk7iUx5XugGpxQNuMIT +HOUFiLwScYedoqueFaqg0GEIK2xFhaO/gA+MoWC6U2unUGBp8LbWd2YYkAoR29LaxnY QgMFuNbnRp7z29xwDkDb33VxTLdLpxyutXUyV/xGVF2EEdboQiiz41WyfCt8CqqYQzk4 EwCftlbnKgODt9d+OGw0JdV+up7VMBQst+SwHyXitQuhoZP0PO+YDPvft0MHa9mYxss0 KLYA== MIME-Version: 1.0 X-Received: by 10.236.123.38 with SMTP id u26mr6083946yhh.93.1394020302018; Wed, 05 Mar 2014 03:51:42 -0800 (PST) Received: by 10.170.202.7 with HTTP; Wed, 5 Mar 2014 03:51:41 -0800 (PST) In-Reply-To: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> Date: Wed, 5 Mar 2014 12:51:41 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=20cf3011d9dfe95e5304f3daa408 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JA9PhYJhiONAhbNywN1X0jLgYVw Cc: MANET IETF Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:51:47 -0000 --20cf3011d9dfe95e5304f3daa408 Content-Type: text/plain; charset=ISO-8859-1 I support the proposal, thanks to authors, AB On Wednesday, March 5, 2014, Stan Ratliff (sratliff) wrote: > Working Group Participants, > > The consensus in the room this morning at IETF 89 is to accept this as a > working group document. If there is opposition to this action, please > respond on the list no later than March 7, 2014. > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf3011d9dfe95e5304f3daa408 Content-Type: text/html; charset=ISO-8859-1 I support the proposal, thanks to authors,

AB

On Wednesday, March 5, 2014, Stan Ratliff (sratliff) wrote:
Working Group Participants,

The consensus in the room this morning at IETF 89 is to accept this as a working group document. If there is opposition to this action, please respond on the list no later than March 7, 2014.

Regards,
Stan
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--20cf3011d9dfe95e5304f3daa408-- From nobody Wed Mar 5 03:55:53 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F1A1A047E for ; Wed, 5 Mar 2014 03:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg3uqcmAThVb for ; Wed, 5 Mar 2014 03:55:49 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1B61A03F3 for ; Wed, 5 Mar 2014 03:55:49 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id x48so1030802wes.7 for ; Wed, 05 Mar 2014 03:55:45 -0800 (PST) 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=pJ/ZjhvGU2CCZqnhO8Ma9pYDIMiUfsx5OBawm6DWMXs=; b=ycheA2MzbnPUms1rvZDfXgRyThmE9BC12Hw+sWRSDsnTLx5LosCkW5x464h5kMhOgc PmmfynIuprMm2tEJTNClun6ErrUtlpubT8fQDNhFgjEutqYzYsl6FVB/sVx5baZSowWt /HzRXkjl+iBUB0x4une2iP6ffm4Lf4IhGsygSxejlYhxz1CHfksOR6R7kFmHMaBhZZR5 jhGxtLY7NwRoCX9aKJCk2+HwED1jbVMX8UInrYsgX6qeQjNx6Yto+GrBTFndwR5TCX6p U+3MxM+WUvkrlbinMpWR/woPxDg6gD+eQaLxiehdQyUQedklx8yk7tHyqYyfSZvzmn7u ivfA== MIME-Version: 1.0 X-Received: by 10.194.22.129 with SMTP id d1mr340477wjf.22.1394020545688; Wed, 05 Mar 2014 03:55:45 -0800 (PST) Received: by 10.194.118.134 with HTTP; Wed, 5 Mar 2014 03:55:45 -0800 (PST) In-Reply-To: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> Date: Wed, 5 Mar 2014 12:55:45 +0100 Message-ID: From: Jiazi YI To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=047d7b5d58686f7a8704f3dab322 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9Bi8RpeMf5jAcAK48hIMNmwZOKs Cc: MANET IETF Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:55:51 -0000 --047d7b5d58686f7a8704f3dab322 Content-Type: text/plain; charset=ISO-8859-1 I'm in favor of accepting it as WG document Jiazi On Wed, Mar 5, 2014 at 12:12 PM, Stan Ratliff (sratliff) wrote: > Working Group Participants, > > The consensus in the room this morning at IETF 89 is to accept this as a > working group document. If there is opposition to this action, please > respond on the list no later than March 7, 2014. > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b5d58686f7a8704f3dab322 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm in favor of accepting it as WG document

Jiazi


On Wed, Mar 5, 2014 at 12:12 PM, Stan Ratliff (sratliff) <sr= atliff@cisco.com> wrote:
Working Group Participants,

The consensus in the room this morning at IETF 89 is to accept this as a wo= rking group document. If there is opposition to this action, please respond= on the list no later than March 7, 2014.

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

--047d7b5d58686f7a8704f3dab322-- From nobody Wed Mar 5 04:21:38 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9488F1A0454 for ; Wed, 5 Mar 2014 04:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owF6QYu51aen for ; Wed, 5 Mar 2014 04:21:32 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4860D1A03A6 for ; Wed, 5 Mar 2014 04:21:32 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id x13so988552qcv.30 for ; Wed, 05 Mar 2014 04:21:28 -0800 (PST) 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=UW6j1wGpit7+X7jPqxt3XeoluxWPwQC14DAeSzhs7ME=; b=TpppM1El6Sl2amTRrKKMmhrnR+nEIb/cPRsLQxRYSC5RBQaOTb7no3yXtxCWNSrqDR em8DgJqLr4ymCcACQMXztnDa6vkXNvmTEnrQxZ7GXTdZ0Du8K1m99yMxzK1ESCZi+KAP iD3rvAtsa/brKd1vHPq550PMIhN1xJe/7c550XL2l7jOIm/QLgnFofGa9q1XofQ6KkLM i0AGMlx+5RFWxxIXwT33lqS6DiwqPprws1GzLYk90GG32RoEky02dEQsQ91ut6KdP9i/ gR5h5VSSBPKLk6/MOXcYL1Qcq3l4ZSdGXLhYfFUMMbTrOG2ZfI9N3S7Ed/N7ZdE7hOzn ldOA== MIME-Version: 1.0 X-Received: by 10.224.171.200 with SMTP id i8mr1712614qaz.96.1394022088653; Wed, 05 Mar 2014 04:21:28 -0800 (PST) Received: by 10.224.130.2 with HTTP; Wed, 5 Mar 2014 04:21:28 -0800 (PST) Received: by 10.224.130.2 with HTTP; Wed, 5 Mar 2014 04:21:28 -0800 (PST) In-Reply-To: References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> Date: Wed, 5 Mar 2014 12:21:28 +0000 Message-ID: From: Henning Rogge To: Teco Boot Content-Type: multipart/alternative; boundary=001a11c2ca886744db04f3db0f5e Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NmJ7KtV35VVqHk_cxFEkNByjIZM Cc: MANET IETF , Stan Ratliff Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 12:21:34 -0000 --001a11c2ca886744db04f3db0f5e Content-Type: text/plain; charset=ISO-8859-1 I planned to rename it to something similar to this anyways, so I am okay with this suggestion. Henning On Mar 5, 2014 11:23 AM, "Teco Boot" wrote: > May I suggest to rename to draft-manet-olsrv2-dat-metric? > > Teco > > Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) > het volgende geschreven: > > > Working Group Participants, > > > > The consensus in the room this morning at IETF 89 is to accept this as a > working group document. If there is opposition to this action, please > respond on the list no later than March 7, 2014. > > > > Regards, > > Stan > > _______________________________________________ > > 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 > --001a11c2ca886744db04f3db0f5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I planned to rename it to something similar to this anyways,= so I am okay with this suggestion.

Henning

On Mar 5, 2014 11:23 AM, "Teco Boot" &= lt;teco@inf-net.nl> wrote:
May I suggest to rename to draft-manet-olsrv2-dat-metric?

Teco

Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) <sratliff@cisco.com> het volgende geschreven:
> Working Group Participants,
>
> The consensus in the room this morning at IETF 89 is to accept this as= a working group document. If there is opposition to this action, please re= spond on the list no later than March 7, 2014.
>
> Regards,
> Stan
> _______________________________________________
> 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
--001a11c2ca886744db04f3db0f5e-- From nobody Wed Mar 5 05:18:00 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881311A044B for ; Wed, 5 Mar 2014 04:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb__h96kGLiN for ; Wed, 5 Mar 2014 04:00:27 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id BF0281A0424 for ; Wed, 5 Mar 2014 04:00:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 8E90C2408BE; Wed, 5 Mar 2014 04:00:24 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.8.0.6] (unknown [37.139.15.61]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id DBC95240455; Wed, 5 Mar 2014 04:00:22 -0800 (PST) From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= Content-Type: multipart/alternative; boundary="Apple-Mail=_BEA7EE55-7283-4BE2-A4DD-115B1D6E798C" Message-Id: <335AD6ED-F820-4C3B-9C11-F6593D4EEE43@axelcdv.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Wed, 5 Mar 2014 12:00:19 +0000 References: <20140305115333.7635.9928.idtracker@ietfa.amsl.com> To: " List" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/1cKGi8KDVcZ0LVkEMQTUp7cSkj4 X-Mailman-Approved-At: Wed, 05 Mar 2014 05:17:55 -0800 Cc: Soon Young Oh , gerla Subject: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 12:00:29 -0000 --Apple-Mail=_BEA7EE55-7283-4BE2-A4DD-115B1D6E798C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi all, We just pushed a new revision of ODMRP out, the -02 version presented at = the meeting. I got some comments during this week and plan to integrate = them into a -03 revision pretty soon. I'd be happy to discuss additional = suggestions or remarks that could be added to that revision. Thanks, Axel D=E9but du message r=E9exp=E9di=E9 : > De: internet-drafts@ietf.org > Objet: New Version Notification for draft-gerla-manet-odmrp-02.txt > Date: 5 mars 2014 11:53:33 UTC > =C0: "William Su" , "Yunjung Yi" = , "Axel Coli Verdiere" = , "Sung-Ju Lee" = , Mario Gerla = , "Professor Mario Gerla" , = William Su , Axel Colin de Verdiere = >=20 >=20 > A new version of I-D, draft-gerla-manet-odmrp-02.txt > has been successfully submitted by Axel Colin de Verdiere and posted = to the > IETF repository. >=20 > Name: draft-gerla-manet-odmrp > Revision: 02 > Title: On-Demand Multicast Routing Protocol (ODMRP) for = Ad Hoc Networks > Document date: 2014-03-05 > Group: Individual Submission > Pages: 30 > URL: = http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-02.txt > Status: = https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/ > Htmlized: http://tools.ietf.org/html/draft-gerla-manet-odmrp-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-02 >=20 > Abstract: > The On-Demand Multicast Routing Protocol (ODMRP) is a multicast > routing protocol designed for ad hoc networks with mobile hosts. > ODMRP is a mesh-based, rather than a conventional tree-based, > multicast scheme and uses a forwarding group concept (only a subset > of nodes forwards the multicast packets via scoped flooding). It > applies on-demand procedures to dynamically build routes and = maintain > multicast group membership. ODMRP is well suited for ad hoc = wireless > networks with mobile hosts where bandwidth is limited, topology > changes frequently and rapidly, and power is constrained. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_BEA7EE55-7283-4BE2-A4DD-115B1D6E798C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = all,

We just pushed a new revision of ODMRP out, the = -02 version presented at the meeting. I got some comments during this = week and plan to integrate them into a -03 revision pretty soon. I'd be = happy to discuss additional suggestions or remarks that could be added = to that = revision.

Thanks,

Axel


D=E9but du message r=E9exp=E9di=E9 :

De: internet-drafts@ietf.org
<= /span>
Objet: = New Version = Notification for draft-gerla-manet-odmrp-02.txt
Date: 5 mars 2014 11:53:33 = UTC
=C0: = "William Su" <william.su@boeing.com>, = "Yunjung Yi" <unknown-email-Yunj= ung-Yi@ietfa.amsl.com>, "Axel Coli Verdiere" <axel@axelcdv.com>, "Sung-Ju Lee" = <unknown-email-Sun= g-Ju-Lee@ietfa.amsl.com>, Mario Gerla <gerla@cs.ucla.edu>, "Professor = Mario Gerla" <gerla@cs.ucla.edu>, William Su = <william.su@boeing.com>, = Axel Colin de Verdiere <axel@axelcdv.com>
=

A new version of I-D, draft-gerla-manet-odmrp-02.txt
has = been successfully submitted by Axel Colin de Verdiere and posted to = the
IETF repository.

Name: = draft-gerla-manet-odmrp
Revision: 02
Title: On-Demand = Multicast Routing Protocol (ODMRP) for Ad Hoc Networks
Document = date: = 2014-03-05
Group: Individual = Submission
Pages: 30
URL: =            http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-02.txtStatus:         https:/= /datatracker.ietf.org/doc/draft-gerla-manet-odmrp/
Htmlized: =       http://tool= s.ietf.org/html/draft-gerla-manet-odmrp-02
Diff: =           htt= p://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-02

Abst= ract:
  The On-Demand Multicast Routing Protocol (ODMRP) = is a multicast
  routing protocol designed for ad hoc = networks with mobile hosts.
  ODMRP is a mesh-based, = rather than a conventional tree-based,
  multicast scheme = and uses a forwarding group concept (only a subset
  of = nodes forwards the multicast packets via scoped flooding).  It
=   applies on-demand procedures to dynamically build routes and = maintain
  multicast group membership.  ODMRP is well = suited for ad hoc wireless
  networks with mobile hosts = where bandwidth is limited, topology
  changes frequently = and rapidly, and power is constrained.




Please note = that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_BEA7EE55-7283-4BE2-A4DD-115B1D6E798C-- From nobody Wed Mar 5 05:23:28 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE4A1A047E for ; Wed, 5 Mar 2014 05:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdiGkEFTQ5dF for ; Wed, 5 Mar 2014 05:23:25 -0800 (PST) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 49C611A0078 for ; Wed, 5 Mar 2014 05:23:25 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id pa12so1046926veb.0 for ; Wed, 05 Mar 2014 05:23:21 -0800 (PST) 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=kKbrGdUIV8GStKw3HxE+N1FdDapRK1r1fe3KQxTHkgM=; b=xjWfxUfyflcDOc4VPgdDLMgDGb+4J/nZ8AATqE8GFD6CL+PyGo+yQfYXKUKObf44sP QTCEn8T8MrbMG7h1CF6Jgcxu6VwyZ1fUZLFhQZwKgXv6IxBMtDHiMjZcZngbmnVm3xtC xO4C4sTCBdwBVqMjUW32azAQtXbzE1vKhiv+g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kKbrGdUIV8GStKw3HxE+N1FdDapRK1r1fe3KQxTHkgM=; b=m0rdC5NpWgRflah5cBJ1J2GYDeYo6lRTuO9XQuOxuCG3Kzn8XnAzMqd5q0Bw7eG7Nu rl3SX8hwU4xtGLjB4V/F4eqkqnxqsN0bUlbFCjzklkWFAS21jn8JFgPZm62O1m+oryCk WfTArZ33G5/ZqqoH+D10h1yLQ4VPHPS/1WgkpiDfqssDsG4Y+fGGuwIRI2DnYBJw3VJe lMybKLpzF3zCnHz0YdHI61/S1vANXwvWGDW9QmGrAyerBxute/E2hBW5TIzTSk+IwRBz gfPytJhOWCoyfh1hGv5QEXGEjPh7pNfSXdO4/H2LL1PVjzdxoutg5j1UFs3OZwZT9/3+ H1Zg== X-Gm-Message-State: ALoCoQkHxUQ71lecXRLnev5GisRLfF5hRuuyJ61MW+lXGsjTOoPsup4lKh7UzAx6eaRrKeN51P56 MIME-Version: 1.0 X-Received: by 10.220.47.10 with SMTP id l10mr92034vcf.56.1394025801522; Wed, 05 Mar 2014 05:23:21 -0800 (PST) Received: by 10.220.230.9 with HTTP; Wed, 5 Mar 2014 05:23:21 -0800 (PST) In-Reply-To: References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> Date: Wed, 5 Mar 2014 13:23:21 +0000 Message-ID: From: Ulrich Herberg To: Teco Boot Content-Type: multipart/alternative; boundary=001a11c2a58cb55e0804f3dbeca9 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/e43u6Bu6fnR5ZPWEu__aa3HM5CQ Cc: MANET IETF , Stan Ratliff Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:23:27 -0000 --001a11c2a58cb55e0804f3dbeca9 Content-Type: text/plain; charset=ISO-8859-1 Hi, I also support adoption of the document. Regarding the name, I am not sure I understand the proposal. Do you suggest to rename it to draft-*ietf*-manet-olsrv2-dat-metric, or draft-*rogge*-manet-olsrv2-dat-metric? (i.e., to rename the draft while it is still an individual draft or when submitting it as WG document should it be adopted). Regards Ulrich On Wed, Mar 5, 2014 at 11:23 AM, Teco Boot wrote: > May I suggest to rename to draft-manet-olsrv2-dat-metric? > > Teco > > Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) > het volgende geschreven: > > > Working Group Participants, > > > > The consensus in the room this morning at IETF 89 is to accept this as a > working group document. If there is opposition to this action, please > respond on the list no later than March 7, 2014. > > > > Regards, > > Stan > > _______________________________________________ > > 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 > --001a11c2a58cb55e0804f3dbeca9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I also support adoption of the document.
Regarding the name, I am not sure I understand the proposal. Do= you suggest to rename it to draft-ietf-manet-olsrv2-dat-metric, or = draft-rogge-manet-olsrv2-dat-metric? (i.e., to rename the draft whil= e it is still an individual draft or when submitting it as WG document shou= ld it be adopted).

Regards
Ulrich


On Wed, Mar 5, 2014 at 11:23 AM, Teco Boot <teco@inf-net.n= l> wrote:
May I suggest to rename to draft-manet-olsrv= 2-dat-metric?

Teco

Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) <sratliff@cisco.com> het volgende geschreven:

> Working Group Participants,
>
> The consensus in the room this morning at IETF 89 is to accept this as= a working group document. If there is opposition to this action, please re= spond on the list no later than March 7, 2014.
>
> Regards,
> Stan
> _______________________________________________
> 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

--001a11c2a58cb55e0804f3dbeca9-- From nobody Wed Mar 5 05:30:23 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886421A00BC for ; Wed, 5 Mar 2014 05:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqL4K9lW8DMR for ; Wed, 5 Mar 2014 05:30:17 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 84C571A00C2 for ; Wed, 5 Mar 2014 05:30:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 49B071E24CD; Wed, 5 Mar 2014 05:30:12 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-hotel-wifi-156-3d.meeting.ietf.org (unknown [130.129.156.61]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8D03D1E24CB; Wed, 5 Mar 2014 05:30:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_049FFABF-64B4-4B83-8F73-853E14F20D4F" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Heide Clausen In-Reply-To: Date: Wed, 5 Mar 2014 14:30:08 +0100 Message-Id: <7C036ECC-2F78-4B6E-97FB-89D372EFBFE7@thomasclausen.org> References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/EyFbY4v4csBFwiI7pgU652hrW8A Cc: MANET IETF , Stan Ratliff Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:30:21 -0000 --Apple-Mail=_049FFABF-64B4-4B83-8F73-853E14F20D4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ulrich, Spinning through another draft-rogge- just for renaming does seem a = little excessive. I believe that the tracker can easily get populated = with appropriate "replaced by" information, regardless of name changes. Thomas On 05 Mar 2014, at 14:23 , Ulrich Herberg wrote: > Hi, >=20 > I also support adoption of the document. >=20 > Regarding the name, I am not sure I understand the proposal. Do you = suggest to rename it to draft-ietf-manet-olsrv2-dat-metric, or = draft-rogge-manet-olsrv2-dat-metric? (i.e., to rename the draft while it = is still an individual draft or when submitting it as WG document should = it be adopted).=20 >=20 > Regards > Ulrich >=20 >=20 > On Wed, Mar 5, 2014 at 11:23 AM, Teco Boot wrote: > May I suggest to rename to draft-manet-olsrv2-dat-metric? >=20 > Teco >=20 > Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) = het volgende geschreven: >=20 > > Working Group Participants, > > > > The consensus in the room this morning at IETF 89 is to accept this = as a working group document. If there is opposition to this action, = please respond on the list no later than March 7, 2014. > > > > Regards, > > Stan > > _______________________________________________ > > 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=_049FFABF-64B4-4B83-8F73-853E14F20D4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Ulrich,

Spinning through another = draft-rogge- just for renaming does seem a little excessive. I believe = that the tracker can easily get populated with appropriate "replaced by" = information, regardless of name = changes.

Thomas

On 05 = Mar 2014, at 14:23 , Ulrich Herberg <ulrich@herberg.name> = wrote:

Hi,

I also support adoption = of the document.

Regarding the name, I am not sure I = understand the proposal. Do you suggest to rename it to = draft-ietf-manet-olsrv2-dat-metric, or = draft-rogge-manet-olsrv2-dat-metric? (i.e., to rename the draft = while it is still an individual draft or when submitting it as WG = document should it be adopted).

Regards
Ulrich


On Wed, Mar 5, 2014 at 11:23 AM, Teco Boot <teco@inf-net.nl> wrote:
May I suggest to = rename to draft-manet-olsrv2-dat-metric?

Teco

Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) <sratliff@cisco.com> het = volgende geschreven:

> Working Group Participants,
>
> The consensus in the room this morning at IETF 89 is to accept this = as a working group document. If there is opposition to this action, = please respond on the list no later than March 7, 2014.
>
> Regards,
> Stan
> _______________________________________________
> 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=_049FFABF-64B4-4B83-8F73-853E14F20D4F-- From nobody Wed Mar 5 05:33:15 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A781A00C2 for ; Wed, 5 Mar 2014 05:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NO7AmPxevn0 for ; Wed, 5 Mar 2014 05:33:12 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 39EA41A0041 for ; Wed, 5 Mar 2014 05:33:12 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id ij19so594529vcb.10 for ; Wed, 05 Mar 2014 05:33:08 -0800 (PST) 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=kQhEbxBJH/a/bz6Y2pq8folGJC/Aw/i/uVeBEBEDqC8=; b=11MkP71xfjIBP/PT/w4N6TcBTvsaLc8OWF1O+CPdcBd0y64IKHRko7tFgRPI1d05Dc F0PzvvvL3iSxhgN7jyGEgnw1fjklEF+N2FOezmfey71w29ZIIncfj65tTSwPe3s+zvP3 QJDGuxzJRCEcjFJ1A2+BQzyzAgqwwLlZSm0Rc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kQhEbxBJH/a/bz6Y2pq8folGJC/Aw/i/uVeBEBEDqC8=; b=Ko1w909qgmrCsaQ7ZAeMFwSuuSwodFSjlHBGT9ggiMS09oBHNWdNpeA3BWUuI7xoZt uW3WfZ7rE6aAmtXOBhI4iicjcAXMVmfKW8gv9KaEKPgFaxvGCudod4E6FuX+OkFj16U+ JpencdtaGes+EdR6MWnpn+a1tBPrsoQRd6HUJ3mwLfFzJURFN/M8gCwBHn5x+SJSA4+d CtYax5/7vA06/R6WmheQPYgB5ctXY3JjuPnpc15Cj1M6SU7TNmYTmC4iURVf2XqEDQww D1VAgyo1cYvZ5gfj1xolVIg70ujfUnn3re++Y2CbcFpnCljsSH6dpKENgrmWy1YUioAx MXeQ== X-Gm-Message-State: ALoCoQklqq1c9D/2SiyafC+NuoI2nnEh2MnMKWLXoPO51B4oWYiDzlFPpO2UNxtT+WH3USM9Uq01 MIME-Version: 1.0 X-Received: by 10.58.200.168 with SMTP id jt8mr348634vec.30.1394026388496; Wed, 05 Mar 2014 05:33:08 -0800 (PST) Received: by 10.220.230.9 with HTTP; Wed, 5 Mar 2014 05:33:08 -0800 (PST) In-Reply-To: <7C036ECC-2F78-4B6E-97FB-89D372EFBFE7@thomasclausen.org> References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> <7C036ECC-2F78-4B6E-97FB-89D372EFBFE7@thomasclausen.org> Date: Wed, 5 Mar 2014 13:33:08 +0000 Message-ID: From: Ulrich Herberg To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=047d7bd6bd76b1cb2f04f3dc0f54 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CrqusNMxx1vvkQ6DbpgjAaJQjzI Cc: MANET IETF , Stan Ratliff Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:33:14 -0000 --047d7bd6bd76b1cb2f04f3dc0f54 Content-Type: text/plain; charset=ISO-8859-1 Thomas, yes, that's what I thought, too. It's just that Teco suggested to rename it to draft-manet-... (without ietf or rogge after "draft"). It's of course not a requirement for an individual draft. I just wanted to make sure I understand the proposal correctly. I also suggest to not rename the current draft, but when submitting it as WG document (if that is the consensus of the WG). Once the draft is uploaded, I can set the "replaced by" accordingly. Regards Ulrich On Wed, Mar 5, 2014 at 1:30 PM, Thomas Heide Clausen < thomas@thomasclausen.org> wrote: > Ulrich, > > Spinning through another draft-rogge- just for renaming does seem a little > excessive. I believe that the tracker can easily get populated with > appropriate "replaced by" information, regardless of name changes. > > Thomas > > On 05 Mar 2014, at 14:23 , Ulrich Herberg wrote: > > Hi, > > I also support adoption of the document. > > Regarding the name, I am not sure I understand the proposal. Do you > suggest to rename it to draft-*ietf*-manet-olsrv2-dat-metric, or draft- > *rogge*-manet-olsrv2-dat-metric? (i.e., to rename the draft while it is > still an individual draft or when submitting it as WG document should it be > adopted). > > Regards > Ulrich > > > On Wed, Mar 5, 2014 at 11:23 AM, Teco Boot wrote: > >> May I suggest to rename to draft-manet-olsrv2-dat-metric? >> >> Teco >> >> Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) < >> sratliff@cisco.com> het volgende geschreven: >> >> > Working Group Participants, >> > >> > The consensus in the room this morning at IETF 89 is to accept this as >> a working group document. If there is opposition to this action, please >> respond on the list no later than March 7, 2014. >> > >> > Regards, >> > Stan >> > _______________________________________________ >> > 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 > > > --047d7bd6bd76b1cb2f04f3dc0f54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thomas,

yes, that's what I= thought, too. It's just that Teco suggested to rename it to draft-mane= t-... (without ietf or rogge after "draft"). It's of course n= ot a requirement for an individual draft. I just wanted to make sure I unde= rstand the proposal correctly.
I also suggest to not rename the current draft, but when submitting i= t as WG document (if that is the consensus of the WG). Once the draft is up= loaded, I can set the "replaced by" accordingly.

Regards
Ulrich


On Wed, Mar 5, 2014 at 1:30 PM, Thomas Heide Clause= n <thomas@thomasclausen.org> wrote:
Ulrich,<= div>
Spinning through another draft-rogge- just for renaming = does seem a little excessive. I believe that the tracker can easily get pop= ulated with appropriate "replaced by" information, regardless of = name changes.

Thomas

On 05 Mar 2014,= at 14:23 , Ulrich Herberg <ulrich@herberg.name> wrote:

Hi,

I also suppo= rt adoption of the document.

Regarding the name, I am not sure= I understand the proposal. Do you suggest to rename it to draft-ietf-manet-olsrv2-dat-metric, or draft-rogge-manet-olsrv2-dat-metric? (= i.e., to rename the draft while it is still an individual draft or when sub= mitting it as WG document should it be adopted).

Regards
Ulrich


On Wed, Mar 5, 2014 at 11:23 AM, Teco Boot <teco@inf-net.n= l> wrote:
May I suggest to rename to draft-manet-olsrv= 2-dat-metric?

Teco

Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) <sratliff@cisco.com> het volg= ende geschreven:

> Working Group Participants,
>
> The consensus in the room this morning at IETF 89 is to accept this as= a working group document. If there is opposition to this action, please re= spond on the list no later than March 7, 2014.
>
> Regards,
> Stan
> _______________________________________________
> 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
http= s://www.ietf.org/mailman/listinfo/manet


--047d7bd6bd76b1cb2f04f3dc0f54-- From nobody Wed Mar 5 05:48:18 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B071A017C for ; Wed, 5 Mar 2014 05:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ6RkgltSW1d for ; Wed, 5 Mar 2014 05:48:14 -0800 (PST) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2451A02AD for ; Wed, 5 Mar 2014 05:48:14 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id jx11so1049198veb.31 for ; Wed, 05 Mar 2014 05:48:10 -0800 (PST) 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=RpAaL38prePwTZ70Zaj8EiiYnsx/yx5vmwZiiQNKddw=; b=nz3yAzm2JZbNEA+MmGQC0laXyFdmayqcad6wRNXZB0lwYYiI8FbZLVt9kT8LogtzMv uEd51v1mnqjEF97vmcchAG7RyU+JzeX+3gzwWHVN4VzBfRFv0v5P5Yvt6sXNN9WlXRWL yBVG7z61PdC0rsjikmalB8TnTh87iRgNblj8I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=RpAaL38prePwTZ70Zaj8EiiYnsx/yx5vmwZiiQNKddw=; b=epZnk10LGDFXzHPKzMg/QLHBQbDNY5RQUo9FKEsGmyXNWu4wHTkl12eBS5Kfuzejrc SmnsDhXOsGlmg/CX8lid4XRXVuKXFmQ6n5qsotxh5czStibBBWK2Yrh5UtX6olw7aiwH LwW6mbn/6RnBP/ucwfV8LxwTAgwm+/pIoH1ogSnDBBTRpy36NqKKlxv45Hc5tJ5a28Xe eLql3pJKbMpVyjpuJPbS5k6ArQsqru9oWRwutlmcMZZivguIXIRWtZobZ7wfasFwLI9J cH+HdTMvEXZ90EX2BWzJpXY/ssy3cMpfniuXR7wgCcHRLYugIw/08nrhHEn15ve/jW7i ARcQ== X-Gm-Message-State: ALoCoQmINduTerOL6A3801Mz50dR5J4TDVU3pv7dN9kRIUP5FlUWgqOVHmV64Vz0YGmw7D4gv7A4 MIME-Version: 1.0 X-Received: by 10.58.37.232 with SMTP id b8mr320192vek.27.1394027290464; Wed, 05 Mar 2014 05:48:10 -0800 (PST) Received: by 10.220.230.9 with HTTP; Wed, 5 Mar 2014 05:48:10 -0800 (PST) Date: Wed, 5 Mar 2014 13:48:10 +0000 Message-ID: From: Ulrich Herberg To: manet@ietf.org, Thomas Clausen Content-Type: multipart/alternative; boundary=089e01176de574a6b104f3dc45dd Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek Subject: [manet] OLSRv2 + RFC6971 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:48:15 -0000 --089e01176de574a6b104f3dc45dd Content-Type: text/plain; charset=ISO-8859-1 Thomas, I apologize that your last presentation slot fell under the table today because of lack of time. As this work interests me personally (as editor of RFC6971), can I ask you to give a bit of context on the mailing list? The slides are already in the proceedings, so they are available for download (as I mentioned as part of the OLSRv2 + extensions package). Thanks Ulrich --089e01176de574a6b104f3dc45dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thomas,

I apologize that your last = presentation slot fell under the table today because of lack of time. As th= is work interests me personally (as editor of RFC6971), can I ask you to gi= ve a bit of context on the mailing list? The slides are already in the proc= eedings, so they are available for download (as I mentioned as part of the = OLSRv2 + extensions package).

Thanks
Ulrich
--089e01176de574a6b104f3dc45dd-- From nobody Wed Mar 5 06:02:33 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E0F1A0052 for ; Wed, 5 Mar 2014 06:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfD4NKpk4haS for ; Wed, 5 Mar 2014 06:02:29 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A34B21A0043 for ; Wed, 5 Mar 2014 06:02:29 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id if11so1030767vcb.22 for ; Wed, 05 Mar 2014 06:02:26 -0800 (PST) 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=rRs3b4LhoQSd/eNck7O8rfOthSaJYGr9u5116XKcPEk=; b=DymX62CoBdmzf2C5+KqKA3gesxs6sf2waTb7suQcRkhfU6ihwk87oZJ68Nbn2ZKLne t2kyOet8Ljq7G9jabfsnuE2+p1BXVgWT/PIBsmMbqHVeEw3ZGIQakr84DpOYhLcOBxf/ 0KTy1G68OxV6yqFhqH/urdxIA7zTpfJnoVgEU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=rRs3b4LhoQSd/eNck7O8rfOthSaJYGr9u5116XKcPEk=; b=fnQljS1QxTv6HJ9N4SgNfuusuJLN0BJR99oijwVCHiflu+g8DGT5L53CcrmvkXzMUg QHPdI4YtPPgSK4evkx/lID823RbsC+vad6AMtOGEysbkO4ZqLDYiehcF23e3GpjuhjC7 So1fj5chHig0Sn8ZXkcg/vRgFI4IF4vsr+2iqBH5uY3WUSIE4mnqqTHe8kZVnYOuRes8 G/ggwC6W1XXPvisnW4uAtBy0XAgcATM+qD9zrsQ3jKMc2pYM7HqU4bcMTTK+SMsu0M6Y 42HKaQbjZ6XqB8LNHr//j0IJiqqSjllB6Rg/zyGJ2Fv8JD7Ou9zpr/Nd6YabFUwzQmFJ Ojmg== X-Gm-Message-State: ALoCoQk9eVzaPlruUYLr01dPLhytWbr9LWtrK0/xZdmSEAFsIAJ3Zb0THKQ7jICC0bBIpTUfPZer MIME-Version: 1.0 X-Received: by 10.52.166.103 with SMTP id zf7mr1265983vdb.30.1394028145917; Wed, 05 Mar 2014 06:02:25 -0800 (PST) Received: by 10.220.230.9 with HTTP; Wed, 5 Mar 2014 06:02:25 -0800 (PST) Date: Wed, 5 Mar 2014 14:02:25 +0000 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a11c2c10272081b04f3dc7829 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/1yGhfxQ1w6kX1wllBIkXaxHa8eI Subject: [manet] Writable MIB Module IESG Statement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 14:02:31 -0000 --001a11c2c10272081b04f3dc7829 Content-Type: text/plain; charset=ISO-8859-1 Hi, As I mentioned during the meeting, please have a look at a statement from the IESG related to writable MIB modules: http://www.ietf.org/iesg/statement/writable-mib-module.html While the OLSRv2-MIB and NHDP-MIB are writable, they will not be affected as they are already completed. But it may have impact on management for other protocols developed in this WG. Best regards Ulrich --001a11c2c10272081b04f3dc7829 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

As I mentioned during the meeting, please = have a look at a statement from the IESG related to writable MIB modules:
While the OLSRv2-MIB and NHDP-MIB are writable, they will no= t be affected as they are already completed. But it may have impact on mana= gement for other protocols developed in this WG.

Best reg= ards
Ulrich
--001a11c2c10272081b04f3dc7829-- From nobody Wed Mar 5 06:05:37 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85C41A03AC for ; Wed, 5 Mar 2014 06:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cTqN-aZimJS for ; Wed, 5 Mar 2014 06:05:33 -0800 (PST) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id CBEDC1A0221 for ; Wed, 5 Mar 2014 06:05:32 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id jw12so1051287veb.23 for ; Wed, 05 Mar 2014 06:05:29 -0800 (PST) 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=jn/ZAJuHd59GsnFQ4MfNyZLqf9rvqsB08p9GtDt+gCg=; b=gxWw9efmCgIvig6h9iMk7DNK+KjR1iK20mKZ9HXREzgMJgC66ZvpaJvZBBMGced9VH jbINR9Q3M9G/zoqBcCByN2hL+z+zzCCYKyAUrDZCHNet+f2DEEtzzdxsCb97KgJU/hY4 ih4oB4XT7IuPQbfidr8k2/USldHpLedBnNtJs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=jn/ZAJuHd59GsnFQ4MfNyZLqf9rvqsB08p9GtDt+gCg=; b=HRN0l3SCoOXBNVktxDQN4kV8LgJ08tu1z/LjkC6grTbDIcEOlHRg39n0rntYpMDmjC RxRPu2EGrstAK0wLblnjsxaGVjTgWxZWMbK7nDh3y5OTAO3QfwDTT6N7p1OcN0KzAOnm 3NlriLQMmOIomc572LE0T+UVnOVyuBYOJwRhm25zmk06hq52if8DV4TaoqVyrPsf/rtl SJlDn87CmIDFWg1eIMWptIUKCa55uaEjn5ej8SaN1R3DF7mXYf0y36KCaJHMU6mudK3k Di61SC0aZiY6pHy/GyC4JUhjfRrIpDOjcVo9HSR+S7XUxrYAHSFjHUr7JhR4Sr0g67rj Melg== X-Gm-Message-State: ALoCoQlEaGLHg2r3dEVZYhvGZRByxa83GzOuWsssL8h9nQhieRQ+8ytXdYYJ/inNqPCUx8SQAXt7 MIME-Version: 1.0 X-Received: by 10.220.159.4 with SMTP id h4mr184722vcx.1.1394028329080; Wed, 05 Mar 2014 06:05:29 -0800 (PST) Received: by 10.220.230.9 with HTTP; Wed, 5 Mar 2014 06:05:29 -0800 (PST) Date: Wed, 5 Mar 2014 14:05:29 +0000 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a11c2ca0c5cb15a04f3dc8388 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/fJBU51wOWHcQrtOpHoDlwrTcTrg Subject: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 14:05:34 -0000 --001a11c2ca0c5cb15a04f3dc8388 Content-Type: text/plain; charset=ISO-8859-1 Dear WG chairs, as we mentioned during the MANET meeting, Thomas and I would like to request to get a consensus call on the mailing list for WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01. Best regards Ulrich --001a11c2ca0c5cb15a04f3dc8388 Content-Type: text/html; charset=ISO-8859-1
Dear WG chairs,

as we mentioned during the MANET meeting, Thomas and I would like to request to get a consensus call on the mailing list for WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01.

Best regards
Ulrich
--001a11c2ca0c5cb15a04f3dc8388-- From nobody Wed Mar 5 07:49:40 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF511A00DA; Wed, 5 Mar 2014 07:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZfWi-LoSFYT; Wed, 5 Mar 2014 07:49:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E771A0747; Wed, 5 Mar 2014 07:49:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140305154926.4432.21589.idtracker@ietfa.amsl.com> Date: Wed, 05 Mar 2014 07:49:26 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/fUAvLznguYNAwgkUTYsjQxIrMX4 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-tlv-extension-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 15:49:34 -0000 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 : Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-olsrv2-tlv-extension-05.txt Pages : 18 Date : 2014-03-05 Abstract: This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP), to increase their abilities to accommodate protocol extensions. This document updates OLSRv2 and RFC6130. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-tlv-extension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-olsrv2-tlv-extension-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-olsrv2-tlv-extension-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 5 08:48:03 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457E21A063D for ; Wed, 5 Mar 2014 08:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vryog1NIgjlX for ; Wed, 5 Mar 2014 08:47:59 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 20F131A0140 for ; Wed, 5 Mar 2014 08:47:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D3B982432FE; Wed, 5 Mar 2014 08:47:55 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-hotel-wifi-156-3d.meeting.ietf.org (unknown [130.129.156.61]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id B79F1241000; Wed, 5 Mar 2014 08:47:54 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Heide Clausen In-Reply-To: Date: Wed, 5 Mar 2014 17:47:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vu8C_afi_nrCJxCQD7PmkZ0JURY Cc: MANET IETF Subject: Re: [manet] OLSRv2 + RFC6971 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:48:01 -0000 Dear Ulrich, all, On 05 Mar 2014, at 14:48 , Ulrich Herberg wrote: > Thomas, > I apologize that your last presentation slot fell under the table = today because of lack of time. Such are the rules of the game: time is at a premium in face to face = meetings, and it was more important to spend that time to discuss WG = items and new items that might be immediate actions for the WG. This = presentation was "for your information" (the "collective your", that = is). > As this work interests me personally (as editor of RFC6971), can I = ask you to give a bit of context on the mailing list? The slides are = already in the proceedings, so they are available for download (as I = mentioned as part of the OLSRv2 + extensions package). >=20 > Thanks > Ulrich A bit of context: RFC6971 - also know as DFF, among friends - is an = experimental mechanism which works below the IP layer and above the link = layer. It's raison d'etre is to improve data delivery in case the = intended next-hop (as indicated by the routing table) is somehow not = reachable, and do so before a routing protocol "catches up" and repairs = the routing topology. DFF does this by way of (at the router from where = the next hop was not reachable) engaging a "depth first forwarding" = mechanism. I'll let you read the RFC for further details, but my = colleagues and I thought it a quite clever trick. Consequently, we went ahead and implemented it and tested it, with both = LOADng and OLSRv2. We tested across two scenarios: one MANET with highly (artificially) = lossy links, but otherwise no router mobility; another MANET with = "normal" links but with router mobility.=20 The slides contain simulation results for LOADng in a MANET with = intentionally lossy links -- whereas for OLSRv2, the results displayed = in the slides are from the MANET with router mobility. There's really no = significance to the choice of which scenario for which protocol, other = than to - precisely - not engage in routing protocol comparisons = here....that's NOT the goal, and so we want to steer the discussion = around that potential rathole by way of the results presented. We actually didn't try to be particularly clever in what we did in = integrating DFF with the two protocols: there are more fancy heuristics = possible than those we implemented, especially for when using DFF with = OLSRv2. Even so the results turned out interesting: improved data = delivery rates across the board, and no (observed, at least) harmful = effects.=20 (OK, we did try to be a little bit clever by inventing an extension to = DFF, which we called DFF++ -- but it's possible to be even more clever = than that, with a little effort) =46rom the OLSRv2-results, we chose the catchphrase (and the title of = the presentation) "success before convergence" since it turned out that = the combination OLSRv2+DFF enabled data delivery "success" across the = last couple of hops while the (HELLO) message exchange of OLSRv2 was = catching up with a local topology change due to router mobility. But, look at the results in the presentation (and, perhaps, the papers = cited in the presentation with more data), and judge for yourself. = Actually, I'll be even more user-friendly than Ulrich, and throw in (for = free) a link to the slides here: http://tools.ietf.org/agenda/89/slides/slides-89-manet-7.pdf Now, we thought it interesting to bring these results to the attention = of the WG for the following reasons: o It helps both LOADng and OLSRv2, and in both scenarios = where there are packet losses=20 on the links and when the topology changes dynamically = due to mobility o It's relatively simple to implement o It doesn't entail any additional control signals o It doesn't require any modifications to the routing = protocols Given that RFC6971 is an *experimental* RFC, we thought that we would = bring the results of our *experiments* to the attention of the IETF; = after all, that's the whole point of the IEF publishing *experimental* = RFCs ... At this juncture, we'd much hope that our initial results are = interesting enough to encourage others to experiment with this = mechanism, and to report back in a similar vein.=20 Also at this juncture, we're not actually suggesting any WG actions to = be taken. We would suggest - and, of course, yield to the decision of the WG = chairs on this matter - that this WG and mailing list might be a place = to report and discuss such experiments and results, for when applying = DFF in conjunction with MANET routing protocols? Longer-term, and depending on how the experiments progress, there may be = things that could be considered for WG actions. These may include = bringing DFF towards standards track, documenting DFF++, documenting = more "clever heuristics" than what we did initially (as informational = documents) if some turn out to be particularly useful (or, conversely, = documenting heuristics that turn out to be particularly harmful), etc.=20= I'm glad that Ulrich "came out of the closet" as the editor of RFC6971, = since that gives me an excuse to hive answering questions to the = intricate details of DFF off to him: the mechanism is dead-simple, but = the reasoning behind it has its details that he's probably a lot better = equipped to answer questions to, than am I. Hope this answers your question, triggers interest, and gets all y'all = a-coding, such that we may have more data to mull over soon. Best, Thomas From nobody Wed Mar 5 11:52:07 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC7B1A0242 for ; Wed, 5 Mar 2014 11:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBBFgao2MlTr for ; Wed, 5 Mar 2014 11:52:02 -0800 (PST) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id C132A1A0247 for ; Wed, 5 Mar 2014 11:52:02 -0800 (PST) Received: by mail-yh0-f48.google.com with SMTP id z6so1581970yhz.7 for ; Wed, 05 Mar 2014 11:51:59 -0800 (PST) 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=3LpV7gIKFe4LEaFCeLhMKvY0ZWLqzlKvKh7dR9iuoxM=; b=dACVt6Z+leDoAvNAIoNFQM1IzI1ke/iU4duzSIaagNOwUeSv/S/22J3jiquDvLB3Jp KEcBgYmIIELt5ciZGy7e5GY3kMTjHC2h5GYJ0LrycFNwKdbkl/nN/lx47CfVqwH7Kg+R D5GwK7yFkpfudEZkhALU22M+uLn3bKqIuyXkWNoNMk3AyHljTdyIdco+D2lbW8MQanfp vqb0Yw/M+3pEiWFF9jZwlR2ymHvlMluNB4zLeid6poDRY88RaebNMss9NXOGrxn+/qsD FnbOl9aBuT1yO3hCR24A7oyfCrRNcy9XL7HXjcUQJ4B0aPm+zeXqxhkVFL4uwcEsyhzk LaZQ== MIME-Version: 1.0 X-Received: by 10.236.191.130 with SMTP id g2mr2526993yhn.160.1394049119064; Wed, 05 Mar 2014 11:51:59 -0800 (PST) Received: by 10.170.202.7 with HTTP; Wed, 5 Mar 2014 11:51:59 -0800 (PST) In-Reply-To: References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> Date: Wed, 5 Mar 2014 20:51:59 +0100 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: multipart/alternative; boundary=20cf30563d578a9c8204f3e15ab1 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xNsneJiVKzgUf99OO1a3L3vpEGc Cc: MANET IETF , Stan Ratliff Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 19:52:05 -0000 --20cf30563d578a9c8204f3e15ab1 Content-Type: text/plain; charset=ISO-8859-1 Hi Teco I thought you and Henning agreed that it is not must related to OLSRv2. However, I don't mind your suggestion. AB On Wednesday, March 5, 2014, Teco Boot wrote: > May I suggest to rename to draft-manet-olsrv2-dat-metric? > > Teco > > Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) > > het volgende geschreven: > > > Working Group Participants, > > > > The consensus in the room this morning at IETF 89 is to accept this as a > working group document. If there is opposition to this action, please > respond on the list no later than March 7, 2014. > > > > Regards, > > Stan > > _______________________________________________ > > 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 > --20cf30563d578a9c8204f3e15ab1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco

I thought you and Henning agreed that it is not = must=A0related to OLSRv2. However, I don't mind your suggestion.=A0

AB

On Wednesday, March 5, 2014, Teco Boot wro= te:
May I suggest to rename to draft-manet-olsrv= 2-dat-metric?

Teco

Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) <manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--20cf30563d578a9c8204f3e15ab1-- From nobody Wed Mar 5 12:11:38 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9F61A0251 for ; Wed, 5 Mar 2014 12:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0kUc0-ugSDk for ; Wed, 5 Mar 2014 12:11:30 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 533221A048F for ; Wed, 5 Mar 2014 12:11:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4095; q=dns/txt; s=iport; t=1394050287; x=1395259887; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XLXxVjQToNapK2UtMWWUWKP4KGmAYIgJuTy7ypQ1uO8=; b=OxbCXn/VIbJK0DDr8TGMkQg8oMduZhnm3OWV5RQUYa3X1l7iOAlBmBnX r6Av87qSTV1UfvdF+ahkYGbsCkYwdM3LS+1x5GjXU5EM+EZ9/8FmCry9H hpg4312wE0ohkYIcp2Zb4mSaJliP92/0YMKKssTg027AdLksMEeH9Xfya A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAC2EF1OtJV2d/2dsb2JhbABagwY7V8ENgRoWdIIlAQEBAwEBAQFrCwULAgEIBDsHIQYLFBECBA4Fh2UDCQgNyAMNhlATAQMGAYw1ghEEB4MkgRQEiRONPYFtjGOFSIMtgio X-IronPort-AV: E=Sophos; i="4.97,594,1389744000"; d="scan'208,217"; a="25177561" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 05 Mar 2014 20:11:26 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s25KBQ25021709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 20:11:26 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.172]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 14:11:26 -0600 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] draft-rogge-baccelli-olsrv2-ett-metric Thread-Index: AQHPOGPJiA8bCyFNB0iARcfb9cD77prSvlUAgACONYCAAAVFAA== Date: Wed, 5 Mar 2014 20:11:25 +0000 Message-ID: References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@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.82.231.108] Content-Type: multipart/alternative; boundary="_000_BBC58CB51CD1476FAAACFD20634C674Bciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2DWaYNPSPzm20xt0LGrS2Q8CWoo Cc: MANET IETF Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:11:36 -0000 --_000_BBC58CB51CD1476FAAACFD20634C674Bciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yeah, I also heard some chatter about uses that are not associated with OLS= Rv2. Having said that, I don't have a strong opinion either way. I'll just = ask - are we sure we want to rename it as an OSLRv2 doc? Regards, Stan On Mar 5, 2014, at 2:51 PM, Abdussalam Baryun > wrote: Hi Teco I thought you and Henning agreed that it is not must related to OLSRv2. How= ever, I don't mind your suggestion. AB On Wednesday, March 5, 2014, Teco Boot wrote: May I suggest to rename to draft-manet-olsrv2-dat-metric? Teco Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) > het volgende geschreven: > Working Group Participants, > > The consensus in the room this morning at IETF 89 is to accept this as a = working group document. If there is opposition to this action, please respo= nd on the list no later than March 7, 2014. > > Regards, > Stan > _______________________________________________ > 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_BBC58CB51CD1476FAAACFD20634C674Bciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9078CB1C633076409434A7262E4E8448@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Yeah, I also heard some chatter about uses that are not associated with OLS= Rv2. Having said that, I don't have a strong opinion either way. I'll just = ask - are we sure we want to rename it as an OSLRv2 doc?

Regards,
Stan

On Mar 5, 2014, at 2:51 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Teco

I thought you and Henning agreed that it is not must related to O= LSRv2. However, I don't mind your suggestion. 

AB

On Wednesday, March 5, 2014, Teco Boot wrote:
May I suggest to rename to draft-manet-olsrv2-dat-metric?

Teco

Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) <sratliff@cisco= .com> het volgende geschreven:

> Working Group Participants,
>
> The consensus in the room this morning at IETF 89 is to accept this as= a working group document. If there is opposition to this action, please re= spond on the list no later than March 7, 2014.
>
> Regards,
> Stan
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

--_000_BBC58CB51CD1476FAAACFD20634C674Bciscocom_-- From nobody Wed Mar 5 12:16:16 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE3A1A045B for ; Wed, 5 Mar 2014 12:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gan1wezYN9CP for ; Wed, 5 Mar 2014 12:16:13 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A690E1A0270 for ; Wed, 5 Mar 2014 12:16:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5864D5804CF; Wed, 5 Mar 2014 12:16:10 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.155.58] (unknown [130.129.155.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C79BC5804CC; Wed, 5 Mar 2014 12:16:09 -0800 (PST) References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-F1759642-123D-4C8E-82BB-5D7FE0A23828 Content-Transfer-Encoding: 7bit Message-Id: <6E6B32A0-55E8-476C-A049-EED875D94E48@thomasclausen.org> X-Mailer: iPhone Mail (11B651) From: Thomas Heide Clausen Date: Wed, 5 Mar 2014 20:16:04 +0000 To: "Stan Ratliff (sratliff)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/nu_075f8eEmpg9g2TSSrjAxzXvo Cc: MANET IETF Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:16:15 -0000 --Apple-Mail-F1759642-123D-4C8E-82BB-5D7FE0A23828 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable We need to scope the experiment correctly so as to get any meaningful result= s and feedback.=20 My experience is that proactive and reactive protocols have and behave *very= * different wrt metrics and I would not bet on being able to get meaningful r= esults from mushing them together willy-nilly.=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 mars 2014, at 20:11, "Stan Ratliff (sratliff)" w= rote: >=20 > Yeah, I also heard some chatter about uses that are not associated with OL= SRv2. Having said that, I don't have a strong opinion either way. I'll just a= sk - are we sure we want to rename it as an OSLRv2 doc? >=20 > Regards, > Stan >=20 >> On Mar 5, 2014, at 2:51 PM, Abdussalam Baryun wrote: >>=20 >> Hi Teco >>=20 >> I thought you and Henning agreed that it is not must related to OLSRv2. H= owever, I don't mind your suggestion.=20 >>=20 >> AB >>=20 >>> On Wednesday, March 5, 2014, Teco Boot wrote: >>> May I suggest to rename to draft-manet-olsrv2-dat-metric? >>>=20 >>> Teco >>>=20 >>> Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) het volgende geschreven: >>>=20 >>> > Working Group Participants, >>> > >>> > The consensus in the room this morning at IETF 89 is to accept this as= a working group document. If there is opposition to this action, please res= pond on the list no later than March 7, 2014. >>> > >>> > Regards, >>> > Stan >>> > _______________________________________________ >>> > 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-F1759642-123D-4C8E-82BB-5D7FE0A23828 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
We need to scope the experiment correc= tly so as to get any meaningful results and feedback. 

My experience is that proactive and reactive protocols have and beh= ave *very* different wrt metrics and I would not bet on being able to get me= aningful results from mushing them together willy-nilly. 
-- 
Thomas Heide Clausen

"Today's scientists have substituted mathematics for 
&nbs= p; experiments, and they wander off through equation 
&n= bsp; after equation, and eventually  build a structure 
=
  which has no relation to reality."
 - Nikola= Tesla, 
    Modern Mechanics and Inventions, J= uly, 1934

On 5 mars 2014, at 20:11, "Stan Ratliff (sratl= iff)" <sratliff@cisco.com> w= rote:

Yeah, I also heard some chatter about uses that are not associated with OLSR= v2. Having said that, I don't have a strong opinion either way. I'll just as= k - are we sure we want to rename it as an OSLRv2 doc?

Regards,
Stan

On Mar 5, 2014, at 2:51 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Teco

I thought you and Henning agreed that it is not must related to OL= SRv2. However, I don't mind your suggestion. 

AB

On Wednesday, March 5, 2014, Teco Boot wrote:
May I suggest to rename to draft-manet-olsrv2-dat-metric?

Teco

Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) <sratliff@cisco.c= om> het volgende geschreven:

> Working Group Participants,
>
> The consensus in the room this morning at IETF 89 is to accept this as a= working group document. If there is opposition to this action, please respo= nd on the list no later than March 7, 2014.
>
> Regards,
> Stan
> _______________________________________________
> manet mailing list
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
man= et@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-F1759642-123D-4C8E-82BB-5D7FE0A23828-- From nobody Wed Mar 5 12:23:31 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C371A0240 for ; Wed, 5 Mar 2014 12:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwGBxTEpC5aq for ; Wed, 5 Mar 2014 12:23:22 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 77D2E1A066A for ; Wed, 5 Mar 2014 12:23:21 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id 19so4080161ykq.7 for ; Wed, 05 Mar 2014 12:23:17 -0800 (PST) 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=rYa0MHIKoqcqKJXzGYCIYFwbGovQofVXQoYO2SMJl7U=; b=etwlVF97hSyu1MhNEEe7Y/NNSc600zlrJxGu36K6/5B39fWct0rYL8wtTZiV4ZyWZm ypnMzZgj2OY89TNBcrelocmFUzHVkubi5QWMORdr46ai9JXLJTz/9x8zxBBTkEVd8B1+ bXC/X/rxcZg5LNNE2bd3n9aMxG2mDiEc7srm/foSf/9YFFOzQ5BJCUk2uu8Py4XLOGOO vmJ/HUdcrSKKkt6Bp2xkEQN8JW3Orow59wbWIXOstpiWtR+cw/gzyaliytcwAXYGaKnM zTrwuZy8X1KFuqpJTSrb4e8l1i9eZhaEdZerDuaqtTCN26dcT5VxFO0BaBohU+86+479 5z+Q== MIME-Version: 1.0 X-Received: by 10.236.157.167 with SMTP id o27mr3910683yhk.127.1394050997687; Wed, 05 Mar 2014 12:23:17 -0800 (PST) Received: by 10.170.202.7 with HTTP; Wed, 5 Mar 2014 12:23:17 -0800 (PST) In-Reply-To: <5317012F.60701@computer.org> References: <5317012F.60701@computer.org> Date: Wed, 5 Mar 2014 21:23:17 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=20cf303f676c841bfb04f3e1ca63 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/KuAjqB8tlbtJjhugC8Zqh_VxAzE Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:23:24 -0000 --20cf303f676c841bfb04f3e1ca63 Content-Type: text/plain; charset=ISO-8859-1 Hi Charles, As I suggested in meeting IMHO we get a schedule plan for submission as long not much clear discussion by the group. Implementing AODVv2 is not a must (this was discussed before) because most already practiced its techniques but when tested within the coming two years it will be better as OLSRv2 taken some years tests after submit. AB --20cf303f676c841bfb04f3e1ca63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Charles,

As I=A0suggested in meeting IMHO=A0we ge= t=A0a schedule plan for submission as long not much clear=A0discussion by t= he group.=A0

Implementing AODVv2 is not a must (th= is was discussed before)=A0because most=A0already practiced=A0its technique= s=A0but when=A0tested within the coming two years=A0it will be=A0better as = OLSRv2 taken some years tests after submit.=A0

AB


--20cf303f676c841bfb04f3e1ca63-- From nobody Wed Mar 5 12:28:49 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786341A0240 for ; Wed, 5 Mar 2014 12:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5shLzGQvzOi for ; Wed, 5 Mar 2014 12:28:45 -0800 (PST) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 977FA1A0175 for ; Wed, 5 Mar 2014 12:28:45 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id hw13so1539508qab.18 for ; Wed, 05 Mar 2014 12:28:41 -0800 (PST) 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=RZ+GaZGX5UB36Ei1EMZbdn7AE2ZrTt9Myfz5cmxOajA=; b=RBvbMuyyeHaJHYjzEaKW7ZxcfSQVuoGDJRjAsp8L0aRCF20S39EKILltgsjOnNAU6R 8VkKxE7hTFxswb652dgtndDD8rwBiJSdAVaaXl/oAdvbJM9eG4ceu+Hi7bPnUkJjWkYB Kf9uMPkspghO1Rc+aXTEJoVH1G49OesjMBUbQsSJtXhZEz+xLM68rKIZV7EyQVBkb2ae TenldCtFp7iJvx9prclKdtxf6e7SgSkRPx2xz0V4ihcr9HxaIo+hjlRREAFVn/Y/rT3C JwNtucxth05i1qXVaXNrLN3Ex9w1eUN9EFUxCf6rHBd3I0H04XrCrdLhx/YTkp+1EeaU 3KYA== X-Received: by 10.140.92.213 with SMTP id b79mr4548188qge.108.1394051321716; Wed, 05 Mar 2014 12:28:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.130.2 with HTTP; Wed, 5 Mar 2014 12:28:21 -0800 (PST) In-Reply-To: References: <5317012F.60701@computer.org> From: Henning Rogge Date: Wed, 5 Mar 2014 20:28:21 +0000 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NToWwsoQ6U12rpRKFNTExSibpfE Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:28:47 -0000 "Implementation is not a most for a standard track document"... that is an "interesting" point of view. Henning Rogge On Wed, Mar 5, 2014 at 8:23 PM, Abdussalam Baryun wrote: > > Hi Charles, > > As I suggested in meeting IMHO we get a schedule plan for submission as long > not much clear discussion by the group. > > Implementing AODVv2 is not a must (this was discussed before) because most > already practiced its techniques but when tested within the coming two years > it will be better as OLSRv2 taken some years tests after submit. > > AB > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed Mar 5 12:32:18 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA3F1A02B6 for ; Wed, 5 Mar 2014 12:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDjftw9dANiN for ; Wed, 5 Mar 2014 12:32:15 -0800 (PST) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C2E501A0227 for ; Wed, 5 Mar 2014 12:32:14 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id f73so1655195yha.31 for ; Wed, 05 Mar 2014 12:32:11 -0800 (PST) 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=hzFFXlm/JMtFahP71hqKxPYwUB4oJ7i18qb3ATdNbMo=; b=fmtY3afM+VoGu/4J+lLMm1ZOOQBjV1D2abpB3y/DOx/JOEHPXOAe8ZO0M1zguSwO7U ikgB/Vv3E8VnfvXIeL9dXTl8/UEAg+GBLccA1fR0wCCF/Vs7uojei31bXt12n8KeewWV jyODIPWFEedGpHtpd4op6NQH6ex6L35/ufJd2mb8oiAeCvuhXeMicPVDaEza7PcsvpAB I8U6te5CNyiH045U7hX7PAK8a6qoAdcwfYUlhCyyqNBBo9euc0spFjSRN9Qz1aH8M8fn VjD8+qKm9hN7uGf+pNtTsf+JQZLncFT7gMrttGA+K7bH/K5qNtsYkECbdMGXOLLj7pFa BZXA== MIME-Version: 1.0 X-Received: by 10.236.131.19 with SMTP id l19mr9886872yhi.0.1394051530591; Wed, 05 Mar 2014 12:32:10 -0800 (PST) Received: by 10.170.202.7 with HTTP; Wed, 5 Mar 2014 12:32:10 -0800 (PST) In-Reply-To: References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> Date: Wed, 5 Mar 2014 21:32:10 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=20cf3010e96d4793fc04f3e1eab0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/sv77GwEb17r4CVIvnGvLyOJ8qsM Cc: MANET IETF Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:32:16 -0000 --20cf3010e96d4793fc04f3e1eab0 Content-Type: text/plain; charset=ISO-8859-1 I really agree more with the author presenting today (Henning) that this work is for both reactive and proactive protocols. So I understood that we adopted it as link-metrics not as metrics for only OLSRv2, of you read the item it's clear I think, AB On Wednesday, March 5, 2014, Stan Ratliff (sratliff) wrote: > Yeah, I also heard some chatter about uses that are not associated with > OLSRv2. Having said that, I don't have a strong opinion either way. I'll > just ask - are we sure we want to rename it as an OSLRv2 doc? > > Regards, > Stan > > On Mar 5, 2014, at 2:51 PM, Abdussalam Baryun > > wrote: > > Hi Teco > > I thought you and Henning agreed that it is not must related to OLSRv2. > However, I don't mind your suggestion. > > AB > > On Wednesday, March 5, 2014, Teco Boot wrote: > >> May I suggest to rename to draft-manet-olsrv2-dat-metric? >> >> Teco >> >> Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) < >> sratliff@cisco.com> het volgende geschreven: >> >> > Working Group Participants, >> > >> > The consensus in the room this morning at IETF 89 is to accept this as >> a working group document. If there is opposition to this action, please >> respond on the list no later than March 7, 2014. >> > >> > Regards, >> > Stan >> > _______________________________________________ >> > 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 >> > > --20cf3010e96d4793fc04f3e1eab0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I really agree more with the author presenting today (Henning)=A0that this = work is for both reactive and proactive protocols. So I understood that we = adopted it as link-metrics=A0not as metrics=A0for only=A0OLSRv2, of you rea= d the item it's clear I think,=A0

AB

On Wednesday, March 5, 2014, Stan Ratliff (sratlif= f) wrote:
Yeah, I also heard some chatter about uses that are not associated with OLS= Rv2. Having said that, I don't have a strong opinion either way. I'= ll just ask - are we sure we want to rename it as an OSLRv2 doc?

Regards,
Stan

On Mar 5, 2014, at 2:51 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Teco

I thought you and Henning agreed that it is not must=A0related to OLSR= v2. However, I don't mind your suggestion.=A0

AB

On Wednesday, March 5, 2014, Teco Boot wrote:
May I suggest to rename to draft-manet-olsrv2-dat-metric?

Teco

Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) <sratliff@cisc= o.com> het volgende geschreven:

> Working Group Participants,
>
> The consensus in the room this morning at IETF 89 is to accept this as= a working group document. If there is opposition to this action, please re= spond on the list no later than March 7, 2014.
>
> Regards,
> Stan
> _______________________________________________
> 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

--20cf3010e96d4793fc04f3e1eab0-- From nobody Wed Mar 5 12:36:08 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C05E1A0326 for ; Wed, 5 Mar 2014 12:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvxxrNmx9vIO for ; Wed, 5 Mar 2014 12:36:04 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 72D3B1A02C1 for ; Wed, 5 Mar 2014 12:36:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 1D3B36E214E; Wed, 5 Mar 2014 12:36:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id AD7631D22CD; Wed, 5 Mar 2014 12:36:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Wed, 5 Mar 2014 21:35:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C3A51E9-80B4-4000-A717-41A4B38828F3@thomasclausen.org> References: <5317012F.60701@computer.org> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bd54-YQqMwTLsK9iVOrbj9Lz71E Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:36:06 -0000 > On 5 mars 2014, at 21:23, Abdussalam Baryun w= rote: >=20 >=20 > Hi Charles, >=20 > As I suggested in meeting IMHO we get a schedule plan for submission as lo= ng not much clear discussion by the group.=20 >=20 > Implementing AODVv2 is not a must (this was discussed before) because most= already practiced its techniques but when tested within the coming two year= s it will be better as OLSRv2 taken some years tests after submit.=20 >=20 Actually, for OLSRv2, we have had regular interoperability tests since 2004-= 2005 or so, and (of course) implementations for that long. Publishing on Standards Track, i.e., prescribing a solution, without having s= ignificant experimental and operational experience is, IMO, questionable for= an organization to do, and I do very much share the worries of Rick as to t= he maturity of the current reactive protocol effort. Thomas > AB >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Mar 5 12:37:29 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539341A063E for ; Wed, 5 Mar 2014 12:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YFN7M1SDt3h for ; Wed, 5 Mar 2014 12:37:22 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id BDDCF1A0650 for ; Wed, 5 Mar 2014 12:37:18 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id w8so1530071qac.41 for ; Wed, 05 Mar 2014 12:37:14 -0800 (PST) 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=aqDf5/qMQxaGQuJz4YNGJhPBm8rpDPXboLPujb5d6aE=; b=xuwGJdMxVxg/eUZU/LeMN7jtPVmQsYpR74ENxr7HrGnhpWlCeywJcTs44zzTskoCUG /9XeHgKt0NeMEYtKLIaRjiaLxhVaBF6WbaiD3yNQyFkKIXHnJHS1k3dlDeXoybCTFz+S vRhbu+P1/a6KKFQowx1oMqDGMF/aSgCGrmz5c2X6lCk52I1yfTaPYaYesLx/pIFWTS4F Y4sfy05oh+VYfRsqdm/xeynx5SalWYFo/Ra9q1ux8NLcx2cXKwgK9EgKdDxWkmlPj6MM 61MhrLlMNfN7AXsx+4wtml0/fNe2ltUB/7X8P+ceHvVPQKptXIBGsSFhTvXxY/AKJt4f ZuJA== X-Received: by 10.140.92.213 with SMTP id b79mr4593155qge.108.1394051834912; Wed, 05 Mar 2014 12:37:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.130.2 with HTTP; Wed, 5 Mar 2014 12:36:54 -0800 (PST) In-Reply-To: References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> From: Henning Rogge Date: Wed, 5 Mar 2014 20:36:54 +0000 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Z5HtqQjUZp6qA3oCU-Vsa5U5GuI Cc: MANET IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:37:25 -0000 As I said today, main problem to use this with a reactive routing protocol is that you would lack a source of packet loss data. Henning On Wed, Mar 5, 2014 at 8:32 PM, Abdussalam Baryun wrote: > I really agree more with the author presenting today (Henning) that this > work is for both reactive and proactive protocols. So I understood that we > adopted it as link-metrics not as metrics for only OLSRv2, of you read the > item it's clear I think, > > AB > > > On Wednesday, March 5, 2014, Stan Ratliff (sratliff) wrote: >> >> Yeah, I also heard some chatter about uses that are not associated with >> OLSRv2. Having said that, I don't have a strong opinion either way. I'll >> just ask - are we sure we want to rename it as an OSLRv2 doc? >> >> Regards, >> Stan >> >> On Mar 5, 2014, at 2:51 PM, Abdussalam Baryun >> wrote: >> >> Hi Teco >> >> I thought you and Henning agreed that it is not must related to OLSRv2. >> However, I don't mind your suggestion. >> >> AB >> >> On Wednesday, March 5, 2014, Teco Boot wrote: >>> >>> May I suggest to rename to draft-manet-olsrv2-dat-metric? >>> >>> Teco >>> >>> Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) >>> het volgende geschreven: >>> >>> > Working Group Participants, >>> > >>> > The consensus in the room this morning at IETF 89 is to accept this as >>> > a working group document. If there is opposition to this action, please >>> > respond on the list no later than March 7, 2014. >>> > >>> > Regards, >>> > Stan >>> > _______________________________________________ >>> > 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 nobody Wed Mar 5 12:39:57 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D511A066A for ; Wed, 5 Mar 2014 12:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FegjZr5vjbe1 for ; Wed, 5 Mar 2014 12:39:52 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 20E821A04F6 for ; Wed, 5 Mar 2014 12:39:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C46D41C052F; Wed, 5 Mar 2014 12:39:28 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4C9021C08B9; Wed, 5 Mar 2014 12:39:28 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-DBBFA9C0-0A3C-47DF-BFC6-A3DC30F59EC9 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Wed, 5 Mar 2014 21:39:27 +0100 Content-Transfer-Encoding: 7bit Message-Id: <80E1F767-0F98-489C-AC16-66022D5C85A3@thomasclausen.org> References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6SmHGaNQlnnhDU9H20_oKSmv4DM Cc: MANET IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:39:53 -0000 --Apple-Mail-DBBFA9C0-0A3C-47DF-BFC6-A3DC30F59EC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable My operational and deployment experience is, that there's a substantial diff= erence in how link metrics apply in the two different protocol categories. D= o you (or anybody) have operational evidence to the contrary? Thomas Sent from my iPad > On 5 mars 2014, at 21:32, Abdussalam Baryun w= rote: >=20 > I really agree more with the author presenting today (Henning) that this w= ork is for both reactive and proactive protocols. So I understood that we ad= opted it as link-metrics not as metrics for only OLSRv2, of you read the ite= m it's clear I think,=20 >=20 > AB >=20 >> On Wednesday, March 5, 2014, Stan Ratliff (sratliff) wrote: >> Yeah, I also heard some chatter about uses that are not associated with O= LSRv2. Having said that, I don't have a strong opinion either way. I'll just= ask - are we sure we want to rename it as an OSLRv2 doc? >>=20 >> Regards, >> Stan >>=20 >>> On Mar 5, 2014, at 2:51 PM, Abdussalam Baryun wrote: >>>=20 >>> Hi Teco >>>=20 >>> I thought you and Henning agreed that it is not must related to OLSRv2. H= owever, I don't mind your suggestion.=20 >>>=20 >>> AB >>>=20 >>>> On Wednesday, March 5, 2014, Teco Boot wrote: >>>> May I suggest to rename to draft-manet-olsrv2-dat-metric? >>>>=20 >>>> Teco >>>>=20 >>>> Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) het volgende geschreven: >>>>=20 >>>> > Working Group Participants, >>>> > >>>> > The consensus in the room this morning at IETF 89 is to accept this a= s a working group document. If there is opposition to this action, please re= spond on the list no later than March 7, 2014. >>>> > >>>> > Regards, >>>> > Stan >>>> > _______________________________________________ >>>> > 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-DBBFA9C0-0A3C-47DF-BFC6-A3DC30F59EC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
My operational and deployment experience is, that there's a substantial difference in how link metrics apply in the two different protocol categories. Do you (or anybody) have operational evidence to the contrary?

Thomas

Sent from my iPad

On 5 mars 2014, at 21:32, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I really agree more with the author presenting today (Henning) that this work is for both reactive and proactive protocols. So I understood that we adopted it as link-metrics not as metrics for only OLSRv2, of you read the item it's clear I think, 

AB

On Wednesday, March 5, 2014, Stan Ratliff (sratliff) wrote:
Yeah, I also heard some chatter about uses that are not associated with OLSRv2. Having said that, I don't have a strong opinion either way. I'll just ask - are we sure we want to rename it as an OSLRv2 doc?

Regards,
Stan

On Mar 5, 2014, at 2:51 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Teco

I thought you and Henning agreed that it is not must related to OLSRv2. However, I don't mind your suggestion. 

AB

On Wednesday, March 5, 2014, Teco Boot wrote:
May I suggest to rename to draft-manet-olsrv2-dat-metric?

Teco

Op 5 mrt. 2014, om 12:12 heeft Stan Ratliff (sratliff) <sratliff@cisco.com> het volgende geschreven:

> Working Group Participants,
>
> The consensus in the room this morning at IETF 89 is to accept this as a working group document. If there is opposition to this action, please respond on the list no later than March 7, 2014.
>
> Regards,
> Stan
> _______________________________________________
> 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-DBBFA9C0-0A3C-47DF-BFC6-A3DC30F59EC9-- From nobody Wed Mar 5 12:43:54 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8A71A02EF for ; Wed, 5 Mar 2014 12:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBbfn8xhjAQg for ; Wed, 5 Mar 2014 12:43:50 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2571D1A0290 for ; Wed, 5 Mar 2014 12:43:50 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id c41so1678936yho.13 for ; Wed, 05 Mar 2014 12:43:46 -0800 (PST) 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=VKsrO15SHbwyoF3/Ar5fcuf+EYfaYYBRoFc+7nmS9JM=; b=Dld3ulhX60Vh+AweP5rh56QbjKmNCfKLU3eEdQjYfgX4wu+mVI2J0hhpTXHZwrrz8H 1dBW/BSlpA+1vcf2CnVqluXoZUqb0CdOf2SfP3snFhU3POQ5Dyd9KEDcEUhNaWOAHVLC 1Prg3X9+jSBkdQ/yDR197gzwxPPcYCVvWu+tLib3VDDu29q5tu8qt+aYMN71U62hZv9a ijhJtDl+cS04UOQLm7HIjToBASchRPsBQBndW7wXZlpRXb06vtV4+jj/23UOSgcehjvH PHj2ooLvRrwlaj5u9rwSoOqOWINFlbe3zIx9q8njnrcdn/wU0tJmN5NxwCU4Wi1wa4fk nRfA== MIME-Version: 1.0 X-Received: by 10.236.85.112 with SMTP id t76mr9774968yhe.74.1394052226275; Wed, 05 Mar 2014 12:43:46 -0800 (PST) Received: by 10.170.202.7 with HTTP; Wed, 5 Mar 2014 12:43:46 -0800 (PST) In-Reply-To: <6E6B32A0-55E8-476C-A049-EED875D94E48@thomasclausen.org> References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> <6E6B32A0-55E8-476C-A049-EED875D94E48@thomasclausen.org> Date: Wed, 5 Mar 2014 21:43:46 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=20cf300e526dbedc2204f3e2132c Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PGUqEUFiF9lvIo4aqnt9imBEzgo Cc: MANET IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:43:52 -0000 --20cf300e526dbedc2204f3e2132c Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas I see that the draft is not about routing results, but formatting metrics for purposes. AB On Wednesday, March 5, 2014, Thomas Heide Clausen wrote: > We need to scope the experiment correctly so as to get any meaningful > results and feedback. > I agree only if we find that the draft is not scoped. Did you find some error in scope in draft. Please help. > > My experience is that proactive and reactive protocols have and behave > *very* different wrt metrics and I would not bet on being able to get > meaningful results from mushing them together willy-nilly. > The reactive and proactive have and behave "very" different in messages send/receive/information but still we agreed to have RFC5444 for both, and NHDP for both. Why not metric, please help. AB > > -- > Thomas Heide Clausen > http://www.thomasclausen.org > > "Today's scientists have substituted mathematics for > experiments, and they wander off through equation > after equation, and eventually build a structure > which has no relation to reality." > If not from math then there is no practice. > - Nikola Tesla, > Modern Mechanics and Inventions, July, 1934 > > --20cf300e526dbedc2204f3e2132c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas

I see that the draft is not about routing resu= lts, but formatting metrics for purposes.=A0

AB
On Wednesday, March 5, 2014, Thomas Heide Clausen wrote:
We need to scope the experiment correctly so as to g= et any meaningful results and feedback.=A0
I agree only if we find that the draft is not scoped. Did you f= ind some error in scope in draft. Please help.=A0
=A0

My experience is that proactive and reactive protocols have and beh= ave *very* different wrt metrics and I would not bet on being able to get m= eaningful results from mushing them together willy-nilly.=A0

The reactive and proactive have and = behave "very" different in messages send/receive/information=A0bu= t still we agreed to have RFC5444 for both, and NHDP for both. Why not metr= ic, please help.=A0

AB

--=A0
Thomas Heide Clausen

"Today's scientists have substituted mathemati= cs for=A0
=A0=A0experiments, and they wander off through equation= =A0
=A0=A0after equation, and eventually =A0build a structure=A0<= /div>
=A0=A0which has no relation to reality."

If not from math then there is= no practice.=A0
=A0
=A0- Nikola Tesla,=A0
=A0=A0 =A0Modern Mechanics and In= ventions, July, 1934

--20cf300e526dbedc2204f3e2132c-- From nobody Wed Mar 5 12:45:38 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92A71A0251 for ; Wed, 5 Mar 2014 12:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1rNbpjTGpZK for ; Wed, 5 Mar 2014 12:45:33 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A25901A02EF for ; Wed, 5 Mar 2014 12:45:33 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id j5so4403515qga.4 for ; Wed, 05 Mar 2014 12:45:29 -0800 (PST) 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=YF1l1Nk02KZkPw5D9IoO1QPxs2gk5YhJZd5ohBetd/M=; b=kFZ0H4DfBWWIm7atOw3lGzsDMI2hOspeOtrA6ln3vNBFqkUq9FXWKPOPHl68Bcx6lp 3iLmOe3eX44EAFJoM5sp4bWCavisLUk0MzMNf9fdf2Ky5evdfAkSEAgZRwSkCVCcmM93 F9wo6URKgXMt593V5PsLCXvvwx/Of/wvgF/hCTjgpmryENCvWrI+EAktofPFAJbP5twN E/5Jq2Kr0JFyBIqH5BqfXT6R5UYCYX0ftPBvMt4Z/unvWfmZLUKnto74j+gHIydjZDR+ 6imMz4/YdC2OKhxSb5zFrYj56RFPsotoht/viG80wBfP0E8uudpL8k3sshjaTpqiWG9M YVgg== X-Received: by 10.140.97.37 with SMTP id l34mr9115977qge.56.1394052329796; Wed, 05 Mar 2014 12:45:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.130.2 with HTTP; Wed, 5 Mar 2014 12:45:09 -0800 (PST) In-Reply-To: References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> <6E6B32A0-55E8-476C-A049-EED875D94E48@thomasclausen.org> From: Henning Rogge Date: Wed, 5 Mar 2014 20:45:09 +0000 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/coGr8V8SdHBttJxBpIgL7qutbwI Cc: MANET IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:45:35 -0000 On Wed, Mar 5, 2014 at 8:43 PM, Abdussalam Baryun wrote: > The reactive and proactive have and behave "very" different in messages > send/receive/information but still we agreed to have RFC5444 for both, and > NHDP for both. Why not metric, please help. If you are running NHDP, you are not running a completely reactive protocol. Henning From nobody Wed Mar 5 12:48:41 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9112D1A0538 for ; Wed, 5 Mar 2014 12:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wB0LwnvqsCA for ; Wed, 5 Mar 2014 12:48:37 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6781A02AA for ; Wed, 5 Mar 2014 12:48:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 2215C1D22CD; Wed, 5 Mar 2014 12:48:34 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4CB411C052F; Wed, 5 Mar 2014 12:48:33 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-2B539B3A-2664-451C-9B38-944ED62AE296 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Wed, 5 Mar 2014 21:48:32 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> <6E6B32A0-55E8-476C-A049-EED875D94E48@thomasclausen.org> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BX6otJdZ9AChaJTS9TutdLNCFhA Cc: MANET IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:48:39 -0000 --Apple-Mail-2B539B3A-2664-451C-9B38-944ED62AE296 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear Abdussalam, > On 5 mars 2014, at 21:43, Abdussalam Baryun w= rote: >=20 > Hi Thomas >=20 > I see that the draft is not about routing results, but formatting metrics f= or purposes.=20 >=20 > AB >=20 >> On Wednesday, March 5, 2014, Thomas Heide Clausen wrote: >> We need to scope the experiment correctly so as to get any meaningful res= ults and feedback.=20 >=20 > I agree only if we find that the draft is not scoped. Did you find some er= ror in scope in draft. Please help.=20 AFAIK, the draft is scoping for and aiming at OLSRv2. For that purpose, it i= s quite appropriate. > =20 >>=20 >> My experience is that proactive and reactive protocols have and behave *v= ery* different wrt metrics and I would not bet on being able to get meaningf= ul results from mushing them together willy-nilly.=20 >=20 > The reactive and proactive have and behave "very" different in messages se= nd/receive/information but still we agreed to have RFC5444 for both, and NHD= P for both. Why not metric, please help.=20 >=20 1) try to deploy networks with reactive and proactive protocols, using the s= ame metric, 2) the ID of Henning talks about pkt sequence numbers and HELLO messages, no= ne of which are present in the reactive protocol Even if 1) wasn't applicable (though, it is), the difference wrt 2) makes th= at moot: it's simply not the same mechanism that applies in the two cases. Thomas > AB >>=20 >> --=20 >> Thomas Heide Clausen >> http://www.thomasclausen.org >>=20 >> "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." >=20 > If not from math then there is no practice.=20 > =20 >> - Nikola Tesla,=20 >> Modern Mechanics and Inventions, July, 1934 >>=20 --Apple-Mail-2B539B3A-2664-451C-9B38-944ED62AE296 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Dear Abdussalam,

On 5 mars 2014, at 21:43, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Thomas

I see that the draft is not about routing results, but formatting metrics for purposes. 

AB

On Wednesday, March 5, 2014, Thomas Heide Clausen wrote:
We need to scope the experiment correctly so as to get any meaningful results and feedback. 

I agree only if we find that the draft is not scoped. Did you find some error in scope in draft. Please help. 

AFAIK, the draft is scoping for and aiming at OLSRv2. For that purpose, it is quite appropriate.

 

My experience is that proactive and reactive protocols have and behave *very* different wrt metrics and I would not bet on being able to get meaningful results from mushing them together willy-nilly. 

The reactive and proactive have and behave "very" different in messages send/receive/information but still we agreed to have RFC5444 for both, and NHDP for both. Why not metric, please help. 


1) try to deploy networks with reactive and proactive protocols, using the same metric,

2) the ID of Henning talks about pkt sequence numbers and HELLO messages, none of which are present in the reactive protocol

Even if 1) wasn't applicable (though, it is), the difference wrt 2) makes that moot: it's simply not the same mechanism that applies in the two cases.

Thomas

AB

-- 
Thomas Heide Clausen

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."

If not from math then there is no practice. 
 
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

--Apple-Mail-2B539B3A-2664-451C-9B38-944ED62AE296-- From nobody Wed Mar 5 12:49:06 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D141A02AA for ; Wed, 5 Mar 2014 12:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu-eGe8rIiKd for ; Wed, 5 Mar 2014 12:49:02 -0800 (PST) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A71701A06B8 for ; Wed, 5 Mar 2014 12:49:02 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id hw13so1579341qab.32 for ; Wed, 05 Mar 2014 12:48:58 -0800 (PST) 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=5RLHsx+tQ1ZSrBdoBCyY8sAGHAwN1ISedFHrfmrzQj0=; b=oY08QAzgLPCZmOB3BAh3MfSX7zhVHhu7gQxrOAcFhn8sUq6SgPokV45wSX3idRGGGC yTYL0yJEGg61ulUlKoMgb5dsnVFg66kT1NUoybRYVjnHtpJbui0K7H9ev4rArgG1fXLM i8Dr2HBEK+hdIJ1RoIRTV6bZuVtcRkdKdoxAeImXlnLktwV+UXzKxLnTi9bLanjfhNr2 yapb4EGm9GG8RL30ZzhlVIVAslGHZlNk+rQ9Glb/zCCjNmVfxT1TVuvkAl4XJVlHOqP4 jODsDPk78w0UeTAU5xrhAeMa1I+OzaBVw/v7bWhr7EG+WHy5T02Ps/MHbTpk7kuf+oWB 4eGg== X-Received: by 10.140.98.33 with SMTP id n30mr9165323qge.8.1394052538819; Wed, 05 Mar 2014 12:48:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.130.2 with HTTP; Wed, 5 Mar 2014 12:48:38 -0800 (PST) In-Reply-To: References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <508641F2.9050100@fkie.fraunhofer.de> <5088E2B5.60102@fkie.fraunhofer.de> From: Henning Rogge Date: Wed, 5 Mar 2014 20:48:38 +0000 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_EqiO2rFZcw2d5TZC5mKq9p67fs Cc: manet Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:49:05 -0000 Hi, we talked about the different approaches for DLEP a LONG time ago... I suggested a "stateless UDP" approach, but the WG consensus decided for Stans DLEP approach. I backed down and began to work on helping to improve Stan's DLEP draft. Can we consider this issue resolved (with WG consensus) after you didn't even raised the point at the WG meeting today? Henning On Wed, Mar 5, 2014 at 7:47 AM, Abdussalam Baryun wrote: > Hi Will and Henning, > > I am not sure of the work in progress related to draft-ivancic and > draft-rogge mentioned below. However, I think they are interesting to be > consider by the WG. Was there a decision made on the drafts by the authors > or was it to be submitted else where. Please help. Thanking you, > > AB > > > On Monday, October 22, 2012, 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 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 > > > > On Monday, November 5, 2012, Henning Rogge wrote: >> >> On Thu, Oct 25, 2012 at 8:56 AM, Henning Rogge >> 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. >> >> Now that the submission block period is over, I have also uploaded the >> draft properly to the IETF as a personal draft: >> >> https://datatracker.ietf.org/doc/draft-rogge-stateless-rfc5444-dlep/ >> >> 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 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed Mar 5 12:49:23 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64E51A06DA for ; Wed, 5 Mar 2014 12:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k50Frq4Az5E9 for ; Wed, 5 Mar 2014 12:49:11 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id D9B4F1A06D6 for ; Wed, 5 Mar 2014 12:49:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 76B8C1C052F; Wed, 5 Mar 2014 12:49:08 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CB3EB1D22CD; Wed, 5 Mar 2014 12:49:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Wed, 5 Mar 2014 21:49:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <16F91DE0-4681-4677-9312-9417CFBA45B0@thomasclausen.org> References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> <6E6B32A0-55E8-476C-A049-EED875D94E48@thomasclausen.org> To: Henning Rogge Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0GYw0aLQxsNNSjIuyxi0c9o17G8 Cc: MANET IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:49:15 -0000 > On 5 mars 2014, at 21:45, Henning Rogge wrote: >=20 > On Wed, Mar 5, 2014 at 8:43 PM, Abdussalam Baryun > wrote: >> The reactive and proactive have and behave "very" different in messages >> send/receive/information but still we agreed to have RFC5444 for both, an= d >> NHDP for both. Why not metric, please help. >=20 > If you are running NHDP, you are not running a completely reactive protoco= l. >=20 That, too. Thomas > Henning From nobody Wed Mar 5 12:55:27 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDFE1A0303 for ; Wed, 5 Mar 2014 12:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZAelyFJG_cI for ; Wed, 5 Mar 2014 12:55:23 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A3E421A0326 for ; Wed, 5 Mar 2014 12:55:23 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id i8so1821563qcq.23 for ; Wed, 05 Mar 2014 12:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bxc+ItA0/BJziw9cDPCImB57iD18S1pdeyIrYFeSoog=; b=GjxPZN5cpHBLtBOyZtjDppNj4ik23Pd4MbnrCjeY0rSRHsFWSoyhctsBICT6GqN4db ly3WjtU5NgooUjPokmTX2tuB3owTa9i5siwAQX/wqqSSkhP5Cpw146GUy106/3JQgODi Uetuxbdb3490z7047sEwzWUn5N9Ew6axpklCuutmeVV8eZy4zl/MP6rAESoH/KTvv1aX XWFxOYrnKQOCGLah6U3G/k6I1Bso40esj4qYqmyTg266BUzd+e6DLcbGC5ifF4XgDsns U7rGbxizgXVpK7jDuql4TA2/qTRi7A5oLPJynf4uARCLkU8wu9neOwstH8JnyHRWOEyI LVTA== X-Received: by 10.229.241.9 with SMTP id lc9mr3167878qcb.15.1394052919893; Wed, 05 Mar 2014 12:55:19 -0800 (PST) Received: from [192.168.1.114] (c-69-140-151-4.hsd1.md.comcast.net. [69.140.151.4]) by mx.google.com with ESMTPSA id m14sm11324808qax.9.2014.03.05.12.55.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 12:55:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Joe Macker In-Reply-To: Date: Wed, 5 Mar 2014 15:55:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1A6233B0-9A04-4AB7-8454-9762AD1792AD@gmail.com> References: To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/XinKb1b7iKRyhgIlHXfmo75sfrk Cc: MANET IETF Subject: Re: [manet] OLSRv2 + RFC6971 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:55:26 -0000 The DFF interactions and concepts are interesting thanks for sharing the = recent results. As I read through it I can definitely see where more DFF++ ideas could = happen. -Joe On Mar 5, 2014, at 11:47 AM, Thomas Heide Clausen = wrote: > Dear Ulrich, all, >=20 >=20 > On 05 Mar 2014, at 14:48 , Ulrich Herberg wrote: >=20 >> Thomas, >> I apologize that your last presentation slot fell under the table = today because of lack of time. >=20 > Such are the rules of the game: time is at a premium in face to face = meetings, and it was more important to spend that time to discuss WG = items and new items that might be immediate actions for the WG. This = presentation was "for your information" (the "collective your", that = is). >=20 >=20 >> As this work interests me personally (as editor of RFC6971), can I = ask you to give a bit of context on the mailing list? The slides are = already in the proceedings, so they are available for download (as I = mentioned as part of the OLSRv2 + extensions package). >>=20 >> Thanks >> Ulrich >=20 >=20 > A bit of context: RFC6971 - also know as DFF, among friends - is an = experimental mechanism which works below the IP layer and above the link = layer. It's raison d'etre is to improve data delivery in case the = intended next-hop (as indicated by the routing table) is somehow not = reachable, and do so before a routing protocol "catches up" and repairs = the routing topology. DFF does this by way of (at the router from where = the next hop was not reachable) engaging a "depth first forwarding" = mechanism. I'll let you read the RFC for further details, but my = colleagues and I thought it a quite clever trick. >=20 > Consequently, we went ahead and implemented it and tested it, with = both LOADng and OLSRv2. >=20 > We tested across two scenarios: one MANET with highly (artificially) = lossy links, but otherwise no router mobility; another MANET with = "normal" links but with router mobility.=20 >=20 > The slides contain simulation results for LOADng in a MANET with = intentionally lossy links -- whereas for OLSRv2, the results displayed = in the slides are from the MANET with router mobility. There's really no = significance to the choice of which scenario for which protocol, other = than to - precisely - not engage in routing protocol comparisons = here....that's NOT the goal, and so we want to steer the discussion = around that potential rathole by way of the results presented. >=20 > We actually didn't try to be particularly clever in what we did in = integrating DFF with the two protocols: there are more fancy heuristics = possible than those we implemented, especially for when using DFF with = OLSRv2. Even so the results turned out interesting: improved data = delivery rates across the board, and no (observed, at least) harmful = effects.=20 >=20 > (OK, we did try to be a little bit clever by inventing an extension to = DFF, which we called DFF++ -- but it's possible to be even more clever = than that, with a little effort) >=20 > =46rom the OLSRv2-results, we chose the catchphrase (and the title of = the presentation) "success before convergence" since it turned out that = the combination OLSRv2+DFF enabled data delivery "success" across the = last couple of hops while the (HELLO) message exchange of OLSRv2 was = catching up with a local topology change due to router mobility. >=20 > But, look at the results in the presentation (and, perhaps, the papers = cited in the presentation with more data), and judge for yourself. = Actually, I'll be even more user-friendly than Ulrich, and throw in (for = free) a link to the slides here: >=20 > http://tools.ietf.org/agenda/89/slides/slides-89-manet-7.pdf >=20 > Now, we thought it interesting to bring these results to the attention = of the WG for the following reasons: >=20 > o It helps both LOADng and OLSRv2, and in both scenarios = where there are packet losses=20 > on the links and when the topology changes dynamically = due to mobility >=20 > o It's relatively simple to implement >=20 > o It doesn't entail any additional control signals >=20 > o It doesn't require any modifications to the routing = protocols >=20 > Given that RFC6971 is an *experimental* RFC, we thought that we would = bring the results of our *experiments* to the attention of the IETF; = after all, that's the whole point of the IEF publishing *experimental* = RFCs ... >=20 > At this juncture, we'd much hope that our initial results are = interesting enough to encourage others to experiment with this = mechanism, and to report back in a similar vein.=20 >=20 > Also at this juncture, we're not actually suggesting any WG actions to = be taken. >=20 > We would suggest - and, of course, yield to the decision of the WG = chairs on this matter - that this WG and mailing list might be a place = to report and discuss such experiments and results, for when applying = DFF in conjunction with MANET routing protocols? >=20 > Longer-term, and depending on how the experiments progress, there may = be things that could be considered for WG actions. These may include = bringing DFF towards standards track, documenting DFF++, documenting = more "clever heuristics" than what we did initially (as informational = documents) if some turn out to be particularly useful (or, conversely, = documenting heuristics that turn out to be particularly harmful), etc.=20= >=20 > I'm glad that Ulrich "came out of the closet" as the editor of = RFC6971, since that gives me an excuse to hive answering questions to = the intricate details of DFF off to him: the mechanism is dead-simple, = but the reasoning behind it has its details that he's probably a lot = better equipped to answer questions to, than am I. >=20 > Hope this answers your question, triggers interest, and gets all y'all = a-coding, such that we may have more data to mull over soon. >=20 > Best, >=20 > Thomas >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Mar 5 13:06:38 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFBF1A067E for ; Wed, 5 Mar 2014 13:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhSaC40ZVsEC for ; Wed, 5 Mar 2014 13:06:32 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) by ietfa.amsl.com (Postfix) with ESMTP id D64691A071A for ; Wed, 5 Mar 2014 13:06:31 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id 142so4224576ykq.0 for ; Wed, 05 Mar 2014 13:06:28 -0800 (PST) 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=4s/NaAvgtRw9RR69UNIAzFhKs2T3eH5BPWO+JQyAaqk=; b=FsICgsGn9i+9DzNDecnZTA7dEZLnFq0R99HoJk9D3uxdSDod3bs+vN4LMkXzQFbr5m +/MggpJjP5EiY2eETCa/MjJ4XApT0pi5qniQYtWy+at75cOj1TwHT+9qMuEuPM30y+aH Ri4ZYaGb0CgAJFe7269MkawxWFp7Hzmr4YqWsY02aLUG+gK+j6PdkCgYdLb0NWvqYwfR +iGSxVDkkBrCCDrixXc0/LYnino51uVlQlpJ4jaSsnI44oD8qLxsfjl8UcrgfOj/5ibs o507ypvfcdkhMnNZmzYL5pogxP2XkO5qN0DPuJVlrs/VFRjwxBYR2/TezH7vLUjXtCAu LZZw== MIME-Version: 1.0 X-Received: by 10.236.191.130 with SMTP id g2mr4787yhn.160.1394053587919; Wed, 05 Mar 2014 13:06:27 -0800 (PST) Received: by 10.170.202.7 with HTTP; Wed, 5 Mar 2014 13:06:27 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Mar 2014 22:06:27 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=20cf30563d57e7e7b504f3e26449 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PWeBmXvCQHKcKaUht8UpKywzT7c Cc: MANET IETF Subject: Re: [manet] OLSRv2 + RFC6971 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:06:36 -0000 --20cf30563d57e7e7b504f3e26449 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas and Ulrich, I reviewed the RFC before and know from previous simulation experience its importance to MANET. However, I have seen that it may add some overhead with mobile routers issue but better with packet losses issue. I add my interest to discuss the use of DFF with mostly OLSRv2. AB On Wednesday, March 5, 2014, Thomas Heide Clausen wrote: > Dear Ulrich, all, > > > On 05 Mar 2014, at 14:48 , Ulrich Herberg > > wrote: > > > Thomas, > > I apologize that your last presentation slot fell under the table today > because of lack of time. > > Such are the rules of the game: time is at a premium in face to face > meetings, and it was more important to spend that time to discuss WG items > and new items that might be immediate actions for the WG. This presentation > was "for your information" (the "collective your", that is). > > > > As this work interests me personally (as editor of RFC6971), can I ask > you to give a bit of context on the mailing list? The slides are already in > the proceedings, so they are available for download (as I mentioned as part > of the OLSRv2 + extensions package). > > > > Thanks > > Ulrich > > > A bit of context: RFC6971 - also know as DFF, among friends - is an > experimental mechanism which works below the IP layer and above the link > layer. It's raison d'etre is to improve data delivery in case the intended > next-hop (as indicated by the routing table) is somehow not reachable, and > do so before a routing protocol "catches up" and repairs the routing > topology. DFF does this by way of (at the router from where the next hop > was not reachable) engaging a "depth first forwarding" mechanism. I'll let > you read the RFC for further details, but my colleagues and I thought it a > quite clever trick. > > Consequently, we went ahead and implemented it and tested it, with both > LOADng and OLSRv2. > > We tested across two scenarios: one MANET with highly (artificially) lossy > links, but otherwise no router mobility; another MANET with "normal" links > but with router mobility. > > The slides contain simulation results for LOADng in a MANET with > intentionally lossy links -- whereas for OLSRv2, the results displayed in > the slides are from the MANET with router mobility. There's really no > significance to the choice of which scenario for which protocol, other than > to - precisely - not engage in routing protocol comparisons here....that's > NOT the goal, and so we want to steer the discussion around that potential > rathole by way of the results presented. > > We actually didn't try to be particularly clever in what we did in > integrating DFF with the two protocols: there are more fancy heuristics > possible than those we implemented, especially for when using DFF with > OLSRv2. Even so the results turned out interesting: improved data delivery > rates across the board, and no (observed, at least) harmful effects. > > (OK, we did try to be a little bit clever by inventing an extension to > DFF, which we called DFF++ -- but it's possible to be even more clever than > that, with a little effort) > > From the OLSRv2-results, we chose the catchphrase (and the title of the > presentation) "success before convergence" since it turned out that the > combination OLSRv2+DFF enabled data delivery "success" across the last > couple of hops while the (HELLO) message exchange of OLSRv2 was catching up > with a local topology change due to router mobility. > > But, look at the results in the presentation (and, perhaps, the papers > cited in the presentation with more data), and judge for yourself. > Actually, I'll be even more user-friendly than Ulrich, and throw in (for > free) a link to the slides here: > > http://tools.ietf.org/agenda/89/slides/slides-89-manet-7.pdf > > Now, we thought it interesting to bring these results to the attention of > the WG for the following reasons: > > o It helps both LOADng and OLSRv2, and in both scenarios > where there are packet losses > on the links and when the topology changes dynamically due > to mobility > > o It's relatively simple to implement > > o It doesn't entail any additional control signals > > o It doesn't require any modifications to the routing > protocols > > Given that RFC6971 is an *experimental* RFC, we thought that we would > bring the results of our *experiments* to the attention of the IETF; after > all, that's the whole point of the IEF publishing *experimental* RFCs ... > > At this juncture, we'd much hope that our initial results are interesting > enough to encourage others to experiment with this mechanism, and to report > back in a similar vein. > > Also at this juncture, we're not actually suggesting any WG actions to be > taken. > > We would suggest - and, of course, yield to the decision of the WG chairs > on this matter - that this WG and mailing list might be a place to report > and discuss such experiments and results, for when applying DFF in > conjunction with MANET routing protocols? > > Longer-term, and depending on how the experiments progress, there may be > things that could be considered for WG actions. These may include bringing > DFF towards standards track, documenting DFF++, documenting more "clever > heuristics" than what we did initially (as informational documents) if some > turn out to be particularly useful (or, conversely, documenting heuristics > that turn out to be particularly harmful), etc. > > I'm glad that Ulrich "came out of the closet" as the editor of RFC6971, > since that gives me an excuse to hive answering questions to the intricate > details of DFF off to him: the mechanism is dead-simple, but the reasoning > behind it has its details that he's probably a lot better equipped to > answer questions to, than am I. > > Hope this answers your question, triggers interest, and gets all y'all > a-coding, such that we may have more data to mull over soon. > > Best, > > Thomas > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf30563d57e7e7b504f3e26449 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas and Ulrich,

I reviewed the RFC before and know= from previous simulation=A0experience its importance to MANET. However, I = have seen that it may add some overhead with mobile=A0routers issue=A0but b= etter with packet=A0losses issue.=A0=A0I add my interest to discuss the=A0u= se of=A0DFF with mostly=A0OLSRv2.=A0

AB

On Wednesday, March 5, 2014, Thomas Heide Cla= usen wrote:
Dear Ulrich, all,


On 05 Mar 2014, at 14:48 , Ulrich Herberg <ulrich@her= berg.name> wrote:

> Thomas,
> I apologize that your last presentation slot fell under the table toda= y because of lack of time.

Such are the rules of the game: time is at a premium in face to face meetin= gs, and it was more important to spend that time to discuss WG items and ne= w items that might be immediate actions for the WG. This presentation was &= quot;for your information" (the "collective your", that is).=


> =A0As this work interests me personally (as editor of RFC6971), can I = ask you to give a bit of context on the mailing list? The slides are alread= y in the proceedings, so they are available for download (as I mentioned as= part of the OLSRv2 + extensions package).
>
> Thanks
> Ulrich


A bit of context: RFC6971 - also know as DFF, among friends - is an experim= ental mechanism which works below the IP layer and above the link layer. It= 's raison d'etre is to improve data delivery in case the intended n= ext-hop (as indicated by the routing table) is somehow not reachable, and d= o so before a routing protocol "catches up" and repairs the routi= ng topology. DFF does this by way of (at the router from where the next hop= was not reachable) engaging a "depth first forwarding" mechanism= . I'll let you read the RFC for further details, but my colleagues and = I thought it a quite clever trick.

Consequently, we went ahead and implemented it and tested it, with both LOA= Dng and OLSRv2.

We tested across two scenarios: one MANET with highly (artificially) lossy = links, but otherwise no router mobility; another MANET with "normal&qu= ot; links but with router mobility.

The slides contain simulation results for LOADng in a MANET with intentiona= lly lossy links -- whereas for OLSRv2, the results displayed in the slides = are from the MANET with router mobility. There's really no significance= to the choice of which scenario for which protocol, other than to - precis= ely - not engage in routing protocol comparisons here....that's NOT the= goal, and so we want to steer the discussion around that potential rathole= by way of the results presented.

We actually didn't try to be particularly clever in what we did in inte= grating DFF with the two protocols: there are more fancy heuristics possibl= e than those we implemented, especially for when using DFF with OLSRv2. Eve= n so the results turned out interesting: improved data delivery rates acros= s the board, and no (observed, at least) harmful effects.

(OK, we did try to be a little bit clever by inventing an extension to DFF,= which we called DFF++ -- but it's possible to be even more clever than= that, with a little effort)

>From the =A0OLSRv2-results, we chose the catchphrase (and the title of the = presentation) "success before convergence" since it turned out th= at the combination OLSRv2+DFF enabled data delivery "success" acr= oss the last couple of hops while the (HELLO) message exchange of OLSRv2 wa= s catching up with a local topology change due to router mobility.

But, look at the results in the presentation (and, perhaps, the papers cite= d in the presentation with more data), and judge for yourself. Actually, I&= #39;ll be even more user-friendly than Ulrich, and throw in (for free) a li= nk to the slides here:

=A0 =A0 =A0 =A0 http://tools.ietf.org/agenda/89/slides/slid= es-89-manet-7.pdf

Now, we thought it interesting to bring these results to the attention of t= he WG for the following reasons:

=A0 =A0 =A0 =A0 o =A0 =A0 =A0 It helps both LOADng and OLSRv2, and in both = scenarios where there are packet losses
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 on the links and when the topology changes = dynamically due to mobility

=A0 =A0 =A0 =A0 o =A0 =A0 =A0 It's relatively simple to implement

=A0 =A0 =A0 =A0 o =A0 =A0 =A0 It doesn't entail any additional control = signals

=A0 =A0 =A0 =A0 o =A0 =A0 =A0 It doesn't require any modifications to t= he routing protocols

Given that RFC6971 is an *experimental* RFC, we thought that we would bring= the results of our *experiments* to the attention of the IETF; after all, = that's the whole point of the IEF publishing *experimental* RFCs ...
At this juncture, we'd much hope that our initial results are interesti= ng enough to encourage others to experiment with this mechanism, and to rep= ort back in a similar vein.

Also at this juncture, we're not actually suggesting any WG actions to = be taken.

We would suggest - and, of course, yield to the decision of the WG chairs o= n this matter - that this WG and mailing list might be a place to report an= d discuss such experiments and results, for when applying DFF in conjunctio= n with MANET routing protocols?

Longer-term, and depending on how the experiments progress, there may be th= ings that could be considered for WG actions. These may include bringing DF= F towards standards track, documenting DFF++, documenting more "clever= heuristics" than what we did initially (as informational documents) i= f some turn out to be particularly useful (or, conversely, documenting heur= istics that turn out to be particularly harmful), etc.

I'm glad that Ulrich "came out of the closet" as the editor o= f RFC6971, since that gives me an excuse to hive answering questions to the= intricate details of DFF off to him: the mechanism is dead-simple, but the= reasoning behind it has its details that he's probably a lot better eq= uipped to answer questions to, than am I.

Hope this answers your question, triggers interest, and gets all y'all = a-coding, such that we may have more data to mull over soon.

Best,

Thomas


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--20cf30563d57e7e7b504f3e26449-- From nobody Wed Mar 5 13:18:55 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7551A0724 for ; Wed, 5 Mar 2014 13:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sx4Pu0e-PonT for ; Wed, 5 Mar 2014 13:18:51 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF131A02EE for ; Wed, 5 Mar 2014 13:18:51 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 200so4262802ykr.3 for ; Wed, 05 Mar 2014 13:18:47 -0800 (PST) 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=3FufP/svx8flW+46sl35369O8K/HA468Ymg4GgvO3q4=; b=hzNtg3Vj3GUNHkeow0Ai9D/+328MUfAE0JiukzAaJcWs03CrrHHUts8RDfIn6Z1Gry 5BF9O+ozD1Dsid92qjpdNkBYwKOuGa9VoavdMV1/dgSQZ8FGemIFcNOerhCZKY9in2Ey yUKAlMZz/FWXNlZV8zMg8fq+IRBwT1qJOyyQg8KssjpcyvfEM1arnWaIShFUm5n+2Z08 faulegX+XaIPfCNs/NRXBn0/xVS1ks27m1qb1u4M5GS1ajGx+SLswtJ78wMM+BsOReXQ EqK79p9PCauKhGPz2R0rp+dEnH8V+l8ayWRUv6B1HdCHXztT2svujAgz2dvYLZp7BOnx XUXw== MIME-Version: 1.0 X-Received: by 10.236.93.208 with SMTP id l56mr5896347yhf.112.1394054327554; Wed, 05 Mar 2014 13:18:47 -0800 (PST) Received: by 10.170.202.7 with HTTP; Wed, 5 Mar 2014 13:18:47 -0800 (PST) In-Reply-To: References: <5317012F.60701@computer.org> Date: Wed, 5 Mar 2014 22:18:47 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=20cf3010ead1fdd82a04f3e29051 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/v4Vyx0LTTPjn-UHSTSbPdveOCVM Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:18:53 -0000 --20cf3010ead1fdd82a04f3e29051 Content-Type: text/plain; charset=ISO-8859-1 I mean there are implementations and it works, but still under test for new v2, OLSR and AODV are well known. We don't wait for implementation to finish then submit for standards as far as I understand standard track ( I remember once heard that from an AD I think, am I mistaken). AB On Wednesday, March 5, 2014, Henning Rogge wrote: > "Implementation is not a most for a standard track document"... that > is an "interesting" point of view. > > Henning Rogge > > On Wed, Mar 5, 2014 at 8:23 PM, Abdussalam Baryun > > wrote: > > > > Hi Charles, > > > > As I suggested in meeting IMHO we get a schedule plan for submission as > long > > not much clear discussion by the group. > > > > Implementing AODVv2 is not a must (this was discussed before) because > most > > already practiced its techniques but when tested within the coming two > years > > it will be better as OLSRv2 taken some years tests after submit. > > > > AB > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > --20cf3010ead1fdd82a04f3e29051 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I mean there are implementations and it works, but still under test for new= v2,=A0OLSR and AODV are well known. We don't wait for implementation t= o finish then submit for standards as far as I understand standard track ( = I remember once heard that from an AD I think, am I mistaken).=A0

AB

On Wednesday, March 5, 2014, Henning Rogge wrote:=
"Implementation is not a most for a= standard track document"... that
is an "interesting" point of view.

Henning Rogge

On Wed, Mar 5, 2014 at 8:23 PM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
>
> Hi Charles,
>
> As I suggested in meeting IMHO we get a schedule plan for submission a= s long
> not much clear discussion by the group.
>
> Implementing AODVv2 is not a must (this was discussed before) because = most
> already practiced its techniques but when tested within the coming two= years
> it will be better as OLSRv2 taken some years tests after submit.
>
> AB
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
--20cf3010ead1fdd82a04f3e29051-- From nobody Wed Mar 5 13:22:04 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5C71A0450 for ; Wed, 5 Mar 2014 13:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_7wGGNKixz7 for ; Wed, 5 Mar 2014 13:22:00 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 10C311A02EE for ; Wed, 5 Mar 2014 13:22:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B3E041C08B9; Wed, 5 Mar 2014 13:21:56 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 408F21C052F; Wed, 5 Mar 2014 13:21:56 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-556201A5-CB53-47AE-A53D-6B2151CAD249 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Wed, 5 Mar 2014 22:21:55 +0100 Content-Transfer-Encoding: 7bit Message-Id: <680DC4B8-52F7-49B6-BB04-B82F0138CAF0@thomasclausen.org> References: <5317012F.60701@computer.org> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/j-XF2vmEJyZK4qGjCXrxK51i6jg Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:22:02 -0000 --Apple-Mail-556201A5-CB53-47AE-A53D-6B2151CAD249 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 5 mars 2014, at 22:18, Abdussalam Baryun w= rote: >=20 > I mean there are implementations and it works, but still under test for ne= w v2, OLSR and AODV are well known. We don't wait for implementation to fini= sh then submit for standards as far as I understand standard track ( I remem= ber once heard that from an AD I think, am I mistaken).=20 Actually, having running code (And, preferably, multiple interoperable imple= mentations) is very very very highly recommended before publishing at std. t= rack. Actually, I'd submit that *not* having multiple interoperable implementation= s should be a requirement before std. track publication. Thomas > AB >=20 >> On Wednesday, March 5, 2014, Henning Rogge wrote: >> "Implementation is not a most for a standard track document"... that >> is an "interesting" point of view. >>=20 >> Henning Rogge >>=20 >> On Wed, Mar 5, 2014 at 8:23 PM, Abdussalam Baryun >> wrote: >> > >> > Hi Charles, >> > >> > As I suggested in meeting IMHO we get a schedule plan for submission as= long >> > not much clear discussion by the group. >> > >> > Implementing AODVv2 is not a must (this was discussed before) because m= ost >> > already practiced its techniques but when tested within the coming two y= ears >> > it will be better as OLSRv2 taken some years tests after submit. >> > >> > AB >> > >> > >> > >> > _______________________________________________ >> > 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-556201A5-CB53-47AE-A53D-6B2151CAD249 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 5 mars 2014, at 22:1= 8, Abdussalam Baryun <abdus= salambaryun@gmail.com> wrote:

=
I mean there are implementations and it works, but still under test for= new v2, OLSR and AODV are well known. We don't wait for implementation= to finish then submit for standards as far as I understand standard track (= I remember once heard that from an AD I think, am I mistaken). 
<= /blockquote>

Actually, having running code (And, preferably, m= ultiple interoperable implementations) is very very very highly recommended b= efore publishing at std. track.

Actually, I'd submit that= *not* having multiple interoperable implementations should be a requirement= before std. track publication.

Thomas

AB

On Wednesday, March 5, 2= 014, Henning Rogge wrote:
"Implementation i= s not a most for a standard track document"... that
is an "interesting" point of view.

Henning Rogge

On Wed, Mar 5, 2014 at 8:23 PM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
>
> Hi Charles,
>
> As I suggested in meeting IMHO we get a schedule plan for submission as= long
> not much clear discussion by the group.
>
> Implementing AODVv2 is not a must (this was discussed before) because m= ost
> already practiced its techniques but when tested within the coming two y= ears
> it will be better as OLSRv2 taken some years tests after submit.
>
> AB
>
>
>
> _______________________________________________
> manet mailing list
> https://www.ietf.org/mailman/listinfo/manet
>
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-556201A5-CB53-47AE-A53D-6B2151CAD249-- From nobody Wed Mar 5 13:26:44 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ED51A02EE for ; Wed, 5 Mar 2014 13:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-HqBRO9TYQE for ; Wed, 5 Mar 2014 13:26:36 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 03BFD1A0716 for ; Wed, 5 Mar 2014 13:26:32 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id a1so1996245wgh.34 for ; Wed, 05 Mar 2014 13:26:28 -0800 (PST) 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=S6b+V0tl+2Nl8u/zFG9YN+59xsKZIok1qrEUcjYW2LY=; b=JbmjSmaOEYgp+cIqz0nK/yMbkCM/pNUP4qQBSC2djrjWgkCXjYLtJUiBOycPEWNsl7 5NrnztPlz9ilVVC+XobT2cPqDYhk4bAlh3eYxtOYqSqLacS6LeY/GFwESfh7UJ2GQbI6 vc8KRsIicAUGUcCoZBsI50zTV+nNhA9kC8dHyi5tMMTh4qUEK9jJPloPyiIjOhXZSnz3 Z990xvHSCbBCnR3NLNh1vrRYxrVs4cW5UZhyB+zhK7TI5dJHCGrUnktn/9m/0gLBiFsk rTCxBdzhZKA97zOS+xUwaUS4Y6CY+cq2FH2QErhGRujNX11v0JaTOlcAUT8hbRB6/A3u t7Vw== MIME-Version: 1.0 X-Received: by 10.194.219.132 with SMTP id po4mr4433625wjc.7.1394054788762; Wed, 05 Mar 2014 13:26:28 -0800 (PST) Received: by 10.194.118.134 with HTTP; Wed, 5 Mar 2014 13:26:28 -0800 (PST) In-Reply-To: <1A6233B0-9A04-4AB7-8454-9762AD1792AD@gmail.com> References: <1A6233B0-9A04-4AB7-8454-9762AD1792AD@gmail.com> Date: Wed, 5 Mar 2014 22:26:28 +0100 Message-ID: From: Jiazi YI To: Joe Macker Content-Type: multipart/alternative; boundary=001a11c288a27b6f2604f3e2ac2c Archived-At: http://mailarchive.ietf.org/arch/msg/manet/QV0Lszb5XFv3bknbgZdVE1NoD4c Cc: MANET IETF , Thomas Heide Clausen Subject: Re: [manet] OLSRv2 + RFC6971 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:26:41 -0000 --001a11c288a27b6f2604f3e2ac2c Content-Type: text/plain; charset=ISO-8859-1 As one can imagine, the performance of DFF is directly related to the order of Candidate Next Hop List (CNHL). The The DFF++ is proposed to improve the issue. The advantage of DFF++ is: o It doesn't require additional signaling in the air; o Therefore, it wouldn't affect compatibility; o It just need one additional field in the CNHL - no additional memory is required. The limitations are: o The DFF++ won't work for the "very first packet" o It could provide the optimal path, but a "workable" path. More ideas about improving the order of CNHL are appreciated. cheers Jiazi On Wed, Mar 5, 2014 at 9:55 PM, Joe Macker wrote: > The DFF interactions and concepts are interesting thanks for sharing the > recent results. > As I read through it I can definitely see where more DFF++ ideas could > happen. > > -Joe > > On Mar 5, 2014, at 11:47 AM, Thomas Heide Clausen < > thomas@thomasclausen.org> wrote: > > > Dear Ulrich, all, > > > > > > On 05 Mar 2014, at 14:48 , Ulrich Herberg wrote: > > > >> Thomas, > >> I apologize that your last presentation slot fell under the table today > because of lack of time. > > > > Such are the rules of the game: time is at a premium in face to face > meetings, and it was more important to spend that time to discuss WG items > and new items that might be immediate actions for the WG. This presentation > was "for your information" (the "collective your", that is). > > > > > >> As this work interests me personally (as editor of RFC6971), can I ask > you to give a bit of context on the mailing list? The slides are already in > the proceedings, so they are available for download (as I mentioned as part > of the OLSRv2 + extensions package). > >> > >> Thanks > >> Ulrich > > > > > > A bit of context: RFC6971 - also know as DFF, among friends - is an > experimental mechanism which works below the IP layer and above the link > layer. It's raison d'etre is to improve data delivery in case the intended > next-hop (as indicated by the routing table) is somehow not reachable, and > do so before a routing protocol "catches up" and repairs the routing > topology. DFF does this by way of (at the router from where the next hop > was not reachable) engaging a "depth first forwarding" mechanism. I'll let > you read the RFC for further details, but my colleagues and I thought it a > quite clever trick. > > > > Consequently, we went ahead and implemented it and tested it, with both > LOADng and OLSRv2. > > > > We tested across two scenarios: one MANET with highly (artificially) > lossy links, but otherwise no router mobility; another MANET with "normal" > links but with router mobility. > > > > The slides contain simulation results for LOADng in a MANET with > intentionally lossy links -- whereas for OLSRv2, the results displayed in > the slides are from the MANET with router mobility. There's really no > significance to the choice of which scenario for which protocol, other than > to - precisely - not engage in routing protocol comparisons here....that's > NOT the goal, and so we want to steer the discussion around that potential > rathole by way of the results presented. > > > > We actually didn't try to be particularly clever in what we did in > integrating DFF with the two protocols: there are more fancy heuristics > possible than those we implemented, especially for when using DFF with > OLSRv2. Even so the results turned out interesting: improved data delivery > rates across the board, and no (observed, at least) harmful effects. > > > > (OK, we did try to be a little bit clever by inventing an extension to > DFF, which we called DFF++ -- but it's possible to be even more clever than > that, with a little effort) > > > > From the OLSRv2-results, we chose the catchphrase (and the title of the > presentation) "success before convergence" since it turned out that the > combination OLSRv2+DFF enabled data delivery "success" across the last > couple of hops while the (HELLO) message exchange of OLSRv2 was catching up > with a local topology change due to router mobility. > > > > But, look at the results in the presentation (and, perhaps, the papers > cited in the presentation with more data), and judge for yourself. > Actually, I'll be even more user-friendly than Ulrich, and throw in (for > free) a link to the slides here: > > > > http://tools.ietf.org/agenda/89/slides/slides-89-manet-7.pdf > > > > Now, we thought it interesting to bring these results to the attention > of the WG for the following reasons: > > > > o It helps both LOADng and OLSRv2, and in both scenarios > where there are packet losses > > on the links and when the topology changes dynamically due > to mobility > > > > o It's relatively simple to implement > > > > o It doesn't entail any additional control signals > > > > o It doesn't require any modifications to the routing > protocols > > > > Given that RFC6971 is an *experimental* RFC, we thought that we would > bring the results of our *experiments* to the attention of the IETF; after > all, that's the whole point of the IEF publishing *experimental* RFCs ... > > > > At this juncture, we'd much hope that our initial results are > interesting enough to encourage others to experiment with this mechanism, > and to report back in a similar vein. > > > > Also at this juncture, we're not actually suggesting any WG actions to > be taken. > > > > We would suggest - and, of course, yield to the decision of the WG > chairs on this matter - that this WG and mailing list might be a place to > report and discuss such experiments and results, for when applying DFF in > conjunction with MANET routing protocols? > > > > Longer-term, and depending on how the experiments progress, there may be > things that could be considered for WG actions. These may include bringing > DFF towards standards track, documenting DFF++, documenting more "clever > heuristics" than what we did initially (as informational documents) if some > turn out to be particularly useful (or, conversely, documenting heuristics > that turn out to be particularly harmful), etc. > > > > I'm glad that Ulrich "came out of the closet" as the editor of RFC6971, > since that gives me an excuse to hive answering questions to the intricate > details of DFF off to him: the mechanism is dead-simple, but the reasoning > behind it has its details that he's probably a lot better equipped to > answer questions to, than am I. > > > > Hope this answers your question, triggers interest, and gets all y'all > a-coding, such that we may have more data to mull over soon. > > > > Best, > > > > Thomas > > > > > > _______________________________________________ > > 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 > --001a11c288a27b6f2604f3e2ac2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As one can imagine, the performance of DFF is directly rel= ated to the order of Candidate Next Hop List (CNHL).=A0

= The The DFF++ is proposed to improve the issue. The advantage of DFF++ is:<= /div>

=A0 o It doesn't require additional signaling in th= e air;=A0
=A0 o Therefore, it wouldn't affect compatibility;<= /div>
=A0 o It just need one additional field in the CNHL - no addition= al memory is required.=A0

The limitations are:

=A0 o The= DFF++ won't work for the "very first packet"
=A0 o= It could provide the optimal path, but a "workable" path.=A0

More ideas about improving the order of CNHL are apprec= iated.

cheers

Jiazi
=



On Wed, Mar 5, 2014 at 9:55 PM, Joe Macker <jpmacker@gmail.com> wrote:
The DFF interactions and concepts are interesting thanks for sharing the re= cent results.
As I read through it I can definitely see where more DFF++ ideas could happ= en.

-Joe

On Mar 5, 2014, at 11:47 AM, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:

> Dear Ulrich, all,
>
>
> On 05 Mar 2014, at 14:48 , Ulrich Herberg <ulrich@herberg.name> wrote:
>
>> Thomas,
>> I apologize that your last presentation slot fell under the table = today because of lack of time.
>
> Such are the rules of the game: time is at a premium in face to face m= eetings, and it was more important to spend that time to discuss WG items a= nd new items that might be immediate actions for the WG. This presentation = was "for your information" (the "collective your", that= is).
>
>
>> As this work interests me personally (as editor of RFC6971), can I= ask you to give a bit of context on the mailing list? The slides are alrea= dy in the proceedings, so they are available for download (as I mentioned a= s part of the OLSRv2 + extensions package).
>>
>> Thanks
>> Ulrich
>
>
> A bit of context: RFC6971 - also know as DFF, among friends - is an ex= perimental mechanism which works below the IP layer and above the link laye= r. It's raison d'etre is to improve data delivery in case the inten= ded next-hop (as indicated by the routing table) is somehow not reachable, = and do so before a routing protocol "catches up" and repairs the = routing topology. DFF does this by way of (at the router from where the nex= t hop was not reachable) engaging a "depth first forwarding" mech= anism. I'll let you read the RFC for further details, but my colleagues= and I thought it a quite clever trick.
>
> Consequently, we went ahead and implemented it and tested it, with bot= h LOADng and OLSRv2.
>
> We tested across two scenarios: one MANET with highly (artificially) l= ossy links, but otherwise no router mobility; another MANET with "norm= al" links but with router mobility.
>
> The slides contain simulation results for LOADng in a MANET with inten= tionally lossy links -- whereas for OLSRv2, the results displayed in the sl= ides are from the MANET with router mobility. There's really no signifi= cance to the choice of which scenario for which protocol, other than to - p= recisely - not engage in routing protocol comparisons here....that's NO= T the goal, and so we want to steer the discussion around that potential ra= thole by way of the results presented.
>
> We actually didn't try to be particularly clever in what we did in= integrating DFF with the two protocols: there are more fancy heuristics po= ssible than those we implemented, especially for when using DFF with OLSRv2= . Even so the results turned out interesting: improved data delivery rates = across the board, and no (observed, at least) harmful effects.
>
> (OK, we did try to be a little bit clever by inventing an extension to= DFF, which we called DFF++ -- but it's possible to be even more clever= than that, with a little effort)
>
> From the =A0OLSRv2-results, we chose the catchphrase (and the title of= the presentation) "success before convergence" since it turned o= ut that the combination OLSRv2+DFF enabled data delivery "success"= ; across the last couple of hops while the (HELLO) message exchange of OLSR= v2 was catching up with a local topology change due to router mobility.
>
> But, look at the results in the presentation (and, perhaps, the papers= cited in the presentation with more data), and judge for yourself. Actuall= y, I'll be even more user-friendly than Ulrich, and throw in (for free)= a link to the slides here:
>
> =A0 =A0 =A0 http://tools.ietf.org/agenda/89/slides/sli= des-89-manet-7.pdf
>
> Now, we thought it interesting to bring these results to the attention= of the WG for the following reasons:
>
> =A0 =A0 =A0 o =A0 =A0 =A0 It helps both LOADng and OLSRv2, and in both= scenarios where there are packet losses
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 on the links and when the topology changes= dynamically due to mobility
>
> =A0 =A0 =A0 o =A0 =A0 =A0 It's relatively simple to implement
>
> =A0 =A0 =A0 o =A0 =A0 =A0 It doesn't entail any additional control= signals
>
> =A0 =A0 =A0 o =A0 =A0 =A0 It doesn't require any modifications to = the routing protocols
>
> Given that RFC6971 is an *experimental* RFC, we thought that we would = bring the results of our *experiments* to the attention of the IETF; after = all, that's the whole point of the IEF publishing *experimental* RFCs .= ..
>
> At this juncture, we'd much hope that our initial results are inte= resting enough to encourage others to experiment with this mechanism, and t= o report back in a similar vein.
>
> Also at this juncture, we're not actually suggesting any WG action= s to be taken.
>
> We would suggest - and, of course, yield to the decision of the WG cha= irs on this matter - that this WG and mailing list might be a place to repo= rt and discuss such experiments and results, for when applying DFF in conju= nction with MANET routing protocols?
>
> Longer-term, and depending on how the experiments progress, there may = be things that could be considered for WG actions. These may include bringi= ng DFF towards standards track, documenting DFF++, documenting more "c= lever heuristics" than what we did initially (as informational documen= ts) if some turn out to be particularly useful (or, conversely, documenting= heuristics that turn out to be particularly harmful), etc.
>
> I'm glad that Ulrich "came out of the closet" as the edi= tor of RFC6971, since that gives me an excuse to hive answering questions t= o the intricate details of DFF off to him: the mechanism is dead-simple, bu= t the reasoning behind it has its details that he's probably a lot bett= er equipped to answer questions to, than am I.
>
> Hope this answers your question, triggers interest, and gets all y'= ;all a-coding, such that we may have more data to mull over soon.
>
> Best,
>
> Thomas
>
>
> _______________________________________________
> 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

--001a11c288a27b6f2604f3e2ac2c-- From nobody Wed Mar 5 13:27:39 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F9C1A0747 for ; Wed, 5 Mar 2014 13:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdfRuqt8emLw for ; Wed, 5 Mar 2014 13:27:35 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C03881A077B for ; Wed, 5 Mar 2014 13:27:35 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id f73so1765511yha.0 for ; Wed, 05 Mar 2014 13:27:32 -0800 (PST) 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=1prYqgdkdgALuUJSJ4z8hhA6P8YshmaO/BV92hjuEmc=; b=UFklYwkcPueuYzNgXTkMIrJF/KdtnLzVu3pVgVFcuxBTWhw4A7IpKj7XIAFWSeuWaV uNiL4v8Lm+XE1Kr0w70MTDbIeQh8JG65cOCW+1sHexvNpXolWNObdGq1FHFOiBzaDVDe nWkO2UCvrmRfFlepbQ/QP589sZzdu4BbWvXoOc3jujVTXNeGR1PZjnTSEqXAzTcHXmoi 0M9szlqTKXwKQDWQhNmRNj1a9eM9p6Gp2/ms0mobMC9Fm618BO4aDfReBqXhhvacuNN3 2Pxdfcq4+qCgmITEGPfAv7nMhdF0w3CCQVaT7zm49oodFVuM4puTZfwOrPGyWicSggM+ Kkmw== MIME-Version: 1.0 X-Received: by 10.236.126.162 with SMTP id b22mr9747249yhi.72.1394054851936; Wed, 05 Mar 2014 13:27:31 -0800 (PST) Received: by 10.170.202.7 with HTTP; Wed, 5 Mar 2014 13:27:31 -0800 (PST) In-Reply-To: References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <508641F2.9050100@fkie.fraunhofer.de> <5088E2B5.60102@fkie.fraunhofer.de> Date: Wed, 5 Mar 2014 22:27:31 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=20cf301af6053f46a504f3e2b007 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UBQps8ksPN0yIWgu-NP0e3Mdhpw Cc: manet Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:27:37 -0000 --20cf301af6053f46a504f3e2b007 Content-Type: text/plain; charset=ISO-8859-1 Yes Henning, I decided to back down to get progress for the DLEP, or to find that my argument may not get change done. But did you plan to progress that draft below of yours. AB On Wednesday, March 5, 2014, Henning Rogge wrote: > Hi, > > we talked about the different approaches for DLEP a LONG time ago... I > suggested a "stateless UDP" approach, but the WG consensus decided for > Stans DLEP approach. > > I backed down and began to work on helping to improve Stan's DLEP draft. > > Can we consider this issue resolved (with WG consensus) after you > didn't even raised the point at the WG meeting today? > > Henning > > On Wed, Mar 5, 2014 at 7:47 AM, Abdussalam Baryun > wrote: > > Hi Will and Henning, > > > > I am not sure of the work in progress related to draft-ivancic and > > draft-rogge mentioned below. However, I think they are interesting to be > > consider by the WG. Was there a decision made on the drafts by the > authors > > or was it to be submitted else where. Please help. Thanking you, > > > > AB > > > > > > . > > --20cf301af6053f46a504f3e2b007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes Henning,

I decided to=A0back=A0down to get progress = for the DLEP,=A0or to find that=A0my argument may not get change done. But = did you plan to progress that draft below=A0of yours.=A0

AB

On Wednesday, March 5, 2014, Henning Rogge wrote:
Hi,

we talked about the different approaches for DLEP a LONG time ago... I
suggested a "stateless UDP" approach, but the WG consensus decide= d for
Stans DLEP approach.

I backed down and began to work on helping to improve Stan's DLEP draft= .

Can we consider this issue resolved (with WG consensus) after you
didn't even raised the point at the WG meeting today?

Henning

On Wed, Mar 5, 2014 at 7:47 AM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> Hi Will and Henning,
>
> I am not sure of the work in progress related to draft-ivancic and
> draft-rogge mentioned below. However, I think they are interesting to = be
> consider by the WG. Was there a decision made on the drafts by the aut= hors
> or was it to be submitted else where. Please help. Thanking you,
>
> AB
>
>
> . =A0

--20cf301af6053f46a504f3e2b007-- From nobody Wed Mar 5 13:29:14 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AA71A077D for ; Wed, 5 Mar 2014 13:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtUnK7KZ19nS for ; Wed, 5 Mar 2014 13:29:12 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id DC3B61A0761 for ; Wed, 5 Mar 2014 13:29:11 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id o15so1592650qap.37 for ; Wed, 05 Mar 2014 13:29:08 -0800 (PST) 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=roS7qDaQ4alYvirbal3UfD4U7hx+C68C4ujmTNb+DCU=; b=kVJbd+wzNJwibtOPw4kIt0LWTVs3IfKJWn4E2dXfKDXiBXwqx5s+oMagJoYS3PiT7a sFuRElxsR9l9O2UcJKRLyhaMkCfAg/9ajxjvWNzRmgkHrKEofpkrFbM9FuS2AE8k5UzY G2r+aRJzbHl5XLCzd3yYBcog/MFEyE5B5eH5xKqb9AdAXR5gIDe/MQ4rGWR0WyhCbD5F Rs1np+5KT3Kx9KHt53tKY7TlQE/tLLP/ckPazUn3FjZ8yRlAdY0f0hY4A69CqjqShSU+ 83vkVoYA9jla0ElN38KwJnhGmcsQvXL5sK0becRayTwPom561K1iSsfKJkPGD70lqzxS t2Jw== X-Received: by 10.224.87.193 with SMTP id x1mr9901624qal.70.1394054948132; Wed, 05 Mar 2014 13:29:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.130.2 with HTTP; Wed, 5 Mar 2014 13:28:48 -0800 (PST) In-Reply-To: References: <3416819E-1188-4AE9-9454-84421FF65A9F@nasa.gov> <508641F2.9050100@fkie.fraunhofer.de> <5088E2B5.60102@fkie.fraunhofer.de> From: Henning Rogge Date: Wed, 5 Mar 2014 21:28:48 +0000 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2KI6UizpCKxP1jX3Ho3PpAUIV7I Cc: manet Subject: Re: [manet] DLEP and modem Link Property Advertisements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:29:13 -0000 No, because of the WG consensus about DLEP I don't plan to continue to work on my informal draft about rfc5444 dlep. Henning On Wed, Mar 5, 2014 at 9:27 PM, Abdussalam Baryun wrote: > Yes Henning, > > I decided to back down to get progress for the DLEP, or to find that my > argument may not get change done. But did you plan to progress that draft > below of yours. > > AB > > > On Wednesday, March 5, 2014, Henning Rogge wrote: >> >> Hi, >> >> we talked about the different approaches for DLEP a LONG time ago... I >> suggested a "stateless UDP" approach, but the WG consensus decided for >> Stans DLEP approach. >> >> I backed down and began to work on helping to improve Stan's DLEP draft. >> >> Can we consider this issue resolved (with WG consensus) after you >> didn't even raised the point at the WG meeting today? >> >> Henning >> >> On Wed, Mar 5, 2014 at 7:47 AM, Abdussalam Baryun >> wrote: >> > Hi Will and Henning, >> > >> > I am not sure of the work in progress related to draft-ivancic and >> > draft-rogge mentioned below. However, I think they are interesting to be >> > consider by the WG. Was there a decision made on the drafts by the >> > authors >> > or was it to be submitted else where. Please help. Thanking you, >> > >> > AB >> > >> > >> > . >> > From nobody Wed Mar 5 17:42:16 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6E81A0056; Wed, 5 Mar 2014 17:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxkE55afZ01k; Wed, 5 Mar 2014 17:42:12 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4E1A004E; Wed, 5 Mar 2014 17:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3231; q=dns/txt; s=iport; t=1394070129; x=1395279729; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FhFbZnP8NOPAOyPRWsQqno7liR09HDnAkAqx8E5A9+0=; b=ZDAnT+4COStrR4TJbCndFDiiNFuEFzRdtf0GoWVn4i5Vvu84WSON2JJ5 HymGUAZc8Jix+Bhrz1lvJnkY1HeAEnDt5+Wp+zQz+IZ0oSASL9nwvaKUY KRj1oZS4kc5Pow+HiVNnq+RMYDzA7JFby+FnN02JODcOC5bE8BWexJXmm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAInRF1OtJV2b/2dsb2JhbABagmUhgRLBE4EZFnSCJQEBAQQnXgQCAQgRBAEBCx0HMhQJCAEBBAESCBOHXgHPGheOIDgGgx6BFAEDiROhVYMtgio X-IronPort-AV: E=Sophos;i="4.97,596,1389744000"; d="scan'208";a="25264708" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 06 Mar 2014 01:42:08 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s261g8O2011287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 01:42:08 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 19:42:08 -0600 From: "Nobo Akiya (nobo)" To: "Snyder, Brian" , "rtg-bfd@ietf.org" , "manet@ietf.org" Thread-Topic: Hello, use case question about BFD Thread-Index: Ac84vWmXOMLqhV2dTI2t+Ls0fEMTwwAEEWFw Date: Thu, 6 Mar 2014 01:42:07 +0000 Message-ID: References: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.254.166] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/iq_ByeOdIDv7tB1ndlRUctI9ekc Subject: Re: [manet] Hello, use case question about BFD X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 01:42:14 -0000 + MANET WG Hi Brian, I agree that no existing BFD would fit well into MANET scenario. Instead of= a proxy approach, I would see variant of multipoint BFD or broadcast-style= BFD may be simpler and more fitting, where each MANET interface would peri= odically broadcast BFD packets and remote state is maintained by reception = of received BFD packets from remote MANET interfaces. If MANET WG thinks, in addition to DLEP, having an efficient hello mechanis= m will be useful and at layer 3, then this would be a technically interesti= ng problem to discuss further. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Snyder, Bria= n > Sent: Wednesday, March 05, 2014 5:02 PM > To: rtg-bfd@ietf.org > Subject: Hello, use case question about BFD >=20 > Hello all, >=20 > I have just started researching BFD and am not sure it is a viable soluti= on to > my networking problem.=A0 If someone would be so kind as to comment on > below I would greatly appreciate it! >=20 > I am interested in determining if one could use BFD in place of a radio a= ware > routing methodology (like DLEP).=A0 My problem with DLEP is that it is no= t a > standard yet and is therefore hard to build anything against. >=20 > I'm thinking BFD could take the place, with a few caveats. >=20 > It seems to me that BFD can't operate in an event driven mode, IE: Sendin= g > a DOWN control packet.=A0 Therefore it is very chatty, even more-so then = the > L3 hello's I'm hoping to minimize.=A0 Since the main purpose is to give q= uicker > convergence then I am willing to configure all the L3 HELLOs (bandwidth i= s > expensive in my environment), I was wondering if 'proxy-ing' the BFD > connections is a viable solution (of course assuming no authentication). >=20 > IE: >=20 > RTR-H -----=A0=A0=A0 HUB-MDM=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <->=A0 MDM-A ---=A0 RTR-A > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0MDM-B --- =A0RTR-B >=20 > So I'm curious if I could have HUB-MDM "proxy/spoof" the BFD control > packets for RTR A and B and have MDM -A/B proxy for Rtr -A/b > respectively. >=20 > Is there any reason why this couldn't work?=A0 If any MDM dropped out of > network, then HUB-MDM would simply stop proxying on his behalf, and > RTR-H should figure it out and kill the peer at BFD speeds. >=20 > Assuming I am on the correct track, would it be further possible to > aggregate with the descrimitor field at HUB-MDM to only have one BFD > session going for all Modems.=A0 There could be thousands of MDM in one > network and I would envision this could be a scale problem for RTR-H to > manage all this, as well as pps scale issue processing all those for both= RTR- > H and HUB-MDM. >=20 > Any thoughts? I am new too this and wondering if I am on the right track = or > wasting my time considering BFD for this purpose.. >=20 > Thanks, > Brian Snyder > Snr. Applied Researcher From nobody Wed Mar 5 22:39:59 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6581A00E4; Wed, 5 Mar 2014 22:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdKCksP_u95b; Wed, 5 Mar 2014 22:39:53 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5E61A00CB; Wed, 5 Mar 2014 22:39:53 -0800 (PST) Received: by mail-yk0-f174.google.com with SMTP id 20so5654202yks.5 for ; Wed, 05 Mar 2014 22:39:49 -0800 (PST) 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=vIIOa3tS/43EiTkpUTUzdG5h6IqJ5JZwEQl0LnNCHKk=; b=J9/2Mlbr/hfLrB9rPFdXLwIK7bXLZbOZttaGEEs5DiZFegPOEmNX3kD7ESrQR+hipa iefNTy1xamdqn+vlKwYvjT6dAXg2jSVnz9a4H++s5Uw+uX+PKkNfgo9a13JD28oUUR9U C+zL4t+SP5isdluZ791uKesCtB6s9TrifLefEWR4lSYJQarW3VvA4Kcb7DOJAO7gIzpp F11IytpD9SHPXTu7AaiXf9z9uCdFNxVCykX1mGrNGOcZTnvkMHlza0bKe3NAdxDwtAAs SbAGmq02OiCFWxWQ0UlgU3vDRuiJ/7vX92HSCL8xIb4HJXSWERGeJ0GYtpdguhVFTZnF YXvQ== MIME-Version: 1.0 X-Received: by 10.236.182.229 with SMTP id o65mr12205607yhm.86.1394087989721; Wed, 05 Mar 2014 22:39:49 -0800 (PST) Received: by 10.170.202.7 with HTTP; Wed, 5 Mar 2014 22:39:49 -0800 (PST) In-Reply-To: References: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> Date: Thu, 6 Mar 2014 07:39:49 +0100 Message-ID: From: Abdussalam Baryun To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=20cf30563ed369bdf804f3ea6792 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3GcSbfJYcesaqZzWk-phOTSpl6U Cc: "rtg-bfd@ietf.org" , "manet@ietf.org" Subject: Re: [manet] Hello, use case question about BFD X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 06:39:56 -0000 --20cf30563ed369bdf804f3ea6792 Content-Type: text/plain; charset=ISO-8859-1 Hi Nobo and Brian, You discussion is not easy for me to find your theory in IETF or in MANET. However, I never say no to reasonable discuss because it is why the list is created. Comments below, On Thursday, March 6, 2014, Nobo Akiya (nobo) wrote: > + MANET WG > > Hi Brian, > > I agree that no existing BFD would fit well into MANET scenario. Instead > of a proxy approach, I would see variant of multipoint BFD or > broadcast-style BFD may be simpler and more fitting, where each MANET > interface would periodically broadcast BFD packets and remote state is > maintained by reception of received BFD packets from remote MANET > interfaces. Was this MANET method BFD documented/published before in or out IETF? Please give link > > If MANET WG thinks, in addition to DLEP, having an efficient hello > mechanism will be useful and at layer 3, then this would be a technically > interesting problem to discuss further. I cannot think about it only if I can understand the purpose problem and solution. I did not understand your points. > -Nobo > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org ] On > Behalf Of Snyder, Brian > > Sent: Wednesday, March 05, 2014 5:02 PM > > To: rtg-bfd@ietf.org > > Subject: Hello, use case question about BFD > > > > Hello all, > > > > I have just started researching BFD and am not sure it is a viable > solution to > > my networking problem. If someone would be so kind as to comment on > > below I would greatly appreciate it! > > > > I am interested in determining if one could use BFD in place of a radio > aware > > routing methodology (like DLEP). My problem with DLEP is that it is not > a > > standard yet and is therefore hard to build anything against. Yes not standard, but it is published, adopted technology by some companies and adopted by IETF MANET WG. Why you use BFD which still not published or used for MANET in community. It may be good but not clear yet, and you did not compare yet between performance of DLEP and BFD performance in MANET so how you decided. > > > I'm thinking BFD could take the place, with a few caveats. I don't think you convinced and your argument is weak. You replacing DLEP by BFD in a MANET scenario, why? > > > It seems to me that BFD can't operate in an event driven mode, IE: > Sending > > a DOWN control packet. Therefore it is very chatty, even more-so then > the > > L3 hello's I'm hoping to minimize. Since the main purpose is to give > quicker > > convergence then I am willing to configure all the L3 HELLOs (bandwidth > is > > expensive in my environment), I was wondering if 'proxy-ing' the BFD > > connections is a viable solution (of course assuming no authentication). How do you compare between both DLEP and BDF solutions for the problem, then we can think clear of if BDF is viable. I don't think of new solution if I have better one published. I don't know if viable only after comparing popular practice solution with new theory solution. Best regards AB --20cf30563ed369bdf804f3ea6792 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Nobo and Brian,

You discussion is not easy for me to = find your theory in IETF or in MANET. However, I never say no to reasonable= =A0discuss because it is why the list is created.=A0=A0Comments below,
<= br> On Thursday, March 6, 2014, Nobo Akiya (nobo) wrote:
+ MANET WG

Hi Brian,

I agree that no existing BFD would fit well into MANET scenario. Instead of= a proxy approach, I would see variant of multipoint BFD or broadcast-style= BFD may be simpler and more fitting, where each MANET interface would peri= odically broadcast BFD packets and remote state is maintained by reception = of received BFD packets from remote MANET interfaces.

Was this MANET=A0method BFD=A0documented/published befo= re in or out IETF? Please give link

If MANET WG thinks, in addition to DLEP, having an efficient hello mechanis= m will be useful and at layer 3, then this would be a technically interesti= ng problem to discuss further.

I cannot thi= nk about it only if I can understand the purpose problem=A0and solution. I = did not understand your points.=A0



-Nobo

> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org= ] On Behalf Of Snyder, Brian
> Sent: Wednesday, March 05, 2014 5:02 PM
> To: rtg-bfd@ietf.org
> Subject: Hello, use case question about BFD
>
> Hello all,
>
> I have just started researching BFD and am not sure it is a viable sol= ution to
> my networking problem.=A0 If someone would be so kind as to comment on=
> below I would greatly appreciate it!
>
> I am interested in determining if one could use BFD in place of a radi= o aware
> routing methodology (like DLEP).=A0 My problem with DLEP is that it is= not a
> standard yet and is therefore hard to build anything against.

Yes not standard, but it is published, adopted tech= nology by some companies and adopted by IETF MANET WG. Why you use BFD whic= h still not published or used=A0for MANET in community. It may be good but = not clear yet, and you did not compare yet between performance of=A0DLEP an= d BFD performance=A0in MANET=A0so how you decided.

>
> I'm thinking BFD could take the place, with a few caveats.

I don't think you convinced and your argument = is weak. You replacing DLEP by BFD in a MANET scenario, why?=A0

>
> It seems to me that BFD can't operate in an event driven mode, IE:= Sending
> a DOWN control packet.=A0 Therefore it is very chatty, even more-so th= en the
> L3 hello's I'm hoping to minimize.=A0 Since the main purpose i= s to give quicker
> convergence then I am willing to configure all the L3 HELLOs (bandwidt= h is
> expensive in my environment), I was wondering if 'proxy-ing' t= he BFD
> connections is a viable solution (of course assuming no authentication= ).

How do you compare between both DLEP and= BDF=A0solutions for the problem, then we can=A0think clear=A0of if BDF=A0i= s viable.=A0

=A0I don't think of new solution if I have better o= ne published. I don't know if viable only after comparing popular pract= ice=A0solution with new theory solution.=A0

Best r= egards
AB
--20cf30563ed369bdf804f3ea6792-- From nobody Thu Mar 6 06:00:10 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0656F1A02A7; Thu, 6 Mar 2014 05:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZZomkp_CXuk; Thu, 6 Mar 2014 05:59:50 -0800 (PST) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 085EA1A0156; Thu, 6 Mar 2014 05:59:49 -0800 (PST) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,600,1389762000"; d="scan'208";a="8437165" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport.idirect.net with ESMTP; 06 Mar 2014 08:59:34 -0500 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 08:59:35 -0500 From: "Snyder, Brian" To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" , "manet@ietf.org" Thread-Topic: Hello, use case question about BFD Thread-Index: Ac84vWmXOMLqhV2dTI2t+Ls0fEMTwwAEEWFwAB0w6OA= Date: Thu, 6 Mar 2014 13:59:19 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7342F2E69C@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/u8ukfcE76Y2m2e1hrWhOhR_xyB0 Subject: Re: [manet] Hello, use case question about BFD X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:59:53 -0000 Nobo, Thank you for your advice. My problem with periodic anything really would = be the cost of bandwidth (even 1 small packet every second) would become ve= ry costly at scale. There could be thousands of modems in one network and i= nroute bandwidth is very expensive. My space is very unique compared to te= rrestrial architectures given how precious bandwidth is (in both directions= , but especially the inroute). With this goal in mind I think proxying mi= ght be better. I could still look into multipoint/broadcast BFD (I actuall= y didn't realize those existed, I was just reading the original RFC I guess= ). Maybe that could help me optimize the hub proxying on behalf of all the= se modems... but my goal still needs to be protect the satellite bandwidth = at all costs. Quesiton: Could BFD allow for an actual proxying node on someone's behalf. = Like is it possible to associate say 1000 different bgp peers/ospf neighbo= rs to the same IPADDR but with different discriminators. So the hub equipm= ent could track a MDM to Discriminator 'session'. Therefore the upstream r= outer implementation would need the ability to demultiplex that discriminat= or to different sessions - with the notion that the IP address you're conne= cting too is explicitly not the actual peer? From my intpretation of RFC58= 80 that's not possible. (But hopefully I'm wrong ;)) That being the case, is there any other way but to proxy (man-in-the-middle= attack) the BFD flow? That should be possible assuming no authentication = -- but clearly less than ideal. Regards, Brian -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Wednesday, March 05, 2014 8:42 PM To: Snyder, Brian; rtg-bfd@ietf.org; manet@ietf.org Subject: RE: Hello, use case question about BFD + MANET WG Hi Brian, I agree that no existing BFD would fit well into MANET scenario. Instead of= a proxy approach, I would see variant of multipoint BFD or broadcast-style= BFD may be simpler and more fitting, where each MANET interface would peri= odically broadcast BFD packets and remote state is maintained by reception = of received BFD packets from remote MANET interfaces. If MANET WG thinks, in addition to DLEP, having an efficient hello mechanis= m will be useful and at layer 3, then this would be a technically interesti= ng problem to discuss further. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Snyder,=20 > Brian > Sent: Wednesday, March 05, 2014 5:02 PM > To: rtg-bfd@ietf.org > Subject: Hello, use case question about BFD >=20 > Hello all, >=20 > I have just started researching BFD and am not sure it is a viable=20 > solution to my networking problem.=A0 If someone would be so kind as to=20 > comment on below I would greatly appreciate it! >=20 > I am interested in determining if one could use BFD in place of a=20 > radio aware routing methodology (like DLEP).=A0 My problem with DLEP is=20 > that it is not a standard yet and is therefore hard to build anything aga= inst. >=20 > I'm thinking BFD could take the place, with a few caveats. >=20 > It seems to me that BFD can't operate in an event driven mode, IE:=20 > Sending a DOWN control packet.=A0 Therefore it is very chatty, even=20 > more-so then the > L3 hello's I'm hoping to minimize.=A0 Since the main purpose is to give=20 > quicker convergence then I am willing to configure all the L3 HELLOs=20 > (bandwidth is expensive in my environment), I was wondering if=20 > 'proxy-ing' the BFD connections is a viable solution (of course assuming = no authentication). >=20 > IE: >=20 > RTR-H -----=A0=A0=A0 HUB-MDM=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <->=A0 MDM-A ---=A0 RTR-A > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 > MDM-B --- =A0RTR-B >=20 > So I'm curious if I could have HUB-MDM "proxy/spoof" the BFD control=20 > packets for RTR A and B and have MDM -A/B proxy for Rtr -A/b=20 > respectively. >=20 > Is there any reason why this couldn't work?=A0 If any MDM dropped out of= =20 > network, then HUB-MDM would simply stop proxying on his behalf, and=20 > RTR-H should figure it out and kill the peer at BFD speeds. >=20 > Assuming I am on the correct track, would it be further possible to=20 > aggregate with the descrimitor field at HUB-MDM to only have one BFD=20 > session going for all Modems.=A0 There could be thousands of MDM in one=20 > network and I would envision this could be a scale problem for RTR-H=20 > to manage all this, as well as pps scale issue processing all those=20 > for both RTR- H and HUB-MDM. >=20 > Any thoughts? I am new too this and wondering if I am on the right=20 > track or wasting my time considering BFD for this purpose.. >=20 > Thanks, > Brian Snyder > Snr. Applied Researcher From nobody Thu Mar 6 06:13:48 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0888D1A0357; Thu, 6 Mar 2014 06:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iYS9zU0UEoG; Thu, 6 Mar 2014 06:13:35 -0800 (PST) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 92C5C1A0361; Thu, 6 Mar 2014 06:13:23 -0800 (PST) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,600,1389762000"; d="scan'208,217";a="8437792" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport.idirect.net with ESMTP; 06 Mar 2014 09:13:19 -0500 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 09:13:19 -0500 From: "Snyder, Brian" To: Abdussalam Baryun , "Nobo Akiya (nobo)" Thread-Topic: [manet] Hello, use case question about BFD Thread-Index: Ac84vWmXOMLqhV2dTI2t+Ls0fEMTwwAEEWFwABjGK4AABO+3oA== Date: Thu, 6 Mar 2014 14:13:03 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7342F2E6D4@VAUS-MBX03.idirect.net> References: <84585478AABBBF4B9DF597FC0F84AF7342F2D1DF@VAUS-MBX03.idirect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/alternative; boundary="_000_84585478AABBBF4B9DF597FC0F84AF7342F2E6D4VAUSMBX03idirec_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pUBC_5dDtShWwpzO9vScjB9qq8M Cc: "rtg-bfd@ietf.org" , "manet@ietf.org" Subject: Re: [manet] Hello, use case question about BFD X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:13:44 -0000 --_000_84585478AABBBF4B9DF597FC0F84AF7342F2E6D4VAUSMBX03idirec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Baryun/Nobo, Thank you for your insight ... I appreciate the conversation..= .. My comments are embedded below --- Brian From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: Thursday, March 06, 2014 1:40 AM To: Nobo Akiya (nobo) Cc: Snyder, Brian; rtg-bfd@ietf.org; manet@ietf.org Subject: Re: [manet] Hello, use case question about BFD Hi Nobo and Brian, You discussion is not easy for me to find your theory in IETF or in MANET. = However, I never say no to reasonable discuss because it is why the list is= created. Comments below, On Thursday, March 6, 2014, Nobo Akiya (nobo) wrote: + MANET WG Hi Brian, I agree that no existing BFD would fit well into MANET scenario. Instead of= a proxy approach, I would see variant of multipoint BFD or broadcast-style= BFD may be simpler and more fitting, where each MANET interface would peri= odically broadcast BFD packets and remote state is maintained by reception = of received BFD packets from remote MANET interfaces. Was this MANET method BFD documented/published before in or out IETF? Pleas= e give link [BS] - Not that I know of, this idea was a product of my own brainstorming = (though others may have gone down this road and I am not aware - as I just = joined both email lists recently). If MANET WG thinks, in addition to DLEP, having an efficient hello mechanis= m will be useful and at layer 3, then this would be a technically interesti= ng problem to discuss further. I cannot think about it only if I can understand the purpose problem and so= lution. I did not understand your points. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f Snyder, Brian > Sent: Wednesday, March 05, 2014 5:02 PM > To: rtg-bfd@ietf.org > Subject: Hello, use case question about BFD > > Hello all, > > I have just started researching BFD and am not sure it is a viable soluti= on to > my networking problem. If someone would be so kind as to comment on > below I would greatly appreciate it! > > I am interested in determining if one could use BFD in place of a radio a= ware > routing methodology (like DLEP). My problem with DLEP is that it is not = a > standard yet and is therefore hard to build anything against. Yes not standard, but it is published, adopted technology by some companies= and adopted by IETF MANET WG. Why you use BFD which still not published or= used for MANET in community. It may be good but not clear yet, and you did= not compare yet between performance of DLEP and BFD performance in MANET s= o how you decided. [BS] - So for a few reasons I thought BFD actually solved my particular pro= blem more elegantly. DLEP would do what I am attempting to do but I have s= ome technical and political concerns. Technically, It seems much heavier then what I require. I have no need for = all the flow control / qos stuff. I simply want to propagate link state for= much faster L3 routing convergence. So aside from all the extra complicat= ions DLEP brings to the solution, it is also more limiting. There are no e= xtensions (that I know of) for having DLEP work with BGP, which is the targ= et routing method of a lot of my customers.... Which brings me to political issues... I feel I'll have very little say or = ability to affect their decisions. If I tell them they must use OSPF for in= stance, I don't think they will agree. Furthermore my second political con= cern, is it seems like one needs a less mainstream cisco build (The 'GC' li= ne) in order to get DLEP functionality on the router. I think it will be a= s big a battle to get folks to change their builds from their already appro= ved and tested rollouts (similar to asking them to change routing protocols= ). I think both these issues will make a DLEP solution very limiting to ou= r audience. Perhaps when DLEP is standardized and therefore promoted into = mainstream routing builds, this political argument will disappear.... I wou= ld love for that to happen, but it's not there yet. However, from what I can tell BFD has none of these issues. It seems to be= in standard cisco builds, it can be used with any higher level routing pro= tocol as it's more 'interface scoped'. This I felt just maps to my problem= better.... with the caveat that it is very chatty and I need to cut that d= own. So BFD has this DEMAND mode that can shut down the chattiness and if = I can proxy it and send an ADMIN_DOWN to shut down routing peers/neighbors = on behalf of modem link state, then I have solved all my problems without n= eeding any OTA chatter - which is the only natural advantage to DLEP, in my= use case. > > I'm thinking BFD could take the place, with a few caveats. I don't think you convinced and your argument is weak. You replacing DLEP b= y BFD in a MANET scenario, why? [BS] - I think I answered this above, please let me know if it's not clear. > > It seems to me that BFD can't operate in an event driven mode, IE: Sendin= g > a DOWN control packet. Therefore it is very chatty, even more-so then th= e > L3 hello's I'm hoping to minimize. Since the main purpose is to give qui= cker > convergence then I am willing to configure all the L3 HELLOs (bandwidth i= s > expensive in my environment), I was wondering if 'proxy-ing' the BFD > connections is a viable solution (of course assuming no authentication). How do you compare between both DLEP and BDF solutions for the problem, the= n we can think clear of if BDF is viable. [BS] - Also I think explained above.... I don't think of new solution if I have better one published. I don't know= if viable only after comparing popular practice solution with new theory s= olution. [BS] - I would agree with you but in this case it seems BFD is actually mor= e mainstream then DLEP, which is a factor in my decision. Best regards AB --_000_84585478AABBBF4B9DF597FC0F84AF7342F2E6D4VAUSMBX03idirec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Baryun/Nobo, Thank you fo= r your insight … I appreciate the conversation…. My comments ar= e embedded below --- Brian

 <= /p>

From: Abdussal= am Baryun [mailto:abdussalambaryun@gmail.com]
Sent: Thursday, March 06, 2014 1:40 AM
To: Nobo Akiya (nobo)
Cc: Snyder, Brian; rtg-bfd@ietf.org; manet@ietf.org
Subject: Re: [manet] Hello, use case question about BFD

 

Hi Nobo and Brian,

 

You discussion is not easy for me to find your theor= y in IETF or in MANET. However, I never say no to reasonable discuss b= ecause it is why the list is created.  Comments below,

On Thursday, March 6, 2014, Nobo Akiya (nobo) wrote:

+ MANET WG

Hi Brian,

I agree that no existing BFD would fit well into MANET scenario. Instead of= a proxy approach, I would see variant of multipoint BFD or broadcast-style= BFD may be simpler and more fitting, where each MANET interface would peri= odically broadcast BFD packets and remote state is maintained by reception of received BFD packets from remot= e MANET interfaces.

 

Was this MANET method BFD documented/publi= shed before in or out IETF? Please give link

 <= /p>

[BS] – Not that I k= now of, this idea was a product of my own brainstorming (though others may = have gone down this road and I am not aware – as I just joined both email lists recently).

 <= /p>


If MANET WG thinks, in addition to DLEP, having an efficient hello mechanis= m will be useful and at layer 3, then this would be a technically interesti= ng problem to discuss further.

 

I cannot think about it only if I can understand the= purpose problem and solution. I did not understand your points. =

 

 


-Nobo

> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of Snyder, Brian
> Sent: Wednesday, March 05, 2014 5:02 PM
> To: rtg-bfd@ietf.org
> Subject: Hello, use case question about BFD
>
> Hello all,
>
> I have just started researching BFD and am not sure it is a viable sol= ution to
> my networking problem.  If someone would be so kind as to comment= on
> below I would greatly appreciate it!
>
> I am interested in determining if one could use BFD in place of a radi= o aware
> routing methodology (like DLEP).  My problem with DLEP is that it= is not a
> standard yet and is therefore hard to build anything against.

 

Yes not standard, but it is published, adopted techn= ology by some companies and adopted by IETF MANET WG. Why you use BFD which= still not published or used for MANET in community. It may be good bu= t not clear yet, and you did not compare yet between performance of DLEP and BFD performance in MANET&nbs= p;so how you decided.

 

[BS] – So for a few= reasons I thought BFD actually solved my particular problem more elegantly= .  DLEP would do what I am attempting to do but I have some technical and political concerns.


Technically, It seems much heavier then what I require. I have no need for = all the flow control / qos stuff. I simply want to propagate link state for= much faster L3 routing convergence.  So aside from all the extra comp= lications DLEP brings to the solution, it is also more limiting.  There are no extensions (that I know of) f= or having DLEP work with BGP, which is the target routing method of a lot o= f my customers….

 <= /p>

Which brings me to politi= cal issues… I feel I’ll have very little say or ability to affe= ct their decisions. If I tell them they must use OSPF for instance, I don’t think they will agree.  Furthermore my second political= concern, is it seems like one needs a less mainstream cisco build (The = 216;GC’ line) in order to get DLEP functionality on the router. = I think it will be as big a battle to get folks to change their builds from their already approved and tested rollouts (similar to asking = them to change routing protocols).  I think both these issues will mak= e a DLEP solution very limiting to our audience.  Perhaps when DLEP is= standardized and therefore promoted into mainstream routing builds, this political argument will disappear…. = I would love for that to happen, but it’s not there yet.

 <= /p>

However, from what I can = tell BFD has none of these issues.  It seems to be in standard cisco b= uilds, it can be used with any higher level routing protocol as it’s more ‘interface scoped’.  This I felt just = maps to my problem better…. with the caveat that it is very chatty an= d I need to cut that down.  So BFD has this DEMAND mode that can shut = down the chattiness and if I can proxy it and send an ADMIN_DOWN to shut down routing peers/neighbors on behalf of modem link state, then I ha= ve solved all my problems without needing any OTA chatter – which is = the only natural advantage to DLEP, in my use case.

 <= /p>

 <= /p>

>
> I'm thinking BFD could take the place, with a few caveats.<= /p>

 

I don't think you convinced and your argument is wea= k. You replacing DLEP by BFD in a MANET scenario, why? 

 <= /p>

[BS] – I think I an= swered this above, please let me know if it’s not clear.

 

>
> It seems to me that BFD can't operate in an event driven mode, IE: Sen= ding
> a DOWN control packet.  Therefore it is very chatty, even more-so= then the
> L3 hello's I'm hoping to minimize.  Since the main purpose is to = give quicker
> convergence then I am willing to configure all the L3 HELLOs (bandwidt= h is
> expensive in my environment), I was wondering if 'proxy-ing' the BFD > connections is a viable solution (of course assuming no authentication= ).

 

How do you compare between both DLEP and BDF so= lutions for the problem, then we can think clear of if BDF i= s viable. 

 

[BS]  - Also I think= explained above….

 <= /p>

 I don't think of new solution if I have better= one published. I don't know if viable only after comparing popular practic= e solution with new theory solution. 

 

[BS] – I would agre= e with you but in this case it seems BFD is actually more mainstream then D= LEP, which is a factor in my decision.

 <= /p>

Best regards

AB

--_000_84585478AABBBF4B9DF597FC0F84AF7342F2E6D4VAUSMBX03idirec_-- From nobody Thu Mar 6 08:16:09 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838811A0110 for ; Thu, 6 Mar 2014 08:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS0Wl8QGMhEX for ; Thu, 6 Mar 2014 08:16:06 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 841E31A00A6 for ; Thu, 6 Mar 2014 08:16:05 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 10so7228156ykt.4 for ; Thu, 06 Mar 2014 08:16:01 -0800 (PST) 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=2qKez/weCt00hP0ExhDiMqb0uvhwyhfoz36vcwjE/d8=; b=cpP7pV8+x6V4qjRLXVAmDdppFnfKWQyuXqteakF/CaVokg8CXlO7WMWuwuqAtMNJKX EYxBQA/g6YIbGtuqZV68c0YRCPqzylK/m24uUrWYluR7mnfHK03tszJhNv8FAg3TLWFo zgoNymSCRxvxfmlneaJL8IjbJrQ3S9dWFI5nCyYDQ8Wu5AL9fm8Aonv/gvXFZco2LMi/ RBnuRDHgSNoC95ulg0Hr2d7j5FJsBF/B+193bg9kAeYhqUMFSW7Pe2g8wsIwi4Bujzla MYdmMy4SDFANHo9WpESzqhkA7fStVywM8Pw+Dno2Clfkx9wOGLrzwJr4qAOc4hbrSBJW j45g== MIME-Version: 1.0 X-Received: by 10.236.191.130 with SMTP id g2mr851574yhn.160.1394122561506; Thu, 06 Mar 2014 08:16:01 -0800 (PST) Received: by 10.170.202.7 with HTTP; Thu, 6 Mar 2014 08:16:01 -0800 (PST) In-Reply-To: <53170334.2020908@computer.org> References: <53170334.2020908@computer.org> Date: Thu, 6 Mar 2014 17:16:01 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=20cf30563d570d521504f3f27475 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ulccPFlpLnCmNPEDrm1PsICIGfY Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:16:08 -0000 --20cf30563d570d521504f3f27475 Content-Type: text/plain; charset=ISO-8859-1 Hi Charles, I just had before a comment on the open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance. For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved). Best Regards AB On Wednesday, March 5, 2014, Charles E. Perkins wrote: > Hello folks, > > Part of the job of finishing the AODVv2 specification will be to comb > the mailing list for issues that are still not resolved. If there are > any specific issues that have not been gotten proper attention, I hope > to find them -- but if anyone would like to help by bringing them > up here on the mailing list, that will be appreciated. > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf30563d570d521504f3f27475 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Charles,

I just had before a comment on the open=A0ti= ckets,=A0were they all closed,=A0because I think may be open. Seems most=A0= MANET WG don't care=A0about tickets but I like to track=A0and I remembe= r that the AD did mention it's importance.=A0

For me I will review new draft and comment, but if the = authors have no more pending=A0issues to update,=A0please confirm (sorry th= at I was not able to remember if there are confirmation from authors that d= raft is ready or not, also need=A0their confirm of=A0final points of open i= ssues for next draft if not resolved).=A0

Best Regards

AB

On Wednesday, = March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved. =A0If there are any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--20cf30563d570d521504f3f27475-- From nobody Thu Mar 6 08:26:43 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAB71A0051 for ; Thu, 6 Mar 2014 08:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V9Rj8LMxhrJ for ; Thu, 6 Mar 2014 08:26:40 -0800 (PST) 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 4F3391A0092 for ; Thu, 6 Mar 2014 08:26:40 -0800 (PST) Received: from [31.133.164.91] by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WLb7z-0007Zh-Jf; Thu, 06 Mar 2014 11:26:35 -0500 Message-ID: <5318A1BA.1020408@computer.org> Date: Thu, 06 Mar 2014 08:26:34 -0800 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <53170334.2020908@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060206090504010303040300" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ffe012e5e4b90868a6512e81c78de34d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.164.91 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vVXUFsby9RO9V0orprl1vlEXjjE Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:26:42 -0000 This is a multi-part message in MIME format. --------------060206090504010303040300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Abdussalam, Actually, all of the issues were resolved. Then, apparently, the issues page crashed, and some recent updates to the issues were lost. However, they were sent to the mailing list, and so are recoverable, with a nontrivial amount of work amounting to an archaeological expedition through the mailing list archives. I wanted to have time to do this, but so far have not. If anyone wants to volunteer to recover the issue-tracker updates from the mailing list, that would be terrific. Regards, Charlie P. On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: > Hi Charles, > > I just had before a comment on the open tickets, were they all > closed, because I think may be open. Seems most MANET WG don't > care about tickets but I like to track and I remember that the AD did > mention it's importance. > > For me I will review new draft and comment, but if the authors have no > more pending issues to update, please confirm (sorry that I was not > able to remember if there are confirmation from authors that draft is > ready or not, also need their confirm of final points of open issues > for next draft if not resolved). > > Best Regards > > AB > > On Wednesday, March 5, 2014, Charles E. Perkins wrote: > > Hello folks, > > Part of the job of finishing the AODVv2 specification will be to comb > the mailing list for issues that are still not resolved. If there are > any specific issues that have not been gotten proper attention, I hope > to find them -- but if anyone would like to help by bringing them > up here on the mailing list, that will be appreciated. > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. --------------060206090504010303040300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved). 

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.
--------------060206090504010303040300-- From nobody Thu Mar 6 08:50:45 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAD91A008B for ; Thu, 6 Mar 2014 08:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0R8hHn86Udh for ; Thu, 6 Mar 2014 08:50:30 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 650A41A0051 for ; Thu, 6 Mar 2014 08:50:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B0DAB1C02DB; Thu, 6 Mar 2014 08:50:26 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from dhcp-hotel-wifi-156-3d.meeting.ietf.org (unknown [130.129.156.61]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 735E81C0776; Thu, 6 Mar 2014 08:50:18 -0800 (PST) From: Thomas Heide Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_391F8DD7-94E1-4E0A-AD6E-DF00D205C7E9" Date: Thu, 6 Mar 2014 17:48:47 +0100 Message-Id: <7C4038A0-9C79-4049-97D7-C563AFEEDC77@thomasclausen.org> To: Mobile Ad Hoc Networks mailing list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yRV4_Xe1XPuQ0vlgcoF9zqCELtM Cc: "" , manet-ads@tools.ietf.org Subject: [manet] Regarding the reactive protocol development - again X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:50:38 -0000 --Apple-Mail=_391F8DD7-94E1-4E0A-AD6E-DF00D205C7E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, I have been requested to - one last time - iterate my comments to the = reactive protocol, currently being discussed by the working group.=20 Somebody *very* persuasive twisted my arm and convinced me to do so - = but I do not write "one last time" lightly: this is the one last shot. First, I would like to direct your attention to this posting from me, = which is from 2010, and which was a review of a predecessor to the = current document.=20 = http://www.ietf.org/mail-archive/web/manet/current/msg11858.html All my comments, and issues raised, in that review (and in other reviews = since then) still apply to the current document - now 4 years later.=20 I have reminded the WG about this review several times, as late as in = November 2013. I shall, in the below, reiterate the key points that I have made in = review quoted above, as well as (as appropriate) add new issues or = update the issues that I have previously raised. I strongly encourage = the WG to look at the details in the review from 2010.=20 Unfortunately, given that the protocol is vastly underspecified and = ridden with options (that also are underspecified), this list probably = is not exhaustive, but it was what I could extract from the = specification as written: o I am confused by the use of square brackets around = stuff: usually, [FOO] refers to a reference in the References section, but this is not = systematically the case in this document (both in the prose and in the notation (cf. = Table 1). o I 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=20 RFC5444 (I have not seen overruling reasons otherwise in = the document). o While we are on the terminology, "packet" appears to be = used both to describe (i) a RFC5444 packet, (ii) a protocol data unit for this = protocol, and (iii) an IP=20 datagram.=20 =09 o There is an awful lot of places where different = terminology is used for the same=20 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. Some of = these terms, but not all, are define. o While we are on that, I notice that "active source" is = used; I am not sure what=20 that is vs a "source" and vs a PktSource. A source is = someone who generates data traffic, I would suspect ... so an active source = is....what? Or, is a source someone who can, but doesn't, generate data traffic? - = if so, what is the significance of that wrt. routing protocol operation? And, wrt a = /reactive/ routing protocol, which I would assume constructs routes only for active = source-destination pairs? o I have a very simple mind, and I like = bullet-point-pseudocode over=20 "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: o Do FOO; otherwise: o Do BAR; 4. Retransmit the RREQ The way in which this document is written is very = confusing: if I was to implement the processing of an incoming RREQ message, which section should I = implement? 7.5 would seem to be the=20 place to start, and it gives and ordered list of things = to do. Except it says... In this section (unless qualified by additional = description such as "upstream" or "neighboring") all occurrences of the term = "router" refer to the AODVv2 router handling the received RteMsg. So, off to chase what "upstream" and "neighboring" mean. = Whoops, "upstream" is not defined. One interpretation would be that it would be "the next hop = towards a gateway to..." something. But to what? Another interpretation would be "the next hop towards = the source of the RteMsg", but as this is part of the route discovery process, I probably do not know = what that would be. Or, is it "the best next-hop towards the source of the RteMsg that I know so far?" Or = ... Section 5.2 says: To avoid repeated failure of Route Discovery, an AODVv2 = router (HandlingRtr) handling a RREP message SHOULD attempt to = verify connectivity to the next upstream router towards AODVv2 = router originating an RREQ message. So for the case when an RteMsg is an RREP, then I could = make a guess that "upstream" means "next hop=20 towards the source of the corresponding RREQ message". = Except Section 7.5 probably also applies to RREQs. So off chasing if there is a rule covering that, = also, and guessing what that rule might mean too. I've only just started to determine if I am to be = processing a given RteMsg, and I am already at a loss for how to proceed, and have had to guess (hoping, of = course, to both guess RIGHT and guess as other implementers, with whom I would hope to be = interoperable, would guess). This is but one example - but, it applies for all such = processes and procedures. The document is=20 vague and underspecified through and through, and not a = solid basis for generating independent and interoperable implementations of this protocol. Another case of underspecification (and I am not = pointing them all out, these are just examples=20 of some of the most flagrant cases): what does = "relevant" mean in the below?=20 Whenever an AODVv2 router (HandlingRtr) handles an incoming RteMsg (i.e., RREQ or RREP), for = every relevant address (RteMsg.Address) in the RteMsg ... How is an implementer supposed to determine with which = addresses (if any) processing is to be=20 undertaken? And one more: Suppose Route[RteMsg.Address] = uses the same metric type as the incoming routing information, and the route entry = contains Route.SeqNum, Route.Metric, and Route.Broken. = Suppose the incoming ... This is a protocol specification, "supposing" is not = supposed to happen - unambiguous instructions that does not require the implementer to undertake guesswork = is required. This *specification* is ripe with such instances of = ambiguities and - as I have indicated in many, many, many previous reviews, requires a very through rework and = complete rewrite. Then, and only then, can we start understanding if the *protocol* itself has = problems. o Related to the above point, an awful lot of the document = is optional, as exemplified by the below: To avoid repeated failure of Route Discovery, an AODVv2 = router (HandlingRtr) handling a RREP message SHOULD attempt to = verify connectivity to the next upstream router towards AODVv2 = router originating an RREQ message. This MAY be done by = including the Acknowledgement Request (AckReq) message TLV (see = Section 15.2) in the RREP. Any unicast packet will satisfy the = Acknowledgement Request, for example an ICMP REPLY message. If the = verification is not received within UNICAST_MESSAGE_SENT_TIMEOUT, = HandlingRtr SHOULD put the upstream neighbor in the blacklist.=20 So I have a (2119-languague) "SHOULD" telling me to = "attempt to verify connectivity". Then a (again, 2119-language) "MAY" suggesting to accomplish that by = sending an AckReq.=20 It's a MAY - therefore, I know (as it's 2119-language) = that I do not have to do that, send that message.=20 But I still SHOULD "attempt to verify connectivity", so = how do I do that? It's not clear what it means that any "unicast packet = will satisfy the Acknowledgement Request" (which I decided to not send, as that was a MAY), nor is = it clear how the routing process will get access to any such unicast packet (assuming, that is, that said = unicast packet isn't destined for that process).=20 Also, I am apparently supposed to receive a = "verification" before some timeout. Search as I may, I have not found anything indicating where that "verification" = is generated, I see no messages defined to this effect, nor any processing allowing me to infer it. Again, this is an example of underspecification, that = leaves each implementation to "guess and interpret" how to proceed - rather than provide an = unambiguous process to follow to ensure interoperability. And this is only ONE from among MANY examples of such in = this specification. Here's another from section 8.2: AODVv2 routers SHOULD monitor connectivity to = adjacent routers along active routes. This monitoring can be accomplished = by one or several mechanisms, including: =09 o Neighborhood discovery [RFC6130] o Route timeout o Lower layer trigger that a link is broken o TCP timeouts o Promiscuous listening o Other monitoring mechanisms or heuristics If a next-hop AODVv2 router has become unreachable, = RERR_Gen follows the procedures specified in Section 8.3.2. So, I will implement this protocol using RFC6130, since = I happen to have an implementation of RFC6130 around.=20 My next-door-neighbor, Francois, also implements this = protocol - but he doesn't have an RFC6130 implementation around, and therefore uses "route timeout". As Francois = and I both are lazy, of course, we implement only one mechanism each (this is allowed, according to the = text). As Francois' implementation doesn't generate RFC6130 = HELLOs, for all intents and purposes he doesn't exist to my implementation, which will establish that no = connectivity to him exists. We've both followed the specification to the letter, = implemented all the SHOULD and MUST - and yet, we can't interoperate. I am *NOT* walking through the entire specification and = pointing out every single such situation, and how each ambiguity and underspecification can lead to = non-interoperable implementations that otherwise can claim to be implementing this specification: there simply are too = many.=20 I have called upon the authors of this specification, = for four years now, to walk through the document and=20 work through these to clarify and render the = specification complete and unambiguous.=20 o EVEN WORSE: I searched through the document for AckReq = and Acknowledgement Request, and I actually do not see any instructions telling me how to = implement the code for processing this. So,=20 this specification allows (MAY) me to send an AckReq - = but doesn't tell me how to process it or how to act when receiving it. =09 Again, this is an example of underspecification, that = leaves each implementation to "guess and interpret" how to proceed - rather than provide an = unambiguous process to follow to ensure interoperability. And this is only ONE from among MANY examples of such in = this specification. o It seems that the protocol does not support routers with = multiple interfaces. There is this paragraph in the applicability statement, which = indicates that it is an insurmountable problem for the authors to address: Multi-homing is difficult unless the sequence number is = expanded to include the AODVv2 router's IP address as well as = SeqNum. Otherwise, comparing sequence numbers would not work to evaluate = freshness. Even when the IP address is included, there isn't a good = way to compare sequence numbers from different IP addresses, = but at least a handling node can determine whether the two given = sequence numbers are comparable. If the route table can store multiple = routes for the same destination, then multi-homing can work with = sequence numbers augmented by IP addresses. Worse, though, after reading this paragraph in the = applicability statement, I actually still do not understand if this protocol can - or, can not - be used on routers = with multiple interfaces. The applicability statement, also, reads: AODVv2 supports routers with multiple interfaces, as long as each interface has its = own (unicast routeable) IP address; the set of all network interfaces = supporting AODVv2 is administratively configured in a list (namely, AODVv2_INTERFACES). which seems to be at odds with the previously quoted = paragraph. So, I still do not know where the protocol applies. This is not unrelated to the next issue.... o In a great many places, it is stated "IP address of the = (node, Adjacent Node, Adjacent Router) sending the message".=20 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 or assumed here? The relationship = node/interface/address is, at best, unclear. =09 It seems to me that this specification is written with = the assumption that each router has *exactly* one interface participating in the routing protocol, with = *exactly* one IP address - and that that router *never* use anything but that IP Address for anything. If that is correct, then it should be written clearly in = the applicability statement that multiple interfaces and multiple addresses are *NOT* supported, and that = this protocol MUST NOT be used in deployments where any router can have more than one interface or = more than one IP Address. If that's not true, then a major rework of the protocol = and the specification is required. This is also not unrelated to the next issue.... o I 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=20 "terminology mnemonics". I note that the text sometimes = uses "router" and=20 sometimes "node", and it is not clear that/if there is a = difference, or if there should be a difference. The word "Router Client" is also = used (albeit inconsistently capitalized) as is "client". An application running on a host has very, very specific = expectations as to how the underlying IP link behaves. Applications "Expect an IP Link that = looks like an Ethernet". I believe that it was Dave Thaler that once said something like "don't expect = Microsoft to rewrite their IP stack..."=20 Applications expect what they expect. Even, a protocol = such as NDP, which an IPv6-host uses to (among other things) configure its interfaces = has this expectation. Therefore, unless the goal is to explicitly not support general = applications and general IP stacks, an appropriate=20 link model must be presented to hosts. Yes, links between MANET routers are not "looking like = an Ethernet". That's quite alright,=20 as long as the *only* application seeing these "MANET = links" is the routing application.=20 Expose the weirdness of "a MANET link" to an = off-the-shelf app or protocol (such as NDP,=20 mDNS, ...), and unpredictable behaviour ensures. The way that other MANET routing protocols have taken = is, to provide an IP hop isolation of the hosts (which run "off the shelf applications") = from the "MANET links": in other words, a "regular IP link" ties the "host" to the "router" and = the "router" then has one or more interfaces towards the "MANET links". o There are a lot of places, where the IP forwarding = engine and the routing protocol process interact - and, in surprising ways. First, there is the whole "react to failure to deliver = an IP datagram due to not having an entry in the routing table, and by way of flooding = control traffic", which is a formidable vector for making every router in the network = participate in a DDOS attack. Second, from section 5.1: =09 The route table entry is a conceptual data structure. Implementations may use any internal representation so = long as it provides access to the information specified below. The route's state determines the operations that can be = performed on the route table entry. During use, an Active route is = maintained continuously by AODVv2 and is considered to remain = active as long as it is used at least once during every ACTIVE_INTERVAL. = When a route is no longer Active, it becomes an Idle route. After an = idle route remains Idle for MAX_IDLETIME, it becomes an Expired = route. An So, part of the data structures, maintained by this = protocol, are the "route table entry", whose state depends on if a route is "used at least once during ..." -- i.e., = the routing process must be notified every time a data packet=20 is being forwarded? I do not know for sure, but I am not = sure that that's even possible to do on commodity=20 operating systems - but, it does appear to be rather = inefficient, increasing per-packet processing overhead for a router? Section 8.1: Before using a route to forward a = packet, an AODVv2 router MUST check the status of the route as follows. Does this imply that the operating system needs to also = be modified to also consult with data-structures,=20 maintained internally by this protocol? The point here is not (necessarily) that it is bad to do = so - but, it would be required that all such assumptions and requirements be called out in the applicability = statement: "This protocol requires that the operating system permits you to do XXX, YYY, ZZZ".=20 o Section 5.4: In order to reduce multicast overhead, retransmitting multicast packets in MANETs SHOULD be done = according to methods specified in [RFC6621] What happens if that "SHOULD" is not done? Does it break = interoperability? Also, RFC6621 is not std.track, so this is a downref that requires special = handling. I note that SHOULD is a fairly strong normative statement, but the RFC6621 is cited as an = informational reference. This does not appear appropriate. And finally, RFC6621 specifies a number of different = algorithms and modes of operation, some of which require additional signalling. For interoperable = implementations to result, this is insufficient. o I have a general concern about how this protocol imposes = constraints on RFC5444 usage, which precludes co-existence with other RFC5444 = protocols running on the same=20 device.=20 Let me give an example hereof, from Section 5.4: When multiple messages are aggregated = into a single packet according to RFC 5444 formatting, and the aggregation of messages = is also authenticated (e.g., with IPsec), and the IP destination = is multiple hops away, it becomes infeasible to delete individual = messages. In such cases, instead of deleting individual messages, = they are maintained in the aggregation of messages, but simply = ignored for further processing. In such cases where individual = messages cannot be deleted, in this document "disregarded" means = "ignored". Otherwise, any such "disregarded" AODVv2 messages SHOULD = be deleted from the aggregated messages in the RFC 5444 packet. An RFC5444 packet is *never* to be sent more than one = hop. Never forwarded. Never. A router=20 receives an RFC5444 packet, decapsulates it, process = each message (if appropriate), the owner process of each message identifies which messages are to be = forwarded (if appropriate), hands those off to the appropriate "message multiplexing engine" which packs = those messages up in a new RFC5444 packet,=20 and transmits that new RFC5444 packet. Also, in RFC5444 messages, addresses are contained in = address blocks. There is no semantics associated with an address being in one address block, = or in another (in fact, (re-)organising addresses into address blocks is one of the tricks to use to = obtain more compact messages). Likewise, there is no semantics associated with an address being first, = last, or in any other position in an address block: the ordering of addresses in an address block carries no = semantics. Therefore, writing something like this: RteMsg.Address[i] denotes the [i]th address in = an RFC 5444 AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes = the associated prefix length for RteMsg.Address[i], and = RteMsg.{field} denotes the corresponding value in the named AddrTLV block = associated with RteMsg.Address[i]. makes no sense whatsoever (aside from the fact that I do = not understand the notation RteMsg.{field} -=20 that would indicate a "field" in a message, not in an = attribute associated with an address).=20 Let me give one more example, from section 9: If a message with an unknown type is received, the message is disregarded. An implementation of this specification will (according = to RFC5444) "own", and therefore get=20 messages that this protocol has gotten assigned by IANA, = say, RREQ/RREP/RERR/RREP_ACK.=20 Messages of any other Message Types will not (again, = according to RFC5444) be delivered to an implementation of this protocol. Therefore, this protocol has no mandate, room, nor = permission to specify discarding any message=20 types other than those than it "owns". o Section 10, this is incorrect, at least as described, or = at best *very* incomplete. What happens when router "inside the MANET" but just = adjacent to the IAR issues a RREQ to a=20 destination inside the MANET? The IAR (presumably = configured to answer to 0::/0) would reply=20 with an RREP. At the very least, the IAR MUST NOT reply to any RREQs, = received on interfaces towards the MANET and for addresses belonging to a prefix covering the = MANET. This is not sufficient, of course, but it is a step towards rendering this correct. o The whole of section 13 must be removed, with the = exception of section 13.6 which is already covered by RFC5444. All the other optional mechanisms are either = underspecified, with known problems in common deployment topologies, or both. Further, they = are clearly indicated as "not needed" so why are they included? o Section 14.2 "Protocol Constants" contains a = semantically null sentence AODVv2 protocol constants typically do not = require changes A constant is constant, therefore it doesn't change. = Even for very loose definitions of constant. With that being said, the interesting part here is = actually not that bit...but rather, what happens *if* these are not set to the values that are indicated? = Or, if different implementations use different values for these? The same holds for 14.2, = btw: is a network able to operate with different routers setting different values? Will it = break? Degrade gracefully? Just work?=20 =09 o Security Considerations First, there is the whole "react to failure to deliver = an IP datagram due to not having an entry in the routing table, and by way of flooding = control traffic", which is a formidable vector for making every router in the network = participate in a DDOS attack. Second: This section does not mandate any specific = security measures. Instead, this section describes various security = considerations and potential avenues to secure AODVv2 routing. If recent dealings with the SEC-ADs are to be believed, = then this is not going to pass muster. At least, a "Mandatory to Implement" security mechanism is going = to be required. Third, Quoting Chris Dearlove: "I'm just going to note that were the security = considerations section in this draft regarded=20 as adequate by the security ADs, then they = would be applying very different standards to=20 those they have applied to OLSRv2. (I think that's easy to see as a factual = statement by consulting the record of what they have=20 required, and then noting that several of = these things are not present in this draft. Note that=20 in the case of OLSRv2 that has resulted in the = production of additional documents. This are not=20 just trivial additions either.)" =09 Fourth: The most important security mechanisms = for AODVv2 routing are integrity/authentication and confidentiality. In situations where routing information or router = identity are suspect, integrity and authentication techniques SHOULD = be applied to AODVv2 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 this protocol? I think that this issue of = mutable messages deserves being called out explicitly in this=20 section, especially if there are known or = recommended ways of handling this (as is the case, for example,=20 in the security considerations section of = RFC5444 regarding the mutable header fields for=20 hop-count/hop-limit of messages As I indicated in the beginning: the protocol specification is ripe with = things that are underspecified, vaguely specified, and options whose = interactions are not well-defined.=20 The above are examples of what is wrong - but not a complete list.=20 This document is *far* from being publishable in its current shape, and = a considerable effort is required to make it publishable - or, even, to = make it into a shape where we can start evaluating if the actual = protocol is a viable candidate for standardisation. It has been four = years now, that I have requested that this effort be expanded on the = document, and on its predecessor, to no avail. Thomas --Apple-Mail=_391F8DD7-94E1-4E0A-AD6E-DF00D205C7E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii All,

I have been requested to - = one last time - iterate my comments to the reactive protocol, currently = being discussed by the working = group. 

Somebody *very* persuasive twisted = my arm and convinced me to do so - but I do not write "one last time" = lightly: this is the one last shot.

First, I = would like to direct your attention to this posting from me, which is = from 2010, and which was a review of a predecessor to the current = document. 

=

All my comments, and issues raised, in that review = (and in other reviews since then) still apply to the current document - = now 4 years later. 
I have reminded the WG about this = review several times, as late as in November = 2013.

I shall, in the below, reiterate the key = points that I have made in review quoted above, as well as (as = appropriate) add new issues or update the issues that I have previously = raised. I strongly encourage the WG to look at the details in the review = from 2010. 

Unfortunately, given that the = protocol is vastly underspecified and ridden with options (that also are = underspecified), this list probably is not exhaustive, but it was what I = could extract from the specification as = written:


o I am = confused by the use of square brackets around stuff: usually, [FOO] = refers to
a reference in the References section, but this = is not systematically the case in this
= document (both in the prose and in the notation (cf. Table = 1).

o I 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).

o While we = are on the terminology, "packet" appears to be used both to = describe
(i) a RFC5444 packet, (ii) a protocol data unit = for this protocol, and (iii) an IP 
= datagram. 

o There 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. Some of these = terms, but
not all, are = define.

o While we are on that, I notice = that "active source" is used; I am not sure what 
= that is vs a "source" and vs a PktSource. A source is someone who = generates
data traffic, I would suspect ... so an active = source is....what?  Or, is a source
= someone who can, but doesn't, generate data traffic? - if so, = what is the significance
of that wrt. routing = protocol operation? And, wrt a /reactive/ routing protocol, = which
= I would assume constructs routes only for active = source-destination pairs?

o 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:
= o Do FOO;
= otherwise:
= o = Do BAR;
4. = Retransmit the RREQ

= The way in which this document is written is very confusing: if I = was to implement the processing
of an incoming RREQ = message, which section should I implement? 7.5 would seem to be = the 
place to start, and it = gives and ordered list of things to do. Except it = says...

		In this section (unless =
qualified by additional description such as
		=
"upstream" or "neighboring") all occurrences of the term =
"router"

		=
refer to the AODVv2 router handling the received RteMsg.

So, off to chase what = "upstream" and "neighboring" mean. Whoops, "upstream" is not defined. = One
= interpretation would be that it would be "the next hop towards a = gateway to..." something. But to what?
= Another interpretation would be "the next hop towards the source = of the RteMsg", but as this is part
= of the route discovery process, I probably do not know what that = would be. Or, is it "the best next-hop
= towards the source of the RteMsg that I know so far?" Or = ...

Section 5.2 = says:

		=
To avoid repeated failure of Route Discovery, an AODVv2 router
		=
(HandlingRtr) handling a RREP message SHOULD attempt to verify
		=
connectivity to the next upstream router towards AODVv2 router
		=
originating an RREQ message.

= So for the case when an RteMsg is an RREP, then I could make a = guess that "upstream" means "next hop 
= towards the source of the corresponding RREQ message". Except = Section 7.5 probably also applies to
= RREQs. So off chasing if there is a rule covering that, also, and = guessing what that rule might mean too.

= I've only just started to determine if I am to be processing a = given RteMsg, and I am already at a loss for
= how to proceed, and have had to guess (hoping, of course, to both = guess RIGHT and guess as other
implementers, with whom I = would hope to be interoperable, would = guess).

This is but one example - = but, it applies for all such processes and procedures. The document = is 
vague and underspecified = through and through, and not a solid basis for generating = independent
and interoperable = implementations of this protocol.

		Another =
case of underspecification (and I am not pointing them all out, these =
are just examples 
		of some of the most =
flagrant cases): what does "relevant" mean in the =
below? 

		=
   Whenever an AODVv2 router (HandlingRtr)
		   handles an incoming =
RteMsg (i.e., RREQ or RREP), for every relevant
		   address =
(RteMsg.Address) in the RteMsg =
...

= How is an implementer supposed to determine with which addresses = (if any) processing is to be 
= undertaken?

And one = more:

= Suppose Route[RteMsg.Address] = uses the same metric type as the
 		   incoming routing =
information, and the route entry contains
		=
   Route.SeqNum, Route.Metric, and Route.Broken.  Suppose the =
incoming ...

This is a protocol = specification, "supposing" is not supposed to happen - unambiguous = instructions that
does not require the = implementer to undertake guesswork is = required.

This *specification* is = ripe with such instances of ambiguities and - as I have indicated in = many, many, many
previous reviews, = requires a very through rework and complete rewrite. Then, and only = then, can we
start understanding if = the *protocol* itself has = problems.


o Related = to the above point, an awful lot of the document is optional, as = exemplified by the below:

		To avoid repeated failure of Route Discovery, an AODVv2 =
router
		(HandlingRtr) handling a =
RREP message SHOULD attempt to verify
		connectivity to the next =
upstream router towards AODVv2 router
		originating an RREQ =
message. This MAY be done by including =
the
		=
Acknowledgement Request (AckReq) message TLV (see Section 15.2) in
		=
the RREP.  Any unicast packet will satisfy the Acknowledgement
		=
Request, for example an ICMP REPLY message.  If the verification =
is
		=
not received within UNICAST_MESSAGE_SENT_TIMEOUT, HandlingRtr =
SHOULD
		=
put the upstream neighbor in the blacklist. =

So I have a = (2119-languague) "SHOULD" telling me to "attempt to verify = connectivity". Then a (again,
2119-language) "MAY" = suggesting to accomplish that by sending an = AckReq. 

It's a MAY - therefore, I = know (as it's 2119-language) that I do not have to do that, send that = message. 
But I still SHOULD = "attempt to verify connectivity", so how do I do = that?

It's not clear what it = means that any "unicast packet will satisfy the Acknowledgement = Request"
(which I decided to not = send, as that was a MAY), nor is it clear how the routing process will = get access
to any such unicast = packet (assuming, that is, that said unicast packet isn't destined for = that process). 

= Also, I am apparently supposed to receive a "verification" before = some timeout. Search as I may, I have
= not found anything indicating where that "verification" is = generated, I see no messages defined to this
= effect, nor any processing allowing me to infer = it.

Again, this is an example = of underspecification, that leaves each implementation to "guess = and
interpret" how to proceed - rather than provide = an unambiguous process to follow to ensure
= interoperability.

= And this is only ONE from among MANY examples of such in this = specification. Here's another from section = 8.2:

		=
   AODVv2 routers SHOULD monitor connectivity to adjacent routers =
along
		=
   active routes.  This monitoring can be accomplished by one or =
several
		=
   mechanisms, including:
	
		=
   o  Neighborhood discovery [RFC6130]
		=
   o  Route timeout
		=
   o  Lower layer trigger that a link is broken
		=
   o  TCP timeouts
		=
   o  Promiscuous listening
		=
   o  Other monitoring mechanisms or heuristics

		=
   If a next-hop AODVv2 router has become unreachable, RERR_Gen =
follows
		=
   the procedures specified in Section =
8.3.2.


= So, I will implement this protocol using RFC6130, since I happen = to have an implementation of RFC6130 around. 
= My next-door-neighbor, Francois, also implements this protocol - = but he doesn't have an RFC6130 implementation
= around, and therefore uses "route timeout". As Francois and I = both are lazy, of course, we implement only
= one mechanism each (this is allowed, according to the = text).

As Francois' = implementation doesn't generate RFC6130 HELLOs, for all intents and = purposes he doesn't
exist to my = implementation, which will establish that no connectivity to him = exists.

We've both followed the = specification to the letter, implemented all the SHOULD and MUST - and = yet, we can't
= interoperate.

I = am *NOT* walking through the entire specification and pointing out every = single such situation, and how each
= ambiguity and underspecification can lead to non-interoperable = implementations that otherwise can claim to be
= implementing this specification: there simply are too = many. 

I have called upon the = authors of this specification, for four years now, to walk through the = document and 
work through these to = clarify and render the specification complete and = unambiguous. 

o EVEN WORSE: I searched through = the document for AckReq and Acknowledgement Request, and = I
= actually do not see any instructions telling me how to implement = the code for processing this. So, 
= this specification allows (MAY) me to send an AckReq - but = doesn't tell me how to process it or
= how to act when receiving it.
=
Again, this is an example = of underspecification, that leaves each implementation to "guess = and
= interpret" how to proceed - rather than provide an unambiguous = process to follow to ensure
= interoperability.

= And this is only ONE from among MANY examples of such in this = specification.


o It seems = that the protocol does not support routers with multiple interfaces. = There is this
paragraph in the = applicability statement, which indicates that it is an insurmountable = problem
for the authors to = address:

		=
Multi-homing is difficult unless the sequence number is expanded =
to
		include the AODVv2 =
router's IP address as well as SeqNum.  Otherwise,
		comparing sequence =
numbers would not work to evaluate freshness.
		Even when the IP address =
is included, there isn't a good way to
		compare sequence numbers =
from different IP addresses, but at least a
		handling node can =
determine whether the two given sequence numbers
		are comparable.  If the =
route table can store multiple routes for the
		same destination, then =
multi-homing can work with sequence numbers

		augmented by IP =
addresses.

Worse, though, after = reading this paragraph in the applicability statement, I actually still = do not understand
if this protocol can - = or, can not - be used on routers with multiple = interfaces.

The applicability = statement, also, reads:

= AODVv2 supports routers = with
		=
multiple interfaces, as long as each interface has its own =
(unicast
		=
routeable) IP address; the set of all network interfaces =
supporting
		=
AODVv2 is administratively configured in a list (namely,
		=
AODVv2_INTERFACES).

= which seems to be at odds with the previously quoted paragraph. = So, I still do not know where the protocol
= applies.

This is not unrelated to = the next issue....

o In a great many places, it is = stated "IP address of the (node, Adjacent Node, Adjacent Router) 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 or assumed here? The relationship = node/interface/address is, at best, unclear.
=
It seems to me that this = specification is written with the assumption that each router has = *exactly* one
interface participating = in the routing protocol, with *exactly* one IP address - and that that = router *never*
use anything but that IP = Address for anything.

= If that is correct, then it should be written clearly in the = applicability statement that multiple interfaces
= and multiple addresses are *NOT* supported, and that this = protocol MUST NOT be used in deployments
= where any router can have more than one interface or more than = one IP Address.

If that's not true, then = a major rework of the protocol and the specification is = required.

This is also not = unrelated to the next issue....

o I 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 word "Router Client" is also used = (albeit inconsistently capitalized)
= as is "client".

= An application running on a host has very, very specific = expectations as to how the underlying
= IP link behaves. Applications "Expect an IP Link that looks like = an Ethernet". I believe that it was
= Dave Thaler that once said something like "don't expect Microsoft = to rewrite their IP stack..." 
= Applications expect what they expect. Even, a protocol such as = NDP, which an IPv6-host
uses to (among other = things) configure its interfaces has this expectation. Therefore, = unless
the goal is to explicitly not support general = applications and general IP stacks, an appropriate 
= link model must be presented to = hosts.

Yes, links between MANET = routers are not "looking like an Ethernet". That's quite = alright, 
as long as the *only* = application seeing these "MANET links" is the routing = application. 
Expose the weirdness of = "a MANET link" to an off-the-shelf app or protocol (such as = NDP, 
mDNS, ...), and = unpredictable behaviour ensures.

= The way that other MANET routing protocols have taken is, to = provide an IP hop isolation
of the hosts (which run = "off the shelf applications") from the "MANET links": in other = words,
= a "regular IP link" ties the "host" to the = "router" and the "router" then has one or more
= interfaces towards the "MANET = links".

o There are a lot of places, where = the IP forwarding engine and the routing protocol = process
interact - and, in = surprising ways.

First, there is the whole = "react to failure to deliver an IP datagram due to not = having
= an entry in the routing table, and by way of = flooding control traffic", which is a formidable
= vector for making every router in the network participate in = a DDOS attack.

Second, from section = 5.1:
		The route table entry is a conceptual data =
structure.
		=
Implementations may use any internal representation so long as it
		=
provides access to the information specified =
below.

= <snip>

		The route's state =
determines the operations that can be performed on
		=
the route table entry.  During use, an Active route is maintained
		=
continuously by AODVv2 and is considered to remain active as long =
as
		=
it is used at least once during every ACTIVE_INTERVAL.  When a =
route
		=
is no longer Active, it becomes an Idle route.  After an idle =
route
		=
remains Idle for MAX_IDLETIME, it becomes an Expired route.  =
An


So, part of the data = structures, maintained by this protocol, are the "route table entry", = whose state depends on
if a route is "used at = least once during ..." -- i.e., the routing process must be notified = every time a data packet 
is being forwarded? I do = not know for sure, but I am not sure that that's even possible to do on = commodity 
= operating systems - but, it does appear to be rather inefficient, = increasing per-packet processing overhead
for a = router?

Section = 8.1:
=   Before using a route to forward a packet, an AODVv2 = router MUST check
   =
		=
the status of the route as follows.

Does this imply that the = operating system needs to also be modified to also consult with = data-structures, 
maintained internally by = this protocol?


The point here is not = (necessarily) that it is bad to do so - but, it would be required that = all such assumptions
and requirements be = called out in the applicability statement: "This protocol requires that = the operating system
permits you to do XXX, = YYY, ZZZ". 

o Section 5.4:
= In order to reduce multicast = overhead,
   =
	  =
 retransmitting multicast packets in MANETs SHOULD be done according
	  =
 to methods specified in [RFC6621]

= What happens if that "SHOULD" is not done? Does it break = interoperability? Also, RFC6621 is not
= std.track, so this is a downref that requires special handling. I = note that SHOULD is a fairly strong
= normative statement, but the RFC6621 is cited as an informational = reference. This does not appear
= appropriate.

= And finally, RFC6621 specifies a number of different algorithms = and modes of operation, some of which
= require additional signalling. For interoperable implementations = to result, this is insufficient.


	o	I have a general concern about how this protocol imposes =
constraints on RFC5444 usage,
		which precludes =
co-existence with other RFC5444 protocols running on the =
same 
		device. 

		Let me give an example =
hereof, from Section 5.4:

		 		=
When multiple messages are aggregated into a single packet =
according
		=
to RFC 5444 =
formatting, and the aggregation of messages is also
		=
authenticated (e.g., with IPsec), and the IP destination is =
multiple
		=
hops away, it becomes infeasible to delete individual messages.  =
In
		=
such cases, instead of deleting individual messages, they are
		=
maintained in the aggregation of messages, but simply ignored for
		=
further processing.  In such cases where individual messages =
cannot
		=
be deleted, in this document "disregarded" means "ignored".
		=
Otherwise, any such "disregarded" AODVv2 messages SHOULD be =
deleted
		=
from the aggregated messages in the RFC 5444 =
packet.

		=
An =
RFC5444 packet is *never* to be sent more than one hop. Never forwarded. =
Never. A router 
		receives an RFC5444 =
packet, decapsulates it, process each message (if appropriate), the =
owner process
		of each message identifies which messages are to be forwarded (if appropriate), hands those off to =
the
		appropriate "message =
multiplexing engine" which packs those messages up in a new RFC5444 =
packet, 
		and =
transmits that new RFC5444 =
packet.

		Also, in RFC5444 =
messages, addresses are contained in address blocks. There is no =
semantics
		associated with an =
address being in one address block, or in another (in fact, =
(re-)organising addresses
		into address blocks is =
one of the tricks to use to obtain more compact messages). Likewise, =
there is
		no semantics associated =
with an address being first, last, or in any other position in an =
address block:
		the ordering of addresses =
in an address block carries no semantics.

		Therefore, writing =
something like this:

			=
RteMsg.Address[i] denotes =
the [i]th address in an RFC
	  =
 5444 AddrBlk of the RteMsg. =
  RteMsg.PrefixLength[i] denotes =
the
	   =
associated prefix length for RteMsg.Address[i], and RteMsg.{field}
	  =
 denotes the corresponding value in the named AddrTLV block associated
	  =
 with RteMsg.Address[i].

		makes no sense whatsoever (aside from the fact =
that I do not understand the notation RteMsg.{field} =
- 
		=
that would indicate a "field" in a message, not in an attribute =
associated with an address). 

		Let me give one more example, from section =
9:

	   If a message with an unknown =
type is received, the message is
	  =
 disregarded.


		An implementation of this specification will (according =
to RFC5444) "own", and therefore get 
		=
messages that this protocol has gotten assigned by IANA, say, =
RREQ/RREP/RERR/RREP_ACK. 
		=
Messages of any other Message Types will not (again, according to =
RFC5444) be delivered to
		an implementation of this =
protocol.

		Therefore, this protocol =
has no mandate, room, nor permission to specify discarding any =
message 
		types other than those =
than it "owns".

	o	Section 10, this is incorrect, at =
least as described, or at best *very* incomplete.

		What happens =
when router "inside the MANET" but just adjacent to the IAR issues =
a RREQ to a 
		destination inside the =
MANET? The IAR (presumably configured to answer to 0::/0) would =
reply 
		with an =
RREP.

		At the very least, the =
IAR MUST NOT reply to any RREQs, received on interfaces towards the =
MANET
		and for addresses =
belonging to a prefix covering the MANET. This is not sufficient, of =
course, but it
		is a step towards =
rendering this correct.

	o	The whole =
of section 13 must be removed, with the exception of section 13.6 which =
is already covered
		by RFC5444. All the other =
optional mechanisms are either underspecified, with known =
problems
		in common deployment =
topologies, or both. Further, they are clearly indicated as "not needed" =
so
		=
why are they included?

	o	Section =
14.2 "Protocol Constants" contains a semantically null =
sentence

			AODVv2 protocol constants typically do not =
require changes

	=
	=
A =
constant is constant, therefore it doesn't change. Even for very loose =
definitions of constant.
		With that being said, the =
interesting part here is actually not that bit...but rather, what =
happens
		*if* these are not set to =
the values that are indicated? Or, if different implementations =
use
		=
different values for these? The same holds for 14.2, btw: is a =
network able to operate with
		different routers setting =
different values? Will it break? Degrade gracefully? Just =
work? 

	
	o	Security Considerations

		=
First, there is the whole "react to failure to deliver an IP =
datagram due to not having
		an entry in the routing table, and by way of =
flooding control traffic", which is a formidable
		=
vector for making every router in the network participate in =
a DDOS attack.

	=
Second:

=  This section does not = mandate any specific security measures.
	  =
 Instead, this section describes various security considerations and
	   potential avenues to secure =
AODVv2 routing.

If recent dealings with = the SEC-ADs are to be believed, then this is not going to pass muster. = At least,
a "Mandatory to = Implement" security mechanism is going to be = required.

Third, Quoting Chris = Dearlove:
"I'm just going = to note that were the security considerations section in this draft = regarded 
 as adequate = by the security ADs, then they would be applying very different = standards to 
 those they = have applied to OLSRv2.

 (I think = that's easy to see as a factual statement by consulting the record of = what they have 
=   required, and then noting that several of these = things are not present in this draft. Note that 
=   in the case of OLSRv2 that has resulted in the = production of additional documents. This are not 
=   just trivial additions = either.)"
= Fourth:
= The most important security = mechanisms for AODVv2 routing are
		integrity/authentication =
and confidentiality.

		=
In situations where routing information or router identity are
		=
suspect, integrity and authentication techniques SHOULD be =
applied to
		=
AODVv2 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
= this protocol?  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

As I = indicated in the beginning: the protocol specification is ripe with = things that are underspecified, vaguely specified, and options whose = interactions are not well-defined. 

The = above are examples of what is wrong - but not a complete = list. 

This document is *far* from being = publishable in its current shape, and a considerable effort is required = to make it publishable - or, even, to make it into a shape where we can = start evaluating if the actual protocol is a viable candidate for = standardisation. It has been four years now, that I have requested that = this effort be expanded on the document, and on its predecessor, to no = avail.

Thomas


=

= --Apple-Mail=_391F8DD7-94E1-4E0A-AD6E-DF00D205C7E9-- From nobody Thu Mar 6 08:52:03 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4F1A006B for ; Thu, 6 Mar 2014 08:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQH7_v4kKKlO for ; Thu, 6 Mar 2014 08:51:47 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 029411A0122 for ; Thu, 6 Mar 2014 08:51:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 594731CA6A07; Thu, 6 Mar 2014 08:51:42 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-hotel-wifi-156-3d.meeting.ietf.org (unknown [130.129.156.61]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0D4801CA6A0B; Thu, 6 Mar 2014 08:51:39 -0800 (PST) From: Thomas Heide Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_342D79F1-7639-4791-8A65-09CDF80ABDD1" Date: Thu, 6 Mar 2014 17:50:38 +0100 Message-Id: <2AD1987F-0468-4EF7-9826-C9B16EDB332E@thomasclausen.org> To: Mobile Ad Hoc Networks mailing list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2fneeocWhBZ2n3Fji7y24MS-JqY Cc: "" , manet-ads@tools.ietf.org Subject: [manet] Regarding the reactive protocol development - again X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:52:00 -0000 --Apple-Mail=_342D79F1-7639-4791-8A65-09CDF80ABDD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear All, I have been requested to - one last time - iterate my comments to the = reactive protocol, currently being discussed by the working group.=20 Somebody *very* persuasive twisted my arm and convinced me to do so - = but I do not write "one last time" lightly: this is the one last shot. First, I would like to direct your attention to this posting from me, = which is from 2010, and which was a review of a predecessor to the = current document.=20 = http://www.ietf.org/mail-archive/web/manet/current/msg11858.html All my comments, and issues raised, in that review (and in other reviews = since then) still apply to the current document - now 4 years later.=20 I have reminded the WG about this review several times, as late as in = November 2013. I shall, in the below, reiterate the key points that I have made in = review quoted above, as well as (as appropriate) add new issues or = update the issues that I have previously raised. I strongly encourage = the WG to look at the details in the review from 2010.=20 Unfortunately, given that the protocol is vastly underspecified and = ridden with options (that also are underspecified), this list probably = is not exhaustive, but it was what I could extract from the = specification as written: o I am confused by the use of square brackets around = stuff: usually, [FOO] refers to a reference in the References section, but this is not = systematically the case in this document (both in the prose and in the notation (cf. = Table 1). o I 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=20 RFC5444 (I have not seen overruling reasons otherwise in = the document). o While we are on the terminology, "packet" appears to be = used both to describe (i) a RFC5444 packet, (ii) a protocol data unit for this = protocol, and (iii) an IP=20 datagram.=20 =09 o There is an awful lot of places where different = terminology is used for the same=20 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. Some of = these terms, but not all, are define. o While we are on that, I notice that "active source" is = used; I am not sure what=20 that is vs a "source" and vs a PktSource. A source is = someone who generates data traffic, I would suspect ... so an active source = is....what? Or, is a source someone who can, but doesn't, generate data traffic? - = if so, what is the significance of that wrt. routing protocol operation? And, wrt a = /reactive/ routing protocol, which I would assume constructs routes only for active = source-destination pairs? o I have a very simple mind, and I like = bullet-point-pseudocode over=20 "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: o Do FOO; otherwise: o Do BAR; 4. Retransmit the RREQ The way in which this document is written is very = confusing: if I was to implement the processing of an incoming RREQ message, which section should I = implement? 7.5 would seem to be the=20 place to start, and it gives and ordered list of things = to do. Except it says... In this section (unless qualified by additional = description such as "upstream" or "neighboring") all occurrences of the term = "router" refer to the AODVv2 router handling the received RteMsg. So, off to chase what "upstream" and "neighboring" mean. = Whoops, "upstream" is not defined. One interpretation would be that it would be "the next hop = towards a gateway to..." something. But to what? Another interpretation would be "the next hop towards = the source of the RteMsg", but as this is part of the route discovery process, I probably do not know = what that would be. Or, is it "the best next-hop towards the source of the RteMsg that I know so far?" Or = ... Section 5.2 says: To avoid repeated failure of Route Discovery, an AODVv2 = router (HandlingRtr) handling a RREP message SHOULD attempt to = verify connectivity to the next upstream router towards AODVv2 = router originating an RREQ message. So for the case when an RteMsg is an RREP, then I could = make a guess that "upstream" means "next hop=20 towards the source of the corresponding RREQ message". = Except Section 7.5 probably also applies to RREQs. So off chasing if there is a rule covering that, = also, and guessing what that rule might mean too. I've only just started to determine if I am to be = processing a given RteMsg, and I am already at a loss for how to proceed, and have had to guess (hoping, of = course, to both guess RIGHT and guess as other implementers, with whom I would hope to be = interoperable, would guess). This is but one example - but, it applies for all such = processes and procedures. The document is=20 vague and underspecified through and through, and not a = solid basis for generating independent and interoperable implementations of this protocol. Another case of underspecification (and I am not = pointing them all out, these are just examples=20 of some of the most flagrant cases): what does = "relevant" mean in the below?=20 Whenever an AODVv2 router (HandlingRtr) handles an incoming RteMsg (i.e., RREQ or RREP), for = every relevant address (RteMsg.Address) in the RteMsg ... How is an implementer supposed to determine with which = addresses (if any) processing is to be=20 undertaken? And one more: Suppose Route[RteMsg.Address] = uses the same metric type as the incoming routing information, and the route entry = contains Route.SeqNum, Route.Metric, and Route.Broken. = Suppose the incoming ... This is a protocol specification, "supposing" is not = supposed to happen - unambiguous instructions that does not require the implementer to undertake guesswork = is required. This *specification* is ripe with such instances of = ambiguities and - as I have indicated in many, many, many previous reviews, requires a very through rework and = complete rewrite. Then, and only then, can we start understanding if the *protocol* itself has = problems. o Related to the above point, an awful lot of the document = is optional, as exemplified by the below: To avoid repeated failure of Route Discovery, an AODVv2 = router (HandlingRtr) handling a RREP message SHOULD attempt to = verify connectivity to the next upstream router towards AODVv2 = router originating an RREQ message. This MAY be done by = including the Acknowledgement Request (AckReq) message TLV (see = Section 15.2) in the RREP. Any unicast packet will satisfy the = Acknowledgement Request, for example an ICMP REPLY message. If the = verification is not received within UNICAST_MESSAGE_SENT_TIMEOUT, = HandlingRtr SHOULD put the upstream neighbor in the blacklist.=20 So I have a (2119-languague) "SHOULD" telling me to = "attempt to verify connectivity". Then a (again, 2119-language) "MAY" suggesting to accomplish that by = sending an AckReq.=20 It's a MAY - therefore, I know (as it's 2119-language) = that I do not have to do that, send that message.=20 But I still SHOULD "attempt to verify connectivity", so = how do I do that? It's not clear what it means that any "unicast packet = will satisfy the Acknowledgement Request" (which I decided to not send, as that was a MAY), nor is = it clear how the routing process will get access to any such unicast packet (assuming, that is, that said = unicast packet isn't destined for that process).=20 Also, I am apparently supposed to receive a = "verification" before some timeout. Search as I may, I have not found anything indicating where that "verification" = is generated, I see no messages defined to this effect, nor any processing allowing me to infer it. Again, this is an example of underspecification, that = leaves each implementation to "guess and interpret" how to proceed - rather than provide an = unambiguous process to follow to ensure interoperability. And this is only ONE from among MANY examples of such in = this specification. Here's another from section 8.2: AODVv2 routers SHOULD monitor connectivity to = adjacent routers along active routes. This monitoring can be accomplished = by one or several mechanisms, including: =09 o Neighborhood discovery [RFC6130] o Route timeout o Lower layer trigger that a link is broken o TCP timeouts o Promiscuous listening o Other monitoring mechanisms or heuristics If a next-hop AODVv2 router has become unreachable, = RERR_Gen follows the procedures specified in Section 8.3.2. So, I will implement this protocol using RFC6130, since = I happen to have an implementation of RFC6130 around.=20 My next-door-neighbor, Francois, also implements this = protocol - but he doesn't have an RFC6130 implementation around, and therefore uses "route timeout". As Francois = and I both are lazy, of course, we implement only one mechanism each (this is allowed, according to the = text). As Francois' implementation doesn't generate RFC6130 = HELLOs, for all intents and purposes he doesn't exist to my implementation, which will establish that no = connectivity to him exists. We've both followed the specification to the letter, = implemented all the SHOULD and MUST - and yet, we can't interoperate. I am *NOT* walking through the entire specification and = pointing out every single such situation, and how each ambiguity and underspecification can lead to = non-interoperable implementations that otherwise can claim to be implementing this specification: there simply are too = many.=20 I have called upon the authors of this specification, = for four years now, to walk through the document and=20 work through these to clarify and render the = specification complete and unambiguous.=20 o EVEN WORSE: I searched through the document for AckReq = and Acknowledgement Request, and I actually do not see any instructions telling me how to = implement the code for processing this. So,=20 this specification allows (MAY) me to send an AckReq - = but doesn't tell me how to process it or how to act when receiving it. =09 Again, this is an example of underspecification, that = leaves each implementation to "guess and interpret" how to proceed - rather than provide an = unambiguous process to follow to ensure interoperability. And this is only ONE from among MANY examples of such in = this specification. o It seems that the protocol does not support routers with = multiple interfaces. There is this paragraph in the applicability statement, which = indicates that it is an insurmountable problem for the authors to address: Multi-homing is difficult unless the sequence number is = expanded to include the AODVv2 router's IP address as well as = SeqNum. Otherwise, comparing sequence numbers would not work to evaluate = freshness. Even when the IP address is included, there isn't a good = way to compare sequence numbers from different IP addresses, = but at least a handling node can determine whether the two given = sequence numbers are comparable. If the route table can store multiple = routes for the same destination, then multi-homing can work with = sequence numbers augmented by IP addresses. Worse, though, after reading this paragraph in the = applicability statement, I actually still do not understand if this protocol can - or, can not - be used on routers = with multiple interfaces. The applicability statement, also, reads: AODVv2 supports routers with multiple interfaces, as long as each interface has its = own (unicast routeable) IP address; the set of all network interfaces = supporting AODVv2 is administratively configured in a list (namely, AODVv2_INTERFACES). which seems to be at odds with the previously quoted = paragraph. So, I still do not know where the protocol applies. This is not unrelated to the next issue.... o In a great many places, it is stated "IP address of the = (node, Adjacent Node, Adjacent Router) sending the message".=20 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 or assumed here? The relationship = node/interface/address is, at best, unclear. =09 It seems to me that this specification is written with = the assumption that each router has *exactly* one interface participating in the routing protocol, with = *exactly* one IP address - and that that router *never* use anything but that IP Address for anything. If that is correct, then it should be written clearly in = the applicability statement that multiple interfaces and multiple addresses are *NOT* supported, and that = this protocol MUST NOT be used in deployments where any router can have more than one interface or = more than one IP Address. If that's not true, then a major rework of the protocol = and the specification is required. This is also not unrelated to the next issue.... o I 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=20 "terminology mnemonics". I note that the text sometimes = uses "router" and=20 sometimes "node", and it is not clear that/if there is a = difference, or if there should be a difference. The word "Router Client" is also = used (albeit inconsistently capitalized) as is "client". An application running on a host has very, very specific = expectations as to how the underlying IP link behaves. Applications "Expect an IP Link that = looks like an Ethernet". I believe that it was Dave Thaler that once said something like "don't expect = Microsoft to rewrite their IP stack..."=20 Applications expect what they expect. Even, a protocol = such as NDP, which an IPv6-host uses to (among other things) configure its interfaces = has this expectation. Therefore, unless the goal is to explicitly not support general = applications and general IP stacks, an appropriate=20 link model must be presented to hosts. Yes, links between MANET routers are not "looking like = an Ethernet". That's quite alright,=20 as long as the *only* application seeing these "MANET = links" is the routing application.=20 Expose the weirdness of "a MANET link" to an = off-the-shelf app or protocol (such as NDP,=20 mDNS, ...), and unpredictable behaviour ensures. The way that other MANET routing protocols have taken = is, to provide an IP hop isolation of the hosts (which run "off the shelf applications") = from the "MANET links": in other words, a "regular IP link" ties the "host" to the "router" and = the "router" then has one or more interfaces towards the "MANET links". o There are a lot of places, where the IP forwarding = engine and the routing protocol process interact - and, in surprising ways. First, there is the whole "react to failure to deliver = an IP datagram due to not having an entry in the routing table, and by way of flooding = control traffic", which is a formidable vector for making every router in the network = participate in a DDOS attack. Second, from section 5.1: =09 The route table entry is a conceptual data structure. Implementations may use any internal representation so = long as it provides access to the information specified below. The route's state determines the operations that can be = performed on the route table entry. During use, an Active route is = maintained continuously by AODVv2 and is considered to remain = active as long as it is used at least once during every ACTIVE_INTERVAL. = When a route is no longer Active, it becomes an Idle route. After an = idle route remains Idle for MAX_IDLETIME, it becomes an Expired = route. An So, part of the data structures, maintained by this = protocol, are the "route table entry", whose state depends on if a route is "used at least once during ..." -- i.e., = the routing process must be notified every time a data packet=20 is being forwarded? I do not know for sure, but I am not = sure that that's even possible to do on commodity=20 operating systems - but, it does appear to be rather = inefficient, increasing per-packet processing overhead for a router? Section 8.1: Before using a route to forward a = packet, an AODVv2 router MUST check the status of the route as follows. Does this imply that the operating system needs to also = be modified to also consult with data-structures,=20 maintained internally by this protocol? The point here is not (necessarily) that it is bad to do = so - but, it would be required that all such assumptions and requirements be called out in the applicability = statement: "This protocol requires that the operating system permits you to do XXX, YYY, ZZZ".=20 o Section 5.4: In order to reduce multicast overhead, retransmitting multicast packets in MANETs SHOULD be done = according to methods specified in [RFC6621] What happens if that "SHOULD" is not done? Does it break = interoperability? Also, RFC6621 is not std.track, so this is a downref that requires special = handling. I note that SHOULD is a fairly strong normative statement, but the RFC6621 is cited as an = informational reference. This does not appear appropriate. And finally, RFC6621 specifies a number of different = algorithms and modes of operation, some of which require additional signalling. For interoperable = implementations to result, this is insufficient. o I have a general concern about how this protocol imposes = constraints on RFC5444 usage, which precludes co-existence with other RFC5444 = protocols running on the same=20 device.=20 Let me give an example hereof, from Section 5.4: When multiple messages are aggregated = into a single packet according to RFC 5444 formatting, and the aggregation of messages = is also authenticated (e.g., with IPsec), and the IP destination = is multiple hops away, it becomes infeasible to delete individual = messages. In such cases, instead of deleting individual messages, = they are maintained in the aggregation of messages, but simply = ignored for further processing. In such cases where individual = messages cannot be deleted, in this document "disregarded" means = "ignored". Otherwise, any such "disregarded" AODVv2 messages SHOULD = be deleted from the aggregated messages in the RFC 5444 packet. An RFC5444 packet is *never* to be sent more than one = hop. Never forwarded. Never. A router=20 receives an RFC5444 packet, decapsulates it, process = each message (if appropriate), the owner process of each message identifies which messages are to be = forwarded (if appropriate), hands those off to the appropriate "message multiplexing engine" which packs = those messages up in a new RFC5444 packet,=20 and transmits that new RFC5444 packet. Also, in RFC5444 messages, addresses are contained in = address blocks. There is no semantics associated with an address being in one address block, = or in another (in fact, (re-)organising addresses into address blocks is one of the tricks to use to = obtain more compact messages). Likewise, there is no semantics associated with an address being first, = last, or in any other position in an address block: the ordering of addresses in an address block carries no = semantics. Therefore, writing something like this: RteMsg.Address[i] denotes the [i]th address in = an RFC 5444 AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes = the associated prefix length for RteMsg.Address[i], and = RteMsg.{field} denotes the corresponding value in the named AddrTLV block = associated with RteMsg.Address[i]. makes no sense whatsoever (aside from the fact that I do = not understand the notation RteMsg.{field} -=20 that would indicate a "field" in a message, not in an = attribute associated with an address).=20 Let me give one more example, from section 9: If a message with an unknown type is received, the message is disregarded. An implementation of this specification will (according = to RFC5444) "own", and therefore get=20 messages that this protocol has gotten assigned by IANA, = say, RREQ/RREP/RERR/RREP_ACK.=20 Messages of any other Message Types will not (again, = according to RFC5444) be delivered to an implementation of this protocol. Therefore, this protocol has no mandate, room, nor = permission to specify discarding any message=20 types other than those than it "owns". o Section 10, this is incorrect, at least as described, or = at best *very* incomplete. What happens when router "inside the MANET" but just = adjacent to the IAR issues a RREQ to a=20 destination inside the MANET? The IAR (presumably = configured to answer to 0::/0) would reply=20 with an RREP. At the very least, the IAR MUST NOT reply to any RREQs, = received on interfaces towards the MANET and for addresses belonging to a prefix covering the = MANET. This is not sufficient, of course, but it is a step towards rendering this correct. o The whole of section 13 must be removed, with the = exception of section 13.6 which is already covered by RFC5444. All the other optional mechanisms are either = underspecified, with known problems in common deployment topologies, or both. Further, they = are clearly indicated as "not needed" so why are they included? o Section 14.2 "Protocol Constants" contains a = semantically null sentence AODVv2 protocol constants typically do not = require changes A constant is constant, therefore it doesn't change. = Even for very loose definitions of constant. With that being said, the interesting part here is = actually not that bit...but rather, what happens *if* these are not set to the values that are indicated? = Or, if different implementations use different values for these? The same holds for 14.2, = btw: is a network able to operate with different routers setting different values? Will it = break? Degrade gracefully? Just work?=20 =09 o Security Considerations First, there is the whole "react to failure to deliver = an IP datagram due to not having an entry in the routing table, and by way of flooding = control traffic", which is a formidable vector for making every router in the network = participate in a DDOS attack. Second: This section does not mandate any specific = security measures. Instead, this section describes various security = considerations and potential avenues to secure AODVv2 routing. If recent dealings with the SEC-ADs are to be believed, = then this is not going to pass muster. At least, a "Mandatory to Implement" security mechanism is going = to be required. Third, Quoting Chris Dearlove: "I'm just going to note that were the security = considerations section in this draft regarded=20 as adequate by the security ADs, then they = would be applying very different standards to=20 those they have applied to OLSRv2. (I think that's easy to see as a factual = statement by consulting the record of what they have=20 required, and then noting that several of = these things are not present in this draft. Note that=20 in the case of OLSRv2 that has resulted in the = production of additional documents. This are not=20 just trivial additions either.)" =09 Fourth: The most important security mechanisms = for AODVv2 routing are integrity/authentication and confidentiality. In situations where routing information or router = identity are suspect, integrity and authentication techniques SHOULD = be applied to AODVv2 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 this protocol? I think that this issue of = mutable messages deserves being called out explicitly in this=20 section, especially if there are known or = recommended ways of handling this (as is the case, for example,=20 in the security considerations section of = RFC5444 regarding the mutable header fields for=20 hop-count/hop-limit of messages As I indicated in the beginning: the protocol specification is ripe with = things that are underspecified, vaguely specified, and options whose = interactions are not well-defined.=20 The above are examples of what is wrong - but not a complete list.=20 This document is *far* from being publishable in its current shape, and = a considerable effort is required to make it publishable - or, even, to = make it into a shape where we can start evaluating if the actual = protocol is a viable candidate for standardisation. It has been four = years now, that I have requested that this effort be expanded on the = document, and on its predecessor, to no avail. Thomas --Apple-Mail=_342D79F1-7639-4791-8A65-09CDF80ABDD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear All,

I have been requested = to - one last time - iterate my comments to the reactive protocol, = currently being discussed by the working = group. 

Somebody *very* persuasive twisted = my arm and convinced me to do so - but I do not write "one last time" = lightly: this is the one last shot.

First, I = would like to direct your attention to this posting from me, which is = from 2010, and which was a review of a predecessor to the current = document. 

=

All my comments, and issues raised, in that review = (and in other reviews since then) still apply to the current document - = now 4 years later. 
I have reminded the WG about this = review several times, as late as in November = 2013.

I shall, in the below, reiterate the key = points that I have made in review quoted above, as well as (as = appropriate) add new issues or update the issues that I have previously = raised. I strongly encourage the WG to look at the details in the review = from 2010. 

Unfortunately, given that the = protocol is vastly underspecified and ridden with options (that also are = underspecified), this list probably is not exhaustive, but it was what I = could extract from the specification as = written:


o I am = confused by the use of square brackets around stuff: usually, [FOO] = refers to
a reference in the References section, but this = is not systematically the case in this
= document (both in the prose and in the notation (cf. Table = 1).

o I 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).

o While we = are on the terminology, "packet" appears to be used both to = describe
(i) a RFC5444 packet, (ii) a protocol data unit = for this protocol, and (iii) an IP 
= datagram. 

o There 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. Some of these = terms, but
not all, are = define.

o While we are on that, I notice = that "active source" is used; I am not sure what 
= that is vs a "source" and vs a PktSource. A source is someone who = generates
data traffic, I would suspect ... so an active = source is....what?  Or, is a source
= someone who can, but doesn't, generate data traffic? - if so, = what is the significance
of that wrt. routing = protocol operation? And, wrt a /reactive/ routing protocol, = which
= I would assume constructs routes only for active = source-destination pairs?

o 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:
= o Do FOO;
= otherwise:
= o = Do BAR;
4. = Retransmit the RREQ

= The way in which this document is written is very confusing: if I = was to implement the processing
of an incoming RREQ = message, which section should I implement? 7.5 would seem to be = the 
place to start, and it = gives and ordered list of things to do. Except it = says...

		In this section (unless =
qualified by additional description such as
		=
"upstream" or "neighboring") all occurrences of the term =
"router"

		=
refer to the AODVv2 router handling the received RteMsg.

So, off to chase what = "upstream" and "neighboring" mean. Whoops, "upstream" is not defined. = One
= interpretation would be that it would be "the next hop towards a = gateway to..." something. But to what?
= Another interpretation would be "the next hop towards the source = of the RteMsg", but as this is part
= of the route discovery process, I probably do not know what that = would be. Or, is it "the best next-hop
= towards the source of the RteMsg that I know so far?" Or = ...

Section 5.2 = says:

		=
To avoid repeated failure of Route Discovery, an AODVv2 router
		=
(HandlingRtr) handling a RREP message SHOULD attempt to verify
		=
connectivity to the next upstream router towards AODVv2 router
		=
originating an RREQ message.

= So for the case when an RteMsg is an RREP, then I could make a = guess that "upstream" means "next hop 
= towards the source of the corresponding RREQ message". Except = Section 7.5 probably also applies to
= RREQs. So off chasing if there is a rule covering that, also, and = guessing what that rule might mean too.

= I've only just started to determine if I am to be processing a = given RteMsg, and I am already at a loss for
= how to proceed, and have had to guess (hoping, of course, to both = guess RIGHT and guess as other
implementers, with whom I = would hope to be interoperable, would = guess).

This is but one example - = but, it applies for all such processes and procedures. The document = is 
vague and underspecified = through and through, and not a solid basis for generating = independent
and interoperable = implementations of this protocol.

		Another =
case of underspecification (and I am not pointing them all out, these =
are just examples 
		of some of the most =
flagrant cases): what does "relevant" mean in the =
below? 

		=
   Whenever an AODVv2 router (HandlingRtr)
		   handles an incoming =
RteMsg (i.e., RREQ or RREP), for every relevant
		   address =
(RteMsg.Address) in the RteMsg =
...

= How is an implementer supposed to determine with which addresses = (if any) processing is to be 
= undertaken?

And one = more:

= Suppose Route[RteMsg.Address] = uses the same metric type as the
 		   incoming routing =
information, and the route entry contains
		=
   Route.SeqNum, Route.Metric, and Route.Broken.  Suppose the =
incoming ...

This is a protocol = specification, "supposing" is not supposed to happen - unambiguous = instructions that
does not require the = implementer to undertake guesswork is = required.

This *specification* is = ripe with such instances of ambiguities and - as I have indicated in = many, many, many
previous reviews, = requires a very through rework and complete rewrite. Then, and only = then, can we
start understanding if = the *protocol* itself has = problems.


o Related = to the above point, an awful lot of the document is optional, as = exemplified by the below:

		To avoid repeated failure of Route Discovery, an AODVv2 =
router
		(HandlingRtr) handling a =
RREP message SHOULD attempt to verify
		connectivity to the next =
upstream router towards AODVv2 router
		originating an RREQ =
message. This MAY be done by including =
the
		=
Acknowledgement Request (AckReq) message TLV (see Section 15.2) in
		=
the RREP.  Any unicast packet will satisfy the Acknowledgement
		=
Request, for example an ICMP REPLY message.  If the verification =
is
		=
not received within UNICAST_MESSAGE_SENT_TIMEOUT, HandlingRtr =
SHOULD
		=
put the upstream neighbor in the blacklist. =

So I have a = (2119-languague) "SHOULD" telling me to "attempt to verify = connectivity". Then a (again,
2119-language) "MAY" = suggesting to accomplish that by sending an = AckReq. 

It's a MAY - therefore, I = know (as it's 2119-language) that I do not have to do that, send that = message. 
But I still SHOULD = "attempt to verify connectivity", so how do I do = that?

It's not clear what it = means that any "unicast packet will satisfy the Acknowledgement = Request"
(which I decided to not = send, as that was a MAY), nor is it clear how the routing process will = get access
to any such unicast = packet (assuming, that is, that said unicast packet isn't destined for = that process). 

= Also, I am apparently supposed to receive a "verification" before = some timeout. Search as I may, I have
= not found anything indicating where that "verification" is = generated, I see no messages defined to this
= effect, nor any processing allowing me to infer = it.

Again, this is an example = of underspecification, that leaves each implementation to "guess = and
interpret" how to proceed - rather than provide = an unambiguous process to follow to ensure
= interoperability.

= And this is only ONE from among MANY examples of such in this = specification. Here's another from section = 8.2:

		=
   AODVv2 routers SHOULD monitor connectivity to adjacent routers =
along
		=
   active routes.  This monitoring can be accomplished by one or =
several
		=
   mechanisms, including:
	
		=
   o  Neighborhood discovery [RFC6130]
		=
   o  Route timeout
		=
   o  Lower layer trigger that a link is broken
		=
   o  TCP timeouts
		=
   o  Promiscuous listening
		=
   o  Other monitoring mechanisms or heuristics

		=
   If a next-hop AODVv2 router has become unreachable, RERR_Gen =
follows
		=
   the procedures specified in Section =
8.3.2.


= So, I will implement this protocol using RFC6130, since I happen = to have an implementation of RFC6130 around. 
= My next-door-neighbor, Francois, also implements this protocol - = but he doesn't have an RFC6130 implementation
= around, and therefore uses "route timeout". As Francois and I = both are lazy, of course, we implement only
= one mechanism each (this is allowed, according to the = text).

As Francois' = implementation doesn't generate RFC6130 HELLOs, for all intents and = purposes he doesn't
exist to my = implementation, which will establish that no connectivity to him = exists.

We've both followed the = specification to the letter, implemented all the SHOULD and MUST - and = yet, we can't
= interoperate.

I = am *NOT* walking through the entire specification and pointing out every = single such situation, and how each
= ambiguity and underspecification can lead to non-interoperable = implementations that otherwise can claim to be
= implementing this specification: there simply are too = many. 

I have called upon the = authors of this specification, for four years now, to walk through the = document and 
work through these to = clarify and render the specification complete and = unambiguous. 

o EVEN WORSE: I searched through = the document for AckReq and Acknowledgement Request, and = I
= actually do not see any instructions telling me how to implement = the code for processing this. So, 
= this specification allows (MAY) me to send an AckReq - but = doesn't tell me how to process it or
= how to act when receiving it.
=
Again, this is an example = of underspecification, that leaves each implementation to "guess = and
= interpret" how to proceed - rather than provide an unambiguous = process to follow to ensure
= interoperability.

= And this is only ONE from among MANY examples of such in this = specification.


o It seems = that the protocol does not support routers with multiple interfaces. = There is this
paragraph in the = applicability statement, which indicates that it is an insurmountable = problem
for the authors to = address:

		=
Multi-homing is difficult unless the sequence number is expanded =
to
		include the AODVv2 =
router's IP address as well as SeqNum.  Otherwise,
		comparing sequence =
numbers would not work to evaluate freshness.
		Even when the IP address =
is included, there isn't a good way to
		compare sequence numbers =
from different IP addresses, but at least a
		handling node can =
determine whether the two given sequence numbers
		are comparable.  If the =
route table can store multiple routes for the
		same destination, then =
multi-homing can work with sequence numbers

		augmented by IP =
addresses.

Worse, though, after = reading this paragraph in the applicability statement, I actually still = do not understand
if this protocol can - = or, can not - be used on routers with multiple = interfaces.

The applicability = statement, also, reads:

= AODVv2 supports routers = with
		=
multiple interfaces, as long as each interface has its own =
(unicast
		=
routeable) IP address; the set of all network interfaces =
supporting
		=
AODVv2 is administratively configured in a list (namely,
		=
AODVv2_INTERFACES).

= which seems to be at odds with the previously quoted paragraph. = So, I still do not know where the protocol
= applies.

This is not unrelated to = the next issue....

o In a great many places, it is = stated "IP address of the (node, Adjacent Node, Adjacent Router) 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 or assumed here? The relationship = node/interface/address is, at best, unclear.
=
It seems to me that this = specification is written with the assumption that each router has = *exactly* one
interface participating = in the routing protocol, with *exactly* one IP address - and that that = router *never*
use anything but that IP = Address for anything.

= If that is correct, then it should be written clearly in the = applicability statement that multiple interfaces
= and multiple addresses are *NOT* supported, and that this = protocol MUST NOT be used in deployments
= where any router can have more than one interface or more than = one IP Address.

If that's not true, then = a major rework of the protocol and the specification is = required.

This is also not = unrelated to the next issue....

o I 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 word "Router Client" is also used = (albeit inconsistently capitalized)
= as is "client".

= An application running on a host has very, very specific = expectations as to how the underlying
= IP link behaves. Applications "Expect an IP Link that looks like = an Ethernet". I believe that it was
= Dave Thaler that once said something like "don't expect Microsoft = to rewrite their IP stack..." 
= Applications expect what they expect. Even, a protocol such as = NDP, which an IPv6-host
uses to (among other = things) configure its interfaces has this expectation. Therefore, = unless
the goal is to explicitly not support general = applications and general IP stacks, an appropriate 
= link model must be presented to = hosts.

Yes, links between MANET = routers are not "looking like an Ethernet". That's quite = alright, 
as long as the *only* = application seeing these "MANET links" is the routing = application. 
Expose the weirdness of = "a MANET link" to an off-the-shelf app or protocol (such as = NDP, 
mDNS, ...), and = unpredictable behaviour ensures.

= The way that other MANET routing protocols have taken is, to = provide an IP hop isolation
of the hosts (which run = "off the shelf applications") from the "MANET links": in other = words,
= a "regular IP link" ties the "host" to the = "router" and the "router" then has one or more
= interfaces towards the "MANET = links".

o There are a lot of places, where = the IP forwarding engine and the routing protocol = process
interact - and, in = surprising ways.

First, there is the whole = "react to failure to deliver an IP datagram due to not = having
= an entry in the routing table, and by way of = flooding control traffic", which is a formidable
= vector for making every router in the network participate in = a DDOS attack.

Second, from section = 5.1:
		The route table entry is a conceptual data =
structure.
		=
Implementations may use any internal representation so long as it
		=
provides access to the information specified =
below.

= <snip>

		The route's state =
determines the operations that can be performed on
		=
the route table entry.  During use, an Active route is maintained
		=
continuously by AODVv2 and is considered to remain active as long =
as
		=
it is used at least once during every ACTIVE_INTERVAL.  When a =
route
		=
is no longer Active, it becomes an Idle route.  After an idle =
route
		=
remains Idle for MAX_IDLETIME, it becomes an Expired route.  =
An


So, part of the data = structures, maintained by this protocol, are the "route table entry", = whose state depends on
if a route is "used at = least once during ..." -- i.e., the routing process must be notified = every time a data packet 
is being forwarded? I do = not know for sure, but I am not sure that that's even possible to do on = commodity 
= operating systems - but, it does appear to be rather inefficient, = increasing per-packet processing overhead
for a = router?

Section = 8.1:
=   Before using a route to forward a packet, an AODVv2 = router MUST check
   =
		=
the status of the route as follows.

Does this imply that the = operating system needs to also be modified to also consult with = data-structures, 
maintained internally by = this protocol?


The point here is not = (necessarily) that it is bad to do so - but, it would be required that = all such assumptions
and requirements be = called out in the applicability statement: "This protocol requires that = the operating system
permits you to do XXX, = YYY, ZZZ". 

o Section 5.4:
= In order to reduce multicast = overhead,
   =
	  =
 retransmitting multicast packets in MANETs SHOULD be done according
	  =
 to methods specified in [RFC6621]

= What happens if that "SHOULD" is not done? Does it break = interoperability? Also, RFC6621 is not
= std.track, so this is a downref that requires special handling. I = note that SHOULD is a fairly strong
= normative statement, but the RFC6621 is cited as an informational = reference. This does not appear
= appropriate.

= And finally, RFC6621 specifies a number of different algorithms = and modes of operation, some of which
= require additional signalling. For interoperable implementations = to result, this is insufficient.


	o	I have a general concern about how this protocol imposes =
constraints on RFC5444 usage,
		which precludes =
co-existence with other RFC5444 protocols running on the =
same 
		device. 

		Let me give an example =
hereof, from Section 5.4:

		 		=
When multiple messages are aggregated into a single packet =
according
		=
to RFC 5444 =
formatting, and the aggregation of messages is also
		=
authenticated (e.g., with IPsec), and the IP destination is =
multiple
		=
hops away, it becomes infeasible to delete individual messages.  =
In
		=
such cases, instead of deleting individual messages, they are
		=
maintained in the aggregation of messages, but simply ignored for
		=
further processing.  In such cases where individual messages =
cannot
		=
be deleted, in this document "disregarded" means "ignored".
		=
Otherwise, any such "disregarded" AODVv2 messages SHOULD be =
deleted
		=
from the aggregated messages in the RFC 5444 =
packet.

		=
An =
RFC5444 packet is *never* to be sent more than one hop. Never forwarded. =
Never. A router 
		receives an RFC5444 =
packet, decapsulates it, process each message (if appropriate), the =
owner process
		of each message identifies which messages are to be forwarded (if appropriate), hands those off to =
the
		appropriate "message =
multiplexing engine" which packs those messages up in a new RFC5444 =
packet, 
		and =
transmits that new RFC5444 =
packet.

		Also, in RFC5444 =
messages, addresses are contained in address blocks. There is no =
semantics
		associated with an =
address being in one address block, or in another (in fact, =
(re-)organising addresses
		into address blocks is =
one of the tricks to use to obtain more compact messages). Likewise, =
there is
		no semantics associated =
with an address being first, last, or in any other position in an =
address block:
		the ordering of addresses =
in an address block carries no semantics.

		Therefore, writing =
something like this:

			=
RteMsg.Address[i] denotes =
the [i]th address in an RFC
	  =
 5444 AddrBlk of the RteMsg. =
  RteMsg.PrefixLength[i] denotes =
the
	   =
associated prefix length for RteMsg.Address[i], and RteMsg.{field}
	  =
 denotes the corresponding value in the named AddrTLV block associated
	  =
 with RteMsg.Address[i].

		makes no sense whatsoever (aside from the fact =
that I do not understand the notation RteMsg.{field} =
- 
		=
that would indicate a "field" in a message, not in an attribute =
associated with an address). 

		Let me give one more example, from section =
9:

	   If a message with an unknown =
type is received, the message is
	  =
 disregarded.


		An implementation of this specification will (according =
to RFC5444) "own", and therefore get 
		=
messages that this protocol has gotten assigned by IANA, say, =
RREQ/RREP/RERR/RREP_ACK. 
		=
Messages of any other Message Types will not (again, according to =
RFC5444) be delivered to
		an implementation of this =
protocol.

		Therefore, this protocol =
has no mandate, room, nor permission to specify discarding any =
message 
		types other than those =
than it "owns".

	o	Section 10, this is incorrect, at =
least as described, or at best *very* incomplete.

		What happens =
when router "inside the MANET" but just adjacent to the IAR issues =
a RREQ to a 
		destination inside the =
MANET? The IAR (presumably configured to answer to 0::/0) would =
reply 
		with an =
RREP.

		At the very least, the =
IAR MUST NOT reply to any RREQs, received on interfaces towards the =
MANET
		and for addresses =
belonging to a prefix covering the MANET. This is not sufficient, of =
course, but it
		is a step towards =
rendering this correct.

	o	The whole =
of section 13 must be removed, with the exception of section 13.6 which =
is already covered
		by RFC5444. All the other =
optional mechanisms are either underspecified, with known =
problems
		in common deployment =
topologies, or both. Further, they are clearly indicated as "not needed" =
so
		=
why are they included?

	o	Section =
14.2 "Protocol Constants" contains a semantically null =
sentence

			AODVv2 protocol constants typically do not =
require changes

	=
	=
A =
constant is constant, therefore it doesn't change. Even for very loose =
definitions of constant.
		With that being said, the =
interesting part here is actually not that bit...but rather, what =
happens
		*if* these are not set to =
the values that are indicated? Or, if different implementations =
use
		=
different values for these? The same holds for 14.2, btw: is a =
network able to operate with
		different routers setting =
different values? Will it break? Degrade gracefully? Just =
work? 

	
	o	Security Considerations

		=
First, there is the whole "react to failure to deliver an IP =
datagram due to not having
		an entry in the routing table, and by way of =
flooding control traffic", which is a formidable
		=
vector for making every router in the network participate in =
a DDOS attack.

	=
Second:

=  This section does not = mandate any specific security measures.
	  =
 Instead, this section describes various security considerations and
	   potential avenues to secure =
AODVv2 routing.

If recent dealings with = the SEC-ADs are to be believed, then this is not going to pass muster. = At least,
a "Mandatory to = Implement" security mechanism is going to be = required.

Third, Quoting Chris = Dearlove:
"I'm just going = to note that were the security considerations section in this draft = regarded 
 as adequate = by the security ADs, then they would be applying very different = standards to 
 those they = have applied to OLSRv2.

 (I think = that's easy to see as a factual statement by consulting the record of = what they have 
=   required, and then noting that several of these = things are not present in this draft. Note that 
=   in the case of OLSRv2 that has resulted in the = production of additional documents. This are not 
=   just trivial additions = either.)"
= Fourth:
= The most important security = mechanisms for AODVv2 routing are
		integrity/authentication =
and confidentiality.

		=
In situations where routing information or router identity are
		=
suspect, integrity and authentication techniques SHOULD be =
applied to
		=
AODVv2 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
= this protocol?  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

As I = indicated in the beginning: the protocol specification is ripe with = things that are underspecified, vaguely specified, and options whose = interactions are not well-defined. 

The = above are examples of what is wrong - but not a complete = list. 

This document is *far* from being = publishable in its current shape, and a considerable effort is required = to make it publishable - or, even, to make it into a shape where we can = start evaluating if the actual protocol is a viable candidate for = standardisation. It has been four years now, that I have requested that = this effort be expanded on the document, and on its predecessor, to no = avail.

Thomas


=

= --Apple-Mail=_342D79F1-7639-4791-8A65-09CDF80ABDD1-- From nobody Thu Mar 6 11:35:17 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204351A0068 for ; Thu, 6 Mar 2014 11:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH30XXn_rVK3 for ; Thu, 6 Mar 2014 11:35:08 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 412501A0114 for ; Thu, 6 Mar 2014 11:35:08 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id c41so3160744yho.41 for ; Thu, 06 Mar 2014 11:35:04 -0800 (PST) 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=pWDCH5mPAA2k+2qh3wcmuffZm6HRD79CHtAmW7u7MHM=; b=jzTDSuTenGPzyqJFNDzzqVxCGpjvI3LfWsM/ByvxouEtg9KI6ZGLIxbDsA8FwFfBVq aQzv7BP89rouIIVaFDy5oVKbdJNCEDEQ1dgjNdlgb9FtRc7U2YsewQ7MF06M1BjHCIQt qFaY0YPxpVgrAeUgT7UVLbT5xSbazVj9rhez7Xj47PujOklwBvIx3eSHQtqw8ECcBjro fsx1vxm6VUeLZhkM+PuHT0+Om8+Jwgtg4C8eR5R3k1/m3gbhpQrPNnDvj/uKV/53/whA 0H3OrlC1x+2El1TEkqXr/7LBFiQVqwHEc5J9zIi2pDD3ox1Dlybjrma2zIqy1vKHNkOQ VPVw== MIME-Version: 1.0 X-Received: by 10.236.194.40 with SMTP id l28mr16839365yhn.63.1394134504007; Thu, 06 Mar 2014 11:35:04 -0800 (PST) Received: by 10.170.202.7 with HTTP; Thu, 6 Mar 2014 11:35:03 -0800 (PST) In-Reply-To: <5318A1BA.1020408@computer.org> References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> Date: Thu, 6 Mar 2014 20:35:03 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=bcaec52c68d1e1802f04f3f53b1b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0Vt8Wod5oLfmpiEZoi2bsj-k6DI Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:35:11 -0000 --bcaec52c68d1e1802f04f3f53b1b Content-Type: text/plain; charset=ISO-8859-1 Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. AB On Thursday, March 6, 2014, Charles E. Perkins wrote: > > Hello Abdussalam, > > Actually, all of the issues were resolved. Then, apparently, the > issues page crashed, and some recent updates to the issues were > lost. However, they were sent to the mailing list, and so are > recoverable, with a nontrivial amount of work amounting to > an archaeological expedition through the mailing list archives. > > I wanted to have time to do this, but so far have not. If anyone > wants to volunteer to recover the issue-tracker updates from the > mailing list, that would be terrific. > > Regards, > Charlie P. > > > On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: > > Hi Charles, > > I just had before a comment on the open tickets, were they all > closed, because I think may be open. Seems most MANET WG don't care about > tickets but I like to track and I remember that the AD did mention it's > importance. > > For me I will review new draft and comment, but if the authors have no > more pending issues to update, please confirm (sorry that I was not able to > remember if there are confirmation from authors that draft is ready or not, > also need their confirm of final points of open issues for next draft if > not resolved). > > Best Regards > > AB > > On Wednesday, March 5, 2014, Charles E. Perkins wrote: > >> Hello folks, >> >> Part of the job of finishing the AODVv2 specification will be to comb >> the mailing list for issues that are still not resolved. If there are >> any specific issues that have not been gotten proper attention, I hope >> to find them -- but if anyone would like to help by bringing them >> up here on the mailing list, that will be appreciated. >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > -- > Regards, > Charlie P. > > --bcaec52c68d1e1802f04f3f53b1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok so I understand from your message below=A0that authors confirm that = the draft is ready complete=A0for WG to review and comment their open=A0iss= ues.=A0

AB

On Thursday, March 6, 2014, Cha= rles E. Perkins wrote:
=20 =20 =20

Hello Abdussalam,

Actually, all of the issues were resolved.=A0 Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.=A0 However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.=A0 If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open=A0tickets,=A0were they all closed,=A0because I think may be open. Seems most=A0MANET WG don't care=A0about tickets but I like to track=A0and I remember= that the AD did mention it's importance.=A0

For me I will review new draft and comment, but if the authors have no more pending=A0issues to update,=A0please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need=A0their confirm of=A0final points of open issues for next draft if not resolved).= =A0

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved. =A0If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

--=20
Regards,
Charlie P.
--bcaec52c68d1e1802f04f3f53b1b-- From nobody Thu Mar 6 12:34:00 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98CA1A0111 for ; Thu, 6 Mar 2014 12:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyIv1YnG8iZE for ; Thu, 6 Mar 2014 12:33:57 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7471A00B4 for ; Thu, 6 Mar 2014 12:33:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D7BB0700AB4; Thu, 6 Mar 2014 12:33:53 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6049F1C0776; Thu, 6 Mar 2014 12:33:53 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-D8B14388-70EC-4A23-9026-98512B613A91 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Thu, 6 Mar 2014 21:33:54 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qK1rqfNSXOIJyFfdv9APLQSy87c Cc: manet-ads@tools.ietf.org, Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 20:33:59 -0000 --Apple-Mail-D8B14388-70EC-4A23-9026-98512B613A91 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 6 mars 2014, at 20:35, Abdussalam Baryun w= rote: >=20 >=20 > Ok so I understand from your message below that authors confirm that the d= raft is ready complete for WG to review and comment their open issues.=20 >=20 Having actually read the I-D, that is not the conclusion that I reach, I am very surprised if the authors believe that to be the state of the docum= ent. Thomas > AB >=20 >> On Thursday, March 6, 2014, Charles E. Perkins wrote: >>=20 >> Hello Abdussalam, >>=20 >> Actually, all of the issues were resolved. Then, apparently, the >> issues page crashed, and some recent updates to the issues were >> lost. However, they were sent to the mailing list, and so are >> recoverable, with a nontrivial amount of work amounting to >> an archaeological expedition through the mailing list archives. >>=20 >> I wanted to have time to do this, but so far have not. If anyone >> wants to volunteer to recover the issue-tracker updates from the >> mailing list, that would be terrific. >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >>> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>> Hi Charles, >>>=20 >>> I just had before a comment on the open tickets, were they all closed, b= ecause I think may be open. Seems most MANET WG don't care about tickets but= I like to track and I remember that the AD did mention it's importance.=20 >>>=20 >>> For me I will review new draft and comment, but if the authors have no m= ore pending issues to update, please confirm (sorry that I was not able to r= emember if there are confirmation from authors that draft is ready or not, a= lso need their confirm of final points of open issues for next draft if not r= esolved).=20 >>>=20 >>> Best Regards >>>=20 >>> AB >>>=20 >>>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>>> Hello folks, >>>>=20 >>>> Part of the job of finishing the AODVv2 specification will be to comb >>>> the mailing list for issues that are still not resolved. If there are >>>> any specific issues that have not been gotten proper attention, I hope >>>> to find them -- but if anyone would like to help by bringing them >>>> up here on the mailing list, that will be appreciated. >>>>=20 >>>> --=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> --=20 >> Regards, >> Charlie P. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-D8B14388-70EC-4A23-9026-98512B613A91 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 6 mars 2014, at 20:35, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:


Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 


Having actually read the I-D, that is not the conclusion that I reach,

I am very surprised if the authors believe that to be the state of the document.

Thomas

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved). 

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-D8B14388-70EC-4A23-9026-98512B613A91-- From nobody Thu Mar 6 13:16:23 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141C71A00A3 for ; Thu, 6 Mar 2014 13:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtQcxn_WOXee for ; Thu, 6 Mar 2014 13:16:18 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5771A0072 for ; Thu, 6 Mar 2014 13:16:17 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 200so8225162ykr.3 for ; Thu, 06 Mar 2014 13:16:14 -0800 (PST) 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=YGqwDfD+baNO3RHWjnNf2voRU4YqRrbHsYN9FEvgO5o=; b=bhIVaYdXtVPwwGmb3YY20Tr9h/wIyQ3qDsvSt5GHEOs9q9s8smL+Wf5PjYC3sdq5Uf mGw0SisCcRn8s0A7n0PNMJEFWgg1YWlW3+I3Jt910FOXBwp0LOavY8mlkI83vtLXBdfD c/yBodYWl0FBzNP5nVq8rftoNsHBjXgc0f5t8P2G5cvsr/o/YOK9C+w3kMs1nNIWKVV4 2IUOroX8Ml1swv/Ro4wvWDeirztYKmYNNpZSdceyoolrFHX38p48dVq2J0LMjO2rENee D82wEVBOn2J6n9PePtaY9nVGoaMLsQ9H5fOlaWfCocyZPq3nvAamxHHpiRcko0IlauDJ EEFw== MIME-Version: 1.0 X-Received: by 10.236.200.35 with SMTP id y23mr17476255yhn.38.1394140573968; Thu, 06 Mar 2014 13:16:13 -0800 (PST) Received: by 10.170.202.7 with HTTP; Thu, 6 Mar 2014 13:16:13 -0800 (PST) In-Reply-To: References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> Date: Thu, 6 Mar 2014 22:16:13 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=bcaec50b4bdeadadb004f3f6a59b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JQRu76uID-KB1P5MqqvyEmID728 Cc: "manet-ads@tools.ietf.org" , Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 21:16:20 -0000 --bcaec50b4bdeadadb004f3f6a59b Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas I seen your comments in the new thread reported. But does this message mean you may have more points then that you posted today. Regards AB On Thursday, March 6, 2014, Thomas Heide Clausen wrote: > > On 6 mars 2014, at 20:35, Abdussalam Baryun > > wrote: > > > Ok so I understand from your message below that authors confirm that the > draft is ready complete for WG to review and comment their open issues. > > > Having actually read the I-D, that is not the conclusion that I reach, > > I am very surprised if the authors believe that to be the state of the > document. > > Thomas > > AB > > On Thursday, March 6, 2014, Charles E. Perkins wrote: > >> >> Hello Abdussalam, >> >> Actually, all of the issues were resolved. Then, apparently, the >> issues page crashed, and some recent updates to the issues were >> lost. However, they were sent to the mailing list, and so are >> recoverable, with a nontrivial amount of work amounting to >> an archaeological expedition through the mailing list archives. >> >> I wanted to have time to do this, but so far have not. If anyone >> wants to volunteer to recover the issue-tracker updates from the >> mailing list, that would be terrific. >> >> Regards, >> Charlie P. >> >> >> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >> >> Hi Charles, >> >> I just had before a comment on the open tickets, were they all >> closed, because I think may be open. Seems most MANET WG don't care about >> tickets but I like to track and I remember that the AD did mention it's >> importance. >> >> For me I will review new draft and comment, but if the authors have no >> more pending issues to update, please confirm (sorry that I was not able to >> remember if there are confirmation from authors that draft is ready or not, >> also need their confirm of final points of open issues for next draft if >> not resolved). >> >> Best Regards >> >> AB >> >> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >> >>> Hello folks, >>> >>> Part of the job of finishing the AODVv2 specification will be to comb >>> the mailing list for issues that are still not resolved. If there are >>> any specific issues that have not been gotten proper attention, I hope >>> to find them -- but if anyone would like to help by bringing them >>> up here on the mailing list, that will be appreciated. >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --bcaec50b4bdeadadb004f3f6a59b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas

I seen your comments in the new thread reporte= d. But does this message mean you may have more points then that you posted= today.=A0

Regards
AB

On Thursday= , March 6, 2014, Thomas Heide Clausen wrote:

On 6 m= ars 2014, at 20:35, Abdussalam Baryun <abd= ussalambaryun@gmail.com> wrote:


Ok so I understand from your m= essage below=A0that authors confirm that the draft is ready complete=A0for = WG to review and comment their open=A0issues.=A0


Having actually read the I-D, that is not the conclusio= n that I reach,

I am very surprised if the authors= believe that to be the state of the document.

Thomas

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:
=20 =20 =20

Hello Abdussalam,

Actually, all of the issues were resolved.=A0 Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.=A0 However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.=A0 If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open=A0tickets,=A0were they all closed,=A0because I think may be open. Seems most=A0MANET WG don't care=A0about tickets but I like to track=A0and I remember= that the AD did mention it's importance.=A0

For me I will review new draft and comment, but if the authors have no more pending=A0issues to update,=A0please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need=A0their confirm of=A0final points of open issues for next draft if not resolved).= =A0

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved. =A0If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

--=20
Regards,
Charlie P.
___________________= ____________________________
manet mailing list
<= span>manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--bcaec50b4bdeadadb004f3f6a59b-- From nobody Thu Mar 6 13:20:25 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8FF1A0134 for ; Thu, 6 Mar 2014 13:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRWmY2NHTAAz for ; Thu, 6 Mar 2014 13:20:14 -0800 (PST) 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 84AF51A012A for ; Thu, 6 Mar 2014 13:20:14 -0800 (PST) Received: from [130.129.155.157] by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WLfi5-0002DO-Iq; Thu, 06 Mar 2014 16:20:10 -0500 Message-ID: <5318E688.5060704@computer.org> Date: Thu, 06 Mar 2014 13:20:08 -0800 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <53170334.2020908@computer.org><5318A1BA.1020408@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060405070809070302000201" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86d18953dc0b4d4804ca7f3e13f532a3b8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.155.157 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/62MhqgGwzdcre0bJUfvwl4tqvCU Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 21:20:22 -0000 This is a multi-part message in MIME format. --------------060405070809070302000201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Abdussalam, The issues that had earlier been posted on the issue tracker had been resolved. I intend to look for the tools.ietf.org emails to the [manet] mailing list to re-document the resolutions, but first I need to work on the issues that were posted to the mailing list today. I am isolating separate issues from the email and hope to have them on the tracker within the week. Regards, Charlie P. On 3/6/2014 1:16 PM, Abdussalam Baryun wrote: > Hi Thomas > > I seen your comments in the new thread reported. But does this message > mean you may have more points then that you posted today. > > Regards > AB > > On Thursday, March 6, 2014, Thomas Heide Clausen wrote: > > > On 6 mars 2014, at 20:35, Abdussalam Baryun > > wrote: > >> >> Ok so I understand from your message below that authors confirm >> that the draft is ready complete for WG to review and comment >> their open issues. >> > > Having actually read the I-D, that is not the conclusion that I reach, > > I am very surprised if the authors believe that to be the state of > the document. > > Thomas > >> AB >> >> On Thursday, March 6, 2014, Charles E. Perkins wrote: >> >> >> Hello Abdussalam, >> >> Actually, all of the issues were resolved. Then, apparently, the >> issues page crashed, and some recent updates to the issues were >> lost. However, they were sent to the mailing list, and so are >> recoverable, with a nontrivial amount of work amounting to >> an archaeological expedition through the mailing list archives. >> >> I wanted to have time to do this, but so far have not. If anyone >> wants to volunteer to recover the issue-tracker updates from the >> mailing list, that would be terrific. >> >> Regards, >> Charlie P. >> >> >> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>> Hi Charles, >>> >>> I just had before a comment on the open tickets, were they >>> all closed, because I think may be open. Seems most MANET WG >>> don't care about tickets but I like to track and I remember >>> that the AD did mention it's importance. >>> >>> For me I will review new draft and comment, but if the >>> authors have no more pending issues to update, please >>> confirm (sorry that I was not able to remember if there are >>> confirmation from authors that draft is ready or not, also >>> need their confirm of final points of open issues for next >>> draft if not resolved). >>> >>> Best Regards >>> >>> AB >>> >>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>> >>> Hello folks, >>> >>> Part of the job of finishing the AODVv2 specification >>> will be to comb >>> the mailing list for issues that are still not resolved. >>> If there are >>> any specific issues that have not been gotten proper >>> attention, I hope >>> to find them -- but if anyone would like to help by >>> bringing them >>> up here on the mailing list, that will be appreciated. >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. --------------060405070809070302000201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Abdussalam,

The issues that had earlier been posted on the issue tracker
had been resolved.  I intend to look for the tools.ietf.org emails
to the [manet] mailing list to re-document the resolutions, but
first I need to work on the issues that were posted to the
mailing list today.  I am isolating separate issues from the email
and hope to have them on the tracker within the week.

Regards,
Charlie P.

On 3/6/2014 1:16 PM, Abdussalam Baryun wrote:
Hi Thomas

I seen your comments in the new thread reported. But does this message mean you may have more points then that you posted today. 

Regards
AB

On Thursday, March 6, 2014, Thomas Heide Clausen wrote:

On 6 mars 2014, at 20:35, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:


Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 


Having actually read the I-D, that is not the conclusion that I reach,

I am very surprised if the authors believe that to be the state of the document.

Thomas

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved). 

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

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

-- 
Regards,
Charlie P.
--------------060405070809070302000201-- From nobody Thu Mar 6 13:26:43 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBFD1A013E for ; Thu, 6 Mar 2014 13:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZwJGvTAPHHp for ; Thu, 6 Mar 2014 13:26:38 -0800 (PST) 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 91BBC1A00E1 for ; Thu, 6 Mar 2014 13:26:38 -0800 (PST) Received: from [130.129.155.157] by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WLfoI-0007D7-AA; Thu, 06 Mar 2014 16:26:34 -0500 Message-ID: <5318E809.5000103@computer.org> Date: Thu, 06 Mar 2014 13:26:33 -0800 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <53170334.2020908@computer.org><5318A1BA.1020408@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070801050609010307000406" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad869793c4e16dbf4b59e17d563c146c2c11350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.155.157 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9ryzWA7vlP_Mi3Pq9PDvZRG7WvE Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 21:26:41 -0000 This is a multi-part message in MIME format. --------------070801050609010307000406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Abdussalam, Before the draft goes to last call, we need to resolve the open issues that were posted to the mailing list. When I mentioned that the earlier issues on the issue tracker had been resolved, that did not include the other issues that were not posted to the issue tracker. As mentioned in my previous email, I will take care of posting them to the tracker so that the resolution process will be easier to follow. Regards, Charlie P. On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: > > Ok so I understand from your message below that authors confirm that > the draft is ready complete for WG to review and comment their > open issues. > > AB > > On Thursday, March 6, 2014, Charles E. Perkins wrote: > > > Hello Abdussalam, > > Actually, all of the issues were resolved. Then, apparently, the > issues page crashed, and some recent updates to the issues were > lost. However, they were sent to the mailing list, and so are > recoverable, with a nontrivial amount of work amounting to > an archaeological expedition through the mailing list archives. > > I wanted to have time to do this, but so far have not. If anyone > wants to volunteer to recover the issue-tracker updates from the > mailing list, that would be terrific. > > Regards, > Charlie P. > > > On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >> Hi Charles, >> >> I just had before a comment on the open tickets, were they all >> closed, because I think may be open. Seems most MANET WG don't >> care about tickets but I like to track and I remember that the AD >> did mention it's importance. >> >> For me I will review new draft and comment, but if the authors >> have no more pending issues to update, please confirm (sorry that >> I was not able to remember if there are confirmation from authors >> that draft is ready or not, also need their confirm of final >> points of open issues for next draft if not resolved). >> >> Best Regards >> >> AB >> >> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >> >> Hello folks, >> >> Part of the job of finishing the AODVv2 specification will be >> to comb >> the mailing list for issues that are still not resolved. If >> there are >> any specific issues that have not been gotten proper >> attention, I hope >> to find them -- but if anyone would like to help by bringing them >> up here on the mailing list, that will be appreciated. >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > -- > Regards, > Charlie P. > -- Regards, Charlie P. --------------070801050609010307000406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my
previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved). 

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.

-- 
Regards,
Charlie P.
--------------070801050609010307000406-- From nobody Thu Mar 6 13:38:01 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62491A00E1 for ; Thu, 6 Mar 2014 13:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgnji8tFFAXy for ; Thu, 6 Mar 2014 13:37:57 -0800 (PST) Received: from nm6-vm1.access.bullet.mail.gq1.yahoo.com (nm6-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.4]) by ietfa.amsl.com (Postfix) with ESMTP id EC9561A00CA for ; Thu, 6 Mar 2014 13:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1394141872; bh=x2VTXjZbZGq/8FfAOhlVsE6zHL7BxRXkhdMRZ0LHNvg=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type; b=5FfWD15n/WI4gq88tXNHjsFJHnQ0WvzfYnNxwPGF8wnXGESrT0wJTZHjNt5F+/3NoBmDzswljezeXDgr3Tut7U1nlx4KMoD46WeWmYqUBytw/eDmUNY7KC3hfRXZ+R5tpN20Du09ZOkZp1UcOdHg3HOHwG8gOpJp6byM1RfG1ic= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; b=fE16B3j0Lgn7PEn7Ab3kAFFgQSexD1MUyQ4eUoLtzE4lhQYeTXj5kYqVqYVr4pgu0pgp+ain5wCuH8l+Y4uW+FmxeCUpfAINT74UunHsym2QnaTeOdoM5GaRCycp58WnMBmEpyLRJno0aavmc+JJbsKAAszodrffPgpN3eb2aLk=; Received: from [216.39.60.166] by nm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 06 Mar 2014 21:37:52 -0000 Received: from [67.195.22.119] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 06 Mar 2014 21:37:52 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.gq1.yahoo.com with NNFMP; 06 Mar 2014 21:37:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1394141872; bh=x2VTXjZbZGq/8FfAOhlVsE6zHL7BxRXkhdMRZ0LHNvg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type; b=n83SRdvrfE06vl8cKUys2wiJ4cRX8IFmTW5I45CMBkvq1yimBDSrJoNXTlSmQe81ng83ZYoaLb/OMfqs7Nuvk5/Jw42yY34594E/RvCDsFXgZUshtgsIdH1djN2fYQqTlBmuz+Vo6RGcW/NDAykKRIcSiEB8ISRzo7Et8pKG5oY= X-Yahoo-Newman-Id: 718887.52834.bm@smtp114.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WdT4WQkVM1k2MUOV2TtIg3BjMz68eM.bTy5QaXYAqljV4bs eP8jBDqF6i3CrSh068BCKSyaRNThg4wo2PkOx_QTE5dXmaZ9TDLCQBbado02 7Su7_Bp0hIyxpXzPFc0WExjCMoZw.6uo182_2.Fxs8ZqSM002F3CZoD.aDBS RQT_pOqFisdmrtDYbargobpWhurWJZLe.dFk5l1KC7fhl6bEaWw5rPE.BuaV ZZuFN_kdM_xHI3dwTxhwyHPZ6zIs4oF8uQVgFWxjX2iRfacLYsgJooUrEC5R yTYahGrDzkw20cwrT2Rgty5EMYIojiR4viorB6gb2o65Cf7oFsnZz4cyTDvw Zj7ePlRKboBPep6ewRWQcPfwfIM0q4WL1cN33J9_9ZxWInyp_ZMsyeUOXXaq 8QVOAxJKq3YJQrv_.KnsblXfeINSETPc_m45dKqAtNz8KvjeL_J43Kxm5asD 6KY0xp74TfGh4r6pxwayCeftrOLOkwlU2yXDlHxvXlbUzrIBG6j8r_m.C3tl ZLZNhrRGtGk.T77t5DCqqUhOHrqbUjmEseEwL7DQHZ5zAVQ.IJOP10HwWP5P 0u.8C X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@69.111.215.218 with plain [67.195.15.5]) by smtp114.sbc.mail.gq1.yahoo.com with SMTP; 06 Mar 2014 13:37:52 -0800 PST User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 06 Mar 2014 13:37:47 -0800 From: Don Sturek To: "Charles E. Perkins" , Abdussalam Baryun Message-ID: Thread-Topic: [manet] Remaining issues affecting the AODVv2 specification References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> In-Reply-To: <5318E809.5000103@computer.org> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3476957870_1736115" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Vzoir5G0A685xLJXuPalKqMoLik Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 21:38:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3476957870_1736115 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Charlie, It would be worth (going forward) addressing issues as they come up on the reflector rather than having to mine these topics out of the reflector archives months later. Most folks have limited time to spend reviewing drafts. Ignoring comments for several months does not help resolving these issues since in many cases the comment and context is lost after a long period of time. Don From: "Charles E. Perkins" Organization: Blue Skies Date: Thursday, March 6, 2014 1:26 PM To: Abdussalam Baryun Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification Hello Abdussalam, Before the draft goes to last call, we need to resolve the open issues that were posted to the mailing list. When I mentioned that the earlier issues on the issue tracker had been resolved, that did not include the other issues that were not posted to the issue tracker. As mentioned in my previous email, I will take care of posting them to the tracker so that the resolution process will be easier to follow. Regards, Charlie P. On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: > > Ok so I understand from your message below that authors confirm that the > draft is ready complete for WG to review and comment their open issues. > > > > AB > > > On Thursday, March 6, 2014, Charles E. Perkins wrote: > >> >> >> Hello Abdussalam, >> >> Actually, all of the issues were resolved. Then, apparently, the >> issues page crashed, and some recent updates to the issues were >> lost. However, they were sent to the mailing list, and so are >> recoverable, with a nontrivial amount of work amounting to >> an archaeological expedition through the mailing list archives. >> >> I wanted to have time to do this, but so far have not. If anyone >> wants to volunteer to recover the issue-tracker updates from the >> mailing list, that would be terrific. >> >> Regards, >> Charlie P. >> >> >> >> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >> >> >>> Hi Charles, >>> >>> >>> >>> I just had before a comment on the open tickets, were they all closed, >>> because I think may be open. Seems most MANET WG don't care about tickets >>> but I like to track and I remember that the AD did mention it's importance. >>> >>> >>> >>> >>> For me I will review new draft and comment, but if the authors have no more >>> pending issues to update, please confirm (sorry that I was not able to >>> remember if there are confirmation from authors that draft is ready or not, >>> also need their confirm of final points of open issues for next draft if not >>> resolved). >>> >>> >>> >>> Best Regards >>> >>> >>> >>> >>> AB >>> >>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>> >>>> Hello folks, >>>> >>>> Part of the job of finishing the AODVv2 specification will be to comb >>>> the mailing list for issues that are still not resolved. If there are >>>> any specific issues that have not been gotten proper attention, I hope >>>> to find them -- but if anyone would like to help by bringing them >>>> up here on the mailing list, that will be appreciated. >>>> >>>> -- >>>> Regards, >>>> Charlie P. >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> >> >> >> -- >> Regards, >> Charlie P. >> >> > > -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --B_3476957870_1736115 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Charlie,

=
It would be worth (going forward) addressing issues as they come = up on the reflector rather than having to mine these topics out of the refle= ctor archives months later.

Most folks have limited= time to spend reviewing drafts.  Ignoring comments for several months = does not help resolving these issues since in many cases the comment and con= text is lost after a long period of time.

Don
=


From: "Cha= rles E. Perkins" <charliep@compute= r.org>
Organization: Blue S= kies
Date: Thursday, March 6, 2014= 1:26 PM
To: Abdussalam Baryun <= ;abdussalambaryun@gmail.com&= gt;
Cc: Mobile Ad Hoc Networks mai= ling list <manet@ietf.org>
Subject: Re: [manet] Remaining issues aff= ecting the AODVv2 specification


Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so= are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If= anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets,&nb= sp;were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like= to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of = ;final points of open issues for next draft if not resolved). = ;

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.
--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.

-- 
Regards,
Charlie P.
_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/= mailman/listinfo/manet --B_3476957870_1736115-- From nobody Thu Mar 6 13:52:45 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CB91A00BB for ; Thu, 6 Mar 2014 13:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REVBcw8WPnDu for ; Thu, 6 Mar 2014 13:52:42 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 32ADC1A00AF for ; Thu, 6 Mar 2014 13:52:42 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id f73so3408860yha.0 for ; Thu, 06 Mar 2014 13:52:37 -0800 (PST) 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=ARsawxG48EJAgtP8K8KiQkTlfJb61ln5G+ztR5iBhdg=; b=kZev/0noNrLHJEA6zt9npv9Oy28XD0oJYBtLrXYojHu5UYsOpCjpFjGFsfejgNwqan hGlPSjHToiLYJ65TUTNhZaOoO98cDO7cDnWznxeT/5JVXi7STkd4h7eiiT1tgpcJmcEi pxdbyNYvHoc6UlXu+gc6SWKv4ajImFtwBtFXtnWGEQKLTIa8Q+/Oq9zsfr1xVU9AKzSt I/0RGBOd9cX2N2ZHsFgUgDj9NdP+YBPh/M8ht6Gq5cUFaouXrpt72FUSTOKi+eELuLMV QrT0sg//zcxc0OObv8ymbGGx9lv0qKG+Ua3xIaH+kqufbMEGOuTFn0TxUHWTTx6SsvLj D2AQ== MIME-Version: 1.0 X-Received: by 10.236.93.208 with SMTP id l56mr4972946yhf.112.1394142757718; Thu, 06 Mar 2014 13:52:37 -0800 (PST) Received: by 10.170.202.7 with HTTP; Thu, 6 Mar 2014 13:52:37 -0800 (PST) In-Reply-To: <5318E688.5060704@computer.org> References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E688.5060704@computer.org> Date: Thu, 6 Mar 2014 22:52:37 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=20cf3010ead1d70fc804f3f72773 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/W7qK_Ppi01qVs8u11Ltz39AiABY Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 21:52:45 -0000 --20cf3010ead1d70fc804f3f72773 Content-Type: text/plain; charset=ISO-8859-1 Hi Charles It is ok, I will do the previous ticket tracker, as you confirmed they are resolved. The new comments from WG we can input them as new tickets and solve that way to help progress. I am happy to do that both previous and new if you like. AB On Thursday, March 6, 2014, Charles E. Perkins wrote: > > Hello Abdussalam, > > The issues that had earlier been posted on the issue tracker > had been resolved. I intend to look for the tools.ietf.org emails > to the [manet] mailing list to re-document the resolutions, but > first I need to work on the issues that were posted to the > mailing list today. I am isolating separate issues from the email > and hope to have them on the tracker within the week. > > Regards, > Charlie P. > > On 3/6/2014 1:16 PM, Abdussalam Baryun wrote: > > Hi Thomas > > I seen your comments in the new thread reported. But does this message > mean you may have more points then that you posted today. > > Regards > AB > > On Thursday, March 6, 2014, Thomas Heide Clausen wrote: > > > On 6 mars 2014, at 20:35, Abdussalam Baryun > wrote: > > > Ok so I understand from your message below that authors confirm that the > draft is ready complete for WG to review and comment their open issues. > > > Having actually read the I-D, that is not the conclusion that I reach, > > I am very surprised if the authors believe that to be the state of the > document. > > Thomas > > AB > > On Thursday, March 6, 2014, Charles E. Perkins wrote: > > > Hello Abdussalam, > > Actually, all of the issues were resolved. Then, apparently, the > issues page crashed, and some recent updates to the issues were > lost. However, they were sent to the mailing list, and so are > recoverable, with a nontrivial amount of work amounting to > an archaeological expedition through the mailing list archives. > > I wanted to have time to do this, but so far have not. If anyone > wants to volunteer to recover the issue-tracker updates from the > mailing list, that would be terrific. > > Regards, > Charlie P. > > > On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: > > Hi Charles, > > I just had before a comment on the open tickets, were they all > closed, because I think may be open. Seems most MANET WG don't care about > tickets but I like to track and I remember that the AD did mention it's > importance. > > For me I will review new draft and comment, but if the authors have no > more pending issues to update, please confirm (sorry that I was not able to > remember if there are confirmation from authors that draft is ready or not, > also need their confirm of final points of open issues for next draft if > not resolved). > > Best Regards > > AB > > On Wednesday, March 5, 2014, Charles E. Perkins wrote: > > Hello folks, > > Part of the job of finishing the AODVv2 specification will be to comb > the mailing list for issues that are still not resolved. If there are > any specific issues that have not bee > > -- > Regards, > Charlie P. > > --20cf3010ead1d70fc804f3f72773 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Charles=A0

It is ok, I will do the previous=A0tic= ket tracker, as you confirmed they are resolved. The new comments from WG= =A0we can input them as new tickets=A0and solve that way to help progress. = I am happy to do that both previous and new=A0if you like.=A0

AB

On Thursday, March 6, 2014, Charles E.= Perkins wrote:
=20 =20 =20

Hello Abdussalam,

The issues that had earlier been posted on the issue tracker
had been resolved.=A0 I intend to look for the tools.ietf.org emails
to the [manet] mailing list to re-document the resolutions, but
first I need to work on the issues that were posted to the
mailing list today.=A0 I am isolating separate issues from the email and hope to have them on the tracker within the week.

Regards,
Charlie P.

On 3/6/2014 1:16 PM, Abdussalam Baryun wrote:
Hi Thomas

I seen your comments in the new thread reported. But does this message mean you may have more points then that you posted today.=A0

Regards
AB

On Thursday, March 6, 2014, Thomas Heide Clausen wrote:

On 6 mars 2014, at 20:35, Abdussalam Baryun <abdussa= lambaryun@gmail.com> wrote:


Ok so I understand from your message below=A0that authors confirm that the draft is ready complete=A0for WG to review and comment their open=A0issues.=A0


Having actually read the I-D, that is not the conclusion that I reach,

I am very surprised if the authors believe that to be the state of the document.

Thomas

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.=A0 Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.=A0 However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.=A0 If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open=A0tickets,=A0were they all closed,=A0because= I think may be open. Seems most=A0MANET WG don'= t care=A0about tickets but I like to track=A0and I remember that the AD did mention it's importance.=A0

For me I will review new draft and comment, but if the authors have no more pending=A0issues to update,=A0please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need=A0their confirm of=A0final points of open issues for next draft if not resolved).=A0

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved. =A0If there are
any specific issues that have not bee
--=20
Regards,
Charlie P.
--20cf3010ead1d70fc804f3f72773-- From nobody Thu Mar 6 14:04:10 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2491A01AC for ; Thu, 6 Mar 2014 14:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpUDU6Biglx6 for ; Thu, 6 Mar 2014 14:03:27 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 49DE11A0068 for ; Thu, 6 Mar 2014 14:03:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4FB81701838; Thu, 6 Mar 2014 14:03:06 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9E667701817; Thu, 6 Mar 2014 14:02:53 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-20D59204-95B1-433D-B979-90F4A3042C2B Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Thu, 6 Mar 2014 23:02:53 +0100 Content-Transfer-Encoding: 7bit Message-Id: <69B3041A-D744-4765-B29E-56CCA1D8418C@thomasclausen.org> References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/I0xErHiSygHrevv5hEGgIALfwbY Cc: "manet-ads@tools.ietf.org" , Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 22:04:03 -0000 --Apple-Mail-20D59204-95B1-433D-B979-90F4A3042C2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 6 mars 2014, at 22:16, Abdussalam Baryun w= rote: >=20 > Hi Thomas >=20 > I seen your comments in the new thread reported. But does this message mea= n you may have more points then that you posted today.=20 >=20 The protocol specification is so vague and ambiguous, and the protocol is so= underspecified, that it is just impossible to answer that question - either= way - at this juncture. Thomas > Regards > AB >=20 >> On Thursday, March 6, 2014, Thomas Heide Clausen wrote: >>=20 >>> On 6 mars 2014, at 20:35, Abdussalam Baryun = wrote: >>>=20 >>>=20 >>> Ok so I understand from your message below that authors confirm that the= draft is ready complete for WG to review and comment their open issues.=20 >>>=20 >>=20 >> Having actually read the I-D, that is not the conclusion that I reach, >>=20 >> I am very surprised if the authors believe that to be the state of the do= cument. >>=20 >> Thomas >>=20 >>> AB >>>=20 >>>> On Thursday, March 6, 2014, Charles E. Perkins wrote: >>>>=20 >>>> Hello Abdussalam, >>>>=20 >>>> Actually, all of the issues were resolved. Then, apparently, the >>>> issues page crashed, and some recent updates to the issues were >>>> lost. However, they were sent to the mailing list, and so are >>>> recoverable, with a nontrivial amount of work amounting to >>>> an archaeological expedition through the mailing list archives. >>>>=20 >>>> I wanted to have time to do this, but so far have not. If anyone >>>> wants to volunteer to recover the issue-tracker updates from the >>>> mailing list, that would be terrific. >>>>=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>>=20 >>>>> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>>>> Hi Charles, >>>>>=20 >>>>> I just had before a comment on the open tickets, were they all closed,= because I think may be open. Seems most MANET WG don't care about tickets b= ut I like to track and I remember that the AD did mention it's importance.=20= >>>>>=20 >>>>> For me I will review new draft and comment, but if the authors have no= more pending issues to update, please confirm (sorry that I was not able to= remember if there are confirmation from authors that draft is ready or not,= also need their confirm of final points of open issues for next draft if no= t resolved).=20 >>>>>=20 >>>>> Best Regards >>>>>=20 >>>>> AB >>>>>=20 >>>>>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>>>>> Hello folks, >>>>>>=20 >>>>>> Part of the job of finishing the AODVv2 specification will be to comb= >>>>>> the mailing list for issues that are still not resolved. If there ar= e >>>>>> any specific issues that have not been gotten proper attention, I hop= e >>>>>> to find them -- but if anyone would like to help by bringing them >>>>>> up here on the mailing list, that will be appreciated. >>>>>>=20 >>>>>> --=20 >>>>>> Regards, >>>>>> Charlie P. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> --=20 >>>> Regards, >>>> Charlie P. >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-20D59204-95B1-433D-B979-90F4A3042C2B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 6 mars 2014, at 22:16, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Thomas

I seen your comments in the new thread reported. But does this message mean you may have more points then that you posted today. 


The protocol specification is so vague and ambiguous, and the protocol is so underspecified, that it is just impossible to answer that question - either way - at this juncture.

Thomas

Regards
AB

On Thursday, March 6, 2014, Thomas Heide Clausen wrote:

On 6 mars 2014, at 20:35, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:


Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 


Having actually read the I-D, that is not the conclusion that I reach,

I am very surprised if the authors believe that to be the state of the document.

Thomas

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved). 

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-20D59204-95B1-433D-B979-90F4A3042C2B-- From nobody Thu Mar 6 14:31:57 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AC91A00AF for ; Thu, 6 Mar 2014 14:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAYWKDckMAs9 for ; Thu, 6 Mar 2014 14:31:53 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A2D3B1A0068 for ; Thu, 6 Mar 2014 14:31:53 -0800 (PST) Received: by mail-yk0-f175.google.com with SMTP id 131so8472070ykp.6 for ; Thu, 06 Mar 2014 14:31:49 -0800 (PST) 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=sb1Rc9l9h8jGtMk6tmYseObcAphaLwS1ZaaojckEFkA=; b=ZFU1cjJdnkAJNlbAHHaU3BeMQzmbXdnV7brKijMWRSTU9T0yPWnUc4zNV6NjPh06xq c1Fa2PxMACqXMIKFwPMCXZWSRf7/P98C6YNbDjHast334YQh2HZO+RhIMkeiQ4yHlnXm i6Z401KHTJeB6b235m+eal1Uxpt276x98WsCIQ1/11OT6OojcgY9sssGzM9W1632O+lj +W8b8JfJimH4vkRhDfnXF75z2x4zJI82uwneSQNT7YfNhNnxnzCnjAR580nny50mw9Ed 0j3j2wlRrH45jqNImubg+/vGQGutTh5vp2p+kFx/tnVBDn8uqPV1xYMIytJe4Sgd7TLK j0lw== MIME-Version: 1.0 X-Received: by 10.236.89.11 with SMTP id b11mr18730139yhf.16.1394145109415; Thu, 06 Mar 2014 14:31:49 -0800 (PST) Received: by 10.170.202.7 with HTTP; Thu, 6 Mar 2014 14:31:49 -0800 (PST) Date: Thu, 6 Mar 2014 23:31:49 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=20cf300e56b7031b4b04f3f7b43d Archived-At: http://mailarchive.ietf.org/arch/msg/manet/z0zTi9OljNsaXZVZ5YgytxYoVqk Cc: manet Subject: [manet] OLSRv2 interoperable experience X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 22:31:55 -0000 --20cf300e56b7031b4b04f3f7b43d Content-Type: text/plain; charset=ISO-8859-1 Hello Thomas, I asked a question in the last meeting IETF 89 about the tests of OLSRv2 and experience as it was presented and mention many tests. I asked just for technical summary, showing advise or possible errors detected in some deployment and interoperability work of this protocol. Please help. Best Regards, AB --20cf300e56b7031b4b04f3f7b43d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Thomas,

I asked a question in the last meeting IET= F 89=A0about the tests of OLSRv2 and experience as it was presented and men= tion many tests. I asked just for technical=A0summary, showing advise or po= ssible=A0errors detected in some deployment and interoperability=A0work of = this protocol. Please help.=A0

Best Regards,

AB

--20cf300e56b7031b4b04f3f7b43d-- From nobody Thu Mar 6 15:01:07 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102181A00F1 for ; Thu, 6 Mar 2014 15:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyr5bziNONU9 for ; Thu, 6 Mar 2014 15:00:59 -0800 (PST) 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 8DD991A002B for ; Thu, 6 Mar 2014 15:00:59 -0800 (PST) Received: from [130.129.155.157] by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WLhHa-0001BU-R7; Thu, 06 Mar 2014 18:00:55 -0500 Message-ID: <5318FE25.2090601@computer.org> Date: Thu, 06 Mar 2014 15:00:53 -0800 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Don Sturek References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070105010804090300040306" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86b2661f081cbea5ad0fe1dcf71807e76a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.155.157 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JLxdmzmR8QUyZGKjsbLnMbQPTJk Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 23:01:03 -0000 This is a multi-part message in MIME format. --------------070105010804090300040306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Don, Yes, it has been my intention to address the issues as they arise, and I do agree that it is far better to do so when the context is current. In the case of the missing resolutions on the issue tracker, that was due to some malfunction on the IETF tools site. In the case of the issues that were never posted on the IETF issue tracker, there have been various other problems. Regards, Charlie P. On 3/6/2014 1:37 PM, Don Sturek wrote: > Hi Charlie, > > It would be worth (going forward) addressing issues as they come up on > the reflector rather than having to mine these topics out of the > reflector archives months later. > > Most folks have limited time to spend reviewing drafts. Ignoring > comments for several months does not help resolving these issues since > in many cases the comment and context is lost after a long period of time. > > Don > > > From: "Charles E. Perkins" > > Organization: Blue Skies > Date: Thursday, March 6, 2014 1:26 PM > To: Abdussalam Baryun > > Cc: Mobile Ad Hoc Networks mailing list > > Subject: Re: [manet] Remaining issues affecting the AODVv2 specification > > > Hello Abdussalam, > > Before the draft goes to last call, we need to resolve the > open issues that were posted to the mailing list. When I > mentioned that the earlier issues on the issue tracker had > been resolved, that did not include the other issues that > were not posted to the issue tracker. As mentioned in my > previous email, I will take care of posting them to the tracker > so that the resolution process will be easier to follow. > > Regards, > Charlie P. > > On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: >> >> Ok so I understand from your message below that authors confirm that >> the draft is ready complete for WG to review and comment their >> open issues. >> >> AB >> >> On Thursday, March 6, 2014, Charles E. Perkins wrote: >> >> >> Hello Abdussalam, >> >> Actually, all of the issues were resolved. Then, apparently, the >> issues page crashed, and some recent updates to the issues were >> lost. However, they were sent to the mailing list, and so are >> recoverable, with a nontrivial amount of work amounting to >> an archaeological expedition through the mailing list archives. >> >> I wanted to have time to do this, but so far have not. If anyone >> wants to volunteer to recover the issue-tracker updates from the >> mailing list, that would be terrific. >> >> Regards, >> Charlie P. >> >> >> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>> Hi Charles, >>> >>> I just had before a comment on the open tickets, were they all >>> closed, because I think may be open. Seems most MANET WG don't >>> care about tickets but I like to track and I remember that the >>> AD did mention it's importance. >>> >>> For me I will review new draft and comment, but if the authors >>> have no more pending issues to update, please confirm (sorry >>> that I was not able to remember if there are confirmation from >>> authors that draft is ready or not, also need their confirm >>> of final points of open issues for next draft if not resolved). >>> >>> Best Regards >>> >>> AB >>> >>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>> >>> Hello folks, >>> >>> Part of the job of finishing the AODVv2 specification will >>> be to comb >>> the mailing list for issues that are still not resolved. If >>> there are >>> any specific issues that have not been gotten proper >>> attention, I hope >>> to find them -- but if anyone would like to help by bringing >>> them >>> up here on the mailing list, that will be appreciated. >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> -- >> Regards, >> Charlie P. >> > > -- > Regards, > Charlie P. > _______________________________________________ manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------070105010804090300040306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Don,

Yes, it has been my intention to address the issues as they arise, and
I do agree that it is far better to do so when the context is current.

In the case of the missing resolutions on the issue tracker, that was
due to some malfunction on the IETF tools site.  In the case of the
issues that were never posted on the IETF issue tracker, there have
been various other problems.

Regards,
Charlie P.


On 3/6/2014 1:37 PM, Don Sturek wrote:
Hi Charlie,

It would be worth (going forward) addressing issues as they come up on the reflector rather than having to mine these topics out of the reflector archives months later.

Most folks have limited time to spend reviewing drafts.  Ignoring comments for several months does not help resolving these issues since in many cases the comment and context is lost after a long period of time.

Don


From: "Charles E. Perkins" <charliep@computer.org>
Organization: Blue Skies
Date: Thursday, March 6, 2014 1:26 PM
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: Re: [manet] Remaining issues affecting the AODVv2 specification


Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my
previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved). 

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.
--------------070105010804090300040306-- From nobody Thu Mar 6 15:01:18 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F741A01AF for ; Thu, 6 Mar 2014 15:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnSxQqPu9Nqy for ; Thu, 6 Mar 2014 15:01:09 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 995BE1A01A7 for ; Thu, 6 Mar 2014 15:01:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DD2171C0776; Thu, 6 Mar 2014 15:01:05 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9797F1C02DB; Thu, 6 Mar 2014 15:01:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Fri, 7 Mar 2014 00:01:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3FF22EA3-280E-40FE-9E5C-3BD425F18FCF@thomasclausen.org> References: To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ONinIi-FTtBkvLqDbV0SMyAp97w Cc: manet Subject: Re: [manet] OLSRv2 interoperable experience X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 23:01:13 -0000 Dear Abdussalam, > On 6 mars 2014, at 23:31, Abdussalam Baryun w= rote: >=20 > Hello Thomas, >=20 > I asked a question in the last meeting IETF 89 about the tests of OLSRv2 a= nd experience as it was presented and mention many tests. I asked just for t= echnical summary, showing advise or possible errors detected in some deploym= ent and interoperability work of this protocol. Please help.=20 >=20 These are really two different things, that you are asking about. Interoperability implies that independent implementations of the protocols a= re able to interoperate: correctly parse and interpret each other's messages= , and "do the right processing" as a consequence. As indicated, and as indic= ated in the shepherd write-up for OLSRv2 prior to publication, several known= implementations exist and have demonstrated this through numerous interoper= ability tests over the years.=20 Demonstrated interoperability of independent implementations (the operative w= ord being "independent", as in "developed by different teams/institutions, w= ithout any conferring outside of reading the same specification") really ser= ve as the litmus test of the quality of a specification, and are - in my not= so humble opinion - indispensable prior to publishing a protocol specificat= ion on standards track. I am sure you will agree, the reason for which stand= ards are written is to enable independent implementors to write interoperabl= e code, so standards need to be written to enable exactly that. Deployment experiences are hugely dependent on the scenarios that you are de= ploying in, specifically (but not exclusively) the L2 you are using. Mobilit= y, topology densities, ..., all play a role here, too. As far as I know, for= MANETs there are many different scenarios and L2 in use. I know of MANETs t= hat are deployed over (perfectly reliable, high-capacity) Ethernet point-to-= point links, and of other MANETs that are deployed over (highly lossy, low-c= apacity, time-varying) wireless links -- and, even, MANETs which have both k= inds of links at the same time.=20 To try to make a general observation that seem commonly (but not universally= ) valid, the biggest "lesson learned" from deployments probably is, that hop= -count metrics aren't the most appropriate metric to use in many wireless sc= enarios; Henning and Emmanuel's I-D (that was called for, for WG adaptation r= ecently) is an alternative metric that is based on the deployment experienc= es of Henning and Emmanuel and which - in their deployments, at least, is ad= vantageous. I strongly encourage those efforts, of documenting operational e= xperiences, and which metrics are found to be viable. I know that NRL has be= en successful with different metrics (different from the Henning/Emmanuel pr= oposal, that is) for their scenarios/L2's, and that's wonderful also - their= scenarios and L2's are very different. Indeed, that is the reason why OLSRv= 2 does not recommend a specific metric, but leaves the flexibility for a dep= loyment and L2 to use an appropriate (or, multiple appropriate) metrics. Best, Thomas > Best Regards, >=20 > AB >=20 From nobody Thu Mar 6 15:06:54 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0961A0157 for ; Thu, 6 Mar 2014 15:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw5uC7km2dbV for ; Thu, 6 Mar 2014 15:06:45 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id F18CB1A01C0 for ; Thu, 6 Mar 2014 15:06:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3BE08701F6C; Thu, 6 Mar 2014 15:06:41 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 73A191C0776; Thu, 6 Mar 2014 15:06:40 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-A9A7270B-324A-4712-A05A-2663731BB910 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: <5318FE25.2090601@computer.org> Date: Fri, 7 Mar 2014 00:06:39 +0100 Content-Transfer-Encoding: 7bit Message-Id: <58C9687E-3374-45D4-8EE6-B37A1AA33C8E@thomasclausen.org> References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> <5318FE25.2090601@computer.org> To: "Charles E. Perkins" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/KNJw-BpGUMAYFWIl5_ozC9cSpVM Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 23:06:52 -0000 --Apple-Mail-A9A7270B-324A-4712-A05A-2663731BB910 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 7 mars 2014, at 00:00, "Charles E. Perkins" wro= te: >=20 >=20 > Hello Don, >=20 > Yes, it has been my intention to address the issues as they arise, and > I do agree that it is far better to do so when the context is current. > In the case of the missing resolutions on the issue tracker, that was > due to some malfunction on the IETF tools site. In the case of the > issues that were never posted on the IETF issue tracker, there have > been various other problems. >=20 I believe that the IETF maintains stable archives of the messages sent to th= e mail reflectors, and that any issues posted there are available - and have= been repeated frequently - in postings on this reflector. I am not aware of any failures of the mail reflector archives, and so I am n= ot sure what "various other problems" are referred. So far, I have never had= any problems retrieving past postings from these archives. I have no recoll= ection of having heard of others reporting problems of the sort. My experience remains, that the IETF Tools Team and the Secretariat always h= ave been very rapid in resolving any problems that may have occurred. (As a b= onus, they are a true pleasure to deal with, even when there are problems) Best, Thomas > Regards, > Charlie P. >=20 >=20 >> On 3/6/2014 1:37 PM, Don Sturek wrote: >> Hi Charlie, >>=20 >> It would be worth (going forward) addressing issues as they come up on th= e reflector rather than having to mine these topics out of the reflector arc= hives months later. >>=20 >> Most folks have limited time to spend reviewing drafts. Ignoring comment= s for several months does not help resolving these issues since in many case= s the comment and context is lost after a long period of time. >>=20 >> Don >>=20 >>=20 >> From: "Charles E. Perkins" >> Organization: Blue Skies >> Date: Thursday, March 6, 2014 1:26 PM >> To: Abdussalam Baryun >> Cc: Mobile Ad Hoc Networks mailing list >> Subject: Re: [manet] Remaining issues affecting the AODVv2 specification >>=20 >>=20 >> Hello Abdussalam, >>=20 >> Before the draft goes to last call, we need to resolve the >> open issues that were posted to the mailing list. When I >> mentioned that the earlier issues on the issue tracker had >> been resolved, that did not include the other issues that >> were not posted to the issue tracker. As mentioned in my >> previous email, I will take care of posting them to the tracker >> so that the resolution process will be easier to follow. >>=20 >> Regards, >> Charlie P. >>=20 >>> On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: >>>=20 >>> Ok so I understand from your message below that authors confirm that the= draft is ready complete for WG to review and comment their open issues.=20 >>>=20 >>> AB >>>=20 >>>> On Thursday, March 6, 2014, Charles E. Perkins wrote: >>>>=20 >>>> Hello Abdussalam, >>>>=20 >>>> Actually, all of the issues were resolved. Then, apparently, the >>>> issues page crashed, and some recent updates to the issues were >>>> lost. However, they were sent to the mailing list, and so are >>>> recoverable, with a nontrivial amount of work amounting to >>>> an archaeological expedition through the mailing list archives. >>>>=20 >>>> I wanted to have time to do this, but so far have not. If anyone >>>> wants to volunteer to recover the issue-tracker updates from the >>>> mailing list, that would be terrific. >>>>=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>>=20 >>>>> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>>>> Hi Charles, >>>>>=20 >>>>> I just had before a comment on the open tickets, were they all closed,= because I think may be open. Seems most MANET WG don't care about tickets b= ut I like to track and I remember that the AD did mention it's importance.=20= >>>>>=20 >>>>> For me I will review new draft and comment, but if the authors have no= more pending issues to update, please confirm (sorry that I was not able to= remember if there are confirmation from authors that draft is ready or not,= also need their confirm of final points of open issues for next draft if no= t resolved).=20 >>>>>=20 >>>>> Best Regards >>>>>=20 >>>>> AB >>>>>=20 >>>>>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>>>>> Hello folks, >>>>>>=20 >>>>>> Part of the job of finishing the AODVv2 specification will be to comb= >>>>>> the mailing list for issues that are still not resolved. If there ar= e >>>>>> any specific issues that have not been gotten proper attention, I hop= e >>>>>> to find them -- but if anyone would like to help by bringing them >>>>>> up here on the mailing list, that will be appreciated. >>>>>>=20 >>>>>> --=20 >>>>>> Regards, >>>>>> Charlie P. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> --=20 >>>> Regards, >>>> Charlie P. >>=20 >> --=20 >> Regards, >> Charlie P. >> _______________________________________________ manet mailing list manet@= ietf.org https://www.ietf.org/mailman/listinfo/manet >=20 > --=20 > Regards, > Charlie P. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-A9A7270B-324A-4712-A05A-2663731BB910 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 7 mars 2014, at 00:00, "Charles E. Perkins" <charliep@computer.org> wrote:


Hello Don,

Yes, it has been my intention to address the issues as they arise, and
I do agree that it is far better to do so when the context is current.
In the case of the missing resolutions on the issue tracker, that was
due to some malfunction on the IETF tools site.  In the case of the
issues that were never posted on the IETF issue tracker, there have
been various other problems.


I believe that the IETF maintains stable archives of the messages sent to the mail reflectors, and that any issues posted there are available - and have been repeated frequently - in postings on this reflector.

I am not aware of any failures of the mail reflector archives, and so I am not sure what "various other problems" are referred. So far, I have never had any problems retrieving past postings from these archives. I have no recollection of having heard of others reporting problems of the sort.

My experience remains, that the IETF Tools Team and the Secretariat always have been very rapid in resolving any problems that may have occurred. (As a bonus, they are a true pleasure to deal with, even when there are problems)

Best,

Thomas



Regards,
Charlie P.


On 3/6/2014 1:37 PM, Don Sturek wrote:
Hi Charlie,

It would be worth (going forward) addressing issues as they come up on the reflector rather than having to mine these topics out of the reflector archives months later.

Most folks have limited time to spend reviewing drafts.  Ignoring comments for several months does not help resolving these issues since in many cases the comment and context is lost after a long period of time.

Don


From: "Charles E. Perkins" <charliep@computer.org>
Organization: Blue Skies
Date: Thursday, March 6, 2014 1:26 PM
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: Re: [manet] Remaining issues affecting the AODVv2 specification


Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my
previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved). 

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-A9A7270B-324A-4712-A05A-2663731BB910-- From nobody Thu Mar 6 22:36:15 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468611A0211 for ; Thu, 6 Mar 2014 22:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHCAYhIFpTqG for ; Thu, 6 Mar 2014 22:36:10 -0800 (PST) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id B4FFD1A020E for ; Thu, 6 Mar 2014 22:36:10 -0800 (PST) Received: by mail-yh0-f48.google.com with SMTP id z6so3811704yhz.7 for ; Thu, 06 Mar 2014 22:36:06 -0800 (PST) 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=X4cXCyQhilliZ/1K3xrEirclmc2UwA20/ZfAfpclr0o=; b=oHbrE/XqLaIx/U29LJfJ1OuRvUnkGfvVFNUXthDaz7Z1O8vuRHdgcQKWnNoUaIyuxc LIQYCO+UcTZSMMPFqVc2ssqClJHYDOKm9X050cmBwFkqzpNHSfuzeeO1K4wTmd2kbIZf wOy0taoG90I6zXbuhrOz+/aLCJSBJdjZbUU1+ecrm4q0kYRNyoRnCCjieFcBhFR12pbk Mr0iyihNvmNZYP3+Q0IZRA7Pz4YAlBT0k2zuUOc7ZL8Gb/SvLz3I4STTCJhyvJbs/PGk eepReGZgHkwpc5bF+TCMcOXNUDgqHV817XuGgr63LSZHN4lpYWhqpQZLpcj3t8t3H8T/ FSPw== MIME-Version: 1.0 X-Received: by 10.236.190.100 with SMTP id d64mr20606426yhn.76.1394174166445; Thu, 06 Mar 2014 22:36:06 -0800 (PST) Received: by 10.170.202.7 with HTTP; Thu, 6 Mar 2014 22:36:06 -0800 (PST) In-Reply-To: <3FF22EA3-280E-40FE-9E5C-3BD425F18FCF@thomasclausen.org> References: <3FF22EA3-280E-40FE-9E5C-3BD425F18FCF@thomasclausen.org> Date: Fri, 7 Mar 2014 07:36:06 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=20cf305e262bf2335d04f3fe7711 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pPCB9X-cPQyYo5o8kHWpNFAln9w Cc: manet Subject: Re: [manet] OLSRv2 interoperable experience X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 06:36:13 -0000 --20cf305e262bf2335d04f3fe7711 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, Thanks a lot. so could I understand that when implementing OLSRv2 and when people gathered testing OLSRv2 (as you pictures of gatherings in your presentation in MANET WG IETF89) the process of test had no single minor error in coding or error in routing process in that gathering or what were the learning main issues/points developed. Sorry if my question was not explained well, AB On Thursday, March 6, 2014, Thomas Heide Clausen wrote: > Dear Abdussalam, > > > On 6 mars 2014, at 23:31, Abdussalam Baryun > > wrote: > > > > Hello Thomas, > > > > I asked a question in the last meeting IETF 89 about the tests of OLSRv2 > and experience as it was presented and mention many tests. I asked just for > technical summary, showing advise or possible errors detected in some > deployment and interoperability work of this protocol. Please help. > > > > These are really two different things, that you are asking about. > > Interoperability implies that independent implementations of the protocols > are able to interoperate: correctly parse and interpret each other's > messages, and "do the right processing" as a consequence. As indicated, and > as indicated in the shepherd write-up for OLSRv2 prior to publication, > several known implementations exist and have demonstrated this through > numerous interoperability tests over the years. > > Demonstrated interoperability of independent implementations (the > operative word being "independent", as in "developed by different > teams/institutions, without any conferring outside of reading the same > specification") really serve as the litmus test of the quality of a > specification, and are - in my not so humble opinion - indispensable prior > to publishing a protocol specification on standards track. I am sure you > will agree, the reason for which standards are written is to enable > independent implementors to write interoperable code, so standards need to > be written to enable exactly that. > > Deployment experiences are hugely dependent on the scenarios that you are > deploying in, specifically (but not exclusively) the L2 you are using. > Mobility, topology densities, ..., all play a role here, too. As far as I > know, for MANETs there are many different scenarios and L2 in use. I know > of MANETs that are deployed over (perfectly reliable, high-capacity) > Ethernet point-to-point links, and of other MANETs that are deployed over > (highly lossy, low-capacity, time-varying) wireless links -- and, even, > MANETs which have both kinds of links at the same time. > > To try to make a general observation that seem commonly (but not > universally) valid, the biggest "lesson learned" from deployments probably > is, that hop-count metrics aren't the most appropriate metric to use in > many wireless scenarios; Henning and Emmanuel's I-D (that was called for, > for WG adaptation recently) is an alternative metric that is based on the > deployment experiences of Henning and Emmanuel and which - in their > deployments, at least, is advantageous. I strongly encourage those efforts, > of documenting operational experiences, and which metrics are found to be > viable. I know that NRL has been successful with different metrics > (different from the Henning/Emmanuel proposal, that is) for their > scenarios/L2's, and that's wonderful also - their scenarios and L2's are > very different. Indeed, that is the reason why OLSRv2 does not recommend a > specific metric, but leaves the flexibility for a deployment and L2 to use > an appropriate (or, multiple appropriate) metrics. > > Best, > > Thomas > > > > Best Regards, > > > > AB > > > --20cf305e262bf2335d04f3fe7711 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas,

Thanks a lot.=A0=A0so could I understand that= when implementing OLSRv2 and when people gathered testing OLSRv2 (as you p= ictures of gatherings=A0in your=A0presentation in MANET WG=A0IETF89) the pr= ocess of test had no single minor=A0error in coding or error in routing pro= cess in that gathering=A0or what were=A0the learning main=A0issues/points= =A0developed.=A0Sorry if my question was=A0not explained well,=A0

AB

On Thursday, March 6, 2014, Thomas Heide Clau= sen wrote:
Dear Abdussalam,

> On 6 mars 2014, at 23:31, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
>
> Hello Thomas,
>
> I asked a question in the last meeting IETF 89 about the tests of OLSR= v2 and experience as it was presented and mention many tests. I asked just = for technical summary, showing advise or possible errors detected in some d= eployment and interoperability work of this protocol. Please help.
>

These are really two different things, that you are asking about.

Interoperability implies that independent implementations of the protocols = are able to interoperate: correctly parse and interpret each other's me= ssages, and "do the right processing" as a consequence. As indica= ted, and as indicated in the shepherd write-up for OLSRv2 prior to publicat= ion, several known implementations exist and have demonstrated this through= numerous interoperability tests over the years.

Demonstrated interoperability of independent implementations (the operative= word being "independent", as in "developed by different tea= ms/institutions, without any conferring outside of reading the same specifi= cation") really serve as the litmus test of the quality of a specifica= tion, and are - in my not so humble opinion - indispensable prior to publis= hing a protocol specification on standards track. I am sure you will agree,= the reason for which standards are written is to enable independent implem= entors to write interoperable code, so standards need to be written to enab= le exactly that.

Deployment experiences are hugely dependent on the scenarios that you are d= eploying in, specifically (but not exclusively) the L2 you are using. Mobil= ity, topology densities, ..., all play a role here, too. As far as I know, = for MANETs there are many different scenarios and L2 in use. I know of MANE= Ts that are deployed over (perfectly reliable, high-capacity) Ethernet poin= t-to-point links, and of other MANETs that are deployed over (highly lossy,= low-capacity, time-varying) wireless links -- and, even, MANETs which have= both kinds of links at the same time.

To try to make a general observation that seem commonly (but not universall= y) valid, the biggest "lesson learned" from deployments probably = is, that hop-count metrics aren't the most appropriate metric to use in= many wireless scenarios; Henning and Emmanuel's I-D (that was called f= or, for WG adaptation recently) is an alternative metric that =A0is based o= n the deployment experiences of Henning and Emmanuel and which - in their d= eployments, at least, is advantageous. I strongly encourage those efforts, = of documenting operational experiences, and which metrics are found to be v= iable. I know that NRL has been successful with different metrics (differen= t from the Henning/Emmanuel proposal, that is) for their scenarios/L2's= , and that's wonderful also - their scenarios and L2's are very dif= ferent. Indeed, that is the reason why OLSRv2 does not recommend a specific= metric, but leaves the flexibility for a deployment and L2 to use an appro= priate (or, multiple appropriate) metrics.

Best,

Thomas


> Best Regards,
>
> AB
>
--20cf305e262bf2335d04f3fe7711-- From nobody Thu Mar 6 23:53:40 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C651C1A023B for ; Thu, 6 Mar 2014 23:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7CYeMqqDj-T for ; Thu, 6 Mar 2014 23:53:36 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C629F1A0200 for ; Thu, 6 Mar 2014 23:53:35 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 10so9808036ykt.4 for ; Thu, 06 Mar 2014 23:53:31 -0800 (PST) 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=jni11FsO81LcwRrUrIcsoEkYFu5aBc5no6zRBD7sYh0=; b=GSaW0FDIZ+y8IMjQxLVe5yO+lPL5Ir3OqhpvpjvTbA9sz0ynXUSLYzWNSAgwUc0vxY lO1/D4NThhQ+duh7+V1jBOatL4p4QVdEfAqQzT8n3yy+i7/nh4qRYD5bfpepqZrfpki0 E6gJIK24ZLUOjjPVlErCL/lumNyHCFmeRB99OaddrAL3bUbdEne8rcI6AbXGuEF/G+ky J9tj8BNHUnnQiW8DFViH1MFNW3F49nlBCS+VzzIpKge4Lg9Foej6sv7PEuurzLDcfz6Q IXOY+DhfrrX/wxl7j8eVZdc5ZsrU1SFfDUv6toCSE+ohXfZfiukxBYMx/HLswWixY9FX v0+g== MIME-Version: 1.0 X-Received: by 10.236.127.39 with SMTP id c27mr17392yhi.120.1394178811357; Thu, 06 Mar 2014 23:53:31 -0800 (PST) Received: by 10.170.202.7 with HTTP; Thu, 6 Mar 2014 23:53:31 -0800 (PST) In-Reply-To: References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> Date: Fri, 7 Mar 2014 08:53:31 +0100 Message-ID: From: Abdussalam Baryun To: Don Sturek Content-Type: multipart/alternative; boundary=20cf3010e2d1cdeeb504f3ff8cb6 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0ihp6TxWMPjESt_B9VDWegcNXw8 Cc: Mobile Ad Hoc Networks mailing list Subject: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 07:53:39 -0000 --20cf3010e2d1cdeeb504f3ff8cb6 Content-Type: text/plain; charset=ISO-8859-1 Hi Don, I think the issue of not missing messages happens a lot to me with most of the IETF editors related to I-Ds. The best tool is the ticket tracker, because discussion messages are some how not focused on the I-D but may go through theories/imaginations/possibilities/personality/etc. When the AODVv2 started -00 with new author team it was not DYMO any more, and I think that no message has been not replied to since AODVv2-00 published in March 2013. Yes there was a reminder from participant on DYMO draft comments, but I am not sure the authors have time to discuss DYMO document after it mature and the WG dropping it and starting adopting another document which is AODVv2. I recommend the WG to focus on active documents so we can progress our work. Otherwise we will not have time. AB On Thursday, March 6, 2014, Don Sturek wrote: > Hi Charlie, > > It would be worth (going forward) addressing issues as they come up on the > reflector rather than having to mine these topics out of the reflector > archives months later. > > Most folks have limited time to spend reviewing drafts. Ignoring comments > for several months does not help resolving these issues since in many cases > the comment and context is lost after a long period of time. > > Don > > > From: "Charles E. Perkins" > Organization: Blue Skies > Date: Thursday, March 6, 2014 1:26 PM > To: Abdussalam Baryun > Cc: Mobile Ad Hoc Networks mailing list > Subject: Re: [manet] Remaining issues affecting the AODVv2 specification > > > Hello Abdussalam, > > Before the draft goes to last call, we need to resolve the > open issues that were posted to the mailing list. When I > mentioned that the earlier issues on the issue tracker had > been resolved, that did not include the other issues that > were not posted to the issue tracker. As mentioned in my > previous email, I will take care of posting them to the tracker > so that the resolution process will be easier to follow. > > Regards, > Charlie P. > > On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: > > > Ok so I understand from your message below that authors confirm that the > draft is ready complete for WG to review and comment their open issues. > > AB > > On Thursday, March 6, 2014, Charles E. Perkins wrote: > >> >> Hello Abdussalam, >> >> Actually, all of the issues were resolved. Then, apparently, the >> issues page crashed, and some recent updates to the issues were >> lost. However, they were sent to the mailing list, and so are >> recoverable, with a nontrivial amount of work amounting to >> an archaeological expedition through the mailing list archives. >> >> I wanted to have time to do this, but so far have not. If anyone >> wants to volunteer to recover the issue-tracker updates from the >> mailing list, that would be terrific. >> >> Regards, >> Charlie P. >> >> >> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >> >> Hi Charles, >> >> I just had before a comment on the open tickets, were they all >> closed, because I think may be open. Seems most MANET WG don't care about >> tickets but I like to track and I remember that the AD did mention it's >> importance. >> >> For me I will review new draft and comment, but if the authors have no >> more pending issues to update, please confirm (sorry that I was not able to >> remember if there are confirmation from authors that draft is ready or not, >> also need their confirm of final points of open issues for next draft if >> not resolved). >> >> Best Regards >> >> AB >> >> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >> >>> Hello folks, >>> >>> Part of the job of finishing the AODVv2 specification will be to comb >>> the mailing list for issues that are still not resolved. If there are >>> any specific issues that have not been gotten proper attention, I hope >>> to find them -- but if anyone would like to help by bringing them >>> up here on the mailing list, that will be appreciated. >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> -- >> Regards, >> Charlie P. >> >> > -- > Regards, > Charlie P. > > _______________________________________________ manet mailing list > manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > --20cf3010e2d1cdeeb504f3ff8cb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Don,

I think the issue of not missing messages happen= s a lot to me with=A0most of the IETF editors related to I-Ds. The best too= l is the ticket tracker, because discussion messages are some how not focus= ed on the I-D but may go through theories/imaginations/possibilities/person= ality/etc.=A0

When the AODVv2 started -00 with new author team=A0it w= as not DYMO any more,=A0and I think that no message has been not replied to= since AODVv2-00=A0published in March 2013. Yes there was a reminder from p= articipant on DYMO draft comments,=A0but I am not sure the authors have tim= e to=A0discuss DYMO=A0document after it mature and the WG dropping it and s= tarting adopting=A0another document which is AODVv2.=A0

I recommend the WG=A0to focus on active documents so we= can progress our work. Otherwise we will not have time.=A0

<= /div>AB

On Thursday, March 6, 2014, Don Sturek wrote:
Hi Charlie,

It would be worth (going forward) addressing issues as they come up on= the reflector rather than having to mine these topics out of the reflector= archives months later.

Most folks have limited ti= me to spend reviewing drafts. =A0Ignoring comments for several months does = not help resolving these issues since in many cases the comment and context= is lost after a long period of time.

Don


From: "Charles E. Perkins&quo= t; <charliep@computer.org>
Organization: Blue Skies
Date: Thursday, March 6, 2014 1:26= PM
To: Abdussalam Baryun <<= a>abdussalambaryun@gmail.com>
Cc: Mobile Ad Hoc Networks mailing= list <manet@ietf.org>
Sub= ject: Re: [manet] Remaining issues affecting the AODVv2 specificati= on

=20 =20 =20

Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.=A0 When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.=A0=A0 As mentioned in my
previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below=A0that authors confirm that the draft is ready complete=A0for WG to review and comment their open=A0issues.=A0

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.=A0 Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.=A0 However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.=A0 If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open=A0tickets,=A0wer= e they all closed,=A0because I think may be open. Seems most=A0MANET WG don't care=A0about tickets but I like t= o track=A0and I remember that the AD did mention it's importance.=A0

For me I will review new draft and comment, but if the authors have no more pending=A0issues to update,=A0please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need=A0their confirm of=A0final points of open issues for next draft if not resolved).=A0

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved. =A0If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.
--
Regards,
Charlie P.

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

--=20
Regards,
Charlie P.

--=20
Regards,
Charlie P.
_______________________________________________ manet mailing list manet@ietf.org h= ttps://www.ietf.org/mailman/listinfo/manet
--20cf3010e2d1cdeeb504f3ff8cb6-- From nobody Fri Mar 7 01:05:58 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46571A025A for ; Fri, 7 Mar 2014 01:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDbYPnyB-j8u for ; Fri, 7 Mar 2014 01:05:54 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 4956C1A025D for ; Fri, 7 Mar 2014 01:05:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 18DE91C2049B; Fri, 7 Mar 2014 01:05:50 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9B5C31C2049A; Fri, 7 Mar 2014 01:05:49 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-6524DBF2-B893-40CE-B0DC-2227341CE0EB Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Fri, 7 Mar 2014 10:05:50 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1C91EFF0-5BA8-4371-AC9A-9C7912B6F687@thomasclausen.org> References: <3FF22EA3-280E-40FE-9E5C-3BD425F18FCF@thomasclausen.org> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xAUBoh_gEDGcOz4Drb5vIvEOB2M Cc: manet Subject: Re: [manet] OLSRv2 interoperable experience X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:05:56 -0000 --Apple-Mail-6524DBF2-B893-40CE-B0DC-2227341CE0EB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear Abdussalam,, > On 7 mars 2014, at 07:36, Abdussalam Baryun w= rote: >=20 > Hi Thomas, >=20 > Thanks a lot. so could I understand that when implementing OLSRv2 and whe= n people gathered testing OLSRv2 (as you pictures of gatherings in your pres= entation in MANET WG IETF89) the process of test had no single minor error i= n coding or error in routing process in that gathering or what were the lear= ning main issues/points developed. Sorry if my question was not explained we= ll,=20 >=20 Interops have as objective to verify interoperability of independent impleme= ntations of the same specification - as a way to measure the quality of a sp= ecification prior to standardization. That's what a standards developing org= anization is interested in, and not the quality of code from one organizatio= n or another.=20 I believe that the OLSR/OLSRv2 interops were successful, in that we had nume= rous independent and complete implementations participating successfully ove= r the years. Interops do not really have as goal to test the ability of an individual or a= n organization to write bug-free code, and so it is not really in my place t= o report if person X came along with code that segfaulted, or if the code of= organization Y had a memory leak. In fact, I'd probably make myself highly u= npopular if I did hang out person X or organization Y, by divulging which fl= aws their code had. Also, mind you, some of the interops were as much as 10 years ago....given t= hat, on some days, I have a hard time remembering what I had for breakfast ;= ) I probably would not remember such details correctly anyways: as they wer= e not relevant to the interop, they were not recorded. Best, Thomas > AB >=20 >> On Thursday, March 6, 2014, Thomas Heide Clausen wrote: >> Dear Abdussalam, >>=20 >> > On 6 mars 2014, at 23:31, Abdussalam Baryun wrote: >> > >> > Hello Thomas, >> > >> > I asked a question in the last meeting IETF 89 about the tests of OLSRv= 2 and experience as it was presented and mention many tests. I asked just fo= r technical summary, showing advise or possible errors detected in some depl= oyment and interoperability work of this protocol. Please help. >> > >>=20 >> These are really two different things, that you are asking about. >>=20 >> Interoperability implies that independent implementations of the protocol= s are able to interoperate: correctly parse and interpret each other's messa= ges, and "do the right processing" as a consequence. As indicated, and as in= dicated in the shepherd write-up for OLSRv2 prior to publication, several kn= own implementations exist and have demonstrated this through numerous intero= perability tests over the years. >>=20 >> Demonstrated interoperability of independent implementations (the operati= ve word being "independent", as in "developed by different teams/institution= s, without any conferring outside of reading the same specification") really= serve as the litmus test of the quality of a specification, and are - in my= not so humble opinion - indispensable prior to publishing a protocol specif= ication on standards track. I am sure you will agree, the reason for which s= tandards are written is to enable independent implementors to write interope= rable code, so standards need to be written to enable exactly that. >>=20 >> Deployment experiences are hugely dependent on the scenarios that you are= deploying in, specifically (but not exclusively) the L2 you are using. Mobi= lity, topology densities, ..., all play a role here, too. As far as I know, f= or MANETs there are many different scenarios and L2 in use. I know of MANETs= that are deployed over (perfectly reliable, high-capacity) Ethernet point-t= o-point links, and of other MANETs that are deployed over (highly lossy, low= -capacity, time-varying) wireless links -- and, even, MANETs which have both= kinds of links at the same time. >>=20 >> To try to make a general observation that seem commonly (but not universa= lly) valid, the biggest "lesson learned" from deployments probably is, that h= op-count metrics aren't the most appropriate metric to use in many wireless s= cenarios; Henning and Emmanuel's I-D (that was called for, for WG adaptation= recently) is an alternative metric that is based on the deployment experie= nces of Henning and Emmanuel and which - in their deployments, at least, is a= dvantageous. I strongly encourage those efforts, of documenting operational e= xperiences, and which metrics are found to be viable. I know that NRL has be= en successful with different metrics (different from the Henning/Emmanuel pr= oposal, that is) for their scenarios/L2's, and that's wonderful also - their= scenarios and L2's are very different. Indeed, that is the reason why OLSRv= 2 does not recommend a specific metric, but leaves the flexibility for a dep= loyment and L2 to use an appropriate (or, multiple appropriate) metrics. >>=20 >> Best, >>=20 >> Thomas >>=20 >>=20 >> > Best Regards, >> > >> > AB >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-6524DBF2-B893-40CE-B0DC-2227341CE0EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Abdussalam,,

On= 7 mars 2014, at 07:36, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Thomas,

Thanks a lot. &= nbsp;so could I understand that when implementing OLSRv2 and when people gat= hered testing OLSRv2 (as you pictures of gatherings in your presen= tation in MANET WG IETF89) the process of test had no single minor = ;error in coding or error in routing process in that gathering or what w= ere the learning main issues/points developed. Sorry if m= y question was not explained well, 


Interops have as objec= tive to verify interoperability of independent implementations of the same s= pecification - as a way to measure the quality of a specification prior to s= tandardization. That's what a standards developing organization is intereste= d in, and not the quality of code from one organization or another. 

I believe that the OLSR/OLSRv2 interops were successf= ul, in that we had numerous independent and complete implementations partici= pating successfully over the years.

Interops do not= really have as goal to test the ability of an individual or an organization= to write bug-free code, and so it is not really in my place to report if pe= rson X came along with code that segfaulted, or if the code of organization Y= had a memory leak. In fact, I'd probably make myself highly unpopular if I d= id hang out person X or organization Y, by divulging which flaws their code h= ad.

Also, mind you, some of the interops were as mu= ch as 10 years ago....given that, on some days, I have a hard time rememberi= ng what I had for breakfast ;)  I probably would not remember such deta= ils correctly anyways: as they were not relevant to the interop, they were n= ot recorded.

Best,

Thomas<= /div>

AB

On Thu= rsday, March 6, 2014, Thomas Heide Clausen wrote:
Dear Abdussalam,

> On 6 mars 2014, at 23:31, Abdussalam Baryun <abdussalambary= un@gmail.com> wrote:
>
> Hello Thomas,
>
> I asked a question in the last meeting IETF 89 about the tests of OLSRv= 2 and experience as it was presented and mention many tests. I asked just fo= r technical summary, showing advise or possible errors detected in some depl= oyment and interoperability work of this protocol. Please help.
>

These are really two different things, that you are asking about.

Interoperability implies that independent implementations of the protocols a= re able to interoperate: correctly parse and interpret each other's messages= , and "do the right processing" as a consequence. As indicated, and as indic= ated in the shepherd write-up for OLSRv2 prior to publication, several known= implementations exist and have demonstrated this through numerous interoper= ability tests over the years.

Demonstrated interoperability of independent implementations (the operative w= ord being "independent", as in "developed by different teams/institutions, w= ithout any conferring outside of reading the same specification") really ser= ve as the litmus test of the quality of a specification, and are - in my not= so humble opinion - indispensable prior to publishing a protocol specificat= ion on standards track. I am sure you will agree, the reason for which stand= ards are written is to enable independent implementors to write interoperabl= e code, so standards need to be written to enable exactly that.

Deployment experiences are hugely dependent on the scenarios that you are de= ploying in, specifically (but not exclusively) the L2 you are using. Mobilit= y, topology densities, ..., all play a role here, too. As far as I know, for= MANETs there are many different scenarios and L2 in use. I know of MANETs t= hat are deployed over (perfectly reliable, high-capacity) Ethernet point-to-= point links, and of other MANETs that are deployed over (highly lossy, low-c= apacity, time-varying) wireless links -- and, even, MANETs which have both k= inds of links at the same time.

To try to make a general observation that seem commonly (but not universally= ) valid, the biggest "lesson learned" from deployments probably is, that hop= -count metrics aren't the most appropriate metric to use in many wireless sc= enarios; Henning and Emmanuel's I-D (that was called for, for WG adaptation r= ecently) is an alternative metric that  is based on the deployment expe= riences of Henning and Emmanuel and which - in their deployments, at least, i= s advantageous. I strongly encourage those efforts, of documenting operation= al experiences, and which metrics are found to be viable. I know that NRL ha= s been successful with different metrics (different from the Henning/Emmanue= l proposal, that is) for their scenarios/L2's, and that's wonderful also - t= heir scenarios and L2's are very different. Indeed, that is the reason why O= LSRv2 does not recommend a specific metric, but leaves the flexibility for a= deployment and L2 to use an appropriate (or, multiple appropriate) metrics.=

Best,

Thomas


> Best Regards,
>
> AB
>
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-6524DBF2-B893-40CE-B0DC-2227341CE0EB-- From nobody Fri Mar 7 01:08:08 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA7F1A0113 for ; Fri, 7 Mar 2014 01:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LBOKKRIHE0r for ; Fri, 7 Mar 2014 01:08:00 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 94B071A010B for ; Fri, 7 Mar 2014 01:08:00 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id o15so3765651qap.9 for ; Fri, 07 Mar 2014 01:07:56 -0800 (PST) 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=E6Md36U1Kq0QcgORJ2rKgD0NnOF2sR33znl5hlq0igk=; b=ESaQJyoMkRiE8hw7lOWdAD1w1vlwgfvnKOCzxT3v3lvECa7nPSFihFTZKvZRB5+Piy inYzcehRuASJOz02TIZ0tTOeoil1c5080kVLiye6tRyADlilbAkhXAvNOD9ubN8B/aDr ZiVKogJdfZ7NWRMAbyo/r3sTyshmNuB32Bz1e+yzrDFjP6TUdclJFijiKrc2EnvXxqHu lMs24l8+/jo9cDuLwY4qF+rmxCzq9FJ6Di2ljukUYLGHgeM8TO6QzJAo5BHfG0mQ1He1 pxsLUYJKOdFE4AVDvTkFMYvhP3MLc1JB6GwKazDGR7oKLU2JXI1y16sJ7LxBAggYK3gW bb3A== MIME-Version: 1.0 X-Received: by 10.140.47.20 with SMTP id l20mr19204029qga.9.1394183276108; Fri, 07 Mar 2014 01:07:56 -0800 (PST) Received: by 10.224.120.66 with HTTP; Fri, 7 Mar 2014 01:07:55 -0800 (PST) Received: by 10.224.120.66 with HTTP; Fri, 7 Mar 2014 01:07:55 -0800 (PST) In-Reply-To: References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> Date: Fri, 7 Mar 2014 09:07:55 +0000 Message-ID: From: Henning Rogge To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=001a11c14cd2eca0b604f40096d5 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lEr46_MW8ROMu5seRTQU48Wcgtw Cc: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:08:04 -0000 --001a11c14cd2eca0b604f40096d5 Content-Type: text/plain; charset=ISO-8859-1 Abdussalam, I give you an advise and check the difference between the last DYMO draft and the first AODVv2 draft. If you keep your strange opinion about how to deal with reviews about late DYMO drafts then no one can help you. Except maybe the WG chairs... Henning Rogge On Mar 7, 2014 7:53 AM, "Abdussalam Baryun" wrote: > Hi Don, > > I think the issue of not missing messages happens a lot to me with most of > the IETF editors related to I-Ds. The best tool is the ticket tracker, > because discussion messages are some how not focused on the I-D but may go > through theories/imaginations/possibilities/personality/etc. > > When the AODVv2 started -00 with new author team it was not DYMO any > more, and I think that no message has been not replied to since > AODVv2-00 published in March 2013. Yes there was a reminder from > participant on DYMO draft comments, but I am not sure the authors have time > to discuss DYMO document after it mature and the WG dropping it and > starting adopting another document which is AODVv2. > > I recommend the WG to focus on active documents so we can progress our > work. Otherwise we will not have time. > > AB > > On Thursday, March 6, 2014, Don Sturek wrote: > >> Hi Charlie, >> >> It would be worth (going forward) addressing issues as they come up on >> the reflector rather than having to mine these topics out of the reflector >> archives months later. >> >> Most folks have limited time to spend reviewing drafts. Ignoring >> comments for several months does not help resolving these issues since in >> many cases the comment and context is lost after a long period of time. >> >> Don >> >> >> From: "Charles E. Perkins" >> Organization: Blue Skies >> Date: Thursday, March 6, 2014 1:26 PM >> To: Abdussalam Baryun >> Cc: Mobile Ad Hoc Networks mailing list >> Subject: Re: [manet] Remaining issues affecting the AODVv2 specification >> >> >> Hello Abdussalam, >> >> Before the draft goes to last call, we need to resolve the >> open issues that were posted to the mailing list. When I >> mentioned that the earlier issues on the issue tracker had >> been resolved, that did not include the other issues that >> were not posted to the issue tracker. As mentioned in my >> previous email, I will take care of posting them to the tracker >> so that the resolution process will be easier to follow. >> >> Regards, >> Charlie P. >> >> On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: >> >> >> Ok so I understand from your message below that authors confirm that the >> draft is ready complete for WG to review and comment their open issues. >> >> AB >> >> On Thursday, March 6, 2014, Charles E. Perkins wrote: >> >>> >>> Hello Abdussalam, >>> >>> Actually, all of the issues were resolved. Then, apparently, the >>> issues page crashed, and some recent updates to the issues were >>> lost. However, they were sent to the mailing list, and so are >>> recoverable, with a nontrivial amount of work amounting to >>> an archaeological expedition through the mailing list archives. >>> >>> I wanted to have time to do this, but so far have not. If anyone >>> wants to volunteer to recover the issue-tracker updates from the >>> mailing list, that would be terrific. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>> >>> Hi Charles, >>> >>> I just had before a comment on the open tickets, were they all >>> closed, because I think may be open. Seems most MANET WG don't care about >>> tickets but I like to track and I remember that the AD did mention it's >>> importance. >>> >>> For me I will review new draft and comment, but if the authors have no >>> more pending issues to update, please confirm (sorry that I was not able to >>> remember if there are confirmation from authors that draft is ready or not, >>> also need their confirm of final points of open issues for next draft if >>> not resolved). >>> >>> Best Regards >>> >>> AB >>> >>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>> >>>> Hello folks, >>>> >>>> Part of the job of finishing the AODVv2 specification will be to comb >>>> the mailing list for issues that are still not resolved. If there are >>>> any specific issues that have not been gotten proper attention, I hope >>>> to find them -- but if anyone would like to help by bringing them >>>> up here on the mailing list, that will be appreciated. >>>> >>>> -- >>>> Regards, >>>> Charlie P. >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> >> -- >> 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 > > --001a11c14cd2eca0b604f40096d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Abdussalam,

I give you an advise and check the difference between the la= st DYMO draft and the first AODVv2 draft. If you keep your strange opinion = about how to deal with reviews about late DYMO drafts then no one can help = you.

Except maybe the WG chairs...

Henning Rogge

On Mar 7, 2014 7:53 AM, "Abdussalam Baryun&= quot; <abdussalambaryun@gm= ail.com> wrote:
Hi Don,

I think the issue of not missing messages happen= s a lot to me with=A0most of the IETF editors related to I-Ds. The best too= l is the ticket tracker, because discussion messages are some how not focus= ed on the I-D but may go through theories/imaginations/possibilities/person= ality/etc.=A0

When the AODVv2 started -00 with new author team=A0it w= as not DYMO any more,=A0and I think that no message has been not replied to= since AODVv2-00=A0published in March 2013. Yes there was a reminder from p= articipant on DYMO draft comments,=A0but I am not sure the authors have tim= e to=A0discuss DYMO=A0document after it mature and the WG dropping it and s= tarting adopting=A0another document which is AODVv2.=A0

I recommend the WG=A0to focus on active documents so we= can progress our work. Otherwise we will not have time.=A0

<= /div>AB

On Thursday, March 6, 2014, Don Sturek wrote:
Hi Charlie,

It would be worth (going forward) addressing issues as they come up on= the reflector rather than having to mine these topics out of the reflector= archives months later.

Most folks have limited ti= me to spend reviewing drafts. =A0Ignoring comments for several months does = not help resolving these issues since in many cases the comment and context= is lost after a long period of time.

Don


From: "Charles E. Perkins&quo= t; <charliep@computer.org>
Organization: Blue Skies
Date: Thursday, March 6, 2014 1:26= PM
To: Abdussalam Baryun <<= a>abdussalambaryun@gmail.com>
Cc: Mobile Ad Hoc Networks mailing= list <manet@ietf.org>
Sub= ject: Re: [manet] Remaining issues affecting the AODVv2 specificati= on

=20 =20 =20

Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.=A0 When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.=A0=A0 As mentioned in my
previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below=A0that authors confirm that the draft is ready complete=A0for WG to review and comment their open=A0issues.=A0

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.=A0 Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.=A0 However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.=A0 If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open=A0tickets,=A0wer= e they all closed,=A0because I think may be open. Seems most=A0MANET WG don't care=A0about tickets but I like t= o track=A0and I remember that the AD did mention it's importance.=A0

For me I will review new draft and comment, but if the authors have no more pending=A0issues to update,=A0please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need=A0their confirm of=A0final points of open issues for next draft if not resolved).=A0

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved. =A0If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.
--
Regards,
Charlie P.

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

--=20
Regards,
Charlie P.

--=20
Regards,
Charlie P.
_______________________________________________ manet mailing list manet@ietf.org h= ttps://www.ietf.org/mailman/listinfo/manet

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

--001a11c14cd2eca0b604f40096d5-- From nobody Fri Mar 7 01:23:27 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15671A017B for ; Fri, 7 Mar 2014 01:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0E2pBHRzCO2 for ; Fri, 7 Mar 2014 01:23:23 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) by ietfa.amsl.com (Postfix) with ESMTP id A81E71A012B for ; Fri, 7 Mar 2014 01:23:23 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id 142so10025116ykq.0 for ; Fri, 07 Mar 2014 01:23:19 -0800 (PST) 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=AeXoYei4BVLHTWoP5RBPvhYVuQgakS1yrJEyCpeDMr4=; b=QYeScHWpWsIdNYepyx7rkaNIeGZYzCmwjiG7/caQJZG0xR7UixHMOmTlmZYjolmOuX /v/VtlF55aDNiZWExE8tbFxxl9rFmCfcOdVHVXmsLwwUGePqRJCVfXj9tHW4CdCGyB0c cfj3UnSNzpnqbzaQHdxwH90fYooujkhNS5536GXxfAwgvGtHCvA583iGaHjbe14pdC+e cF9VTyl7vvswUZ2vv4jQK2o/Zom8WPsHLKz7UsTsym2sQ/YzCD1tnE+YDn/W0Ob7OFiC ZbrF2HXhH5aKR6PQUtvKMdYScmRIJTKW9GlzavdiTZWoPcBGa2JSa18/womRZ2imqZfW HRUg== MIME-Version: 1.0 X-Received: by 10.236.19.162 with SMTP id n22mr20386397yhn.23.1394184199357; Fri, 07 Mar 2014 01:23:19 -0800 (PST) Received: by 10.170.202.7 with HTTP; Fri, 7 Mar 2014 01:23:19 -0800 (PST) In-Reply-To: <1C91EFF0-5BA8-4371-AC9A-9C7912B6F687@thomasclausen.org> References: <3FF22EA3-280E-40FE-9E5C-3BD425F18FCF@thomasclausen.org> <1C91EFF0-5BA8-4371-AC9A-9C7912B6F687@thomasclausen.org> Date: Fri, 7 Mar 2014 10:23:19 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=089e0160d0b6f44bac04f400cd73 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ORt0Hdd-BokTh6I04CKSyLkJ-9A Cc: manet Subject: Re: [manet] OLSRv2 interoperable experience X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:23:26 -0000 --089e0160d0b6f44bac04f400cd73 Content-Type: text/plain; charset=ISO-8859-1 Thanks Thomas, I was not interested in names, but experiencing OLSRv2. I just needed an answer from you because the gathering was mentioned in IETF89 and I did not benefit from knowing that there was such gathering. Now I understand that there was no technical summary published for OLSRv2 of such gathering. AB On Friday, March 7, 2014, Thomas Heide Clausen wrote: > Dear Abdussalam,, > > On 7 mars 2014, at 07:36, Abdussalam Baryun > > wrote: > > Hi Thomas, > > Thanks a lot. so could I understand that when implementing OLSRv2 and > when people gathered testing OLSRv2 (as you pictures of gatherings in > your presentation in MANET WG IETF89) the process of test had no single > minor error in coding or error in routing process in that gathering or what > were the learning main issues/points developed. Sorry if my question > was not explained well, > > > Interops have as objective to verify interoperability of independent > implementations of the same specification - as a way to measure the quality > of a specification prior to standardization. That's what a standards > developing organization is interested in, and not the quality of code from > one organization or another. > > I believe that the OLSR/OLSRv2 interops were successful, in that we had > numerous independent and complete implementations participating > successfully over the years. > > Interops do not really have as goal to test the ability of an individual > or an organization to write bug-free code, and so it is not really in my > place to report if person X came along with code that segfaulted, or if the > code of organization Y had a memory leak. In fact, I'd probably make myself > highly unpopular if I did hang out person X or organization Y, by divulging > which flaws their code had. > > Also, mind you, some of the interops were as much as 10 years ago....given > that, on some days, I have a hard time remembering what I had for breakfast > ;) I probably would not remember such details correctly anyways: as they > were not relevant to the interop, they were not recorded. > > Best, > > Thomas > > AB > > On Thursday, March 6, 2014, Thomas Heide Clausen wrote: > >> Dear Abdussalam, >> >> > On 6 mars 2014, at 23:31, Abdussalam Baryun >> wrote: >> > >> > Hello Thomas, >> > >> > I asked a question in the last meeting IETF 89 about the tests of >> OLSRv2 and experience as it was presented and mention many tests. I asked >> just for technical summary, showing advise or possible errors detected in >> some deployment and interoperability work of this protocol. Please help. >> > >> >> These are really two different things, that you are asking about. >> >> Interoperability implies that independent implementations of the >> protocols are able to interoperate: correctly parse and interpret each >> other's messages, and "do the right processing" as a consequence. As >> indicated, and as indicated in the shepherd write-up for OLSRv2 prior to >> publication, several known implementations exist and have demonstrated this >> through numerous interoperability tests over the years. >> >> Demonstrated interoperability of independent implementations (the >> operative word being "independent", as in "developed by different >> teams/institutions, without any conferring outside of reading the same >> specification") really serve as the litmus test of the quality of a >> specification, and are - in my not so humble opinion - indispensable prior >> to publishing a protocol specification on standards track. I am sure you >> will agree, the reason for which standards are written is to enable >> independent implementors to write interoperable code, so standards need to >> be written to enable exactly that. >> >> Deployment experiences are hugely dependent on the scenarios that you are >> deploying in, specifically (but not exclusively) the L2 you are using. >> Mobility, topology densities, ..., all play a role here, too. As far as I >> know, for MANETs there are many different scenarios and L2 in use. I know >> of MANETs that are deployed over (perfectly reliable, high-capacity) >> Ethernet point-to-point links, and of other MANETs that are deployed over >> (highly lossy, low-capacity, time-varying) wireless links -- and, even, >> MANETs which have both kinds of links at the same time. >> >> To try to make a general observation that seem commonly (but not >> universally) valid, the biggest "lesson learned" from deployments probably >> is, that hop-count metrics aren't the most appropriate metric to use in >> many wireless scenarios; Henning and Emmanuel's I-D (that was called for, >> for WG adaptation recently) is an alternative metric that is based on the >> deployment experiences of Henning and Emmanuel and which - in their >> deployments, at least, is advantageous. I strongly encourage those efforts, >> of documenting operational experiences, and which metrics are found to be >> viable. I know that NRL has been successful with different metrics >> (different from the Henning/Emmanuel proposal, that is) for their >> scenarios/L2's, and that's wonderful also - their scenarios and L2's are >> very different. Indeed, that is the reason why OLSRv2 does not recommend a >> specific metric, but leaves the flexibility for a deployment and L2 to use >> an appropriate (or, multiple appropriate) metrics. >> >> Best, >> >> Thomas >> >> >> > Best Regards, >> > >> > AB >> > >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --089e0160d0b6f44bac04f400cd73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Thomas, I=A0was not interested in names, but experiencing OLSRv2= .=A0I just needed an answer from you because the gathering was mentioned in= IETF89=A0and I did not benefit from knowing that there was such=A0gatherin= g. Now=A0I understand that there was no technical summary published=A0for O= LSRv2=A0of such gathering.=A0

AB

On Friday, March 7, 2014, Thomas Heide Clau= sen wrote:
Dear A= bdussalam,,

On 7 mars 2014, at 07:36, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Thomas,

Thanks a lot.=A0=A0so could I understand= that when implementing OLSRv2 and when people gathered testing OLSRv2 (as = you pictures of gatherings=A0in your=A0presentation in MANET WG=A0IETF89) t= he process of test had no single minor=A0error in coding or error in routin= g process in that gathering=A0or what were=A0the learning main=A0issues/poi= nts=A0developed.=A0Sorry if my question was=A0not explained well,=A0


Interops have as obje= ctive to verify interoperability of independent implementations of the same= specification - as a way to measure the quality of a specification prior t= o standardization. That's what a standards developing organization is i= nterested in, and not the quality of code from one organization or another.= =A0

I believe that the OLSR/OLSRv2 interops were successful= , in that we had numerous independent and complete implementations particip= ating successfully over the years.

Interops do not= really have as goal to test the ability of an individual or an organizatio= n to write bug-free code, and so it is not really in my place to report if = person X came along with code that segfaulted, or if the code of organizati= on Y had a memory leak. In fact, I'd probably make myself highly unpopu= lar if I did hang out person X or organization Y, by divulging which flaws = their code had.

Also, mind you, some of the interops were as much as 10= years ago....given that, on some days, I have a hard time remembering what= I had for breakfast ;) =A0I probably would not remember such details corre= ctly anyways: as they were not relevant to the interop, they were not recor= ded.

Best,

Thomas

AB

On Thursday, March 6, = 2014, Thomas Heide Clausen wrote:
Dear Abdussalam,

> On 6 mars 2014, at 23:31, Abdussalam Baryun <abdussalambaryun@gm= ail.com> wrote:
>
> Hello Thomas,
>
> I asked a question in the last meeting IETF 89 about the tests of OLSR= v2 and experience as it was presented and mention many tests. I asked just = for technical summary, showing advise or possible errors detected in some d= eployment and interoperability work of this protocol. Please help.
>

These are really two different things, that you are asking about.

Interoperability implies that independent implementations of the protocols = are able to interoperate: correctly parse and interpret each other's me= ssages, and "do the right processing" as a consequence. As indica= ted, and as indicated in the shepherd write-up for OLSRv2 prior to publicat= ion, several known implementations exist and have demonstrated this through= numerous interoperability tests over the years.

Demonstrated interoperability of independent implementations (the operative= word being "independent", as in "developed by different tea= ms/institutions, without any conferring outside of reading the same specifi= cation") really serve as the litmus test of the quality of a specifica= tion, and are - in my not so humble opinion - indispensable prior to publis= hing a protocol specification on standards track. I am sure you will agree,= the reason for which standards are written is to enable independent implem= entors to write interoperable code, so standards need to be written to enab= le exactly that.

Deployment experiences are hugely dependent on the scenarios that you are d= eploying in, specifically (but not exclusively) the L2 you are using. Mobil= ity, topology densities, ..., all play a role here, too. As far as I know, = for MANETs there are many different scenarios and L2 in use. I know of MANE= Ts that are deployed over (perfectly reliable, high-capacity) Ethernet poin= t-to-point links, and of other MANETs that are deployed over (highly lossy,= low-capacity, time-varying) wireless links -- and, even, MANETs which have= both kinds of links at the same time.

To try to make a general observation that seem commonly (but not universall= y) valid, the biggest "lesson learned" from deployments probably = is, that hop-count metrics aren't the most appropriate metric to use in= many wireless scenarios; Henning and Emmanuel's I-D (that was called f= or, for WG adaptation recently) is an alternative metric that =A0is based o= n the deployment experiences of Henning and Emmanuel and which - in their d= eployments, at least, is advantageous. I strongly encourage those efforts, = of documenting operational experiences, and which metrics are found to be v= iable. I know that NRL has been successful with different metrics (differen= t from the Henning/Emmanuel proposal, that is) for their scenarios/L2's= , and that's wonderful also - their scenarios and L2's are very dif= ferent. Indeed, that is the reason why OLSRv2 does not recommend a specific= metric, but leaves the flexibility for a deployment and L2 to use an appro= priate (or, multiple appropriate) metrics.

Best,

Thomas


> Best Regards,
>
> AB
>
___________________= ____________________________
manet mailing list
<= span>manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--089e0160d0b6f44bac04f400cd73-- From nobody Fri Mar 7 01:24:27 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1131A0273 for ; Fri, 7 Mar 2014 01:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J81urTFd9sk4 for ; Fri, 7 Mar 2014 01:24:20 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC671A01AE for ; Fri, 7 Mar 2014 01:24:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A2F441C20541; Fri, 7 Mar 2014 01:24:16 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0AA9F1C20540; Fri, 7 Mar 2014 01:24:16 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-B11A9810-2D43-4A22-BF1B-7273B48F0669 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Fri, 7 Mar 2014 10:24:16 +0100 Content-Transfer-Encoding: 7bit Message-Id: <81CA23AB-EAA1-4343-9E69-E123684B43EF@thomasclausen.org> References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> To: Henning Rogge Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yoCbTguk_gF4Zi866GGgCCt41_4 Cc: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:24:23 -0000 --Apple-Mail-B11A9810-2D43-4A22-BF1B-7273B48F0669 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear Abdussalam, > On 7 mars 2014, at 10:07, Henning Rogge wrote: >=20 > Abdussalam, >=20 > I give you an advise and check the difference between the last DYMO draft a= nd the first AODVv2 draft. >=20 Abdussalam, in order to help you be more autonomous in such matters, let me t= ry to provide you with the method that I (and, I guess, Henning, and others)= use to track such changes. 1) Go to the datatracker for this document: http://tools.ietf.org/html/draft-ietf-manet-aodvv2 2) Click on the link 00, which takes you here: http://tools.ietf.org/html/draft-ietf-manet-aodvv2-00 3) hitting "Diff1" gets you: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf= -manet-aodvv2-00.txt There're two points here: o The IETF has recorded that this document is the successor o= f DYMO, and o The differences between DYMO and this document is non-exist= ing, except for the title and other document header metadata. Also, not only are these two documents mostly identical, you will also notic= e that so are some of the authors. Also, you will see that on the datatracker, it is indicated that this docume= nt replaces dymo: https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/ So, unequivocally, the two documents are the same. And, the latest -03 actually is remarkably (and disappointingly) identical t= o the latest DYMO document - which is exactly the problem that the WG should= worry about, that input given has not been reflected by the authors. Best, Thomas > If you keep your strange opinion about how to deal with reviews about late= DYMO drafts then no one can help you. >=20 > Except maybe the WG chairs... >=20 > Henning Rogge >=20 >> On Mar 7, 2014 7:53 AM, "Abdussalam Baryun" w= rote: >> Hi Don, >>=20 >> I think the issue of not missing messages happens a lot to me with most o= f the IETF editors related to I-Ds. The best tool is the ticket tracker, bec= ause discussion messages are some how not focused on the I-D but may go thro= ugh theories/imaginations/possibilities/personality/etc.=20 >>=20 >> When the AODVv2 started -00 with new author team it was not DYMO any more= , and I think that no message has been not replied to since AODVv2-00 publis= hed in March 2013. Yes there was a reminder from participant on DYMO draft c= omments, but I am not sure the authors have time to discuss DYMO document af= ter it mature and the WG dropping it and starting adopting another document w= hich is AODVv2.=20 >>=20 >> I recommend the WG to focus on active documents so we can progress our wo= rk. Otherwise we will not have time.=20 >>=20 >> AB >>=20 >>> On Thursday, March 6, 2014, Don Sturek wrote: >>> Hi Charlie, >>>=20 >>> It would be worth (going forward) addressing issues as they come up on t= he reflector rather than having to mine these topics out of the reflector ar= chives months later. >>>=20 >>> Most folks have limited time to spend reviewing drafts. Ignoring commen= ts for several months does not help resolving these issues since in many cas= es the comment and context is lost after a long period of time. >>>=20 >>> Don >>>=20 >>>=20 >>> From: "Charles E. Perkins" >>> Organization: Blue Skies >>> Date: Thursday, March 6, 2014 1:26 PM >>> To: Abdussalam Baryun >>> Cc: Mobile Ad Hoc Networks mailing list >>> Subject: Re: [manet] Remaining issues affecting the AODVv2 specification= >>>=20 >>>=20 >>> Hello Abdussalam, >>>=20 >>> Before the draft goes to last call, we need to resolve the >>> open issues that were posted to the mailing list. When I >>> mentioned that the earlier issues on the issue tracker had >>> been resolved, that did not include the other issues that >>> were not posted to the issue tracker. As mentioned in my >>> previous email, I will take care of posting them to the tracker >>> so that the resolution process will be easier to follow. >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>>> On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: >>>>=20 >>>> Ok so I understand from your message below that authors confirm that th= e draft is ready complete for WG to review and comment their open issues.=20= >>>>=20 >>>> AB >>>>=20 >>>>> On Thursday, March 6, 2014, Charles E. Perkins wrote: >>>>>=20 >>>>> Hello Abdussalam, >>>>>=20 >>>>> Actually, all of the issues were resolved. Then, apparently, the >>>>> issues page crashed, and some recent updates to the issues were >>>>> lost. However, they were sent to the mailing list, and so are >>>>> recoverable, with a nontrivial amount of work amounting to >>>>> an archaeological expedition through the mailing list archives. >>>>>=20 >>>>> I wanted to have time to do this, but so far have not. If anyone >>>>> wants to volunteer to recover the issue-tracker updates from the >>>>> mailing list, that would be terrific. >>>>>=20 >>>>> Regards, >>>>> Charlie P. >>>>>=20 >>>>>=20 >>>>>> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>>>>> Hi Charles, >>>>>>=20 >>>>>> I just had before a comment on the open tickets, were they all closed= , because I think may be open. Seems most MANET WG don't care about tickets b= ut I like to track and I remember that the AD did mention it's importance.=20= >>>>>>=20 >>>>>> For me I will review new draft and comment, but if the authors have n= o more pending issues to update, please confirm (sorry that I was not able t= o remember if there are confirmation from authors that draft is ready or not= , also need their confirm of final points of open issues for next draft if n= ot resolved).=20 >>>>>>=20 >>>>>> Best Regards >>>>>>=20 >>>>>> AB >>>>>>=20 >>>>>>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>>>>>> Hello folks, >>>>>>>=20 >>>>>>> Part of the job of finishing the AODVv2 specification will be to com= b >>>>>>> the mailing list for issues that are still not resolved. If there a= re >>>>>>> any specific issues that have not been gotten proper attention, I ho= pe >>>>>>> to find them -- but if anyone would like to help by bringing them >>>>>>> up here on the mailing list, that will be appreciated. >>>>>>>=20 >>>>>>> --=20 >>>>>>> Regards, >>>>>>> Charlie P. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> --=20 >>>>> Regards, >>>>> Charlie P. >>>=20 >>> --=20 >>> Regards, >>> Charlie P. >>> _______________________________________________ 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-B11A9810-2D43-4A22-BF1B-7273B48F0669 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Abdussalam,
On 7 mars 2014, at 10:= 07, Henning Rogge <hrogge@gmail.com> wrote:





2) Click on the link 00, which takes you here:


3= ) hitting "Diff1" gets you:


There'r= e two points here:

o The IETF has recorded that this document is t= he successor of DYMO, and
o The differences between DYMO and this document is no= n-existing, except for
the title and other document header metadata= .

A= lso, not only are these two documents mostly identical, you will also notice= that so are some of the authors.

Also, you= will see that on the datatracker, it is indicated that this document replac= es dymo:


So,= unequivocally, the two documents are the same.

And, the latest -03 actually is remarkably (and disappointingly) identi= cal to the latest DYMO document - which is exactly the problem that the WG s= hould worry about, that input given has not been reflected by the authors.

Best,

Thomas

If you k= eep your strange opinion about how to deal with reviews about late DYMO draf= ts then no one can help you.

Except maybe the WG chairs...

Henning Rogge

On Mar 7, 2014 7:53 AM, "Abdussalam Baryun" <<= a href=3D"mailto:abdussalambaryun@gmail.com">abdussalambaryun@gmail.com&= gt; wrote:
Hi Don,

I think the issue of not missing messages happens= a lot to me with most of the IETF editors related to I-Ds. The best to= ol is the ticket tracker, because discussion messages are some how not focus= ed on the I-D but may go through theories/imaginations/possibilities/persona= lity/etc. 

When the AODVv2 started -00 with new author team it= was not DYMO any more, and I think that no message has been not replie= d to since AODVv2-00 published in March 2013. Yes there was a reminder f= rom participant on DYMO draft comments, but I am not sure the authors h= ave time to discuss DYMO document after it mature and the WG dropp= ing it and starting adopting another document which is AODVv2. 

I recommend the WG to focus on active documents so w= e can progress our work. Otherwise we will not have time. 
AB

On Thursday, March 6, 2014, Don Sturek wrote:
Hi Charlie,

It would be worth (going forward) addressing issues as they come up on t= he reflector rather than having to mine these topics out of the reflector ar= chives months later.

Most folks have limited time t= o spend reviewing drafts.  Ignoring comments for several months does no= t help resolving these issues since in many cases the comment and context is= lost after a long period of time.

Don


From: "Charles E. Perkins" <c= harliep@computer.org>
Organizatio= n: Blue Skies
Date: Thursday, March 6, 2014 1:26 P= M
To: Abdussalam Baryun <a= bdussalambaryun@gmail.com>
Cc: Mobile Ad Hoc Networks mailing l= ist <manet@ietf.org>
Subjec= t: Re: [manet] Remaining issues affecting the AODVv2 specification

=20 =20 =20

Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my
= previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets,&nbs= p;were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like t= o track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of = final points of open issues for next draft if not resolved). =

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.
=
--
Regards,
Charlie P.

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

--=20
Regards,
Charlie P.

--=20
Regards,
Charlie P.
_______________________________________________ manet mailing list manet@ietf.org ht= tps://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-B11A9810-2D43-4A22-BF1B-7273B48F0669-- From nobody Fri Mar 7 01:28:11 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2541A006F for ; Fri, 7 Mar 2014 01:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91-cBPvYUTyy for ; Fri, 7 Mar 2014 01:28:07 -0800 (PST) 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 B48461A0164 for ; Fri, 7 Mar 2014 01:28:06 -0800 (PST) Received: from [31.133.164.91] by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WLr4T-0002v0-Gn; Fri, 07 Mar 2014 04:28:01 -0500 Message-ID: <5319911F.2090001@computer.org> Date: Fri, 07 Mar 2014 01:27:59 -0800 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Henning Rogge , Abdussalam Baryun References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000708020808010002020005" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86c1ab11ee84affe8483d6d50fdedf49d1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.164.91 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/AZdF8PodxjMWP3vIOirtzUKmdmQ Cc: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:28:10 -0000 This is a multi-part message in MIME format. --------------000708020808010002020005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello folks, AODVv2 has evolved significantly since it was renamed from DYMO, but all of the comments have to be considered for current relevance. If any remain unresolved, then the discussion will, I expect, produce useful ideas and text to be used in future revisions of AODVv2. Regards, Charlie P. On 3/7/2014 1:07 AM, Henning Rogge wrote: > > Abdussalam, > > I give you an advise and check the difference between the last DYMO > draft and the first AODVv2 draft. If you keep your strange opinion > about how to deal with reviews about late DYMO drafts then no one can > help you. > > Except maybe the WG chairs... > > Henning Rogge > > On Mar 7, 2014 7:53 AM, "Abdussalam Baryun" > > wrote: > > Hi Don, > > I think the issue of not missing messages happens a lot to me > with most of the IETF editors related to I-Ds. The best tool is > the ticket tracker, because discussion messages are some how not > focused on the I-D but may go through > theories/imaginations/possibilities/personality/etc. > > When the AODVv2 started -00 with new author team it was not DYMO > any more, and I think that no message has been not replied to > since AODVv2-00 published in March 2013. Yes there was a reminder > from participant on DYMO draft comments, but I am not sure the > authors have time to discuss DYMO document after it mature and the > WG dropping it and starting adopting another document which is > AODVv2. > > I recommend the WG to focus on active documents so we can progress > our work. Otherwise we will not have time. > > AB > > On Thursday, March 6, 2014, Don Sturek wrote: > > Hi Charlie, > > It would be worth (going forward) addressing issues as they > come up on the reflector rather than having to mine these > topics out of the reflector archives months later. > > Most folks have limited time to spend reviewing drafts. > Ignoring comments for several months does not help resolving > these issues since in many cases the comment and context is > lost after a long period of time. > > Don > > > From: "Charles E. Perkins" > Organization: Blue Skies > Date: Thursday, March 6, 2014 1:26 PM > To: Abdussalam Baryun > Cc: Mobile Ad Hoc Networks mailing list > Subject: Re: [manet] Remaining issues affecting the AODVv2 > specification > > > Hello Abdussalam, > > Before the draft goes to last call, we need to resolve the > open issues that were posted to the mailing list. When I > mentioned that the earlier issues on the issue tracker had > been resolved, that did not include the other issues that > were not posted to the issue tracker. As mentioned in my > previous email, I will take care of posting them to the tracker > so that the resolution process will be easier to follow. > > Regards, > Charlie P. > > On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: >> >> Ok so I understand from your message below that authors >> confirm that the draft is ready complete for WG to review and >> comment their open issues. >> >> AB >> >> On Thursday, March 6, 2014, Charles E. Perkins wrote: >> >> >> Hello Abdussalam, >> >> Actually, all of the issues were resolved. Then, >> apparently, the >> issues page crashed, and some recent updates to the >> issues were >> lost. However, they were sent to the mailing list, and >> so are >> recoverable, with a nontrivial amount of work amounting to >> an archaeological expedition through the mailing list >> archives. >> >> I wanted to have time to do this, but so far have not. >> If anyone >> wants to volunteer to recover the issue-tracker updates >> from the >> mailing list, that would be terrific. >> >> Regards, >> Charlie P. >> >> >> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>> Hi Charles, >>> >>> I just had before a comment on the open tickets, were >>> they all closed, because I think may be open. Seems >>> most MANET WG don't care about tickets but I like to >>> track and I remember that the AD did mention it's >>> importance. >>> >>> For me I will review new draft and comment, but if the >>> authors have no more pending issues to update, please >>> confirm (sorry that I was not able to remember if there >>> are confirmation from authors that draft is ready or >>> not, also need their confirm of final points of open >>> issues for next draft if not resolved). >>> >>> Best Regards >>> >>> AB >>> >>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>> >>> Hello folks, >>> >>> Part of the job of finishing the AODVv2 >>> specification will be to comb >>> the mailing list for issues that are still not >>> resolved. If there are >>> any specific issues that have not been gotten proper >>> attention, I hope >>> to find them -- but if anyone would like to help by >>> bringing them >>> up here on the mailing list, that will be appreciated. >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> -- >> Regards, >> Charlie P. >> > > -- > 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 > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------000708020808010002020005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello folks,

AODVv2 has evolved significantly since it was renamed
from DYMO, but all of the comments have to be considered
for current relevance.  If any remain unresolved, then the
discussion will, I expect, produce useful ideas and text to
be used in future revisions of AODVv2.

Regards,
Charlie P.

On 3/7/2014 1:07 AM, Henning Rogge wrote:

Abdussalam,

I give you an advise and check the difference between the last DYMO draft and the first AODVv2 draft. If you keep your strange opinion about how to deal with reviews about late DYMO drafts then no one can help you.

Except maybe the WG chairs...

Henning Rogge

On Mar 7, 2014 7:53 AM, "Abdussalam Baryun" <abdussalambaryun@gmail.com> wrote:
Hi Don,

I think the issue of not missing messages happens a lot to me with most of the IETF editors related to I-Ds. The best tool is the ticket tracker, because discussion messages are some how not focused on the I-D but may go through theories/imaginations/possibilities/personality/etc. 

When the AODVv2 started -00 with new author team it was not DYMO any more, and I think that no message has been not replied to since AODVv2-00 published in March 2013. Yes there was a reminder from participant on DYMO draft comments, but I am not sure the authors have time to discuss DYMO document after it mature and the WG dropping it and starting adopting another document which is AODVv2. 

I recommend the WG to focus on active documents so we can progress our work. Otherwise we will not have time. 

AB

On Thursday, March 6, 2014, Don Sturek wrote:
Hi Charlie,

It would be worth (going forward) addressing issues as they come up on the reflector rather than having to mine these topics out of the reflector archives months later.

Most folks have limited time to spend reviewing drafts.  Ignoring comments for several months does not help resolving these issues since in many cases the comment and context is lost after a long period of time.

Don


From: "Charles E. Perkins" <charliep@computer.org>
Organization: Blue Skies
Date: Thursday, March 6, 2014 1:26 PM
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: Re: [manet] Remaining issues affecting the AODVv2 specification


Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my
previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved). 

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.

-- 
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



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



-- 
Regards,
Charlie P.
--------------000708020808010002020005-- From nobody Fri Mar 7 01:29:09 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BC41A0286 for ; Fri, 7 Mar 2014 01:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h18zA6FOMlf6 for ; Fri, 7 Mar 2014 01:29:04 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id DA12D1A0175 for ; Fri, 7 Mar 2014 01:29:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 050831D89DA; Fri, 7 Mar 2014 01:29:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 461091C04AB; Fri, 7 Mar 2014 01:29:00 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-9F070633-F32E-44CB-AC1D-978AA2EF6D48 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Fri, 7 Mar 2014 10:29:01 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4FA6ACEA-E511-47B9-BC70-DC5C8B63AC01@thomasclausen.org> References: <3FF22EA3-280E-40FE-9E5C-3BD425F18FCF@thomasclausen.org> <1C91EFF0-5BA8-4371-AC9A-9C7912B6F687@thomasclausen.org> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tBF4AT8TNEDnXo1FNchodHI51Ko Cc: manet Subject: Re: [manet] OLSRv2 interoperable experience X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:29:08 -0000 --Apple-Mail-9F070633-F32E-44CB-AC1D-978AA2EF6D48 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear Abdussalam, Have you tried googeling for OLSR Interop? Also, we have (when found appropriate by the chairs) both advertised these e= vents in advance to the WG, and reported back. Looking through the minutes a= nd proceedings from previous IETF meetings should provide you with such info= rmation. Of course, the very best plan would be for you to implement OLSRv2 yourself,= so that you would have a reason for participating in a future such event. D= o let us know, if you go down that path, when you have running code? Best, Thomas Sent from my iPad > On 7 mars 2014, at 10:23, Abdussalam Baryun w= rote: >=20 >=20 > Thanks Thomas, I was not interested in names, but experiencing OLSRv2. I j= ust needed an answer from you because the gathering was mentioned in IETF89 a= nd I did not benefit from knowing that there was such gathering. Now I under= stand that there was no technical summary published for OLSRv2 of such gathe= ring.=20 >=20 > AB >=20 >> On Friday, March 7, 2014, Thomas Heide Clausen wrote: >> Dear Abdussalam,, >>=20 >>> On 7 mars 2014, at 07:36, Abdussalam Baryun = wrote: >>>=20 >>> Hi Thomas, >>>=20 >>> Thanks a lot. so could I understand that when implementing OLSRv2 and w= hen people gathered testing OLSRv2 (as you pictures of gatherings in your pr= esentation in MANET WG IETF89) the process of test had no single minor error= in coding or error in routing process in that gathering or what were the le= arning main issues/points developed. Sorry if my question was not explained w= ell,=20 >>>=20 >>=20 >> Interops have as objective to verify interoperability of independent impl= ementations of the same specification - as a way to measure the quality of a= specification prior to standardization. That's what a standards developing o= rganization is interested in, and not the quality of code from one organizat= ion or another.=20 >>=20 >> I believe that the OLSR/OLSRv2 interops were successful, in that we had n= umerous independent and complete implementations participating successfully o= ver the years. >>=20 >> Interops do not really have as goal to test the ability of an individual o= r an organization to write bug-free code, and so it is not really in my plac= e to report if person X came along with code that segfaulted, or if the code= of organization Y had a memory leak. In fact, I'd probably make myself high= ly unpopular if I did hang out person X or organization Y, by divulging whic= h flaws their code had. >>=20 >> Also, mind you, some of the interops were as much as 10 years ago....give= n that, on some days, I have a hard time remembering what I had for breakfas= t ;) I probably would not remember such details correctly anyways: as they w= ere not relevant to the interop, they were not recorded. >>=20 >> Best, >>=20 >> Thomas >>=20 >>> AB >>>=20 >>>> On Thursday, March 6, 2014, Thomas Heide Clausen wrote: >>>> Dear Abdussalam, >>>>=20 >>>> > On 6 mars 2014, at 23:31, Abdussalam Baryun wrote: >>>> > >>>> > Hello Thomas, >>>> > >>>> > I asked a question in the last meeting IETF 89 about the tests of OLS= Rv2 and experience as it was presented and mention many tests. I asked just f= or technical summary, showing advise or possible errors detected in some dep= loyment and interoperability work of this protocol. Please help. >>>> > >>>>=20 >>>> These are really two different things, that you are asking about. >>>>=20 >>>> Interoperability implies that independent implementations of the protoc= ols are able to interoperate: correctly parse and interpret each other's mes= sages, and "do the right processing" as a consequence. As indicated, and as i= ndicated in the shepherd write-up for OLSRv2 prior to publication, several k= nown implementations exist and have demonstrated this through numerous inter= operability tests over the years. >>>>=20 >>>> Demonstrated interoperability of independent implementations (the opera= tive word being "independent", as in "developed by different teams/instituti= ons, without any conferring outside of reading the same specification") real= ly serve as the litmus test of the quality of a specification, and are - in m= y not so humble opinion - indispensable prior to publishing a protocol speci= fication on standards track. I am sure you will agree, the reason for which s= tandards are written is to enable independent implementors to write interope= rable code, so standards need to be written to enable exactly that. >>>>=20 >>>> Deployment experiences are hugely dependent on the scenarios that you a= re deploying in, specifically (but not exclusively) the L2 you are using. Mo= bility, topology densities, ..., all play a role here, too. As far as I know= , for MANETs there are many different scenarios and L2 in use. I know of MAN= ETs that are deployed over (perfectly reliable, high-capacity) Ethernet poin= t-to-point links, and of other MANETs that are deployed over (highly lossy, l= ow-capacity, time-varying) wireless links -- and, even, MANETs which have bo= th kinds of links at the same time. >>>>=20 >>>> To try to make a general observation that seem commonly (but not univer= sally) valid, the biggest "lesson learned" from deployments probably is, tha= t hop-count metrics aren't the most appropriate metric to use in many wirele= ss scenarios; Henning and Emmanuel's I-D (that was called for, for WG adapta= tion recently) is an alternative metric that is based on the deployment exp= eriences of Henning and Emmanuel and which - in their deployments, at least,= is advantageous. I strongly encourage those efforts, of documenting operati= onal experiences, and which metrics are found to be viable. I know that NRL h= as been successful with different metrics (different from the Henning/Emmanu= el proposal, that is) for their scenarios/L2's, and that's wonderful also - t= heir scenarios and L2's are very different. Indeed, that is the reason why O= LSRv2 does not recommend a specific metric, but leaves the flexibility for a= deployment and L2 to use an appropriate (or, multiple appropriate) metrics.= >>>>=20 >>>> Best, >>>>=20 >>>> Thomas >>>>=20 >>>>=20 >>>> > Best Regards, >>>> > >>>> > AB >>>> > >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-9F070633-F32E-44CB-AC1D-978AA2EF6D48 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Abdussalam,

<= div>Have you tried googeling for OLSR Interop?

Also= , we have (when found appropriate by the chairs) both advertised these event= s in advance to the WG, and reported back. Looking through the minutes and p= roceedings from previous IETF meetings should provide you with such informat= ion.

Of course, the very best plan would be for you= to implement OLSRv2 yourself, so that you would have a reason for participa= ting in a future such event. Do let us know, if you go down that path, when y= ou have running code?

Best,

Thomas

Sent from my iPad

On 7 mars 2014, at 10:23, Ab= dussalam Baryun <abdussalam= baryun@gmail.com> wrote:

=
Thanks Thomas, I was not interested in names, but experiencing OLSR= v2. I just needed an answer from you because the gathering was mentione= d in IETF89 and I did not benefit from knowing that there was such = ;gathering. Now I understand that there was no technical summary publis= hed for OLSRv2 of such gathering. 

AB

On Friday, March 7, 2014, Thomas Heide Claus= en wrote:
Dear Abdu= ssalam,,

On 7 mars 2014, at 07:36, Abdussalam Baryun <= abdussalambaryun@gmail.com> wrote:

Hi Thomas,

Thanks a lot.  so could I under= stand that when implementing OLSRv2 and when people gathered testing OLSRv2 (= as you pictures of gatherings in your presentation in MANET WG&nbs= p;IETF89) the process of test had no single minor error in coding or er= ror in routing process in that gathering or what were the learning= main issues/points developed. Sorry if my question was = not explained well, 


Interops have as objec= tive to verify interoperability of independent implementations of the same s= pecification - as a way to measure the quality of a specification prior to s= tandardization. That's what a standards developing organization is intereste= d in, and not the quality of code from one organization or another. 

I believe that the OLSR/OLSRv2 interops were successful,= in that we had numerous independent and complete implementations participat= ing successfully over the years.

Interops do not re= ally have as goal to test the ability of an individual or an organization to= write bug-free code, and so it is not really in my place to report if perso= n X came along with code that segfaulted, or if the code of organization Y h= ad a memory leak. In fact, I'd probably make myself highly unpopular if I di= d hang out person X or organization Y, by divulging which flaws their code h= ad.

Also, mind you, some of the interops were as much as 10 y= ears ago....given that, on some days, I have a hard time remembering what I h= ad for breakfast ;)  I probably would not remember such details correct= ly anyways: as they were not relevant to the interop, they were not recorded= .

Best,

Thomas

AB

On Thursday, March 6, 20= 14, Thomas Heide Clausen wrote:
Dear Abdussalam,

> On 6 mars 2014, at 23:31, Abdussalam Baryun <abdussalambaryun@gma= il.com> wrote:
>
> Hello Thomas,
>
> I asked a question in the last meeting IETF 89 about the tests of OLSRv= 2 and experience as it was presented and mention many tests. I asked just fo= r technical summary, showing advise or possible errors detected in some depl= oyment and interoperability work of this protocol. Please help.
>

These are really two different things, that you are asking about.

Interoperability implies that independent implementations of the protocols a= re able to interoperate: correctly parse and interpret each other's messages= , and "do the right processing" as a consequence. As indicated, and as indic= ated in the shepherd write-up for OLSRv2 prior to publication, several known= implementations exist and have demonstrated this through numerous interoper= ability tests over the years.

Demonstrated interoperability of independent implementations (the operative w= ord being "independent", as in "developed by different teams/institutions, w= ithout any conferring outside of reading the same specification") really ser= ve as the litmus test of the quality of a specification, and are - in my not= so humble opinion - indispensable prior to publishing a protocol specificat= ion on standards track. I am sure you will agree, the reason for which stand= ards are written is to enable independent implementors to write interoperabl= e code, so standards need to be written to enable exactly that.

Deployment experiences are hugely dependent on the scenarios that you are de= ploying in, specifically (but not exclusively) the L2 you are using. Mobilit= y, topology densities, ..., all play a role here, too. As far as I know, for= MANETs there are many different scenarios and L2 in use. I know of MANETs t= hat are deployed over (perfectly reliable, high-capacity) Ethernet point-to-= point links, and of other MANETs that are deployed over (highly lossy, low-c= apacity, time-varying) wireless links -- and, even, MANETs which have both k= inds of links at the same time.

To try to make a general observation that seem commonly (but not universally= ) valid, the biggest "lesson learned" from deployments probably is, that hop= -count metrics aren't the most appropriate metric to use in many wireless sc= enarios; Henning and Emmanuel's I-D (that was called for, for WG adaptation r= ecently) is an alternative metric that  is based on the deployment expe= riences of Henning and Emmanuel and which - in their deployments, at least, i= s advantageous. I strongly encourage those efforts, of documenting operation= al experiences, and which metrics are found to be viable. I know that NRL ha= s been successful with different metrics (different from the Henning/Emmanue= l proposal, that is) for their scenarios/L2's, and that's wonderful also - t= heir scenarios and L2's are very different. Indeed, that is the reason why O= LSRv2 does not recommend a specific metric, but leaves the flexibility for a= deployment and L2 to use an appropriate (or, multiple appropriate) metrics.=

Best,

Thomas


> Best Regards,
>
> AB
>
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
= --Apple-Mail-9F070633-F32E-44CB-AC1D-978AA2EF6D48-- From nobody Fri Mar 7 01:35:21 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74001A0159 for ; Fri, 7 Mar 2014 01:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by7GOsZC-DK2 for ; Fri, 7 Mar 2014 01:35:14 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6D21A0164 for ; Fri, 7 Mar 2014 01:35:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3544B1D8A05; Fri, 7 Mar 2014 01:35:10 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8BE4E1C07B0; Fri, 7 Mar 2014 01:35:09 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-2A1DBD9D-F086-4E64-927E-002C04ACE475 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: <5319911F.2090001@computer.org> Date: Fri, 7 Mar 2014 10:35:10 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0F344EA3-92F7-49C2-BBAD-3DAF7CEF618E@thomasclausen.org> References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> <5319911F.2090001@computer.org> To: "Charles E. Perkins" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_GNV4N5hNcEl-LIuMnZfGNym4rI Cc: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:35:18 -0000 --Apple-Mail-2A1DBD9D-F086-4E64-927E-002C04ACE475 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 7 mars 2014, at 10:27, "Charles E. Perkins" wro= te: >=20 > Hello folks, >=20 > AODVv2 has evolved significantly since it was renamed > from DYMO, If that is the case, then: o why hasn't the working group been presented with a list of t= hese "evolutions"? o why do all the review comments, given to DYMO, still apply?= Yes, intermediate RREPs were removed, a few sections shuffled around, but be= yond that, there has been no attempts made to evolve the specification towar= ds something publishable.... Thomas > but all of the comments have to be considered > for current relevance. If any remain unresolved, then the > discussion will, I expect, produce useful ideas and text to > be used in future revisions of AODVv2. >=20 > Regards, > Charlie P. >=20 >> On 3/7/2014 1:07 AM, Henning Rogge wrote: >> Abdussalam, >>=20 >> I give you an advise and check the difference between the last DYMO draft= and the first AODVv2 draft. If you keep your strange opinion about how to d= eal with reviews about late DYMO drafts then no one can help you. >>=20 >> Except maybe the WG chairs... >>=20 >> Henning Rogge >>=20 >>> On Mar 7, 2014 7:53 AM, "Abdussalam Baryun" = wrote: >>> Hi Don, >>>=20 >>> I think the issue of not missing messages happens a lot to me with most o= f the IETF editors related to I-Ds. The best tool is the ticket tracker, bec= ause discussion messages are some how not focused on the I-D but may go thro= ugh theories/imaginations/possibilities/personality/etc.=20 >>>=20 >>> When the AODVv2 started -00 with new author team it was not DYMO any mor= e, and I think that no message has been not replied to since AODVv2-00 publi= shed in March 2013. Yes there was a reminder from participant on DYMO draft c= omments, but I am not sure the authors have time to discuss DYMO document af= ter it mature and the WG dropping it and starting adopting another document w= hich is AODVv2.=20 >>>=20 >>> I recommend the WG to focus on active documents so we can progress our w= ork. Otherwise we will not have time.=20 >>>=20 >>> AB >>>=20 >>>> On Thursday, March 6, 2014, Don Sturek wrote: >>>> Hi Charlie, >>>>=20 >>>> It would be worth (going forward) addressing issues as they come up on t= he reflector rather than having to mine these topics out of the reflector ar= chives months later. >>>>=20 >>>> Most folks have limited time to spend reviewing drafts. Ignoring comme= nts for several months does not help resolving these issues since in many ca= ses the comment and context is lost after a long period of time. >>>>=20 >>>> Don >>>>=20 >>>>=20 >>>> From: "Charles E. Perkins" >>>> Organization: Blue Skies >>>> Date: Thursday, March 6, 2014 1:26 PM >>>> To: Abdussalam Baryun >>>> Cc: Mobile Ad Hoc Networks mailing list >>>> Subject: Re: [manet] Remaining issues affecting the AODVv2 specificatio= n >>>>=20 >>>>=20 >>>> Hello Abdussalam, >>>>=20 >>>> Before the draft goes to last call, we need to resolve the >>>> open issues that were posted to the mailing list. When I >>>> mentioned that the earlier issues on the issue tracker had >>>> been resolved, that did not include the other issues that >>>> were not posted to the issue tracker. As mentioned in my >>>> previous email, I will take care of posting them to the tracker >>>> so that the resolution process will be easier to follow. >>>>=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>>> On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>> Ok so I understand from your message below that authors confirm that t= he draft is ready complete for WG to review and comment their open issues.=20= >>>>>=20 >>>>> AB >>>>>=20 >>>>>> On Thursday, March 6, 2014, Charles E. Perkins wrote: >>>>>>=20 >>>>>> Hello Abdussalam, >>>>>>=20 >>>>>> Actually, all of the issues were resolved. Then, apparently, the >>>>>> issues page crashed, and some recent updates to the issues were >>>>>> lost. However, they were sent to the mailing list, and so are >>>>>> recoverable, with a nontrivial amount of work amounting to >>>>>> an archaeological expedition through the mailing list archives. >>>>>>=20 >>>>>> I wanted to have time to do this, but so far have not. If anyone >>>>>> wants to volunteer to recover the issue-tracker updates from the >>>>>> mailing list, that would be terrific. >>>>>>=20 >>>>>> Regards, >>>>>> Charlie P. >>>>>>=20 >>>>>>=20 >>>>>>> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>>>>>> Hi Charles, >>>>>>>=20 >>>>>>> I just had before a comment on the open tickets, were they all close= d, because I think may be open. Seems most MANET WG don't care about tickets= but I like to track and I remember that the AD did mention it's importance.= =20 >>>>>>>=20 >>>>>>> For me I will review new draft and comment, but if the authors have n= o more pending issues to update, please confirm (sorry that I was not able t= o remember if there are confirmation from authors that draft is ready or not= , also need their confirm of final points of open issues for next draft if n= ot resolved).=20 >>>>>>>=20 >>>>>>> Best Regards >>>>>>>=20 >>>>>>> AB >>>>>>>=20 >>>>>>>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>>>>>>> Hello folks, >>>>>>>>=20 >>>>>>>> Part of the job of finishing the AODVv2 specification will be to co= mb >>>>>>>> the mailing list for issues that are still not resolved. If there a= re >>>>>>>> any specific issues that have not been gotten proper attention, I h= ope >>>>>>>> to find them -- but if anyone would like to help by bringing them >>>>>>>> up here on the mailing list, that will be appreciated. >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Regards, >>>>>>>> Charlie P. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>> --=20 >>>>>> Regards, >>>>>> Charlie P. >>>>=20 >>>> --=20 >>>> Regards, >>>> Charlie P. >>>> _______________________________________________ manet mailing list mane= t@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 > --=20 > Regards, > Charlie P. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-2A1DBD9D-F086-4E64-927E-002C04ACE475 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 7 mars 2014, at 10:27, "Charles E. Perkins" <charliep@computer.org> wrote:

Hello folks,

AODVv2 has evolved significantly since it was renamed
from DYMO,

If that is the case, then:

o why hasn't the working group been presented with a list of these "evolutions"?
o why do all the review comments, given to DYMO, still apply?

Yes, intermediate RREPs were removed, a few sections shuffled around, but beyond that, there has been no attempts made to evolve the specification towards something publishable....

Thomas

but all of the comments have to be considered
for current relevance.  If any remain unresolved, then the
discussion will, I expect, produce useful ideas and text to
be used in future revisions of AODVv2.

Regards,
Charlie P.

On 3/7/2014 1:07 AM, Henning Rogge wrote:

Abdussalam,

I give you an advise and check the difference between the last DYMO draft and the first AODVv2 draft. If you keep your strange opinion about how to deal with reviews about late DYMO drafts then no one can help you.

Except maybe the WG chairs...

Henning Rogge

On Mar 7, 2014 7:53 AM, "Abdussalam Baryun" <abdussalambaryun@gmail.com> wrote:
Hi Don,

I think the issue of not missing messages happens a lot to me with most of the IETF editors related to I-Ds. The best tool is the ticket tracker, because discussion messages are some how not focused on the I-D but may go through theories/imaginations/possibilities/personality/etc. 

When the AODVv2 started -00 with new author team it was not DYMO any more, and I think that no message has been not replied to since AODVv2-00 published in March 2013. Yes there was a reminder from participant on DYMO draft comments, but I am not sure the authors have time to discuss DYMO document after it mature and the WG dropping it and starting adopting another document which is AODVv2. 

I recommend the WG to focus on active documents so we can progress our work. Otherwise we will not have time. 

AB

On Thursday, March 6, 2014, Don Sturek wrote:
Hi Charlie,

It would be worth (going forward) addressing issues as they come up on the reflector rather than having to mine these topics out of the reflector archives months later.

Most folks have limited time to spend reviewing drafts.  Ignoring comments for several months does not help resolving these issues since in many cases the comment and context is lost after a long period of time.

Don


From: "Charles E. Perkins" <charliep@computer.org>
Organization: Blue Skies
Date: Thursday, March 6, 2014 1:26 PM
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: Re: [manet] Remaining issues affecting the AODVv2 specification


Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my
previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved). 

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.

-- 
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



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



-- 
Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-2A1DBD9D-F086-4E64-927E-002C04ACE475-- From nobody Fri Mar 7 01:53:23 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6506C1A01A9 for ; Fri, 7 Mar 2014 01:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dj05li9jht0q for ; Fri, 7 Mar 2014 01:53:18 -0800 (PST) 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 518AE1A0164 for ; Fri, 7 Mar 2014 01:53:18 -0800 (PST) Received: from [31.133.164.91] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WLrSq-0006mN-IG; Fri, 07 Mar 2014 04:53:12 -0500 Message-ID: <53199704.7020409@computer.org> Date: Fri, 07 Mar 2014 01:53:08 -0800 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Thomas Heide Clausen References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> <5319911F.2090001@computer.org> <0F344EA3-92F7-49C2-BBAD-3DAF7CEF618E@thomasclausen.org> In-Reply-To: <0F344EA3-92F7-49C2-BBAD-3DAF7CEF618E@thomasclausen.org> Content-Type: multipart/alternative; boundary="------------010106000209010602040900" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8682d67525f41b766146fd7245ac093ae7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.164.91 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tBq3ScheCXIK7eiRVizsuy3yIok Cc: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:53:20 -0000 This is a multi-part message in MIME format. --------------010106000209010602040900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/7/2014 1:35 AM, Thomas Heide Clausen wrote: > > On 7 mars 2014, at 10:27, "Charles E. Perkins" > wrote: > >> Hello folks, >> >> AODVv2 has evolved significantly since it was renamed >> from DYMO, > > If that is the case, then: > > owhy hasn't the working group been presented with a list of these > "evolutions"? Please refer to the "Changes" appendices in the documents. For each revision, the changes have been enumerated there, and there has been discussion on the mailing list. > owhy do all the review comments, given to DYMO, still apply? Perhaps they do *not* all apply to later revisions of the draft. Anyway, this is a matter for further discussion as we work through the issues after I post them on the issue tracker. > > Yes, intermediate RREPs were removed, a few sections shuffled around, > but beyond that, there has been no attempts made to evolve the > specification towards something publishable.... I view statements like this as unconstructive and unprofessional. This statement in particular is obviously false. --------------010106000209010602040900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 3/7/2014 1:35 AM, Thomas Heide Clausen wrote:

On 7 mars 2014, at 10:27, "Charles E. Perkins" <charliep@computer.org> wrote:

Hello folks,

AODVv2 has evolved significantly since it was renamed
from DYMO,

If that is the case, then:

o why hasn't the working group been presented with a list of these "evolutions"?

Please refer to the "Changes" appendices in the documents.  For each
revision, the changes have been enumerated there, and there has been
discussion on the mailing list.

o why do all the review comments, given to DYMO, still apply?

Perhaps they do *not* all apply to later revisions of the draft.
Anyway, this is a matter for further discussion as we work through
the issues after I post them on the issue tracker.



Yes, intermediate RREPs were removed, a few sections shuffled around, but beyond that, there has been no attempts made to evolve the specification towards something publishable....

I view statements like this as unconstructive and unprofessional.
This statement in particular is obviously false.


--------------010106000209010602040900-- From nobody Fri Mar 7 02:03:42 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010901A02A8 for ; Fri, 7 Mar 2014 02:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFh9qPm2jQnP for ; Fri, 7 Mar 2014 02:03:36 -0800 (PST) Received: from mtagate2.edf.fr (mtagate2.edf.fr [192.54.193.62]) by ietfa.amsl.com (Postfix) with ESMTP id 278701A0164 for ; Fri, 7 Mar 2014 02:03:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,606,1389740400"; d="scan'208";a="325108422" Received: from unknown (HELO XHUB003AU.notes.edfgdf.fr) ([10.122.19.74]) by CLAF1MTA2.edf.fr with ESMTP; 07 Mar 2014 11:02:11 +0100 In-Reply-To: <0F344EA3-92F7-49C2-BBAD-3DAF7CEF618E@thomasclausen.org> References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> <5319911F.2090001@computer.org> <0F344EA3-92F7-49C2-BBAD-3DAF7CEF618E@thomasclausen.org> To: manet@ietf.org MIME-Version: 1.0 X-KeepSent: FF293DB4:6CE60627-C1257C94:0036A3A2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF142 March 12, 2011 From: Cedric-2 LAVENU Message-ID: Date: Fri, 7 Mar 2014 11:02:03 +0100 Content-Type: multipart/alternative; boundary="=_alternative 00371E25C1257C94_=" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xAqvPPYiutIKvWNzZYTdaPZJK48 Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:03:41 -0000 Message en plusieurs parties au format MIME --=_alternative 00371E25C1257C94_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Charlie, all, I think that the only thing to focus on is to address the issues pointed = out on the mailing list (in the past or in the present). Up to know these comments have never been adressed properly. For now, the draft DOES NOT allow the developement of mutliple = interoperable implementations. Best regards, C=E9dric De : ietf@thomasclausen.org A : charliep@computer.org Cc : manet@ietf.org Date : 07/03/2014 10:35 Objet : Re: [manet] Remaining issues affecting the AODVv2 specification Envoy=E9 par : manet-bounces@ietf.org On 7 mars 2014, at 10:27, "Charles E. Perkins" = wrote: Hello folks, AODVv2 has evolved significantly since it was renamed from DYMO, = If that is the case, then: o why hasn't the working group been presented with a list of these = "evolutions"? o why do all the review comments, given to DYMO, still apply? Yes, intermediate RREPs were removed, a few sections shuffled around, but = beyond that, there has been no attempts made to evolve the specification = towards something publishable.... Thomas but all of the comments have to be considered for current relevance. If any remain unresolved, then the discussion will, I expect, produce useful ideas and text to be used in future revisions of AODVv2. Regards, Charlie P. On 3/7/2014 1:07 AM, Henning Rogge wrote: Abdussalam, I give you an advise and check the difference between the last DYMO draft = and the first AODVv2 draft. If you keep your strange opinion about how to = deal with reviews about late DYMO drafts then no one can help you. Except maybe the WG chairs... Henning Rogge On Mar 7, 2014 7:53 AM, "Abdussalam Baryun" = wrote: Hi Don, = I think the issue of not missing messages happens a lot to me with most of = the IETF editors related to I-Ds. The best tool is the ticket tracker, = because discussion messages are some how not focused on the I-D but may go = through theories/imaginations/possibilities/personality/etc. = When the AODVv2 started -00 with new author team it was not DYMO any more, = and I think that no message has been not replied to since AODVv2-00 = published in March 2013. Yes there was a reminder from participant on DYMO = draft comments, but I am not sure the authors have time to discuss DYMO = document after it mature and the WG dropping it and starting adopting = another document which is AODVv2. = I recommend the WG to focus on active documents so we can progress our = work. Otherwise we will not have time. = AB On Thursday, March 6, 2014, Don Sturek wrote: Hi Charlie, It would be worth (going forward) addressing issues as they come up on the = reflector rather than having to mine these topics out of the reflector = archives months later. Most folks have limited time to spend reviewing drafts. Ignoring comments = for several months does not help resolving these issues since in many = cases the comment and context is lost after a long period of time. Don From: "Charles E. Perkins" Organization: Blue Skies Date: Thursday, March 6, 2014 1:26 PM To: Abdussalam Baryun Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification Hello Abdussalam, Before the draft goes to last call, we need to resolve the open issues that were posted to the mailing list. When I mentioned that the earlier issues on the issue tracker had been resolved, that did not include the other issues that were not posted to the issue tracker. As mentioned in my previous email, I will take care of posting them to the tracker so that the resolution process will be easier to follow. Regards, Charlie P. On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: Ok so I understand from your message below that authors confirm that the = draft is ready complete for WG to review and comment their open issues. = AB On Thursday, March 6, 2014, Charles E. Perkins wrote: Hello Abdussalam, Actually, all of the issues were resolved. Then, apparently, the issues page crashed, and some recent updates to the issues were lost. However, they were sent to the mailing list, and so are recoverable, with a nontrivial amount of work amounting to an archaeological expedition through the mailing list archives. I wanted to have time to do this, but so far have not. If anyone wants to volunteer to recover the issue-tracker updates from the mailing list, that would be terrific. Regards, Charlie P. On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: Hi Charles, = I just had before a comment on the open tickets, were they all closed, = because I think may be open. Seems most MANET WG don't care about tickets = but I like to track and I remember that the AD did mention it's = importance. = For me I will review new draft and comment, but if the authors have no = more pending issues to update, please confirm (sorry that I was not able = to remember if there are confirmation from authors that draft is ready or = not, also need their confirm of final points of open issues for next draft = if not resolved). = Best Regards AB On Wednesday, March 5, 2014, Charles E. Perkins wrote: Hello folks, Part of the job of finishing the AODVv2 specification will be to comb the mailing list for issues that are still not resolved. If there are any specific issues that have not been gotten proper attention, I hope to find them -- but if anyone would like to help by bringing them up here on the mailing list, that will be appreciated. -- = Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- = Regards, Charlie P. -- = 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 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- = 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 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. --=_alternative 00371E25C1257C94_= MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Charlie, all,

I think that the only thing to focus on is to address the issues pointed out on the mailing list (in the past or in the present).
Up to know these comments have never been adressed properly.
For now, the draft DOES NOT allow the developement of mutliple interoperable implementations.

Best regards,
C=E9dric




De :     &= nbsp;  ietf@thomasclausen.org
A :     &n= bsp;  charliep@computer.org
Cc :   &nb= sp;    manet@ietf.org
Date :    =    07/03/2014 10:35
Objet :        Re: [manet] Remaining issues affecting the AODVv2 specification
Envoy=E9 par :  = ;      manet-bounces@ietf.o= rg




On 7 mars 2014, at 10:27, "Charles E. Perkins" <charliep@computer.org> wrote:
Hello folks,

AODVv2 has evolved significantly since it was renamed
from DYMO,

If that is the case, then:

o why hasn't the working group been presented with a list of these "evolutions"?
o why do all the review comments, given to DYMO, still apply?

Yes, intermediate RREPs were removed, a few sections shu= ffled around, but beyond that, there has been no attempts made to evolve the specification towards something publishable....

Thomas

but all of the comments have to be considered
for current relevance.  If any remain unresolved, then the
discussion will, I expect, produce useful ideas and text to
be used in future revisions of AODVv2.

Regards,
Charlie P.
On 3/7/2014 1:07 AM, Henning Rogge wrote:

Abdussalam,

I give you an advise and check the difference between the last DYMO draft and the first AODVv2 draft. If you keep your strange opinion about how to deal with reviews about late DYMO drafts then no one can help you.

Except maybe the WG chairs...

Henning Rogge

On Mar 7, 2014 7:53 AM, "Abdussalam Baryun" <= ;abdussalambaryun@gmail.com> wrote:
Hi Don,

I think the issue of not missing messages happens a lot to me with most of the IETF editors related to I-Ds. The best tool is the ticket tracker, because discussion messages are some how not focused on the I-D but may go through theories/imaginations/possibilities/personality/= etc.

When the AODVv2 started -00 with new author team it was not DYMO any more, and I think that no message has been not replied to since AODVv2-00 published in March 2013. Yes there was a reminder from participant on DYMO draft comments, but I am not sure the authors have time to discuss DYMO document after it mature and the WG dropping it and starting adopting another document which is AODVv2.

I recommend the WG to focus on active documents so we can progress our work. Otherwise we will not have time.

AB

On Thursday, March 6, 2014, Don Sturek wrote:
Hi Charlie,

It would be worth (going forward) ad= dressing issues as they come up on the reflector rather than having to mine these topics out of the reflector archives months later.

Most folks have limited time to spend reviewing drafts.  Ignoring comments for several months does not help resolving these issues since in many cases the comment and context is lost after a long period of time.

Don


From: "Charles E. Perkins&q= uot; <charliep@computer.org>
Organization: Blue Skies
Date: Thursday, March 6, 2014 1:26 PM
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: Re: [manet] Remaining issues affecting the AODVv2 specificatio= n


Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my
previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.
On 3/6/2014 11:35 AM, Abdussalam Bar= yun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues.  

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.
On 3/6/2014 8:16 AM, Abdussalam Bary= un wrote:
Hi Charles,

I just had before a comment on the o= pen tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like to track and I remember that the AD did mention it's importance.

For me I will review new draft and c= omment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from autho= rs that draft is ready or not, also need their confirm of final points of open issues for next draft if not resolved).

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.

--
Regards,
Charlie P.

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

--
Regards,
Charlie P.

--
Regards,
Charlie P.
____________________________________= ___________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet

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


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


--
Regards,
Charlie P.
_______________________________________________
manet mailing list
m= anet@ietf.org
https://www.ietf.org/mailman/listinfo/manet= _______________________________________________
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= 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 tr= ace sur quelque support que ce soit. Nous 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 prohibi= ted 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.

--=_alternative 00371E25C1257C94_=-- From nobody Fri Mar 7 02:28:04 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D801A0175 for ; Fri, 7 Mar 2014 02:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ4FpwZ1S80y for ; Fri, 7 Mar 2014 02:27:57 -0800 (PST) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E604C1A0158 for ; Fri, 7 Mar 2014 02:27:56 -0800 (PST) Received: by mail-yh0-f46.google.com with SMTP id b6so1011557yha.5 for ; Fri, 07 Mar 2014 02:27:52 -0800 (PST) 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=7/ptJ8kIyQwjqGketm4Qr8xRTfSg9WmQ0powb8jM8F8=; b=gOSC9JWpwtyT2Qn/ZlplvcZV/GZDzCAC2Y+pT9XeoIaOGvBFfLEtIqatYBACras9Ck BudBmVqe81yo3reUA2sPLQm/2GYl3aJNsKoIHhdVLwF9kjkvUvCybizdn5RNFAb1UY5l 9TJl9XBNyCijnrQ4thoo3WKxpzdblyUC4EEforecJPNAmb9BcKMQVQyk6h9JEkAAqb/0 zP1zz96kfYgyqgeOGCu45J+8e4TyNabE2LRpxwy7y17+72l0utHE+Sa+7Q2sbTvNMHYf rYKtV0SocrktOr1WxQw9tGe3Mld/DFSMfy+FkalycQhc1y4fo80vS3fjqE7cL7IWKcUg eabw== MIME-Version: 1.0 X-Received: by 10.236.118.212 with SMTP id l60mr22119409yhh.78.1394188072668; Fri, 07 Mar 2014 02:27:52 -0800 (PST) Received: by 10.170.202.7 with HTTP; Fri, 7 Mar 2014 02:27:52 -0800 (PST) In-Reply-To: <680DC4B8-52F7-49B6-BB04-B82F0138CAF0@thomasclausen.org> References: <5317012F.60701@computer.org> <680DC4B8-52F7-49B6-BB04-B82F0138CAF0@thomasclausen.org> Date: Fri, 7 Mar 2014 11:27:52 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=20cf3005de08d254fe04f401b4bc Archived-At: http://mailarchive.ietf.org/arch/msg/manet/akYogd_UpjGO-cp91PwDykEkr_4 Cc: Mobile Ad Hoc Networks mailing list Subject: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:28:02 -0000 --20cf3005de08d254fe04f401b4bc Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas and Henning, I agree that The point of having standard implementations is very interesting but not necessary when we have experiment RFC. But we should not miss important thing Charles decided to do for AODVv2 mentioned in IETF89 presentation. Working on an open source AODVv2 implementation by the standard-author is very very very most best important, this way the WG and the community can do more tests and more interoperability in all the world. Usually companies dislike open sources because competition. Best, AB --20cf3005de08d254fe04f401b4bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas and Henning,

I agree that=A0The point of=A0hav= ing standard=A0implementations is very interesting but not necessary when w= e have experiment RFC.=A0But we should not miss important thing Charles dec= ided to do for AODVv2 mentioned in IETF89 presentation.=A0

=A0Working on=A0an open source AODVv2 implementation=A0= by the standard-author=A0is very very very most best important, this way th= e WG and the community=A0can do more tests and more interoperability in all= the world. Usually companies dislike open sources because competition.=A0<= /div>

Best,

AB
--20cf3005de08d254fe04f401b4bc-- From nobody Fri Mar 7 02:30:28 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6D61A012B for ; Fri, 7 Mar 2014 02:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4friK5EWieg for ; Fri, 7 Mar 2014 02:30:23 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id F2DD81A006F for ; Fri, 7 Mar 2014 02:30:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 1598B1C07B0; Fri, 7 Mar 2014 02:30:19 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5E9071C04AB; Fri, 7 Mar 2014 02:30:18 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-9079C9EB-BB4E-4D40-AB4C-074764439621 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: <53199704.7020409@computer.org> Date: Fri, 7 Mar 2014 11:30:19 +0100 Content-Transfer-Encoding: 7bit Message-Id: <433172E4-4062-44F1-ADB1-03503E9FD34C@thomasclausen.org> References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> <5319911F.2090001@computer.org> <0F344EA3-92F7-49C2-BBAD-3DAF7CEF618E@thomasclausen.org> <53199704.7020409@computer.org> To: "Charles E. Perkins" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3CNlVGMEnVnSj63TwyQf8OsQAss Cc: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:30:25 -0000 --Apple-Mail-9079C9EB-BB4E-4D40-AB4C-074764439621 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 7 mars 2014, at 10:53, "Charles E. Perkins" wro= te: >=20 >=20 >> On 3/7/2014 1:35 AM, Thomas Heide Clausen wrote: >>=20 >> On 7 mars 2014, at 10:27, "Charles E. Perkins" wr= ote: >>=20 >>> Hello folks, >>>=20 >>> AODVv2 has evolved significantly since it was renamed >>> from DYMO, >>=20 >> If that is the case, then: >>=20 >> o why hasn't the working group been presented with a list of these "evol= utions"? >=20 > Please refer to the "Changes" appendices in the documents.=20 Alright, let us do that, then. Here's the changes section: > Appendix B. Changes since revision ...-02.txt >=20 > This section lists the changes since AODVv2 revision ...-02.txt >=20 > o The "Added Node" feature was removed. This feature was intended > to enable additional routing information to be carried within a > RREQ or a RREP message, thus increasing the amount of topological > information available to nodes along a routing path. However, > enlarging the packet size to include information which might never > be used can increase congestion of the wireless medium. The > feature can be included as an optional feature at a later date > when better algorithms are understood for determining when the > inclusion of additional routing information might be worthwhile. I'll grant you, that bit was also removed. I am still not sure what it did, s= o thats probably good.=20 But I overlooked that in my previous mail. > o Numerous editorial improvements and improvements to consistent > terminology were made. Instances of OrigNodeNdx and TargNodeNdx > were replaced by OrigNdx and TargNdx, to be consistent with the > terminology shown in Table 1. Imprecise, but as you say 'editorial', then that implies that they do not im= pact protocol operations, nor interoperability. > o Example RREQ and RREP message formats shown in the Appendices were > changed to use OrigSeqNum and TargSeqNum message TLVs instead of > using the SeqNum message TLV. I.e. updates to the presentation of non-normative parts of the specification= . > o Inclusion of the OrigNode's SeqNum in the RREP message is not > specified. The processing rules for the OrigNode's SeqNum were > incompletely specified in previous versions of the draft, and very > little benefit is foreseen for including that information, since > reverse path forwarding is used for the RREP. Not sure that I understand what the above says? Apparently, something that w= as incompletely specified was removed, which probably is good. But I do not r= emember having seen any discussion on that point. > o Additional acknowledgements were included, and contributors names > were alphabetized. Editorial - does not impact protocol operations, implementability, interoper= ability > o Definitions in the Terminology section capitalize the term to be > defined. Editorial - does not impact protocol operations, implementability, interoper= ability > o Uncited bibliographic entries deleted. Editorial - does not impact protocol operations, implementability, interoper= ability > o Ancient "Changes" sections were deleted Editorial - does not impact protocol operations, implementability, interoper= ability I am not sure that I consider capitalizing terminology, deleting unused bibl= iographic entries, ordering contributor names alphabetically, updating non-n= ormative examples in an appendix, and removing an underspecified feature fro= m a previous version to represent "has evolved significantly".=20 Especially, as issues have been raised regarding interoperability, implement= ability, unambiguity, security etc. which have gone unaddressed. For four ye= ars... > For each > revision, the changes have been enumerated there, and there has been > discussion on the mailing list. >> o why do all the review comments, given to DYMO, still apply? >=20 > Perhaps they do *not* all apply to later revisions of the draft. I believe that there have been several people who have made reviews to the l= ater versions of DYMO, and who have indicated that these still apply. In mee= tings, on this mailing list.=20 > Anyway, this is a matter for further discussion as we work through > the issues after I post them on the issue tracker. >=20 No! This *was* a matter for discussion when the issues were raised - that wa= s when it was timely to do so, not at some unspecified time in the future.=20= As for "unspecified time in the future", let me remind you that more than a y= ear ago, in an email to this list, the WG was promised - prompted by the WG c= hair - that the authors of this document would get back to the list and expl= ain some RFC5444-issue "next month"... >> Yes, intermediate RREPs were removed, a few sections shuffled around, but= beyond that, there has been no attempts made to evolve the specification to= wards something publishable.... >=20 > I view statements like this as unconstructive and unprofessional. > This statement in particular is obviously false. You are right, I actually can not know if attempts were made or not. So that= phrasing was imprecise. I can only judge the result, as published by way of revisions to I-Ds. So, l= et me reformulate my conclusion to something that's obviously true: If attempts have been made to evolve the specification towards some= thing publishable,=20 then these attempts have been insufficient, and have failed. Best, Thomas= --Apple-Mail-9079C9EB-BB4E-4D40-AB4C-074764439621 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 7 mars 2014, at 10:5= 3, "Charles E. Perkins" <charlie= p@computer.org> wrote:



Appendix B.  Changes since revision ...-02.txt


   This section lists the changes since AO= DVv2 revision ...-02.txt


   o  The "Added Node" feature was re= moved.  This feature was intended

      to enable additional routing in= formation to be carried within a

      RREQ or a RREP message, thus in= creasing the amount of topological

      information available to nodes a= long a routing path.  However,

      enlarging the packet size to in= clude information which might never

      be used can increase congestion= of the wireless medium.  The

      feature can be included as an o= ptional feature at a later date

      when better algorithms are unde= rstood for determining when the

      inclusion of additional routing= information might be worthwhile.


I'll grant you, that bit was also removed. I am still not sure what it did,= so thats probably good. 


   o  Numerous editorial improvements= and improvements to consistent

      terminology were made.  In= stances of OrigNodeNdx and TargNodeNdx

      were replaced by OrigNdx and Ta= rgNdx, to be consistent with the

      terminology shown in Table 1.







 For each
revision, the changes have been enu= merated there, and there has been
discussion on the mailing list.
= o why do all the review comments, given to DYMO, still apply?

Perhaps they do *not* all apply to later revisions of the draft.

I believe that there have been several pe= ople who have made reviews to the later versions of DYMO, and who have indic= ated that these still apply. In meetings, on  this mailing list. <= /div>

Anyway, this is a matter for further discussion as we work through
the issues after I post them on the issue tracker.


No! This *was* a matter for discus= sion when the issues were raised - that was when it was timely to do so, not= at some unspecified time in the future. 

As for "un= specified time in the future", let me remind you that more than a year ago, i= n an email to this list, the WG was promised - prompted by the WG chair - th= at the authors of this document would get back to the list and explain some R= FC5444-issue "next month"...

Yes, intermediate RREPs were removed, a few sections shuffled around, but beyond that, there has been no attempts made to evolve the specification towards something publishable....

I view statements like this as unconstructive and unprofessional.
This statement in particular is obviously false.
<= div>
You are right, I actually can not know if attempts were m= ade or not. So that phrasing was imprecise.

I can o= nly judge the result, as published by way of revisions to I-Ds. So, let me r= eformulate my conclusion to something that's obviously true:

<= /div>
If attempts have been made to evolve the specification towards something= publishable, 
then these attempts have been insufficient, and have= failed.

Best,

Thomas
= --Apple-Mail-9079C9EB-BB4E-4D40-AB4C-074764439621-- From nobody Fri Mar 7 02:35:04 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1113B1A018A for ; Fri, 7 Mar 2014 02:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuzUSiEARvyf for ; Fri, 7 Mar 2014 02:35:01 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id DF7D41A012B for ; Fri, 7 Mar 2014 02:35:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 040181D89DA; Fri, 7 Mar 2014 02:34:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.154.183] (unknown [130.129.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B172D1C07B0; Fri, 7 Mar 2014 02:34:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Fri, 7 Mar 2014 11:34:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <10606C9C-ED28-45E8-8A9D-96D4447D6958@thomasclausen.org> References: <5317012F.60701@computer.org> <680DC4B8-52F7-49B6-BB04-B82F0138CAF0@thomasclausen.org> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/S9RVQk0PrR_esYmDtsaGpLl9Opo Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:35:03 -0000 Dear Abdussalam, > On 7 mars 2014, at 11:27, Abdussalam Baryun w= rote: >=20 > Hi Thomas and Henning, >=20 > I agree that The point of having standard implementations is very interest= ing but not necessary when we have experiment RFC.=20 Ah, but IIRC this document intends to be published as Proposed Standard, not= as experimental. Hence, the bar is - and should be - a *lot* higher. > But we should not miss important thing Charles decided to do for AODVv2 me= ntioned in IETF89 presentation.=20 >=20 > Working on an open source AODVv2 implementation by the standard-author is= very very very most best important, At the IETF88, Mr. Perkins informed us that the implementations were underta= ken by some students in Germany - and not by himself. > this way the WG and the community can do more tests and more interoperabil= ity in all the world. In order to be able to do interoperability testing, one needs a stable, unam= biguous, complete specification to implement. > Usually companies dislike open sources because competition.=20 Plenty of companies participate in open source projects.=20 Heck, as recent as yesterday over lunch, I was talking to two guys from Cisc= o, spending their entire time developing open source protocol implementation= s. Best, Thomas > Best, >=20 > AB From nobody Fri Mar 7 02:54:56 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C600D1A01AE for ; Fri, 7 Mar 2014 02:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsK44XnSognQ for ; Fri, 7 Mar 2014 02:54:52 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 422081A019B for ; Fri, 7 Mar 2014 02:54:52 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id ld10so3995324pab.40 for ; Fri, 07 Mar 2014 02:54:48 -0800 (PST) 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=K+kO9+27wg50AeIonZFoR+we0PlptlIj9trurmUPvMg=; b=g9LHsfhpDHCG7RqHsRzdjuRVAYxq0eHmvEWXt1lLwsUMMeNxyA+C7lsdeNqLrhaT81 Es3EGe7qwF6QJHUNbUdU+5yZ+vGaK1rjqZz+ZxQCAHQnWO/sDc0OiJzUj4TusYf6fjYg 5ILMrh5TIqVyoi5+MsNqmxczGuydXvmemzbWhw0mT2xGEumjc1MdvuiHAIiLzNTXQACM GFYF61rpET/BlkRTqqyZo60aUjD2ZIBNKT3c75J52GpCZO3Jp3W1hnt8q7qJhsPsV4Zb MEHQNADwDQqGEQqn7DXhtJSZWPmxq2rDRAtFugJmuLSK/3/WfusJOPeBXYtBQHq8+N6j DwJA== MIME-Version: 1.0 X-Received: by 10.66.21.7 with SMTP id r7mr21066400pae.135.1394189687080; Fri, 07 Mar 2014 02:54:47 -0800 (PST) Received: by 10.70.131.133 with HTTP; Fri, 7 Mar 2014 02:54:47 -0800 (PST) Date: Fri, 7 Mar 2014 16:24:47 +0530 Message-ID: From: hari To: manet@ietf.org Content-Type: multipart/alternative; boundary=bcaec520f2690c4b6404f402156b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/nhyg9x-zRkAzyNiYka1gFMj-ITI Subject: [manet] rem X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:54:54 -0000 --bcaec520f2690c4b6404f402156b Content-Type: text/plain; charset=ISO-8859-1 -- Thanks & Regards, S.Harihara Gopalan M.E.,(Ph.D) Assistant Professor, Sri Ramakrishna Engineering College, Coimbatore-641022. Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy. --bcaec520f2690c4b6404f402156b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


--
<= span>=A0=A0=A0=A0 Thanks & Regards,
=A0 =A0=A0 S= .Harihara Gopalan M.E.,(Ph.D)
=A0=A0=A0=A0 Assistant Professor,
=A0 = =A0=A0 Sri Ramakrishna Engineering College,
=A0 =A0=A0 Coimbatore-641022.
=A0Please consider your environmental resp= onsibility.
= Before printing this e-mail message, ask yourself whether you really need a= hard copy.
--bcaec520f2690c4b6404f402156b-- From nobody Fri Mar 7 05:30:42 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6591A0271 for ; Fri, 7 Mar 2014 05:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_MZ06OExfEV for ; Fri, 7 Mar 2014 05:30:35 -0800 (PST) Received: from nm1-vm4.access.bullet.mail.gq1.yahoo.com (nm1-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.89]) by ietfa.amsl.com (Postfix) with ESMTP id 826C91A0159 for ; Fri, 7 Mar 2014 05:30:35 -0800 (PST) Received: from [216.39.60.168] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Mar 2014 13:30:31 -0000 Received: from [67.195.22.113] by tm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Mar 2014 13:30:31 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.gq1.yahoo.com with NNFMP; 07 Mar 2014 13:30:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1394199031; bh=6no0Yu5TJE6kpbmdp+ihmTn17A0zq63lxbGhb4X5T/8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type; b=VQjV8ZGd+XIWqUCwzez3vd1pXhao8MmBxKwLBB+NUT0IMkxWYUm8gZBx15TeCqhgzBivtBiMjevGNUGux96vKpzu0i6fOHw2hHsifl3e36TUrEYXIflG7Jo7l02qK/EexzO2+zCO8wormgGpAh84qzPA1P4YkkwdvmyPwTi+Qog= X-Yahoo-Newman-Id: 188601.90596.bm@smtp115.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: RX1ywxUVM1lF6Qp3PjqS79OWacRNCkZpqupDyLbFYBLfOW8 HGVvAQRwU07MapNsBsbCOjAuB8Vi5qZnWbEO0wgjR6esQKu7AR9m8RwrcNQQ ACWqlehsH8sxnb5dtszYU8XC9YAr0TzG.rJtd6FXDJLBJdy5kUws07312Jwp iVekYhNEZrQQlgdMQKqO8PdiPNbZhEwlIuaWFXyrXVotEQOK9RbfiB06T03p cXVSYdOwqUgmqzB_20nwmLaWYEzuNpqsUtQ291dy4CtO7eE9wag_zlx0mw6J 2IdPgFRlzfojlvNm9O95lw4lbwuEKUoOJGF7g7webMMhWCRBzZVpR4M4qTEL 0ANL9WkOWCecH8HCgo6KpOjyt0bNnk1Ck0.NMiX5L2kR2Q.KjrPV5iORqsVt K6Td7g1zIa2p8ZEkShiZTSYy7s8mVm8or6hfRmp5ZYWrLOOL2bPXFz173IET 4GQ3Skf39iMjyHDaS21cmS4UFj3Wk1pNHgZRjCJq5sTTiinU8yIJ5FzGEY5M GEgFg5opGcSdS6zN.eUtwnSiiVbIP57gUzStMEJ0K_SGeyWsQP_PTcu9zgFk - X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@69.111.215.218 with plain [67.195.15.5]) by smtp115.sbc.mail.gq1.yahoo.com with SMTP; 07 Mar 2014 05:30:30 -0800 PST User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 07 Mar 2014 05:30:26 -0800 From: Don Sturek To: Abdussalam Baryun Message-ID: Thread-Topic: [manet] Remaining issues affecting the AODVv2 specification References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3477015029_43417" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gBqmvRZ38o-Q-EWK--2ICAdsTWE Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 13:30:39 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3477015029_43417 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi AB, I think the issue is that AODVv2 (or DYMO) has been selected as the proactive/reactive routing protocol the MANET group has adopted to work on (and I disagree on the topic of "missing messages" since I have never had that experience). As a result of AODVv2's selection, we should expect the editor(s) to be responsive to input to the group. I think if you go to the MANET e-mail reflector (and, yes, I expect it will work for you), you will see that the editing group for this draft has faile= d to be responsive (over a very long period of time). It would be great not to worry about old drafts as long as the new drafts have incorporated all of the changes needed by the group over time=8A=8A.. Don From: Abdussalam Baryun Date: Thursday, March 6, 2014 11:53 PM To: Don Sturek Cc: "Charles E. Perkins" , Mobile Ad Hoc Networks mailing list Subject: [manet] Remaining issues affecting the AODVv2 specification Hi Don, I think the issue of not missing messages happens a lot to me with most of the IETF editors related to I-Ds. The best tool is the ticket tracker, because discussion messages are some how not focused on the I-D but may go through theories/imaginations/possibilities/personality/etc. When the AODVv2 started -00 with new author team it was not DYMO any more, and I think that no message has been not replied to since AODVv2-00 published in March 2013. Yes there was a reminder from participant on DYMO draft comments, but I am not sure the authors have time to discuss DYMO document after it mature and the WG dropping it and starting adopting another document which is AODVv2. I recommend the WG to focus on active documents so we can progress our work= . Otherwise we will not have time. AB On Thursday, March 6, 2014, Don Sturek wrote: > Hi Charlie, >=20 > It would be worth (going forward) addressing issues as they come up on th= e > reflector rather than having to mine these topics out of the reflector > archives months later. >=20 > Most folks have limited time to spend reviewing drafts. Ignoring comment= s for > several months does not help resolving these issues since in many cases t= he > comment and context is lost after a long period of time. >=20 > Don >=20 >=20 > From: "Charles E. Perkins" > Organization: Blue Skies > Date: Thursday, March 6, 2014 1:26 PM > To: Abdussalam Baryun > Cc: Mobile Ad Hoc Networks mailing list > Subject: Re: [manet] Remaining issues affecting the AODVv2 specification >=20 > =20 > =20 > Hello Abdussalam, > =20 > Before the draft goes to last call, we need to resolve the > open issues that were posted to the mailing list. When I > mentioned that the earlier issues on the issue tracker had > been resolved, that did not include the other issues that > were not posted to the issue tracker. As mentioned in my > previous email, I will take care of posting them to the tracker > so that the resolution process will be easier to follow. > =20 > Regards, > Charlie P. > =20 > =20 > On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: > =20 > =20 >>=20 >> Ok so I understand from your message below that authors confirm that th= e >> draft is ready complete for WG to review and comment their open issues. >>=20 >> =20 >> =20 >> AB >> =20 >>=20 >> On Thursday, March 6, 2014, Charles E. Perkins wrote: >> =20 >>> =20 >>> =20 >>> Hello Abdussalam, >>> =20 >>> Actually, all of the issues were resolved. Then, apparently, the >>> issues page crashed, and some recent updates to the issues were >>> lost. However, they were sent to the mailing list, and so are >>> recoverable, with a nontrivial amount of work amounting to >>> an archaeological expedition through the mailing list archives. >>> =20 >>> I wanted to have time to do this, but so far have not. If anyone >>> wants to volunteer to recover the issue-tracker updates from the >>> mailing list, that would be terrific. >>> =20 >>> Regards, >>> Charlie P. >>> =20 >>> =20 >>> =20 >>> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>> =20 >>> =20 >>>> Hi Charles,=20 >>>>=20 >>>> =20 >>>> =20 >>>> I just had before a comment on the open tickets, were they all closed, >>>> because I think may be open. Seems most MANET WG don't care about tick= ets >>>> but I like to track and I remember that the AD did mention it's import= ance. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> For me I will review new draft and comment, but if the authors have no= more >>>> pending issues to update, please confirm (sorry that I was not able to >>>> remember if there are confirmation from authors that draft is ready or= not, >>>> also need their confirm of final points of open issues for next draft = if >>>> not resolved). >>>> =20 >>>>=20 >>>> =20 >>>> Best Regards >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> AB >>>> =20 >>>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>>> =20 >>>>> Hello folks, >>>>> =20 >>>>> Part of the job of finishing the AODVv2 specification will be to com= b >>>>> the mailing list for issues that are still not resolved. If there a= re >>>>> any specific issues that have not been gotten proper attention, I ho= pe >>>>> to find them -- but if anyone would like to help by bringing them >>>>> up here on the mailing list, that will be appreciated. >>>>> =20 >>>>> --=20 >>>>> Regards, >>>>> Charlie P. >>>>> =20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> =20 >>>> =20 >>>> =20 >>> =20 >>> =20 >>> --=20 >>> Regards, >>> Charlie P. >>> =20 >>> =20 >> =20 >> =20 > =20 > =20 > --=20 > Regards, > Charlie P. > =20 > _______________________________________________ manet mailing list > manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet --B_3477015029_43417 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi AB,

I think the issue is that AODVv2 (or DYMO) has been selected as the proactive/reactive routing proto= col the MANET group has adopted to work on (and I disagree on the topic of "= missing messages" since I have never had that experience).   As a resul= t of AODVv2's selection, we should expect the editor(s) to be responsive to = input to the group.

I think if you go to the MANET = e-mail reflector (and, yes, I expect it will work for you), you will see tha= t the editing group for this draft has failed to be responsive (over a very = long period of time).

It would be great not to worr= y about old drafts as long as the new drafts have incorporated all of the ch= anges needed by the group over time……..

Don


From: Abdussalam Baryun <abdu= ssalambaryun@gmail.com>
Date: Thursday, March 6, 2014 11:53 PM
To: Don Sturek <d.sturek@att.net&= gt;
Cc: "Charles E. Perkins" <<= a href=3D"mailto:charliep@computer.org">charliep@computer.org>, Mobile = Ad Hoc Networks mailing list <manet@ietf.= org>
Subject: [manet] Remai= ning issues affecting the AODVv2 specification

Hi Do= n,

I think the issue of not missing messages happens a lo= t to me with most of the IETF editors related to I-Ds. The best tool is= the ticket tracker, because discussion messages are some how not focused on= the I-D but may go through theories/imaginations/possibilities/personality/= etc. 

When the AODVv2 started -00 with new aut= hor team it was not DYMO any more, and I think that no message has= been not replied to since AODVv2-00 published in March 2013. Yes there= was a reminder from participant on DYMO draft comments, but I am not s= ure the authors have time to discuss DYMO document after it mature= and the WG dropping it and starting adopting another document which is= AODVv2. 

I recommend the WG to focus on = active documents so we can progress our work. Otherwise we will not have tim= e. 

AB

On Thursday, March 6, 2014, Don = Sturek wrote:
Hi Charlie,

It would be worth (going forward) addressing issues as they = come up on the reflector rather than having to mine these topics out of the = reflector archives months later.

Most folks have li= mited time to spend reviewing drafts.  Ignoring comments for several mo= nths does not help resolving these issues since in many cases the comment an= d context is lost after a long period of time.

Don<= /div>


From: "Charles E. Perkins" <charliep@computer.org>= ;
Organization: Blue Skies
Date: Thursday, March 6, 2014 1:26 PM
= To: Abdussalam Baryun <abdussal= ambaryun@gmail.com>
Cc: Mob= ile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: Re: [manet] Remaining issues affecting= the AODVv2 specification


Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so= are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If= anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets,&nb= sp;were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like= to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of = ;final points of open issues for next draft if not resolved). = ;

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.
--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.

-- 
Regards,
Charlie P.
_______________________________________________ manet mailing list manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet
=
--B_3477015029_43417-- From nobody Fri Mar 7 06:49:16 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898B11A0230 for ; Fri, 7 Mar 2014 06:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKWoKV5J3ro2 for ; Fri, 7 Mar 2014 06:49:10 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 50B7C1A0073 for ; Fri, 7 Mar 2014 06:49:10 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wn1so4177482obc.11 for ; Fri, 07 Mar 2014 06:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=vpeTjq+WQYEB+8EER4/FZ0GzGDQHkGj30kh+fyaTj20=; b=up2wX8fIwVYyElTGbrrZUCvbBg8y88FRdl93qg+oAccPopGNVZZ4WupON3gNEFm9vh moRoT7Id5xQRjEHLQ2iX9m2oxyVTi+YNR47rbBpwEHnPYiwrYiiv1askUPJxgBfT4aq+ mXh3fmxGjCUFTV8AaMTQUcv0oe99P8zvuVdNQO67tOF4D0+KbozYBX+X7z8Sq2KQhnLM Al/CQfNZgg8EhQbI4AiCow8T4R3+y0OAMQGa5Lfg9gZaGZHNhcbi37a5/c/D5I8KZdlk u2wvovw9DCNZJLYnQlSTu/heotEgh19Zzl2Q9gP8OEVyXkOq5TzQyzEyJz7G4YS8IjRO +9ew== X-Received: by 10.60.227.72 with SMTP id ry8mr182248oec.86.1394203745953; Fri, 07 Mar 2014 06:49:05 -0800 (PST) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.98.104 with HTTP; Fri, 7 Mar 2014 06:48:45 -0800 (PST) In-Reply-To: References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> From: Emmanuel Baccelli Date: Fri, 7 Mar 2014 15:48:45 +0100 X-Google-Sender-Auth: 2SaRPB2AM_In8LTC_9Dny-rMLE8 Message-ID: To: MANET IETF Content-Type: multipart/alternative; boundary=001a1136ab0605af7b04f4055bfa Archived-At: http://mailarchive.ietf.org/arch/msg/manet/224jMnV6IPPZ8XpXM7vn-WSSF5k Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 14:49:13 -0000 --001a1136ab0605af7b04f4055bfa Content-Type: text/plain; charset=ISO-8859-1 Hi all, My take on this. I think we all agree that progress in the MANET working group has been painfully slow over the last decade.The proactive protocol took 10+ years to converge, and the reactive protocol is not progressing as quickly as desired either. Now, from a 30k feet perspective, even one more year delay for AODVv2 would mean less than 10% more time that was needed for OLSRv2... So from this perspective, maybe we should not pick too much on AODVv2 and we should not get too alarmed: it seems it is the fate of MANET to deal with such slow progress. While the (non-technical) reasons for that fate could also be discussed, I'm not certain this particular thread is the most appropriate to do so. Since the decision was made to carry on with the reactive protocol based on AODVv2, there is some progress on the reactive protocol specification -- not as big as desired, but still tangible -- and there are a couple of independent implementations out there, that already helped improving the spec. So, should the most coherent course of action not be to focus on being constructive, and on fostering this progress? For me, being constructive at wg level translates in the following: - Process the issues raised: retain the technical points, and filter out non-technical noise that unfortunately slipped in during recent turmoils. - Use modern logging tools: log the identified, valid technical points in the issue tracker. - Work better together: less rhetoric, more proposals of concrete fixes for entries that pop up in the issue tracker, by order of priority. I am convinced that if we did stick to the above, the desired progress will happen sooner, rather than later. Best regards, Emmanuel On Fri, Mar 7, 2014 at 2:30 PM, Don Sturek wrote: > Hi AB, > > I think the issue is that AODVv2 (or DYMO) has been selected as the proactive/reactive > routing protocol the MANET group has adopted to work on (and I disagree on > the topic of "missing messages" since I have never had that experience). > As a result of AODVv2's selection, we should expect the editor(s) to be > responsive to input to the group. > > I think if you go to the MANET e-mail reflector (and, yes, I expect it > will work for you), you will see that the editing group for this draft has > failed to be responsive (over a very long period of time). > > It would be great not to worry about old drafts as long as the new drafts > have incorporated all of the changes needed by the group over time........ > > Don > > > From: Abdussalam Baryun > Date: Thursday, March 6, 2014 11:53 PM > To: Don Sturek > Cc: "Charles E. Perkins" , Mobile Ad Hoc Networks > mailing list > Subject: [manet] Remaining issues affecting the AODVv2 specification > > Hi Don, > > I think the issue of not missing messages happens a lot to me with most of > the IETF editors related to I-Ds. The best tool is the ticket tracker, > because discussion messages are some how not focused on the I-D but may go > through theories/imaginations/possibilities/personality/etc. > > When the AODVv2 started -00 with new author team it was not DYMO any > more, and I think that no message has been not replied to since > AODVv2-00 published in March 2013. Yes there was a reminder from > participant on DYMO draft comments, but I am not sure the authors have time > to discuss DYMO document after it mature and the WG dropping it and > starting adopting another document which is AODVv2. > > I recommend the WG to focus on active documents so we can progress our > work. Otherwise we will not have time. > > AB > > On Thursday, March 6, 2014, Don Sturek wrote: > >> Hi Charlie, >> >> It would be worth (going forward) addressing issues as they come up on >> the reflector rather than having to mine these topics out of the reflector >> archives months later. >> >> Most folks have limited time to spend reviewing drafts. Ignoring >> comments for several months does not help resolving these issues since in >> many cases the comment and context is lost after a long period of time. >> >> Don >> >> >> From: "Charles E. Perkins" >> Organization: Blue Skies >> Date: Thursday, March 6, 2014 1:26 PM >> To: Abdussalam Baryun >> Cc: Mobile Ad Hoc Networks mailing list >> Subject: Re: [manet] Remaining issues affecting the AODVv2 specification >> >> >> Hello Abdussalam, >> >> Before the draft goes to last call, we need to resolve the >> open issues that were posted to the mailing list. When I >> mentioned that the earlier issues on the issue tracker had >> been resolved, that did not include the other issues that >> were not posted to the issue tracker. As mentioned in my >> previous email, I will take care of posting them to the tracker >> so that the resolution process will be easier to follow. >> >> Regards, >> Charlie P. >> >> On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: >> >> >> Ok so I understand from your message below that authors confirm that the >> draft is ready complete for WG to review and comment their open issues. >> >> AB >> >> On Thursday, March 6, 2014, Charles E. Perkins wrote: >> >>> >>> Hello Abdussalam, >>> >>> Actually, all of the issues were resolved. Then, apparently, the >>> issues page crashed, and some recent updates to the issues were >>> lost. However, they were sent to the mailing list, and so are >>> recoverable, with a nontrivial amount of work amounting to >>> an archaeological expedition through the mailing list archives. >>> >>> I wanted to have time to do this, but so far have not. If anyone >>> wants to volunteer to recover the issue-tracker updates from the >>> mailing list, that would be terrific. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>> >>> Hi Charles, >>> >>> I just had before a comment on the open tickets, were they all >>> closed, because I think may be open. Seems most MANET WG don't care about >>> tickets but I like to track and I remember that the AD did mention it's >>> importance. >>> >>> For me I will review new draft and comment, but if the authors have no >>> more pending issues to update, please confirm (sorry that I was not able to >>> remember if there are confirmation from authors that draft is ready or not, >>> also need their confirm of final points of open issues for next draft if >>> not resolved). >>> >>> Best Regards >>> >>> AB >>> >>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>> >>>> Hello folks, >>>> >>>> Part of the job of finishing the AODVv2 specification will be to comb >>>> the mailing list for issues that are still not resolved. If there are >>>> any specific issues that have not been gotten proper attention, I hope >>>> to find them -- but if anyone would like to help by bringing them >>>> up here on the mailing list, that will be appreciated. >>>> >>>> -- >>>> Regards, >>>> Charlie P. >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ manet mailing list >> manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a1136ab0605af7b04f4055bfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
My take = on this. I think we all agree that progress in the MANET working group has = been painfully slow over the last decade.The proactive protocol took 10+ ye= ars to converge, and the reactive protocol is not progressing as quickly as= desired either. 

Now, from a 30k feet p= erspective, even one more year delay for AODVv2 would mean less than 10% mo= re time that was needed for OLSRv2... So from this perspective, maybe we sh= ould not pick too much on AODVv2 and we should not get too alarmed: it seem= s it is the fate of MANET to deal with such slow progress. While the (non-t= echnical) reasons for that fate could also be discussed, I'm not certai= n this particular thread is the most appropriate to do so.

Since the decision was= made to carry on with the reactive protocol based on AODVv2, there is some= progress on the reactive protocol specification -- not as big as desired, = but still tangible -- and there are a couple of independent implementations= out there, that already helped improving the spec.

So, should the most co= herent course of action not be to focus on being constructive, and on foste= ring this progress? For me, being constructive at wg level translates in th= e following:

     - = Process the issues raised: retain the technical points, and filter out non-= technical noise that unfortunately slipped in during recent turmoils.
    &n= bsp;- Use modern logging tools: log the identified, valid technical points = in the issue tracker.
     - Work better together: less rhetoric, more = proposals of concrete fixes for entries that pop up in the issue tracker, b= y order of priority.

I am convinced that if= we did stick to the above, the desired progress will happen sooner, rather= than later.

Best regards,

Emmanuel




On Fri, Mar 7= , 2014 at 2:30 PM, Don Sturek <d.sturek@att.net> wrote:
Hi AB,

I think the issue is that AOD= Vv2 (or DYMO) has been selected as the proactive/reactive routing protocol the MANET group has adopted to= work on (and I disagree on the topic of "missing messages" since= I have never had that experience).   As a result of AODVv2's sele= ction, we should expect the editor(s) to be responsive to input to the grou= p.

I think if you go to the MANET e-mail reflector (and, y= es, I expect it will work for you), you will see that the editing group for= this draft has failed to be responsive (over a very long period of time).<= /div>

It would be great not to worry about old drafts as long= as the new drafts have incorporated all of the changes needed by the group= over time……..

Don


From: Abdussalam Baryun <abdussalambaryun@= gmail.com>
Date: Thursda= y, March 6, 2014 11:53 PM
To: Don Sturek <d.sturek@att.net>
Cc: "Charles E. Perkins" <charliep@computer.o= rg>, Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: [manet] Remaining issues = affecting the AODVv2 specification
Hi Don,

I think the issue of not missing messages= happens a lot to me with most of the IETF editors related to I-Ds. Th= e best tool is the ticket tracker, because discussion messages are some how= not focused on the I-D but may go through theories/imaginations/possibilit= ies/personality/etc. 

When the AODVv2 started -00 with new author team i= t was not DYMO any more, and I think that no message has been not repl= ied to since AODVv2-00 published in March 2013. Yes there was a remind= er from participant on DYMO draft comments, but I am not sure the auth= ors have time to discuss DYMO document after it mature and the WG= dropping it and starting adopting another document which is AODVv2.&n= bsp;

I recommend the WG to focus on active documents so= we can progress our work. Otherwise we will not have time. 

AB

On Thursday, March 6, 2014, Don Sturek wrote:
Hi Charlie,

It would be worth (going= forward) addressing issues as they come up on the reflector rather than ha= ving to mine these topics out of the reflector archives months later.

Most folks have limited time to spend reviewing drafts.=  Ignoring comments for several months does not help resolving these i= ssues since in many cases the comment and context is lost after a long peri= od of time.

Don


From: "Charles E. Perkins&quo= t; <charliep@computer.org>
Organization: Blue Skies
Date:= Thursday, March 6, 2014 1:26 PM
To: Abdussalam Baryun <abdus= salambaryun@gmail.com>
Cc: Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: Re: [manet] Remaining issues= affecting the AODVv2 specification

=20 =20 =20

Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets,&nb= sp;were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I = like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of = ;final points of open issues for next draft if not resolved). = ;

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.
--
Regards,
Charlie P.

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

--=20
Regards,
Charlie P.

--=20
Regards,
Charlie P.
_______________________________________________ manet mailing list manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet<= /div>

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


--001a1136ab0605af7b04f4055bfa-- From nobody Fri Mar 7 07:00:37 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF401A0282 for ; Fri, 7 Mar 2014 07:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Txrz__SXte0w for ; Fri, 7 Mar 2014 07:00:30 -0800 (PST) Received: from nm3-vm4.access.bullet.mail.gq1.yahoo.com (nm3-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC8A1A0285 for ; Fri, 7 Mar 2014 07:00:30 -0800 (PST) Received: from [216.39.60.175] by nm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Mar 2014 15:00:26 -0000 Received: from [67.195.22.118] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Mar 2014 15:00:26 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.gq1.yahoo.com with NNFMP; 07 Mar 2014 15:00:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1394204426; bh=w+yRCn2zScvlUiif1p9X1gml86EHsEpwkMbcCkxXlVM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type; b=3I+6W127lPaVMlmZtHEUJt1Gksvv3bw7++T4X3ttTPr+uCBHH3sNm1EL4qLRJUa6rQ0AKqYIDFf+w0B6q2TOet6Fhv1afE7PFnGAecb6aN0y+nEpTTY5n+29hXZo9KE7z78CK1EIXGdq23/DWAo89lkPRLO7iGagKaJmAzD38us= X-Yahoo-Newman-Id: 96102.53135.bm@smtp113.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .T0G3isVM1kfITAcCKhqInHz7DPeYfa0i2TVCmFSxxAyYDd Foa_GwfN2Sg9pvBpxON11RdTywjDyy9nEv8kcaGTTe1OhdxwA15mCNchn4IR FYw3pZvgSHCIMnmdwMFa27qnguM0gjwtzaiYqrYeRSF2rMCPPyqr2Ttm_pu4 gq4DaqwgIs4W5FnkWDwcF6pN8BkKYUiNMiy5NwtTyF7XFn6C3dgo2sUNnccl 6kda3hK9D.Q3APR26ngRF9g6iW0Y_SG7xDS3YWA77aJEwpnAOT2hZ49IShQ3 UCzdReOwBHAe61ofj.EhIj5u.O9hawmfDewbmAEt6JS7Vo8YTs26lEy3Ricd vgV6hIrFIzXuYn8HrTygtBaC0BMTGfzhfCLS3cPm3zYtm_A4MeJP7XZJ3fMZ WNZHcdvZ4CM9BmraxF8KKUjiT4wfcccyaQ8eq698r8ekcMqmSFKYaM8s44Dm eFyV.2m01iCBBD3syZI2JvNiL2vNb.I95ZGLkGdVR97VicmqP2b4XXncNI2w emQwpDp46D0aQ1ty6NWWNRRO0mD2Z2.X0r2Fm2lh0B1JSkdbJu9RmxpNyHm3 tzqj4bA-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@69.111.215.218 with plain [67.195.15.5]) by smtp113.sbc.mail.gq1.yahoo.com with SMTP; 07 Mar 2014 07:00:26 -0800 PST User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 07 Mar 2014 07:00:22 -0800 From: Don Sturek To: Emmanuel Baccelli , MANET IETF Message-ID: Thread-Topic: [manet] Remaining issues affecting the AODVv2 specification References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3477020424_408080" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/nPEZbXSCuN_UiMRlTlA1YZDNS9k Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 15:00:35 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3477020424_408080 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable +1 if we can apply some schedule metric around the bulleted items below=8A=8A.. Don From: Emmanuel Baccelli Date: Friday, March 7, 2014 6:48 AM To: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification Hi all, My take on this. I think we all agree that progress in the MANET working group has been painfully slow over the last decade.The proactive protocol took 10+ years to converge, and the reactive protocol is not progressing as quickly as desired either. Now, from a 30k feet perspective, even one more year delay for AODVv2 would mean less than 10% more time that was needed for OLSRv2... So from this perspective, maybe we should not pick too much on AODVv2 and we should not get too alarmed: it seems it is the fate of MANET to deal with such slow progress. While the (non-technical) reasons for that fate could also be discussed, I'm not certain this particular thread is the most appropriate t= o do so. Since the decision was made to carry on with the reactive protocol based on AODVv2, there is some progress on the reactive protocol specification -- no= t as big as desired, but still tangible -- and there are a couple of independent implementations out there, that already helped improving the spec. So, should the most coherent course of action not be to focus on being constructive, and on fostering this progress? For me, being constructive at wg level translates in the following: - Process the issues raised: retain the technical points, and filter out non-technical noise that unfortunately slipped in during recent turmoils. - Use modern logging tools: log the identified, valid technical points in the issue tracker. - Work better together: less rhetoric, more proposals of concrete fixe= s for entries that pop up in the issue tracker, by order of priority. I am convinced that if we did stick to the above, the desired progress will happen sooner, rather than later. Best regards, Emmanuel On Fri, Mar 7, 2014 at 2:30 PM, Don Sturek wrote: > Hi AB, >=20 > I think the issue is that AODVv2 (or DYMO) has been selected as the > proactive/reactive routing protocol the MANET group has adopted to work o= n > (and I disagree on the topic of "missing messages" since I have never had= that > experience). As a result of AODVv2's selection, we should expect the > editor(s) to be responsive to input to the group. >=20 > I think if you go to the MANET e-mail reflector (and, yes, I expect it wi= ll > work for you), you will see that the editing group for this draft has fai= led > to be responsive (over a very long period of time). >=20 > It would be great not to worry about old drafts as long as the new drafts= have > incorporated all of the changes needed by the group over time=8A=8A.. >=20 > Don >=20 >=20 > From: Abdussalam Baryun > Date: Thursday, March 6, 2014 11:53 PM > To: Don Sturek > Cc: "Charles E. Perkins" , Mobile Ad Hoc Networks > mailing list > Subject: [manet] Remaining issues affecting the AODVv2 specification >=20 > Hi Don, >=20 > I think the issue of not missing messages happens a lot to me with most o= f the > IETF editors related to I-Ds. The best tool is the ticket tracker, becaus= e > discussion messages are some how not focused on the I-D but may go throug= h > theories/imaginations/possibilities/personality/etc. >=20 > When the AODVv2 started -00 with new author team it was not DYMO any more= , and > I think that no message has been not replied to since AODVv2-00 published= in > March 2013. Yes there was a reminder from participant on DYMO draft comme= nts, > but I am not sure the authors have time to discuss DYMO document after it > mature and the WG dropping it and starting adopting another document whic= h is > AODVv2.=20 >=20 > I recommend the WG to focus on active documents so we can progress our wo= rk. > Otherwise we will not have time. >=20 > AB >=20 > On Thursday, March 6, 2014, Don Sturek wrote: >> Hi Charlie, >>=20 >> It would be worth (going forward) addressing issues as they come up on t= he >> reflector rather than having to mine these topics out of the reflector >> archives months later. >>=20 >> Most folks have limited time to spend reviewing drafts. Ignoring commen= ts >> for several months does not help resolving these issues since in many ca= ses >> the comment and context is lost after a long period of time. >>=20 >> Don >>=20 >>=20 >> From: "Charles E. Perkins" >> Organization: Blue Skies >> Date: Thursday, March 6, 2014 1:26 PM >> To: Abdussalam Baryun >> Cc: Mobile Ad Hoc Networks mailing list >> Subject: Re: [manet] Remaining issues affecting the AODVv2 specificatio= n >>=20 >> =20 >> =20 >> Hello Abdussalam, >> =20 >> Before the draft goes to last call, we need to resolve the >> open issues that were posted to the mailing list. When I >> mentioned that the earlier issues on the issue tracker had >> been resolved, that did not include the other issues that >> were not posted to the issue tracker. As mentioned in my >> previous email, I will take care of posting them to the tracker >> so that the resolution process will be easier to follow. >> =20 >> Regards, >> Charlie P. >> =20 >> =20 >> On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: >> =20 >> =20 >>>=20 >>> Ok so I understand from your message below that authors confirm that t= he >>> draft is ready complete for WG to review and comment their open issues. >>>=20 >>> =20 >>> =20 >>> AB >>> =20 >>>=20 >>> On Thursday, March 6, 2014, Charles E. Perkins wrote: >>> =20 >>>> =20 >>>> =20 >>>> Hello Abdussalam, >>>> =20 >>>> Actually, all of the issues were resolved. Then, apparently, the >>>> issues page crashed, and some recent updates to the issues were >>>> lost. However, they were sent to the mailing list, and so are >>>> recoverable, with a nontrivial amount of work amounting to >>>> an archaeological expedition through the mailing list archives. >>>> =20 >>>> I wanted to have time to do this, but so far have not. If anyone >>>> wants to volunteer to recover the issue-tracker updates from the >>>> mailing list, that would be terrific. >>>> =20 >>>> Regards, >>>> Charlie P. >>>> =20 >>>> =20 >>>> =20 >>>> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>>> =20 >>>> =20 >>>>> Hi Charles,=20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> I just had before a comment on the open tickets, were they all closed= , >>>>> because I think may be open. Seems most MANET WG don't care about tic= kets >>>>> but I like to track and I remember that the AD did mention it's >>>>> importance.=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> For me I will review new draft and comment, but if the authors have n= o >>>>> more pending issues to update, please confirm (sorry that I was not a= ble >>>>> to remember if there are confirmation from authors that draft is read= y or >>>>> not, also need their confirm of final points of open issues for next = draft >>>>> if not resolved). >>>>> =20 >>>>>=20 >>>>> =20 >>>>> Best Regards >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> AB >>>>> =20 >>>>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>>>> =20 >>>>>> Hello folks, >>>>>> =20 >>>>>> Part of the job of finishing the AODVv2 specification will be to co= mb >>>>>> the mailing list for issues that are still not resolved. If there = are >>>>>> any specific issues that have not been gotten proper attention, I h= ope >>>>>> to find them -- but if anyone would like to help by bringing them >>>>>> up here on the mailing list, that will be appreciated. >>>>>> =20 >>>>>> --=20 >>>>>> Regards, >>>>>> Charlie P. >>>>>> =20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>> =20 >>>> --=20 >>>> Regards, >>>> Charlie P. >>>> =20 >>>> =20 >>> =20 >>> =20 >> =20 >> =20 >> --=20 >> Regards, >> Charlie P. >> =20 >> _______________________________________________ manet mailing list >> manet@ietf.orghttps://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 --B_3477020424_408080 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
+1 if we can apply some sc= hedule metric around the bulleted items below……..

=
Don


From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
D= ate: Friday, March 7, 2014 6:48 AM
To: MANET IETF <manet@ietf.org>
Subject: Re: [manet] Remain= ing issues affecting the AODVv2 specification











On Fri, Mar 7, 2014 at 2= :30 PM, Don Sturek <d.sturek@att.net> wrote:
Hi AB,

I think the issue is that AO= DVv2 (or DYMO) has been selected as the proactive/reactive routing protocol the MANET group has adopted to wo= rk on (and I disagree on the topic of "missing messages" since I have never = had that experience).   As a result of AODVv2's selection, we should ex= pect the editor(s) to be responsive to input to the group.

I think if you go to the MANET e-mail reflector (and, yes, I expect = it will work for you), you will see that the editing group for this draft ha= s failed to be responsive (over a very long period of time).

<= /div>
It would be great not to worry about old drafts as long as the new= drafts have incorporated all of the changes needed by the group over time&#= 8230;…..

Don


From: Abdussalam B= aryun <abduss= alambaryun@gmail.com>
Date: = Thursday, March 6, 2014 11:53 PM
To: Don Sturek <d.sture= k@att.net>
Cc: "Charles E. = Perkins" <charliep= @computer.org>, Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: [manet] Remaining issues affecting the AODV= v2 specification

Hi Don,
I think the issue of not missing messages happens a lot to me w= ith most of the IETF editors related to I-Ds. The best tool is the tick= et tracker, because discussion messages are some how not focused on the I-D = but may go through theories/imaginations/possibilities/personality/etc. = ;

When the AODVv2 started -00 with new author team&= nbsp;it was not DYMO any more, and I think that no message has been not= replied to since AODVv2-00 published in March 2013. Yes there was a re= minder from participant on DYMO draft comments, but I am not sure the a= uthors have time to discuss DYMO document after it mature and the = WG dropping it and starting adopting another document which is AODVv2.&= nbsp;

I recommend the WG to focus on active do= cuments so we can progress our work. Otherwise we will not have time. <= /div>

AB

On Thursday, March 6, 2014, Don Sturek w= rote:
Hi Charlie,

It would be worth (going forward) addressing issues as they come up o= n the reflector rather than having to mine these topics out of the reflector= archives months later.

Most folks have limited tim= e to spend reviewing drafts.  Ignoring comments for several months does= not help resolving these issues since in many cases the comment and context= is lost after a long period of time.

Don


Fro= m: "Charles E. Perkins" <charliep@computer.org>
Organization: Blue Skies
Date: Thursday, March 6, 2014 1:26 PM
To: Abdussalam Baryun <abdussalambaryun@= gmail.com>
Cc: Mobile Ad Ho= c Networks mailing list <manet@ietf.org>
Subject: Re: [manet] Remaining issues affecting the AODV= v2 specification


Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in my previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and so= are
recoverable, with a nontrivial amount of work amounting to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  If= anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the open tickets,&nb= sp;were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I like= to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able to remember if there are confirmation from authors that draft is ready or not, also need their confirm of = ;final points of open issues for next draft if not resolved). = ;

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be appreciated.
--
Regards,
Charlie P.

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

-- 
Regards,
Charlie P.

-- 
Regards,
Charlie P.
_______________________________________________ manet mailing list manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet
=

____________________________= ___________________
manet mailing list
manet@ietf.orghttps= ://www.ietf.org/mailman/listinfo/manet


_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/= mailman/listinfo/manet --B_3477020424_408080-- From nobody Fri Mar 7 07:35:42 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBFB1A0026 for ; Fri, 7 Mar 2014 07:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF62rfQadpN8 for ; Fri, 7 Mar 2014 07:35:35 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id A495C1A0294 for ; Fri, 7 Mar 2014 07:35:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A98391C07B0; Fri, 7 Mar 2014 07:35:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.207.197.247] (unknown [31.55.17.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id ED1051C04AB; Fri, 7 Mar 2014 07:35:29 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_2D187E8F-894E-4B9E-92F8-B0AF0A53A2D6" From: Thomas Heide Clausen In-Reply-To: Date: Fri, 7 Mar 2014 16:35:38 +0100 Message-Id: References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> To: "Dr. Emmanuel Baccelli" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_-cOSTjxDxrJPxHndwsIJ7AoTn8 Cc: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 15:35:40 -0000 --Apple-Mail=_2D187E8F-894E-4B9E-92F8-B0AF0A53A2D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Don't forget, Emmanuel, that several years back - after the reactive = working-group protocol development was officially declared dead by the = WG chairs, who actually at the same time asked in a meeting if there = were somebody willing to pick up reactive protocol development - an = alternative reactive protocol specification emerged out of actual = deployed code.=20 That alternative reactive protocol development was backed by a large and = diverse community. There were (are) implementations, deployments, = documented interoperability of that alternative reactive protocol. There = were none of the WG protocol at the time - as there still are none, = today. Also, ready-baked specifications of that alternative reactive protocol = were proposed to the working group, from which interoperable = implementations had already been developed. That community is, obviously, standing by and watching in befuddlement = that (i) they were excluded from the (suddenly revived) working group = protocol, that (ii) the revived working-group protocol - now, several = years later - still is not at an implementable state ready for = standardisation, with no actual deployments, and that (iii) the comments = and issues raised by members of that community. to the suddenly revived = working-group protocol, were - and are - actively ignored. This has nothing to do with using tools, or rhetorics, and has certainly = nothing to do with "non-techincal noise" either -- it has everything to = do with following, or ignoring, the IETF credo of "rough consensus and = running code". As for your comment on "some progress on the reactive protocol = specification -- not as big as desired, but still tangible", I refer you = to: http://www.ietf.org/mail-archive/web/manet/current/msg16049.html I honestly have a hard time imagining that not addressing 4 year old = review comments and raised issues can be construed as "tangible = progress" Respectfully, Thomas On 07 Mar 2014, at 15:48 , Emmanuel Baccelli = wrote: > Hi all, >=20 > My take on this. I think we all agree that progress in the MANET = working group has been painfully slow over the last decade.The proactive = protocol took 10+ years to converge, and the reactive protocol is not = progressing as quickly as desired either.=20 >=20 > Now, from a 30k feet perspective, even one more year delay for AODVv2 = would mean less than 10% more time that was needed for OLSRv2... So from = this perspective, maybe we should not pick too much on AODVv2 and we = should not get too alarmed: it seems it is the fate of MANET to deal = with such slow progress. While the (non-technical) reasons for that fate = could also be discussed, I'm not certain this particular thread is the = most appropriate to do so. >=20 > Since the decision was made to carry on with the reactive protocol = based on AODVv2, there is some progress on the reactive protocol = specification -- not as big as desired, but still tangible -- and there = are a couple of independent implementations out there, that already = helped improving the spec. >=20 > So, should the most coherent course of action not be to focus on being = constructive, and on fostering this progress? For me, being constructive = at wg level translates in the following: >=20 > - Process the issues raised: retain the technical points, and = filter out non-technical noise that unfortunately slipped in during = recent turmoils. > - Use modern logging tools: log the identified, valid technical = points in the issue tracker. > - Work better together: less rhetoric, more proposals of concrete = fixes for entries that pop up in the issue tracker, by order of = priority. >=20 > I am convinced that if we did stick to the above, the desired progress = will happen sooner, rather than later. >=20 > Best regards, >=20 > Emmanuel >=20 >=20 >=20 >=20 >=20 > On Fri, Mar 7, 2014 at 2:30 PM, Don Sturek wrote: > Hi AB, >=20 > I think the issue is that AODVv2 (or DYMO) has been selected as the = proactive/reactive routing protocol the MANET group has adopted to work = on (and I disagree on the topic of "missing messages" since I have never = had that experience). As a result of AODVv2's selection, we should = expect the editor(s) to be responsive to input to the group. >=20 > I think if you go to the MANET e-mail reflector (and, yes, I expect it = will work for you), you will see that the editing group for this draft = has failed to be responsive (over a very long period of time). >=20 > It would be great not to worry about old drafts as long as the new = drafts have incorporated all of the changes needed by the group over = time=85=85.. >=20 > Don >=20 >=20 > From: Abdussalam Baryun > Date: Thursday, March 6, 2014 11:53 PM > To: Don Sturek > Cc: "Charles E. Perkins" , Mobile Ad Hoc = Networks mailing list > Subject: [manet] Remaining issues affecting the AODVv2 specification >=20 > Hi Don, >=20 > I think the issue of not missing messages happens a lot to me with = most of the IETF editors related to I-Ds. The best tool is the ticket = tracker, because discussion messages are some how not focused on the I-D = but may go through theories/imaginations/possibilities/personality/etc.=20= >=20 > When the AODVv2 started -00 with new author team it was not DYMO any = more, and I think that no message has been not replied to since = AODVv2-00 published in March 2013. Yes there was a reminder from = participant on DYMO draft comments, but I am not sure the authors have = time to discuss DYMO document after it mature and the WG dropping it and = starting adopting another document which is AODVv2.=20 >=20 > I recommend the WG to focus on active documents so we can progress our = work. Otherwise we will not have time.=20 >=20 > AB >=20 > On Thursday, March 6, 2014, Don Sturek wrote: > Hi Charlie, >=20 > It would be worth (going forward) addressing issues as they come up on = the reflector rather than having to mine these topics out of the = reflector archives months later. >=20 > Most folks have limited time to spend reviewing drafts. Ignoring = comments for several months does not help resolving these issues since = in many cases the comment and context is lost after a long period of = time. >=20 > Don >=20 >=20 > From: "Charles E. Perkins" > Organization: Blue Skies > Date: Thursday, March 6, 2014 1:26 PM > To: Abdussalam Baryun > Cc: Mobile Ad Hoc Networks mailing list > Subject: Re: [manet] Remaining issues affecting the AODVv2 = specification >=20 >=20 > Hello Abdussalam, >=20 > Before the draft goes to last call, we need to resolve the > open issues that were posted to the mailing list. When I > mentioned that the earlier issues on the issue tracker had > been resolved, that did not include the other issues that > were not posted to the issue tracker. As mentioned in my > previous email, I will take care of posting them to the tracker > so that the resolution process will be easier to follow. >=20 > Regards, > Charlie P. >=20 > On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: >>=20 >> Ok so I understand from your message below that authors confirm that = the draft is ready complete for WG to review and comment their open = issues.=20 >>=20 >> AB >>=20 >> On Thursday, March 6, 2014, Charles E. Perkins wrote: >>=20 >> Hello Abdussalam, >>=20 >> Actually, all of the issues were resolved. Then, apparently, the >> issues page crashed, and some recent updates to the issues were >> lost. However, they were sent to the mailing list, and so are >> recoverable, with a nontrivial amount of work amounting to >> an archaeological expedition through the mailing list archives. >>=20 >> I wanted to have time to do this, but so far have not. If anyone >> wants to volunteer to recover the issue-tracker updates from the >> mailing list, that would be terrific. >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>> Hi Charles, >>>=20 >>> I just had before a comment on the open tickets, were they all = closed, because I think may be open. Seems most MANET WG don't care = about tickets but I like to track and I remember that the AD did mention = it's importance.=20 >>>=20 >>> For me I will review new draft and comment, but if the authors have = no more pending issues to update, please confirm (sorry that I was not = able to remember if there are confirmation from authors that draft is = ready or not, also need their confirm of final points of open issues for = next draft if not resolved).=20 >>>=20 >>> Best Regards >>>=20 >>> AB >>>=20 >>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>> Hello folks, >>>=20 >>> Part of the job of finishing the AODVv2 specification will be to = comb >>> the mailing list for issues that are still not resolved. If there = are >>> any specific issues that have not been gotten proper attention, I = hope >>> to find them -- but if anyone would like to help by bringing them >>> up here on the mailing list, that will be appreciated. >>>=20 >>> --=20 >>> Regards, >>> Charlie P. >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> --=20 >> Regards, >> Charlie P. >=20 > --=20 > Regards, > Charlie P. > _______________________________________________ manet mailing list = manet@ietf.orghttps://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=_2D187E8F-894E-4B9E-92F8-B0AF0A53A2D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Don't = forget, Emmanuel, that several years back - after the reactive = working-group protocol development was officially declared dead by the = WG chairs, who actually at the same time asked in a meeting if there = were somebody willing to pick up reactive protocol development - an = alternative reactive protocol specification emerged out of actual = deployed code. 

That alternative reactive = protocol development was backed by a large and diverse community. There = were (are) implementations, deployments, documented interoperability of = that alternative reactive protocol. There were none of the WG protocol = at the time - as there still are none, = today.

Also, ready-baked specifications of that = alternative reactive protocol were proposed to the working group, from = which interoperable implementations had already been = developed.

That community is, obviously, standing by = and watching in befuddlement that (i) they were excluded from the = (suddenly revived) working group protocol, that (ii) the revived = working-group protocol - now, several years later - still is not at an = implementable state ready for standardisation, with no actual = deployments, and that (iii) the comments and issues raised by members of = that community. to the suddenly revived working-group protocol, were - = and are - actively ignored.

This has nothing to = do with using tools, or rhetorics, and has certainly nothing to do with =  "non-techincal noise" either -- it has everything to do with = following, or ignoring, the IETF credo of "rough consensus and running = code".

As for your comment on "some progress on the = reactive protocol specification -- not as big as desired, but still = tangible", I refer you to:

=

I honestly have a hard time imagining that not = addressing 4 year old review comments and raised issues can be construed = as "tangible = progress"

Respectfully,

= Thomas

On 07 Mar 2014, at 15:48 , = Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr&= gt; wrote:

Hi all,

My take on this. I = think we all agree that progress in the MANET working group has been = painfully slow over the last decade.The proactive protocol took 10+ = years to converge, and the reactive protocol is not progressing as = quickly as desired either. 

Now, from a 30k = feet perspective, even one more year delay for AODVv2 would mean less = than 10% more time that was needed for OLSRv2... So from this = perspective, maybe we should not pick too much on AODVv2 and we should = not get too alarmed: it seems it is the fate of MANET to deal with such = slow progress. While the (non-technical) reasons for that fate could = also be discussed, I'm not certain this particular thread is the most = appropriate to do so.

Since the decision = was made to carry on with the reactive protocol based on AODVv2, there = is some progress on the reactive protocol specification -- not as big as = desired, but still tangible -- and there are a couple of independent = implementations out there, that already helped improving the spec.

So, should the = most coherent course of action not be to focus on being constructive, = and on fostering this progress? For me, being constructive at wg level = translates in the following:

    =  - Process the issues raised: retain the technical points, and = filter out non-technical noise that unfortunately slipped in during = recent turmoils.
    =  - Use modern logging tools: log the identified, valid technical = points in the issue tracker.
    =  - Work better together: less rhetoric, more proposals of concrete = fixes for entries that pop up in the issue tracker, by order of = priority.

I am convinced = that if we did stick to the above, the desired progress will happen = sooner, rather than later.

Best = regards,

Emmanuel





On Fri, = Mar 7, 2014 at 2:30 PM, Don Sturek <d.sturek@att.net> wrote:
Hi AB,

I think the issue is that = AODVv2 (or DYMO) has been selected as the proactive/reactive routing = protocol the MANET group has adopted to work on (and I disagree on the = topic of "missing messages" since I have never had that experience). =   As a result of AODVv2's selection, we should expect the editor(s) = to be responsive to input to the group.

I think if you go to the MANET e-mail reflector = (and, yes, I expect it will work for you), you will see that the editing = group for this draft has failed to be responsive (over a very long = period of time).

It would be great not to worry about old drafts as = long as the new drafts have incorporated all of the changes needed by = the group over = time=85=85..

Don


From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Thursday, March 6, 2014 11:53 = PM
To: Don Sturek <d.sturek@att.net>
Cc: "Charles E. Perkins" <charliep@computer.org>, Mobile Ad Hoc Networks = mailing list <manet@ietf.org>
Subject: [manet] Remaining = issues affecting the AODVv2 specification

Hi Don,

I think the issue = of not missing messages happens a lot to me with most of the IETF = editors related to I-Ds. The best tool is the ticket tracker, because = discussion messages are some how not focused on the I-D but may go = through theories/imaginations/possibilities/personality/etc. 

When the AODVv2 started -00 with new author = team it was not DYMO any more, and I think that no message has = been not replied to since AODVv2-00 published in March 2013. Yes = there was a reminder from participant on DYMO draft comments, but I = am not sure the authors have time to discuss DYMO document = after it mature and the WG dropping it and starting = adopting another document which is AODVv2. 

I recommend the WG to focus on active documents = so we can progress our work. Otherwise we will not have = time. 

AB

On Thursday, March 6, = 2014, Don Sturek wrote:
Hi Charlie,

It would be worth (going = forward) addressing issues as they come up on the reflector rather than = having to mine these topics out of the reflector archives months = later.

Most folks have limited time to spend reviewing = drafts.  Ignoring comments for several months does not help = resolving these issues since in many cases the comment and context is = lost after a long period of time.

Don


From: "Charles E. Perkins" = <charliep@computer.org>
Organization: Blue Skies
Date: Thursday, March 6, 2014 1:26 = PM
To: Abdussalam Baryun = <abdussalambaryun@gmail.com>
Cc: Mobile Ad Hoc Networks mailing = list <manet@ietf.org>
Subject: Re: [manet] Remaining issues = affecting the AODVv2 specification

=20 =20 =20

Hello Abdussalam,

Before the draft goes to last call, we need to resolve the
open issues that were posted to the mailing list.  When I
mentioned that the earlier issues on the issue tracker had
been resolved, that did not include the other issues that
were not posted to the issue tracker.   As mentioned in = my
previous email, I will take care of posting them to the tracker
so that the resolution process will be easier to follow.

Regards,
Charlie P.

On 3/6/2014 11:35 AM, Abdussalam Baryun wrote:

Ok so I understand from your message below that authors = confirm that the draft is ready complete for WG to review and comment their open issues. 

AB

On Thursday, March 6, 2014, Charles E. Perkins wrote:

Hello Abdussalam,

Actually, all of the issues were resolved.  Then, apparently, the
issues page crashed, and some recent updates to the issues were
lost.  However, they were sent to the mailing list, and = so are
recoverable, with a nontrivial amount of work amounting = to
an archaeological expedition through the mailing list archives.

I wanted to have time to do this, but so far have not.  = If anyone
wants to volunteer to recover the issue-tracker updates from the
mailing list, that would be terrific.

Regards,
Charlie P.


On 3/6/2014 8:16 AM, Abdussalam Baryun wrote:
Hi Charles,

I just had before a comment on the = open tickets, were they all closed, because I think may be open. Seems most MANET WG don't care about tickets but I = like to track and I remember that the AD did mention it's importance. 

For me I will review new draft and comment, but if the authors have no more pending issues to update, please confirm (sorry that I was not able = to remember if there are confirmation from authors that draft is ready or not, also need their confirm = of final points of open issues for next draft if not = resolved). 

Best Regards

AB

On Wednesday, March 5, 2014, Charles E. Perkins = wrote:
Hello folks,

Part of the job of finishing the AODVv2 specification will be to comb
the mailing list for issues that are still not resolved.  If there are
any specific issues that have not been gotten proper attention, I hope
to find them -- but if anyone would like to help by bringing them
up here on the mailing list, that will be = appreciated.

--
Regards,
Charlie P.

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

--=20
Regards,
Charlie P.

--=20
Regards,
Charlie P.
_______________________________________________ manet mailing list manet@ietf.orghttps://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=_2D187E8F-894E-4B9E-92F8-B0AF0A53A2D6-- From nobody Fri Mar 7 07:36:22 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDA81A0294 for ; Fri, 7 Mar 2014 07:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fXXEUP0Fqsp for ; Fri, 7 Mar 2014 07:36:18 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 518C81A00FE for ; Fri, 7 Mar 2014 07:36:17 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id x48so5126555wes.38 for ; Fri, 07 Mar 2014 07:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CQeydYD+KMta1E4hRCqWqbqaH2bNtFN/md0fmYhCPGQ=; b=KnmEvgOlLBmquH2GZ7VYPIHJsq5V5Cfr+d7yed6qK214B696KKRNGttQgZRM/fV8uq POPUPcKagLlCa+Stxp9e4rmLvXAHGY6bN2MiQhW5jgM3n31jrtY+J2s8MnyDlubLRPMp ZAqxlHyU5YeGeiMuHVGCZHNlkldDIQgGfM+UXKPw3Yd3WjLI/CEgSIwUa4n4Jya+fS+Y /3kaF4l6tuQja5jul2exw0Yfp8l3djWKlGj0aS0Ov42pN4BYF1c4RLUdSPH5n+9vvOC1 Vqs1ZeVNdoqhQYkBOODx1i1ciwCbtN1OZK0dROJ44wxbB4HbhDLCpcPTBJy89WkuZG0z 4/+g== X-Received: by 10.194.234.5 with SMTP id ua5mr4185232wjc.93.1394206572413; Fri, 07 Mar 2014 07:36:12 -0800 (PST) Received: from [192.168.112.235] (sphinx.lix.polytechnique.fr. [193.55.176.1]) by mx.google.com with ESMTPSA id xt1sm11283613wjb.17.2014.03.07.07.36.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 07:36:11 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jiazi Yi In-Reply-To: Date: Fri, 7 Mar 2014 16:36:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C5B6776-34AB-4575-93FD-81483CE25D38@gmail.com> References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hU3E_P_OyLM5oDXmbu1-ZU5etYk Cc: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 15:36:21 -0000 Hi,=20 I would support the bulleted items, but what you said at the beginning = is very hard for me to agree with.=20 > My take on this. I think we all agree that progress in the MANET = working group has been painfully slow over the last decade.The proactive = protocol took 10+ years to converge, and the reactive protocol is not = progressing as quickly as desired either.=20 Even it takes a lot of time for OLSRv2 to converge, the last 10+ years = are with numerous efforts: 5 interop events, 10+ RFC/Internet Drafts, = countless discussions, implementations.=20 >=20 > Now, from a 30k feet perspective, even one more year delay for AODVv2 = would mean less than 10% more time that was needed for OLSRv2... The current AODVv2 draft (previously called DYMO) is actually dated from = Jan 2005 as WG document. So I would say so far, it has taken almost the same time as OLSRv2, and = we don't know how much more time it will need.=20 > So from this perspective, maybe we should not pick too much on AODVv2 = and we should not get too alarmed: it seems it is the fate of MANET to = deal with such slow progress. I think it's unfair to compare AODVv2 and OLSRv2 in this way.=20 Having seen part of the work that have been done around OLSRv2, if I was = one of the OLSRv2 co-authors, I would probably feel offended.=20 > While the (non-technical) reasons for that fate could also be = discussed, I'm not certain this particular thread is the most = appropriate to do so. I certainly agree with that. Hopefully that's what will happen in the = future. However, if it was the case 4 years ago, we won't have the issue = like this today.=20 cheers Jiazi On 07 Mar 2014, at 15:48 , Emmanuel Baccelli = wrote: > Hi all, >=20 > My take on this. I think we all agree that progress in the MANET = working group has been painfully slow over the last decade.The proactive = protocol took 10+ years to converge, and the reactive protocol is not = progressing as quickly as desired either.=20 >=20 > Now, from a 30k feet perspective, even one more year delay for AODVv2 = would mean less than 10% more time that was needed for OLSRv2... So from = this perspective, maybe we should not pick too much on AODVv2 and we = should not get too alarmed: it seems it is the fate of MANET to deal = with such slow progress. While the (non-technical) reasons for that fate = could also be discussed, I'm not certain this particular thread is the = most appropriate to do so. >=20 > Since the decision was made to carry on with the reactive protocol = based on AODVv2, there is some progress on the reactive protocol = specification -- not as big as desired, but still tangible -- and there = are a couple of independent implementations out there, that already = helped improving the spec. >=20 > So, should the most coherent course of action not be to focus on being = constructive, and on fostering this progress? For me, being constructive = at wg level translates in the following: >=20 > - Process the issues raised: retain the technical points, and = filter out non-technical noise that unfortunately slipped in during = recent turmoils. > - Use modern logging tools: log the identified, valid technical = points in the issue tracker. > - Work better together: less rhetoric, more proposals of concrete = fixes for entries that pop up in the issue tracker, by order of = priority. >=20 > I am convinced that if we did stick to the above, the desired progress = will happen sooner, rather than later. >=20 > Best regards, >=20 > Emmanuel >=20 >=20 >=20 >=20 >=20 > On Fri, Mar 7, 2014 at 2:30 PM, Don Sturek wrote: > Hi AB, >=20 > I think the issue is that AODVv2 (or DYMO) has been selected as the = proactive/reactive routing protocol the MANET group has adopted to work = on (and I disagree on the topic of "missing messages" since I have never = had that experience). As a result of AODVv2's selection, we should = expect the editor(s) to be responsive to input to the group. >=20 > I think if you go to the MANET e-mail reflector (and, yes, I expect it = will work for you), you will see that the editing group for this draft = has failed to be responsive (over a very long period of time). >=20 > It would be great not to worry about old drafts as long as the new = drafts have incorporated all of the changes needed by the group over = time=85=85.. >=20 > Don >=20 >=20 > From: Abdussalam Baryun > Date: Thursday, March 6, 2014 11:53 PM > To: Don Sturek > Cc: "Charles E. Perkins" , Mobile Ad Hoc = Networks mailing list > Subject: [manet] Remaining issues affecting the AODVv2 specification >=20 > Hi Don, >=20 > I think the issue of not missing messages happens a lot to me with = most of the IETF editors related to I-Ds. The best tool is the ticket = tracker, because discussion messages are some how not focused on the I-D = but may go through theories/imaginations/possibilities/personality/etc.=20= >=20 > When the AODVv2 started -00 with new author team it was not DYMO any = more, and I think that no message has been not replied to since = AODVv2-00 published in March 2013. Yes there was a reminder from = participant on DYMO draft comments, but I am not sure the authors have = time to discuss DYMO document after it mature and the WG dropping it and = starting adopting another document which is AODVv2.=20 >=20 > I recommend the WG to focus on active documents so we can progress our = work. Otherwise we will not have time.=20 >=20 > AB >=20 > On Thursday, March 6, 2014, Don Sturek wrote: > Hi Charlie, >=20 > It would be worth (going forward) addressing issues as they come up on = the reflector rather than having to mine these topics out of the = reflector archives months later. >=20 > Most folks have limited time to spend reviewing drafts. Ignoring = comments for several months does not help resolving these issues since = in many cases the comment and context is lost after a long period of = time. >=20 > Don >=20 >=20 > From: "Charles E. Perkins" > Organization: Blue Skies > Date: Thursday, March 6, 2014 1:26 PM > To: Abdussalam Baryun > Cc: Mobile Ad Hoc Networks mailing list > Subject: Re: [manet] Remaining issues affecting the AODVv2 = specification >=20 >=20 > Hello Abdussalam, >=20 > Before the draft goes to last call, we need to resolve the > open issues that were posted to the mailing list. When I > mentioned that the earlier issues on the issue tracker had > been resolved, that did not include the other issues that > were not posted to the issue tracker. As mentioned in my > previous email, I will take care of posting them to the tracker > so that the resolution process will be easier to follow. >=20 > Regards, > Charlie P. >=20 > On 3/6/2014 11:35 AM, Abdussalam Baryun wrote: >>=20 >> Ok so I understand from your message below that authors confirm that = the draft is ready complete for WG to review and comment their open = issues.=20 >>=20 >> AB >>=20 >> On Thursday, March 6, 2014, Charles E. Perkins wrote: >>=20 >> Hello Abdussalam, >>=20 >> Actually, all of the issues were resolved. Then, apparently, the >> issues page crashed, and some recent updates to the issues were >> lost. However, they were sent to the mailing list, and so are >> recoverable, with a nontrivial amount of work amounting to >> an archaeological expedition through the mailing list archives. >>=20 >> I wanted to have time to do this, but so far have not. If anyone >> wants to volunteer to recover the issue-tracker updates from the >> mailing list, that would be terrific. >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >> On 3/6/2014 8:16 AM, Abdussalam Baryun wrote: >>> Hi Charles, >>>=20 >>> I just had before a comment on the open tickets, were they all = closed, because I think may be open. Seems most MANET WG don't care = about tickets but I like to track and I remember that the AD did mention = it's importance.=20 >>>=20 >>> For me I will review new draft and comment, but if the authors have = no more pending issues to update, please confirm (sorry that I was not = able to remember if there are confirmation from authors that draft is = ready or not, also need their confirm of final points of open issues for = next draft if not resolved).=20 >>>=20 >>> Best Regards >>>=20 >>> AB >>>=20 >>> On Wednesday, March 5, 2014, Charles E. Perkins wrote: >>> Hello folks, >>>=20 >>> Part of the job of finishing the AODVv2 specification will be to = comb >>> the mailing list for issues that are still not resolved. If there = are >>> any specific issues that have not been gotten proper attention, I = hope >>> to find them -- but if anyone would like to help by bringing them >>> up here on the mailing list, that will be appreciated. >>>=20 >>> --=20 >>> Regards, >>> Charlie P. >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> --=20 >> Regards, >> Charlie P. >>=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ manet mailing list = manet@ietf.orghttps://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 nobody Fri Mar 7 07:41:31 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AD41A023A for ; Fri, 7 Mar 2014 07:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq3nBR5Ck964 for ; Fri, 7 Mar 2014 07:41:28 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2824D1A01E0 for ; Fri, 7 Mar 2014 07:41:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 33D421D89DA; Fri, 7 Mar 2014 07:41:21 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.207.197.247] (unknown [31.55.17.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BFDD97224EE; Fri, 7 Mar 2014 07:41:17 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Heide Clausen In-Reply-To: <6C5B6776-34AB-4575-93FD-81483CE25D38@gmail.com> Date: Fri, 7 Mar 2014 16:41:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> <6C5B6776-34AB-4575-93FD-81483CE25D38@gmail.com> To: Jiazi YI X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CCHkaiGrFkG25U0MX3OlEdZ5cKQ Cc: "Dr. Emmanuel Baccelli" , MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 15:41:29 -0000 On 07 Mar 2014, at 16:36 , Jiazi Yi wrote: =20 >> So from this perspective, maybe we should not pick too much on AODVv2 = and we should not get too alarmed: it seems it is the fate of MANET to = deal with such slow progress. >=20 > I think it's unfair to compare AODVv2 and OLSRv2 in this way.=20 > Having seen part of the work that have been done around OLSRv2, if I = was one of the OLSRv2 co-authors, I would probably feel offended.=20 >=20 Rest assured, we are offended. Emmanuel, kindly flog yourself with a wet = newspaper at the earliest possible convenience ;) Don't neglect that RFC5444, RFC5148, RFC6130, for example, were written = by the OLSRv2 authors (and some other folks), but is also a building = block for other MANET protocols.=20 I agree that it's not quite an "apples to apples" comparison that is = being made here. From nobody Fri Mar 7 08:30:43 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808181A01E6 for ; Fri, 7 Mar 2014 08:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKO3H2vE3tNt for ; Fri, 7 Mar 2014 08:30:40 -0800 (PST) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD5A1A0064 for ; Fri, 7 Mar 2014 08:30:40 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i4so4342531oah.15 for ; Fri, 07 Mar 2014 08:30:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=W6J7MRuEtvC59Rm3qkAkHAksSTG8MxFshtg4lzqonSM=; b=bn6KNdOBtxWraX3YJA0FCLduKv1l8Gqq0cTj4iFzC1AFvhaZmiL2bHuPBfNAN/2KDf 1bWMEcgGCcSOp5FTmQDDybNxDotnSCedSP6S3XHGQv/PiVkQhByz0/jp9PDmcojl+2Ri YAZ0VyYlmBoVAn/Secc+YqDHQ9dmIFYTjxYG7mYEnLB3UFKMThDZScd5g3tzEgEIyAny +IYD8rzOlUApdUDCXQE1k8mt1LQajZ/Tkvx5Iws5JSZmdFp/KJbBPR61Jq4QCeDa5qM6 6N0/KvYv2JYipQa9ZAsmonPCTKlhcAf/YIAKVMtvHP1e/p60kNwiJWsBYOLBfCvKmTLc 3Pug== X-Received: by 10.182.213.104 with SMTP id nr8mr1121619obc.81.1394209836128; Fri, 07 Mar 2014 08:30:36 -0800 (PST) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.98.104 with HTTP; Fri, 7 Mar 2014 08:30:16 -0800 (PST) In-Reply-To: References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> <6C5B6776-34AB-4575-93FD-81483CE25D38@gmail.com> From: Emmanuel Baccelli Date: Fri, 7 Mar 2014 17:30:16 +0100 X-Google-Sender-Auth: n6eTQoO5zf2Dgd2zDRly7Rv3eeA Message-ID: To: MANET IETF Content-Type: multipart/alternative; boundary=001a11c32c360662a604f406c6ab Archived-At: http://mailarchive.ietf.org/arch/msg/manet/wze0UnCvpOtRmT_D6NH7F284DmU Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 16:30:42 -0000 --001a11c32c360662a604f406c6ab Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, On Fri, Mar 7, 2014 at 4:41 PM, Thomas Heide Clausen wrote: > > On 07 Mar 2014, at 16:36 , Jiazi Yi wrote: > > > > > >> So from this perspective, maybe we should not pick too much on AODVv2 > and we should not get too alarmed: it seems it is the fate of MANET to deal > with such slow progress. > > > > I think it's unfair to compare AODVv2 and OLSRv2 in this way. > > Having seen part of the work that have been done around OLSRv2, if I was > one of the OLSRv2 co-authors, I would probably feel offended. > > > > Rest assured, we are offended. Emmanuel, kindly flog yourself with a wet > newspaper at the earliest possible convenience ;) > I already started auto-flagelating myself in preparation ;) > > Don't neglect that RFC5444, RFC5148, RFC6130, for example, were written by > the OLSRv2 authors (and some other folks), but is also a building block for > other MANET protocols. > > I agree that it's not quite an "apples to apples" comparison that is being > made here. > Don't get me wrong: I am not trying to minimize the work done on the proactive protocol, or on the RFCs you mention, which are vey useful. Fortunately, I'm an outsider: I don't have any vested interest in this discussion, I am neither a co-author of the reactive spec, nor of the proactive spec, nor of the loadng spec. So I can safely say I am all for comparing apples to apples, too ;) But for us outsiders, it is impossible to distinguish (i) what went wrong and when, (ii) who was excluded from what design team and (iii) who refused to participate, (iv) what's the root of the bad blood. All this has been too opaque for too long, and will thus remain murky in the foreseeable future. So I don't intend to get into any more debates about various interpretations of email archives from X years ago. For us outsiders, the best bet is to just drop these packets, and focus on "where to, from here & now". There is a list of issues. Let's formulate them as constructively as possible, and let's log them in the issue tracker. Let's focus on concrete proposals to fix them. And as Don suggested, let's put time limits -- they usually help to get something done, if used properly. Maybe I'm being too naive, but it seems to me everyone is welcome to participate. Cheers, Emmanuel > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c32c360662a604f406c6ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,


On Fri, Mar 7, 2014 at 4:41 PM, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:

On 07 Mar 2014, at 16:36 , Jiazi Yi <yi.jiazi@gmail.com> wrote:

<SNIP<

>
>> So from this perspective, maybe we should not pick too much on AOD= Vv2 and we should not get too alarmed: it seems it is the fate of MANET to = deal with such slow progress.
>
> I think it's unfair to compare AODVv2 and OLSRv2 in this way.
> Having seen part of the work that have been done around OLSRv2, if I w= as one of the OLSRv2 co-authors, I would probably feel offended.
>

Rest assured, we are offended. Emmanuel, kindly flog yourself with a = wet newspaper at the earliest possible convenience ;)
=

I already started auto-flagelating myself in = preparation ;)=A0

=A0

Don't neglect that RFC5444, RFC5148, RFC6130, for example, were written= by the OLSRv2 authors (and some other folks), but is also a building block= for other MANET protocols.

I agree that it's not quite an "apples to apples" comparison = that is being made here.


Don't get me wrong: I am not trying to minimize the work done on the p= roactive protocol, or on the RFCs you mention, which are vey useful.=A0

Fortunately, I'm an outsider: I don't have any = vested interest in this discussion, I am neither a co-author of the reactiv= e spec, nor of the proactive spec, nor of the loadng spec. So I can safely = say I am all for comparing apples to apples, too ;)

But for us outsiders, it is impossible to distinguish (= i) what went wrong and when, (ii) who was excluded from what design team an= d (iii) who refused to participate, (iv) what's the root of the bad blo= od. All this has been too opaque for too long, and will thus remain murky i= n the foreseeable future.

So I don't intend to get into any more debates abou= t various interpretations of email archives from X years ago. For us outsid= ers, the best bet is to just drop these packets, and focus on "where t= o, from here & now".=A0

There is a list of issues. Let's formulate them as = constructively as possible, and let's log them in the issue tracker. Le= t's focus on concrete proposals to fix them. And as Don suggested, let&= #39;s put time limits -- they usually help to get something done, if used p= roperly.

Maybe I'm being too naive, but it seems to me every= one is welcome to participate.

Cheers,
<= br>
Emmanuel








=
=A0

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

--001a11c32c360662a604f406c6ab-- From nobody Fri Mar 7 09:11:15 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142481A0074 for ; Fri, 7 Mar 2014 09:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.447 X-Spam-Level: X-Spam-Status: No, score=-7.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LfDv9KQrRfs for ; Fri, 7 Mar 2014 09:11:06 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id E39B51A006B for ; Fri, 7 Mar 2014 09:11:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,608,1389744000"; d="scan'208";a="354924295" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 07 Mar 2014 17:11:01 +0000 From: "Dearlove, Christopher (UK)" X-IronPort-AV: E=Sophos;i="4.97,608,1389744000"; d="scan'208";a="49278495" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 07 Mar 2014 17:11:00 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.106]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Fri, 7 Mar 2014 17:11:00 +0000 To: Jiazi Yi , Emmanuel Baccelli Thread-Topic: [manet] Remaining issues affecting the AODVv2 specification Thread-Index: AQHPOglxP4ENFs8EikCep7heMzK2YprVtJuAgAANQICAABTMoA== Date: Fri, 7 Mar 2014 17:11:00 +0000 Message-ID: References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> <6C5B6776-34AB-4575-93FD-81483CE25D38@gmail.com> In-Reply-To: <6C5B6776-34AB-4575-93FD-81483CE25D38@gmail.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" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/maYTEcuLxmQN-0FEWWjn65oEGV4 Cc: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 17:11:13 -0000 Jiazi > Having seen part of the work that have been done around OLSRv2, if I was = one of the OLSRv2 co-authors, I would probably feel offended. OLSRv2 took far too long. I might get offended if someone said "and that was your fault", either to m= e individually or the authors collectively. But I didn't take the comments = I saw that way. Who was responsible for that delay? Well, pretty much everyone who was invo= lved (not excluding the authors) and also things that aren't anyone's fault= . Attempting to break it down would not be helpful in my opinion. What's the lessons from that for AODVv2? I would say two key points. - First, there's a range of assessments of the quality of AODVv2. Right now= I'm not going to comment on those. I'm just going to say that at the most = optimistic end there is, based on OLSRv2 experience, a significant way to g= o, based on security requirements for a start. (By significant I mean not 2= 014.) At the other end, a lot longer. - Second, there's experience in pushing OLSRv2 through. I've referred to se= curity above. There is more that applies. It could help. -- = 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 nobody Fri Mar 7 10:33:37 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD071A01E9 for ; Fri, 7 Mar 2014 10:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y15FLW8ovdeE for ; Fri, 7 Mar 2014 10:33:33 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C07071A017E for ; Fri, 7 Mar 2014 10:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8994; q=dns/txt; s=iport; t=1394217209; x=1395426809; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fuWICDFRyVJvjGru2bmcabw2UwOSPrejynOgAH/ekgM=; b=MmC9Rq01d8iJcuuBRQAgcrKgtBBwgoYtcz6aw6d6lRcDZMLTF0SQF46X zyUKz8g61EhcIBbIC5vkmHUwCUjlIZ8grkSKu90Kp/76ERnfhJqQ302H3 wiG0Fx5xJr7wsHtpJD6Aljg+5ds45M4LAFeOjf7qiJfcUv7AS7HGoMA/d E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAF0QGlOtJXG9/2dsb2JhbABagwY7V8EmgRQWdIIlAQEBAwEBAQFrCxACAQg/ByEGCxQRAgQOBYdlAwkIDckPDYcFEwSMRIE1EQFMBAeDJIEUBJZWgW2MY4VIgy2Bcjk X-IronPort-AV: E=Sophos;i="4.97,609,1389744000"; d="scan'208,217";a="308873447" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 07 Mar 2014 18:33:28 +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 s27IXSPX030041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 18:33:28 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.172]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 12:33:27 -0600 From: "Stan Ratliff (sratliff)" To: Emmanuel Baccelli Thread-Topic: [manet] Remaining issues affecting the AODVv2 specification Thread-Index: AQHPOglyf8C4gVkHrU+FGF6vOJVThJrWGTCAgAANQICAAAFxAIAADawAgAAiaIA= Date: Fri, 7 Mar 2014 18:33:27 +0000 Message-ID: References: <53170334.2020908@computer.org> <5318A1BA.1020408@computer.org> <5318E809.5000103@computer.org> <6C5B6776-34AB-4575-93FD-81483CE25D38@gmail.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.42.95] Content-Type: multipart/alternative; boundary="_000_A80DE4982C6A49069261254A858AC283ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kyzL_RMTZTwzkt-drudxcuWDk5I Cc: MANET IETF Subject: Re: [manet] Remaining issues affecting the AODVv2 specification X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 18:33:36 -0000 --_000_A80DE4982C6A49069261254A858AC283ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Emmanuel, On Mar 7, 2014, at 11:30 AM, Emmanuel Baccelli > wrote: Hi Thomas, On Fri, Mar 7, 2014 at 4:41 PM, Thomas Heide Clausen > wrote: On 07 Mar 2014, at 16:36 , Jiazi Yi > wrote: >> So from this perspective, maybe we should not pick too much on AODVv2 an= d we should not get too alarmed: it seems it is the fate of MANET to deal w= ith such slow progress. > > I think it's unfair to compare AODVv2 and OLSRv2 in this way. > Having seen part of the work that have been done around OLSRv2, if I was = one of the OLSRv2 co-authors, I would probably feel offended. > Rest assured, we are offended. Emmanuel, kindly flog yourself with a wet ne= wspaper at the earliest possible convenience ;) I already started auto-flagelating myself in preparation ;) Don't neglect that RFC5444, RFC5148, RFC6130, for example, were written by = the OLSRv2 authors (and some other folks), but is also a building block for= other MANET protocols. I agree that it's not quite an "apples to apples" comparison that is being = made here. Don't get me wrong: I am not trying to minimize the work done on the proact= ive protocol, or on the RFCs you mention, which are vey useful. Fortunately, I'm an outsider: I don't have any vested interest in this disc= ussion, I am neither a co-author of the reactive spec, nor of the proactive= spec, nor of the loadng spec. So I can safely say I am all for comparing a= pples to apples, too ;) But for us outsiders, it is impossible to distinguish (i) what went wrong a= nd when, (ii) who was excluded from what design team and (iii) who refused = to participate, (iv) what's the root of the bad blood. All this has been to= o opaque for too long, and will thus remain murky in the foreseeable future= . So I don't intend to get into any more debates about various interpretation= s of email archives from X years ago. For us outsiders, the best bet is to = just drop these packets, and focus on "where to, from here & now". There is a list of issues. Let's formulate them as constructively as possib= le, and let's log them in the issue tracker. Let's focus on concrete propos= als to fix them. And as Don suggested, let's put time limits -- they usuall= y help to get something done, if used properly. (Standing to applaud)=85 Bravo. Well said. Thank you for saying it. Regards, Stan Maybe I'm being too naive, but it seems to me everyone is welcome to partic= ipate. Cheers, Emmanuel _______________________________________________ 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_A80DE4982C6A49069261254A858AC283ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1B3C1842EE39254F92B679BC444E4C35@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Emmanuel, 

On Mar 7, 2014, at 11:30 AM, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> wrote:

Hi Thomas,


On Fri, Mar 7, 2014 at 4:41 PM, Thomas Heide Cla= usen <ietf@thomas= clausen.org> wrote:

On 07 Mar 2014, at 16:36 , Jiazi Yi <yi.jiazi@gmail.com> wrote:

<SNIP<

>
>> So from this perspective, maybe we should not pick too much on AOD= Vv2 and we should not get too alarmed: it seems it is the fate of MANET to = deal with such slow progress.
>
> I think it's unfair to compare AODVv2 and OLSRv2 in this way.
> Having seen part of the work that have been done around OLSRv2, if I w= as one of the OLSRv2 co-authors, I would probably feel offended.
>

Rest assured, we are offended. Emmanuel, kindly flog yourself with a wet ne= wspaper at the earliest possible convenience ;)


I already started auto-flagelating myself in preparation ;) 

 

Don't neglect that RFC5444, RFC5148, RFC6130, for example, were written by = the OLSRv2 authors (and some other folks), but is also a building block for= other MANET protocols.

I agree that it's not quite an "apples to apples" comparison that= is being made here.


Don't get me wrong: I am not trying to minimize the work done on the p= roactive protocol, or on the RFCs you mention, which are vey useful. <= /div>

Fortunately, I'm an outsider: I don't have any vested interest in this= discussion, I am neither a co-author of the reactive spec, nor of the proa= ctive spec, nor of the loadng spec. So I can safely say I am all for compar= ing apples to apples, too ;)

But for us outsiders, it is impossible to distinguish (i) what went wr= ong and when, (ii) who was excluded from what design team and (iii) who ref= used to participate, (iv) what's the root of the bad blood. All this has be= en too opaque for too long, and will thus remain murky in the foreseeable future.

So I don't intend to get into any more debates about various interpret= ations of email archives from X years ago. For us outsiders, the best bet i= s to just drop these packets, and focus on "where to, from here & = now". 

There is a list of issues. Let's formulate them as constructively as p= ossible, and let's log them in the issue tracker. Let's focus on concrete p= roposals to fix them. And as Don suggested, let's put time limits -- they u= sually help to get something done, if used properly.

(Standing to applaud)=85 Bravo. Well said. Thank you for saying it.&nb= sp;

Regards,
Stan



Maybe I'm being too naive, but it seems to me everyone is welcome to p= articipate.

Cheers,

Emmanuel








 

_______________________________________________
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_A80DE4982C6A49069261254A858AC283ciscocom_-- From nobody Fri Mar 7 12:49:44 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7F81A02C2 for ; Fri, 7 Mar 2014 12:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUkHlrtBO2Cr for ; Fri, 7 Mar 2014 12:49:37 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 89A9F1A0084 for ; Fri, 7 Mar 2014 12:49:37 -0800 (PST) Received: by mail-yh0-f50.google.com with SMTP id t59so4852866yho.37 for ; Fri, 07 Mar 2014 12:49:33 -0800 (PST) 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=fdf8xpf/HEvIVisgURCQ4dqJf+y90T+oyn3v/Ncwjyk=; b=X47kqCBcMseug6D6ZuO541gwpcQhnCgbTf7h1+0IUjjM5PdLmYQ7cBBdVn4eIyF2lD ztmcXWjyCdyklUloqGUwrTXZaIi+ha/7H0UNvITiZwc2aq08JW6CzUTZjuglQT/vfial KbnVyrE9rVMNywjSU7/UZrlCq5acSzoRIavXX4G5Azz1NCu3yBT01ikfyLjFxvrHVkQP COtAsBLM5NAyZFeC1c276Tb6M3PLDYJyfLkje6wLPPl2oGa1EjDE0a/ELWpQpwf9gY7h ap80wrEg/0kS90XJkdR8ZTQG+3M09XX2OIWN5opV2mMxzZRJzqpV/1owQjlImddVdjYF lY3g== MIME-Version: 1.0 X-Received: by 10.236.94.243 with SMTP id n79mr25223673yhf.46.1394225372965; Fri, 07 Mar 2014 12:49:32 -0800 (PST) Received: by 10.170.202.7 with HTTP; Fri, 7 Mar 2014 12:49:32 -0800 (PST) In-Reply-To: <7C4038A0-9C79-4049-97D7-C563AFEEDC77@thomasclausen.org> References: <7C4038A0-9C79-4049-97D7-C563AFEEDC77@thomasclausen.org> Date: Fri, 7 Mar 2014 20:49:32 +0000 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=20cf3011d87717af2604f40a64f7 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8lfUlidyxyGLc4n4NP9tcqrqYUY Cc: Mobile Ad Hoc Networks mailing list Subject: [manet] Regarding the reactive protocol development - again X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 20:49:42 -0000 --20cf3011d87717af2604f40a64f7 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, March 6, 2014, Thomas Heide Clausen wrote: > > o 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: > o Do FOO; > otherwise: > o Do BAR; > 4. Retransmit the RREQ > > The way in which this document is written is very confusing: > I think the way written for the specification should be similar way of RFC 3561, that is important for interoperability purposes between both specifications of AODVv2 and RFC3561. (I remember it was said while developing the OLSRv2 draft to be similar structure of RFC3626). Regards AB --20cf3011d87717af2604f40a64f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thursday, March 6, 2014, Thomas Heide Clausen wrote:

o I have a very simple mind, and I like bulle= t-point-pseudocode over=A0
"textual pseudocode". E.g somethi= ng like this is more readable to me:

Upon receiving an RREQ, a router:
1. Record X;
2. R= ecord Y;
3. If z then:
o Do FOO;
otherwise:
= o Do BAR;
4. Retransmit the RREQ

T= he way in which this document is written is very confusing:

I think the = way written for the=A0specification should be=A0similar way=A0of RFC 3561, = that=A0is important for interoperability purposes=A0between both specificat= ions of=A0AODVv2 and RFC3561. (I=A0remember it=A0was said while developing = the OLSRv2 draft to be similar structure of RFC3626).=A0

Regards
AB

=A0
--20cf3011d87717af2604f40a64f7-- From nobody Fri Mar 7 13:04:42 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E9F1A0270 for ; Fri, 7 Mar 2014 13:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ItlRrVT0-14 for ; Fri, 7 Mar 2014 13:04:39 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 646FA1A01FD for ; Fri, 7 Mar 2014 13:04:39 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id k14so3331468wgh.34 for ; Fri, 07 Mar 2014 13:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OJiLOLP+ZKhxDS1X2zyX6NkaCluY7KGOuB+rYgvHKQk=; b=OVXKuAb1kfUiVZvqFSRY4uXvshXsLIEWTRL94L81XHTnCwrM0yWK+H0jJSg/TbV1DF KRAO42CFtQbRZY2VCplQJ08WJgym/pDsbT8TrbfgF6Swl4O/4Iz/SiUe2MxC2XAPtSKo BYJa7mBzz5CVmk8r0b++KzoJfGXbbno99W711mLFViPT+6HDEFtJ1Sz9gdqqQFR6gnoO mOTL1hDS635X7U5ER+vWOm+bKwSUh7R6Gu4yaYfOMQgiHrFzha5z6mF5WWcQZM4hgVYN i0eP1Z+HLE5CQ/D2QOzDHyN1kwtNRV4jzEk8rmKW1xfdBwAssaZqSlAr5P+hI47wh7bi xuEg== X-Received: by 10.194.78.77 with SMTP id z13mr22011336wjw.64.1394226274624; Fri, 07 Mar 2014 13:04:34 -0800 (PST) Received: from jy-mac-pro.home (128-79-35-43.hfc.dyn.abo.bbox.fr. [128.79.35.43]) by mx.google.com with ESMTPSA id z1sm14463416wjq.19.2014.03.07.13.04.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 13:04:33 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jiazi Yi In-Reply-To: Date: Fri, 7 Mar 2014 22:04:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C4038A0-9C79-4049-97D7-C563AFEEDC77@thomasclausen.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/TNnzj5JoZlNedqvBu9_Swx3p7wI Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Regarding the reactive protocol development - again X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 21:04:41 -0000 Firstly, as far as I know, AODVv2 won't be interoperable with RFC 3561.=20= Secondly, I think the reason of OLSRv2 having similar style of RFC 3626 = is that, such style is easy to understand, and the WG decided to take = that way. It's not the case for AODVv2 here.=20 best Jiazi On 07 Mar 2014, at 21:49 , Abdussalam Baryun = wrote: >=20 > On Thursday, March 6, 2014, Thomas Heide Clausen wrote: >=20 > o I have a very simple mind, and I like bullet-point-pseudocode = over=20 > "textual pseudocode". E.g something like this is more readable to me: >=20 > Upon receiving an RREQ, a router: > 1. Record X; > 2. Record Y; > 3. If z then: > o Do FOO; > otherwise: > o Do BAR; > 4. Retransmit the RREQ >=20 > The way in which this document is written is very confusing: >=20 > I think the way written for the specification should be similar way of = RFC 3561, that is important for interoperability purposes between both = specifications of AODVv2 and RFC3561. (I remember it was said while = developing the OLSRv2 draft to be similar structure of RFC3626).=20 >=20 > Regards > AB >=20 > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Fri Mar 7 19:04:18 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273AB1A01BB for ; Fri, 7 Mar 2014 19:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTXsDMz8u3Es for ; Fri, 7 Mar 2014 19:04:13 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0701A017E for ; Fri, 7 Mar 2014 19:04:13 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id ik5so4943886vcb.23 for ; Fri, 07 Mar 2014 19:04:08 -0800 (PST) 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=RzbNiKwkP+EvhRhaAOAZTX6cwD7a985NdaxCe0BGtv8=; b=RAbYVoggYNaLcM264xhfRro5ZoVpsFULh/32HK4sXeTdbtMl+ZYkdbG/5Gl/EymA6C AkFYwCg1jdCAVzdX+LbuRAv6LtATBg4+5I+4pnA0C3uX/e2/jVl27GHaJ60jByOFQK+t JxGejGj6FodQK6WClcoVGDwsNphSkIKd95LxM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=RzbNiKwkP+EvhRhaAOAZTX6cwD7a985NdaxCe0BGtv8=; b=m+Ay3rRNFp8plwqK/TkCR6JVMX1R4HTbpVgIn6aFaRf/jgHycOAcN6Jq8hd+i7eZPp CmDLxXXiUTIPgkm7Q1KK52x8hxb8x/sg2tb8Ynhft8BRfOqUKOm/oYP773G0n3eHedfK wsO5/2elyh1VvZgQCi7uIi5kPRtwG9g73KC2dyHgVUaCR/TBtNzjlWLildsJ9Bm2/fTe 51qmCEt25za3SYDfsvxDJozzG0G5GwjWRK3uESN4VWGQNkzqs/HoE1zs0zWJYOagkTXo gBcDAAvC+c/hcv45/lceaBt6BGtJutE2q2KJIkMKC2U1WcLs7C3zeqPfkygSH8kL+S9d qSCA== X-Gm-Message-State: ALoCoQnxGFN1tDDSyMto0meUuVUsaisXp9TFoo1QEecHtaPNOn8nKQkwDjt9f760r+mmZ+xMWssq MIME-Version: 1.0 X-Received: by 10.220.12.140 with SMTP id x12mr12731601vcx.19.1394247848706; Fri, 07 Mar 2014 19:04:08 -0800 (PST) Received: by 10.220.230.9 with HTTP; Fri, 7 Mar 2014 19:04:08 -0800 (PST) Date: Fri, 7 Mar 2014 19:04:08 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a11c3d97cc073fe04f40f9f6c Archived-At: http://mailarchive.ietf.org/arch/msg/manet/nTEWM9kzUn6yqfPLIVX73jOHrVA Subject: [manet] IETF89 preliminary minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 03:04:15 -0000 --001a11c3d97cc073fe04f40f9f6c Content-Type: text/plain; charset=ISO-8859-1 Hello, I uploaded the preliminary minutes to: http://www.ietf.org/proceedings/89/minutes/minutes-89-manet Please verify correctness and send edits to me by email. Many thanks to Justin and Axel for taking the minutes. I have edited and merged them. Best regards Ulrich --001a11c3d97cc073fe04f40f9f6c Content-Type: text/html; charset=ISO-8859-1
Hello,

I uploaded the preliminary minutes to:
http://www.ietf.org/proceedings/89/minutes/minutes-89-manet

Please verify correctness and send edits to me by email.
Many thanks to Justin and Axel for taking the minutes. I have edited and merged them.

Best regards
Ulrich
--001a11c3d97cc073fe04f40f9f6c-- From nobody Fri Mar 7 21:34:31 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC07F1A0160 for ; Fri, 7 Mar 2014 21:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7ZGvvNgwC2x for ; Fri, 7 Mar 2014 21:34:24 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 73F371A0091 for ; Fri, 7 Mar 2014 21:34:24 -0800 (PST) Received: by mail-yk0-f171.google.com with SMTP id q9so13279722ykb.2 for ; Fri, 07 Mar 2014 21:34:19 -0800 (PST) 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=RPYQqM/z/0sURKCQPkTr23N5/hQbcry3Tx/orTHlUhk=; b=Ovyp9WQ8De3exSkUObQRYLUjYCNz4NHVriDrOognmsyXzPqiC2yvEEn5KzeqndxPdj iuBJ+UHgojvvfPVRPibiNGeYPhsncSZYmoK1LCLyY+bh6GwAcb3R1Ti/yNGxoZI4TCWd 0Hah8On1dYudBIlBNpJSPls/+VCQKHYS2DUhDpk1DNKYfvpYBbHiOme24q/h+KjQ5fXT qwiXULQXAmwicFnZOqZ772FV/ZNRyOuByLfNjyS3ubAsAy98WLPJpf9OOJ8YD4fB/Yuv 3nQqOnIDM+c0yeAdAn1Hhoh9awDx5R2haUqG4oJghR/dvpUV7WHBPHdl8azGpD0DBBMT Q8Mg== MIME-Version: 1.0 X-Received: by 10.236.100.235 with SMTP id z71mr27837849yhf.43.1394256859832; Fri, 07 Mar 2014 21:34:19 -0800 (PST) Received: by 10.170.202.7 with HTTP; Fri, 7 Mar 2014 21:34:19 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Mar 2014 05:34:19 +0000 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf301b65fbdb261d04f411b861 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7klke2JpmrbPmF7VD-HSz6h3N1w Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] IETF89 preliminary minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 05:34:27 -0000 --20cf301b65fbdb261d04f411b861 Content-Type: text/plain; charset=ISO-8859-1 Hi Ulrich, Quick Minutes amendment points: -Your draft in the last presentation was asked to be adopted by WG but not to be in WGLC. -There was only one WG chair present, the minutes show that there were two. Please delete the name that was not in session chair position in the room. -Names of participants when they input are not consistent. Please add: Abdussalam Baryun (AB) in start, then use AB in all following inputs. Please do same for Teco, Rick, Stan. Also abbreviate These following not related to names; CP, JC, EB, RT, etc. - the name should be Rick Taylor (RT), please amend and then use RT, because the surname was repeated different ( as Tayler). -IMHO we need to make minutes clear of participant hat or power. For example WG chair which was Stan or SR, please show his power if he is talking as chair, as SR (WG chair) and if he says I am as participant then only put SR. (This point can be checked with chair or AD if acceptable or not). -Also IMHO when Adrian the AD talked as AD, please make it Adrian (WG AD). We had two AD, so Stewart input may add to it (WG AD). (This point can be checked with chair or AD if acceptable or not). I will try to listen to the recording to see if there are more comments. Thanks Ulrich, Stan, Justin and Alex. Best Wishes, AB On Saturday, March 8, 2014, Ulrich Herberg wrote: > Hello, > > I uploaded the preliminary minutes to: > http://www.ietf.org/proceedings/89/minutes/minutes-89-manet > > Please verify correctness and send edits to me by email. > Many thanks to Justin and Axel for taking the minutes. I have edited and > merged them. > > Best regards > Ulrich > --20cf301b65fbdb261d04f411b861 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ulrich,

Quick=A0Minutes amendment points:

-Your draft in the last presentation was asked to be adopte= d by WG but=A0not to be in WGLC.=A0

-There was onl= y one WG chair present, the minutes show that there were two. Please delete= the name that was not in session=A0chair position in the room.=A0

-Names of participants when they input=A0are not consis= tent. Please add: Abdussalam Baryun (AB) in start, then use AB in all follo= wing inputs.=A0Please do same for Teco, Rick, Stan. Also abbreviate=A0These= following=A0not related to names; CP, JC, EB, RT,=A0etc.=A0

- the name should be=A0Rick=A0Taylor (RT), please amend= and then use RT, because=A0the surname was repeated different ( as Tayler)= . =A0

-IMHO=A0we need to=A0make minutes clear of p= articipant hat or power. For example=A0WG chair which was Stan or SR, pleas= e show his power if he is talking as chair, as SR (WG chair)=A0and if he sa= ys I am as participant then only put SR. (This point can be checked with ch= air or AD if acceptable or not).=A0

-Also IMHO=A0when Adrian the AD talked as AD, please ma= ke it Adrian (WG AD). We had two AD, so Stewart input may add to it (WG AD)= . (This point ca= n be checked with chair or AD if acceptable or not).=A0

I will try to=A0listen to the recording to see if there= are more comments.=A0

Thanks Ulrich, Stan,=A0Just= in and Alex.=A0

Best Wishes,

<= div> AB
--20cf301b65fbdb261d04f411b861-- From nobody Fri Mar 7 21:48:12 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9B51A01B6 for ; Fri, 7 Mar 2014 21:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVEWx9Y6ibPi for ; Fri, 7 Mar 2014 21:48:09 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id D2CF61A0160 for ; Fri, 7 Mar 2014 21:48:08 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id oy12so5075175veb.26 for ; Fri, 07 Mar 2014 21:48:04 -0800 (PST) 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=V9E+SigCIhcSdMcRdbMYNld0uZmgaVK7+sGrdwYj9lI=; b=Blg5HsNXVoluPk6j8KOc6N6BsJ0rr55uSL0Xeu90hyfBpTcFwHnaX6ZOcBJDOxJuiF LMXKyG25uLFWxeei8n6qlFpEqCTdJX8OGjLD197sMyqsmmu7pEzRFy4nsqfcfo57zQL7 XseIA/vj4dJBKRceL2IcEhfFSUWhlLXcum7Js= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V9E+SigCIhcSdMcRdbMYNld0uZmgaVK7+sGrdwYj9lI=; b=HFFau72s8/TcdbvwZQjEmzPXD0uI/zmN2YZcEoliVtbRfI+KoMhwe95PYLivLaGPoc imkusynvgAPX7BYkuvP8VfCg+g3HO59AjZI2aJ6RyxL9WdAc/pR+cm23okvEfWSZNhlf UxRbMPDd6sGba/t8JAE0XW56EuLswDEQM7cSviBcgZ9+o3c5gjafFozu7NwYBw14pJCg S1nQwMg4O5kVG7vZoCMe1k3pm6RJd5Jg0uyFIsMKnbVpOyDyKhxEK+3ZnOhN64MB1zpv ZS2iZF1DEYjrKythC3wGMcQSYIQneaoJfpCjOFOWCR86OZzo+zDN7b0NnnCKdlJXAkbW f+Sg== X-Gm-Message-State: ALoCoQkdgsS7+Q42dnopnDBPYNSSIHkUlM3AdNWBOpT7GnuJ2AwolilkYJnVVO9BA9ubC68MsGUj MIME-Version: 1.0 X-Received: by 10.52.189.33 with SMTP id gf1mr15066615vdc.26.1394257684158; Fri, 07 Mar 2014 21:48:04 -0800 (PST) Received: by 10.220.230.9 with HTTP; Fri, 7 Mar 2014 21:48:04 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Mar 2014 21:48:04 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=001a1136b262fd6ffb04f411e98d Archived-At: http://mailarchive.ietf.org/arch/msg/manet/4uD5Jh2Hk05EvQ8p2J9XR7KzhB0 Cc: "manet@ietf.org" Subject: Re: [manet] IETF89 preliminary minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 05:48:10 -0000 --001a1136b262fd6ffb04f411e98d Content-Type: text/plain; charset=ISO-8859-1 Hello Abdussalam, see below On Fri, Mar 7, 2014 at 9:34 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > > Hi Ulrich, > > Quick Minutes amendment points: > > -Your draft in the last presentation was asked to be adopted by WG but not > to be in WGLC. > That is correct. I updated the minutes accordingly. Thanks. > > -There was only one WG chair present, the minutes show that there were > two. Please delete the name that was not in session chair position in the > room. > Joe is WG co-chair. I had already made clear that he was not attending the session by adding "(absent)". > > -Names of participants when they input are not consistent. Please add: > Abdussalam Baryun (AB) in start, then use AB in all following > inputs. Please do same for Teco, Rick, Stan. Also abbreviate These > following not related to names; CP, JC, EB, RT, etc. > In the latest update, I have expanded each name at least once. If you want to have full consistency (with abbreviations), then I invite you to send me the updated text file. > > - the name should be Rick Taylor (RT), please amend and then use RT, > because the surname was repeated different ( as Tayler). > I corrected Tayler to Taylor. > > -IMHO we need to make minutes clear of participant hat or power. For > example WG chair which was Stan or SR, please show his power if he is > talking as chair, as SR (WG chair) and if he says I am as participant then > only put SR. (This point can be checked with chair or AD if acceptable or > not). > I disagree. In my opinion, it would be inappropriate for the minute takers to interpret with which "hat" each speaker was talking. Important is to know who said what. > > -Also IMHO when Adrian the AD talked as AD, please make it Adrian (WG AD). > There is no "WG AG". There is a responsible AD for each WG. It is clear from the WG page that Adrian is our responsible AD. In my opinion, there is no need to repeat that in the minutes. > We had two AD, so Stewart input may add to it (WG AD). (This point can be > checked with chair or AD if acceptable or not). > I am not sure what you request here. I expanded the name correctly. You can check on the IESG page that Stewart was AD at the time of the meeting. > > I will try to listen to the recording to see if there are more comments. > You are free to do so. Best regards Ulrich > > Thanks Ulrich, Stan, Justin and Alex. > > Best Wishes, > > AB > > On Saturday, March 8, 2014, Ulrich Herberg wrote: > >> Hello, >> >> I uploaded the preliminary minutes to: >> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet >> >> Please verify correctness and send edits to me by email. >> Many thanks to Justin and Axel for taking the minutes. I have edited and >> merged them. >> >> Best regards >> Ulrich >> > --001a1136b262fd6ffb04f411e98d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Abdussalam,

see below


On Fri, Mar 7, 2014 at 9:34 PM, A= bdussalam Baryun <abdussalambaryun@gmail.com> wrote= :

Hi Ulrich,

Quick=A0Mi= nutes amendment points:

-Your draft in the last pres= entation was asked to be adopted by WG but=A0not to be in WGLC.=A0

That is correct. I updated the minut= es accordingly. Thanks.
=A0

-There was only one WG chair present, the minutes = show that there were two. Please delete the name that was not in session=A0= chair position in the room.=A0

Joe is WG co-chair. I had already made clear that he was not attending the = session by adding "(absent)".
=A0

-Names of participants when they input=A0are not consis= tent. Please add: Abdussalam Baryun (AB) in start, then use AB in all follo= wing inputs.=A0Please do same for Teco, Rick, Stan. Also abbreviate=A0These= following=A0not related to names; CP, JC, EB, RT,=A0etc.=A0

In the latest update, I have expande= d each name at least once. If you want to have full consistency (with abbre= viations), then I invite you to send me the updated text file.
=A0

- the name should be=A0Rick=A0Taylor (RT), please amend= and then use RT, because=A0the surname was repeated different ( as Tayler)= . =A0

I corrected Tayler to Tay= lor.
=A0

-IMHO=A0we need to=A0make minutes clear of participant hat or power. For e= xample=A0WG chair which was Stan or SR, please show his power if he is talk= ing as chair, as SR (WG chair)=A0and if he says I am as participant then on= ly put SR. (This point can be checked with chair or AD if acceptable or not= ).=A0

I disagree. In my opinion, it would = be inappropriate for the minute takers to interpret with which "hat&qu= ot; each speaker was talking. Important is to know who said what.

=A0

-Also IMHO=A0when Adrian the AD talked as AD, please ma= ke it Adrian (WG AD).

There is= no "WG AG". There is a responsible AD for each WG. It is clear f= rom the WG page that Adrian is our responsible AD. In my opinion, there is = no need to repeat that in the minutes.

=A0
We had two= AD, so Stewart input may add to it (WG AD). (This point can be checked with chair or AD if= acceptable or not).=A0

I am not sure what you request here.= I expanded the name correctly. You can check on the IESG page that Stewart= was AD at the time of the meeting.
=A0

I will try to=A0listen to the recording to see if there= are more comments.=A0

You are = free to do so.

Best regards
Ulrich
=A0

Thanks Ulrich, Stan,=A0Justin and Alex.=A0

Best Wishes,

AB

--001a1136b262fd6ffb04f411e98d-- From nobody Sat Mar 8 15:05:05 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7991A02BE; Sat, 8 Mar 2014 15:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34LeM0aNuncN; Sat, 8 Mar 2014 15:05:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D33A91A02F1; Sat, 8 Mar 2014 15:04:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140308230457.17570.52968.idtracker@ietfa.amsl.com> Date: Sat, 08 Mar 2014 15:04:57 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ekx0bZSeFJ3Yfae-jrrWaAZS8Zk Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-mib-10.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 23:05:03 -0000 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 : Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process Authors : Robert G. Cole Joseph Macker Brian Adamson Filename : draft-ietf-manet-smf-mib-10.txt Pages : 64 Date : 2014-03-08 Abstract: This memo 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 aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB module also reports state information, performance information, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-smf-mib-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-mib-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Mar 8 15:07:59 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B7D1A011C for ; Sat, 8 Mar 2014 15:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnpeiYXMUZhj for ; Sat, 8 Mar 2014 15:07:54 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6281A0110 for ; Sat, 8 Mar 2014 15:07:54 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so5538653vcb.41 for ; Sat, 08 Mar 2014 15:07:49 -0800 (PST) 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=p3oDnzXxpj0qVY/HN+qyCuiK5QjB8mYBEn8KY1wraSU=; b=nkbSHoZ6ST76WciRM7lBQKCU3dOadedfkCt3lwpw7pYsTc+EbcJGeT/KtR6lcduKLz NQD/EBNzQG+4dUu3L3Mm0aEIr+4mzERiLwdVcY1eQAtWhYQe7Argt6qXdULSM0lhAn3w sCsX+9NvKrWVfPkKa5jHUV87HqDeZNIfzwWMI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=p3oDnzXxpj0qVY/HN+qyCuiK5QjB8mYBEn8KY1wraSU=; b=aI86hE1PDq3SFLTnx4s1vePvONiXueifwtaLmwC55r9Jmrhz/n2jxF9UxN3pZ1HQA7 ibv4O/SX7hDwFjYCB24KUhkKAvwyj3kvsiaUZVfrXoDrYVQCrA0wmcdr9qdQJYV6hKC+ giGtcdvhdv7LakSxxDjhAJsp4Vs1KD2NQboFa+QWhunxK0Ebf7jCcWve/4xw3bNpP/jb m6hqtAVNQWUJ5de+vPT7wVySDcFxAR37kmYxFHDPlAc/5RWYo9q6HHdXb6u4vD6keZZW /IzSKVUQHGe5O3BfqHczuPjS9Uhn1eMW7sMIbszWkmxsQBMDqVlfW3YPN3sZkUAWW3Sz HemQ== X-Gm-Message-State: ALoCoQkh3TTrrE9+lElDBBowzC41DcsPM7eR8/eSU74yk+XTrO8xVS4M12qUNhi9e7E7AeQOq5wP MIME-Version: 1.0 X-Received: by 10.220.191.134 with SMTP id dm6mr16463909vcb.16.1394320069456; Sat, 08 Mar 2014 15:07:49 -0800 (PST) Received: by 10.220.230.9 with HTTP; Sat, 8 Mar 2014 15:07:49 -0800 (PST) In-Reply-To: <20140308230457.17570.52968.idtracker@ietfa.amsl.com> References: <20140308230457.17570.52968.idtracker@ietfa.amsl.com> Date: Sat, 8 Mar 2014 15:07:49 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org, "Cole, Robert G USA CIV (US)" Content-Type: multipart/alternative; boundary=089e0158a82a718c5404f420705c Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hyoXQGkzpYRGwR_lwZzacyT1rEk Subject: Re: [manet] I-D Action: draft-ietf-manet-smf-mib-10.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 23:07:56 -0000 --089e0158a82a718c5404f420705c Content-Type: text/plain; charset=ISO-8859-1 Hi Bob, thanks for the submission. I am glad to see the document progressing! Best regards Ulrich On Sat, Mar 8, 2014 at 3:04 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 : Definition of Managed Objects for the Manet > Simplified Multicast Framework Relay Set Process > Authors : Robert G. Cole > Joseph Macker > Brian Adamson > Filename : draft-ietf-manet-smf-mib-10.txt > Pages : 64 > Date : 2014-03-08 > > Abstract: > This memo 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 aspects of the > Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc > Networks (MANETs). The SMF-MIB module also reports state > information, performance information, and notifications. In addition > to configuration, the additional state and performance information is > useful to operators troubleshooting multicast forwarding problems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-smf-mib-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-mib-10 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 > --089e0158a82a718c5404f420705c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Bob,

thanks for the submission. = I am glad to see the document progressing!

Best regards
Ulr= ich


= On Sat, Mar 8, 2014 at 3:04 PM, <internet-drafts@ietf.org><= /span> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Mobile Ad-hoc Networks Working Group of= the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Definition of Managed Objects f= or the Manet Simplified Multicast Framework Relay Set Process
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Robert G. Cole
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joseph Macker
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Brian Adamson
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-smf-mib-10.txt =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 64
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-03-08

Abstract:
=A0 =A0This memo defines a portion of the Management Information Base (MIB)=
=A0 =A0for use with network management protocols in the Internet community.=
=A0 =A0In particular, it describes objects for configuring aspects of the =A0 =A0Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc
=A0 =A0Networks (MANETs). =A0The SMF-MIB module also reports state
=A0 =A0information, performance information, and notifications. =A0In addit= ion
=A0 =A0to configuration, the additional state and performance information i= s
=A0 =A0useful to operators troubleshooting multicast forwarding problems.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-smf-mib-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-smf-m= ib-10


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

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

--089e0158a82a718c5404f420705c-- From nobody Mon Mar 10 01:09:31 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7672C1A03D5 for ; Mon, 10 Mar 2014 01:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNYoY0LhpxPh for ; Mon, 10 Mar 2014 01:09:26 -0700 (PDT) Received: from nm27-vm5.bullet.mail.gq1.yahoo.com (nm27-vm5.bullet.mail.gq1.yahoo.com [98.136.216.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7411A03F0 for ; Mon, 10 Mar 2014 01:09:26 -0700 (PDT) Received: from [98.137.12.60] by nm27.bullet.mail.gq1.yahoo.com with NNFMP; 10 Mar 2014 08:09:21 -0000 Received: from [216.39.60.215] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 10 Mar 2014 08:09:21 -0000 Received: from [127.0.0.1] by omp1102.mail.gq1.yahoo.com with NNFMP; 10 Mar 2014 08:09:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 333907.74896.bm@omp1102.mail.gq1.yahoo.com Received: (qmail 63449 invoked by uid 60001); 10 Mar 2014 08:09:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394438961; bh=b10bzjZwKWMdlq7kCt2Pa/GbhtbrvA9wOAvY92Ac17Y=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=CIa2HXvxMJmaElWRSOAzEnLTPjtfXL4/ZRdJW0Dky3yqajZ9HlT2/GmS8yFPPRU2KvMOGDDsk9X71l+Ll0gC9eY2bOr6pT465s7IxcFTr3xgeiXfjhhoRKgEIugWUTkqMnc0Ns8JxpP36RVa5LXAwLeghXYHncbdrVSpEW/go8o= 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:MIME-Version:Content-Type; b=xqa3PZnAq3A4cVi4UdvmiWHBID09QRfzKBMqnP+DlW6yPEytCMDOg5aXr3ecd1UMqX1ri+Pm4Iwv60Ac+vy5lKjUNJZQPfATBy9xB4296ki8/P0MYpXNVi1oVCHOW3iZyDPyoNgyuigNeAWXY8lFLqKakeAWpsjm/SgcCVcuj7w=; X-YMail-OSG: lR6x9RkVM1naxjhIDecj0.UHShClditQ4lghjXNyZFj1JGD g1bPq.2Kl1Li8zEda3zgjoCs5dL88IiFjNfENfu5.fMdicm.ET4EGf9NJaTU UXERgVJx4XXypVrVSN3CSoKgQSUhXtuRG1tNGEB2la8bwcFuObfcy3ezCkzx q0J6s77TakisZ42..zMadWGQeIjo8xtyh4rVm0XA74yYQJbtVrcQ7KQ3.VKp VwssbtT1jvTil6mwUN8NNFtWziWKCcIttRNFlP9C299Vc2_liwsDoiyc59xN R3MXVf5Muzx.xrqC8eMfGXxZ6zyQ65cTxiukzxMHkGubquRufAmagCvZFBOh I_dk99wuw5WG0QWhGAOJ4705.kOs3ne2xw_P95NWzqzde2z57Q5SGz.TbIhM Rm2A7GeUxeui3OMuseRqX_WBTleeKz7M8HX4_Z2MS2rkFIiVrvrT_FtFb8n5 JDtQjFjoTAQCZ8eAq5QgNoGTG7OA9f7qXDGhPyEoZ3lwR5S9FcrPrGL31rff FpkvaozPRQjYbtPF7qYdsdgpoutrXjhXB7anBwmcsL3DN7ZbvgdhbiVqyiAm cjBjXUmu.CXEcyBYQVNnHhjlbANyppUwZc28cgB0HJcZCkXuwOSOaa3IRi1N FYaK.5i_yWRmFfoDlEzwCpRa04YFnaF9BpLp6QRRBtdFgkpPI2G8I9Xwx3y3 QNi5TZp0Ufy1AOD6lxwt6Su5lhDy0vJneLxCdmk4OvUafZjZiKCoS3XO7INF hA_PMTpYCxOsdUI5dxY.eb30- Received: from [223.166.179.28] by web164003.mail.gq1.yahoo.com via HTTP; Mon, 10 Mar 2014 01:09:21 PDT X-Rocket-MIMEInfo: 002.001, Q2FsbCBmb3IgcGFwZXJzCgpUaGUgR3JlZW4gQ29tbXVuaWNhdGlvbnMgYW5kIE5ldHdvcmtzIFRyYWNrIGluIHRoZSBJRUVFIFZlaGljdWxhciBUZWNobm9sb2d5IENvbmZlcmVuY2UgKFZUQzIwMTQtRmFsbCksIDE0LTE3IFNlcCAyMDE0LCBWYW5jb3V2ZXIsIENhbmFkYSBoYXMgYmVlbiBleHRlbmRlZCB0byBNYXJjaCAxNSwgMjAxNC4gUGxlYXNlIHN1Ym1pdCB5b3VyIGxhdGVzdCB3b3JrIGluIHRoZSB0b3BpY3MgYmVsb3cgYnkgdGhlIGRlYWRsaW5lLgpXZWJzaXRlOiBodHRwOi8vd3d3LmllZWV2dGMub3IBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 Message-ID: <1394438961.88449.YahooMailNeo@web164003.mail.gq1.yahoo.com> Date: Mon, 10 Mar 2014 01:09:21 -0700 (PDT) From: Jinsong Wu To: manet MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="133570123-151082425-1394438961=:88449" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/dTBwYMUSI3965p38sZknDBGaeRs Subject: [manet] Extended deadline March 15: 2014 IEEE VTC Fall Green Communications and Networks Track X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Jinsong Wu List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 08:09:29 -0000 --133570123-151082425-1394438961=:88449 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Call for papers=0A=0AThe Green Communications and Networks Track in the IEE= E Vehicular Technology Conference (VTC2014-Fall), 14-17 Sep 2014, Vancouver= , Canada has been extended to March 15, 2014. Please submit your latest wor= k in the topics below by the deadline.=0AWebsite: http://www.ieeevtc.org/vt= c2014fall/tracks.php=0ASubmission Web Link: http://vtc2014fall.trackchair.c= om/track/1251/submit=0AExtended Submission Deadline: 15 March 2014=0ASubmis= sion requirements: 5-page full papers=0ATopics of Interest:=0AGreen wireles= s communications and networks, Green architecture, strategies, algorithms, = protocols, scheduling, and/or designs, Energy-efficient heterogeneous netwo= rks, Energy-aware self-organized networks, Low-power sensor networks, Machi= ne-to-machine communications, Energy harvesting, storage, and recycling, Cr= oss-layer optimization for green networks, Green mobile communications, Rad= io resource management for green wireless systems, Green cooperative commun= ications, Smart grid networks, Energy consumption management, Green softwar= e/hardware, Energy-aware system design, Architectures and design of low pow= er equipment, Green data centers and/or cloud computing, Electromagnetic po= llution mitigation, ICT for green objectives, Environmental monitoring.=0A-= ---------------------------------------------------=0ATrack Co-Chairs:=0ANe= elesh Mehta (neeleshbmehta[at]gmail[dot]com)=0ATeng Joon Lim (eleltj[at]nus= [dot]edu[dot]sg)=0AJinsong Wu (wujs[at]ieee[dot]org)=0A=0ATechnical Program= Committee Members:=0ABiplab Sikdar, Rensselaer Polytechnic Institute, USA= =0ACelimuge Wu, University of Electro-communications, Japan=0AChristoph Lan= ge, Deutsche Telekom AG, Germany=0AChung Shue Chen, Alcatel-Lucent Bell Lab= s, France=0AChunyi SONG, National Institute of Information and Communicatio= ns Technology, Japan=0ADaesik Hong, Yonsei University, South Korea=0ADeokwo= o Jung, Advanced Digital Sciences Center, Singapore=0ADietrich Zeller, Alca= tel-Lucent Bell Labs, Germany=0ADusit Niyato, Nanyang Technological Univers= ity, Singapore=0AIoannis Krikidis, University of Cyprus, Republic of Cyprus= =A0=0AJun Zhang, Hong Kong University of Science and Technology, Hong Kong= =0AKwang-Cheng Chen, National Taiwan University, Taiwan=0AKai Yang, Univers= ity Paris Sud - 11, France=0AMaged Elkashlan, Queen Mary, University of Lon= don, UK=0AMarco Listanti, University of Rome "La Sapienza", Italy=0AMarios = Kountouris, SUPELEC, France=0AMiquel Payaro, CTTC, Spain=0AMuhammad Zeeshan= Shakir, Texas A&M University at Qatar, Qatar=0APanagiotis Demestichas, Uni= versity of Piraeus, Greece=0ARadha Krishna Ganti, Indian Institute of Techn= ology, India=0APapademetriou Rallis, University of Portsmouth, UK=0ARui Zha= ng, National University of Singapore, Singapore=0AShahriar Mirabbasi, Unive= rsity of British Columbia, Canada=0AShengrong Bu, Carleton University, Cana= da=0ATony Q.S. Quek, Singapore University of Technology and Design, , Singa= pore=0AWen Chen, Shanghai Jiaotong University, China=0AWenyi Zhang, Univers= ity of Science and Technology of China, China=0AWilliam Liu, Auckland Unive= rsity of Technology, New Zealand=0AXianfu Lei, Utah State University, USA= =0AXiao-Ping Zhang, University of Birmingham=0AXiaoying Gan, Shanghai Jiaot= ong University, China=0AYanxiao Zhao, =A0South Dakota School of Mines & Tec= hnology, USA=0AYeh-Ching Chung, =A0National Tsing Hua University, Taiwan=0A= Zhili Sun, University of Surrey, UK --133570123-151082425-1394438961=:88449 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Call for papers

The Green Commu= nications and Networks Track in the IEEE Vehicular Technology Conference (V= TC2014-Fall), 14-17 Sep 2014, Vancouver, Canada has been extended to March = 15, 2014. Please submit your latest work in the topics below by the deadlin= e.
Website: http://www.ieeevtc.org/vtc2014fall/tracks.php
Submission Web Link: http://vtc2014fall.trackchair.com/track/1251/submit=
Extended Submission Deadline: 15 March 2014
Submission= requirements: 5-page full papers
Topics of Interest:
G= reen wireless communications and networks, Green architecture, strategies, = algorithms, protocols, scheduling, and/or designs, Energy-efficient heterog= eneous networks, Energy-aware self-organized networks, Low-power sensor networks, Machine-to-machine communications, Energy harvesting, sto= rage, and recycling, Cross-layer optimization for green networks, Green mob= ile communications, Radio resource management for green wireless systems, G= reen cooperative communications, Smart grid networks, Energy consumption ma= nagement, Green software/hardware, Energy-aware system design, Architecture= s and design of low power equipment, Green data centers and/or cloud comput= ing, Electromagnetic pollution mitigation, ICT for green objectives, Enviro= nmental monitoring.
---------------------------------------------= -------
Track Co-Chairs:
Neelesh Mehta (neeleshbmehta[a= t]gmail[dot]com)
Teng Joon Lim (eleltj[at]nus[dot]edu[dot]sg)
Jinsong Wu (wujs[at]ieee[dot]org)

Technical= Program Committee Members:
Biplab Sikdar, Rensselaer Polytechnic= Institute, USA
Celimuge Wu, University of Electro-communications, Japan
Christoph Lange, Deutsche Telekom = AG, Germany
Chung Shue Chen, Alcatel-Lucent Bell Labs, France
Chunyi SONG, National Institute of Information and Communications Te= chnology, Japan
Daesik Hong, Yonsei University, South Korea
=
Deokwoo Jung, Advanced Digital Sciences Center, Singapore
Di= etrich Zeller, Alcatel-Lucent Bell Labs, Germany
Dusit Niyato, Na= nyang Technological University, Singapore
Ioannis Krikidis, Unive= rsity of Cyprus, Republic of Cyprus 
Jun Zhang, Hong Kong Un= iversity of Science and Technology, Hong Kong
Kwang-Cheng Chen, N= ational Taiwan University, Taiwan
Kai Yang, University Paris Sud = - 11, France
Maged Elkashlan, Queen Mary, University of London, U= K
Marco Listanti, University of Rome "La Sapienza", Italy
Marios Kountouris, SUPELEC, France
Miquel Payaro, CTTC, Spain
Muhammad Zeeshan Shakir, Texas A&M University at Qatar= , Qatar
Panagiotis Demestichas, University of Piraeus, Greece
Radha Krishna Ganti, Indian Institute of Technology, India
Papademetriou Rallis, University of Portsmouth, UK
Rui Zhang, Na= tional University of Singapore, Singapore
Shahriar Mirabbasi, Uni= versity of British Columbia, Canada
Shengrong Bu, Carleton Univer= sity, Canada
Tony Q.S. Quek, Singapore University of Technology a= nd Design, , Singapore
Wen Chen, Shanghai Jiaotong University, Ch= ina
Wenyi Zhang, University of Science and Technology of China, C= hina
William Liu, Auckland University of Technology, New Zealand<= /div>
Xianfu Lei, Utah State University, USA
Xiao-Ping Zhang,= University of Birmingham
Xiaoying Gan, Shanghai Jiaotong Univers= ity, China
Yanxiao Zhao,  South Dakota School of Mines & Technology, USA
Yeh-Ching Chung,  National Tsin= g Hua University, Taiwan
Zhili Sun, University of Surrey, UK
--133570123-151082425-1394438961=:88449-- From nobody Mon Mar 10 06:43:17 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A211A044A for ; Mon, 10 Mar 2014 06:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItnlZfS7ALJW for ; Mon, 10 Mar 2014 06:43:12 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id AFBD21A0434 for ; Mon, 10 Mar 2014 06:43:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id ACC5C600118; Mon, 10 Mar 2014 06:43:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id A10811C018A; Mon, 10 Mar 2014 06:43:05 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8CAE3ECD-92B1-4E01-B1CF-D3E2AAD44550" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: Date: Mon, 10 Mar 2014 14:43:02 +0100 Message-Id: <905353BD-2987-4F6D-99C4-15C57F8E563F@thomasclausen.org> References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> <6E6B32A0-55E8-476C-A049-EED875D94E48@thomasclausen.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pUf6JOl4gTczaWkzuhYVkCz4frY Cc: MANET IETF , Stan Ratliff Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 13:43:14 -0000 --Apple-Mail=_8CAE3ECD-92B1-4E01-B1CF-D3E2AAD44550 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 05 Mar 2014, at 21:43, Abdussalam Baryun = wrote: > Hi Thomas >=20 > I see that the draft is not about routing results, but formatting = metrics for purposes.=20 >=20 With the purpose being to "run a routing protocol". And, proactive and reactive protocols are *very* different in how they = use metrics....and, as Henning points out, in how metrics values can be = estimated. > AB >=20 > On Wednesday, March 5, 2014, Thomas Heide Clausen wrote: > We need to scope the experiment correctly so as to get any meaningful = results and feedback.=20 >=20 > I agree only if we find that the draft is not scoped. Did you find = some error in scope in draft. Please help.=20 > =20 >=20 > My experience is that proactive and reactive protocols have and behave = *very* different wrt metrics and I would not bet on being able to get = meaningful results from mushing them together willy-nilly.=20 >=20 > The reactive and proactive have and behave "very" different in = messages send/receive/information but still we agreed to have RFC5444 = for both, and NHDP for both. Why not metric, please help.=20 Because it's not the same thing at all. Thomas >=20 > AB >=20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org >=20 > "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." >=20 > If not from math then there is no practice.=20 > =20 > - Nikola Tesla,=20 > Modern Mechanics and Inventions, July, 1934 >=20 --Apple-Mail=_8CAE3ECD-92B1-4E01-B1CF-D3E2AAD44550 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 05 Mar 2014, at 21:43, Abdussalam = Baryun <abdussalambaryun@gmail.com&= gt; wrote:

Hi Thomas

I see that the draft is not = about routing results, but formatting metrics for = purposes. 


With the = purpose being to "run a routing protocol".

And, = proactive and reactive protocols are *very* different in how they use = metrics....and, as Henning points out, in how metrics values can be = estimated.

AB

On = Wednesday, March 5, 2014, Thomas Heide Clausen wrote:
We need to scope the experiment correctly so as to get = any meaningful results and = feedback. 

I agree only if we = find that the draft is not scoped. Did you find some error in scope in = draft. Please help. 
 

My experience is = that proactive and reactive protocols have and behave *very* different = wrt metrics and I would not bet on being able to get meaningful results = from mushing them together willy-nilly. 

The reactive and proactive have = and behave "very" different in messages = send/receive/information but still we agreed to have RFC5444 for = both, and NHDP for both. Why not metric, please = help. 

Because it's not the = same thing at = all.

Thomas


AB

-- 
Thomas Heide = Clausen

"Today's scientists have substituted mathematics = for 
  experiments, and they wander off through = equation 
  after equation, and eventually =  build a structure 
  which has no = relation to reality."

If not from math then there is no = practice. 
 
 - Nikola Tesla, 
   =  Modern Mechanics and Inventions, July, = 1934


= --Apple-Mail=_8CAE3ECD-92B1-4E01-B1CF-D3E2AAD44550-- From nobody Mon Mar 10 06:47:16 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCABF1A0436 for ; Mon, 10 Mar 2014 06:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2k8bgVciezz for ; Mon, 10 Mar 2014 06:47:11 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id DBB171A041E for ; Mon, 10 Mar 2014 06:47:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DDA4760011D; Mon, 10 Mar 2014 06:47:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id B4D7A60011B; Mon, 10 Mar 2014 06:46:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_316A369A-C910-485C-AB4A-2AC9CA8AE3F7" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <905353BD-2987-4F6D-99C4-15C57F8E563F@thomasclausen.org> Date: Mon, 10 Mar 2014 14:46:55 +0100 Message-Id: <43B8404E-868F-41F3-9333-64A1E9EF83AE@thomasclausen.org> References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> <6E6B32A0-55E8-476C-A049-EED875D94E48@thomasclausen.org> <905353BD-2987-4F6D-99C4-15C57F8E563F@thomasclausen.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/XoRViYWWF6OtC1xGfRylvtLPXhA Cc: MANET IETF , Stan Ratliff Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 13:47:13 -0000 --Apple-Mail=_316A369A-C910-485C-AB4A-2AC9CA8AE3F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 (Oh boy, this was a long week, I'd entirely forgotten that I'd already = replied to this. Mea culpa, apologies for the double-posting) On 10 Mar 2014, at 14:43, Thomas Clausen wrote: >=20 > On 05 Mar 2014, at 21:43, Abdussalam Baryun = wrote: >=20 >> Hi Thomas >>=20 >> I see that the draft is not about routing results, but formatting = metrics for purposes.=20 >>=20 >=20 > With the purpose being to "run a routing protocol". >=20 > And, proactive and reactive protocols are *very* different in how they = use metrics....and, as Henning points out, in how metrics values can be = estimated. >=20 >> AB >>=20 >> On Wednesday, March 5, 2014, Thomas Heide Clausen wrote: >> We need to scope the experiment correctly so as to get any meaningful = results and feedback.=20 >>=20 >> I agree only if we find that the draft is not scoped. Did you find = some error in scope in draft. Please help.=20 >> =20 >>=20 >> My experience is that proactive and reactive protocols have and = behave *very* different wrt metrics and I would not bet on being able to = get meaningful results from mushing them together willy-nilly.=20 >>=20 >> The reactive and proactive have and behave "very" different in = messages send/receive/information but still we agreed to have RFC5444 = for both, and NHDP for both. Why not metric, please help.=20 >=20 > Because it's not the same thing at all. >=20 > Thomas >=20 >>=20 >> AB >>=20 >> --=20 >> Thomas Heide Clausen >> http://www.thomasclausen.org >>=20 >> "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." >>=20 >> If not from math then there is no practice.=20 >> =20 >> - Nikola Tesla,=20 >> Modern Mechanics and Inventions, July, 1934 >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_316A369A-C910-485C-AB4A-2AC9CA8AE3F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 (Oh = boy, this was a long week, I'd entirely forgotten that I'd already = replied to this. Mea culpa, apologies for the = double-posting)

On 10 Mar 2014, at 14:43, Thomas = Clausen <ietf@thomasclausen.org> = wrote:


On 05 Mar 2014, at 21:43, Abdussalam = Baryun <abdussalambaryun@gmail.com&= gt; wrote:

Hi Thomas

I see that the draft is not = about routing results, but formatting metrics for = purposes. 


With the = purpose being to "run a routing protocol".

And, = proactive and reactive protocols are *very* different in how they use = metrics....and, as Henning points out, in how metrics values can be = estimated.

AB

On = Wednesday, March 5, 2014, Thomas Heide Clausen wrote:
We need to scope the experiment correctly so as to get = any meaningful results and = feedback. 

I agree only if we = find that the draft is not scoped. Did you find some error in scope in = draft. Please help. 
 

My experience is = that proactive and reactive protocols have and behave *very* different = wrt metrics and I would not bet on being able to get meaningful results = from mushing them together willy-nilly. 

The reactive and proactive have = and behave "very" different in messages = send/receive/information but still we agreed to have RFC5444 for = both, and NHDP for both. Why not metric, please = help. 

Because it's not the same = thing at = all.

Thomas


AB

-- 
Thomas Heide = Clausen

"Today's scientists have substituted mathematics = for 
  experiments, and they wander off through = equation 
  after equation, and eventually =  build a structure 
  which has no = relation to reality."

If not from math then there is no = practice. 
 
 - Nikola Tesla, 
   =  Modern Mechanics and Inventions, July, = 1934

=

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

= --Apple-Mail=_316A369A-C910-485C-AB4A-2AC9CA8AE3F7-- From nobody Mon Mar 10 06:50:28 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538A11A0436 for ; Mon, 10 Mar 2014 06:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S18_YGKXFqEW for ; Mon, 10 Mar 2014 06:50:23 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 58D7A1A041E for ; Mon, 10 Mar 2014 06:50:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 585B06000F2; Mon, 10 Mar 2014 06:50:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id D68111C018A; Mon, 10 Mar 2014 06:50:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CA12A8FE-FFDB-445A-B4C4-E79FE9C767DF" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: Date: Mon, 10 Mar 2014 14:50:12 +0100 Message-Id: <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org> References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-yixrB4-hVIZMu8UwK1KIYk4AVA Cc: "" , MANET IETF Subject: Re: [manet] IETF89 preliminary minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 13:50:26 -0000 --Apple-Mail=_CA12A8FE-FFDB-445A-B4C4-E79FE9C767DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ulrich, Thank you for prompt posting of minutes. =20 A couple of things that I would like to make more precise, all the same, = in the minutes: > o draft-ietf-manet-olsrv2-multitopology: Dearlove > Teco: Why not make this document standards track? > CD: If people implement this and it's great. Then I'm find fine = changing this to standards track if that's the case. > TC: I do not think as a working group that we should go down the = standards track document without many implementations as that has = happened in other places within the IETF and document quality has = suffered. I honestly do not think that Chris would make that typo, even when = speaking ;) > CD: If it gets stuck in the queue for 4 years we may have enough = experience that we may want to push for standards track. > Rick Taylor: Is there any record of this for this draft being = experimental and then changing to standards track later down the line? > CD: We will post something up on the list. > TC: I think that experimental should have an explanation on what the = experiment is and what the successful experiment is and what the = conclusion is. > Ulrich: Do you have intention to add a description of what those = experiments are and what will make them successful? > Adrian Farrel: Yes, he does have that intention. As it reads in the above, it sounds as if I'm making a demand, that = Adrian is committing Chris to satisfy. That's not exactly how it went = down, so perhaps we should clarify that in the minutes? I'd like to go on record here, that I did not say that it "should have = an explanation" to cater to my whim, but that I (as I actually stated at = the mike) I was reciting what I had heard was an IESG = statement/requirement (so: I thought it was the IESGs whim to be = satisfied). Adrian then clarified this, that it was not an "IESG = statement/requirement" as such, but that the current routing ADs (which = include him, so his whim) who require this" > o draft-rogge-baccelli-olsrv2-ett-metric: Rogge > Henning: It will also not break anything if different values are used = as the values are unit-less so the routes might be crazy but they will = work. > TC: I think experimental is exactly the place for this document > Emmanuel: I would like to comment to Rick's earlier comment about if = this is related to OLSRv2. It uses building blocks such as sequence = numbers in RFC5444 and missed NHDP HELLO messages to calculate the = metric, so in that regard it could be used with other protocols and is = not only tied to OLSRv2. > CD: There needs to be a section describing the experiments.=20 > TC: I think this draft should be focused to OLSRv2 (and not other = protocols) and not make it something overly broad and have it stall out. > Henning: For AODV this metric would be a problem as there isn't = normally control traffic or any unicast traffic on a link, so there is = nothing to measure. I believe that what I said was that my experience with both proactive = and reactive protocol deployments leave me to believe that metrics "make = sense in very different ways in these two protocol families", and = therefore would need to be considered separately. Specifically, = constructing an "experiment for a metric for a proactive protocol" = (which, as this is going Experimental, is a requirement by the RTG ADs) = is easy - whereas constructing an "experiment for the same metric for = both a proactive and a reactive protocol" is a lot harder to do = correctly, and probably will just make us stall. Therefore, given that the existing operational experience, on which this = document is based, is exclusively for proactive / OLSR, only, my = preference is simply to document the metric as for OLSR, and design the = experiment accordingly. > o draft-gerla-manet-odmrp: Colin de Verdiere > draft-gerla-manet-odmrp-asym Brain-fart here, but I actually do not recall if the authors requested = WG adoption "now", "a bit later", or "not at all but just wanted to = inform the WG what we're doing"? - Or was it "none of the above"? > o draft-clausen-manet-olsrv2-management-snapshot: Herberg > UH: Presenting. Requesting WG adoption Have I missed something, or was WG adoption for this document already = called for on the list? If not, any reasons for "not"? >=20 > o OLSRv2 + RFC6971: Clausen > No time for presentation (slides in the proceedings), brought to the = mailing list. It'd be kind if the minutes contains a link to the message which Ulrich = started and wherein the discussion was brought forward: In the new "archive format" (which I am given to understand is = being reworked to show the threads) that'd be: = http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek or, the format that actually allows seeing the threads, and = which is useful currently: = http://www.ietf.org/mail-archive/web/manet/current/msg16016.html Cheers, Thomas On 08 Mar 2014, at 04:04, Ulrich Herberg wrote: > Hello, >=20 > I uploaded the preliminary minutes to: > http://www.ietf.org/proceedings/89/minutes/minutes-89-manet >=20 > Please verify correctness and send edits to me by email. > Many thanks to Justin and Axel for taking the minutes. I have edited = and merged them. >=20 > Best regards > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_CA12A8FE-FFDB-445A-B4C4-E79FE9C767DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Ulrich,

Thank you for prompt = posting of minutes.
 
A couple of things that I = would like to make more precise, all the same, in the = minutes:

o =
draft-ietf-manet-olsrv2-multitopology: Dearlove
<SNIP>
Teco: Why not make this document =
standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's =
the case.
TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.
I honestly do not think that Chris =
would make that typo, even when speaking ;)
CD: If it gets stuck in the queue for 4 years we may have =
enough experience that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
Adrian Farrel: Yes, he does have that =
intention.
As it reads in the above, it sounds as if I'm =
making a demand, that Adrian is committing Chris to satisfy. That's not =
exactly how it went down, so perhaps we should clarify that in the =
minutes?
I'd like to go on record here, that I did not say =
that it "should have an explanation" to cater to my whim, but that I (as =
I actually stated at the mike) I was reciting what I had heard was an =
IESG statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).

Adrian then clarified this, that it =
was not an "IESG statement/requirement" as such, but that the current =
routing ADs (which include him, so his whim) who require =
this"

<SNIP>

 o draft-rogge-baccelli-olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will =
also not break anything if different values are used as the values are =
unit-less so the routes might be crazy but they will =
work.
TC: I think experimental is exactly the place for this =
document
Emmanuel: I would like to comment to Rick's earlier comment about if =
this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to =
OLSRv2 (and not other protocols) and not make it something overly broad =
and have it stall out.
Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to =
measure.

I =
believe that what I said was that my experience with both proactive and =
reactive protocol deployments leave me to believe that metrics "make =
sense in very different ways in these two protocol families", and =
therefore would need to be considered separately. Specifically, =
constructing an "experiment for a metric for a proactive protocol" =
(which, as this is going Experimental, is a requirement by the RTG ADs) =
is easy - whereas constructing an "experiment for the same metric for =
both a proactive and a reactive protocol" is a lot harder to do =
correctly, and probably will just make us =
stall.

Therefore, given that the existing =
operational experience, on which this document is based, is exclusively =
for proactive / OLSR, only, my preference is simply to document the =
metric as for OLSR, and design the experiment =
accordingly.

<SNIP>

 o draft-gerla-manet-odmrp: Colin de =
Verdiere
   draft-gerla-manet-odmrp-asym
Brain-fart here, =
but I actually do not recall if the authors requested WG adoption "now", =
"a bit later", or "not at all but just wanted to inform the WG what =
we're doing"? - Or was it "none of the =
above"?

<SNIP>

o =
draft-clausen-manet-olsrv2-management-snapshot: Herberg
UH: Presenting. Requesting WG adoption


Have I missed something, or was WG adoption for this document =
already called for on the list? If not, any reasons for "not"?

<SNIP>

 o OLSRv2 + RFC6971: Clausen
No time for presentation (slides in the proceedings), brought to the =
mailing list.

It'd be kind =
if the minutes contains a link to the message which Ulrich started and =
wherein the discussion was brought =
forward:

	In the new "archive format" =
(which I am given to understand is being reworked to show the threads) =
that'd be:

	or, the format that actually =
allows seeing the threads, and which is useful =
currently:
=


Cheers,

Thomas

=

On 08 Mar 2014, at 04:04, Ulrich Herberg <ulrich@herberg.name> =
wrote:

Hello,

I uploaded =
the preliminary minutes to:
http:=
//www.ietf.org/proceedings/89/minutes/minutes-89-manet


Please verify correctness and send edits to me by =
email.
Many thanks to Justin and Axel for taking the minutes. I =
have edited and merged them.

Best regards
Ulrich

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

=

--Apple-Mail=_CA12A8FE-FFDB-445A-B4C4-E79FE9C767DF--


From nobody Mon Mar 10 07:25:13 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919801A047A for ; Mon, 10 Mar 2014 07:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.446
X-Spam-Level: 
X-Spam-Status: No, score=-7.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucUf5n49OdiF for ; Mon, 10 Mar 2014 07:25:02 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 77D861A044C for ; Mon, 10 Mar 2014 07:25:00 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,624,1389744000";  d="scan'208,217";a="355343419"
Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 10 Mar 2014 14:24:54 +0000
From: "Dearlove, Christopher (UK)" 
X-IronPort-AV: E=Sophos; i="4.97,624,1389744000"; d="scan'208,217"; a="49479886"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 10 Mar 2014 14:24:54 +0000
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.106]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Mon, 10 Mar 2014 14:24:54 +0000
To: Thomas Clausen , Ulrich Herberg 
Thread-Topic: [manet] IETF89 preliminary minutes
Thread-Index: AQHPOnsZMQfbSc/LMU2E7v8iYpDYpZraWloAgAAI6jA=
Date: Mon, 10 Mar 2014 14:24:53 +0000
Message-ID: 
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org>
In-Reply-To: <36539249-D8C7-4507-B477-77BFBEE5D726@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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D4027493BGLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0XKAxjXbHC4ARNgvacfu4Gdw94E
Cc: "" , MANET IETF 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 14:25:08 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D4027493BGLKXM0002VGREEN_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

If we're nitpicking, then "Then" should not start a new sentence.

As for Adrian's comment, I took it as a lighthearted way of saying that if =
we wanted a smooth passage, that's what we should do.

(I partly regret making the four year reference. I'd be horrified if it too=
k that long. But if it took a long time - four years being just a random fi=
gure - we'd be ready for ST then.)

--
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 [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Clausen
Sent: 10 March 2014 13:50
To: Ulrich Herberg
Cc: ; MANET IETF
Subject: Re: [manet] IETF89 preliminary minutes


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Consider carefully whether you should click on any links, open any attachme=
nts or reply.
For information regarding Red Flags that you can look out for in emails you=
 receive, click here.
If you feel the email is suspicious, please follow this process.
Ulrich,

Thank you for prompt posting of minutes.

A couple of things that I would like to make more precise, all the same, in=
 the minutes:


o draft-ietf-manet-olsrv2-multitopology: Dearlove


Teco: Why not make this document standards track?

CD: If people implement this and it's great.  Then I'm find  fine changing =
this to standards track if that's the case.

TC: I do not think as a working group that we should go down the standards =
track document without many implementations as that has happened in other p=
laces within the IETF and document quality has suffered.
I honestly do not think that Chris would make that typo, even when speaking=
 ;)

CD: If it gets stuck in the queue for 4 years we may have enough experience=
 that we may want to push for standards track.

Rick Taylor: Is there any record of this for this draft being experimental =
and then changing to standards track later down the line?

CD: We will post something up on the list.

TC: I think that experimental should have an explanation on what the experi=
ment is and what the successful experiment is and what the conclusion is.

Ulrich: Do you have intention to add a description of what those experiment=
s are and what will make them successful?

Adrian Farrel: Yes, he does have that intention.

As it reads in the above, it sounds as if I'm making a demand, that Adrian =
is committing Chris to satisfy. That's not exactly how it went down, so per=
haps we should clarify that in the minutes?

I'd like to go on record here, that I did not say that it "should have an e=
xplanation" to cater to my whim, but that I (as I actually stated at the mi=
ke) I was reciting what I had heard was an IESG statement/requirement (so: =
I thought it was the IESGs whim to be satisfied).



Adrian then clarified this, that it was not an "IESG statement/requirement"=
 as such, but that the current routing ADs (which include him, so his whim)=
 who require this"







 o draft-rogge-baccelli-olsrv2-ett-metric: Rogge



Henning: It will also not break anything if different values are used as th=
e values are unit-less so the routes might be crazy but they will work.

TC: I think experimental is exactly the place for this document

Emmanuel: I would like to comment to Rick's earlier comment about if this i=
s related to OLSRv2.  It uses building blocks such as sequence numbers in R=
FC5444 and missed NHDP HELLO messages to calculate the metric, so in that r=
egard it could be used with other protocols and is not only tied to OLSRv2.

CD: There needs to be a section describing the experiments.

TC: I think this draft should be focused to OLSRv2 (and not other protocols=
) and not make it something overly broad and have it stall out.

Henning: For AODV this metric would be a problem as there isn't normally co=
ntrol traffic or any unicast traffic on a link, so there is nothing to meas=
ure.



I believe that what I said was that my experience with both proactive and r=
eactive protocol deployments leave me to believe that metrics "make sense i=
n very different ways in these two protocol families", and therefore would =
need to be considered separately. Specifically, constructing an "experiment=
 for a metric for a proactive protocol" (which, as this is going Experiment=
al, is a requirement by the RTG ADs) is easy - whereas constructing an "exp=
eriment for the same metric for both a proactive and a reactive protocol" i=
s a lot harder to do correctly, and probably will just make us stall.



Therefore, given that the existing operational experience, on which this do=
cument is based, is exclusively for proactive / OLSR, only, my preference i=
s simply to document the metric as for OLSR, and design the experiment acco=
rdingly.




 o draft-gerla-manet-odmrp: Colin de Verdiere

   draft-gerla-manet-odmrp-asym
Brain-fart here, but I actually do not recall if the authors requested WG a=
doption "now", "a bit later", or "not at all but just wanted to inform the =
WG what we're doing"? - Or was it "none of the above"?




o draft-clausen-manet-olsrv2-management-snapshot: Herberg

UH: Presenting. Requesting WG adoption



Have I missed something, or was WG adoption for this document already calle=
d for on the list? If not, any reasons for "not"?









 o OLSRv2 + RFC6971: Clausen

No time for presentation (slides in the proceedings), brought to the mailin=
g list.

It'd be kind if the minutes contains a link to the message which Ulrich sta=
rted and wherein the discussion was brought forward:

            In the new "archive format" (which I am given to understand is =
being reworked to show the threads) that'd be:
                        http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3u=
xKExI5NPbafy5Vet9ek

            or, the format that actually allows seeing the threads, and whi=
ch is useful currently:
                        http://www.ietf.org/mail-archive/web/manet/current/=
msg16016.html

Cheers,

Thomas

On 08 Mar 2014, at 04:04, Ulrich Herberg > wrote:


Hello,
I uploaded the preliminary minutes to:
http://www.ietf.org/proceedings/89/minutes/minutes-89-manet

Please verify correctness and send edits to me by email.
Many thanks to Justin and Axel for taking the minutes. I have edited and me=
rged them.

Best regards
Ulrich
_______________________________________________
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D4027493BGLKXM0002VGREEN_
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable











If we’re nitpicking=
, then “Then” should not start a new sentence.


 <=
/p>

As for Adrian’s com=
ment, I took it as a lighthearted way of saying that if we wanted a smooth =
passage, that’s what we should do.


 <=
/p>

(I partly regret making t=
he four year reference. I’d be horrified if it took that long. But if=
 it took a long time – four years being just a random figure –
 we’d be ready for ST then.)


 <=
/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 [mailto:manet-bounces@ietf.org]
On Behalf Of Thomas Clausen

Sent: 10 March 2014 13:50

To: Ulrich Herberg

Cc: <manet-chairs@tools.ietf.org>; MANET IETF

Subject: Re: [manet] IETF89 preliminary minutes






 




 




*** WARNING ***=








This message originates from outside our organ=
isation, either from an external partner or the internet.

Co=
nsider carefully whether you should click on any links, open any attachment=
s or reply.

Fo=
r information regarding 
Red Flags that you can look out for in emails you rec=
eive,
 click 
here.

If=
 you feel the email is suspicious, please follow

this process.






Ulrich,




 






Thank you for prompt posting of minutes.<=
/p>





 






A couple of things that I would like to make more pr=
ecise, all the same, in the minutes:






 








o draft-ietf-mane=
t-olsrv2-multitopology: Dearlove








<SNIP>








Teco: Why not mak=
e this document standards track?


CD: If people implement this and it's great.  Then I'm find=
  fine changing this t=
o standards track if that's the case.


TC: I do not think as a working group that we should go down the stand=
ards track document without many implementations as that has happened in ot=
her places within the IETF and document quality has suffered.





I honestly do not think that Chris would make that t=
ypo, even when speaking ;)






CD: If it gets st=
uck in the queue for 4 years we may have enough experience that we may want=
 to push for standards track.


Rick Taylor: Is there any record of this for this draft being experime=
ntal and then changing to standards track later down the line?

CD: We will post something up on the list.


TC: I think that experimental should have an explanation on what the e=
xperiment is and what the successful experiment is and what the conclusion =
is.


Ulrich: Do you have intention to add a description of what those exper=
iments are and what will make them successful?


Adrian Farrel: Yes, he does have that intention.




As it reads in th=
e above, it sounds as if I'm making a demand, that Adrian is committing Chr=
is to satisfy. That's not exactly how it went down, so perhaps we should cl=
arify that in the minutes?




I'd like to go on record here, that I did not say that it "should=
 have an explanation" to cater to my whim, but that I (as I actually s=
tated at the mike) I was reciting what I had heard was an IESG statement/re=
quirement (so: I thought it was the IESGs whim to be satisfied).=







 






Adrian then clarified this, that it was not an "IESG statement/re=
quirement" as such, but that the current routing ADs (which include hi=
m, so his whim) who require this"






 






<SNIP>






 








 o draft-rogge-ba=
ccelli-olsrv2-ett-metric: Rogge




<SNIP>=









Henning: It will =
also not break anything if different values are used as the values are unit=
-less so the routes might be crazy but they will work.






TC: I think exper=
imental is exactly the place for this document


Emmanuel: I would like to comment to Rick's earlier comment about if t=
his is related to OLSRv2.  It uses building blocks such as sequence nu=
mbers in RFC5444 and missed NHDP HELLO messages to calculate the metric, so=
 in that regard it could be used with other protocols and is not only tied =
to OLSRv2.


CD: There needs to be a section describing the experiments. 


TC: I think this draft should be focused=
 to OLSRv2 (and not other protocols) and not make it something overly broad=
 and have it stall out.


Henning: For AODV this metric would be a problem as there isn't normal=
ly control traffic or any unicast traffic on a link, so there is nothing to=
 measure.










 








I believe that what I said was that my experience with both proactive =
and reactive protocol deployments leave me to believe that metrics "ma=
ke sense in very different ways in these two protocol families", and t=
herefore would need to be considered separately. Specifically, constructing=
 an "experiment for a metric for a proactive protocol" (which, as=
 this is going Experimental, is a requirement by the RTG ADs) is easy - whe=
reas constructing an "experiment for the same metric for both a proact=
ive and a reactive protocol" is a lot harder to do correctly, and prob=
ably will just make us stall.






 






Therefore, given that the existing operational experience, on which th=
is document is based, is exclusively for proactive / OLSR, only, my prefere=
nce is simply to document the metric as for OLSR, and design the experiment=
 accordingly.






 






<SNIP>






 








 o draft-gerla-ma=
net-odmrp: Colin de Verdiere


   draft-gerla-manet-odmrp-asym






Brain-fart here, but I actually do not recall if the=
 authors requested WG adoption "now", "a bit later", or=
 "not at all but just wanted to inform the WG what we're doing"? =
- Or was it "none of the above"?








 






<SNIP>






 








o draft-clausen-m=
anet-olsrv2-management-snapshot: Herberg


UH: Presenting. Requesting WG adoption






 






Have I missed something, or was WG adoption for this document already ca=
lled for on the list? If not, any reasons for "not"?






 






<SNIP>






 






 =



 o OLSRv2 + RFC6971: Clausen


No time for presentation (slides in the proceedings), brought to the m=
ailing list.






 








It'd be kind if the minutes contains a link to the m=
essage which Ulrich started and wherein the discussion was brought forward:=







 






   &nb=
sp;        In the new "archi=
ve format" (which I am given to understand is being reworked to show t=
he threads) that'd be:






   &nb=
sp;            =
        
http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet=
9ek






 






   &nb=
sp;        or, the format that ac=
tually allows seeing the threads, and which is useful currently:=







   &nb=
sp;            =
        
http://www.ietf.org/mail-archive/web/manet/current/msg16016.html=







 






Cheers,






 






Thomas






 








On 08 Mar 2014, at 04:04, Ulrich Herberg <ulrich@herberg.name> wrote:

















Hello,




I uploaded the preliminary minutes to:

htt=
p://www.ietf.org/proceedings/89/minutes/minutes-89-manet



Please verify correctness and send edits to me by email.




Many thanks to Justin and Axel for taking the minute=
s. I have edited and merged them.



Best regards

Ulrich




_______________________________________________

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_B31EEDDDB8ED7E4A93FDF12A4EECD30D4027493BGLKXM0002VGREEN_--


From nobody Mon Mar 10 07:32:16 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AA51A0473 for ; Mon, 10 Mar 2014 07:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUfwBUos6Txg for ; Mon, 10 Mar 2014 07:32:11 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id CEE381A0447 for ; Mon, 10 Mar 2014 07:32:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5C32A600276; Mon, 10 Mar 2014 07:32:06 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id C356960027B; Mon, 10 Mar 2014 07:31:34 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F5D7D4BE-0355-49EB-99ED-4DDF4164CC50"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Clausen 
In-Reply-To: 
Date: Mon, 10 Mar 2014 15:31:30 +0100
Message-Id: <2644D5CF-A334-483C-9095-157B10458AE5@thomasclausen.org>
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org> 
To: Christopher Dearlove 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RojKg8J5rfr3yPfxrgpYGGjx1kI
Cc: "" , MANET IETF 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 14:32:15 -0000

--Apple-Mail=_F5D7D4BE-0355-49EB-99ED-4DDF4164CC50
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On 10 Mar 2014, at 15:24, Dearlove, Christopher (UK) =
 wrote:

> If we=92re nitpicking, then =93Then=94 should not start a new =
sentence.=20

;)

> As for Adrian=92s comment, I took it as a lighthearted way of saying =
that if we wanted a smooth passage, that=92s what we should do.

That was my reading, also.

> (I partly regret making the four year reference. I=92d be horrified if =
it took that long. But if it took a long time =96 four years being just =
a random figure =96 we=92d be ready for ST then.)

Agreed. I'm personally shooting for something closer to "4 months" as a =
horizon for seeing this forward, though, as experimental....

> =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
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas =
Clausen
> Sent: 10 March 2014 13:50
> To: Ulrich Herberg
> Cc: ; MANET IETF
> Subject: Re: [manet] IETF89 preliminary minutes
> =20
> =20
> *** WARNING ***
> This message originates from outside our organisation, either from an =
external partner or the internet.
> Consider carefully whether you should click on any links, open any =
attachments or reply.
> For information regarding Red Flags that you can look out for in =
emails you receive, click here.
> If you feel the email is suspicious, please follow this process.
>=20
> Ulrich,
> =20
> Thank you for prompt posting of minutes.
> =20
> A couple of things that I would like to make more precise, all the =
same, in the minutes:
> =20
> o draft-ietf-manet-olsrv2-multitopology: Dearlove
> 
> Teco: Why not make this document standards track?
> CD: If people implement this and it's great.  Then I'm find  fine =
changing this to standards track if that's the case.
> TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.
> I honestly do not think that Chris would make that typo, even when =
speaking ;)
> CD: If it gets stuck in the queue for 4 years we may have enough =
experience that we may want to push for standards track.
> Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
> CD: We will post something up on the list.
> TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
> Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
> Adrian Farrel: Yes, he does have that intention.
> As it reads in the above, it sounds as if I'm making a demand, that =
Adrian is committing Chris to satisfy. That's not exactly how it went =
down, so perhaps we should clarify that in the minutes?
> I'd like to go on record here, that I did not say that it "should have =
an explanation" to cater to my whim, but that I (as I actually stated at =
the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).
> =20
> Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"
> =20
> 
> =20
>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
> 
> Henning: It will also not break anything if different values are used =
as the values are unit-less so the routes might be crazy but they will =
work.
> TC: I think experimental is exactly the place for this document
> Emmanuel: I would like to comment to Rick's earlier comment about if =
this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
> CD: There needs to be a section describing the experiments.=20
> TC: I think this draft should be focused to OLSRv2 (and not other =
protocols) and not make it something overly broad and have it stall out.
> Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.
> =20
> I believe that what I said was that my experience with both proactive =
and reactive protocol deployments leave me to believe that metrics "make =
sense in very different ways in these two protocol families", and =
therefore would need to be considered separately. Specifically, =
constructing an "experiment for a metric for a proactive protocol" =
(which, as this is going Experimental, is a requirement by the RTG ADs) =
is easy - whereas constructing an "experiment for the same metric for =
both a proactive and a reactive protocol" is a lot harder to do =
correctly, and probably will just make us stall.
> =20
> Therefore, given that the existing operational experience, on which =
this document is based, is exclusively for proactive / OLSR, only, my =
preference is simply to document the metric as for OLSR, and design the =
experiment accordingly.
> =20
> 
> =20
>  o draft-gerla-manet-odmrp: Colin de Verdiere
>    draft-gerla-manet-odmrp-asym
> Brain-fart here, but I actually do not recall if the authors requested =
WG adoption "now", "a bit later", or "not at all but just wanted to =
inform the WG what we're doing"? - Or was it "none of the above"?
> =20
> 
> =20
> o draft-clausen-manet-olsrv2-management-snapshot: Herberg
> UH: Presenting. Requesting WG adoption
> =20
> Have I missed something, or was WG adoption for this document already =
called for on the list? If not, any reasons for "not"?
> =20
> 
> =20
> =20
>  o OLSRv2 + RFC6971: Clausen
> No time for presentation (slides in the proceedings), brought to the =
mailing list.
> =20
> It'd be kind if the minutes contains a link to the message which =
Ulrich started and wherein the discussion was brought forward:
> =20
>             In the new "archive format" (which I am given to =
understand is being reworked to show the threads) that'd be:
>                         =
http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek
> =20
>             or, the format that actually allows seeing the threads, =
and which is useful currently:
>                         =
http://www.ietf.org/mail-archive/web/manet/current/msg16016.html
> =20
> Cheers,
> =20
> Thomas
> =20
> On 08 Mar 2014, at 04:04, Ulrich Herberg  wrote:
>=20
>=20
> Hello,
>=20
> I uploaded the preliminary minutes to:
> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet
>=20
> Please verify correctness and send edits to me by email.
> Many thanks to Justin and Axel for taking the minutes. I have edited =
and merged them.
>=20
> Best regards
> Ulrich
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
> =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


--Apple-Mail=_F5D7D4BE-0355-49EB-99ED-4DDF4164CC50
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On 10 Mar 2014, at 15:24, Dearlove, =
Christopher (UK) <Chris.Dearlove@baesystems.co=
m> wrote:

If we=92re nitpicking, then =93Then=94 should not =
start a new sentence. 

;)
=


As for Adrian=92s comment, I took =
it as a lighthearted way of saying that if we wanted a smooth passage, =
that=92s what we should do.

That was my =
reading, also.

(I partly regret making the four year reference. I=92d =
be horrified if it took that long. But if it took a long time =96 four =
years being just a random figure =96 we=92d be ready for ST =
then.)

Agreed. I'm =
personally shooting for something closer to "4 months" as a horizon for =
seeing this forward, though, as =
experimental....

 
--
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 [mailto:manet-bounces@ietf.org] On Behalf Of Thomas =
Clausen
Sent: 10 March 2014 =
13:50
To: Ulrich =
Herberg
Cc: <manet-chairs@tools.ietf.org>; MANET =
IETF
Subject: Re: [manet] IETF89 =
preliminary minutes
 
 
*** =
WARNING ***
This =
message originates from outside our organisation, either from an =
external partner or the internet.
Consider =
carefully whether you should click on any links, open any attachments or =
reply.
For information regarding Red Flags that you can look out for =
in emails you receive, click here.
If you feel the email is =
suspicious, please follow this =
process.
Ulrich,
 
Thank =
you for prompt posting of minutes.
 
A couple of things that I would like to make more =
precise, all the same, in the minutes:
 
o =
draft-ietf-manet-olsrv2-multitopology: =
Dearlove
<SNIP>
Teco: Why not make this document =
standards track?
CD: If people implement =
this and it's great.  Then I'm find  fine changing this to =
standards track if that's the case.
TC: I do =
not think as a working group that we should go down the standards track =
document without many implementations as that has happened in other =
places within the IETF and document quality has =
suffered.
I =
honestly do not think that Chris would make that typo, even when =
speaking ;)
CD: If it gets stuck in the queue for 4 years we may have =
enough experience that we may want to push for standards =
track.
Rick Taylor: Is there any =
record of this for this draft being experimental and then changing to =
standards track later down the line?
CD: We =
will post something up on the list.
TC: I =
think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
Ulrich: Do you have =
intention to add a description of what those experiments are and what =
will make them successful?
Adrian Farrel: =
Yes, he does have that intention.
As it =
reads in the above, it sounds as if I'm making a demand, that Adrian is =
committing Chris to satisfy. That's not exactly how it went down, so =
perhaps we should clarify that in the minutes?
I'd like to go on record here, that I did not say that =
it "should have an explanation" to cater to my whim, but that I (as I =
actually stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).
 
Adrian then =
clarified this, that it was not an "IESG statement/requirement" as such, =
but that the current routing ADs (which include him, so his whim) who =
require this"
 
<SNIP>
 
 o draft-rogge-baccelli-olsrv2-ett-metric: =
Rogge
<SNIP>
Henning: It will also not =
break anything if different values are used as the values are unit-less =
so the routes might be crazy but they will =
work.
TC: I think experimental is exactly the place =
for this document
Emmanuel: I =
would like to comment to Rick's earlier comment about if this is related =
to OLSRv2.  It uses building blocks such as sequence numbers in =
RFC5444 and missed NHDP HELLO messages to calculate the metric, so in =
that regard it could be used with other protocols and is not only tied =
to OLSRv2.
CD: There needs to be a =
section describing the experiments. 
TC: I think this draft should be =
focused to OLSRv2 (and not other protocols) and not make it something =
overly broad and have it stall out.
Henning: For AODV this metric would be a problem as =
there isn't normally control traffic or any unicast traffic on a link, =
so there is nothing to =
measure.
 
I believe that =
what I said was that my experience with both proactive and reactive =
protocol deployments leave me to believe that metrics "make sense in =
very different ways in these two protocol families", and therefore would =
need to be considered separately. Specifically, constructing an =
"experiment for a metric for a proactive protocol" (which, as this is =
going Experimental, is a requirement by the RTG ADs) is easy - whereas =
constructing an "experiment for the same metric for both a proactive and =
a reactive protocol" is a lot harder to do correctly, and probably will =
just make us stall.
 
Therefore, given =
that the existing operational experience, on which this document is =
based, is exclusively for proactive / OLSR, only, my preference is =
simply to document the metric as for OLSR, and design the experiment =
accordingly.
 
<SNIP>
 
 o draft-gerla-manet-odmrp: Colin de =
Verdiere
   =
draft-gerla-manet-odmrp-asym
Brain-fart here, but I actually do not recall if the =
authors requested WG adoption "now", "a bit later", or "not at all but =
just wanted to inform the WG what we're doing"? - Or was it "none of the =
above"?
 
<SNIP>
 
o =
draft-clausen-manet-olsrv2-management-snapshot: =
Herberg
UH: Presenting. Requesting =
WG adoption
 
Have I missed something, =
or was WG adoption for this document already called for on the list? If =
not, any reasons for "not"?
 
<SNIP>
 
 
 o OLSRv2 + RFC6971: Clausen
No time for presentation (slides in the proceedings), =
brought to the mailing list.
 
It'd be kind if the minutes contains a link to the =
message which Ulrich started and wherein the discussion was brought =
forward:
 
        &=
nbsp;   In the new "archive =
format" (which I am given to understand is being reworked to show the =
threads) that'd be:
        &=
nbsp;           &nb=
sp;   http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbaf=
y5Vet9ek
 
        &=
nbsp;   or, the format that =
actually allows seeing the threads, and which is useful =
currently:
        &=
nbsp;           &nb=
sp;   http://www.ietf.org/mail-archive/web/manet/current/msg16016.ht=
ml
 
Cheers,
 
Thomas
 
****************************=
****************************************
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.
***************************************************************=
*****

=

--Apple-Mail=_F5D7D4BE-0355-49EB-99ED-4DDF4164CC50--


From nobody Mon Mar 10 09:08:15 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D151A04A4 for ; Mon, 10 Mar 2014 09:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnZWUHn9ozQD for ; Mon, 10 Mar 2014 09:08:09 -0700 (PDT)
Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 48C011A04C2 for ; Mon, 10 Mar 2014 09:08:09 -0700 (PDT)
Received: by mail-yh0-f43.google.com with SMTP id b6so7268305yha.30 for ; Mon, 10 Mar 2014 09:08:03 -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=pJNiP3nABxyOnfqq1ZLMp1HFUAE7d+FO6xK7HSswe1g=; b=k51eK2DZn80QQHhwlW2iOY1K2Jpm63M9cG5ZiOSRkhY0o741tTKwElpwNdf6Wl7nJO l1sT6HeWWfvFlDgmFvVLyKvTJFeC4hkIuC7W1fb9xFueTpNtxJmVOqGCLzH1ZEfNSlBE BtmU7q0urlvI9FGR+57ICKc+aljOx0aR/fVLz8RM401s5zpybPkoBjprBmSMn3rDsiH3 YfU1eVBQ5WTF+O0Pw7njZMbIlHw17MsuGm14sCgpARpbTL1vaj3k4o7MQIkm1i1l7Ola Ir0IYWwpSPip5lEJqjzOaXy93hmRII0o8F2yCdTdJq9ARaiKkST3bb7SE6eJG9z4Di8D BXEQ==
MIME-Version: 1.0
X-Received: by 10.236.127.166 with SMTP id d26mr16783490yhi.90.1394467683759;  Mon, 10 Mar 2014 09:08:03 -0700 (PDT)
Received: by 10.170.202.7 with HTTP; Mon, 10 Mar 2014 09:08:03 -0700 (PDT)
In-Reply-To: <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org>
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org>
Date: Mon, 10 Mar 2014 17:08:03 +0100
Message-ID: 
From: Abdussalam Baryun 
To: Thomas Clausen 
Content-Type: multipart/alternative; boundary=20cf3011e0bff0fb0c04f442ce07
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lctQVFVFR4RRR87cQiy_bgRe0DM
Cc: "" , MANET IETF 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 16:08:13 -0000

--20cf3011e0bff0fb0c04f442ce07
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Thomas,

Thanks for the update. I don't think the latest multicast draft was
requested to be adopted in the meeting, but Ulrich did request his it for
his draft, and I am waiting for announce on the list for DLEP plan and
all adoption request in WG meeting.

AB

On Monday, March 10, 2014, Thomas Clausen wrote:

> Ulrich,
>
> Thank you for prompt posting of minutes.
>
> A couple of things that I would like to make more precise, all the same,
> in the minutes:
>
> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>
> 
>
> Teco: Why not make this document standards track?
> CD: If people implement this and it's great.  Then I'm find  fine changin=
g this to standards track if that's the case.
> TC: I do not think as a working group that we should go down the standard=
s track document without many implementations as that has happened in other=
 places within the IETF and document quality has suffered.
>
> I honestly do not think that Chris would make that typo, even when
> speaking ;)
>
> CD: If it gets stuck in the queue for 4 years we may have enough experien=
ce that we may want to push for standards track.
> Rick Taylor: Is there any record of this for this draft being experimenta=
l and then changing to standards track later down the line?
> CD: We will post something up on the list.
> TC: I think that experimental should have an explanation on what the expe=
riment is and what the successful experiment is and what the conclusion is.
> Ulrich: Do you have intention to add a description of what those experime=
nts are and what will make them successful?
> Adrian Farrel: Yes, he does have that intention.
>
> As it reads in the above, it sounds as if I'm making a demand, that Adria=
n is committing Chris to satisfy. That's not exactly how it went down, so p=
erhaps we should clarify that in the minutes?
>
> I'd like to go on record here, that I did not say that it "should have an
> explanation" to cater to my whim, but that I (as I actually stated at the
> mike) I was reciting what I had heard was an IESG statement/requirement
> (so: I thought it was the IESGs whim to be satisfied).
>
> Adrian then clarified this, that it was not an "IESG
> statement/requirement" as such, but that the current routing ADs (which
> include him, so his whim) who require this"
>
> 
>
>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>
> 
>
> Henning: It will also not break anything if different values are used as =
the values are unit-less so the routes might be crazy but they will work.
>
> TC: I think experimental is exactly the place for this document
> Emmanuel: I would like to comment to Rick's earlier comment about if this=
 is related to OLSRv2.  It uses building blocks such as sequence numbers in=
 RFC5444 and missed NHDP HELLO messages to calculate the metric, so in that=
 regard it could be used with other protocols and is not only tied to OLSRv=
2.
> CD: There needs to be a section describing the experiments. TC: I think t=
his draft should be focused to OLSRv2 (and not other protocols) and not mak=
e it something overly broad and have it stall out.Henning: For AODV this me=
tric would be a problem as there isn't normally control traffic or any unic=
ast traffic on a link, so there is nothing to measure.
>
>
> I believe that what I said was that my experience with both proactive and
> reactive protocol deployments leave me to believe that metrics "make sens=
e
> in very different ways in these two protocol families", and therefore wou=
ld
> need to be considered separately. Specifically, constructing an "experime=
nt
> for a metric for a proactive protocol" (which, as this is going
> Experimental, is a requirement by the RTG ADs) is easy - whereas
> constructing an "experiment for the same metric for both a proactive and =
a
> reactive protocol" is a lot harder to do correctly, and probably will jus=
t
> make us stall.
>
> Therefore, given that the existing operational experience, on which this
> document is based, is exclusively for proactive / OLSR, only, my preferen=
ce
> is simply to document the metric as for OLSR, and design the experiment
> accordingly.
>
>
> 
>
>  o draft-gerla-manet-odmrp: Colin de Verdiere
>    draft-gerla-manet-odmrp-asym
>
> Brain-fart here, but I actually do not recall if the authors requested WG
> adoption "now", "a bit later", or "not at all but just wanted to inform t=
he
> WG what we're doing"? - Or was it "none of the above"?
>
> 
>
> o draft-clausen-manet-olsrv2-management-snapshot: Herberg
> UH: Presenting. Requesting WG adoption
>
>
> Have I missed something, or was WG adoption for this document already cal=
led for on the list? If not, any reasons for "not"?
>
> 
>
>  o OLSRv2 + RFC6971: Clausen
> No time for presentation (slides in the proceedings), brought to the mail=
ing list.
>
>
> It'd be kind if the minutes contains a link to the message which Ulrich
> started and wherein the discussion was brought forward:
>
> In the new "archive format" (which I am given to understand is being
> reworked to show the threads) that'd be:
> http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek
>
> or, the format that actually allows seeing the threads, and which is
> useful currently:
> http://www.ietf.org/mail-archive/web/manet/current/msg16016.html
>
> Cheers,
>
> Thomas
>
> On 08 Mar 2014, at 04:04, Ulrich Herberg >
> wrote:
>
> Hello,
>
> I uploaded the preliminary minutes to:
> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet
>
> Please verify correctness and send edits to me by email.
> Many thanks to Justin and Axel for taking the minutes. I have edited and
> merged them.
>
> Best regards
> Ulrich
> _______________________________________________
> manet mailing list
> manet@ietf.org 
> https://www.ietf.org/mailman/listinfo/manet
>
>
>

--20cf3011e0bff0fb0c04f442ce07
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=A0Thomas,

Thanks for the update. I don't think th=
e latest=A0multicast draft was requested to be=A0adopted in the meeting, bu=
t Ulrich did request his it for his draft,=A0and I am waiting for announce=
=A0on=A0the list for DLEP plan=A0and all=A0adoption request in WG=A0meeting=
.=A0



AB

On Monday, March 10, 2014, Thomas Clausen  wr=
ote:
=
Ulrich,


Thank you for prompt posting of minutes.
=A0
=

A couple of things that I would like to make more precise, all the sam=
e, in the minutes:

o draft-ietf-manet-olsrv2-multitopology: Dearlove

<SNIP>
Teco: Why not make this do=
cument standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's the case=
.
TC: I do not think as a working group that we should go down the standards =
track document without many implementations as that has happened in other p=
laces within the IETF and document quality has suffered.


I honestly do not think that Chris would make that typo, even when spe=
aking ;)
CD: If it gets stuck in the queue for 4 years we may have enough experience=
 that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being experimental =
and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the experi=
ment is and what the successful experiment is and what the conclusion is.
Ulrich: Do you have intention to add a description of what those experiment=
s are and what will make them successful?
Adrian Farrel: Yes, he does have that intention.
As it reads in the above, it sounds as=
 if I'm making a demand, that Adrian is committing Chris to satisfy. Th=
at's not exactly how it went down, so perhaps we should clarify that in=
 the minutes?


I'd like to go on record here, that I did not say that it "sh=
ould have an explanation" to cater to my whim, but that I (as I actual=
ly stated at the mike) I was reciting what I had heard was an IESG statemen=
t/requirement (so: I thought it was the IESGs whim to be satisfied).



Adrian then clarified this, that it was not an "IE=
SG statement/requirement" as such, but that the current routing ADs (w=
hich include him, so his whim) who require this"



<SNIP>

 o draft-rogge-baccelli-=
olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will also not break anything if different values are used as th=
e values are unit-less so the routes might be crazy but they will work.
TC: I=
 think experimental is exactly the place for this document
Emmanuel: I would like to comment to Rick's earlier comment about if th=
is is related to OLSRv2.  It uses building blocks such as sequence numbers =
in RFC5444 and missed NHDP HELLO messages to calculate the metric, so in th=
at regard it could be used with other protocols and is not only tied to OLS=
Rv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to OLSRv2 =
(and not other protocols) and not make it something overly broad and have i=
t stall out.
Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is noth=
ing to measure.


I believe that what I said was that my experience with both proactive and r=
eactive protocol deployments leave me to believe that metrics "make se=
nse in very different ways in these two protocol families", and theref=
ore would need to be considered separately. Specifically, constructing an &=
quot;experiment for a metric for a proactive protocol" (which, as this=
 is going Experimental, is a requirement by the RTG ADs) is easy - whereas =
constructing an "experiment for the same metric for both a proactive a=
nd a reactive protocol" is a lot harder to do correctly, and probably =
will just make us stall.



Therefore, given that the existing operational experien=
ce, on which this document is based, is exclusively for proactive / OLSR, o=
nly, my preference is simply to document the metric as for OLSR, and design=
 the experiment accordingly.



<SNIP>

 o draft-gerla=
-manet-odmrp: Colin de Verdiere
   draft-gerla-manet-odmrp-asym
Brain-fart here, but=
 I actually do not recall if the authors requested WG adoption "now&qu=
ot;, "a bit later", or "not at all but just wanted to inform=
 the WG what we're doing"? - Or was it "none of the above&quo=
t;?



<SNIP>

o =
draft-clausen-manet-olsrv2-management-snapshot: Herberg
UH: Presenting. Requesting WG adoption


Have I missed s=
omething, or was WG adoption for this document already called for on the li=
st? If not, any reasons for "not"?



<SNIP>

<=
/div>
 o OLSRv2 + RFC6971: Clausen
No time for presentation (slides in the proceedings), brought to the mailin=
g list.

It'd be kind if the=
 minutes contains a link to the message which Ulrich started and wherein th=
e discussion was brought forward:



	In the new=
 "archive format" (which I am given to understand is being rework=
ed to show the threads) that'd be:



	or, the fo=
rmat that actually allows seeing the threads, and which is useful currently=
:
		http://www.ietf.org/mail-archive/web/manet/current/msg16016.html


Cheers,

Thomas

<=
/div>
On 08 Mar 2014, at 04:04, Ulrich Herberg <ulrich@herberg.name> wrote:


Hello,

I uploaded the preliminary minutes to:
http://www.ietf.=
org/proceedings/89/minutes/minutes-89-manet



Please verify correctness and send edits to me by email.
Many =
thanks to Justin and Axel for taking the minutes. I have edited and merged =
them.

Best regards
Ulrich

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





--20cf3011e0bff0fb0c04f442ce07--


From nobody Mon Mar 10 09:13:31 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A8A1A04AE for ; Mon, 10 Mar 2014 09:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9THt87cwDsU for ; Mon, 10 Mar 2014 09:13:20 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 72AB71A0449 for ; Mon, 10 Mar 2014 09:13:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 698D16009EB; Mon, 10 Mar 2014 09:13:15 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from air-de-axel.lan (139-96-190-109.dsl.ovh.fr [109.190.96.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9A6386010A6; Mon, 10 Mar 2014 09:13:05 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0D048012-8A79-48DF-BB81-2252415E9EB9"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
In-Reply-To: 
Date: Mon, 10 Mar 2014 17:13:00 +0100
Message-Id: <7CC2AB65-06AD-4825-A476-BEDF422F482A@axelcdv.com>
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org> 
To: Abdussalam Baryun 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/I7J8VwHcRii_X8oJ5WU8ahBkEMw
Cc: "" , MANET IETF , thomas Clausen 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 16:13:24 -0000

--Apple-Mail=_0D048012-8A79-48DF-BB81-2252415E9EB9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi all,

We did not in fact request WG adoption for ODMRP and ODMRP_ASYM at this =
time, but we felt that the drafts were in good enough shape to ask for =
your comments and move in that direction.

Axel

Le 10 mars 2014 =E0 17:08, Abdussalam Baryun =
 a =E9crit :

> Hi Thomas,
>=20
> Thanks for the update. I don't think the latest multicast draft was =
requested to be adopted in the meeting, but Ulrich did request his it =
for his draft, and I am waiting for announce on the list for DLEP plan =
and all adoption request in WG meeting.=20
>=20
> AB
>=20
> On Monday, March 10, 2014, Thomas Clausen wrote:
> Ulrich,
>=20
> Thank you for prompt posting of minutes.
> =20
> A couple of things that I would like to make more precise, all the =
same, in the minutes:
>=20
>> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>=20
> 
>> Teco: Why not make this document standards track?
>> CD: If people implement this and it's great.  Then I'm find  fine =
changing this to standards track if that's the case.
>> TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.
> I honestly do not think that Chris would make that typo, even when =
speaking ;)
>> CD: If it gets stuck in the queue for 4 years we may have enough =
experience that we may want to push for standards track.
>> Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
>> CD: We will post something up on the list.
>> TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
>> Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
>> Adrian Farrel: Yes, he does have that intention.
> As it reads in the above, it sounds as if I'm making a demand, that =
Adrian is committing Chris to satisfy. That's not exactly how it went =
down, so perhaps we should clarify that in the minutes?
>=20
> I'd like to go on record here, that I did not say that it "should have =
an explanation" to cater to my whim, but that I (as I actually stated at =
the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).
>=20
>=20
> Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"
>=20
>=20
> 
>=20
>>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>=20
> 
>> Henning: It will also not break anything if different values are used =
as the values are unit-less so the routes might be crazy but they will =
work.
>> TC: I think experimental is exactly the place for this document
>> Emmanuel: I would like to comment to Rick's earlier comment about if =
this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
>> CD: There needs to be a section describing the experiments.=20
>> TC: I think this draft should be focused to OLSRv2 (and not other =
protocols) and not make it something overly broad and have it stall out.
>> Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.
>=20
>=20
> I believe that what I said was that my experience with both proactive =
and reactive protocol deployments leave me to believe that metrics "make =
sense in very different ways in these two protocol families", and =
therefore would need to be considered separately. Specifically, =
constructing an "experiment for a metric for a proactive protocol" =
(which, as this is going Experimental, is a requirement by the RTG ADs) =
is easy - whereas constructing an "experiment for the same metric for =
both a proactive and a reactive protocol" is a lot harder to do =
correctly, and probably will just make us stall.
>=20
>=20
> Therefore, given that the existing operational experience, on which =
this document is based, is exclusively for proactive / OLSR, only, my =
preference is simply to document the metric as for OLSR, and design the =
experiment accordingly.
>=20
>=20
> 
>=20
>>  o draft-gerla-manet-odmrp: Colin de Verdiere
>>    draft-gerla-manet-odmrp-asym
> Brain-fart here, but I actually do not recall if the authors requested =
WG adoption "now", "a bit later", or "not at all but just wanted to =
inform the WG what we're doing"? - Or was it "none of the above"?
>=20
> 
>=20
>> o draft-clausen-manet-olsrv2-management-snapshot: Herberg
>> UH: Presenting. Requesting WG adoption
>=20
> Have I missed something, or was WG adoption for this document already =
called for on the list? If not, any reasons for "not"?
>=20
>=20
> 
>=20
>>  o OLSRv2 + RFC6971: Clausen
>> No time for presentation (slides in the proceedings), brought to the =
mailing list.
>=20
> It'd be kind if the minutes contains a link to the message which =
Ulrich started and wherein the discussion was brought forward:
>=20
> 	In the new "archive format" (which I am given to understand is =
being reworked to show the threads) that'd be:
> 		=
http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek
>=20
> 	or, the format that actually allows seeing the threads, and =
which is useful currently:
> 		=
http://www.ietf.org/mail-archive/web/manet/current/msg16016.html
>=20
> Cheers,
>=20
> Thomas
>=20
> On 08 Mar 2014, at 04:04, Ulrich Herberg  wrote:
>=20
>> Hello,
>>=20
>> I uploaded the preliminary minutes to:
>> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet
>>=20
>> Please verify correctness and send edits to me by email.
>> Many thanks to Justin and Axel for taking the minutes. I have edited =
and merged them.
>>=20
>> Best regards
>> Ulrich
>> _______________________________________________
>> 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=_0D048012-8A79-48DF-BB81-2252415E9EB9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Hi =
all,

We did not in fact request WG adoption for ODMRP =
and ODMRP_ASYM at this time, but we felt that the drafts were in good =
enough shape to ask for your comments and move in that =
direction.

Axel

Le 10 =
mars 2014 =E0 17:08, Abdussalam Baryun <abdussalambaryun@gmail.com&=
gt; a =E9crit :

Hi Thomas,

Thanks for the update. =
I don't think the latest multicast draft was requested to =
be adopted in the meeting, but Ulrich did request his it for his =
draft, and I am waiting for announce on the list for DLEP =
plan and all adoption request in WG meeting. 



AB

On Monday, March 10, 2014, Thomas Clausen  =
wrote:
Ulrich,


Thank you for prompt posting of =
minutes.
 
A couple of things that I would like =
to make more precise, all the same, in the =
minutes:

o draft-ietf-manet-olsrv2-multitopology: Dearlove

<SNIP>
Teco: Why not make =
this document standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's =
the case.
TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.


I honestly do not think that Chris would make that typo, even when =
speaking ;)
CD: If it gets stuck =
in the queue for 4 years we may have enough experience that we may want =
to push for standards track.
Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
Adrian Farrel: Yes, he does have that =
intention.
As it reads in the =
above, it sounds as if I'm making a demand, that Adrian is committing =
Chris to satisfy. That's not exactly how it went down, so perhaps we =
should clarify that in the minutes?


I'd like to go on record here, that I did not say that it "should =
have an explanation" to cater to my whim, but that I (as I actually =
stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).



Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"



<SNIP>

 o draft-rogge-baccelli-olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will =
also not break anything if different values are used as the values are =
unit-less so the routes might be crazy but they will =
work.
TC: I think =
experimental is exactly the place for this document
Emmanuel: I would like to comment to Rick's earlier comment about if =
this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to =
OLSRv2 (and not other protocols) and not make it something overly broad =
and have it stall out.
Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.


I believe that what I said was that my experience with both proactive =
and reactive protocol deployments leave me to believe that metrics "make =
sense in very different ways in these two protocol families", and =
therefore would need to be considered separately. Specifically, =
constructing an "experiment for a metric for a proactive protocol" =
(which, as this is going Experimental, is a requirement by the RTG ADs) =
is easy - whereas constructing an "experiment for the same metric for =
both a proactive and a reactive protocol" is a lot harder to do =
correctly, and probably will just make us stall.



Therefore, given that the existing operational =
experience, on which this document is based, is exclusively for =
proactive / OLSR, only, my preference is simply to document the metric =
as for OLSR, and design the experiment accordingly.



<SNIP>

 =
o draft-gerla-manet-odmrp: Colin de Verdiere
   draft-gerla-manet-odmrp-asym
Brain-fart here, =
but I actually do not recall if the authors requested WG adoption "now", =
"a bit later", or "not at all but just wanted to inform the WG what =
we're doing"? - Or was it "none of the above"?



<SNIP>

o draft-clausen-manet-olsrv2-management-snapshot: Herberg
UH: Presenting. Requesting WG adoption


Have I missed =
something, or was WG adoption for this document already called for on =
the list? If not, any reasons for "not"?



<SNIP>
=

 o OLSRv2 + RFC6971: =
Clausen
No time for presentation (slides in the proceedings), brought to the =
mailing list.

It'd be kind =
if the minutes contains a link to the message which Ulrich started and =
wherein the discussion was brought forward:



	=
In the new "archive format" (which I am given to understand is =
being reworked to show the threads) that'd be:



	=
or, the format that actually allows seeing the threads, and which =
is useful currently:

=


Cheers,

Thomas

=

On 08 Mar 2014, at 04:04, Ulrich Herberg <ulrich@herberg.name> wrote:


Hello,

I uploaded the preliminary =
minutes to:
http://www.ietf.org/proceedings/89/minutes/minutes-89-ma=
net



Please verify correctness and send edits to me by =
email.
Many thanks to Justin and Axel for taking the minutes. I =
have edited and merged them.

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

=

--Apple-Mail=_0D048012-8A79-48DF-BB81-2252415E9EB9--


From nobody Mon Mar 10 09:25:47 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F151A04A8 for ; Mon, 10 Mar 2014 09:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNR3Ld_l_em3 for ; Mon, 10 Mar 2014 09:25:41 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C14CA1A049C for ; Mon, 10 Mar 2014 09:25:40 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id x13so9014933wgg.14 for ; Mon, 10 Mar 2014 09:25:35 -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:from:subject:date:to; bh=yVLVBXqHSNoVPIVDHN9nNXx8raLXohdMJe0KgDWgDQc=; b=j2wDrNUB8O1VD2M80Q6new1IWqvnTQNbgZfX/h+JLE2+ZnlfHMcDH8EluvuIU8kBP0 yC0+K0EG3hC79evW+m2YOeJNCS9Dx97pR6hQx01PdOFTCLvHEZk1sjFHCrVVQK+qa/SU kkYsusciP483YZ08eKWw8N1Brd/RCOVhsKsHHNDk51R1DtjizKyFIDDJu/rH9Jz7gwTx ekk830iAeh07kJoCQd/bp3reuPbJiwR6x/Q5bq/8tmaJfcxCVSZIlM0OeCqPmW+hLgpL RAKflGnJpE0nR9UbvHxf+mebhHR/Pm0pbo3TqCUpRzYVDl1wAe6qHJb5xgXGcUggCnuw LozQ==
X-Received: by 10.194.58.180 with SMTP id s20mr2323227wjq.54.1394468734947; Mon, 10 Mar 2014 09:25:34 -0700 (PDT)
Received: from [10.181.39.20] (dab-ell1-h-84-7.dab.02.net. [82.132.238.238]) by mx.google.com with ESMTPSA id 12sm52431580wjm.10.2014.03.10.09.25.33 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 09:25:34 -0700 (PDT)
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-65189C39-C2C9-4D80-86B0-23979FF207DC
Content-Transfer-Encoding: 7bit
Message-Id: <39F0705F-E39E-4031-A85B-37FEF42EF30C@gmail.com>
X-Mailer: iPhone Mail (11B651)
From: Christopher Dearlove 
Date: Mon, 10 Mar 2014 16:25:29 +0000
To: Abdussalam Baryun 
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ljqZUjxwdKS-OGOmXffc8VlZRaE
Cc: "" , MANET IETF , Thomas Clausen 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 16:25:44 -0000

--Apple-Mail-65189C39-C2C9-4D80-86B0-23979FF207DC
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

The multicast draft has already been accepted by the WG. The next process st=
age is WGLC, which we haven't requested yet. Now is the time for any comment=
s before we do request that.

--=20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

> On 10 Mar 2014, at 16:08, Abdussalam Baryun  w=
rote:
>=20
> Hi Thomas,
>=20
> Thanks for the update. I don't think the latest multicast draft was reques=
ted to be adopted in the meeting, but Ulrich did request his it for his draf=
t, and I am waiting for announce on the list for DLEP plan and all adoption r=
equest in WG meeting.=20
>=20
> AB
>=20
>> On Monday, March 10, 2014, Thomas Clausen wrote:
>> Ulrich,
>>=20
>> Thank you for prompt posting of minutes.
>> =20
>> A couple of things that I would like to make more precise, all the same, i=
n the minutes:
>>=20
>>> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>>=20
>> 
>>> Teco: Why not make this document standards track?
>>> CD: If people implement this and it's great.  Then I'm find  fine changi=
ng this to standards track if that's the case.
>>> TC: I do not think as a working group that we should go down the standar=
ds track document without many implementations as that has happened in other=
 places within the IETF and document quality has suffered.
>> I honestly do not think that Chris would make that typo, even when speaki=
ng ;)
>>> CD: If it gets stuck in the queue for 4 years we may have enough experie=
nce that we may want to push for standards track.
>>> Rick Taylor: Is there any record of this for this draft being experiment=
al and then changing to standards track later down the line?
>>> CD: We will post something up on the list.
>>> TC: I think that experimental should have an explanation on what the exp=
eriment is and what the successful experiment is and what the conclusion is.=

>>> Ulrich: Do you have intention to add a description of what those experim=
ents are and what will make them successful?
>>> Adrian Farrel: Yes, he does have that intention.
>> As it reads in the above, it sounds as if I'm making a demand, that Adria=
n is committing Chris to satisfy. That's not exactly how it went down, so pe=
rhaps we should clarify that in the minutes?
>>=20
>> I'd like to go on record here, that I did not say that it "should have an=
 explanation" to cater to my whim, but that I (as I actually stated at the m=
ike) I was reciting what I had heard was an IESG statement/requirement (so: I=
 thought it was the IESGs whim to be satisfied).
>>=20
>>=20
>> Adrian then clarified this, that it was not an "IESG statement/requiremen=
t" as such, but that the current routing ADs (which include him, so his whim=
) who require this"
>>=20
>>=20
>> 
>>=20
>>>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>>=20
>> 
>>> Henning: It will also not break anything if different values are used as=
 the values are unit-less so the routes might be crazy but they will work.
>>> TC: I think experimental is exactly the place for this document
>>> Emmanuel: I would like to comment to Rick's earlier comment about if thi=
s is related to OLSRv2.  It uses building blocks such as sequence numbers in=
 RFC5444 and missed NHDP HELLO messages to calculate the metric, so in that r=
egard it could be used with other protocols and is not only tied to OLSRv2.
>>> CD: There needs to be a section describing the experiments.=20
>>> TC: I think this draft should be focused to OLSRv2 (and not other protoc=
ols) and not make it something overly broad and have it stall out.
>>> Henning: For AODV this metric would be a problem as there isn't normally=
 control traffic or any unicast traffic on a link, so there is nothing to me=
asure.
>>=20
>>=20
>> I believe that what I said was that my experience with both proactive and=
 reactive protocol deployments leave me to believe that metrics "make sense i=
n very different ways in these two protocol families", and therefore would n=
eed to be considered separately. Specifically, constructing an "experiment f=
or a metric for a proactive protocol" (which, as this is going Experimental,=
 is a requirement by the RTG ADs) is easy - whereas constructing an "experim=
ent for the same metric for both a proactive and a reactive protocol" is a l=
ot harder to do correctly, and probably will just make us stall.
>>=20
>>=20
>> Therefore, given that the existing operational experience, on which this d=
ocument is based, is exclusively for proactive / OLSR, only, my preference i=
s simply to document the metric as for OLSR, and design the experiment accor=
dingly.
>>=20
>>=20
>> 
>>=20
>>>  o draft-gerla-manet-odmrp: Colin de Verdiere
>>>    draft-gerla-manet-odmrp-asym
>> Brain-fart here, but I actually do not recall if the authors requested WG=
 adoption "now", "a bit later", or "not at all but just wanted to inform the=
 WG what we're doing"? - Or was it "none of the above"?
>>=20
>> 
>>=20
>>> o draft-clausen-manet-olsrv2-management-snapshot: Herberg
>>> UH: Presenting. Requesting WG adoption
>>=20
>> Have I missed something, or was WG adoption for this document already cal=
led for on the list? If not, any reasons for "not"?
>>=20
>>=20
>> 
>>=20
>>>  o OLSRv2 + RFC6971: Clausen
>>> No time for presentation (slides in the proceedings), brought to the mai=
ling list.
>>=20
>> It'd be kind if the minutes contains a link to the message which Ulrich s=
tarted and wherein the discussion was brought forward:
>>=20
>> 	In the new "archive format" (which I am given to understand is bein=
g reworked to show the threads) that'd be:
>> 		http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NP=
bafy5Vet9ek
>>=20
>> 	or, the format that actually allows seeing the threads, and which i=
s useful currently:
>> 		http://www.ietf.org/mail-archive/web/manet/current/msg16016=
.html
>>=20
>> Cheers,
>>=20
>> Thomas
>>=20
>>> On 08 Mar 2014, at 04:04, Ulrich Herberg  wrote:
>>>=20
>>> Hello,
>>>=20
>>> I uploaded the preliminary minutes to:
>>> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet
>>>=20
>>> Please verify correctness and send edits to me by email.
>>> Many thanks to Justin and Axel for taking the minutes. I have edited and=
 merged them.
>>>=20
>>> 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

--Apple-Mail-65189C39-C2C9-4D80-86B0-23979FF207DC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


The multicast draft has already been a=
ccepted by the WG. The next process stage is WGLC, which we haven't requeste=
d yet. Now is the time for any comments before we do request that.

--=
 
Christopher Dearlove

On 10 Mar 2014, at 16:08, Abdussalam Baryun <abdussalambaryun@gmail.com>=
 wrote:

Hi Thomas,

=

Thanks for the update. I don't think the latest multicast dr=
aft was requested to be adopted in the meeting, but Ulrich did request h=
is it for his draft, and I am waiting for announce on the lis=
t for DLEP plan and all adoption request in WG meeting. =




AB

On Monday, March 10, 2014, Thomas Clausen  wro=
te:
Ulr=
ich,


Thank you for prompt posting of minutes.
 
A couple of things that I would like to make more precise, all the sa=
me, in the minutes:

o draft-ietf-manet-olsrv=
2-multitopology: Dearlove

<SNIP>
Teco: Why not make this docum=
ent standards track?
CD: If people implement this and it's great.  Then I'm find  fine<=
/font> changing this to standards track if that's the case.
TC: I do not think as a working group that we should go down the standards t=
rack document without many implementations as that has happened in other pla=
ces within the IETF and document quality has suffered.


I honestly do not think that Chris would make that typo, even when spea=
king ;)
CD: If it gets stuck in the queue for 4 years we may have enough experience=
 that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being experimental a=
nd then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the experim=
ent is and what the successful experiment is and what the conclusion is.
Ulrich: Do you have intention to add a description of what those experiments=
 are and what will make them successful?
Adrian Farrel: Yes, he does have that intention.
As it reads in the above, it sounds as if=
 I'm making a demand, that Adrian is committing Chris to satisfy. That's not=
 exactly how it went down, so perhaps we should clarify that in the minutes?=



I'd like to go on record here, that I did not say that it "should have a=
n explanation" to cater to my whim, but that I (as I actually stated at the m=
ike) I was reciting what I had heard was an IESG statement/requirement (so: I=
 thought it was the IESGs whim to be satisfied).



Adrian then clarified this, that it was not an "IESG sta=
tement/requirement" as such, but that the current routing ADs (which include=
 him, so his whim) who require this"



<SNIP>

 o draft-rogge-baccelli-ol=
srv2-ett-metric: Rogge

=
<SNIP>
<=
/pre>
Henning: It will also not break anything if different=
 values are used as the values are unit-less so the routes might be crazy bu=
t they will work.
TC: I think experimental is exactly the place for this docume=
nt
Emmanuel: I would like to comment to Rick's earlier comment about if this is=
 related to OLSRv2.  It uses building blocks such as sequence numbers in RFC=
5444 and missed NHDP HELLO messages to calculate the metric, so in that rega=
rd it could be used with other protocols and is not only tied to OLSRv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to OLSRv2 (=
and not other protocols) and not make it something overly broad and have it s=
tall out.
Henning: For AODV this metric would be a problem as there isn't norma=
lly control traffic or any unicast traffic on a link, so there is nothing to=
 measure.


I believe that what I said was that my experience with both proactive and re=
active protocol deployments leave me to believe that metrics "make sense in v=
ery different ways in these two protocol families", and therefore would need=
 to be considered separately. Specifically, constructing an "experiment for a=
 metric for a proactive protocol" (which, as this is going Experimental, is a=
 requirement by the RTG ADs) is easy - whereas constructing an "experiment f=
or the same metric for both a proactive and a reactive protocol" is a lot ha=
rder to do correctly, and probably will just make us stall.



Therefore, given that the existing operational experienc=
e, on which this document is based, is exclusively for proactive / OLSR, onl=
y, my preference is simply to document the metric as for OLSR, and design th=
e experiment accordingly.



<SNIP>

=

 o draft-gerla-mane=
t-odmrp: Colin de Verdiere
   draft-gerla-manet-odmrp-asym
Brain-fart here, but I=
 actually do not recall if the authors requested WG adoption "now", "a bit l=
ater", or "not at all but just wanted to inform the WG what we're doing"? - O=
r was it "none of the above"?



<SNIP>

o draf=
t-clausen-manet-olsrv2-management-snapshot: Herberg
UH: Presenting. Requesting WG adoption


Have I missed som=
ething, or was WG adoption for this document already called for on the list?=
 If not, any reasons for "not"?



<SNIP>

 o OLSRv2 + RFC6971: Clausen
No time for presentation (slides in the proceedings), brought to the mailing=
 list.

It'd be kind if the minut=
es contains a link to the message which Ulrich started and wherein the discu=
ssion was brought forward:



	In t=
he new "archive format" (which I am given to understand is being reworked to=
 show the threads) that'd be:



	or, t=
he format that actually allows seeing the threads, and which is useful curre=
ntly:



Cheers,

Thomas

On 08 Mar 2014, at 04:04, Ulrich Herberg <ulrich@herb=
erg.name> wrote:


Hello,

I uploaded the preliminary minutes to:
http://www.ietf.org=
/proceedings/89/minutes/minutes-89-manet



Please verify correctness and send edits to me by email.
Many t=
hanks to Justin and Axel for taking the minutes. I have edited and merged th=
em.

Best regards
Ulrich

_______________________________________________
manet mailing list
man=
et@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-65189C39-C2C9-4D80-86B0-23979FF207DC--


From nobody Mon Mar 10 09:29:39 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F07C1A04AE for ; Mon, 10 Mar 2014 09:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPJXs7ep3VR2 for ; Mon, 10 Mar 2014 09:29:32 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 76C1B1A04A8 for ; Mon, 10 Mar 2014 09:29:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 57D26620018; Mon, 10 Mar 2014 09:29:27 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id AFAB8620013; Mon, 10 Mar 2014 09:29:23 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_710A5A15-1AAB-48CE-8836-863D70484D11"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Clausen 
In-Reply-To: <39F0705F-E39E-4031-A85B-37FEF42EF30C@gmail.com>
Date: Mon, 10 Mar 2014 17:29:18 +0100
Message-Id: 
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org>  <39F0705F-E39E-4031-A85B-37FEF42EF30C@gmail.com>
To: Christopher Dearlove 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/N5ZfVGbUP1TYeTyVUmacvWjl5P0
Cc: "" , MANET IETF 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 16:29:36 -0000

--Apple-Mail=_710A5A15-1AAB-48CE-8836-863D70484D11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On 10 Mar 2014, at 17:25, Christopher Dearlove =
 wrote:

> The multicast draft has already been accepted by the WG. The next =
process stage is WGLC, which we haven't requested yet. Now is the time =
for any comments before we do request that.
>=20

Are you sure, Chris?=20

I am almost betting that you're mistaken "Multi-Topology" and =
"Multicast".....the former, surely, is WG document. The latter (which =
Axel presented) is not (yet, at least, and was what I asked about)

Of course, there may be a secret multicast WG document that I am not =
aware of :D

Thomas

> --=20
> Christopher Dearlove
> christopher.dearlove@gmail.com (iPhone)
> chris@mnemosyne.demon.co.uk (home)
>=20
> On 10 Mar 2014, at 16:08, Abdussalam Baryun =
 wrote:
>=20
>> Hi Thomas,
>>=20
>> Thanks for the update. I don't think the latest multicast draft was =
requested to be adopted in the meeting, but Ulrich did request his it =
for his draft, and I am waiting for announce on the list for DLEP plan =
and all adoption request in WG meeting.=20
>>=20
>> AB
>>=20
>> On Monday, March 10, 2014, Thomas Clausen wrote:
>> Ulrich,
>>=20
>> Thank you for prompt posting of minutes.
>> =20
>> A couple of things that I would like to make more precise, all the =
same, in the minutes:
>>=20
>>> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>>=20
>> 
>>> Teco: Why not make this document standards track?
>>> CD: If people implement this and it's great.  Then I'm find  fine =
changing this to standards track if that's the case.
>>> TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.
>> I honestly do not think that Chris would make that typo, even when =
speaking ;)
>>> CD: If it gets stuck in the queue for 4 years we may have enough =
experience that we may want to push for standards track.
>>> Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
>>> CD: We will post something up on the list.
>>> TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
>>> Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
>>> Adrian Farrel: Yes, he does have that intention.
>> As it reads in the above, it sounds as if I'm making a demand, that =
Adrian is committing Chris to satisfy. That's not exactly how it went =
down, so perhaps we should clarify that in the minutes?
>>=20
>> I'd like to go on record here, that I did not say that it "should =
have an explanation" to cater to my whim, but that I (as I actually =
stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).
>>=20
>>=20
>> Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"
>>=20
>>=20
>> 
>>=20
>>>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>>=20
>> 
>>> Henning: It will also not break anything if different values are =
used as the values are unit-less so the routes might be crazy but they =
will work.
>>> TC: I think experimental is exactly the place for this document
>>> Emmanuel: I would like to comment to Rick's earlier comment about if =
this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
>>> CD: There needs to be a section describing the experiments.=20
>>> TC: I think this draft should be focused to OLSRv2 (and not other =
protocols) and not make it something overly broad and have it stall out.
>>> Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.
>>=20
>>=20
>> I believe that what I said was that my experience with both proactive =
and reactive protocol deployments leave me to believe that metrics "make =
sense in very different ways in these two protocol families", and =
therefore would need to be considered separately. Specifically, =
constructing an "experiment for a metric for a proactive protocol" =
(which, as this is going Experimental, is a requirement by the RTG ADs) =
is easy - whereas constructing an "experiment for the same metric for =
both a proactive and a reactive protocol" is a lot harder to do =
correctly, and probably will just make us stall.
>>=20
>>=20
>> Therefore, given that the existing operational experience, on which =
this document is based, is exclusively for proactive / OLSR, only, my =
preference is simply to document the metric as for OLSR, and design the =
experiment accordingly.
>>=20
>>=20
>> 
>>=20
>>>  o draft-gerla-manet-odmrp: Colin de Verdiere
>>>    draft-gerla-manet-odmrp-asym
>> Brain-fart here, but I actually do not recall if the authors =
requested WG adoption "now", "a bit later", or "not at all but just =
wanted to inform the WG what we're doing"? - Or was it "none of the =
above"?
>>=20
>> 
>>=20
>>> o draft-clausen-manet-olsrv2-management-snapshot: Herberg
>>> UH: Presenting. Requesting WG adoption
>>=20
>> Have I missed something, or was WG adoption for this document already =
called for on the list? If not, any reasons for "not"?
>>=20
>>=20
>> 
>>=20
>>>  o OLSRv2 + RFC6971: Clausen
>>> No time for presentation (slides in the proceedings), brought to the =
mailing list.
>>=20
>> It'd be kind if the minutes contains a link to the message which =
Ulrich started and wherein the discussion was brought forward:
>>=20
>> 	In the new "archive format" (which I am given to understand is =
being reworked to show the threads) that'd be:
>> 		=
http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek
>>=20
>> 	or, the format that actually allows seeing the threads, and =
which is useful currently:
>> 		=
http://www.ietf.org/mail-archive/web/manet/current/msg16016.html
>>=20
>> Cheers,
>>=20
>> Thomas
>>=20
>> On 08 Mar 2014, at 04:04, Ulrich Herberg  wrote:
>>=20
>>> Hello,
>>>=20
>>> I uploaded the preliminary minutes to:
>>> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet
>>>=20
>>> Please verify correctness and send edits to me by email.
>>> Many thanks to Justin and Axel for taking the minutes. I have edited =
and merged them.
>>>=20
>>> Best regards
>>> Ulrich
>>> _______________________________________________
>>> 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
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


--Apple-Mail=_710A5A15-1AAB-48CE-8836-863D70484D11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On 10 Mar 2014, at 17:25, Christopher =
Dearlove <christopher.dearlove@gmail.=
com> wrote:

The multicast draft has already been accepted by the =
WG. The next process stage is WGLC, which we haven't requested yet. Now =
is the time for any comments before we do request =
that.


Are you sure, =
Chris? 

I am almost betting that you're =
mistaken "Multi-Topology" and "Multicast".....the former, surely, is WG =
document. The latter (which Axel presented) is not (yet, at least, and =
was what I asked about)

Of course, there may be =
a secret multicast WG document that I am not aware of =
:D

Thomas

Hi Thomas,

Thanks for the update. =
I don't think the latest multicast draft was requested to =
be adopted in the meeting, but Ulrich did request his it for his =
draft, and I am waiting for announce on the list for DLEP =
plan and all adoption request in WG meeting. 



AB

On Monday, March 10, 2014, Thomas Clausen  =
wrote:
Ulrich,


Thank you for prompt posting of =
minutes.
 
A couple of things that I would like =
to make more precise, all the same, in the =
minutes:

o draft-ietf-manet-olsrv2-multitopology: Dearlove

<SNIP>
Teco: Why not make =
this document standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's =
the case.
TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.


I honestly do not think that Chris would make that typo, even when =
speaking ;)
CD: If it gets stuck =
in the queue for 4 years we may have enough experience that we may want =
to push for standards track.
Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
Adrian Farrel: Yes, he does have that =
intention.
As it reads in the =
above, it sounds as if I'm making a demand, that Adrian is committing =
Chris to satisfy. That's not exactly how it went down, so perhaps we =
should clarify that in the minutes?


I'd like to go on record here, that I did not say that it "should =
have an explanation" to cater to my whim, but that I (as I actually =
stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).



Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"



<SNIP>

 o draft-rogge-baccelli-olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will =
also not break anything if different values are used as the values are =
unit-less so the routes might be crazy but they will =
work.
TC: I think =
experimental is exactly the place for this document
Emmanuel: I would like to comment to Rick's earlier comment about if =
this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to =
OLSRv2 (and not other protocols) and not make it something overly broad =
and have it stall out.
Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.


I believe that what I said was that my experience with both proactive =
and reactive protocol deployments leave me to believe that metrics "make =
sense in very different ways in these two protocol families", and =
therefore would need to be considered separately. Specifically, =
constructing an "experiment for a metric for a proactive protocol" =
(which, as this is going Experimental, is a requirement by the RTG ADs) =
is easy - whereas constructing an "experiment for the same metric for =
both a proactive and a reactive protocol" is a lot harder to do =
correctly, and probably will just make us stall.



Therefore, given that the existing operational =
experience, on which this document is based, is exclusively for =
proactive / OLSR, only, my preference is simply to document the metric =
as for OLSR, and design the experiment accordingly.



<SNIP>

 =
o draft-gerla-manet-odmrp: Colin de Verdiere
   draft-gerla-manet-odmrp-asym
Brain-fart here, =
but I actually do not recall if the authors requested WG adoption "now", =
"a bit later", or "not at all but just wanted to inform the WG what =
we're doing"? - Or was it "none of the above"?



<SNIP>

o draft-clausen-manet-olsrv2-management-snapshot: Herberg
UH: Presenting. Requesting WG adoption


Have I missed =
something, or was WG adoption for this document already called for on =
the list? If not, any reasons for "not"?



<SNIP>
=

 o OLSRv2 + RFC6971: =
Clausen
No time for presentation (slides in the proceedings), brought to the =
mailing list.

It'd be kind =
if the minutes contains a link to the message which Ulrich started and =
wherein the discussion was brought forward:



	=
In the new "archive format" (which I am given to understand is =
being reworked to show the threads) that'd be:



	=
or, the format that actually allows seeing the threads, and which =
is useful currently:

=


Cheers,

Thomas

=

On 08 Mar 2014, at 04:04, Ulrich Herberg <ulrich@herberg.name> wrote:


Hello,

I uploaded the preliminary =
minutes to:
http://www.ietf.org/proceedings/89/minutes/minutes-89-ma=
net



Please verify correctness and send edits to me by =
email.
Many thanks to Justin and Axel for taking the minutes. I =
have edited and merged them.

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
__________________=
_____________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/=
mailman/listinfo/manet

=

--Apple-Mail=_710A5A15-1AAB-48CE-8836-863D70484D11--


From nobody Mon Mar 10 09:37:01 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0F01A04B0 for ; Mon, 10 Mar 2014 09:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGkwndkBHmGi for ; Mon, 10 Mar 2014 09:36:56 -0700 (PDT)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7320E1A0262 for ; Mon, 10 Mar 2014 09:36:56 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id id10so977816vcb.26 for ; Mon, 10 Mar 2014 09:36:51 -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=LmwVyHhy9LhEHb1STpkqYsqbOI2KSG9zagPFiw+nrRw=; b=3CeyF+9ns9DdoRH651l3b9H3pHUzEJMkNsOPmc0gO/S7pvZJ7BFN4XUO2oxlUOHH23 XIefYPKAjYgI1C8/npjJ73PUACdtWnWz6qfmA2liVzgQP5qRKzwDKhXT0a0XA8TGejx0 Jp9hr1AzEeD+JmM80kULRdqPRYvIwm+pFfMc8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LmwVyHhy9LhEHb1STpkqYsqbOI2KSG9zagPFiw+nrRw=; b=MTNsOcK2TF3O0fl2zoHuMHUghpVuCv9YbcqHZlDPTOSRB3PlhN2IGiCu9ouhb4M19l JADSRej/oQaEvtCyj111IowPZC1hNQFnTZ0Kx0D4k02KzOEZJ1HhHlCEK/P88O6CyXVV TD7XBARqfwQabbA6Nm2gpJZIaAPpUzj5rYxr4xkeaesKCLm5rR9OuM4mTHPkUmIopplu 9TK929k3ZQBiA2vKQ3YZ7EMoAFaP3SvZuAZM7gymIHcBido91t8vokXsDfzL1W3QmqdQ fyRK7Iyvzkz/99aXcPn1gtvBwloj3eSU2E5Dt552bsXM8i6cijBYbtlWtM6oRWlw/Us0 rzaA==
X-Gm-Message-State: ALoCoQn9HchuZrBw7jeERONf/VLf3tcM2HrwL2TSwjMcRBP9QMQ43QrOOCafrR1fqyLws0PzFsxX
MIME-Version: 1.0
X-Received: by 10.52.75.101 with SMTP id b5mr837610vdw.40.1394469410889; Mon, 10 Mar 2014 09:36:50 -0700 (PDT)
Received: by 10.220.230.9 with HTTP; Mon, 10 Mar 2014 09:36:50 -0700 (PDT)
In-Reply-To: <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org>
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org>
Date: Mon, 10 Mar 2014 09:36:50 -0700
Message-ID: 
From: Ulrich Herberg 
To: Thomas Clausen 
Content-Type: multipart/alternative; boundary=20cf3071cfd2e2fb1804f4433573
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7zGi56cOenricmLvN2iO1HdUJ2M
Cc: "" , MANET IETF 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 16:36:59 -0000

--20cf3071cfd2e2fb1804f4433573
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you, Thomas (and others), for the corrections. Of course, you would
do me an immense favo(u)r if you sent me the exact BEFORE/AFTER text,
rather than me having to listen to the audio again :-D Just because I am
lazy ;-)

Ulrich


On Mon, Mar 10, 2014 at 6:50 AM, Thomas Clausen w=
rote:

> Ulrich,
>
> Thank you for prompt posting of minutes.
>
> A couple of things that I would like to make more precise, all the same,
> in the minutes:
>
> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>
> 
>
> Teco: Why not make this document standards track?
> CD: If people implement this and it's great.  Then I'm find  fine changin=
g this to standards track if that's the case.
> TC: I do not think as a working group that we should go down the standard=
s track document without many implementations as that has happened in other=
 places within the IETF and document quality has suffered.
>
> I honestly do not think that Chris would make that typo, even when
> speaking ;)
>
> CD: If it gets stuck in the queue for 4 years we may have enough experien=
ce that we may want to push for standards track.
> Rick Taylor: Is there any record of this for this draft being experimenta=
l and then changing to standards track later down the line?
> CD: We will post something up on the list.
> TC: I think that experimental should have an explanation on what the expe=
riment is and what the successful experiment is and what the conclusion is.
> Ulrich: Do you have intention to add a description of what those experime=
nts are and what will make them successful?
> Adrian Farrel: Yes, he does have that intention.
>
> As it reads in the above, it sounds as if I'm making a demand, that Adria=
n is committing Chris to satisfy. That's not exactly how it went down, so p=
erhaps we should clarify that in the minutes?
>
> I'd like to go on record here, that I did not say that it "should have an
> explanation" to cater to my whim, but that I (as I actually stated at the
> mike) I was reciting what I had heard was an IESG statement/requirement
> (so: I thought it was the IESGs whim to be satisfied).
>
> Adrian then clarified this, that it was not an "IESG
> statement/requirement" as such, but that the current routing ADs (which
> include him, so his whim) who require this"
>
> 
>
>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>
> 
>
> Henning: It will also not break anything if different values are used as =
the values are unit-less so the routes might be crazy but they will work.
>
> TC: I think experimental is exactly the place for this document
> Emmanuel: I would like to comment to Rick's earlier comment about if this=
 is related to OLSRv2.  It uses building blocks such as sequence numbers in=
 RFC5444 and missed NHDP HELLO messages to calculate the metric, so in that=
 regard it could be used with other protocols and is not only tied to OLSRv=
2.
> CD: There needs to be a section describing the experiments. TC: I think t=
his draft should be focused to OLSRv2 (and not other protocols) and not mak=
e it something overly broad and have it stall out.Henning: For AODV this me=
tric would be a problem as there isn't normally control traffic or any unic=
ast traffic on a link, so there is nothing to measure.
>
>
> I believe that what I said was that my experience with both proactive and
> reactive protocol deployments leave me to believe that metrics "make sens=
e
> in very different ways in these two protocol families", and therefore wou=
ld
> need to be considered separately. Specifically, constructing an "experime=
nt
> for a metric for a proactive protocol" (which, as this is going
> Experimental, is a requirement by the RTG ADs) is easy - whereas
> constructing an "experiment for the same metric for both a proactive and =
a
> reactive protocol" is a lot harder to do correctly, and probably will jus=
t
> make us stall.
>
> Therefore, given that the existing operational experience, on which this
> document is based, is exclusively for proactive / OLSR, only, my preferen=
ce
> is simply to document the metric as for OLSR, and design the experiment
> accordingly.
>
>
> 
>
>  o draft-gerla-manet-odmrp: Colin de Verdiere
>    draft-gerla-manet-odmrp-asym
>
> Brain-fart here, but I actually do not recall if the authors requested WG
> adoption "now", "a bit later", or "not at all but just wanted to inform t=
he
> WG what we're doing"? - Or was it "none of the above"?
>
> 
>
> o draft-clausen-manet-olsrv2-management-snapshot: Herberg
> UH: Presenting. Requesting WG adoption
>
>
> Have I missed something, or was WG adoption for this document already cal=
led for on the list? If not, any reasons for "not"?
>
> 
>
>  o OLSRv2 + RFC6971: Clausen
> No time for presentation (slides in the proceedings), brought to the mail=
ing list.
>
>
> It'd be kind if the minutes contains a link to the message which Ulrich
> started and wherein the discussion was brought forward:
>
> In the new "archive format" (which I am given to understand is being
> reworked to show the threads) that'd be:
> http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek
>
> or, the format that actually allows seeing the threads, and which is
> useful currently:
> http://www.ietf.org/mail-archive/web/manet/current/msg16016.html
>
> Cheers,
>
> Thomas
>
> On 08 Mar 2014, at 04:04, Ulrich Herberg  wrote:
>
> Hello,
>
> I uploaded the preliminary minutes to:
> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet
>
> Please verify correctness and send edits to me by email.
> Many thanks to Justin and Axel for taking the minutes. I have edited and
> merged them.
>
> Best regards
> Ulrich
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>
>

--20cf3071cfd2e2fb1804f4433573
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Thank you, Thomas (and others), for the corrections. =
Of course, you would do me an immense favo(u)r if you sent me the exact BEF=
ORE/AFTER text, rather than me having to listen to the audio again :-D Just=
 because I am lazy ;-)


Ulrich


On Mon, Mar 10, 2014 at 6:50 AM, Thomas Clausen <thoma=
s@thomasclausen.org> wrote:


Ulrich,<=
div>
Thank you for prompt posting of minutes.
=A0

A couple of things that I would like to make more precise, all the sam=
e, in the minutes:

o draft-ietf-manet-olsr=
v2-multitopology: Dearlove

<SNIP>
Teco: Why not make this do=
cument standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's the case.
TC: I do not think as a working group that we should go down the standards =
track document without many implementations as that has happened in other p=
laces within the IETF and document quality has suffered.


I honestly do not think that Chris would make that typo, even when spe=
aking ;)
CD: If it gets stuck in the queue for 4 years we may have enough experience=
 that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being experimental =
and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the experi=
ment is and what the successful experiment is and what the conclusion is.
Ulrich: Do you have intention to add a description of what those experiment=
s are and what will make them successful?
Adrian Farrel: Yes, he does have that intention.
As it reads in the above, it sounds as=
 if I'm making a demand, that Adrian is committing Chris to satisfy. Th=
at's not exactly how it went down, so perhaps we should clarify that in=
 the minutes?


I'd like to go on record here, that I did not say that it "sh=
ould have an explanation" to cater to my whim, but that I (as I actual=
ly stated at the mike) I was reciting what I had heard was an IESG statemen=
t/requirement (so: I thought it was the IESGs whim to be satisfied).



Adrian then clarified this, that it was not an "IE=
SG statement/requirement" as such, but that the current routing ADs (w=
hich include him, so his whim) who require this"



<SNIP>

 o draft-rogge-baccelli-=
olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will also not break anything if different values are used as th=
e values are unit-less so the routes might be crazy but they will work.
TC: I=
 think experimental is exactly the place for this document
Emmanuel: I would like to comment to Rick's earlier comment about if th=
is is related to OLSRv2.  It uses building blocks such as sequence numbers =
in RFC5444 and missed NHDP HELLO messages to calculate the metric, so in th=
at regard it could be used with other protocols and is not only tied to OLS=
Rv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to OLSRv2 =
(and not other protocols) and not make it something overly broad and have i=
t stall out.
Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is noth=
ing to measure.


I believe that what I said was that my experience with both proactive and r=
eactive protocol deployments leave me to believe that metrics "make se=
nse in very different ways in these two protocol families", and theref=
ore would need to be considered separately. Specifically, constructing an &=
quot;experiment for a metric for a proactive protocol" (which, as this=
 is going Experimental, is a requirement by the RTG ADs) is easy - whereas =
constructing an "experiment for the same metric for both a proactive a=
nd a reactive protocol" is a lot harder to do correctly, and probably =
will just make us stall.



Therefore, given that the existing operational experien=
ce, on which this document is based, is exclusively for proactive / OLSR, o=
nly, my preference is simply to document the metric as for OLSR, and design=
 the experiment accordingly.



<SNIP>

 o draft-gerla=
-manet-odmrp: Colin de Verdiere
   draft-gerla-manet-odmrp-asym
Brain-fart here, but=
 I actually do not recall if the authors requested WG adoption "now&qu=
ot;, "a bit later", or "not at all but just wanted to inform=
 the WG what we're doing"? - Or was it "none of the above&quo=
t;?



<SNIP>

o =
draft-clausen-manet-olsrv2-management-snapshot: Herberg
UH: Presenting. Requesting WG adoption


Have I missed s=
omething, or was WG adoption for this document already called for on the li=
st? If not, any reasons for "not"?



<SNIP>

<=
/div>
 o OLSRv2 + RFC6971: Clausen
No time for presentation (slides in the proceedings), brought to the mailin=
g list.

It'd be kind if the=
 minutes contains a link to the message which Ulrich started and wherein th=
e discussion was brought forward:



	In the new=
 "archive format" (which I am given to understand is being rework=
ed to show the threads) that'd be:



	or, the fo=
rmat that actually allows seeing the threads, and which is useful currently=
:
		http://www.ietf.org/mail-archive/web/manet/current/msg16016.html


Cheers,

Thomas

<=
/div>
On 08 Mar 2014, at 04:04, Ulrich Herb=
erg <ulrich@her=
berg.name> wrote:


Hello,

I uploaded the preliminary minutes t=
o:
http://www.ietf.org/proceedings/89/minutes/minutes-89-=
manet



Please verify correctness and send edits to me by email.
Many =
thanks to Justin and Axel for taking the minutes. I have edited and merged =
them.

Best regards
Ulrich

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






--20cf3071cfd2e2fb1804f4433573--


From nobody Mon Mar 10 09:43:37 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A78A1A056D for ; Mon, 10 Mar 2014 09:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFaY9UcGwDNL for ; Mon, 10 Mar 2014 09:43:31 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id DFE761A0549 for ; Mon, 10 Mar 2014 09:43:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C47CF621D84; Mon, 10 Mar 2014 09:43:25 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id E7A08621D69; Mon, 10 Mar 2014 09:43:22 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FC6D531E-49B5-4D63-9254-3FA2A23ADB4A"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Clausen 
In-Reply-To: 
Date: Mon, 10 Mar 2014 17:43:19 +0100
Message-Id: <03459F08-E275-471C-A212-E83A6E6A56FB@thomasclausen.org>
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org> 
To: Ulrich Herberg 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0DihTn1ZTQPLN88ynr9p6DhOBdk
Cc: "" , MANET IETF 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 16:43:34 -0000

--Apple-Mail=_FC6D531E-49B5-4D63-9254-3FA2A23ADB4A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Ulrich,

On 10 Mar 2014, at 17:36, Ulrich Herberg  wrote:

> Thank you, Thomas (and others), for the corrections. Of course, you =
would do me an immense favo(u)r if you sent me the exact BEFORE/AFTER =
text, rather than me having to listen to the audio again :-D Just =
because I am lazy ;-)
>=20

Wait, so what are you getting paid the big bucks as IETF WG Secretary =
for, again? ;)

Thomas

> Ulrich
>=20
>=20
> On Mon, Mar 10, 2014 at 6:50 AM, Thomas Clausen =
 wrote:
> Ulrich,
>=20
> Thank you for prompt posting of minutes.
> =20
> A couple of things that I would like to make more precise, all the =
same, in the minutes:
>=20
>> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>=20
> 
>> Teco: Why not make this document standards track?
>> CD: If people implement this and it's great.  Then I'm find  fine =
changing this to standards track if that's the case.
>> TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.
> I honestly do not think that Chris would make that typo, even when =
speaking ;)
>> CD: If it gets stuck in the queue for 4 years we may have enough =
experience that we may want to push for standards track.
>> Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
>> CD: We will post something up on the list.
>> TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
>> Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
>> Adrian Farrel: Yes, he does have that intention.
> As it reads in the above, it sounds as if I'm making a demand, that =
Adrian is committing Chris to satisfy. That's not exactly how it went =
down, so perhaps we should clarify that in the minutes?
>=20
> I'd like to go on record here, that I did not say that it "should have =
an explanation" to cater to my whim, but that I (as I actually stated at =
the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).
>=20
>=20
> Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"
>=20
>=20
> 
>=20
>>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>=20
> 
>> Henning: It will also not break anything if different values are used =
as the values are unit-less so the routes might be crazy but they will =
work.
>> TC: I think experimental is exactly the place for this document
>> Emmanuel: I would like to comment to Rick's earlier comment about if =
this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
>> CD: There needs to be a section describing the experiments.=20
>> TC: I think this draft should be focused to OLSRv2 (and not other =
protocols) and not make it something overly broad and have it stall out.
>> Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.
>=20
>=20
> I believe that what I said was that my experience with both proactive =
and reactive protocol deployments leave me to believe that metrics "make =
sense in very different ways in these two protocol families", and =
therefore would need to be considered separately. Specifically, =
constructing an "experiment for a metric for a proactive protocol" =
(which, as this is going Experimental, is a requirement by the RTG ADs) =
is easy - whereas constructing an "experiment for the same metric for =
both a proactive and a reactive protocol" is a lot harder to do =
correctly, and probably will just make us stall.
>=20
>=20
> Therefore, given that the existing operational experience, on which =
this document is based, is exclusively for proactive / OLSR, only, my =
preference is simply to document the metric as for OLSR, and design the =
experiment accordingly.
>=20
>=20
> 
>=20
>>  o draft-gerla-manet-odmrp: Colin de Verdiere
>>    draft-gerla-manet-odmrp-asym
> Brain-fart here, but I actually do not recall if the authors requested =
WG adoption "now", "a bit later", or "not at all but just wanted to =
inform the WG what we're doing"? - Or was it "none of the above"?
>=20
> 
>=20
>> o draft-clausen-manet-olsrv2-management-snapshot: Herberg
>> UH: Presenting. Requesting WG adoption
>=20
> Have I missed something, or was WG adoption for this document already =
called for on the list? If not, any reasons for "not"?
>=20
>=20
> 
>=20
>>  o OLSRv2 + RFC6971: Clausen
>> No time for presentation (slides in the proceedings), brought to the =
mailing list.
>=20
> It'd be kind if the minutes contains a link to the message which =
Ulrich started and wherein the discussion was brought forward:
>=20
> 	In the new "archive format" (which I am given to understand is =
being reworked to show the threads) that'd be:
> 		=
http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek
>=20
> 	or, the format that actually allows seeing the threads, and =
which is useful currently:
> 		=
http://www.ietf.org/mail-archive/web/manet/current/msg16016.html
>=20
> Cheers,
>=20
> Thomas
>=20
> On 08 Mar 2014, at 04:04, Ulrich Herberg  wrote:
>=20
>> Hello,
>>=20
>> I uploaded the preliminary minutes to:
>> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet
>>=20
>> Please verify correctness and send edits to me by email.
>> Many thanks to Justin and Axel for taking the minutes. I have edited =
and merged them.
>>=20
>> Best regards
>> Ulrich
>> _______________________________________________
>> 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=_FC6D531E-49B5-4D63-9254-3FA2A23ADB4A
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

Ulrich,

On 10 Mar 2014, at 17:36, Ulrich Herberg <ulrich@herberg.name> wrote:

Thank you, Thomas (and others), for the corrections. Of course, you would do me an immense favo(u)r if you sent me the exact BEFORE/AFTER text, rather than me having to listen to the audio again :-D Just because I am lazy ;-)



Wait, so what are you getting paid the big bucks as IETF WG Secretary for, again? ;)

Thomas

Ulrich


On Mon, Mar 10, 2014 at 6:50 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:


Ulrich,

Thank you for prompt posting of minutes.
 


A couple of things that I would like to make more precise, all the same, in the minutes:

o draft-ietf-manet-olsrv2-multitopology: Dearlove

<SNIP>
Teco: Why not make this document standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's the case.
TC: I do not think as a working group that we should go down the standards track document without many implementations as that has happened in other places within the IETF and document quality has suffered.


I honestly do not think that Chris would make that typo, even when speaking ;)
CD: If it gets stuck in the queue for 4 years we may have enough experience that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being experimental and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the experiment is and what the successful experiment is and what the conclusion is.
Ulrich: Do you have intention to add a description of what those experiments are and what will make them successful?
Adrian Farrel: Yes, he does have that intention.
As it reads in the above, it sounds as if I'm making a demand, that Adrian is committing Chris to satisfy. That's not exactly how it went down, so perhaps we should clarify that in the minutes?


I'd like to go on record here, that I did not say that it "should have an explanation" to cater to my whim, but that I (as I actually stated at the mike) I was reciting what I had heard was an IESG statement/requirement (so: I thought it was the IESGs whim to be satisfied).



Adrian then clarified this, that it was not an "IESG statement/requirement" as such, but that the current routing ADs (which include him, so his whim) who require this"



<SNIP>

 o draft-rogge-baccelli-olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will also not break anything if different values are used as the values are unit-less so the routes might be crazy but they will work.
TC: I think experimental is exactly the place for this document
Emmanuel: I would like to comment to Rick's earlier comment about if this is related to OLSRv2.  It uses building blocks such as sequence numbers in RFC5444 and missed NHDP HELLO messages to calculate the metric, so in that regard it could be used with other protocols and is not only tied to OLSRv2.
CD: There needs to be a section describing the experiments. 
TC: I think this draft should be focused to OLSRv2 (and not other protocols) and not make it something overly broad and have it stall out.
Henning: For AODV this metric would be a problem as there isn't normally control traffic or any unicast traffic on a link, so there is nothing to measure.


I believe that what I said was that my experience with both proactive and reactive protocol deployments leave me to believe that metrics "make sense in very different ways in these two protocol families", and therefore would need to be considered separately. Specifically, constructing an "experiment for a metric for a proactive protocol" (which, as this is going Experimental, is a requirement by the RTG ADs) is easy - whereas constructing an "experiment for the same metric for both a proactive and a reactive protocol" is a lot harder to do correctly, and probably will just make us stall.



Therefore, given that the existing operational experience, on which this document is based, is exclusively for proactive / OLSR, only, my preference is simply to document the metric as for OLSR, and design the experiment accordingly.



<SNIP>

 o draft-gerla-manet-odmrp: Colin de Verdiere
   draft-gerla-manet-odmrp-asym
Brain-fart here, but I actually do not recall if the authors requested WG adoption "now", "a bit later", or "not at all but just wanted to inform the WG what we're doing"? - Or was it "none of the above"?



<SNIP>

o draft-clausen-manet-olsrv2-management-snapshot: Herberg
UH: Presenting. Requesting WG adoption


Have I missed something, or was WG adoption for this document already called for on the list? If not, any reasons for "not"?



<SNIP>

 o OLSRv2 + RFC6971: Clausen
No time for presentation (slides in the proceedings), brought to the mailing list.

It'd be kind if the minutes contains a link to the message which Ulrich started and wherein the discussion was brought forward:



	In the new "archive format" (which I am given to understand is being reworked to show the threads) that'd be:



	or, the format that actually allows seeing the threads, and which is useful currently:



Cheers,

Thomas

On 08 Mar 2014, at 04:04, Ulrich Herberg <ulrich@herberg.name> wrote:


Hello,

I uploaded the preliminary minutes to:
http://www.ietf.org/proceedings/89/minutes/minutes-89-manet



Please verify correctness and send edits to me by email.
Many thanks to Justin and Axel for taking the minutes. I have edited and merged them.

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


--Apple-Mail=_FC6D531E-49B5-4D63-9254-3FA2A23ADB4A--


From nobody Mon Mar 10 09:48:49 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A751A065B for ; Mon, 10 Mar 2014 09:48:47 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQJS7AzMRzZJ for ; Mon, 10 Mar 2014 09:48:45 -0700 (PDT)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 49B2B1A05C3 for ; Mon, 10 Mar 2014 09:48:45 -0700 (PDT)
Received: by mail-yh0-f42.google.com with SMTP id t59so741195yho.1 for ; Mon, 10 Mar 2014 09:48: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:cc:content-type;  bh=cGVNJe35h5GXD7tFPGBwdysfZIOWIudeR8lL2EtM9RU=; b=QNQvhXFNSr4xLzsAwO0WyyrHuBY6QScDpbq9TB/cbdrLWHOQf3+7LWFmFtSysde4qk eitLFsH98ONwgx+69Q/9cP8oeb7mnqABBG/h1jr5Ghpz7lQKQ1J12ikCknhVTqxdL8hj 8p1SjC2BIJorDvpAl7LIovt913RdVP/sSgjqqc+Gn2ANFA/vwZtqmwAGjMUb3jgHeNH7 MXF5fFrbyCod+gGT8zf00xsf6r0Mx8kPylbpbZiEHG4cCzLWhzBWeMteti36seUEVd+o uODreDoK3WuWHbxTca0PMUI/Gt+6O2OxuhxRgaUc3Y9IA28/+P2UdrTkMwuiRrZDGH53 wFcg==
MIME-Version: 1.0
X-Received: by 10.236.123.193 with SMTP id v41mr46181452yhh.68.1394470119700;  Mon, 10 Mar 2014 09:48:39 -0700 (PDT)
Received: by 10.170.202.7 with HTTP; Mon, 10 Mar 2014 09:48:39 -0700 (PDT)
Date: Mon, 10 Mar 2014 17:48:39 +0100
Message-ID: 
From: Abdussalam Baryun 
To: =?ISO-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
Content-Type: multipart/alternative; boundary=20cf301afb7b227ce604f4436023
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SVsDPgdQp-uyOkWmGI7n5-6U9Zo
Cc: manet , gerla 
Subject: [manet] ODMRP new draft (was Re:  IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 16:48:47 -0000

--20cf301afb7b227ce604f4436023
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Axel,

Thanks for your presentation. I had a question at meeting but there was no
time. From the presentation (still I did not done review), there was one
slide showing two paths to its destination, so does this multicast protocol
use multipath to reach all its demanded destinations? And how does it
optimise overhead?

AB

On Monday, March 10, 2014, Axel Colin de Verdi=E8re wrote:

> Hi all,
>
> We did not in fact request WG adoption for ODMRP and ODMRP_ASYM at this
> time, but we felt that the drafts were in good enough shape to ask for yo=
ur
> comments and move in that direction.
>
> Axel
>
> Le 10 mars 2014 =E0 17:08, Abdussalam Baryun =
 a
> =E9crit :
>
> Hi Thomas,
>
> Thanks for the update. I don't think the latest multicast draft was
> requested to be adopted in the meeting, but Ulrich did request his it for
> his draft, and I am waiting for announce on the list for DLEP plan and
> all adoption request in WG meeting.
>
> AB
>
> On Monday, March 10, 2014, Thomas Clausen wrote:
>
> Ulrich,
>
> Thank you for prompt posting of minutes.
>
> A couple of things that I would like to make more precise, all the same,
> in the minutes:
>
> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>
> 
>
> Teco: Why not make this document standards track?
> CD: If people implement this and it's great.  Then I'm find  fine changin=
g this to standards track if that's the case.
> TC: I do not think as a working group that we should go down the standard=
s track document without many implementations as that has happened in other=
 places within the IETF and document quality has suffered.
>
> I honestly do not think that Chris would make that typo, even when
> speaking ;)
>
> CD: If it gets stuck in the queue for 4 years we may have enough experien=
ce that we may want to push for standards track.
> Rick Taylor: Is there any record of this for this draft being experimenta=
l and then changing to standards track later down the line?
> CD: We will post something up on the list.
> TC: I think that experimental should have an explanation on what the expe=
riment is and what the successful experiment is and what the conclusion is.
> Ulrich: Do you have intention to add a description of what those experime=
nts are and what will make them successful?
> Adrian Farrel: Yes, he does have that intention.
>
> As it reads in the above, it sounds as if I'm making a demand, that Adria=
n is committing Chris to satisfy. That's not exactly how it went down, so p=
erhaps we should clarify that in the minutes?
>
> I'd like to go on record here, that I did not say that it "should have an
> explanation" to cater to my whim, but that I (as I actually stated at the
> mike) I was reciting what I had heard was an IESG statement/requirement
> (so: I thought it was the IESGs whim to be satisfied).
>
> Adrian then clarified this, that it was not an "IESG
> statement/requirement" as such, but that the current routing ADs (which
> include him, so his whim) who require this"
>
> 
>
>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>
> 
>
> Henning: It will also not break anything if different values are used as =
the values are unit-less so the routes might be crazy but they will work.
>
> TC: I think experimental is exactly the place for this document
> Emmanuel: I would like to comment to Rick's earlier comment about if this=
 is related to OLSRv2.  It uses building blocks such as sequence numbers in=
 RFC5444 and missed NHDP HELLO messages to calculate the metric, so in that=
 regard it could be used with other protocols and is not only tied to OLSRv=
2.
> CD: There needs to be a section describing the experiments. TC: I think t=
his draft should be focused to OLSRv2 (and not other protocols) and not mak=
e it something overly broad and have it stall out.Henning: For AODV this me=
tric would be a problem as there isn't normally control traffic or any unic=
ast traffic on a link, so there is nothing to measure.
>
>
> I believe that what I said was that my experience with both proactive and
> reactive protocol deployments leave me to believe that metrics "make sens=
e
> in very different ways in these two protocol families", and therefore wou=
ld
> need to be considered separately. Specifically, constructing an "experime=
nt
> for a metric for a proactive protocol" (which, as this is going
> Experimental, is a requiremen
>
>
>

--20cf301afb7b227ce604f4436023
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Axel,

Thanks for your presentation. I=A0had a questio=
n at meeting=A0but there was no time. From the presentation (still I did=A0=
not done review), there was one slide showing=A0two paths to its=A0destinat=
ion, so does this multicast protocol use multipath to reach all its demande=
d=A0destinations? And how does it optimise overhead?




AB

On Monday, March 10, 2014, Axel Colin de Verd=
i=E8re  wrote:


Hi all,

We did not in fact request WG adoption for ODMRP=
 and ODMRP_ASYM at this time, but we felt that the drafts were in good enou=
gh shape to ask for your comments and move in that direction.



Axel

Le 10 mars 2014 =E0 17:08, Abdu=
ssalam Baryun <abdussalambaryun@gmail.com> a =E9crit :


Hi=A0Thomas,

Thanks for th=
e update. I don't think the latest=A0multicast draft was requested to b=
e=A0adopted in the meeting, but Ulrich did request his it for his draft,=A0=
and I am waiting for announce=A0on=A0the list for DLEP plan=A0and all=A0ado=
ption request in WG=A0meeting.=A0





AB

On Monday, March 10, 2014, Thomas Clausen  wr=
ote:
Ulrich,


Thank you for prompt posting of minutes.
=A0
=

A couple of things that I would like to make more precise, all the sam=
e, in the minutes:

o draft-ietf-manet-olsrv2-multitopology: Dearlove

<SNIP>
Teco: Why not make this do=
cument standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's the case=
.
TC: I do not think as a working group that we should go down the standards =
track document without many implementations as that has happened in other p=
laces within the IETF and document quality has suffered.




I honestly do not think that Chris would make that typo, even when spe=
aking ;)
CD: If it gets stuck in the queue for 4 years we may have enough experience=
 that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being experimental =
and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the experi=
ment is and what the successful experiment is and what the conclusion is.
Ulrich: Do you have intention to add a description of what those experiment=
s are and what will make them successful?
Adrian Farrel: Yes, he does have that intention.
As it reads in the above, it sounds as=
 if I'm making a demand, that Adrian is committing Chris to satisfy. Th=
at's not exactly how it went down, so perhaps we should clarify that in=
 the minutes?




I'd like to go on record here, that I did not say that it "sh=
ould have an explanation" to cater to my whim, but that I (as I actual=
ly stated at the mike) I was reciting what I had heard was an IESG statemen=
t/requirement (so: I thought it was the IESGs whim to be satisfied).





Adrian then clarified this, that it was not an "IE=
SG statement/requirement" as such, but that the current routing ADs (w=
hich include him, so his whim) who require this"





<SNIP>

 o draft-rogge-baccelli-=
olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will also not break anything if different values are used as th=
e values are unit-less so the routes might be crazy but they will work.
TC: I=
 think experimental is exactly the place for this document
Emmanuel: I would like to comment to Rick's earlier comment about if th=
is is related to OLSRv2.  It uses building blocks such as sequence numbers =
in RFC5444 and missed NHDP HELLO messages to calculate the metric, so in th=
at regard it could be used with other protocols and is not only tied to OLS=
Rv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to OLSRv2 =
(and not other protocols) and not make it something overly broad and have i=
t stall out.
Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is noth=
ing to measure.


I believe that what I said was that my experience with both proactive and r=
eactive protocol deployments leave me to believe that metrics "make se=
nse in very different ways in these two protocol families", and theref=
ore would need to be considered separately. Specifically, constructing an &=
quot;experiment for a metric for a proactive protocol" (which, as this=
 is going Experimental, is a requiremen






--20cf301afb7b227ce604f4436023--


From nobody Mon Mar 10 09:49:24 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972981A066A for ; Mon, 10 Mar 2014 09:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9spAA9AI3wx for ; Mon, 10 Mar 2014 09:49:16 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2427B1A0669 for ; Mon, 10 Mar 2014 09:49:16 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id il7so2379677vcb.32 for ; Mon, 10 Mar 2014 09:49:10 -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=DwbPDF+oeuZeMgKDyS9qelEnzDoeGeECHzRhCMsI8C0=; b=F+MXCBtyovfEmWgTRlyQAUoznQvl0+1ix7X4MsTMm2nxhqaNNJ6KjB+NDwo/X/3c/3 Pp07KagQo7Kg36xBctj5XJqhK9Pmb7fLjapI8py91XCEb3cN4QJHSuqGD9+DlgIJYGHS WN0eiLJoJ4y3KC5/7TJW/AvIDP4xBoCoXvhLQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DwbPDF+oeuZeMgKDyS9qelEnzDoeGeECHzRhCMsI8C0=; b=OPfU0N0eGolE5stQ6hzhqp86cIYTZaqAo3YTL9PXspcp6tkO3i90twjtWG8OdluVcH AHJSM0wfNU2NBTi2qBHNX5wY2dZuM5bXZCJ2FrVOtCIkTAwQToP9GumcmRXLdk02heC6 vp+EFouRuh7Qx3WDA8Paz9w2XMIpSsqXMmeoh6hVO4Nukjq9fvuGxRIJAMkPNxbzbtdb oX0+658wd90vDVcJFxQsWTdKmTBhDcZ0YLdrjgWvZPD5peApcWLIrNm9yZMVHGE5Uok7 X0uFNc24aZPc8gsb9hLqZYcy18QDp9JegdzU+KvL1ql3JnCE1QFvfz96kz80uFA2oax+ KoNg==
X-Gm-Message-State: ALoCoQki0ot7vCOTSEAfRuOiHNlKf5Pk+if2iWwzZ5wt9gSNejLlZ5OrYKV8pBmywdzeELyoKse7
MIME-Version: 1.0
X-Received: by 10.220.188.10 with SMTP id cy10mr185485vcb.36.1394470150526; Mon, 10 Mar 2014 09:49:10 -0700 (PDT)
Received: by 10.220.230.9 with HTTP; Mon, 10 Mar 2014 09:49:10 -0700 (PDT)
In-Reply-To: <03459F08-E275-471C-A212-E83A6E6A56FB@thomasclausen.org>
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org>  <03459F08-E275-471C-A212-E83A6E6A56FB@thomasclausen.org>
Date: Mon, 10 Mar 2014 09:49:10 -0700
Message-ID: 
From: Ulrich Herberg 
To: Thomas Clausen 
Content-Type: multipart/alternative; boundary=047d7bfea07cf8f31a04f4436168
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7KYFAdONmNCBdN9sDRn6MTHpiQk
Cc: "" , MANET IETF 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 16:49:18 -0000

--047d7bfea07cf8f31a04f4436168
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thomas,

I have uploaded a revised revision of the minutes. Please confirm if that
reflects what has been said, or otherwise send me the precise wording :-)

Regards
Ulrich


On Mon, Mar 10, 2014 at 9:43 AM, Thomas Clausen w=
rote:

> Ulrich,
>
> On 10 Mar 2014, at 17:36, Ulrich Herberg  wrote:
>
> Thank you, Thomas (and others), for the corrections. Of course, you would
> do me an immense favo(u)r if you sent me the exact BEFORE/AFTER text,
> rather than me having to listen to the audio again :-D Just because I am
> lazy ;-)
>
>
> Wait, so what are you getting paid the big bucks as IETF WG Secretary for=
,
> again? ;)
>
> Thomas
>
> Ulrich
>
>
> On Mon, Mar 10, 2014 at 6:50 AM, Thomas Clausen wrote:
>
>> Ulrich,
>>
>> Thank you for prompt posting of minutes.
>>
>> A couple of things that I would like to make more precise, all the same,
>> in the minutes:
>>
>> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>>
>> 
>>
>> Teco: Why not make this document standards track?
>> CD: If people implement this and it's great.  Then I'm find  fine changi=
ng this to standards track if that's the case.
>> TC: I do not think as a working group that we should go down the standar=
ds track document without many implementations as that has happened in othe=
r places within the IETF and document quality has suffered.
>>
>> I honestly do not think that Chris would make that typo, even when
>> speaking ;)
>>
>> CD: If it gets stuck in the queue for 4 years we may have enough experie=
nce that we may want to push for standards track.
>> Rick Taylor: Is there any record of this for this draft being experiment=
al and then changing to standards track later down the line?
>> CD: We will post something up on the list.
>> TC: I think that experimental should have an explanation on what the exp=
eriment is and what the successful experiment is and what the conclusion is=
.
>> Ulrich: Do you have intention to add a description of what those experim=
ents are and what will make them successful?
>> Adrian Farrel: Yes, he does have that intention.
>>
>> As it reads in the above, it sounds as if I'm making a demand, that Adri=
an is committing Chris to satisfy. That's not exactly how it went down, so =
perhaps we should clarify that in the minutes?
>>
>> I'd like to go on record here, that I did not say that it "should have a=
n
>> explanation" to cater to my whim, but that I (as I actually stated at th=
e
>> mike) I was reciting what I had heard was an IESG statement/requirement
>> (so: I thought it was the IESGs whim to be satisfied).
>>
>> Adrian then clarified this, that it was not an "IESG
>> statement/requirement" as such, but that the current routing ADs (which
>> include him, so his whim) who require this"
>>
>> 
>>
>>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>>
>> 
>>
>> Henning: It will also not break anything if different values are used as=
 the values are unit-less so the routes might be crazy but they will work.
>>
>> TC: I think experimental is exactly the place for this document
>> Emmanuel: I would like to comment to Rick's earlier comment about if thi=
s is related to OLSRv2.  It uses building blocks such as sequence numbers i=
n RFC5444 and missed NHDP HELLO messages to calculate the metric, so in tha=
t regard it could be used with other protocols and is not only tied to OLSR=
v2.
>> CD: There needs to be a section describing the experiments. TC: I think =
this draft should be focused to OLSRv2 (and not other protocols) and not ma=
ke it something overly broad and have it stall out.Henning: For AODV this m=
etric would be a problem as there isn't normally control traffic or any uni=
cast traffic on a link, so there is nothing to measure.
>>
>>
>> I believe that what I said was that my experience with both proactive an=
d
>> reactive protocol deployments leave me to believe that metrics "make sen=
se
>> in very different ways in these two protocol families", and therefore wo=
uld
>> need to be considered separately. Specifically, constructing an "experim=
ent
>> for a metric for a proactive protocol" (which, as this is going
>> Experimental, is a requirement by the RTG ADs) is easy - whereas
>> constructing an "experiment for the same metric for both a proactive and=
 a
>> reactive protocol" is a lot harder to do correctly, and probably will ju=
st
>> make us stall.
>>
>> Therefore, given that the existing operational experience, on which this
>> document is based, is exclusively for proactive / OLSR, only, my prefere=
nce
>> is simply to document the metric as for OLSR, and design the experiment
>> accordingly.
>>
>>
>> 
>>
>>  o draft-gerla-manet-odmrp: Colin de Verdiere
>>    draft-gerla-manet-odmrp-asym
>>
>> Brain-fart here, but I actually do not recall if the authors requested W=
G
>> adoption "now", "a bit later", or "not at all but just wanted to inform =
the
>> WG what we're doing"? - Or was it "none of the above"?
>>
>> 
>>
>> o draft-clausen-manet-olsrv2-management-snapshot: Herberg
>> UH: Presenting. Requesting WG adoption
>>
>>
>> Have I missed something, or was WG adoption for this document already ca=
lled for on the list? If not, any reasons for "not"?
>>
>> 
>>
>>  o OLSRv2 + RFC6971: Clausen
>> No time for presentation (slides in the proceedings), brought to the mai=
ling list.
>>
>>
>> It'd be kind if the minutes contains a link to the message which Ulrich
>> started and wherein the discussion was brought forward:
>>
>> In the new "archive format" (which I am given to understand is being
>> reworked to show the threads) that'd be:
>> http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek
>>
>> or, the format that actually allows seeing the threads, and which is
>> useful currently:
>> http://www.ietf.org/mail-archive/web/manet/current/msg16016.html
>>
>> Cheers,
>>
>> Thomas
>>
>> On 08 Mar 2014, at 04:04, Ulrich Herberg  wrote:
>>
>> Hello,
>>
>> I uploaded the preliminary minutes to:
>> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet
>>
>> Please verify correctness and send edits to me by email.
>> Many thanks to Justin and Axel for taking the minutes. I have edited and
>> merged them.
>>
>> 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
>
>
>

--047d7bfea07cf8f31a04f4436168
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Thomas,

I have uploaded a revised r=
evision of the minutes. Please confirm if that reflects what has been said,=
 or otherwise send me the precise wording :-)

Regards
Ulric=
h




On Mon,=
 Mar 10, 2014 at 9:43 AM, Thomas Clausen <thomas@thomasclausen.org<=
/a>> wrote:


Ulrich,<=
div>


Thank you, Thomas (and =
others), for the corrections. Of course, you would do me an immense favo(u)=
r if you sent me the exact BEFORE/AFTER text, rather than me having to list=
en to the audio again :-D Just because I am lazy ;-)




Wait, so what are you get=
ting paid the big bucks as IETF WG Secretary for, again? ;)

Thomas



Ulric=
h


On=
 Mon, Mar 10, 2014 at 6:50 AM, Thomas Clausen <thomas@thomasclausen=
.org> wrote:



Ulrich,<=
div>
Thank you for prompt posting of minutes.
=A0


A couple of things that I would like to make more precise, all the sam=
e, in the minutes:

o draft-ietf-manet-olsr=
v2-multitopology: Dearlove

<SNIP>
Teco: Why not make this do=
cument standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's the case.
TC: I do not think as a working group that we should go down the standards =
track document without many implementations as that has happened in other p=
laces within the IETF and document quality has suffered.



I honestly do not think that Chris would make that typo, even when spe=
aking ;)
CD: If it gets stuck in the queue for 4 years we may have enough experience=
 that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being experimental =
and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the experi=
ment is and what the successful experiment is and what the conclusion is.
Ulrich: Do you have intention to add a description of what those experiment=
s are and what will make them successful?
Adrian Farrel: Yes, he does have that intention.
As it reads in the above, it sounds as=
 if I'm making a demand, that Adrian is committing Chris to satisfy. Th=
at's not exactly how it went down, so perhaps we should clarify that in=
 the minutes?



I'd like to go on record here, that I did not say that it "sh=
ould have an explanation" to cater to my whim, but that I (as I actual=
ly stated at the mike) I was reciting what I had heard was an IESG statemen=
t/requirement (so: I thought it was the IESGs whim to be satisfied).




Adrian then clarified this, that it was not an "IE=
SG statement/requirement" as such, but that the current routing ADs (w=
hich include him, so his whim) who require this"




<SNIP>

 o draft-rogge-baccelli-=
olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will also not break anything if different values are used as th=
e values are unit-less so the routes might be crazy but they will work.
TC: I=
 think experimental is exactly the place for this document
Emmanuel: I would like to comment to Rick's earlier comment about if th=
is is related to OLSRv2.  It uses building blocks such as sequence numbers =
in RFC5444 and missed NHDP HELLO messages to calculate the metric, so in th=
at regard it could be used with other protocols and is not only tied to OLS=
Rv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to OLSRv2 =
(and not other protocols) and not make it something overly broad and have i=
t stall out.
Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is noth=
ing to measure.


I believe that what I said was that my experience with both proactive and r=
eactive protocol deployments leave me to believe that metrics "make se=
nse in very different ways in these two protocol families", and theref=
ore would need to be considered separately. Specifically, constructing an &=
quot;experiment for a metric for a proactive protocol" (which, as this=
 is going Experimental, is a requirement by the RTG ADs) is easy - whereas =
constructing an "experiment for the same metric for both a proactive a=
nd a reactive protocol" is a lot harder to do correctly, and probably =
will just make us stall.




Therefore, given that the existing operational experien=
ce, on which this document is based, is exclusively for proactive / OLSR, o=
nly, my preference is simply to document the metric as for OLSR, and design=
 the experiment accordingly.




<SNIP>

 o draft-gerla=
-manet-odmrp: Colin de Verdiere
   draft-gerla-manet-odmrp-asym
Brain-fart here, but=
 I actually do not recall if the authors requested WG adoption "now&qu=
ot;, "a bit later", or "not at all but just wanted to inform=
 the WG what we're doing"? - Or was it "none of the above&quo=
t;?




<SNIP>

o =
draft-clausen-manet-olsrv2-management-snapshot: Herberg
UH: Presenting. Requesting WG adoption


Have I missed s=
omething, or was WG adoption for this document already called for on the li=
st? If not, any reasons for "not"?




<SNIP>

<=
/div>
 o OLSRv2 + RFC6971: Clausen
No time for presentation (slides in the proceedings), brought to the mailin=
g list.

It'd be kind if the=
 minutes contains a link to the message which Ulrich started and wherein th=
e discussion was brought forward:




	In the new=
 "archive format" (which I am given to understand is being rework=
ed to show the threads) that'd be:




	or, the fo=
rmat that actually allows seeing the threads, and which is useful currently=
:
		http://www.ietf.org/mail-archive/web/manet/current/msg16016.html



Cheers,

Thomas

<=
/div>
On 08 Mar 2014, at 04:04, Ulrich Herberg <ulrich@herberg.name=
> wrote:



<=
div>Hello,

I uploaded the preliminary minutes to:
http://www.ietf.org/proceedings/89/minutes/minutes-89-manet




Please verify correctness and send edits to me by email.
Many =
thanks to Justin and Axel for taking the minutes. I have edited and merged =
them.

Best regards
Ulrich

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






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






--047d7bfea07cf8f31a04f4436168--


From nobody Mon Mar 10 09:52:16 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E078B1A0671 for ; Mon, 10 Mar 2014 09:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zr2ZWxKKfMS for ; Mon, 10 Mar 2014 09:52:10 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id BBE891A0552 for ; Mon, 10 Mar 2014 09:52:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B08B1621EE1; Mon, 10 Mar 2014 09:52:05 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 2EBC9621ECF; Mon, 10 Mar 2014 09:52:02 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2CA2E049-9BE9-4F3C-B19F-F64D04916371"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Clausen 
In-Reply-To: 
Date: Mon, 10 Mar 2014 17:52:00 +0100
Message-Id: 
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org>  <03459F08-E275-471C-A212-E83A6E6A56FB@thomasclausen.org> 
To: Ulrich Herberg 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/P2LR2-dh-d9yA-mhpQYrajHcQEo
Cc: "" , MANET IETF 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 16:52:14 -0000

--Apple-Mail=_2CA2E049-9BE9-4F3C-B19F-F64D04916371
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

I'll take a look - and, I sincerely hope that you did notice the smiley?

Thomas

On 10 Mar 2014, at 17:49, Ulrich Herberg  wrote:

> Thomas,
>=20
> I have uploaded a revised revision of the minutes. Please confirm if =
that reflects what has been said, or otherwise send me the precise =
wording :-)
>=20
> Regards
> Ulrich
>=20
>=20
> On Mon, Mar 10, 2014 at 9:43 AM, Thomas Clausen =
 wrote:
> Ulrich,
>=20
> On 10 Mar 2014, at 17:36, Ulrich Herberg  wrote:
>=20
>> Thank you, Thomas (and others), for the corrections. Of course, you =
would do me an immense favo(u)r if you sent me the exact BEFORE/AFTER =
text, rather than me having to listen to the audio again :-D Just =
because I am lazy ;-)
>>=20
>=20
> Wait, so what are you getting paid the big bucks as IETF WG Secretary =
for, again? ;)
>=20
> Thomas
>=20
>> Ulrich
>>=20
>>=20
>> On Mon, Mar 10, 2014 at 6:50 AM, Thomas Clausen =
 wrote:
>> Ulrich,
>>=20
>> Thank you for prompt posting of minutes.
>> =20
>> A couple of things that I would like to make more precise, all the =
same, in the minutes:
>>=20
>>> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>>=20
>> 
>>> Teco: Why not make this document standards track?
>>> CD: If people implement this and it's great.  Then I'm find  fine =
changing this to standards track if that's the case.
>>> TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.
>> I honestly do not think that Chris would make that typo, even when =
speaking ;)
>>> CD: If it gets stuck in the queue for 4 years we may have enough =
experience that we may want to push for standards track.
>>> Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
>>> CD: We will post something up on the list.
>>> TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
>>> Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
>>> Adrian Farrel: Yes, he does have that intention.
>> As it reads in the above, it sounds as if I'm making a demand, that =
Adrian is committing Chris to satisfy. That's not exactly how it went =
down, so perhaps we should clarify that in the minutes?
>>=20
>>=20
>> I'd like to go on record here, that I did not say that it "should =
have an explanation" to cater to my whim, but that I (as I actually =
stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).
>>=20
>>=20
>>=20
>> Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"
>>=20
>>=20
>>=20
>> 
>>=20
>>>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>>=20
>> 
>>> Henning: It will also not break anything if different values are =
used as the values are unit-less so the routes might be crazy but they =
will work.
>>> TC: I think experimental is exactly the place for this document
>>> Emmanuel: I would like to comment to Rick's earlier comment about if =
this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
>>> CD: There needs to be a section describing the experiments.=20
>>> TC: I think this draft should be focused to OLSRv2 (and not other =
protocols) and not make it something overly broad and have it stall out.
>>> Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.
>>=20
>>=20
>> I believe that what I said was that my experience with both proactive =
and reactive protocol deployments leave me to believe that metrics "make =
sense in very different ways in these two protocol families", and =
therefore would need to be considered separately. Specifically, =
constructing an "experiment for a metric for a proactive protocol" =
(which, as this is going Experimental, is a requirement by the RTG ADs) =
is easy - whereas constructing an "experiment for the same metric for =
both a proactive and a reactive protocol" is a lot harder to do =
correctly, and probably will just make us stall.
>>=20
>>=20
>>=20
>> Therefore, given that the existing operational experience, on which =
this document is based, is exclusively for proactive / OLSR, only, my =
preference is simply to document the metric as for OLSR, and design the =
experiment accordingly.
>>=20
>>=20
>>=20
>> 
>>=20
>>>  o draft-gerla-manet-odmrp: Colin de Verdiere
>>>    draft-gerla-manet-odmrp-asym
>> Brain-fart here, but I actually do not recall if the authors =
requested WG adoption "now", "a bit later", or "not at all but just =
wanted to inform the WG what we're doing"? - Or was it "none of the =
above"?
>>=20
>> 
>>=20
>>> o draft-clausen-manet-olsrv2-management-snapshot: Herberg
>>> UH: Presenting. Requesting WG adoption
>>=20
>> Have I missed something, or was WG adoption for this document already =
called for on the list? If not, any reasons for "not"?
>>=20
>>=20
>>=20
>> 
>>=20
>>>  o OLSRv2 + RFC6971: Clausen
>>> No time for presentation (slides in the proceedings), brought to the =
mailing list.
>>=20
>> It'd be kind if the minutes contains a link to the message which =
Ulrich started and wherein the discussion was brought forward:
>>=20
>> 	In the new "archive format" (which I am given to understand is =
being reworked to show the threads) that'd be:
>> 		=
http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek
>>=20
>> 	or, the format that actually allows seeing the threads, and =
which is useful currently:
>> 		=
http://www.ietf.org/mail-archive/web/manet/current/msg16016.html
>>=20
>> Cheers,
>>=20
>> Thomas
>>=20
>> On 08 Mar 2014, at 04:04, Ulrich Herberg  wrote:
>>=20
>>> Hello,
>>>=20
>>> I uploaded the preliminary minutes to:
>>> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet
>>>=20
>>> Please verify correctness and send edits to me by email.
>>> Many thanks to Justin and Axel for taking the minutes. I have edited =
and merged them.
>>>=20
>>> Best regards
>>> Ulrich
>>> _______________________________________________
>>> 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
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


--Apple-Mail=_2CA2E049-9BE9-4F3C-B19F-F64D04916371
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

I'll take a look - and, I sincerely hope that you did notice the smiley?

Thomas

On 10 Mar 2014, at 17:49, Ulrich Herberg <ulrich@herberg.name> wrote:

Thomas,

I have uploaded a revised revision of the minutes. Please confirm if that reflects what has been said, or otherwise send me the precise wording :-)

Regards
Ulrich




On Mon, Mar 10, 2014 at 9:43 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:


Ulrich,

On 10 Mar 2014, at 17:36, Ulrich Herberg <ulrich@herberg.name> wrote:


Thank you, Thomas (and others), for the corrections. Of course, you would do me an immense favo(u)r if you sent me the exact BEFORE/AFTER text, rather than me having to listen to the audio again :-D Just because I am lazy ;-)




Wait, so what are you getting paid the big bucks as IETF WG Secretary for, again? ;)

Thomas



Ulrich


On Mon, Mar 10, 2014 at 6:50 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:



Ulrich,

Thank you for prompt posting of minutes.
 



A couple of things that I would like to make more precise, all the same, in the minutes:

o draft-ietf-manet-olsrv2-multitopology: Dearlove

<SNIP>
Teco: Why not make this document standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's the case.
TC: I do not think as a working group that we should go down the standards track document without many implementations as that has happened in other places within the IETF and document quality has suffered.



I honestly do not think that Chris would make that typo, even when speaking ;)
CD: If it gets stuck in the queue for 4 years we may have enough experience that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being experimental and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the experiment is and what the successful experiment is and what the conclusion is.
Ulrich: Do you have intention to add a description of what those experiments are and what will make them successful?
Adrian Farrel: Yes, he does have that intention.
As it reads in the above, it sounds as if I'm making a demand, that Adrian is committing Chris to satisfy. That's not exactly how it went down, so perhaps we should clarify that in the minutes?



I'd like to go on record here, that I did not say that it "should have an explanation" to cater to my whim, but that I (as I actually stated at the mike) I was reciting what I had heard was an IESG statement/requirement (so: I thought it was the IESGs whim to be satisfied).




Adrian then clarified this, that it was not an "IESG statement/requirement" as such, but that the current routing ADs (which include him, so his whim) who require this"




<SNIP>

 o draft-rogge-baccelli-olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will also not break anything if different values are used as the values are unit-less so the routes might be crazy but they will work.
TC: I think experimental is exactly the place for this document
Emmanuel: I would like to comment to Rick's earlier comment about if this is related to OLSRv2.  It uses building blocks such as sequence numbers in RFC5444 and missed NHDP HELLO messages to calculate the metric, so in that regard it could be used with other protocols and is not only tied to OLSRv2.
CD: There needs to be a section describing the experiments. 
TC: I think this draft should be focused to OLSRv2 (and not other protocols) and not make it something overly broad and have it stall out.
Henning: For AODV this metric would be a problem as there isn't normally control traffic or any unicast traffic on a link, so there is nothing to measure.


I believe that what I said was that my experience with both proactive and reactive protocol deployments leave me to believe that metrics "make sense in very different ways in these two protocol families", and therefore would need to be considered separately. Specifically, constructing an "experiment for a metric for a proactive protocol" (which, as this is going Experimental, is a requirement by the RTG ADs) is easy - whereas constructing an "experiment for the same metric for both a proactive and a reactive protocol" is a lot harder to do correctly, and probably will just make us stall.




Therefore, given that the existing operational experience, on which this document is based, is exclusively for proactive / OLSR, only, my preference is simply to document the metric as for OLSR, and design the experiment accordingly.




<SNIP>

 o draft-gerla-manet-odmrp: Colin de Verdiere
   draft-gerla-manet-odmrp-asym
Brain-fart here, but I actually do not recall if the authors requested WG adoption "now", "a bit later", or "not at all but just wanted to inform the WG what we're doing"? - Or was it "none of the above"?




<SNIP>

o draft-clausen-manet-olsrv2-management-snapshot: Herberg
UH: Presenting. Requesting WG adoption


Have I missed something, or was WG adoption for this document already called for on the list? If not, any reasons for "not"?




<SNIP>

 o OLSRv2 + RFC6971: Clausen
No time for presentation (slides in the proceedings), brought to the mailing list.

It'd be kind if the minutes contains a link to the message which Ulrich started and wherein the discussion was brought forward:




	In the new "archive format" (which I am given to understand is being reworked to show the threads) that'd be:




	or, the format that actually allows seeing the threads, and which is useful currently:




Cheers,

Thomas

On 08 Mar 2014, at 04:04, Ulrich Herberg <ulrich@herberg.name> wrote:



Hello,

I uploaded the preliminary minutes to:
http://www.ietf.org/proceedings/89/minutes/minutes-89-manet




Please verify correctness and send edits to me by email.
Many thanks to Justin and Axel for taking the minutes. I have edited and merged them.

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





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


--Apple-Mail=_2CA2E049-9BE9-4F3C-B19F-F64D04916371--


From nobody Mon Mar 10 09:56:29 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B11C1A0329 for ; Mon, 10 Mar 2014 09:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcL6gGWRu5e3 for ; Mon, 10 Mar 2014 09:56:24 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2757E1A0574 for ; Mon, 10 Mar 2014 09:56:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 1048B621F6E; Mon, 10 Mar 2014 09:56:19 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 15199621F77; Mon, 10 Mar 2014 09:56:15 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CDFD5620-2673-48FB-94AA-BBBC472461FE"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Clausen 
In-Reply-To: 
Date: Mon, 10 Mar 2014 17:56:12 +0100
Message-Id: <9EAD178C-4F28-4BF8-8E2D-8C66CB36B404@thomasclausen.org>
References:  <36539249-D8C7-4507-B477-77BFBEE5D726@thomasclausen.org>  <03459F08-E275-471C-A212-E83A6E6A56FB@thomasclausen.org>  
To: Ulrich Herberg 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/omKsDZ7Q56IpqywZTF6Il0RTDyo
Cc: "" , MANET IETF 
Subject: Re: [manet] IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 16:56:28 -0000

--Apple-Mail=_CDFD5620-2673-48FB-94AA-BBBC472461FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Alright, I have looked. The revised version updates my concerns, thank =
you for your hard work.

Thomas

On 10 Mar 2014, at 17:52, Thomas Clausen  =
wrote:

> I'll take a look - and, I sincerely hope that you did notice the =
smiley?
>=20
> Thomas
>=20
> On 10 Mar 2014, at 17:49, Ulrich Herberg  wrote:
>=20
>> Thomas,
>>=20
>> I have uploaded a revised revision of the minutes. Please confirm if =
that reflects what has been said, or otherwise send me the precise =
wording :-)
>>=20
>> Regards
>> Ulrich
>>=20
>>=20
>> On Mon, Mar 10, 2014 at 9:43 AM, Thomas Clausen =
 wrote:
>> Ulrich,
>>=20
>> On 10 Mar 2014, at 17:36, Ulrich Herberg  wrote:
>>=20
>>> Thank you, Thomas (and others), for the corrections. Of course, you =
would do me an immense favo(u)r if you sent me the exact BEFORE/AFTER =
text, rather than me having to listen to the audio again :-D Just =
because I am lazy ;-)
>>>=20
>>=20
>> Wait, so what are you getting paid the big bucks as IETF WG Secretary =
for, again? ;)
>>=20
>> Thomas
>>=20
>>> Ulrich
>>>=20
>>>=20
>>> On Mon, Mar 10, 2014 at 6:50 AM, Thomas Clausen =
 wrote:
>>> Ulrich,
>>>=20
>>> Thank you for prompt posting of minutes.
>>> =20
>>> A couple of things that I would like to make more precise, all the =
same, in the minutes:
>>>=20
>>>> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>>>=20
>>> 
>>>> Teco: Why not make this document standards track?
>>>> CD: If people implement this and it's great.  Then I'm find  fine =
changing this to standards track if that's the case.
>>>> TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.
>>> I honestly do not think that Chris would make that typo, even when =
speaking ;)
>>>> CD: If it gets stuck in the queue for 4 years we may have enough =
experience that we may want to push for standards track.
>>>> Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
>>>> CD: We will post something up on the list.
>>>> TC: I think that experimental should have an explanation on what =
the experiment is and what the successful experiment is and what the =
conclusion is.
>>>> Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
>>>> Adrian Farrel: Yes, he does have that intention.
>>> As it reads in the above, it sounds as if I'm making a demand, that =
Adrian is committing Chris to satisfy. That's not exactly how it went =
down, so perhaps we should clarify that in the minutes?
>>>=20
>>>=20
>>> I'd like to go on record here, that I did not say that it "should =
have an explanation" to cater to my whim, but that I (as I actually =
stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).
>>>=20
>>>=20
>>>=20
>>> Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"
>>>=20
>>>=20
>>>=20
>>> 
>>>=20
>>>>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>>>=20
>>> 
>>>> Henning: It will also not break anything if different values are =
used as the values are unit-less so the routes might be crazy but they =
will work.
>>>> TC: I think experimental is exactly the place for this document
>>>> Emmanuel: I would like to comment to Rick's earlier comment about =
if this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
>>>> CD: There needs to be a section describing the experiments.=20
>>>> TC: I think this draft should be focused to OLSRv2 (and not other =
protocols) and not make it something overly broad and have it stall out.
>>>> Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.
>>>=20
>>>=20
>>> I believe that what I said was that my experience with both =
proactive and reactive protocol deployments leave me to believe that =
metrics "make sense in very different ways in these two protocol =
families", and therefore would need to be considered separately. =
Specifically, constructing an "experiment for a metric for a proactive =
protocol" (which, as this is going Experimental, is a requirement by the =
RTG ADs) is easy - whereas constructing an "experiment for the same =
metric for both a proactive and a reactive protocol" is a lot harder to =
do correctly, and probably will just make us stall.
>>>=20
>>>=20
>>>=20
>>> Therefore, given that the existing operational experience, on which =
this document is based, is exclusively for proactive / OLSR, only, my =
preference is simply to document the metric as for OLSR, and design the =
experiment accordingly.
>>>=20
>>>=20
>>>=20
>>> 
>>>=20
>>>>  o draft-gerla-manet-odmrp: Colin de Verdiere
>>>>    draft-gerla-manet-odmrp-asym
>>> Brain-fart here, but I actually do not recall if the authors =
requested WG adoption "now", "a bit later", or "not at all but just =
wanted to inform the WG what we're doing"? - Or was it "none of the =
above"?
>>>=20
>>> 
>>>=20
>>>> o draft-clausen-manet-olsrv2-management-snapshot: Herberg
>>>> UH: Presenting. Requesting WG adoption
>>>=20
>>> Have I missed something, or was WG adoption for this document =
already called for on the list? If not, any reasons for "not"?
>>>=20
>>>=20
>>>=20
>>> 
>>>=20
>>>>  o OLSRv2 + RFC6971: Clausen
>>>> No time for presentation (slides in the proceedings), brought to =
the mailing list.
>>>=20
>>> It'd be kind if the minutes contains a link to the message which =
Ulrich started and wherein the discussion was brought forward:
>>>=20
>>> 	In the new "archive format" (which I am given to understand is =
being reworked to show the threads) that'd be:
>>> 		=
http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek
>>>=20
>>> 	or, the format that actually allows seeing the threads, and =
which is useful currently:
>>> 		=
http://www.ietf.org/mail-archive/web/manet/current/msg16016.html
>>>=20
>>> Cheers,
>>>=20
>>> Thomas
>>>=20
>>> On 08 Mar 2014, at 04:04, Ulrich Herberg  =
wrote:
>>>=20
>>>> Hello,
>>>>=20
>>>> I uploaded the preliminary minutes to:
>>>> http://www.ietf.org/proceedings/89/minutes/minutes-89-manet
>>>>=20
>>>> Please verify correctness and send edits to me by email.
>>>> Many thanks to Justin and Axel for taking the minutes. I have =
edited and merged them.
>>>>=20
>>>> Best regards
>>>> Ulrich
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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=_CDFD5620-2673-48FB-94AA-BBBC472461FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Alright, I have looked. The revised version updates =
my concerns, thank you for your hard =
work.

Thomas

On 10 Mar 2014, =
at 17:52, Thomas Clausen <thomas@thomasclausen.org> =
wrote:

I'll =
take a look - and, I sincerely hope that you did notice the =
smiley?

Thomas

On 10 Mar =
2014, at 17:49, Ulrich Herberg <ulrich@herberg.name> =
wrote:

Thomas,

I have =
uploaded a revised revision of the minutes. Please confirm if that =
reflects what has been said, or otherwise send me the precise wording =
:-)

Regards
Ulrich




On =
Mon, Mar 10, 2014 at 9:43 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:


Ulrich,

On 10 Mar 2014, at 17:36, Ulrich Herberg <ulrich@herberg.name> wrote:


Thank you, Thomas (and =
others), for the corrections. Of course, you would do me an immense =
favo(u)r if you sent me the exact BEFORE/AFTER text, rather than me =
having to listen to the audio again :-D Just because I am lazy ;-)




Wait, so what are you =
getting paid the big bucks as IETF WG Secretary for, again? =
;)

Thomas



Ulrich


On Mon, Mar 10, 2014 at 6:50 AM, Thomas Clausen =
<thomas@thomasclausen.org> wrote:



Ulrich,

Thank you for =
prompt posting of minutes.
 



A couple of things that I would like to make more precise, all the =
same, in the minutes:

o draft-ietf-manet-olsrv2-multitopology: Dearlove

<SNIP>
Teco: Why not make =
this document standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's =
the case.
TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.



I honestly do not think that Chris would make that typo, even when =
speaking ;)
CD: If it gets stuck =
in the queue for 4 years we may have enough experience that we may want =
to push for standards track.
Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
Adrian Farrel: Yes, he does have that =
intention.
As it reads in the =
above, it sounds as if I'm making a demand, that Adrian is committing =
Chris to satisfy. That's not exactly how it went down, so perhaps we =
should clarify that in the minutes?



I'd like to go on record here, that I did not say that it "should =
have an explanation" to cater to my whim, but that I (as I actually =
stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).




Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"




<SNIP>

 o draft-rogge-baccelli-olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will =
also not break anything if different values are used as the values are =
unit-less so the routes might be crazy but they will =
work.
TC: I think =
experimental is exactly the place for this document
Emmanuel: I would like to comment to Rick's earlier comment about if =
this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to =
OLSRv2 (and not other protocols) and not make it something overly broad =
and have it stall out.
Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.


I believe that what I said was that my experience with both proactive =
and reactive protocol deployments leave me to believe that metrics "make =
sense in very different ways in these two protocol families", and =
therefore would need to be considered separately. Specifically, =
constructing an "experiment for a metric for a proactive protocol" =
(which, as this is going Experimental, is a requirement by the RTG ADs) =
is easy - whereas constructing an "experiment for the same metric for =
both a proactive and a reactive protocol" is a lot harder to do =
correctly, and probably will just make us stall.




Therefore, given that the existing operational =
experience, on which this document is based, is exclusively for =
proactive / OLSR, only, my preference is simply to document the metric =
as for OLSR, and design the experiment accordingly.




<SNIP>

 =
o draft-gerla-manet-odmrp: Colin de Verdiere
   draft-gerla-manet-odmrp-asym
Brain-fart here, =
but I actually do not recall if the authors requested WG adoption "now", =
"a bit later", or "not at all but just wanted to inform the WG what =
we're doing"? - Or was it "none of the above"?




<SNIP>

o draft-clausen-manet-olsrv2-management-snapshot: Herberg
UH: Presenting. Requesting WG adoption


Have I missed =
something, or was WG adoption for this document already called for on =
the list? If not, any reasons for "not"?




<SNIP>
=

 o OLSRv2 + RFC6971: =
Clausen
No time for presentation (slides in the proceedings), brought to the =
mailing list.

It'd be kind =
if the minutes contains a link to the message which Ulrich started and =
wherein the discussion was brought forward:




	=
In the new "archive format" (which I am given to understand is =
being reworked to show the threads) that'd be:




	=
or, the format that actually allows seeing the threads, and which =
is useful currently:


=


Cheers,

Thomas

=

On 08 Mar 2014, at 04:04, Ulrich Herberg <ulrich@herberg.name> wrote:



Hello,

I uploaded the preliminary =
minutes to:
http://www.ietf.org/proceedings/89/minutes/minutes-89-ma=
net




Please verify correctness and send edits to me by =
email.
Many thanks to Justin and Axel for taking the minutes. I =
have edited and merged them.

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

=




_______________________________________________
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=_CDFD5620-2673-48FB-94AA-BBBC472461FE--


From nobody Mon Mar 10 10:24:07 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F3C1A06A8 for ; Mon, 10 Mar 2014 10:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4RDFK5Yk14n for ; Mon, 10 Mar 2014 10:24:04 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 72F4D1A066C for ; Mon, 10 Mar 2014 10:24:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=762; q=dns/txt; s=iport; t=1394472239; x=1395681839; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KbPlROeEUFFU6PALus8m2oh4gAj9ECWV5Zpq2CCZ/v0=; b=M0SMZVBrAYZSb6awJlQ8R46xRb+mBmDmMyywOEgLIBKbG/89tAB8myFd rumOzkuYMMpW/WqCzFNcW8oMZoZV4pmYs+GEcchEF+w+czZVQfosQYYxP I2GrrzeJlnrVBP4fTEk/T4q91WZLVE/ZTtaw3o5Jl4QDH0JQm8Y9jppfk o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFANXzHVOtJV2c/2dsb2JhbABagwY7V8E9gR8WdIIlAQEBAwEBAQE3NAsFCwIBCDYQJwslAgQOBYdxCA3PQhMEjigzB4MkgRQEmEWSLYMtgis
X-IronPort-AV: E=Sophos;i="4.97,625,1389744000"; d="scan'208";a="26292308"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 10 Mar 2014 17:23:58 +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 s2AHNwRo002532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 17:23:58 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.172]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 12:23:58 -0500
From: "Stan Ratliff (sratliff)" 
To: MANET IETF 
Thread-Topic: [manet] draft-rogge-baccelli-olsrv2-ett-metric
Thread-Index: AQHPOGPJiA8bCyFNB0iARcfb9cD77pra7hQA
Date: Mon, 10 Mar 2014 17:23:58 +0000
Message-ID: <36441D13-16E2-4290-8695-A7617F56DAA1@cisco.com>
References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com>
In-Reply-To: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.41.104]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <89826B869F35C441A5D2D1EF2EE94448@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/4ngS-79N6I-N87FjhU-9bCw4w-g
Cc: Emmanuel Baccelli 
Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 17:24:06 -0000

Working group,=20

The time period for commons having past without *any* objections, this docu=
ment is accepted as a Working Group document.=20

Co-authors, please post the next version of the draft with the "draft-ietf-=
manet" prefix.=20

Regards,
Stan

On Mar 5, 2014, at 6:12 AM, Stan Ratliff (sratliff)  wr=
ote:

> Working Group Participants,=20
>=20
> The consensus in the room this morning at IETF 89 is to accept this as a =
working group document. If there is opposition to this action, please respo=
nd on the list no later than March 7, 2014.=20
>=20
> Regards,
> Stan
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From nobody Mon Mar 10 10:28:24 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66D21A06CB for ; Mon, 10 Mar 2014 10:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO-6H1FqwYyO for ; Mon, 10 Mar 2014 10:28:19 -0700 (PDT)
Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D629D1A06C8 for ; Mon, 10 Mar 2014 10:28:18 -0700 (PDT)
Received: by mail-qc0-f175.google.com with SMTP id e16so7982577qcx.20 for ; Mon, 10 Mar 2014 10:28: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=2UfuVQPNSF+mg1Juz0i+tgELM+D/jNn3xRzlOIuD8UQ=; b=V/IM4u45kdDgftHFukgTTIMVuvfWp+kb5of3uKDNqUdknvD0Mft4sCH/TzyzbtWTTX ULe1ULJ0gEddi1YzNbG/qD5ZgRrbp6FtDfBW6wDgMh12J8paEZc/HhjHAv68LekhJrjK JpWbPZSaA3C7wShlewlCnZ48zkSZtgUOgiRsqbL80IWKxB4kdyutznldzw3S5aB8ElII XTbDPwT1lbgQQGVNv7qdxKJCsCo+WttSQl+kfxS0NrGbvnUkIT7r5u+SirNcO6Rfa1CQ /6kzSxOMizsR8TRNXIFB8h3XOMqRJ7/1sHgSDAUnGuKbn1euvY0jOfNJDfxHDQxsvFrC QbZw==
MIME-Version: 1.0
X-Received: by 10.229.58.68 with SMTP id f4mr5323415qch.18.1394472493347; Mon, 10 Mar 2014 10:28:13 -0700 (PDT)
Received: by 10.224.120.66 with HTTP; Mon, 10 Mar 2014 10:28:13 -0700 (PDT)
Received: by 10.224.120.66 with HTTP; Mon, 10 Mar 2014 10:28:13 -0700 (PDT)
In-Reply-To: <36441D13-16E2-4290-8695-A7617F56DAA1@cisco.com>
References: <73E568FE-EE8E-45DF-A430-3E3F5FF35603@cisco.com> <36441D13-16E2-4290-8695-A7617F56DAA1@cisco.com>
Date: Mon, 10 Mar 2014 17:28:13 +0000
Message-ID: 
From: Henning Rogge 
To: Stan Ratliff 
Content-Type: multipart/alternative; boundary=001a113306b09d821704f443edd3
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/LgTmOjs0I-cCGcnYnjssxwXLchY
Cc: Emmanuel Baccelli , MANET IETF 
Subject: Re: [manet] draft-rogge-baccelli-olsrv2-ett-metric
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 17:28:21 -0000

--001a113306b09d821704f443edd3
Content-Type: text/plain; charset=ISO-8859-1

I am in a business trip in Antwerpen this week, I will publish the new
version on Monday.

Henning Rogge
On Mar 10, 2014 6:23 PM, "Stan Ratliff (sratliff)" 
wrote:

> Working group,
>
> The time period for commons having past without *any* objections, this
> document is accepted as a Working Group document.
>
> Co-authors, please post the next version of the draft with the
> "draft-ietf-manet" prefix.
>
> Regards,
> Stan
>
> On Mar 5, 2014, at 6:12 AM, Stan Ratliff (sratliff) 
> wrote:
>
> > Working Group Participants,
> >
> > The consensus in the room this morning at IETF 89 is to accept this as a
> working group document. If there is opposition to this action, please
> respond on the list no later than March 7, 2014.
> >
> > Regards,
> > Stan
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
>
>

--001a113306b09d821704f443edd3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I am in a business trip in Antwerpen this week, I will publi=
sh the new version on Monday.


Henning Rogge


On Mar 10, 2014 6:23 PM, "Stan Ratliff (sra=
tliff)" <sratliff@cisco.com> wrote:

Working group,



The time period for commons having past without *any* objections, this docu=
ment is accepted as a Working Group document.



Co-authors, please post the next version of the draft with the "draft-=
ietf-manet" prefix.



Regards,

Stan



On Mar 5, 2014, at 6:12 AM, Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:



> Working Group Participants,

>

> The consensus in the room this morning at IETF 89 is to accept this as=
 a working group document. If there is opposition to this action, please re=
spond on the list no later than March 7, 2014.

>

> Regards,

> Stan

> _______________________________________________

> manet mailing list

> manet@ietf.org

> https://www.ietf.org/mailman/listinfo/manet






--001a113306b09d821704f443edd3--


From nobody Mon Mar 10 11:46:33 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4285C1A04B7 for ; Mon, 10 Mar 2014 11:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnZel54rbg2Q for ; Mon, 10 Mar 2014 11:43:56 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE5E1A0454 for ; Mon, 10 Mar 2014 11:43:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 174741C0523 for ; Mon, 10 Mar 2014 11:43:51 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.147.142] (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 5EA771C0694 for ; Mon, 10 Mar 2014 11:43:44 -0700 (PDT)
Content-Type: multipart/mixed; boundary=Apple-Mail-C88126A4-C6C2-4016-AEDB-24B595C5CBE3
Content-Transfer-Encoding: 7bit
From: Thomas Heide Clausen 
Mime-Version: 1.0 (1.0)
Date: Mon, 10 Mar 2014 19:43:39 +0100
Message-Id: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>
To: MANET IETF 
X-Mailer: iPad Mail (11B651)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Z9Odc5ISdq1M_RcSVxMmdvgvWXo
X-Mailman-Approved-At: Mon, 10 Mar 2014 11:46:24 -0700
Subject: [manet] draft-gerla-manetodmrp-02 review
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 18:44:00 -0000

--Apple-Mail-C88126A4-C6C2-4016-AEDB-24B595C5CBE3
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Dear All,

As the authors requested feedback, I have given the most recent version of t=
his document a review. My comments are below - but do also look at the attac=
hed PDF, it's easier to see where each comment applies in there ;)

For those not wanting to read the whole review: I think that this is a well w=
ritten document, I think it's an interesting idea, and I think it's worth ta=
king further, so I'd encourage further further reviews and work.

There are a few things that need to be addressed, though. Outside the obviou=
s, 'security considerations' and 'the experiment', the main issue is "multip=
le interfaces and addresses". While the protocol, as I understand it, can wo=
rk in multiple interfaces/addresses scenarios, I think that the specificatio=
n is unclear on certain things such as which addresses go in which informati=
on sets (such as the Blacklist) and messages.

Either way, see below, and see the file attached to this message - and I loo=
k forward to discussing this further with all y'all.

Cheers,

Thomas

File: draft-gerla-manet-odmrp-02 - flattened.pdf

Annotation summary:

--- Page 1 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
General Comments:

I find this specification very well written, well structured, clear and easy=
 to understand.=20

Note (yellow), 10 mars 2014 19:24, TClausen:
Executive Summary:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I find this specification very well written, well structured, clear, and eas=
y to understand. I believe that there are some clarifications that could be m=
ade, though, and a few "formal" things to correct - but also that the protoc=
ol specification is fairly straight-forward.

Now, the one point that I think is needing a bit of effort is regarding rout=
ers with multiple interfaces and/or multiple addresses, which seems to not b=
e fully specified. At least, it should be made clear which parts of the info=
rmation base are per interface, and the processing adopted accordingly. The w=
ay the "blacklist", for example, is written actually permits an implementati=
on to explicitly "do the wrong thing" when faced with routers with multiple i=
nterfaces. I think that it's fairly easy to clear up.


General Comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I think I understand the general idea, though, of the way the specification i=
s made: you describe, in abstract form, the protocol, signals, etc., and the=
n you provide the mapping to RFC5444-elements in an appendix.

That is not entirely stupid as idea, and the resulting document is actually n=
ice and readable, but.....appendices can't (or, shouldn't) contain normative=
 text. Indeed, there are many MUST/SHOULD/* in Appendix A.=20

I suggest promoting Appendix A to a "numbered section" somewhere (perhaps af=
ter section 7?)=20

While I know that it is early, I think it would be helpful to have some refl=
ections on the security considerations. Recent experiences with the SEC-ADs i=
ndicate, that they're considerably more strict than they were even half a de=
cade ago, so understanding "what we're getting ourselves into" if the WG get=
s involved with this protocol might be helpful.

As was discussed during the MANET wg meeting in London, an EXPERIMENTAL docu=
ment is supposed to enable an experiment, and that experiment should be docu=
mented. See e.g. RFC6971, section 1.2. I'll try to add a couple of my though=
ts on what would make for good "experiments":

I do believe that, perhaps, a distinguishing point of ODMRP vs. SMF and othe=
r such protocols: whereas these rely on "get a copy of the message to each r=
outer, then have the router decide if it delivers those to applications", OD=
MRP works by only getting copies of messages to routers that actually need i=
t. So, an experiment establishing the boundaries where "efforts to construct=
ing the overlay" are out-weighted by the benefits of not having to deliver a=
 copy of the multicast message to each router.

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Mobile Ad hoc Networking (MANET)

Note (yellow), 10 mars 2014 19:24, TClausen:
"Network Working Group" -- see RFC Editor tutorial slides, page 20

Highlight (yellow), 10 mars 2014 19:24, TClausen:
conventional tree-based,

Note (yellow), 10 mars 2014 19:24, TClausen:
Now that I have thought this bit over....

In the end, a tree is constructed, though, is it not? Join Queries flooded, t=
hen Join Replies sent back, in a "Tree-construction" fashion?




--- Page 4 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
routing                    techniques to avoid

Note (yellow), 10 mars 2014 19:24, TClausen:
So, it is actually not clear what this means, specifically. The more I think=
 about it, the less do I think of this as "on demand routing techniques" and=
 the more do I think of this as "on-demand tree construction, with proactive=
 maintenance",

Note (yellow), 10 mars 2014 19:24, TClausen:
The more I think about it, the less do I think of this as "on demand routing=
 techniques" and the more do I think of this as "on-demand tree construction=
, with proactive maintenance",

Note (yellow), 10 mars 2014 19:24, TClausen:
The more I think about it, the less do I think of this as "on demand routing=
 techniques" and the more do I think of this as "on-demand tree construction=
, with proactive maintenance".

It is clear, that a sensible routing protocol creates and manages forwarding=
 trees/graphs/groups only when there is an actual need for one to exist - so=
, in that regard, all sensible multicast routing protocols are "reactive".

As I understand it, this protocol is generating the forwarding tree/graph/gr=
oup from the (expected) source, and then that this is maintained by way of p=
roactive signaling (for as long as there is a need for the forwarding tree/g=
raph/group)

I'd suggest being explicit as to this, both in introduction and in the abstr=
act?

Note (yellow), 10 mars 2014 19:24, TClausen:
I think that you actually also are importing terminology from RFC5444 here, a=
re you not?  At least, section 7 "Packets and Messages" seems to be hinting a=
t - but not calling out explicitly - that you are.

I think I understand why you're not calling it out, with the way that the I-=
D is written and RFC5444 message mapping being in Appendix, but as I have su=
ggested in "general comments", that organization might not be ideal?

Highlight (yellow), 10 mars 2014 19:24, TClausen:
e.g.

Note (yellow), 10 mars 2014 19:24, TClausen:
Technically, that's probably "i.e., " as there are only those two message ty=
pes, yes?

Note (yellow), 10 mars 2014 19:24, TClausen:
I would suggest answering the question, which is on everybody's lips, alread=
y here: does this integrate with "regular IP Multicasting" or does it requir=
e "application level tunneling"?=20

In other words, could I expect an mcast-capable application to "just work", a=
nd can I implement this "on a commodity OS", or will I have to do kernel-lev=
el hacks?

Note (yellow), 10 mars 2014 19:24, TClausen:
I would suggest answering the question, which is on everybody's lips, alread=
y here: does this integrate with "regular IP Multicasting" or does it requir=
e "application level tunneling"?=20

In other words, could I expect an mcast-capable application to "just work", a=
nd can I implement this "on a commodity OS", or will I have to do kernel-lev=
el hacks to make it work?

Having read through the document, I think that I infer that it's possible to=
 build an user-space implementation manipulating working by simply multicast=
 routing table entries.

Would be good to have it confirmed that my understanding is correct - if it i=
s, that is ;)


--- Page 5 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
addresses

Note (yellow), 10 mars 2014 19:24, TClausen:
I am going to pick out this here, but it applies elsewhere also: "addresses"=
?=20

I believe that you aim at "address length independence", v6/v4/short, and th=
at's a good idea which is, I believe, supported well by RFC5444. Alas, I bel=
ieve that you probably want to stick in a definition and explanation of that=
 in here.=20

Also, I gather that these addresses are "interface identifiers" and not "mul=
ticast group addresses", yes? Given that this document talks about multicast=
, I do recommend perhaps calling this out?

Note (yellow), 10 mars 2014 19:24, TClausen:
I actually would love for you to repeat the example text for "Upstream" here=
, also. Yeah, it's repetitive, but when reading through a document and looki=
ng for a definition, it's nice to not be hunting.

Note (yellow), 10 mars 2014 19:24, TClausen:
I am repeating my comment from the introduction here:

The more I think about it, the less do I think of this as "on demand routing=
 techniques" or a "reactive" protocol, and the more do I think of this as "o=
n-demand tree construction, with proactive maintenance".

It is clear, that a sensible routing protocol creates and manages forwarding=
 trees/graphs/groups only when there is an actual need for one to exist - so=
, in that regard, all sensible multicast routing protocols are "reactive".

As I understand it, this protocol is generating the forwarding tree/graph/gr=
oup from the (expected) source, and then that this is maintained by way of p=
roactive signaling (for as long as there is a need for the forwarding tree/g=
raph/group)

I'd suggest being explicit as to this, both in introduction and in the abstr=
act?

Note (yellow), 10 mars 2014 19:24, TClausen:
Just to be clear; am I correct in understanding that:

A Multicast Group Address, is used by applications, and joined (etc) by way o=
f IGMP/MLD.

The ODMRP router hearing these,  maps that to a "Multicast Session".

That ODMRP router then proceeds to construct a Multicast Overlay for that mu=
lticast session; the Multicast Overlay of a multicast session is a source-ro=
oted multicast tree?

Also, as I understand it, "Forwarding Group" and "Multicast Overlay" are, re=
spectively, "links" and "routers" for a given Multicast Session?

I think that thats what it is, but the relationship between these terms/conc=
epts  could merit being rendered crystal clear here.


--- Page 6 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest adding "These multicast overlays are, then, proactively maintained f=
or as long as the overlay is needed (as long as there are members in the mul=
ticast group AND as long as there is data to be delivered to the multicast g=
roup)"

Note (yellow), 10 mars 2014 19:24, TClausen:
IIRC there's a space after and before a "dash"......

Highlight (yellow), 10 mars 2014 19:24, TClausen:
overlay only

Note (yellow), 10 mars 2014 19:24, TClausen:
-> "overlay, only"

Note (yellow), 10 mars 2014 19:24, TClausen:
Correct, but not complete. The overlay is created, trigged by data to delive=
r to the members - but, no overlay is actually created unless there actually=
 are members of the destination set.=20


Highlight (yellow), 10 mars 2014 19:24, TClausen:
overlay for

Note (yellow), 10 mars 2014 19:24, TClausen:
-> "overlay only for...."

Note (yellow), 10 mars 2014 19:24, TClausen:
and until there no longer are members of the multicast group?

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest "if the router belongs to, i.e., has attached hosts which have subsc=
ribed to, the multicast group ..."=20

Highlight (yellow), 10 mars 2014 19:24, TClausen:
originates

Note (yellow), 10 mars 2014 19:24, TClausen:
This is a really detail-oriented comment, but "originates a Join Reply" here=
 - and "Join Reply Generation" as the section title for section 9.1.2 is a l=
ittle incoherent ;)=20

Note (yellow), 10 mars 2014 19:24, TClausen:
I'd proffer that a lot this perhaps should be going in the "Signaling Overhe=
ad" rather than in this section; in part, as you describe messages and sets,=
 before these are defined.

As overview, it's quite too detailed, so perhaps jumping straight to 4.2 and=
 merging 4.1 into 4.3 is the best approach?

Or, perhaps, have 4.2, then 4.3 and finally 4.1 ?


--- Page 7 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
carried

Note (yellow), 10 mars 2014 19:24, TClausen:
This is too "implicit": a "next hop address carried in a packet". You should=
, at least, in the previous bullet point indicate that a Join Reply carries a=
 "next hop address" (and, possibly, what else it carries - I think that for d=
uplicate JR suppression, that's important?)

Highlight (yellow), 10 mars 2014 19:24, TClausen:
it

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest "If that next hop address is an address of this router..."

Also, what does "is an address of" or "corresponds to" this router mean, pre=
cisely? This may sound like a slightly silly question ;) but in NHDP/OLSRv2 w=
e've had to be extremely careful with to what addresses correspond: a router=
, interfaces on that router, or addresses of hosts reachable by way of this r=
outer.

The upshot of this is, that it's really easy to sort out, for example: "Is a=
n address of an interface of this router", or something.

Highlight (yellow), 10 mars 2014 19:24, TClausen:
,

Note (yellow), 10 mars 2014 19:24, TClausen:
For readability, given that this is the overview and functioning:

"If , , , then this ODMRP Router belongs to=
 the forwarding group for the multicast session. Consequently, it installs .=
.."=20


A secondary comment here is, that you have defined "Multicast Session" in th=
e terminology, but you're not using it here (rather, you say "......Forwardi=
ng Group, which correspondS [sic] to this multicast group and source..."


Note (yellow), 10 mars 2014 19:24, TClausen:
This is confusing. What is actually discarded here? I.e., what does "it" cor=
respond to"?


--- Page 8 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
flooded periodically

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest adding that/if that can be done by way of an optimized flooding oper=
ation, if available on the network.


--- Page 9 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
This probably needs a bit more of explanation. As I indicated in the general=
 comments, the separation of abstract message content, and 5444-encoding is a=
 possible way to go, but it is not clear at this point that that's what's be=
ing done.

As a consequence, it is not clear why the section title is "Packets and Mess=
ages" - those are (in MANET) 5444-constructs, typically.

One possibility could be to stick Appendix A after section 7. Another, to ha=
ve appendix A be a subsection to section 7.




--- Page 11 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Multicast Source

Note (yellow), 10 mars 2014 19:24, TClausen:
Somewhat of the same comment as one I have made before: "the address of the M=
ulticast Source"

First, is the "Multicast Source" the router, through which the multicast dat=
a messages ingress through, or is it the host on which the application gener=
ating data, is? Does it make any difference? "Multicast Source" is not defin=
ed.

Second, what about multiple interfaces/addresses?=20

I can probably infer how it should be: this is the IP address that one will f=
ind in the source-address field of IP multicast datagrams, yes? If so, perha=
ps just call that out somewhere so there's no doubt.

Highlight (yellow), 10 mars 2014 19:24, TClausen:
address of the neighbor ODMRP Router

Note (yellow), 10 mars 2014 19:24, TClausen:
Jumping on this just once more. "The address of the neighbor ODMRP router...=
"

The way it is written, one gets the impression that ODMRP is designed for si=
ngle-interface-single-address routers.=20

I do not *think* that this is the case, and it certainly does not have to be=
 made a constraint, so I recommend clearing that up. (Conversely, if it is t=
he case, call that out as a constraint in applicability section). This appli=
es actually through the document, so looking at giving it a pass through wit=
h "remove doubts as to multi-if/addr" as objective would be great.


Highlight (yellow), 10 mars 2014 19:24, TClausen:
R_source

Note (yellow), 10 mars 2014 19:24, TClausen:
Why is it P_multicast_source, but this is R_source?

Note (yellow), 10 mars 2014 19:24, TClausen:
=46rom this description, it appears that it all is "per router" and with no "=
per interface" sets, is that correct?

As I have indicated for the "Blacklist" this may be problematic, or at least=
 necessitate some extra care to specify completely.


--- Page 12 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Multicast Source

Note (yellow), 10 mars 2014 19:24, TClausen:
See previous question regarding Multicast Source

Note (yellow), 10 mars 2014 19:24, TClausen:
Contrary to previous...._source, this is unambiguous ;)

Highlight (yellow), 10 mars 2014 19:24, TClausen:
F_source

Note (yellow), 10 mars 2014 19:24, TClausen:
Why is it P_multicast_source, but this is F_source?


--- Page 13 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
I would probably say "...over which the Join Reply was sent"

Highlight (yellow), 10 mars 2014 19:24, TClausen:
an

Highlight (yellow), 10 mars 2014 19:24, TClausen:
ODMRP Routers

Note (yellow), 10 mars 2014 19:24, TClausen:
What if two routers, A and B, have two interfaces a1, a2, b1, b2?

If A can hear B over a



Note (yellow), 10 mars 2014 19:24, TClausen:
What if two routers, A and B, have two interfaces a1, a2, b1, b2?

If A can hear B over (a1, b1) and B can hear A over (a2, b2), what addresses=
 go into this set?

Also, what if A can hear B over (a1, b1) (and B can hear A over the same pai=
r), and A can hear B over (a1,b2) but B cannot....?

In other words, is this set per interface or per router?

And, what are the addresses you put in there, interface addresses, or "Route=
rIDs"?



--- Page 14 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
Alright, so reading this, it seems that the blacklist must be "per interface=
", yes?


--- Page 15 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
an address

Note (yellow), 10 mars 2014 19:24, TClausen:
Which address? Any? Always the same? Does it matter?


--- Page 16 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
an address

Note (yellow), 10 mars 2014 19:24, TClausen:
Which address? Any? Always the same? Does it matter?

Highlight (yellow), 10 mars 2014 19:24, TClausen:
neighbors

Note (yellow), 10 mars 2014 19:24, TClausen:
I assume that what you want is to forward to all the neighbors on all ODMRP i=
nterfaces of this router, yes?



--- Page 19 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
neighbors

Note (yellow), 10 mars 2014 19:24, TClausen:
Over all ODMRP Interfaces?


Note (yellow), 10 mars 2014 19:24, TClausen:
Here, we are gleaning a bit more precisely what the R_source is; so its an i=
nterface of an ODMRP router over which the Join Reply was sent, yes?


Highlight (yellow), 10 mars 2014 19:24, TClausen:
Else

Note (yellow), 10 mars 2014 19:24, TClausen:
Else -> "Otherwise, if a tuple exists, ..."


--- Page 20 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
"Otherwise, ..."


--- Page 21 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Else

Note (yellow), 10 mars 2014 19:24, TClausen:
->Otherwise

Note (yellow), 10 mars 2014 19:24, TClausen:
Really nit-picking, but " i.e. " -> " i.e., " is the RFC-Editor style....

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest: "...run in conjunction with, and benefit from some of the features o=
f, SMF..."

Strikeout (red), 10 mars 2014 19:24, TClausen:
and                benefit from some of its features.

Note (yellow), 10 mars 2014 19:24, TClausen:
I would be hesitant to call this section "SMF Considerations"

While SMF is an important and useful protocol set, I would suggest that this=
 section be generalized: what's at stake is, and I think that I saw that in t=
he slides that were presented in the London IETF, that if there's a "more ef=
ficient than classic flooding" network-wider broadcast operation in place, t=
hen ODMRP would/should use it - correct?

This might be by way of SMF, or it could be as an extension to OLSRv2's MPR f=
looding, or it could be (as is seen in for example HNCP) something based off=
 of Trickle - or something entirely different.

So, perhaps "Flooding considerations" as section title, and a bit generalize=
d text would work?


--- Page 22 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Packets

Note (yellow), 10 mars 2014 19:24, TClausen:
Packets -> Packet

Note (yellow), 10 mars 2014 19:24, TClausen:
OK, I think that this document should start by actually requesting the alloc=
ations for the two message types. Cf. how it is done in section 18.2 of RFC6=
130

Then, I *think* that the current 15.1 is the Message-Type-Specific TLV Type R=
egistries" that are being set up, for Join-Query yes? I see "Expert Review" m=
entioned, but no guidelines/recommendations for the Expert to follow. Do you=
 intend to mirror those from RFC5444, or are there special concerns to take i=
nto consideration?

I would actually suggest mirroring the structure of the IANA section from RFC=
6130  if for no other reasons, than that it's allocating from RFC5444-regist=
ries, and has been going through the process and so it may be assumed that s=
omething mirroring it will, too. ;)



--- Page 25 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
Just a comment, a cursory review of the mapping to RFC5444 doesn't have anyt=
hing jump at me screaming "problems", which is good.

I was wondering one thing, though: if running OLSRv2 + ODMRP, then there's a=
n obvious option which could be considered (and could be considered, in orde=
r to be disregarded)....

Could one imagine carrying ODMRP signals inside TC messages in any meaningfu=
l way, as TLVs and additional addresses included? *technically* it should be=
 possible, does it make sense?

A second thing, is there any reason to request both JR and JQ message type, o=
r is there a way of using just a single code-point, and are there potential b=
enefits in doing so?

A different way of phrasing the above is: given that code-points by definiti=
on are limited, I'd like to ask for a bit more of "justification" before the=
y are allocated.

FWIW, I've not had the cycles to review the appendices, other than Appendix A=
.


(report generated by GoodReader)




--Apple-Mail-C88126A4-C6C2-4016-AEDB-24B595C5CBE3
Content-Type: application/pdf;
	name="draft-gerla-manet-odmrp-02 - flattened.pdf"
Content-Disposition: attachment;
	filename="draft-gerla-manet-odmrp-02 - flattened.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNmV9T20YUxd/5FHfyRGb8HzCQNwKkZSYmJKjtZEof1tLa
2iJpxe4Kh2+fs5JlW0Zq67XpWA9IMpL88909996zeqKv9ETdS90nX1OPtI/TPg56+NsfdoY48GP6
6FGv0+v1+uT51B8U/7e70+FRZ3B2TF580PU83ELehA5px9v7A+9vuvZy1k3gTvpzOFrAHewN3NH5
HsMNTmvgRnIsIk4XAYXSp1tuZlI9imRKD4eji9tr7+H9fxj37x36LsrrXAe2f1KDd5MYrhJu2leK
TUz5FZvs7zv0mfPyDle4XimJ1Vln4ZKAB6QNM5n+QNc/Uq5EzBPDovIbi/1viXjmSgvzQnJClywS
E6kSwVr0WeryUke44XmdJMAiFAfUPU8Nj8dc0bBFg17/uPy6f9lfJFMe8a3hTt9IEn906D4rf4Jr
5IZ1kigfutneCzl9lNxK51LGKUteyvtd4U7qBFE+1HU/6tAvXEWsvN8V7rhOEOVDN9lfdBCvSCQU
cPqdq0Bwta1ah0d1gtgA6k3V2n8TQexIrb3dCSKP94gpP6STauJxnHMn528hiPVp4Qp3titBrAOt
nrvCnTYJ4kvSvuIxSwIaZZERPtOGvsnM2DR2p6SRvozQCny5Gn27QyuAomVbhV+XrcKiPlhMV7yT
DSQR2EagPbU5rA1wtAYyiFXa7g1WA1Vz7Ap3vGNJ1KC5R+6oThIXY20U853apTo618gN9lkS/QZJ
2Dq+oSqEJkbxQj+VEDrG7vi8QRJqLs60FGfAtZgmaEKtNlnRxkMVto3XNBMmpLho8UOpje7sBO6s
QRJ5mqAiHFyH7THTPGiRYiZE+2lCliBQvkye0SELmaBJNorz8rIKmrMkjk/rJIFnLwdI+yGPOdms
l2l0uMzGbsbQeyDrTRHh1EL66JuR+mQSveAKnY01X1GU67guvPWqkQAdXEEiMZYlika4+ApzyvxH
bjQ9C7D4MrUDHklpkR/eY1RvVtjcY9dkrlmaRgJwMmkHRbnA/PN5kMFhkJEUvCQsRvWIEKtxJqKA
7Dy1oUWMYyZgiNDhzTfX0DWZ6+XAFmMX525HhyJFXBZTcsajCKMoTFUqM5gkuJxFGXOFqzXX+MHN
UqQZRMFpjBDNRACdQjeRiC1gCzFNZSSnCw9RhM4VrtZa45E+FDm1c07xpwyatDMdA6ZYKoLopZWf
pHIG7YINkrBlRSDXVLPIlsNaa63nz9zZzjFyR7XW+j63+1ayJkRgRjyWW4G6wr2Vta78GFe4Jmvt
2ZCtLevgE+RXTH0rTiSKSQatYr4hLaPF83lRx2xCXNtc4ZqsNbLas9AoTUh1E/p4eUenZ7kK8sPz
2nm/hrQ8dYXbmbVeorw+coVrstbVEUXiR2orlxID6Wd2USwPqh3F8mK6TqbIJ1gzQ+Fd2Vzhmqy1
x/QjfZIKM+nh8Oba+5SXzFtpuG1KDMm8P8mrh0a5QhaMNIqaQL4TY9SxFTR76IrXZK5fx4mtS8Q2
bh4iF4HJTk0/UwoRXUSyvUB0hBs0met84VXnTZ2h0Jj0Q7cbMGRAOIxHrjqCm0lHqmk3N2a6Oyfr
1mrFFW6fzfWgyVyXs7xYuy4kkQeJloJ4xkrwvHXHxPsh4iy2w6vFD7TtiQm37UsGTda6aMzQrXHK
Uoxn3qfzNGLo6loEKyHHWkbcJuQx1qxzgSyxoZmVBU5XQQyarLXBGjrmD3paVAaRoPtUMlUClLbZ
RM++nPfz6QnBKD5BP2WrRXVznXO11hqPjoEBlsgGCTQ+Gjbbq2Pc8iAVLkfTO6tqW8zAPkWbrDvv
qlz5mSvcPlvrQbO1fl36ZwKlnufvKuAuXr+sqE0jNnSOkes3GeuawXH/yBWu1lhfyvRFiWloCBVL
vJrfG1O6wjUZ640B/ukGV7gmX70M3sOhjxXM/AWYbQHIUxlqqc2D0C3hxZ22bZ8I7NrERCDvIafY
/1Q2V7wmY115+LYnrnBNxnpbnsr9rnBNxrry8G1PXOFqjfV30SIsFbFoLXfN38i+znFr9H/esSmn
/l/lx65w+2ysC1+NNXsvXlsIK3/1TvaOoSuM9b7SFc56X+kKa72vdIW33le6wlz/j3RffwKe4t5/
CmVuZHN0cmVhbQplbmRvYmoKNSAwIG9iagoxNTc1CmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9Q
YWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIgPj4KZW5k
b2JqCjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0Nz
MSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iago5IDAgb2JqCjw8IC9M
ZW5ndGggMTAgMCBSIC9OIDEgL0FsdGVybmF0ZSAvRGV2aWNlR3JheSAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PgpzdHJlYW0KeAGlVwdUU8kanluSQCChVymhI82AdKRESgggvQg2YhJIIIQYEhTEhi6u
4NrFgmVFF0VdbCsCa8WChcWKZS0PdFFQ1sWCDVff3AQ17r6z753zcs9wv/nnn7/PfwcA9Cy4UqkY
BQAUSOQydjIrc3xmFoNyB2gAE6ADPIAOl1ckZSUmxkEWICmUCIj3179X1wFCUK66E7K+XvuvMxJf
UMSDXMfhKOEX8QoAQMYAQNnAk8rkAGjchHS76XIpgd9DbJifmhwOgKYunGsP74VkYM0WSAQyEY/B
lnFLGGxuQQGX4eXhxUiUFeaIxP/BamLT//MrECsIu4mfFRzaRfkpsfDtAe2fIZCkpUAM/UDqeNxI
AvtDfF8qH5sMcQwAqLkiP40FsRvE/BxZVBrEIRAvEyqiCewNcUepMDUDYigfQyVT4xMgDoSYkV8Y
S8ixhTiLVxSeBbEzxGVCAYfIkz3E22SFyQS/C8Rn+YKISIjjIX4uknNSVRgPKypOIejQNnxJqTAc
rhO68DN53JhEiB0h/k0gZhO6oBwSVSpPJGTCOclbIo4ndIVBXCEoUvoI56QzcmFqNKR7AUDWl8tS
ib3QHnJEjiiKA3EUxEKhLJqgQ3/JDVKxsrZgTMj9MkUy4Tv0keLLlUWyIYbxoUj53Agitko7QTrC
BQJQCKbCvzwgAd2AAYqACBQrUS7gggI4GNACNzjYkEsChwxy8CCVDREXlCgRwfmJ1wPyMkAiXC0E
OZBXDPewlbJUHHw4Z4BcpZwiyFOknBGye4dlq3QSchKV+lRSCI0EV98wVyHcx1fap5JO7FLJDoda
JaAUrhGyldbjJjgTHw1HEB6HB+NMSP9kv7uSPkZJ84JVR2j9Yjthad9nrdOA4ivriVV134k4nYAe
yyFVDKMoGfavCFrzHkrNH96tvgdqXGaucJZKq5ckcSbXKS1WxrBcNkXEu7h0YNhvVeSLoAxV9HqU
b3VJhHZ3IP1ifVvZYVPAuL74+DnA2K3bfPaL7E68aeJV7bYykKCefWU98P+WfWgN6QrpEuke6Rpg
wPdvpE5SL0S3SXfgc+uz1C95UGWXsFOtZhBMyUlYyYLREStXCyAHkS2BMleqnCgglsNI5yh3u/8l
H+q1pKpM9XwRVaHSngvlqmZqNigpRJUQ+omK+Xv+1Ov862irtKnvUYt1jmSZuVQ6ua5sSCD9HBEG
kT/BwvhX8aDcjbmX2c/cxtzNfMG894WDeYP5O7OTuQWuPMFWYgexI1gz1oK1AwactWAnsGYl2o0d
hs++z/u+PhmqOH99MohTxhs+CUQE5MO1qH5mPp3ZTzkh5BAZIfg/xTFv+IT+U6UR8fzfLFKP99ed
QFUByhjT7eiedArdhe5DZ9ERug18vOhhENnRbelxdBO4Gk13okfQR3yOx6esiSGFqCKR8k3Y/KWD
ZUIrP1Ub4Z8QrsmUHNxhf//qI+Or80T0MpH6aURo8DSqNP1TL1SrEpAGNYnAdGiHDMaV6BISZQ9V
5yG6MNG9YBdCJihzqF5znzqaFe6Jc2BHSwAMnIX74GHDmOhyY+BD9DhVxbrjoXA1BI/A/Yn+Rw4k
O5EjyU7KdWWnIUeQo8lRgEH2JOjkUeQYiAMILrlgBrwvABBeKC2RiXKFcgYL3kwEDI6E5+HG8GJ6
wq8Tcc8heAB4kaS8vyDG7TyFrFhFw4kXCVDhHcgQmMGvoh38wrpDy/xAEPzmRcJveAJIBZlgMvRU
CLMhg9EpA/NABagCy8BqsB5sBttAPWgA+8EhcBj21zPgArgEOsFt0AV6wBMwAF6BIQRBKAgNMUDM
EGvEAXFFvBB/JASJROKQZCQTyUZyEQmiQMqQ+UgVsgJZj2xB6pF9SDNyAjmHXEZuId1IH/IceYdi
qDZqiFqijugo1B9lobFoKjoJzUWnoaXoAnQJuhatRXejjegJ9ALaiXahT9BBDGBamDFmg7lj/lg4
loBlYTmYDJuNVWLVWC3WAM9xG3YV68L6sbc4GTfAGbg7zEQ0nobz8Gn4bHwxvh7fgTfip/CreDc+
gH8g0UgWJFdSIIlDGk/KJU0nVZCqSXWkg6TTsPf2kF6RyWRjmB8/mLdMch55JnkxeSN5D/k4+TL5
AXmQQqGYUVwpwZQECpcip1RQ1lF2U45RrlB6KG80tDSsNbw0ojSyNCQa5RrVGjs1jmpc0XikMaSp
q+mgGaiZoMnXLNFcqrlNs0XzomaP5hBVj+pEDaamUvOo86hrqQ3U09Q71BdaWlq2WgFaSVoirbla
a7X2ap3V6tZ6q62v7aIdrj1RW6G9RHu79nHtW9ovaDSaIy2MlkWT05bQ6mknafdob+gGdA86h86n
z6HX0BvpV+hPdTR1HHRYOpN1SnWqdQ7oXNTp19XUddQN1+Xqztat0W3WvaE7qGeg56mXoFegt1hv
p945vV59ir6jfqQ+X3+B/lb9k/oPDDADO4NwA57BfINtBqcNegzJhk6GHMM8wyrDHw07DAeM9I28
jdKNZhjVGB0x6jLGjB2NOcZi46XG+42vG78zsTRhmQhMFpk0mFwxeW06wjTMVGBaabrHtNP0nRnD
LNIs32y52SGzu+a4uYt5kvl0803mp837RxiOCBrBG1E5Yv+IXy1QCxeLZIuZFlst2i0GLa0s2ZZS
y3WWJy37rYytwqzyrFZZHbXqszawDrEWWa+yPmb9mGHEYDHEjLWMU4wBGwubaBuFzRabDpshWyfb
NNty2z22d+2odv52OXar7FrtBuyt7cfZl9nvsv/VQdPB30HosMahzeG1o5NjhuNCx0OOvU6mThyn
UqddTnecac6hztOca52vjSSP9B+ZP3LjyEsuqIuPi9ClxuWiK+rq6ypy3eh62Y3kFuAmcat1u+Gu
7c5yL3bf5d7tYewR51Huccjj6Sj7UVmjlo9qG/WB6cMUwy/UbU99zxjPcs8Wz+deLl48rxqva6Np
o6NGzxndNPqZt6u3wHuT900fA59xPgt9Wn3+9PXzlfk2+Pb52ftl+23wu+Fv6J/ov9j/bAApYGzA
nIDDAW8DfQPlgfsD/whyD8oP2hnUO8ZpjGDMtjEPgm2DucFbgrtCGCHZId+HdIXahHJDa0Pvh9mF
8cPqwh6xRrLyWLtZT8cyx8rGHhz7OjwwfFb48Qgsgh1RGdERqR+ZFrk+8l6UbVRu1K6oAbYPeyb7
eDQpOjZ6efQNjiWHx6nnDMT4xcyKORWrHZsSuz72fpxLnCyuZRw6LmbcynF34h3iJfGHEkACJ2Fl
wt1Ep8RpiT8nkZMSk2qSHiZ7Jpclt6UYpExJ2ZnyKnVs6tLU22nOaYq01nSd9Inp9emvMyIyVmR0
jR81ftb4C5nmmaLMpixKVnpWXdbghMgJqyf0TPSZWDHx+iSnSTMmnZtsPlk8+cgUnSncKQeySdkZ
2Tuz33MTuLXcwamcqRumDvDCeWt4T/hh/FX8PkGwYIXgUU5wzoqc3tzg3JW5fcJQYbWwXxQuWi96
lhedtznvdX5C/vb8j+IM8Z4CjYLsgmaJviRfcqrQqnBG4WWpq7RC2jUtcNrqaQOyWFldEVI0qahJ
bgj/KWxXOCu+UXQXhxTXFL+Znj79wAy9GZIZ7SUuJYtKHpVGlf4wE5/Jm9laZlM2r6x7FmvWltnI
7KmzW+fYzVkwp2cue+6OedR5+fN+KWeWryh/OT9jfssCywVzFzz4hv3Nrgp6hazixsKghZu/xb8V
fduxaPSidYs+VPIrz1cxq6qr3i/mLT7/ned3a7/7uCRnScdS36WblpGXSZZdXx66fMcKvRWlKx6s
HLeycRVjVeWql6unrD5X7V29eQ11jWJN19q4tU3r7NctW/d+vXB9Z83Ymj0bLDYs2vB6I3/jlU1h
mxo2W26u2vzue9H3N7ewtzTWOtZWbyVvLd76cFv6trYf/H+orzOvq6r7c7tke9eO5B2n6v3q63da
7Fy6C92l2NW3e+LuSz9G/NjU4N6wZY/xnqq9YK9i7+N92fuu74/d33rA/0DDTw4/bThocLCyEWks
aRw4JDzU1ZTZdLk5prm1Jajl4M8eP28/bHO45ojRkaVHqUcXHP14rPTY4HHp8f4TuScetE5pvX1y
/Mlrp5JOdZyOPX32TNSZk22stmNng88ePhd4rvm8//lDF3wvNLb7tB/8xeeXgx2+HY0X/S42XQq4
1HJ5zOWjV0KvnLgacfXMNc61C53xnZevp12/eWPija6b/Ju9t8S3nv1a/OvQ7bnwel55V/du9T2L
e7X/GvmvPV2+XUe6I7rb76fcv/2A9+DJb0W/ve9Z8JD2sPqR9aP6Xq/ew31RfZceT3jc80T6ZKi/
4ne93zc8dX760x9hf7QPjB/oeSZ79vH54hdmL7a/9H7ZOpg4eO9Vwauh15VvzN7seOv/tu1dxrtH
Q9PfU96v/XPkny0fYj/c+Vjw8eO/AekI4E4KZW5kc3RyZWFtCmVuZG9iagoxMCAwIG9iagozMzE3
CmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2VkIDkgMCBSIF0KZW5kb2JqCjEyIDAgb2JqCjw8IC9M
ZW5ndGggMTMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac2aTXPaSBCG7/4V
fVunysZIfO/Nn1veihNsdNna7GEsDTCJ0GDNyA7/Pt0aRARmQGhcW8hVRoCEHrr77elX9gs8wgtc
XCsPQgVNUCE+9XCnib+9bqOLO+EMrgJoNprNpgdBCJ5v3qeHXrfV8PttCGYnF0GAp0AwhlP44O3T
SfAdboOc9RC4jreEgxXcyel9onmacH1+k7Kx3kb69ebhabjtDXztgaXhFPym1y4OqAvXGmyBKz70
ox7rwvm9I4bzOtvhIhlmM55oYJmeylQ1AC7jGFIxmWoFKVc8feURvlplqxu5ZiGIcs1VueAhx9SE
6w62CQIvHEyFglX4cF9lz995qEFLuLoeQq8PLIlATznc3wZ3EKSZ0n8o+MwnLN4ErwvXswhimMpX
oYRMFDzxmGmRTIgrB7lZplxtQtie14XrWgTx7XSq9fzPiwtNIeG8IbgeN2Q6uYhFyBPFz0Uylt8+
gUiAj8cUU5nkgYyY5iDH66B18ToWScyzZ+TAmOFF8Vq6nGcUwjDmTHGUxqvgb0SFT4oyeB/SunBt
iyRClvJxFseLM2CKrr6AiKswFc8cFjJLC+VS6aF6dSpC+iIK3oSe0itzCudyqwvXskgCK2wzWtcy
4nAtZ3OZYJdRwH/qlIWaRzBO5Wz9cJhhORRsUBfOs0hCJGGcIcxIzOaxGAtEuBrdwGdTcqCRjEJa
RDOi6hthsKgM2o2NsqsL17RIgrpE3iCW7aGkX8okJh3mJOkIqSmTMtPwxtKUJXpB1GtbTbjOwCKI
tZAQ6fYQVlsk6sL1LYJY++auT+rC9SyCcOVZO78uXGebIAL2HOc1fS1xtiNlum114doWQbjRbJxd
F65lEYSHpY4jcSqjzPSHBhz6A66zcMe3CMJHuICnM5HIWE6wO2D/+CK1Wc+qYbrDeVZB+A2K3oFA
ZWxnuPZgmyDykvEbm9E7MLHQKUqvZs21+xZBtDBql3NcuUL2LGKBbX+EOeX57F4R0h2uZxFEG+Fw
ydIylDF8fUXPQLMRVd5dluQSoQF0JyZ0XSO3stXvXEQ7r7kVV7maqu27w2211fk3buc1d48Tbzoz
Ir2i+XJFuzNqhA8918jZbXW7QXU3EpOExZTCFVW1uOG5fVc4m63uUM2xlM043ptQebHhWqY0jkRq
b8wMvjuczVZ3KWr8JeNJyOFLNnsmxKoxW8INXCNns9W9PHLhD46BIo0+cKXYhB8CCK5wLZutxnLO
1fq3xPn7MePpAu5yZexuH+XYusPZbDXB0QqRwz3xeXw4nNd0TGvLZqv7CLbZRnCsK0dm377nucLZ
TDU2gjytD1mscQlDn/eEHoZayoij59sHRu+7w9lMNcFRWrHQ0FRFRGXm4ypY5hh3OJupJjhqwkOe
5GSX4Y9EvsU8muSLfxXV4t3n5VZzKmnZTDXBmcWfn7PDwfK0tlzhbKaa4GiVuIoRLRZ0b6F6Qpdp
dYXzbaZ6QCktRqYbrpmIq6Sy/AWc76f7dlM92GzC5QtX2XeH22WqCc+4sFccTCLTkGm1EJWWMXe4
raZ6WcgEt1olzBL2F094aqa7vTXoDrfLVBMctZPS+oplGOIIsHdEp7R7rgbHt5lqCh7BUTspwZV6
8v7IuXoI32aqCW2VUrPwVxFB+RjPGc5uqg3eO0EQaEVBuMJ5dlNt4Daid5AgnOFsptrUnP9bECa1
BwnC1X15NlNdwK0EsRo4iyFlvyBc3ZdnN9UmrbS+lqbhAO9Iq5nAZoJ3zffgea4ewrOb6kGe0t/D
JvnWmC3wT9GCbncysmU78XzXMd2zm2pK7AdtNec5z2aqPwjLfExdOJupPgq4rab6H3EGaGNYjGoo
b7c/5wL/5oYeZ4636vAmAHTP1v4RYnnwv0P03+D/V5xbM3LGUzd9/NeSd/fAio/+gMeadMZUHyud
cdXHSmds9bHSGV99rHTGWP+PdI+/AN4RsZIKZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iagoxNDY0
CmVuZG9iagoxMSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMg
MTQgMCBSIC9Db250ZW50cyAxMiAwIFIgPj4KZW5kb2JqCjE0IDAgb2JqCjw8IC9Qcm9jU2V0IFsg
L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4
IDAgUgo+PiA+PgplbmRvYmoKMTYgMCBvYmoKPDwgL0xlbmd0aCAxNyAwIFIgL0ZpbHRlciAvRmxh
dGVEZWNvZGUgPj4Kc3RyZWFtCngBzZpdb9owFIbv+yvO3TqpS2PnCy7p19RpbJRmF9O0iywxNGsI
NA5r++93QpoKGEcF25oMEg4QrEfn9XvwS3iAG3iA03PJIJXggkzxKcMDFx9Z6IR4kM7gLAbXcV2X
QZwC4+37zRCFnsN7PsSzo9M4xo9APIFjMHx7fxT/hst4xXoIXMBe4OAV7uj4uqxFVYr6w0WVTOpd
pF8vhuPRrjfwtWFSpXfAXeZ3J6jCef0dcN2kpkZVOB5ZDMcCCq7v+A5qJKRMpgLiKinlLJcyn5fg
7HXnrKu8auXczhDraw4nZa4D38o8yyuR1giUFFDk5b2Eu6TM8GgKbwJqw4X9XYZo4JgDt8MrSOel
zDNRJQ2hfBNovab6cBFhCMYduP44HAEWCoafL7Yp98DUhwsJQzDPgeGyqPM0kTWMkvRe1BKu5tVj
UmWNqus12n3MueaaCwPCEAzdcCvSZZXXz3C+qe0eYA2uPpxPGSJAWQdfBgpydnXUh/MIQ6AlAgdN
8Wmel3CzFNUzjMU0l3WVC/m2U81UjhGGWMGhKVZwY7EoFOA83TXnUoYIHRik9+X8sRDZVMxEiX7o
BNtv5LrfrUGfMkTkoI4TUYkyRR33w9k8Sx+uRxgCZY2aNfdlXs2wAf8Rh6Pqw0W0IVBwdGw5UcXj
geaaCwLCEIPFQpRZ/gQD/PYfX50Hvu/DZZnOVx14L5n14XzCEIBUqOp6KzkMDZuwduU8whANHKq6
3koOhgt1ZeWEIV5lPUPC66JYYvs9cGfCI1043Bq1AWdrPwdwti1rt+/cbBj0M204v08YooHbkvVg
uJ5m5fweYYjBsr6bV/IdDLKswq26QiPmfV24iDREN7OBUTFD+K+h+p81ZwCqm0IVbmeo7iY1NarC
2RyqfZtDtU+HalOa4jyqslKh2iCaMpxHhWor4KhQbQUcFaqtgKNCtRVwVKi2Ao4O1QbxFFuJR4dq
C+CoUG0QTbnPcSpUWwFHh2qDeIprjtOh2gI4KlQbRFNfc3SoNoinKisdqi2Ao0K1QTR1WelQbRBP
UVZGh2oL4KhQbRBNWVZmc6hmNodqZnOoZjaHamZzqGY2h2q2M1R/z09A1JAU+JPr+u3yaYFXriVe
TlzUYvZLVBCebPwN4uXkH6Pmyrv3s/usYhNuM7XL8Y8lFv4G1oZqW+naVG0rXRurbaVrc7WtdG2w
/o90N38BP+/a+QplbmRzdHJlYW0KZW5kb2JqCjE3IDAgb2JqCjkwMwplbmRvYmoKMTUgMCBvYmoK
PDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDE4IDAgUiAvQ29udGVudHMg
MTYgMCBSID4+CmVuZG9iagoxOCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s
b3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2Jq
CjIwIDAgb2JqCjw8IC9MZW5ndGggMjEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh
bQp4Ac2a23IaORCG7/MUXVzZVZgw+BRnay+8sb2blPEBk4uUnQsxIxhthhGRhInffv+eAxgHJVh2
bTFVeE5i9E2ru9W/8He6pu/09oONKLbUJhvjNMJBG3+jg9YBDuIx/dWndqvdbkfUjynqlPd5d3iw
2+q826P++M3bfh9fof6QtuiVt+03/X/ptF+wPgduP6rgaA73Zutj7qTJpds5MWLoVpFennR7V6tu
4FpXmDilTjvaqxuEwu0erYCrH/pa+1C4zuEGw0X7K+CiFhGG1uhkGjul85daMNRy7TogHvvcS2Ge
fj8Q7uBoVUDg4f1UWUp0PB3L3FEibWzUQFpyqaTLfOdEjkWeUHeaORUL66inp07lI7oy2ulYZ0t8
oXCHnoC42yoC8m6bbouDnU96anKRfcWIl6EqJpNMAbeh852kYG2QqRCX0PgkFO/AExJOxmmuvk/Z
XJrEvVYJxanIc5mRvpcmlSIhNp8aTwwuIMeKTAxUptwD++xSCgqF218VEnjZqa1GMdZ5LCeO9JAa
Q21mwiQ8gCOYadKg27O/u1dfmyTIyqJNruEET00XCrfnCQkj7UTnVg0ySWDiT801nrtaIpxosmUH
U5XBkEutpE1ryFC4XU9IMJAUyPULlMJYGLK/HmgsVO7wYRvy2E5tcURjJlK5dTzosHW1hcJFnpAQ
5IyUMAviMzFiNhDxN8v9LWC5gQUKjTV8TdJMGZlJawlT30wbNK+3ULi2JyDutmRr1Gqib0y0Y+Uc
5xT4Xy6RmO/h9eDG1DtUMV+NcdcIzthNGhqJOELrR1sg3f6RJyLYLmQkeh6q0bTuOUfmsKk2TiK7
TYTjQeRoSIWRSWVs6eIWkhCuLPBC6d55QqJIHzKBkx2T1UO3Y51wkpDgjGZnRJp24pvMOSBqH3w0
6IWHzulC4Q49ITGW44E0tgkvF4Xnu1Q4yjXJH8i/sSpGGTNwxmFgxUgyLg8pXA9G1HMwPgiF2/eE
RCYFcisHRB2mS9097yQUbs8TEs/r/TetQ+F2PRHxm+6edzsUrrMqIDqIgz7nkFxnevRQZNoLjYgI
rO9C4SJPQDzPNL9pHQi3d+QJiD5C4Zt8ICT7BKVR9/NNv9Es93RxWRz3Tq8/f+ydnvD1m3+Oz8/n
B1WLOXIo3DtPQKC7y8/nVcd8tED6cNntnl6clFQApd7p0qXu8Rdg8qRbb6Fwh56AaFxe9T9eXhyf
N3gWcEu1MWd/LkaQ23h6mxjpkNsEqueqaEadl9dgvA+FmwvrJzritnf2oRNFR1z9vngLhVsprF9M
8+QBoXA+YX2cJIozh8gylCCYrebFcV7lFB7FocoxoBjDGy5XoCM7rah0N55b5lsonE9YF6VSleZW
QnR4MgUxJtIURfsohb5Z9s2FQ4TCrRTW81d+pYNQuJXCGoOD137JnLD8VoFwuz5hvfz0F56FwvmE
dSmeWcujqqORzCXKYRSbSK0oN2MWC1Uhh5qv0EJQGLNUoQ5NkfHE0uuEwvlkdT7lYpM1TaIsFhti
R0Mls8RivM+gzap8y7KLAxPA5UqEnvBbFHJiwRcK55PVdiJjBQHDqaTovjIe54tH5mM4vICdsows
S2JYcimPgDEUzierhzrL9Iz7rvMapw45nmT6QSbvF1ZZ5ygUzier1+lz7TahcD5Z/XPHXTvqP0xk
q3C9n2//6koonE9W/6qvZ98LhOv4VPUslUY+07W80KFwPlHt7SjkRiicT1RXHkY7VIh7pDIHhyvW
cioRXa+nfLom5L1PvbvtP/zgoXg+We3vKeBOKJxPVpdRubBceV7U7LJOuFSb7warxrFEEYhlR3u3
vaiW5i8SirfJwrqzUljjlc+mBhORGWtTrSP+PG2IjBfo7rEgh3kN8z2kDxegK8I81HKbLKwjn7AW
9P5PGhAmeug+q0Z58aNJWXdo00SFhFw4KOuCTOInRqsSCTcUWDzERFx+B3V8tQXaLvJJazyWK4x7
kU2LNMInRo3SOccAHOtvoXg+cb1+z2u0DIXzies1uly/SSjcJovryCeu1zfLGi1DLecT12t0uX6T
ULhNFtfRSnH9RUH2ORLZk7ny9McEK/oWKyQTV/wkQAfNpX+JqIx5e8W/Aex9rW0baLlSW7c7+CeT
J2th9YNfZR9IV4rrTaUr1fWm0pXyelPpSn29qXSlwP4f6a7/A6nBztUKZW5kc3RyZWFtCmVuZG9i
agoyMSAwIG9iagoxNjM1CmVuZG9iagoxOSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMg
MCBSIC9SZXNvdXJjZXMgMjIgMCBSIC9Db250ZW50cyAyMCAwIFIgPj4KZW5kb2JqCjIyIDAgb2Jq
Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4g
L0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoKMjQgMCBvYmoKPDwgL0xlbmd0aCAyNSAw
IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVpNc9s2EL3nV+z0UmdGcfRh2fGh
Bztxp+2M08RRDp26B4iEJDQkwQCQHf37PhAURcmE4qw9HfEQQQwJPu7u29238lf6SF/p9Vs7oMRS
n2yCrwMs+vh3cHp8ikWS0+WE+sf9fn9Ak4QGw/D//uPsdHQ8fHNCk/zF68kEt9BkRkf0zMfLF5N/
6WpSYf0RcONBDY4acC+Ofi+cNIV0r94ZMXNdSP98d33zoes/cO5amGRBw/7gZH0BF9zovAPcetPn
+uSCG54dMLjBuBtcQr9QSiQo0XkpjLK6IF1KI5w2PTLSLU2hijlNbj5fkZqRKFLSRbbya7eQdCey
pVxbnmu5/poQ7ZgLm+rwmEwi7KxKJd0eJbcvSVmSX5ciI6dbMOqLjZovmqtTXN0cTICn512kaHZ9
pgUX3FmEFBO4J1WzmTSycJRLa8Vc2p63lzI0UzJLbeXPcCKXovK0MLhN2sSoqURk1AcX3GmEFKqg
TzJxCuF2drx+CPeTC24cIQUXR+d9XHAnXaQYHg9hrYk0uSp0puerzkc+/iQX3OiQCTGIECLUqBu9
RDGjV0QXZMLaLYQjlZeZzEEVC4Ygv5RGO53oDPa+KOhBfeNarh8hBHxWIwu5TZUl6Hev3IIALpPC
OiRe2asYW2pr1RRZONcGp54L3Pg8ToiqBZiJRNrHR1f3lUzLjd90EaL7EfyzXHBnEUIE1zTGq8Ju
HU3B3z8jCTsnkoWPPV/PqlqcLwuViCo/bl6GC24cIQR2zmWqlnmP9B04cb9QaNSUQ91PpLqDq325
n8vC9wP4lujCGZ21askGG3HBncQJIZJEm9S3H1WZBzFsKRM1qy3TZuaGOwLUmBfgDtjSwOOCG8UJ
oU3FPhJpalBbn8ALLrjhIRNiECHE9TJz8B+yGUxmff1HJvatCqJfuRVaj5ny3puuQITbo7y5fI5k
XfYaj4YF03Qn53FGWL00iUTXWApVtcAl3OvB+TAEzgqHD8jAFkHhBrxOgX5q6+CiexOnxMYepUi+
SBQr7sEFdxanBBfKw/u44BppvaMkftXmXoRUEvxXlf+whGpodwao/MIgRFWJ9Aufo1PdObjgOqV1
2HvXrTTbAMYSVJgjHxf0kD072Lhp+OSQpfVJTFpvzOHrVyZW62TidBna41Y68eTNVPHFl7Gi1h5t
63HdGpPW2Hsq3b2E21reDDGXy3wqzQ+Qlwtuj7Ruv/vT1kxwo5is/kODdB+X0jT+3Ok8fLJ1vkRs
eBOyMHp3vfMuXHAxWY3tpXVimimL1hz90bJM0R3VdaF27EKVoXlC0fKdU+zggovJ6thzWOe54GKy
unLrjSyhW+qa/3231p0oqOJN3Tq44Dplddi3ZmloPlqULTTmIT6wpkuVpVUT8DDxtKARNwmP9sjq
rV54K4kg1lCkgDff1QtbmJovXMvFZHWz8XMsuOBisvpzaZ2RIu8QXuguL8Io0QoFt8K/kn5a1jf8
VE9EEQ2tlMKEN9wjrEWhUZnMVg8CaJe3L/38NYNP76SHsG4BWikvNNCtnpgLb4+0xpz3wo9b0aj7
AoqmaNFbC0WL+aJNfOldN+ybzP2qWrZDggsuJq2xd0gm8luyEMVchmxsAxbkZAG0VY/cawrxZXWN
f5Gdgwtun7RupEutEHYe+fivXHB7pPXjH/69K7ngYtL6nb4vNpx9qwuEl5XZqkeXPg5bXE03V8ZA
csEdsrQexqR1zAis80zLDTqV9ciPasoyg/CfqszL/E8OPVM18eKg44LbI6w5MLrv4YKLCetJexrt
KSBQFwR+O0Fd2BQD32h6uboeW/fQEziMJJAN0Ro0SLngYsJ6aaVXyNcafpV0kdJvOqH3kD3afLHw
+vXF+6uJrWeIGTq/hQBs9H2guKgGPQ00dts0iAlrDG6qYY5FPYVdMLu2lYn0vcRkZ4qxKyRGj6RL
jtEI+AYTuQYjqFUhcpW0gIUl13aHLK0HMWn94O2fcoJruT3S+ilwtu/lguuU1n8pH08k/M9G7ePq
W6kQjvjRs0Teg/an097Wn0TUF//9AT/S0vif9b1McEFZ94f4I5OdSdh642f5ZKIL0vpQ0QVtfajo
grg+VHRBXR8quiCv/0d0H/8DnZD1mQplbmRzdHJlYW0KZW5kb2JqCjI1IDAgb2JqCjE1ODQKZW5k
b2JqCjIzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAyNiAw
IFIgL0NvbnRlbnRzIDI0IDAgUiA+PgplbmRvYmoKMjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERG
IC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBS
Cj4+ID4+CmVuZG9iagoyOCAwIG9iago8PCAvTGVuZ3RoIDI5IDAgUiAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PgpzdHJlYW0KeAHNWl1v2zYUfe+vuI8d4KSW4zjJ3tamHTosaJp4KIYiD7RE2UxlUSUl
Z96v37mk5I/YUhsmGEyglWTZ4vH9POc63+kzfac372xEsaU+2RiXEU76+D8aHY9wEs/p7Zj6x/1+
P6JxTNHA3+fD2ejkeHA+pPH81ZvxGB+hcUqv6YXXL6/G9/R+7LA+BdxpVIOjFbhXrz/mpTS5LI8u
jUjLfUg/XV7dXO+7gdeuhIlnNOhHw+YNoeBOLvaAax76UsdQcIOzAwYXne4HV+pCZ3qqpD0m+qLK
GTlP9mheZaWKhS1JL6TJxNKSMJJiI0UpExJ5smvvUMv1m4TYjDk8fi5UXuIf9lO521LnR4mc8+ap
sDOl8x49zBSiSyy0SiyVM0nK2kqSTh/hCwQ3utiXEHh2auT3SuYllUZKMjLWeaqmlRElYJGVMqcH
tudcs9kyYa2KN6y6jS4U3FlLQhhdlSqfUmF0qWOdsXeDVyi40QEnxOi0JSF8IYtFThNJlUXowZuq
tKQfEGzacCTC1fdVHjtHOx+LfElV7tNl08yhlhu2JMQRsg/bLhDehn3rL45ox909shVnhd1E8+g8
FNxJS0J8/Xh0eaxkmR4hQdErEHVmMbhjqF9vPrw7OR1FdwjD35JEseVEli17vtoQm9tUsHPeYAwF
F7UkxI7LGNJoNIjueq6wyAXytRTfJIlkIVB1pq6EcD3RRanm6l9EQrNCwfVbEiLNtE44XWNRiInK
YB+JgEtTabDrZEm3Vx8A01IibWzUxNfDW+kjMIq2kjsQ3OlFS0I0X/pFjqHgzlsS4kVANQ8JBXe2
LyGGcMp1XX3pE1roQskHF2of6tLBDv/5FQrutCUhfn7nn3hnKLhhS0KMOe0m9xzgXOtS9HVlV80M
HZ5KTSgg+oFQEGvOQjdoetLg1q9bkEPBnRxyQgxaEkITva1UBoK2wTVqBodOli3Bl7jSzVBa2I6J
KAUYjEhTsBMYFU1vvUIth4rkBc4jPocnW8eY4Dy6WhHMKdpXsVXD1hDazwLBDS8OOCGG5y0JAbde
1WTYcdy18Rrfpmiz6BCZRlXBMZextFYYtNgqL1W2acdQy521J8QqnnLtCa+PKxdPjcu5l65xtzk9
FNxKVO/G3OZ3f955KLi9ohpQ4NY/tJM2yw3T1C7tMR3SJnEljQWG5GK41mXOxBvfJxRch6guRPxN
gvumRs9d3MXaGGkLnTu6ssZidWViiRzmyp3IWFkWQagnzQoF1yGq753laAqr5LvWc03CqOm04VDr
0GswrY6h4NpENR48l/OJNJCoBbyI3Jx7WWhkhhO4EabhfNi2516IoeDaRDXAWZQG+AfuumWVsAmw
Fj51tEFms+c1p/eq/dreynAUCO6kTVQzuFq4fPz96toLh5Oz0Z1jTld/XvpXzqM+S4kfrFBwbaL6
B9s97XYouL2ienjMGmDFMp+GZM+7Q8G1ieo9W4S/FAquTVSjZNkNuunnXGCVCpow6RE31h2S2WNV
xgn8eIWCaxPVqWaWy1JBF9LPluw2vX2MoOM6FFybqO7Y6um3QsG1iWr0ni9MdWdiweZrCAnYSMLV
d5MfOy7iPe2niWAx2ysQ3KBDVDfEDSRcZJjrJEuSthSTTNkZxx1GIn4WVcuaqcw5ADAYEJ40rBCG
gusQ1Z8raZau5kIb5HauSszAnNmyjPUYD8RyqaaziTbds8VQcHtF9eorv9BJKLg2UY2w+QvkqCZr
HHa1r5w9d32qcng8yzDrMfgMJspw/WpkFwquTVTDZpB6VZFB+DkFuEGaOMYY7q2Eo0HuYrAUXHKF
MyiDBgWyEBhmr1YouA5RXeoHYeoZvueTXvlLH+61CQHJDWCtAjG2HJVcoLdXKLg2UY2nYxNGB6PA
izFomyPANYtb3wTvi2ciV3ZOtgANThVmddsAQ8F1iGp2EyauD9p8+zEr2jbVo6tAcNEhi+qoQ1R/
rEdLdY2dSNbPbrrENl3rm7pDwN++QfBdp9xW9gu1XIeo9kWY+0OSoDTgtwhIQvweB1Wj8s1OcCML
DHb4V7GmWrvEANp6hYLrENUoW09rBA2WnWMouDZRvbPBc14IBdchqp8DZ/uzoeA6RPX2Bs+5CgXX
IaqfA2f7s6Hg9orqv1WP0DdF9qj4vv+nUMhbNNWidOMAGvW2/gyixvT1mn9tgsatVyA4r6n7A/xh
yQHOwLyoPlR0XlUfKjovqw8VndfVh4rOC+v/Ed3n/wCEfA/cCmVuZHN0cmVhbQplbmRvYmoKMjkg
MCBvYmoKMTY3NAplbmRvYmoKMjcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAv
UmVzb3VyY2VzIDMwIDAgUiAvQ29udGVudHMgMjggMCBSID4+CmVuZG9iagozMCAwIG9iago8PCAv
UHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250
IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjMyIDAgb2JqCjw8IC9MZW5ndGggMzMgMCBSIC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1aXW/bNhR976/gYzekruU4SbO3Zm2HDiia
dh6GYdgDLdE2F1lUSTpO/n3PJSVZVkQ1oYPBBFrL0QdP7se591zlG/vCvrHXv5qEpYaNmUnxNcHB
GP8n56NzHKRrdjVj49F4PE7YLGXJxJ+nj4vz09HkzZTN1i9ez2a4hc0W7CV75vXTi9l/7P3MYX0K
uLOkAscacC9efiys0IWwr95pvrB9SD+/+/T1uu8EfvaJ63TFJuNkWl8QC+70sgdc/dDn+owFN7k4
YnDJWT84xdifpSqYFqmQt7JYMs5+V7JgX0WZ358wXjDv2q9qgxhgsjClSK1hdiVYIe4sW6mytnys
5cZ1QrRjzj+UZ5kWxrCUay1Fxub32FkaVvL0Rthf6p0f8RkJ7vyyLyEesd+TLokFdxFOiJ8Z+7hg
0rJUaZgQTs7gNUUerY2qFt6Y3rfk7IxJ+pnYAx8L7nwwIfbCasUNAs9uylwgxIDasE+b3MqUG8sI
HkXmH8Ke7AGjL7HgzgIJ4TfY2Yw2htXIJjy7FdpKgzA0aqNTcULmRUZYnueGKf1s4KbhhMAeWizg
0JV4YLIPSm+5zgjyjM9zwldksKGznl1x691dwYy13OlgQuy5dS5yVSxd2JEBW/h+02pTnrDtSqI0
7KzdWDAWXBJOCDzbORLssW5ia0k4XOB7l46QNWQmUQBVYWQmtOc6R4oHWm48mBCOcdkCYYR/lR+R
kyms41xaReHuJFuLdMULadaN2XAQabmzy8GEINaXC2JgAkjORDuwVfqmvfWPj2PBvRlMiB/v+6gr
YsFdhBMCJPwZxtJbsIZjCyNzUdj8nmXSoKYRJcOWu4obBBoL7mwwIYLbPe1ELLhpICHQlbxdULth
BAjsh01JrtSNqevGtRav9tDHgjsNJwSaj0Jtc5EtxRrupMrk8oK3qIxgf0bBWAm42Zc2kEt3xYKb
HHNCJIMJga7EbMD6db0Xd9JY42upqfMCREPdSKHYYqMpg0CEVqJRbVak5aaXgwmB4mD5Ddj/sBUL
7k0gIQ5D07k7FtxFOCE6PDcSo7qRpHTsS5dMoX8pFLWnheXo+aoVC64R1Q81BJ7Mi/vh1HThl2rB
rWurriveqVEdCK5XVDfPftthk6YNptJQI+leBMrp0Ems5Y5ZVE9DohoV4q8Vail14CQeMm7BJ8oV
jLpf73R5D8Vs7YFYy4VENZ5bCi0V9d45ar3ScimLKrRcrf+yEfreMZzVvDBrEjz4TfAL4AYGXbZb
seAGRDXtVgi5XM0VuttDViS402MW1ae9ono6miDfPhZof9cQVKhEV9wIV+Fvpdg+2YixlhsW1U+G
0X9DLLiQqJ6ByEqtrEpVziCXLfLW0MwJ0gaVHuy/gKB2tR9aNSVRvbOzEda0Bz2x4EKimlg2MGyg
Ux8aMVaL6jYtd+0XCy4kqnto/8RJhlBdpa6JAF7lqLo5OqtWlYgFNyyquyaI/B4LLiSqZyG31h0H
Oj2aN6HzFBztqBYlpiro5t3EBze3VyS4SUhUtyZwvDuN8P7du8LPJho1VBe7CmEsuJCodgPWnuLp
A6sZ+lpFQwovYHdXV1Ab48WCGxDVzbMPPogFFxLVFHNdvnhMuHG2lLdd0RELLiSqdxxnMFGnCgaO
rSZwxBh7kzuc8t71g/YHXUIsuAFRfbA3mwfEgguJanJrtw9vKf9KwXT4ZDfUdISChtWvWHAhUd1+
X4OJoDF8KSqvUmM8F4grorXm1Ymf9rvmE0V4f0WCS0Kiesul41OKNHrx0FE6C63WrlplwsgldcgZ
25TGQoftzTQPslwSEtWtTHXjaPeiAZOGqBVruQFRHYWj96ZYcCFR7RIiIOwfZMNeYVXNRKwBGgsu
JKpbw9QqHVDi3dsPrjG2xsgB0YaoRKzV7wOqlJhvLFvz+wYZDmLBHbOoTkKiuv2LH3wca7kBUX0w
puYBseB6RfXfEi2khXJvtdq00/u7UqKlxHS4tGI9B7Ocn+z9GUQF559rouyLf2t0keC8ph5P8Icl
vTOw+vEHfkai86L6WNF5VX2s6LysPlZ0XlcfKzovrP9HdF++A6DpNakKZW5kc3RyZWFtCmVuZG9i
agozMyAwIG9iagoxNTUxCmVuZG9iagozMSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMg
MCBSIC9SZXNvdXJjZXMgMzQgMCBSIC9Db250ZW50cyAzMiAwIFIgPj4KZW5kb2JqCjM0IDAgb2Jq
Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4g
L0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoKMzYgMCBvYmoKPDwgL0xlbmd0aCAzNyAw
IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVrbcts2EH3XV+xj0nEUkbpY6lvi
qE06cR1LTGc6nU4HJiEJDW8BISv++y54twLQ4tbTSg8mDZDAwWIv2LP8CrfwFV5fZQ74GYwg8/Ff
B29G+NeZDWd440fw1oPRcDQaOeD54LhFv75czsZDdz4BLxq89jx8BbwNvIBn/r0ceH/D0sux9gE3
dUpwUIMbvPgQKy5jrl69k2yjTEhv3l2vPpk6sO2aSX8H7siZVA9QwY0XBnDVoM91pYJzL88YnDM1
g0slf8X8L3FyCHmw5cBgs1d7yeGXRMSw4mn4ABuZRKB2IoNVskdFsAqaKrlRZRBtnbPOQuwggpst
TAaBGLwdh7chyi4UmQI/iRUTcQZqn4Y8u8AGKXmWJnEg4i2oBGIutru7ZC/BYCtUcJcWgyg2CmEc
hNrBYSfQABFizH0l7oV6gB3L4I7zGAKusJEHGuIdN8qWCm5mMYh9LAIhNZQkZuHQOOfJjVRwU4tB
nDzxKQ9SwU1MBjEZjlFWa7FFoWmdurnn8l7wwylATM9QwY0tBmGag9xGBedYDMLT7iuViUr8JIQt
j7lkimfA4kA3+zzL8D+FNr1JwjA5aAFL9Hb6GmEn2/Lsx2o1VHAji0FU4z7LlQhuurAYRB4Ibvdc
PsArgJ9LyQVw94DCK31ZGRfQz4QchMq9S8AUgxT9I1dZvTAquLnJIIpR0W9lHHcRrwyifaiEz9Ah
b3H30ot8fzdhkgTo4VIuRRJgd4hBDR+P0GFrp12ho4K7tBuEVqgGU4IWG7IHDAVa3xhKFFEEPBTY
rnUv49CWGlr7mwobUMFNLQaBA7d2tlTxOozVql7P33lDBTc5Z4MYWwwCJfFDEf6bnc21DVgQYMxv
tL1TZkUnVXKu3SBOmPXER6jgHLtBlJLL8Bzk42mzv8Bq6ERwk4XdIOqx//UNFdzcbhAouTfo6b7u
eYySi/fRXcdJvHMBVHCXdoPonK9XJxVcnVQf5RCtPOap8HXHwyTelsf1diypF0AFZ0yqi1Hx2JHh
ORgwDMk828rjmME1swCjhBJZjk+fZo5/VHAdSXXj4EqYFzpMxXhGkgcmdUzFU0CRzpQZB+YQLSE2
EKngOpJqHVsfZ1klLC2h0iFrLPmpTnKUHsbXlGE+hCLWL9c/KjhbUo0DtySXu7o8lrd08fSASwV3
zkn12JZUo+T+99g6tiXVtb48xw1xW8e2pLqR3FFsTTa5sj+2lJZ/MS2GCu6ck+qxMakuVl+dSo6i
q8+kFIWT+97ZmEVIldw5J9VjW1Ld6Fx1kCuVLebfMAlMUsDApiVXel0dM4oku3GPtfpRJdedVFfh
tTSKeraeN0Rwri2p7jl99+NUcB1JdfeEfXqp4IxJ9RTD6CcmWYSkpSzIm6skzhSLWxxDD3RUcB1J
dY/Zn3iUCs6WVOcUWJZyX2yQA9HkK+y/J73Sx+JF0rgQ7xEjQAXXkVQ/IY4e3VRwtqR6dfPZW76E
JwpqTY1vejmcjRbjObiPRxwUpb6/nhzKVDicTYZzZzSdVoMOvKhJdeDFavnTarl+/+TQDUpHH1+d
eY3yaEAaSsd1hxNnsbCg/PCrt1z99uajphIBcxgdHJCEQyKbhZg6qIMuSahDork6TdUVHFW99c3G
5uXXqzWWU9dXxvJraw9ciGA2rbfEhRDWcDswFW1bMtFvOXr/ChGVb5nmGlhLva6BCalKvZpSFcg5
I3mpcjIVrmvycl3QI/W6u28aqZiWZAWHu2SuCXbP1rOXCs7GhJBt0Xk84vPYYjnokel4H66X6DLa
Sh6JWER7LKOKSBdZdbas01RPVwth/f7m88d3uvz2hadNeb1bdLWCO/NZW8H1v7mCf6eqg66vEhwD
u1OpKnIT2lAr0GuuAD8DQPoJqf4DFhJDTbhLvkHyc4fH5Y5f95Lsqmpjdzqm6t9FBdfB7vQHYXuD
Cq6D3bFN1b+dCq6D3ekPwvYGFVwHu2Obqn87FZyR3fldXIC2zeOa+vJbivX2DNboXXjOG88uHn2P
U+L+4xOWOWH+Z7UMIriC3Bm5+IVTc0IZnM0XTnnUO1d0Bb1zrugKfudc0RUEz7miKxie/xDd7T9N
WihwCmVuZHN0cmVhbQplbmRvYmoKMzcgMCBvYmoKMTU2NQplbmRvYmoKMzUgMCBvYmoKPDwgL1R5
cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDM4IDAgUiAvQ29udGVudHMgMzYgMCBS
ID4+CmVuZG9iagozOCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj
ZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjQxIDAg
b2JqCjw8IC9MZW5ndGggNDIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1a
a3PaRhT9zq+40y91ZmyiFwJ3msy4idMkrWM7kJl2mk5nLRZQowdZCbvpr+/ZXQRCaLFZezpoJgFk
tDp777mvI77SNX2l568Kl6KCHCoifHTxxsH/btgN8SZK6acROV3HcVwaReR6+u/ypR/6XW8Q0Cjt
PB+NcAmNJnRET3w864z+pvORwroPuJ67BEcrcJ2jd1nJRcbLk9eCTco2pJevLz5etf0B5y6YiGbk
OW5QfcEWnH/aAq5a9KlebcF5/QMG5/bawb35+RndQ5Q1d/0QhO4NQupvLtfRFP7r3qXaAiJANDh9
x68W7YzSNfXoaPTu4vzy04hO4N64oHLGKY2zOF2kVMYpJ0ZvcnHHxDjOpjRazBNOw7eXn359TTec
vvD5mq1rv6rYfTVELA5ftcZubaMBpRQEq30HlNCQrjv7RbxTRXx9Z5qvcab2VN8Eu8EmEGdcUFzS
HSsoYUVJgk8EL2Z8bCD6en97gQtP2yLecA/r07bg+oaIP3v1y71sWxN3xbFwc71HEbfndANn4NFy
zft5q/mq/Ho3i5ESGV3xrEZc/s88houJZTUf77ZcbWcDMFVmbxVMYX+gmbrF786u2hSG20msqk0X
n4YjGVRRnhXxmAsQMc5uWRKPjwkcveNJIl9LEU+noK6MVDafi3wuYlbyOnN2b8lYOMOeIYlhbRaV
cZ7hJcp1KihzGnJ90nXqN7/vvS046QlV1dcx3jmUqh76hhi/+nhuFUab6z1NGOk1G2G0X5z3va7j
un3EZOtidgVKpgzXG5waFm0pUNuBntHlLRczjjq1LFKbNNxNunWQ+85GkOOjKketQV4zhrxqgOK7
tI3pqp1ta+iqVNzwj95GPXGZ08Tmlts/7TaEOTU423nrYKKvd2rOW+1WsDlrabneoC1vhV1C+vy6
4FnE6cMiveGisAFVXWMLrm/IW9W6T/JqC65n6E3OGWq7Hog+5gvZxqUszkr8Q2mnAo0q+ruism6m
rHtMuiVIF+j0UGRXhy24wBAQcRYli7Gq3cQl0Pc5WtDrBRffKOVFwaZcdp1TnnGBsl2ACNv7qdDZ
gvMNAaFyR8q+wDwLwdFCsJKynMq7vAUmjInvVEDHdBeXM9V1LNHZgvPaAgJrFgzjxpbbZK+mYFdA
ml8psBeYWe2lshuRLTjXEBDotgr0WzBImmd5mWdxxJLkGzq0SHAmOQdHjmaYoBo7kEPVogAf0LpV
hyW44NQQEGpuyUAuwJnkImWqV8M7kJ5naCjTORNyfhMyXNBCwuXoHjdCqMJma7lgYAiIGbuVt67c
N1a3XkYCbLbfYWu5viEg9rv7Pd+2BbfSqxqd7dv8jqOrQeqSkccoidO4BJN0RqN8QjdxWZD0s+Bz
DDY8K6WpVwys47UF16pXYWENogA4weYnDMxCoH4+UmEoybUCsUSLMFCxkgIk9jAReVqDZ4vOJFhJ
BCn7R8kY87woYjnyY5ZaIOnl9C8X+ednMCsmqjyKFkLGbk4w4S3QgaAAWwdoi86kWKFYcTHhKiRX
WTWfy4Ighyw4VuLHaFfmUZ4cq0+TPEnyO+neqgFcms8W3KbEpFRS1dHlNwUXt3ys8hnMxUVKF2e/
7THGuDIV+E6PAn2PRktrNyW4p0E38N3QsOjw/HoPhB5kZMfveYbF7BB6srD5oW9Y9MOnCxrzIp5m
suwjGBpulS7fOGr7wQDYlL9rRpYSmit7YG3zpYS2NbPI6aPaeCeAWIyPHpQ3bYddVxnHgkALbw0H
YxcJE1OOTqsRezJVoUPbbM2WRGucpaFbWcOS4b5JeJNFmsUoRLnsBL+booDLJhKpK/sOKWzMUeCR
or5/+T2SRFsuG3oUT354LLxNqWwdgNW6T/Jqa7sWnaqa97D7H6V3zj68li8nJE+82DNHgKsI536P
fH2nBoUsI9Dvd0N/0DcsumeOkONH4HmGxSwRhmE3CPzAsChyxHOPLj8+wPW17ADq1LODFCBr5g1l
nPuDytqhQdFQ2WG9ZXWVdA0s0PHDXVcZs4O/Q098wA4f+BVbhu/QE8FqMNzTDPckw116uS/Bq2rg
6xs9EcGrqGlddF+CQ80LXHpSgCsGtQLU/H6YY+8h+Nq8niI45jZZe/3A20nwasvqohCSXeB2dl9j
pvemSHtgCVyriXgI3hgqHmb8B37LNvZa1cQ+GoErFn3hmGnU1K/VkvXY/EBQ1dcswXmHrCZ6rWoi
dryUHvQDGbSZkYhv5KRfmyMq+amozeLSzpgzIpgaHU912FrOpCbefNNaA55j1Z8fSXBotdTQU6A3
nsQZQKAxrh4seWDE1mELzqQmbt3gMSdswbWqif2uCwPU9MM3StuxxmcLzqQmWgNpu9AWnElNPKsb
7vPR+2v08pX+OpOPUUG+9Uw9iXkyLlYt/TZAW3gmPXH7Do84YwnONemJ76+7Z+MxBKXiV55NoT1J
EZNRIPUmWuDp9FQHasnlg2hlu2PCo4xcPWuXlq0dtuBMeiKWTjSqpU7CNFRku4gJESOFIN8oDafy
N9ytXb3lYVtwh6wnuiY9seaUx7+1tZxJTwSiLdr98EKF6drdDL9A0N6WZSKPStkrnKDzahy24Exy
YmP5x320BWdSEx+HpnG1LTiTmthY/nEfbcG1/Dysc/R7jJxVEksaTcb58kdCQ/y2jcsHsxQeb/y4
crmHP67ko7zTP6stWYLTIpXjHWanrjWqQ0WnpaNDRafVj0NFp+fzQ0WnR+v/Ed31f9mknpIKZW5k
c3RyZWFtCmVuZG9iago0MiAwIG9iagoyMDUyCmVuZG9iagozOSAwIG9iago8PCAvVHlwZSAvUGFn
ZSAvUGFyZW50IDQwIDAgUiAvUmVzb3VyY2VzIDQzIDAgUiAvQ29udGVudHMgNDEgMCBSID4+CmVu
ZG9iago0MyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv
Q3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjQ1IDAgb2JqCjw8
IC9MZW5ndGggNDYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac2aUXObOBDH
3/Mp9i3OnOsCxnbcmT6k195dM+de4/jmpnPuA8GyzRVLBMmT5tvfCoFNY0ScpW3gwWAD0o/V7mr/
wrdwBbfw8lfpQijBARniVxcPHPx0h70hHoQbeDMDp+c4jguzEFzPnNe70bDf8859mG1OXs5meAvM
ltCB77ydncz+g3ezjPUpcAM3h4Md3EnnPVcs5Uy9eJsGS1VF+tfbyfRj1Qn8bRKk4Ro8x/WLC6hw
/XEFXNHo99pT4bxRi+HcQTXc5VVvso1VFAZS/Z6KbXKxWKRMSoBIQsBhy2W04mwBEbrAiqWwjFi8
6IJYQsz4Sq3LVqdazikCouxzpmHky4n+NN39gvEiQsWU7ALjoVhEfAVqzSDIwZFMf909VQFIhBuO
qwLCNJoZrAtKwN06QhdXazTapYg4XG1Zep+Z0FChAWs3KtyoxQExHFoCAsf0WmzTkDXxtcKcVMsN
LAGB7ZJ9TmZPpWMj36hwvj0gHvpY0dXT91S4vj0gng5hu4MK51oCQvscu91ixmAftpsbTGRZdOJ8
DTeRsqa5UHAVRLzIMTktFc6xBAQ2K3M44IZu3pGMwTULVSQ4DOdn2qt0XjMT7VRscUbuwopxlgZK
8+03It5gbA8J3XMpsW1whghWbN/l8UdUuHN7SBzf+WNXUuFGVSGBg93DZKKngylL4nv4TaSboLJ6
eowrO0+FG1hC4qhOj72ICudbQuKibLh553KKEVB43TqQWSgsRRyLO+37WVEiX9lhqXh9e0jYO3vq
GSqcZwmJy+mDmsmkOr82031TS5WegArnVoWEaTcvHPOEltdtTEIYpGmEldLNvamkivHG4TZDfTDC
RDh/3OKQ8M8tIVEalOaHVMuN7AFx4HavXmdhuh9u1BNFlY5J0VTx8AIL+gcbFW4nrA91xIMeGnyl
wlUK6wYclbdS4WzCGsd0J6SeSx76NcL6wOd+tjz0bcIah8cuD009oBX2D5WHfo2wrnQf0o9En+vb
hLUe0/DLFAviKNW6WZsJboSIGeaPZRyssKr6Z8041swK5p1T93R+1gUs4mXCwghLAV0d7OssKl6N
tNbVcIp9JRHjqijMS4Xe5O/rGQThFy7uYrbAOjlSUt/Akqyax/mt2KhwNmmN7QZoF56tipSI8qkU
Lfd+CSFaUlsWbedktjt4nqZ4NeI606/FzD65+ARymyTZilOkTvPVExMeKg243ERSogLqojlDkWaP
1RSuTlyLneQaF93Q9tSBbbO47lvF9fT5F3T6NeKavKBjlqmaL+h4j0jr3RyL7pf5O8npiD7ntVla
e5XSGs2Ds8SzL+h4NdL66AUdTGuY/hJRytlm9XjvA9SBtYlrbLnIwPtOqEdUuDZLa69GWn9gX9Uf
otF7ktzUVMvVSOvjM52e8wsxlitxjk+28wIinFsjrdciAVzM1D0nAb45UuIuSBdmLWe/dK5Pb4pX
UljLVOVDKlybpbVbI613o9L4gGq5Nktrt83S2rVJ68ZDWW6AOqw10rrcfLNjKlyNtG4GVL6bClcp
rT9F+FJaQRCj0Cpv774mqGUlVneJYtnbp2H3mz9EmIv//ahfqrjO5+JeIpxR1o6HfzFp4UqYEdZt
pTPKuq10Rli3lc4o67bSGWn9E+mu/gcIfdKOCmVuZHN0cmVhbQplbmRvYmoKNDYgMCBvYmoKMTIz
NAplbmRvYmoKNDQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0MCAwIFIgL1Jlc291cmNl
cyA0NyAwIFIgL0NvbnRlbnRzIDQ1IDAgUiA+PgplbmRvYmoKNDcgMCBvYmoKPDwgL1Byb2NTZXQg
WyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQx
IDggMCBSCj4+ID4+CmVuZG9iago0OSAwIG9iago8PCAvTGVuZ3RoIDUwIDAgUiAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNW12P27YSffev4NvdAI6qD0qW+9ak6UUKpE2yLoqLm6LQ
yty1bmTJkeRu8+87Q+qDlkltNGtc2EC7lu0ZHQ5nhuQ5yhf2gX1h372uPZbWzGV1CpcevHHh/17k
RPAm3bNXG+Y6rut6bJMyz1ff459VFDh+zNlmv/huswETtrlnN+zCrxeLzf/Ym43EOgdc6LXgWA9u
cfO2aERViOblj1Vy35iQ/vrju4/vTV/AZ++SKt0x3/V49wMquGBtANc5vdRfKjh/dcXgvNAALnYY
e1vcl9U+abKyYK+SWtTPCCM1cm5XEHrOPQOH0ZQILlqbCgLu8CaBpK7KI1QG2ydZ0cB/NUuKs4gu
WVrKb7PigSXs3TFvsjSpT8qICm5lKYiPgAtvdyuaJdzzp7J6TKotfrJJ7nKBn70Xhfzgh/RzUT7m
Yvsg9qJoOhMthlRwkaUg3lfipfmuxRaAvcqT9HOe1Yi8ZltRp1V2J7YsK1izExou+ZYKLjQVBHi8
L/O8fMRI1SLFqqihSDY7UQsAMJRKLRqY7Eqwh+wvUbC6RKxNOUJHBcctBXGfpFmeNUkj2rgcZN2W
92wv6jp5ADiiEJWs5iUMpZ/1BCI7flHBBZaCOFRlCigwdNUxFxi3twU7JBWk+zFPKpjOgmX7Qy7z
THWcffKVpbsSgpsUX3WAVHCepSAqcahgDqEOVcQqVjfVMW2OMIUQJ/a4g1nsyhiH0OyyWp9xGE3/
ooJzLQXRO77EGyK4cG0qiNjxYOBDy9L6CgkrFVxsKQgSCJsRFdzKUhDQNSyhaxeEmnXx3ByhLOol
JNwW1gbZuke9jgoutBTEIWl20LBwWag1lLflsYIqxlrd6usWohla430m8m39fR9IKjh+zQURmAqi
HfKnm48v2BMb7GHPH3En9twwZGHvU9/6//mkK9NBYuU7ruet/M7pYrMftk/sppYTuWRzcHpB5MS+
H1hc0nB6nDuuH3CL00L83Tw5/iGUMGCAGHsWb0SIMQTYX9vGvSsP8+IIIXT8ILL5o4H0A9fhwapP
ovF8iy8zwuiHkD38slH0sdVw35aQxXE/L4qB6zucr23+aFEM3LUTha4tG8XfhxlRDHArFAbriyZj
EMQOD0Pb3DTZXnx60Xdew5thAJKjeH0LnMPt6zOOYgEchdaYONszrK22T3GWs1sLeaC1CbTCAseu
sQihyCeshsqVVlBzbSHbrBChVkpo5WPEVWXZrJB7GdJbGkVQ3tx7Ap+WbmgUeFBuKvtsd0J8WgpI
K2QoVEbYrCa5oRA7R8xHtW2Y5Gd9RF2uPctG5/edqMSwG3gWNkYEx9eWjc7z0IysqeBiy0Znzurs
x07s8mjN+NjbAglEYj+MgKMM46hzOso8tYtgLyEMcBzCTWCy3cJBqmZw5sTL4Wigdo6jeGmX06HT
Bhdh9cFGpB1rZOkpWH1WjpWvzjdvV8Ox8p4AHjZsCySAadkw9naRbFBOR9kwc6/Wry7tgEfeaAnb
b3vNTmGvNpGtOACGP0nyUp7xBfAT8hx0Si19a65G/kmuwqV5/TtZa7m06tdavDRbTa4UXBH1o5iq
ehsX5TJzhLM0lW8hsofdHfAfir/H46gAoqZ/TQfCXn4TRP19Ve6BbsmAPcUGkiMT+leSZ1v2cwkU
34ejqL72dJb8saRi2k70CDRb96KCmyDqK5EKIPS20zusDsDkXyo6I1M/eSfCl1RwNqae1rnG3i7S
uZTTUV3Us05H4cqJ3HUQM250RmtcQzc0OoXjkWxcaVnB+nooC6BlgE/GEvn5g3MrvhxFkYpfjvs7
0BvaxVernS4Hpid2WGXd084Fl+YehJ1LCwdaRWEfHZvVZOcKlKIymiE1AK0FlFX2kBVAdW/Z3VcZ
h3FbkxxVV7Hdj74tENbOFdgUFfCr98juNrS/07NkB2dTVGgoLFZUcDZFhdQbgrG3S/SG1uko8+ad
+ftiMDt7Zm8wO8Uzv76rkddJo62iDfLH7N1vtxt2J5C3rbMtnMlORZ/pie17QxDKk2y3A8fLb+gN
yqrvDXar6d6glK/RDKlEhXnKcEjITDe7I7DWONxffpVDbpLPIOCAClv2o1dKT9s7TnJ9OhD28rMp
X+C8PLSyW3sygtMS6GFNmZb5ya2fvqCCsylfT99xxi+o4IzKV+z4IC6NtekZaEY/JYLzjcrXyPez
L6ngbMrXBjYGZ6HrdSX9m1Za6hVQVDdHLyo4m/KlrdSoCEM7akXWbtd/spSC/qpkqFbEBvVJf1HB
2ZSv4TB0ggIrFrTqdm8FivT5IP6lw1LvqeBsypc2cf+uyuNhePpAtnj1zAGcgZQWp0lw59AYlUrz
e5VqxE+Y7kH+jBo5xZDC03MGcJ9ufhrYb8tDeYOW1O/IJcl89kQebSnv+YnW6Wgp23dP/8zA2fPt
Zpc0nL0sZ3b6gMm3ZHPCCQ/4OVHgx4qzPyOxaTB9F1hP0BXMKCnR9FeBE3EeWlwSYaKawcOVxWkn
xs4JZ8DhnBUCOWQeOg1nALpfHK5s8Zx3TA5W3OFwUL4swhiyKPI9i1OpIs4JI/dBnYKH+Cz+aGHk
AcinKzewOJ13ouAhJOQK2IZLTjTMixODWGz2eSYiTncjrVH6C00m9EHsNR8NcJOvtS2kDTqZECC1
VgtTh9a6CFr5qNeqpjJxr4VW1NIKk0jV+IQV00oMrQKcCKi4RY/wTDTFcWlpL61ikKlVFdjuhSSK
lodohRnUpqXNCu+l5Ya0imBckCpPILSeYHybgkdexU2GxJXdsyl41yAvemPNDR7al5qNKQDkz6iR
M6hd1wNurE9dVeSM/9yBPH8WQ+q0TqgoljsRPqaCm1BRCCgsJlRw1yyieGPZQxbEf7IlEw0Ik/qD
xhCVN5L1quGx/EMjJPkfLU/+LY2K3H/f49PfnvdHF0hi5BQ3D3KA8XzVOX/2XyI6Rc5fKzrFzl8r
OkWoXys6xfteKzpF/P4f0X34B9Png4sKZW5kc3RyZWFtCmVuZG9iago1MCAwIG9iagoyMjI1CmVu
ZG9iago0OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDQwIDAgUiAvUmVzb3VyY2VzIDUx
IDAgUiAvQ29udGVudHMgNDkgMCBSID4+CmVuZG9iago1MSAwIG9iago8PCAvUHJvY1NldCBbIC9Q
REYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAw
IFIKPj4gPj4KZW5kb2JqCjUzIDAgb2JqCjw8IC9MZW5ndGggNTQgMCBSIC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+CnN0cmVhbQp4Ac1b3ZPbNg5/91/Bx83M1pUoSpb7lks/7jqzaZL1TafT3HS0NjdW
a0uOJHeb//5AUh8UTcgWrWnth13RFiAQxA8gAegzeU8+k6/flD5Zl8Qj5RqGPlx48NeP5hFcrPfk
XyvizT3P88lqTXyqfhf/FlEwpzEjq/3s69UKSMjqmdyRiT+vZqvfyXcrKesY4UK/Fo60ws3u/pNV
vMh49dW3RfJc2ST96duHD+9sP8B3D0mx3hLq+ay5wVW4YGkRrmE61X9X4ejihoXzQ7tw378iZ+yk
M10az2OPRUuyMLnNhAX/dpaVDQ9BBCAJ46hhOlvtO8sjd/vjrkrXSVmdZd7J6XvePPYjhrB0k9P3
4rnnLzA5PxX58UC+AhtMS1JtOUk2m4KXJcmf5fChmQf5Qd5Zf93ZbGd10rO8eQRP8fjG6lm0dWBk
T0CDzbIwsiOP5P3M5o80rQgqMZ9aSTWV7Vkz3It5jRfTl0vNp5vsI6ggzbN78pwX5GWbgh8QylHe
4kN+BLcifnpJik1J9nBz8omXnVJIpxXblFDhoqXNi2l8J7l0FW6BeDEnLEYmtymwWDM1sFjmx2LN
LzLyR3XrifE3eh9WXWvg0SLWDVwMpYGfmOpsKOBG0alnbgLutQbaTIg4m2qIeOaO8wRXw/rGccRO
QT4TWxU3UzW5TWKqiqlpqvzziIARLuaRtwxiElmZuQWMiIF/9cIQYZod9zqSSv75yDNAF3z/xIt7
ss4LiB+HPNuk2SdS5dJv7iAQkh/zNGtNYnhhOyAx2gMSDHEgaeoQVFHYagejGtzvRoF0xsYKqRm8
P/LiCyl5VpGnL3KKbcAntbsRkUPEDO0HFVRaHciLYUXgFu4jzrjP/cqRq3DeqeO6An4mt0ngp5ga
i8v/OjjBz8rsWvhZmVbpvhfJ5DiptD1KdTzsOHn47+OKPHGAY1amG17wTc8Uhhe2g58X9eAHw0vg
J6k6+KFUg/ALlzLAGCukZgHrlIopJdkGMHYs1XTf/iSnXCV/8IykGfieZvZJBZu5BqkjFIHCL4yR
AAPM8wMv5APrTTRsrA9FXuXrfNd79PnB8Crhwi1ueBcZhjbHFc+DOSHvuIoar9d/ZPnLjm8+8T24
WH1jfV5p8g5XzTHEcV342MtucxUuQHZcK4gyqOoeeSVgUCVpVmJ36WK7CkcRQEh3VN6Tgh9gXwCr
KbYFcivwgR92X7rDU7UFN5YUnLwkqbwJ8AsOrPdxFc5HAJF0hrZp3EPJd3xdgXM5Hsqq4MmefK8O
ekJwdQjec7HXAYMFzZetiI7CsaUNEDBtpTmpkqSE0+Zul7+U3/T0cfnAVbj4hgHBFggghFo+3r0b
EcrbTW/HU09yuoXyBYXMi7+gpGZqhLJ2YzhCTl8kTSgNEJZucvqMzT0aMISpTBHdkzHqhJzpPApo
jHB0E5OKzA8qpYs26SKYR4yF04oZQxaPhQuEqTodjFNnwOAoE0aYIbmpMwjpPA4X2KrDwW6EXQYL
NmdwFkUm7ShhDFYUUR9hCifOe8QBDkvegH3GYPZ7AjBVB14xtG9vxUZVg57MQwJoaiQC1QyylyfJ
HUGlIUFQUW/ZAAN7lkgJaYYpqYQilJ1iVOJZmpkIqiAE6warkdPE56UtnaSKabOS2LMGk1asrRKd
5lflaul+ZGat8HQZ8TiaM5/B+cHOVTcrOytb5n4JavFD4UOtomb8r+pstOxE9Cnoy1+C5Vu5/XaW
lU1En4KZUB8sv88UJikqFtv8MM6BQBACY411fteHNx8cnUeXrR6N8JZV22EYwvmlU2OHEzVjg5m+
0pfXLNuIYeUpjs7j1EjF2YVR8MNWho5CRmDkTMQ1K9NxKQkaQ7VHlLrszBwlFCdxBsHcKqBQ48dX
iCPWvsaNQfgTDekid7eEcFIDfyh3p4FPUPmBJ7E4YxArcY+noUFSiYCtwIFRSZ/c7mmAue7JB5+l
mYykEil9sKAzEmrLKKmWUGxUqzokIZoQYJbieFNI0FboyksnT+cRhhXHf95C2sr1vGPOxVW4Wy6O
M7OcDcFBpln1EGv3lprjbYrjJ9ymSLPWTA1v7rJXb8vAdpZunq0tjtuZnhTHf/wwf2gK4jIV8Lqu
lq+TokghZwAVDpHzbz7DVtemWcHVif1aUw8XQ7v3En5IU4SgauvhONVgmpWperixQmoCWpomabIy
WspE5ObgnL2V9Z9+3adX6xHMhjWBeq5goCAu80eXRJ5mNfD/rtKZNewGgPiTHH5xFc5SPXb3DoHJ
bQrvUDM1bO8q72BneaV3sDM9bSsA96AaCBq38Jzy3YYgzuEMJlrvEES9IowYXuAdFFXrHXCqQe8Q
qCq/sULKiC2IVynd0TbuauFmXf6m4Keqx9At2Z2Dr4CfyW0S+FkL3OMSP23NPbAycwNek6AhdqZG
C4JAXd2F8FY2IRAFu7qJp2+mmm0OW10Hv8DTg3MAQxx+mjoEVVsDxamG4aeq/Fb4acFZm5TL5bAi
8Nhs1uVvCX5UVY8ngt8JtyngVzM1Flemny7vbW2hYufmhr+2cGFnCuknvQUI8PcWcmb/zg/9sHcG
f8NW18KPLnt7YzHE4adpQ1C1mV2cahB+VFX5jRVSEPvH4Udvucov0x7yXYEpot8Jt0ngpxoRjMUd
l7Vs3X0tocHMDX2dEVslbDuAusAGnduqz0414cnebcjKiYZuaD7RLHULheT6cyn8wl4nK4UhDj9N
HYKqjX441TD8VDeGoVQl/xOHHh/oKPgzzY8ltBHIVryXtNpCbza0DYhavXZS7Tc/NSpQ/4cVgUY/
inVj9LlfOXIVDuvGcMoMQb25/xLGJPBTTI3FHZft7uzNyuxa+FmZtvCr35eQY60BT3x9QQfe8MJ2
0Q+KDVpmiMLwEvhJqg5+KNUw/FTXjLFCyqCbBrwrzRvIhxWBwg8qbn2bvKXNp491zTjB74TbFPCr
mRqL23OZ9UtBCXnK8x1PREvlBl5pkr1ZL1sOeU7V4NzFIeF1m8/wurYG7sMbVJqBiyFu4Lg1WDqB
mgKHEf5k4OjNs5H47P/hKeHCqbLZ6VHk7APH3OAqnKU0JNMUY5599l5X4bDS0NkHjrnBVbhbLg35
WGlojGLO3uuqOcsreLO7X9J7Ar2qyQ76KvXPd7LXuySP/FDJvksS3fdeylU3//oOXsGDhoL/NbSO
wqmCg0dvE66q4HCr0qkawa1Kp1LZtyqdymXfqnQqufs3Svf+/zFoNt4KZW5kc3RyZWFtCmVuZG9i
ago1NCAwIG9iagoyNDE4CmVuZG9iago1MiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDQw
IDAgUiAvUmVzb3VyY2VzIDU1IDAgUiAvQ29udGVudHMgNTMgMCBSID4+CmVuZG9iago1NSAwIG9i
ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+
IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjU3IDAgb2JqCjw8IC9MZW5ndGggNTgg
MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1b23LbNhB911fsW50ZhyHAi6i+
5TadZsZNYqvT6TSdDC3BFluJdEjKqf++C4IXiMLSJqxpqQdLlIjlwWLPYi/wN/gM3+DV24LBqgAX
ihVeMvzg4l8WOiF+WO3gzRJcx3VdBssVMK5+l2/z0HN45MNyN3u1XOIQWN7AGZz49WK2/AveLyus
Y8AFrAYHLbjZ2c9pKfJUlC/f5fFNaUL68d3F5SfTD/jdRZyvNsBd5jc32ILzFgZwjdBTvduC4/MJ
g2OBAVzk+A7Ap1y8jFd/p9n3rVjfip1Iy8JOl7aacxtC6DZnB4EeZQkuXJgIgY9ZboRZdVeihFWW
lnGSFvDxXuQbEedrWO7vtqI4x5/yXBR3WbpO0tsGri24OUGIMoMPWZLCpbjbPsBOFEV8Kx/+fZMg
FTfxvYBrIVIocLHh+gFSkdxurrO8gOwGyk1yYAC24EKCEMpXXGZ7dCpwvS9hnUGatUqDOIV4vUYl
dWjqm+N03dz8XM0FJkKgUI0JCOQBSrlsgKos5XoLtWqvD+kCuOROZRANqvrdVnM+QYjGmkRjThDn
AuICbrLtNvte/Nh7/uClLTiPIMTgw8b+aAuOEYSQz/9y9vEFPLIrdht16DsRc4MAwlamvl9/fVSU
afefc8dlbM4bobPlrvN5cLbbb8tkFRflo8I7nMwLnYhzjxBph5P5vuNyzyeE3ubZ/u4cxqgTt38n
9HhESLSDyd3IiUiUNtrkc88Jfb9d9d4CWcKMXCfygzkx9yLb5ysxTp2eHzhhEFKGZIfTC7gTBXNq
1QvxbYRdenPf8UN3QUzaEmGEVhRyRghN97tzwtN0yKvI/e0VRuJXb48i9xlG7hrzI9gBcrZxBBFs
4YoIqTUeylGSQZKWs5ANjdJoIUdxd9GwhBolEWpWWo2SWlFGS42SGYlmM3KUF6Cpowk9glBbx2pU
xJtlpZ4lEZLZT+geRwUH2Y/uVGbGzKXzfVHo+Mx3QzBL1W3MLMrkoxeoFhZIh2qEmuXJbZLGZZZL
xj6WZXVYWYQT91z0LEaxXx8VZcLKFkgyjx0pAGcrk0rxz11n90SS2iHkmLy66AP6CGthujafnu8i
BXDaYavNnkMtk5348oLgrPHrdkIz04Q0iwjRxqV6agMJae7OtLWRo9gCg0O1VAOjQNOXHMU57pmo
vlmIBkn7CZIZgXxqVRfoQoLZVOoCQUSEpL9tRC5GxZ3GVVVfWnHAhWA+4ZA0CIiQVHd0Zj5p1MQ4
x/XDBRxJm0me21ETA0fXDaKwEdqjpk34xFyMdFjoEyLtcDKM8lw2p3BWwSi8RAvCtFVmaR8unYsm
kP5JRqqv62xyFed5grlTnc01hjhsdbxTfbX/YbRdr8TQ/qcpQo6SU6j1Qo0arBkGfrVr9lZITSCT
JYZcxGs95W/mNup9WBG04/Km7Ljk/mPyqnb060s7Cf2U0N7iPo9+RpHPpZ9RqMpeevy7qlKahnc3
idiugWAfDFtdRz/OkUgy2VX0w0vzJivDz45+1aiOfuSoYfqxaoPprZDi1mE9T6u6jaKevHlYEST9
/AWxwYwGMDTAFpyMek9GP78v7RT0q4X2FndcshvMHUx1vQjMwuyI1+ahZqGY7PZZJ77tRboSv+x3
11haVbSrCrrCXHZ+3Opa+vkYJ2j0k5c0/TR1yFEh1ipq7VCjBunnz6sNprdCylqfQ7hDe7e18Lad
N8Gw3Te283DeVrvfkbST0E9B7C1ul2XrNn7QFhCgNxJ+KDCsw4bCTbwSdZujXt7hde0MPHAPDBwv
aQOnnbGhRdmUNzZYqK8aLlWQ2rVnDs3wKVfDU6LBTblF6RtblNam2pd2ElNVQnumOq7I0rlGo7Dn
7hRGobLIotOouo7LmiZVu0+1uXAqCfbd4OLXqyU2CHumOGx1HZGwz6/vFHhJE0lThxzV7RTkqOGd
QrWSeyuk5oE92SJZY7VCJoD38TZZ9+b35MthRZD086hW8pMf/JQbbcEZW8mRE+AJgTdb7Ipuk8J4
8uMpmNp7bMFRreRW8Ck+2IKjWsnyhECnuvZIQPtV28XtHwrA7n3dkN/nzcRswZGt5OrAjuqry4MB
Sbmp/QECTcWqTO6T8gGPChTqpMBalPglQkZwIz0DTQiqlbxPkzU6IgSRpfH2HIRz6xwcXpDHBbRO
vVb6SNB93eTZrtGbdVrltW3fXlxX+UuluHPZey/uxCrBWLuqK10p0LBA2hyuvzr/0TTsG3i2y2ro
IVS1YpuDAA2Wo3dLcHzKhWxOFbK/nL1pWwtHbcF60+kKsm3ttCfvWb0SyVV37npQC+1tY61POIcx
UBnHniJnjJBqF3G03U4z1HExEQvwJBoPotMilLEEnxMyx/edGnYMk0KzC1mukscoqhI7jwbLVd0S
yVHMw3KCWjFqlDRITW3VqBC7oajFGf2swdiJT7mLwqkuyhT6T1xV5/FEb2+raGzmJO/Dhkduspyq
zo/xIW1wfyTtFHlVLZRyd3rqolUA8Jhgl/HXVa7rJlLF3Vh7DatOm9xB5iLPP9GZC63wfo9AO9+t
KhatI9cgjv04PCUanKpkT9NUGVXJtjLVI2mnMNVaaM9Ux213bc5rFma3IbfFYrPQ0SUAedT2uAww
bHUtkdjioFUqL2kiaeqQo9oSAD1qcBurznJEfm+FFL3+9xIAU5XsidJvypVsRlWyxzrOwfuH7Zv0
qsxQ9Z3M0R025aov69dpcbOcjuaM/5jye4IFCSw/bDHF11/v6+LplbgrRdWAC88P/utJ3fzHJ/xX
DAzx/2zGWtqcKia6fJq+RFUTp4pOlROnik7VE6eKThUUp4pOVRT/Q3Sf/wVEpaH4CmVuZHN0cmVh
bQplbmRvYmoKNTggMCBvYmoKMjEyMgplbmRvYmoKNTYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh
cmVudCA0MCAwIFIgL1Jlc291cmNlcyA1OSAwIFIgL0NvbnRlbnRzIDU3IDAgUiA+PgplbmRvYmoK
NTkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3
IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iago2MSAwIG9iago8PCAvTGVu
Z3RoIDYyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNWltv2zYUfvevOI/p
4Li62Y4HbECTFEOL9ZLYexjWYZAl2uYmSw4pJe1+/Q6pG62QaswEg/Rg62KRnw7Pdy6ffAc3cAev
r7gLEQcHeISHLu44+OnOJjPcifZwuQJn4jiOC6sIXK+8Lr7mM3/iXQSw2o9er1Z4C6w2cAYvvL0a
rf6GtyuJ9RRwU7cCBw240dm7NCcsJfn5NQs3uQ7pp+sPt591F/Dch5BFO/AcN6h/YAvOX2jA1YO+
1LctOG8+YHDuVANuMQH4zLI8i7IErkke0oQ/x4q2lnNqQqg+9xwgunstwc0WOkLgBKsd5XCorbcl
KWFhTjiEaSxOR4RzPHqf0RRuCsK+yQvy8JYckm/HEG3BzQ2E2OPs4ZbwMYRRlLGYplvIM8h3BLKD
AEqzlENMeMTomsSAIMW1TZYk2YP4sbrZgpsZCMFJJOdH75NGrI6hEAYTMMI4puIXYQJplkuw0nr3
IaPhOiH8xxaeLbipjhDtsC+zZwsuMBDiwMg9zQp+vssO52glhssM54iVkQ1haLxyiesr2Uaak4ro
vQkjXPuN8ly24HwDIXBosXhlJrjNCpx0DBuW7eFhRzEBiIuVX0JUMEbSHGlQUyWGL2eSHRVCW3Su
gRE4bEnDjJWklCz88gp2IYc1ISnaMCL0HsnwhM0WnWOgxBOmfPpPLMFNFwZK5CLSlQuqcTZ1vaEK
gxhBxvXKimiCNq83W3AXBkrguJuMPYRVjFN8rPIn/arXcLrftvDmZlJ0p7A/tgU31XFiMXExACv5
yR6XvNMWXDBkSvgGSrxRDYfsqNN/DGuR6DtBsIx/ItDEYR6KKM0JVgn1Zms5z0AJHD+EfZHkNAp5
DluWFYcxrIscs6lyHrMtxyTbBkCaYtYNE/ovidEzqs0WnGsgRONwVNRKjIi0kALWJDSLEW+CKSFj
dEtTLKakNbs5pQYmvi3BBQsdIXA8XKiEAM2lTY7WqsqsHau2ZlJRVfu24C4GTIhgriOECCUimLxL
79F94pYbYo0tNlvLNY31APuIQNtYo3HUUDJuixBdHMFAQysTiy7jw2/LFZYuqoFtLWdqrGPKI0yt
yMQHmu+wplOz+pczgQJbh0PIMNYUSYgFnwT18VMXmARpi87UWUfYxNCYMISHNYBSB2BZRzdKk6Ca
yLhvi07bWhtnsbxgC87UWmei95KdluwhEpJu8x3gWjPaht0mVn/D4pwTAsuyc4M5Gvhos4Tnm5pr
HDymG9nTyA5CJIEKY9XUVD0OBhh5oq1Qj3DJA1twpub68QzPOGMLztRcVwsrynVReS9J3jUQsgaV
Hmz/sRIpDpjvBHdkifKIMbbghtxc+6bmGhfxB4DbV/Ad4bTVcufexHHduQftmKqk+9d3h9IJxMLr
XO9iUQ86Wu3bdAZnTQXy3cFbnG4QTBzPDwxD2uF0RULzgplhUJ4VDBWHn+D9zWQp99+UegVKUkrt
q2NO63VSZL9aomi+vNKK7MoKeLCHCzRotSAeJLCEm5FOmlfsIe5yp7iOpXmqu3RzjYyCvq9RRAYj
6Ps9goi1uzdjvqS7l4N23J2Tu7TYw8/SjchdQdKIfCz2a8KEqNBPVrFiLQl8x5sEwQLJ2qBXedVP
AtPi+85iMps6yCztoBX6kgTH6FvHb91d56uth7sXRx6Oh9LDH/nqCF8+KQ8r7vJdp3520129r6z8
UrfqrE37CC+z128II/08k26FqbAbfADrBGzPjwTSvtKhfTBbcD26VTv4c/dswZlUq6qIuEzC6J+E
ooag1AzNSawTV6J+QJG3LiC0z2ELTqtaaWd4xklbcD2qFUbVyxOSc0NwrxnzBaNqNWiHuSmh290a
szLmZ/WdwkmG7Ded8lgzNW6JisEct8wk1yhxg8mxnlaJE6qIdyyx/lK+JRSq2+lbv73NljMpcacj
6LnDEpxrUuJUVUQE7VZgPXqh2TSkUp+Qr5g07zBtwZmUOBEN8e3Vo3apxz7mS7bgtEqceRq7K7bg
TEpcmZKrTuDXUnTg2KJW8qq2xe/2r82T2IIzKXE48J6mBQcXexQO/EAiuhFyCEpcraM10/fv2IIz
KXH9s5141RacSYg7cfr+n9uCG7IO52p1uN/pGND5w6TzHuHt1wNFWQ6d7pAT2evMxkf/nyoN+Mdn
/IsHuMGftT0tLVeKcI6H/0hrO6LRYP6RJt/VDBVdKcMNFV2pww0VXSnEDRVdKer8j+hu/gPzaJ86
CmVuZHN0cmVhbQplbmRvYmoKNjIgMCBvYmoKMTY2OAplbmRvYmoKNjAgMCBvYmoKPDwgL1R5cGUg
L1BhZ2UgL1BhcmVudCA0MCAwIFIgL1Jlc291cmNlcyA2MyAwIFIgL0NvbnRlbnRzIDYxIDAgUiA+
PgplbmRvYmoKNjMgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2Ug
PDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iago2NSAwIG9i
ago8PCAvTGVuZ3RoIDY2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNW21v
2zYQ/u5fcd+Wbqkq6s12gX7YsmzogKxN7H4YhmFQZTrRYEuuJDfpv99RlKgXk7RFG4WEILFk8fTw
+Nzp7nj5AvfwBd7c5ASiHGzIIzwl+MHG3ySwAvwQbeGXJdiWbdsElhEQh3/P/kwD13JmHiy3kzfL
JQ6B5Rqu4MLHq8nyP7hdlliHgPNJBQ4EuMnV+6SgWUKL179m4bqQIf3w693DR9kXeO0uzKIncGzi
1TeYgnPnEnC10Ev9NQXnTEcMjvhycCnAH/fW3X5TxFGYF79n6X7382qV0TyHnBZQpFA8UQirS+m6
PN3W93d1bqo5uzaINue46EcG6JrBeH6KkUXFU5zDQ7pHPgJ+ymmyipNHWIVF2MVycGYILpjLDOJA
+pkXTMFNFQbBl3WR7rOI9pYzTLqriVrkxltp9XAmpuCCERtE4GsNYkG/7GkS0T/328/ItJYlRPss
o0mBl/gdkPBbSstAXXYOU815aoPgq3QNIZJ/R6N4HdMVxAksaFTEaQJBB4DuxBScO2aDIDKDmFvE
ci30dCkq6n5Ps2/wMUsj9HHMdww/TDVnj9gg/LnCID7tkFUZjWj8lWkrhK/hJl61dblFRYaPFDmZ
dF3JjimZrlpGYag5f6YwCLSCdbrZpM/52+HL2B9hCm46YoPwfZlB4MwJ2sNvcbIq3+fMqbDFXe53
G1q9afOwiHP0LqjZh1egCiYnPNJt4lvX863ADxyQPRmu/j0qShY0u75jzfyppxCal+85eNdf0Oq8
WdcyaL9ZYBC+uJEG7S30M9iC67v1ZGawgQXcTwaF+r53aPEi1Me4q/uCVsA/ermZ3zBwrsLijz5w
yA2m4ByFxTvI2/drSFLI9yweLBlLX+K8yK8hymhYYLRaRogtQscFixzpAW5TcERj8dwfsYej8WxW
5o7JEJw3V1j8wezPuWAKbnZoEJM69/0RdJ6myqkbT8NiX+LM5uAJoe2EWuNpNOn5LLA84tlBLXSy
3DZJCVxVnubtO5Y1GVqvXnWtWQXogdjUqkkG3AMd+K3KBcv8pg3e9NDIhQc6hwCdsfopKSshnqiE
NDo+nw1C6CXZwIX22JDQl0L9PjsgLGFJOJnNoJp3T5oZYYnjIGPnaAVSiE/pDpCtu4x+jdN9/pqd
Dzj0C9twFd/3ba7iafm2lHK1pQY2ijBPz7WiGqWxV2Q4r1j1lDlgjifdqleEmuG6ipWxvxNCL8lw
LrSnRsxyhxDcnlk2maLzlAozJLiwGqlQTL8ZwZk77ubsJy0rgH5hG4a7LB5svDGeahje6IGNIlgU
rtSiGqVnOK8s9pbmxPmdfJteEWqGqyqL7MHGDBdCL8lwLrSnRvqyM2K4VNi5DJcKLeItZRSvKk8D
0DrMtbqBC55UsBlax7Utz536CqEl2p/g4cOn5e0AqC7ayMwn6DouCNV1PMv2nalC6PL93S3C1FmI
egYs6mq8A25ttL0Dnsq9A7NzIrxDOar2DhOMOzWjWmvJnuWwKhxfWtUohrClVjaKKaTSsmqU3hPx
Sn3PhHQKNPnO0BO5ukp9iJWOOMlphlsabAuB541YDmRpYV3+WOCGx7HDFBzjSrnpJwl1jz3z5O9N
wakq9axoervJsbQXW9TC32uedYftvPsa9jvcf6EQF6wqrazHmYJTVepP1sopN5qC01Tqjd9+rhB6
wbdfJbRnuqYZjFya2QtFZDByod8ng3G9TgbDTuUenHlVkcHwUSKDUY/SelWX76j0luYU1g65x5Th
0h2V6sGm8Z0rhF6S4VxoT42GGUyFsCfMkOAspGEZrlzod8pgXNLJYNiphuF1jMJH1TEKzkA1Ss9w
vvPV0+YQ9p5yryHDHdXOF3umKcMboRdkeCW0p0bDDEYu7EyGy4VeIIORCzZDKzIYudBzMxi5VDOo
IoORC71cBuPMOxkMO5V7h04Gw0fV3mGiHyUyGD5KZDDqUZ0Mho8SGYx6lNYTOXwnuWdCp3iXIfeY
eiLVTrKHcfhNmuTxCptRWMbS6mRYpxnG3NlzmLFOKNyEj6K0/MiapmSHKTjVTjJ7Rt19wjotRJef
7OHHrpmCk2y0ip2EY888+XtTcKqNVp/vZfZ62kLY0rLrqGq2E815UHbn4QrzZjzs+/n8rcFuCk61
0cokq1oDWzutCX3mbHygu803FftMwek2WhvOOdh5go0MWZjkW0xC8QepH242UDdl8aapH3JIaPz4
9DnNWi0px0rAysonbrqMN6UnYk90hPUGItmUHI21ErF/OEbNSduzGydwmU+G1krEvtQYNTfm9uyy
oDDW6iCRtmf/FV8DlkvDDb7D2sftyy7G7nGMCHYFf40F153ef37z3x+xYxCI/0891pBzvOZrO/jf
FCMkHS/6jhUdr/qOFR0v+44VHS/RjhUdLyh+R3T3/wOGNGBxCmVuZHN0cmVhbQplbmRvYmoKNjYg
MCBvYmoKMTgwOQplbmRvYmoKNjQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0MCAwIFIg
L1Jlc291cmNlcyA2NyAwIFIgL0NvbnRlbnRzIDY1IDAgUiA+PgplbmRvYmoKNjcgMCBvYmoKPDwg
L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9u
dCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iago2OSAwIG9iago8PCAvTGVuZ3RoIDcwIDAgUiAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNmllv4zYQx9/9KeatSeF6JdnxsUALbLNH
d9HsJrH6sOgWhSzTNgtZcnQkm2/foaiDsknZGRutBSTWYVE/DmfImb/8AHfwAK+uExv8BCxIfDy0
ccfC//awN8Qdfw2/umD1LMuywfXBduR18TEa9nvOeADuuvPKdfEWcBdwASfeLjvuP/DOzVlfAndl
F3BQwXUuPoYpi0OW/vQ29hapjvTL25v7W90FPHfjxf4KHMselF+gwvUnGriy0VN9UuGc0RnD2Vca
uEnP7g16AJ8iHsJdxuJneB/FT1485+GSYE6q5awyIFSfIzy/9RYi3HCiCwh80hvVbH4UJnzOYjaH
RRSLv9KKN39MXZgxyDZzL8XLXoJXgyB6Sl4ruFS40RkHxHBoCIgIPe6udxuzRx5lyW/RBngCCUsh
jcALwZvPY5YkEC0gXeGV+yjD2UcxVmOXarkrXUA0Wj7BARVuYAgId8VUr0PjpCsWlu6G3iUsGARb
pvshgZDx5WoWxYnSKSpc3xAQStPH71LhbF1A4Llylrtnm+D5WDwqnGUIiGN5GvcT4a4mhoAo5jlp
OPS4JQtZnE9ls2cRrnLlL4IU1xGM3Q3Ohiz3RemtNR8VbmwIiHzR6uZz7tOKY5aBE8tNFqTc95L0
QxxlmzfFbCJjRZ1cvBpL7lHhRoaAqEAgJ+mCRFQnNaTaeHGKAYsO2rpR4a50AdH6JMJFKtxAFxAi
Wm00x8fw0Qv4XLqQcD/O1OnrYEwqXN8QEAc/+JAvUuEcQ0Co0drFWPQZf8R1YTdUu2LR5YWJvXAO
ZaKiUFPhbENAzHniY3KJPE88XeGyDps48nGtF+nmtwtBgROICAjuZ4EXdyXU5y95BqWA5btEusHE
EBHGHO7bJfCFmq1tk+iOqXRjXUjoHnDMOSrcyBASmNGJ1KTM3AIWLtMV4FjHXDofpil1HD/jWCeM
wZT5KY9CGKGBGxsVryqsd+uIOV8sGKY/izhai6QJCsY8yazJi8PGmtZAA6DCaQvrrbaPPqTCmQpr
ObAxA/adJ2kCnlogutkmYCJilRUNc02lhMzXvapTVLiWwjr1ZgHrQpLh0u81KqrqqQfuUOG0hfWB
zzz4a1S4lsL6R4D3l7BHI6plq5HTs2x75MCgalNVr/7e25ROCxPVq+2MJ2WjHXddRy5cJFEW+wx+
hk/3dVI3zU+WWd1+C9amyxW76ykqcNNrrWKn9NGBNYwRueiyAwFM4a7zIp2vr1EOzkbn67coB1TX
qNs8oWsUjW67BnvY63G189qW1RvbwwHoG6M5r22N0T9GQ0OjYbaGX4TnTtlDxkKffc7WM7OMsevI
tePqvK7y1f5orPqqOMx9dcfDO6hJK4YQd4kuFHYx3dWqZPelwrM1NrtdOe5MuyGMMntfq/CI4mJL
DPggC1qRibx8o8KZFJ6XE7TcQYUzKTxqcVHVC7UesFP8V+WHIjBXuFQ4rcKDrXrzR4aFQ15LeHBA
7T1jQRQuUUKLsNgsulbSUeFMCo9GPfF8P5JCO4p2VSqcV0Z5gipVYlEZYWGSsjCtKhAinGNSeMpO
n+STCmdSeIRYfN8r1vvfZWGBlWshF+/J5PGLjY0KZ1J4sHHUmIQ6veZhloDdFfp+smE+X4jKByOi
HtkGieaACnfOCo+jVXiw83JYqyjdluqK4TWqeeIlS71RLdei8FQFq3wthqEqdc38zRgGbF7y5NPa
PkWZCmdSeOpun2CPCmdSeOSwNnP0OlpxOJuXxDBuWVrpFBHONgk82PQR46iAiV0q3DnrO3aLvrOb
yTbHtZnltg0s1XIt6s7/P6znrO7YJnVny6WPO6QOa4u6cxyQejcV7pzVHbtSYmrRpHPxlXcBX6V7
wdYLpXffNxyXMMxHNinLK9Fht/GbHGmuP2+9JcNfMf1VWo9oOal9WA7+ykmlK1s91SeRToof50on
q+pzpZNl9bnSybr6XOlkYf0f0t39C04kNQUKZW5kc3RyZWFtCmVuZG9iago3MCAwIG9iagoxNDc4
CmVuZG9iago2OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDQwIDAgUiAvUmVzb3VyY2Vz
IDcxIDAgUiAvQ29udGVudHMgNjkgMCBSID4+CmVuZG9iago3MSAwIG9iago8PCAvUHJvY1NldCBb
IC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEg
OCAwIFIKPj4gPj4KZW5kb2JqCjc0IDAgb2JqCjw8IC9MZW5ndGggNzUgMCBSIC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1bbW/bNhD+7l9xyKdkdV29Wy7QAVmbdC2WtondD8M6DKpD
N+psyZHkJv33O4qi3krS8cUdbCCRJYunh8eHx3uhbuESbuHZy9yGeQ4W5HM8tfGLhf/tYBTgl/kK
fpuBNbIsy4bZHGxH/M4P48AdOaEHs9Xg2WyGTWC2gGPY8+dkMPsKZ7MS6y7gfLsCBzW4wfGbpGBZ
woqnr7JoUaiQvn91cfVB9QNeu4iy+Q04lu3JG6jg3IkCnBS6ryMVnDM+YHC2rwaXAry9Gr1j98Xv
6fr0+jpjeQ5xDjkroEihuGEQVVfTRXkacy4sojmD6kKjd6rmLDkh2pwTYgWvrtINPnQIdzcxMqnI
oiRfxUXBrktEb9M4gcsNy77DCuFHX1gDqflGBBdMVBOiEbufb1RwY9WEwGsjd4QDy/VyxdbL7/Ah
S+eomjj5QsBLBRcc8IQIfM2E+LhOE8jYnMXfuLYi+BYt4+uWLocQJdCmJay5ctl1DlHe0y5Vc55m
QizS5TK9y5/3HkM7pYJzD3lC2KoJgfqxcT68WahtHY5nx8ah+WuP74/apmrOOuAJ4U80E4KTi2vv
PE6EuT1Ps7sou+azY7ZZLxl8Or5hyZwt0qy4wcW+mN/w31q3tfhJVJ0famaEFF0i+XQC+YYvEDdR
8eOoyVsNRyq68QFPCd/XTAmphyc4tiewxVtsHFjbCkeWPQ6gEjyYrZplG47/2SpK5RXb3D+xw1Aj
dLVZFvE8youtwls4Q3yQM3E1Iok4Q5zCruVrhH7J0s0aXnAzcyEhv+bXpGcldd45Vp0aXIqg4uUU
g4TpS2VQ0VJ+CCuwMdyoxiKEJUwV3v4AQxG7UUXZKsQRFJrRtTIGML5X2rHewHe6tIcT6lx0DXaM
wyLTXQju9ZpIo5ruSqGPo7tSJBFnTXel0DzdZBgHdPk+LS8aCN/QXRU2Nwx3vQ7D8VTNcOTqoGG4
aFUz3NRKH6L7Trnc9MZ6D6TuiKAy3DasNo7wc5K0WgnLBZrdx3mRDyFOcpYVeCjDptYCPYs+4zoe
QcLuJEIiOG+yZbVpP7UER1mxqeA4ncvMS7NiDQ4l8+KNf5LhqgT3yEw0CNJwqYU+ynCpRRJxSsOl
FvrYddpouLxxx3Dx0wcYrqqVNFzGVnrD5YncYm+s5Zze15E6/ZS5xRYo6tLsCcG9XhOZUzNcKfRx
DFeKJOKsGa4U+lOXZs+32kszP30Iw0WrmuGmVgaGixxwb6xbJNrLVyrDt+WAyQwXgnu9JjKnZrhS
aM5ud4my3GAUOo4LnlIYEaHnYYCCrptaaLJZCZ9zym43PPPwbrP6zLIHDbx5YGvn03OCDsPxVM3w
MrxqdFC2QvSVSnStjOGVx8cn9Hpj/aDe7XCTWRHa4pVnyNWXTyczXAju9ZrIn5rhSqHsfk1iuFIY
EWHNcKXQIl7xsGq+yTKW7JL0cDj33EkI1TjtRZ2O74wsz9bILLE+gfPXO+jUxbxF6NuBRiRNp66D
VsN3xhqhszcXZ+8/zkxTRN+DcprLxJdnOR3jgKdq48CnuV0bB9GqMg4DLkTfqjWO/Fl8BKph1bXi
CFtq5a24Qiot61oZDZErSl89DpkUSPmNaIhcZemrBeAU09W8iokx7dOvGS9mzq4+nrVueMhXKrhD
Ln25utIXVwivG54tczYsUwTfoiwuUwNHQotHrdJwqc14odMiVXO60pd8DqZWe8v+rzulrzF7O/Lc
sQ+ueFKP3TTT47jjUeCGY43Q3VwqhyfsPcfRCCMiDIKR56FLpe42ulS8rokFnhTOT/+YnkGKpf/s
Ls4ZEmKG9Z2hHACzkWyptzRcbii1bTJBrS6Xrfj0QQ0MXM/USuukuNtKlHxbwzpjT8vEGC9WqapW
oriFxcDN+jriew165V0qw3UlSqngvRR5qeAOuUTpmEqUXHtU37MSvBdTUFey1EJ3MwW186AWRjMF
tvQ91UJ5dPW8TOn37Kzkp+FoZl0dXTmTToaMn6pdoU50VbWqHCjQtzI6NY6oJPfG2tAn0k9mRWgN
l7OtkExmuBDc6zWRPzK6qtD2hBKjK7UwIsKa4cpulxELUpwQXlWR0D7B1mufWigpvJKRkFokTanl
ouq7E1AL3R5emR2HxjiMO8lFB0/VxqETXfHbMNiS0ZW5lQxoRSMnwI0CGN7q25SxVaNT/iTXxZiY
B5v6VmYzJHZl9OYOydYYGlHNkCjw4w5lRZ3MqyqMIqx6IaKqNAMMBdA3P53/e4VZuThDf0luI0Vn
q7UVsYZLBSdK0WpwXDg+dp4meXzNOAjclcT/qh1LiP29dGyxHoq10ByStBBb+PIc768+VHCicKwH
t9jgJimWIY5HfKjgTIXjR8DpNiWCs3WFY17RFhHpQu5Aq/fWAN8Y3GxEqwrb8uIUo//ehwrOVDju
bH87qiMJDcijTydDUZuPftzHSYW3rXTc0wLtlAquft1BYUx+AbjSrwuVBW32dPGcj+2EE3zNQu4H
bL9DQVvYQoyMbc8KpNCeTW5X0rbubdFo1qy6Vq949Mu5VnVSF/3yBUnrRNqiINixQQfzfol9yK9w
2NvKd5rh3e2ymQz6YRVloc6wHszmFVuUMXrg/oyHgDY4WvaWu7P7NToIOUzZumBl6S4Ydt4PEgr9
6wN/lcMe/y31S9ScSGNjvl3pz0jhjz4S0Yk89qGiE4nsQ0UnMtmHik4kmA8VnciR/o/oLv8DB7xY
lwplbmRzdHJlYW0KZW5kb2JqCjc1IDAgb2JqCjIwMzMKZW5kb2JqCjcyIDAgb2JqCjw8IC9UeXBl
IC9QYWdlIC9QYXJlbnQgNzMgMCBSIC9SZXNvdXJjZXMgNzYgMCBSIC9Db250ZW50cyA3NCAwIFIg
Pj4KZW5kb2JqCjc2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl
IDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoKNzggMCBv
YmoKPDwgL0xlbmd0aCA3OSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVtt
b9s2EP7uX3HYp3RNXL1bHtYPWZoN6ZAmTVxgwzoMqs0k2mzJkeSm/fc7inr3kbIYt7CBNpLiOz08
Przj3TGP8B4e4dVZasI8BQPSOd6aeGHg/6Y39vBivoJfZmCMDcMwYTYH0xK/5z8mnj22fAdmq9Gr
2QxFYHYHR7Dnz4vR7F84n+VYh4BzzQIcVOBGRxdRxpKIZSdvkuAuo5Bevbm8uaZ+gc8ug2T+AJZh
OuUXdMHZUwJcqXRfP3XBWZMDBme6cnA/Aty8gB661Aye4CSYlj+FSaW0SeR/elVRy8L3xo7pGF6p
dDRb1QSEo5Q99qqtEZqGPzbMiUyZHkKTj9b0fQnCaLOCn1/D25vxLXvcsGjO3m1Wn1iyKytr1uWe
5ewWPcXtGelZGhPgwAp85F0xHw4s4Rbejyh/1DAKlzLRUxU2KqSod43kXswovVhznnYd7a7fq61C
DUkKzptSXqx46cUdrBP2OYw36clDvD4JFouEpSm8HrQKLMcZ+/bUh+JdHcLqccxyrbHhmBKdEfuS
DVgFlm+MfcedSLRpIvRxaTneVKIU7XkM2QOLflLPsHwYIwydDdsaSFVulcLUhiA4RVVojDeXQqR8
+CNvqpKSc4gvszxM1wQfHUqY9jxFsLHHAEhynAa4ZtEijO7hdP5fFD8t2eKerViUwS3LYB5HWRBG
KQTV12ab9ZLVM6e7+lxFsOHaPx4hQ+bsLk6yB/jhMsjmDxxkCTZH8cPHF5BucN8QpDIu6cJztj3X
4UysrfBc3HYvAa7lq6fYeBKh0BOK9+KmqlBIK11tllk4D9IhzspEZ2VYUxtolXrOyuSh0TZcidL7
JN6s0e1jzL4sIZ8WwYCbmv4Uxh/xJGB7Y11FWc/mTqiKsvw2j82U1Kgx+lyKO1lhDIWUPMPwzNx1
deaaHo7+U93lZyhcF0ejzXChuDNqTeaUmz2PVPo8hpMqNXFWDCeVpvEmmTNB8dv8up/fALsyHHfr
TYbj7S4MF1IVw1VScoa70zzEdOZan8u0pCbDXb8nwOgyvFDcGbUmc0qG00oHJly2N/YtywZamSZC
3GEblu1IlPKESzffUk9s5cNd32oynN/SDOebVrO2QS7F8wNhEpmUskrkTvKNQGeuaZ7qP1UbQro3
dt2evbE2w4Xizqg1+VMxnFQ6MJsyKzaS2jQh8mqb5XhQGLQzbsymkOJksto35eqJrRnu+i2G462C
4bUJcimerObrUyqlZriTbwQ6Y+4b2NDfqw0hZ7jdk8PMMLuiMxe4/HA7g08MNutFkLEFZjBwFy+X
8dNWJqMLzuoJMEONRH5fF5z5jTIYVyju8EVz4VW+gVQa1OnyAlfg7ObDOWki2UO16erVZ7ZyBBdv
5atPSlVnuu2MD6af4PANqqqKohspCsX7ZQOtlH1ZD8m4y30ArUyTr6XrpZVm4Yrv8s//uL64OX8j
YyX9fEeuOn5rt89v5Vyt9kKFVLkXkkspI4UzOeDdvlO18yR1Qh4p3sZhBDdsvfwKYQpRnGFUj+dY
dcbwcLfBMhhLjiGIFoBfWwcJlk82y6DZO1DPktw3kO28BhHyWPXuKo9XWBBMwwVLOKY44f+egiQv
HzYEqEtdcIfcznNU7TwHK6zny5QdQ1jUWRN2QtVYFzET010UW3GOvzYtqGs5Hr5UXvXqM0seGM4e
iJJuTyW1Cam+1gVHdIYOpr5qqzpDfOgYj66GePuy1Vgo3m88opU+q/pEq9SMSmX1iVZK1Vd/4zVX
ZRFqx+qTjV2dRvWJ39LxCCNLXV8tpMrqk1JKXn2yRWuoM9f1wtnPlebys1WtoWcxXCjujFqTOeX+
u0DbUfo8hu8TZ8VwUuk3ra/aXmvHxW93YbiQqhiuklIwXLTwOtOyH17XWnQZ3tfA0/bhQnFn1M9l
OKlUs75qk8o0EZY5Ba30O9RXbadVX+W3NMNb9dVCqswp5FLKnMIm+6E1N/dzpctw0cDDI4KSnEKb
4WRnUJM/lQ8nlcZJeB9GQYaZhFYNU226qoZim60KJr+Vc0iaJ9mifdYy+MHUUCzR7GqBa22oL6KU
JRme48jy8xtPIR6rwJQyZXAXsuUiFamlYlvL1xfapj42YHvYjncxx6feDUcKwhSqqDN+eax38cgU
rVRZZtlGiBHO92xbokwT4RQPxXmOK1FalFm2XYOaqw1j8pN3tofdfWFb2ck7Plq7HmAuhdCK8cqk
lP7OEk3JTmxrDGW+SRI8GjQk97GmY88yTTx5ldejO7oVU6BAWpWOaKX5FLyE65vzAUAtTNJ8bCTS
KvVwWvz8pO1aEqWnZ78PAWhPxp7tTyTKNBHyCMlPKNLDnl1cnl99mPGKE/oKuCYqGA12yAfDuWrW
TMgjOh+OIIYsonMG1NPChbhBcZJGlrTLmsvUlsqFHLc0nOxNCodkgCW6rC3X2vL7eFBuDEMreA27
5Zdq9yANSlZfl7VRKdSv4+mCE927luVaQalrBK17XXCy7h0/GikKd5zz7apsGi7R/2GFdhGmcyyd
YRmUR9J4k5Ul2s4QdMGpundFWZgfh3zeRxdcX/fueagKaU1wJtHpGh1h92vMC7KN2fx159I1MRxd
cH2dLuJVwx/pghMdlO3Vetow2zE/Ekx3AI53amrrguvroAw3EyGhC66vg0K8avgjXXCH3EExVR2U
4SaSSOharq+DInndsMe64MgOyp/hMeCx/WCJvq75Of+yDvEPWPBM/zpj+Z8cecetv7YTX/7rOrhn
YPp/l7Ka4EQDxbC2fUmpeC8/NdGJyvyhohNF5ENFJ2q+h4pOVD4PFZ2oJn5HdO//B+KN8VgKZW5k
c3RyZWFtCmVuZG9iago3OSAwIG9iagoyMTEwCmVuZG9iago3NyAwIG9iago8PCAvVHlwZSAvUGFn
ZSAvUGFyZW50IDczIDAgUiAvUmVzb3VyY2VzIDgwIDAgUiAvQ29udGVudHMgNzggMCBSID4+CmVu
ZG9iago4MCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv
Q3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjgyIDAgb2JqCjw8
IC9MZW5ndGggODMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1a35ObNhB+
91+xk5de2osDAgPONA9pfrTJTH6d/dJpOh0Oy2dSG3yAc8l/35UEGHMShj1PxzycbQ6tPq0+rVbf
cguf4RaevsxtiHKwII/wp41fLPxre2MPv0Qb+G0O1tiyLBvmEdhM/V98+J4zZoEL883o6XyOTWC+
hAs48fV4NP8Kr+cS6xBwE7sEBzW40cXbpOBZwosnr7JwWeiQfnz1/uqT7h94732YRStglu1WD1DB
OVMNuMroqT6p4Jh/xuDsiR5cCvAmThZQrDjOUxGt4uQGrtJdIT7nu+2aX0K+w+krVmHx7IiLqZ6z
qgXR5NyRvgb/mwjOm+oWhOr9Z4Crx3Bkne2Xvs/Glm37DPY2mxHgn6OmdPHExyVhs2BaGR3NN3sv
wkWe7rKIw3N4dzV+v1sXcRTmxUzefLFYZDzPezhy7zoZ9V7OMIrNXmqjXmOMFmwgQMjlkC1Ywww+
jwbFSk8MT8bK5qB6QB70yH58w8B55hVPpkZt85TUUEbb1OC3Rxm3J69tWePA9lzwtMZo5LWtAPnh
ewajyW6jmDvjtzueRPzDbnPNs/5z2z2xe6563gFX8afk6j2Gj3BfbzhCtBJDKP1iatWZDXgTGZlb
c9N/iP2e7HaEMVXxXENkxm1jxgsRVD7w78Uf6RaKdFAstEVkYFMHyi5a4yfSKcAF6VgTg9EEoQ5g
PMNcznImGK6VF04CkTH0qOOZxr1CTw66GuMZ3U/zGl5mgqsBLjfldGZguOBqNfCR54pWjLmVH7pa
mUnkyB205b5Bo+zxMJXh9v0NZiSS8TkmRO/SOIErvl3/gDgXKVICRRYm+SYuCr6AMIrSbCESJST/
jEdFnCaA5saTNl4qOMu8wbS7oP8mgptMdSmlHP4Ymq6bK5fluXDP0IsKLjAErqH9dz5PBecbUsoX
TbcJxjXIhhQL12tIlxAmoE5bIk3n2U85JDy+WV2nWX4JSNjyooKbGBYEUh23XgEDDwn8G4fiLoX0
+qvg/TeeHzsbVLDUJxWce84LwtEtCBxvuVnutpBmkPElZt3iPMUBwwd+36aJDCJv0uwuVPFEHrxg
iY+Lxw4uqufEvtNKpGWcQ+O7rei3JFXFpYNO+/6ggrMNC6Jvv72eI4Jzp6YFAfB2KSeosU/chbgc
0wJnOr6Jk1BsE9c/8CFczZlcrpe4fv5N0rs1X9w0ppYKTmQ8hmmNC+yTR3wr9yVcuIJL24x/i9Nd
DphpYJjud1HB+YYF0a/Xnk9RwdUq3P5kqTZ+4SicLp4scK5aEXm3Xcg5xTArvLlM1+v0TmQAd+EP
9G0sViwu9/qigtOqcGj1mst0Y78vDAu7NS75hQrunFU416TC2cj2Wuk6ELjEnikms7opDjZfLjDZ
izhG4GIFj2phrPYf1XUmGU4YrvqXwf/Rl8el8BYO3FrREhXdOetwTocOB0PVFozoUjPbG3242hJ4
Y9d2LQ9Ko63zTlOIG6q/VbTrntdaCXSmUnrDnaEcZCm9aeUM47HNOWfpzallslb0Fq4is6E2eko2
aOWyfKD2Vspk5bBb1CKKJSIWoSIAeqNCe/tVysY08a0vV5X0VnP1iPRW+0FKb0KgEeqhY2zVKb05
5yy9OSbpjeFGhnlnkpZ1GVGjAf49zgs8/uE+pjazRkqKuYzISLdZGqHcjwlp4+qeJXNsUJIOljA1
y2+5w00Tj4ohlpWw7zxe86RACWUR5xGeMw4BNLDc+0oFZ5J07nXwkBtUcCZJx8Fpfb3OsdwmcpHD
6auyTjxbqIzzWEpABMe0ks5DvKRrSwXXJelgyN9r0VVh69nzQZI0Ksdj1/EnwFRPJ4myzPHHnhP4
BqNDJWkPkwzXcQ3WaBsB852x57qmcQtJepmlG8nLOhOuktXmBDe06Nb7EKJu0nCvVJWdoPJ2l6rM
9iOWrXxXOmDEgq5WxsDFTNJbOQ4lvDQHRflOZbhJeqNgMLahguuS3nD5lVLIp4w/aQgcGwz9slIU
pUkRxkmOJ+qi460CKjiT9Gb0AuUfVHAd0puA8QvAR/PSKTMYTSFWlpIC9yRhqi7E6o1uqjcHhuDE
8mrAAhvrR1J6PA3OqmyoN3qTpaiyHr7s8Lu4V20J+mkXoxoZ35WqC76MySJaVfAVPzvKxPvhy1YI
vPSGqVVnrsqURNpyon449LtEhtsmibREQmV4abc1aNouVzNcb/RBDNebJOKsGK43SpQRejLcngbN
VxrEzx4ML1tVDDe36mS4raTs1mTTuaxvSWX4ESmbzHBltzVoInOql2lsrdGBkgObjj0MOqA3RkTo
eBgEmWMw+qDXfbonto7htu8eMBx/djB87wTZSuTyyiemVt0MVyWH1mTreUq/2+0IY2Zsm0oOdCSa
llRw51xysE0lB8346beonuuqONDRtFpSwWkLDn/Gl4AlmHDdqk++/r6NsVyOx4ltweV7gN7lwVvl
CtRfn0IsrNrTvyuMRHCq3mAxvchVGX/wJxGdEufPFZ3SvM8VnZJ9zxWd0n3PFZ0Sfv9HdJ//A9fi
FuIKZW5kc3RyZWFtCmVuZG9iago4MyAwIG9iagoxODkzCmVuZG9iago4MSAwIG9iago8PCAvVHlw
ZSAvUGFnZSAvUGFyZW50IDczIDAgUiAvUmVzb3VyY2VzIDg0IDAgUiAvQ29udGVudHMgODIgMCBS
ID4+CmVuZG9iago4NCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj
ZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjg2IDAg
b2JqCjw8IC9MZW5ndGggODcgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1b
bXPbuBH+rl+Bj7mewyMJEqQ6cx9cR2l8jWNHUvoynU6HkRCbrUQ6JHW5/PsuAL4LgKSVryPNJCJo
7fLZxYMFsAt+JR/JV/LTTemRVUlcUq6g6cGFC/97zGFwsdqSPy2J67iu65Hlini++rv4ihh1/Dgg
y+3kp+USRMjyC3lFXvjzw2T5HzJbSqyngAu9GhxpwU1e3WYVLzJevX5TJF8qHdL7N3fzB90f4N5d
UqyeiO96QfMDLDg61YBrlL7UNxacH10wOC+0gvuRkPsfyAHGdCT2XNeJPRaQSOmdLLcdXcirfx9U
pRsZnhs7rhcxg9K8SB/TLKnygvxMfpk7H/hv1bv8+Xq9LnhZHtH5Xb/KsXuzgLG4uNGO3Z59AdkS
gaw2NyAbsiAfJ6eNeLcZ8X0vHQH5pJ909p0Ejk11I7578vKJZ2S14UlBqicuPH+9+u+cf92lBV+T
L5vk8Yok2ZqUvLJxaKJCYschOmWOy4KQ6ABYOVSr0nEoEJ5mITMo5b89m6m5hzDwAycGdAZlFpbb
EFLfcSOXGpRW6ZaTKu/cD1f2ju350QWuBm7QuNVVXN1juEDXs01KAaraVJOUdU5jkYzMozjQWTH7
+8PtfPamu4G6sjvCOOEydsGRmYWWyPwHQmabkl+R9IscfA88W6fZI4ERmOXfNnz9yLc8q8gCxt4q
z6okzUqSkOZnnZOxngv2A9ekt1RZ7p43nJQ7mN6T8o/d4067woKj9sB1GgjTr7HgPPtSBSbcB3Mo
qsdaFyzbCYkpvaOBZglFlmHbTrh6pdvdpkpXSVmdgjOCOOLHEDJfEmcMod6fQsjUKn0s8t2zWhPc
NZD/LO7ZlwbCqolxgdxzeNxfATAvtkRVrzNfSgHw2hsmKUv3uIS5MnCNOtvEVOx9JMPDqSVwARYs
w2u9I6PPZLhe6VkM16tE4mwYrlda5rtixRXFF/LaTu2aCUcyPJwO1riiKde42nVDy/BaqmG4WcrK
8DCWE8yos7FMNslhGR7ZJxg0w5XekdFI5jSbplCrtORfT4ne/tRhvucRvTIkQsogCPrUoDTbbWti
w5aCZyv+Ybf9zAtTVw7v2zu2jeFhJNa47S5ONC0M75wgpWjU+MQkZWd4aF8ZDw3CtuyOMK6Mw8C+
MkYzXOl9YYZrlWaQBjiF4i0btdqQFA9gz+XTgNT+HNn9lNfLk5NTFof2fh3DAzZgODQtDO98IKUA
vRqgRik7w6lcCIyMxjLZJIdluH9gByOyGyJ1McxrqJRGmq0KnpTctlTfyxrQEJbAYQRk0Dwam9eg
DJbAYcwMSrPqyTwG9hHGnsMgzhuUWcaAJa9BY8iRMQphXmu2zGt8/g7J7vHH3rE9b/rAcOGH2rm+
heG0s1BKxTCvKYNNUnaGe3IhcJkMD6aWnSYkEN5C0nSz+S5zCBlPIYenEnkPBX+daPIIGSRYRaJv
+LH3knGCCWL7BNNkKiwJDchnrPICcrzPuUp+VCLpMEg2YMFF9h3M0APYFhZcWyXqcsb91IvnEHKb
lbyoegkflY9Js0PJoqvGGCw4bZWoUaq+z80KHZr7zJy75CpRcESV6PWJuaFmwVrrHoUpSzi3BD2v
WSPolWJ2zlAAdBj1Y8g969IaOJy+KM3AykuvE5EaaudRbYnH63wtl07N5iDwTQsu8PGkZ7mQ8l2Y
jpQjLFLmAnKgLboNR9/5LWxo0NS6+nFLAEMTXOl+YYJrlZ5HcK3KMwmu1YnIDB1LcFesnLyW4NDU
7yiGBJdSHcFtUmaCU1WSHPXz+ZQeakASnKpSFxzf0E/M5xC81j0yHEecNoLrlZ6YGQpjJ/DDmOiV
IRGyEFIrkUEnOjEkCG5J7DcRnEYyRd8QXDT1BBebHq+zX0ox1rjDJGWZW13YxuhmwCE9z29hCW6r
SNaosBGcKt0vTHCt0lMTQw0ZtcqQBG/KQXqzsXmhYwkeyrx+S3BoWgjemi+FIqpGplHGTm9VNh71
8vmEHmrA0vuIsjGa3kr3yHAkeZoVONUqtaZ86t7p1Y/b+KVVhkTYcEarU2Z8ftYkfIa9uN86lt50
kJ6n0LTQu7NfSrXx2yhlJ7i2EL1vynl3sARXVePfZ4GirUgj6dMSXKu0l5taQ4Xo7fX7xexof9pd
1+7iqDvYxYmmmUPGhIOvqYRfzIFeX1VYfxc21LpfNtzplcLJvbRIqjTP2v3LXn16L+o1yQG9Shxr
fTjh7UJWmuiV1lFvtYOMZXZKYYqC3jj0mEEvDiyFE4xuCEtsC9gfyfXNX05wanveUK8TB7Q9t6lX
ury9m91/Wu4NfzvsZphP/HiwlxVN/TAXDOpII4REd4v8Ui0zEUf/94/T9zpP1hvEwVHVl5YnTXqe
FFLtyU07PnMY0p4A2PPZmTfskdUMTpXBjWHIh3T2je2Q8VGwseAOlMGPevbBH2HBqfLqyHNTh4LH
2vNu5P5XXmyS7/CuRQrvamQJHKQ4CKj/Ayw4TbFvnO3rPwZ3jQWnynYjzwGEvz2lcGw1yYh6a2We
7+D1FvKUlGSdVIk4fl3CQVvxnfRcLM8UQhmtInefFl0sQoLzTGW7rehB+CdrOPsd/MgzDhMhHL2H
aqqo06VZWqXJhvySg8zHHS++AzGaDxacqWy3zOGZaUnAPVfdE1MOp44LTp55keZrODMK9UYyAgpC
tZ8bbAfOtRtDiWcq2yUrKBTK89HQcwu+EqsFMnWgdgseWUpXQT//Cr76zKtvHAr/1bd8aEWLDQ3O
VLZbvLv/9P4NPJlkOdmIN1aqJ2DgHKa1mX0aA0d0Gzk4SOX4lFF40Ux3cg43+/rUdQIahQal89nb
+Wzx7hSU4lhgEEYGhUiUcMLADdjUoPT2w3I2/+v1+x77u97sXZnNEIm+nn/l9C+2tsrdlpkcVget
vVJKnIUA8yces0mZGX5EebVnEfISGxsuubzqHVFeRbqrJ4b13IGX8HpPOOMSC07Vl0aT5T/SKwKH
o5LNaFTNxHYMov6CP1dcntdkV4M3PJUB/3xIHjnc/1djDxKcqgdBMclWdGmegf9GolMFoUtFp0oN
l4pOZdsvFZ3KY18qOpV2/T+i+/g/UDR1vwplbmRzdHJlYW0KZW5kb2JqCjg3IDAgb2JqCjIzMDkK
ZW5kb2JqCjg1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNzMgMCBSIC9SZXNvdXJjZXMg
ODggMCBSIC9Db250ZW50cyA4NiAwIFIgPj4KZW5kb2JqCjg4IDAgb2JqCjw8IC9Qcm9jU2V0IFsg
L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4
IDAgUgo+PiA+PgplbmRvYmoKOTAgMCBvYmoKPDwgL0xlbmd0aCA5MSAwIFIgL0ZpbHRlciAvRmxh
dGVEZWNvZGUgPj4Kc3RyZWFtCngBzVpbc9pGFH73rziP9gwm6ALGfXNtJ02nNDaQ6WTiTEdIK1hH
t+wKu+6v77e6ApbwsGQ64sEIA6tvzznfuXzLD7qnH/TuWhrkShqQdPHSwMUAf41Rf4QLN6Rf5zTo
DwYDg+YuGWb+vnq6GFl9c2zTPDx5N5/jKzT36ZR+8uPsZP5It/MM6yHghkYBjipwJ6cfo5SJiKXn
N8Lx0yakn24m07umN/C/iSPcFZkDwy4/oAvOumwAVy76s551wZkXHQZnDBvAXfbtPtzDpHSWjObC
iWTIpeRxpGdLXcsNSkJsxpwehPZvaYIbXTYRArf5a8UiWkseLSlZvUjuOgGFzOMOyfXikbkppTG5
cRBwZVBJTuRR4rjfWUpBLGWPFnG6KuHqgrtoIcTvMY/ofs3ES3bf7OWUJcELIGbeljT77dPnP25o
weiRp6A38xTgkEc85P8ySlfsWHCjFkIw31fmif0N8/TIkeQx6Qq+ABKg/zp9fz007PG3Ekbzs67l
hk2EaL6F/n91wdldJoTVRAhjgEzyOeIeF/AtAh5sCHj0XdIKgY+r5WFW1LWc0UKIw+7+xqd1wQ1a
CHHlg38kWeQpOzlU0xW0iCivrdN4rT41+Tyb0xMT3H8BRx1kmZqoGWxNcMPLFkKsE5kK5oQUMb5c
LWIBj0p6RIJRGQM392Px7IgM+lLE6wSBMI/xDpeEHfW2AOqCG7cQwkd+jZ+V1dKVYAzZzUW8cRki
3wqG9AyM6FhgtzSvbmmam3jJn5C+M0NXztYFd9FECKyaJdxfquWPu9AFN+wwIYZ2CyFioo9+Fjhb
sR8j7lfMEXAuSocQTCZxzpmaMeSLOPwpMWe1EAJ+fM2Jh1OJ8JvluY9g8771cKZiHyzI2MqZxKuC
ryozluGg61izhRJYF/dcbGVi1XtUN38NfofQJTI864IzWiiBJXfTBT2cJg6azidG6I6i+Dlg3pKF
LEofzjaQNF5qwrMvO0wKe3wYKZTznAAZ2nuhkiBIek0E2bChruUu2kmR95cV/V6HWSI4qgeazK1c
zFNJ8fPWxKELrhqsX88RdYIoSBkyTDtvkaK064bhdClhNw7W+cJ7iinY0ZBYFGcEO9+EVV3rGm/P
bH0wLyswry500XV5uLYbh2tsHWXsNpCsR7zP+sR91UKhYwIH0DYpB+4YliLFD/VekRA3zadruT3D
9e7tVw6ScFGt9haMImBreJrgrLbhGis3tZaI+9KU6u3tHuCu6J/n6ySoZtcMoi66tukai7J/Ekw6
kp7hULo7ozfEtlr/M2y7PzAtm6x89ZN5WGcrOv37zaWaREVDJRfTHrUsuuFnD2NGpky8dxCZeYvC
tieMQhgonFvbLlM8r2dQMGfXjYrnxtbGFJIxNMudjimgGd2fHKSTWg36QamTClbWkCxO6uyeO0QF
x+/T/pX7fcp+rOEoj/zAWaq9YzrZetT7Owxcl/UDq8v6gdWsHxhwzGzyHpyOJPeYcJSIILdcdcgL
Xbd2WT+w2vSDuZoyEhGnMfRGmlx9UaqeWEdKRoM9H9dRJsnk3FBGVtraaGQa35S+4G3bVdNyZpt+
sGAR83maz2UyDpkS/lTT5zMnXSOHwvEfI5Q8kXJ3HTgC5dLPQgGbwgYww/cqhLrg2vQD4MJdprfX
nyaT2z9vbm+QTjCjKXgeyghE3VRVY6XayvbMfJIf99RJ3rLGfXs4NMhsuPHeJF8s1ZTkLXvYHw1H
ZsuicOQhCFVyHV6OWxbbU4b2Ibyw+/ZocNmyaCk9pxB602JSLj2737Eb9jRRWSx7VJrXzCvLq3qk
UGYFJN9j9i01u5Qvs3r06lt7z+3MXOfZKdjYQBHIinSZ4IQJl8J1gHB2ZFpq/vXYi3i/8jyei6TB
Sx3cmS32G6L1UBEbazjgwYpxkmaCvqqAcZypdLVI1sNZBY7mMEHenl/fzAjAZ+eTu2mmxsuEudzn
qJ3VQxdcm85TyPxFKioSV2bDjSkxV+nyw4wyhHaruEKoC26PzlNt/OgLXXB7VJ6jMVUL6IJrVHkM
UyX0D5O7rLRMcMR0XEnXBGd0WeMx2jQeFMJYoPtRKolKkgLncYyeVwwdrVD0jGJVnTBIMg/qRUwi
O9TDRXFqUPkUF7qWa9N4tiiYNxObZxXl0SKGNCSUOnuA5E0PXXRtIk+tvRq59rp7cpLbbFIl5g/q
sAKgwwUTcsWTLZC66NpUHh6hAIRZUwt6zFTW3fgXuQCL8oEe7gnNr0eLl6qfgymLHF0B1AW3R+Kp
1j76QhdclxUeo03hOdpamwvoWq5R4fnCe4RJ3wl2SuVtIVzMWJJmoU+j3tZvc3JEX+/UT0IwIZQA
NcHlAs/AxK+dapnjpDO/dsqapq6iy/WPrqLLBZCuossVkK6iyyWQ/xHd/X9en6W8CmVuZHN0cmVh
bQplbmRvYmoKOTEgMCBvYmoKMTc5NgplbmRvYmoKODkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh
cmVudCA3MyAwIFIgL1Jlc291cmNlcyA5MiAwIFIgL0NvbnRlbnRzIDkwIDAgUiA+PgplbmRvYmoK
OTIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3
IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iago5NCAwIG9iago8PCAvTGVu
Z3RoIDk1IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNWl1T2zgUfc+vuNMn
mIbgrzhJ31gCHXaaNhC3MzstsyNsJdFubKWWDWWGH79XdvyRrBUWkWWsB1BsSzq+V0dX98g/4Rp+
wum5MMEXYIDw8aeJFQP/mm7PxYofwm8eGD3DMEzwfDCt/L78N3DtnjV0wAs7p56HTcCbwxEcuBx3
vL/gwsuwvgRc39yAgxJc5+gqSmgc0eRkHJN50oT0y3hyM226gdcmJPaXYBmmUzygC84eNYArOj3U
f11w1qDF4Mx+M7irj5MpfL+5PLftgXsLJApOeQyTT+P84tA0bnsAVxGsSZwwP12RuItPQe7vG57i
xCgNr2s5oyBEfc5hr5OvMw9iul49wgNLlkDgd84iuMmuhFQIsqCQcLx+T1YsyO9epzR+hM1dUWID
TXDuqIkQ2C0J7imaRLBogQAm6QrNQ0QCM8TFeARs/qEa/LmaLrhBiwnhugpCcABvyQRsZg/WRHon
/Jjd0UC6M1lS8HkcU7HmUSDtW1n3Y8zTNc7Isuharq8gRNnxISq64BwFIdByZ7DkOMtIkhB/Wdir
MuaSoDXZIiIrGnSB9ha9LqTZHJVM79ZfShecrSAE9p0sSQIsgQyFvk+xJ11wZpsJYSgIUffKq+ua
luuPmghh2si1in1T4v9NEwGXPH4gcUbNl+HVBTdUEOJloz/ztC64gYIQ9RgpgMdswSKSZPEiCmBe
2TAsg8d6Y+As8m3B1QXXVxCChesVDWmESwkE6XqFwSuhGOWlgyGgCfUTGcV+HI2n4x/HGE/9JYmY
COVuYL5ZUmoAdeE5CkpcTe8dNBlcTb+5GGoDDAaCim4WG1JBgc9hNrnMNimua5m3IJfAi/Mvk8nF
5/HFuB4htBeTvt1EidpLH6SqazlLQYmz7c1ZFzdQPmX3+TYl4tFJ5e1q3gUkIRvnHyJG9E0FJZKY
RCJkuIRglJA7t9VKulJeiChbLO94jLfkBelQgtMuvMMNJj4iNwU7RdNyzkhBiRojF3KbISmK4yKQ
LfOwHu1JODEF+osJhE4gQQZRwL1pWXTBDRWEkO9fW3azfRB45A6HFSmmV0T8/9tNZ9BiQjhlWr2T
RaBLLo/hmWy4StD7Rs8xhhbs9NfJ0/Q/n+2pKenvD3quMbKHRacdL6xAwlHJw2c7r2CaltVzzNFI
0aUeTtMa9XA1NRWd5qyotubFZr3EX6zUOWGROPVSMSLTTs5nqIXMzhu1k8oHFoTQHxYesWAFMylp
oDd29ZaaQWQj00Y/5vYpWzWqNJ0mhxngNAghhUqziZL1l9OsVzZ5kYTktFkIcfYIIVpE3O7vQETM
Oz0oERu7fC0RGzsVPI39epIsCipu7mQBE/nXOFP3T7qSe5Zb5x7+2nBvh0Ud1Dor7mWNKu4pW+1V
SJ1crdpxjibFlM32m0Ep3zoqtUo5kM4NTXB2o1plOrgfnlE/jVnyCOc8EiygMaYiWHtLcG1Wq2yV
WpVJVQH30yxZCjgVgIaMMXNCWTLiUuy4pyiJPoIoLOxvWbiei+i6tc1qla1Sq3SmlrKNruUa1Spc
XzCNPft8hjrja8kgEeuCa7NaZavUqowQYk19NpeigVQJAjpnERIjeeCYxz3AZKPNe49rmbQ/LBlm
KGGKuuXdThanaTmrUa1CT2BCyaWSgfpKzMMsa3xXR/NOnidwwRKOhwQYJeXRR99xHHnK8a+iC67N
apXVqFYhIUy0QHa8kh+g3NAF5rYxQ69qFF3LqdQqDQjqJrrgVFpVfaT3J0WpavLK9q/8mff1hkVd
F9x/0aqecBBJSYAnGFN54rLO6PsEZzltJJenHLXAR3yioeiCU2lV9SEqC1W1N7GcSquqg3vCLe7w
xLJstMvXiOAJ3yLCNQZ/Xfxa4zEgnkneM1z4ZDmk5TCBbT63rYOr7FXV3sJypkqrqoN7dV1zzpl7
tapcODM/1Fe8TZg4kQw5KeJbFco+fcu4s70c6oLbo1W92mBlB7rgGpSPTlu+TzHbrHyY20pF9mVP
eyyn+gSknC+HqOjOucak+g+GR9h4QLXa2ZzhmsvwQAhT2nWSHxC43a3vi/I3+T6V34dY1m3xYprg
8pzasPCLrUq1bY1f86S6rejyrLqt6PK0uq3o8ry6rejyxPoN0V3/A/cRQbwKZW5kc3RyZWFtCmVu
ZG9iago5NSAwIG9iagoxNTk4CmVuZG9iago5MyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50
IDczIDAgUiAvUmVzb3VyY2VzIDk2IDAgUiAvQ29udGVudHMgOTQgMCBSID4+CmVuZG9iago5NiAw
IG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBS
ID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjk4IDAgb2JqCjw8IC9MZW5ndGgg
OTkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1aTXPTMBC991fsEQZcLNlx
mt5Kk2EKFNLUZYZhOBhXaQ2JE2xD6Ux+PJJlW7KxirtNU+sQS/JHnt9qtfs2+Qln8BNeHacEwhRs
SEM+JLxj80/i7Xu8Ey7htQ/2vm3bBPwQCJXnxWHoOfv0wAV/uffK9/kt4M/hGWy5Pd/zv8PEz7He
B9yAFOCgArf37CTOWBKzzBonwTxrQ/pxfDqbtp3gc6dBEl4DtYlbXoAF54xawJUP3dYRC44OewyO
DP4P7oVVNtUTM/WRvOZFG9tY5uzSIfQ11/iCDR/7t2sGsIExS8MkWmfRKuajo8ViFQb5YLpaROEt
n2tpSHDeqM0hGs9XDKneLpjzhh0cQrBB6AH/5FyNxzPL/zyd5KPGWxjmAMuc18EhNhzayKLU4eAu
4iBNo6uYXQqokz9rlmQwY78jdpMj3apZBz12CM/t4BD/Gu+eM1izOkaH8INvCwb0EN6uohjOfrHk
Fk5ZmgZXzBK+a6VrFkbzKISjy8uEpfCae+4P8N9/yl071V4AC450cAjta3BdLDjb4BDaDraaQ3bN
ND8V5MyT1TKf1nhtUKm4Q4IbjAwO0bTRTbRYQJiwIGMQQMx9M9+WJ38yFqdiR56xqyjNuOlvouy6
QTAW3IHBIeSGsWRxlkKQQkEK30D4+pOr0dlvQDAPseCGRocwf9e9z2DBDQwOoQUq2dUmWiN+Effl
oZEEYMG5BofYwIdgyUM9bxuxvPgnbzL8874e/8WJstVygSpaYME5BoeoHizACZAiVpWLXztZoiqO
GyiyEzGuLsOCowaH0Kz4dGYlBodQ+QcnQKQkkgY7Z2gDpxfv/ZPjo3PfejP7eDG1RLIyOT9XZG2D
OXdkcAhuxRxHZZ3KRtVMeV4/6lcppEizugdGhygzN405YtHBIAenZ051cEUWJSYrpFhwQ6NDIJlr
y+2w4CpR3dAQfXAIt1VU64baRh/L3N2iuoiih0XK1szZeNQVKbuIwDBfJVriUn8lLLg+i2q3VVSL
SZ5z5KnajK0Xt2VCFPGEF9GwzHUR1Qg49VuQ4Jw+i2qnq6iW+Ug9HamlII9QjnC6iGq156neLsoR
ThdRLcJQVY44fjebnF2czCZjFZ60FVaFLG0OW45wuojqpypHOGZRrV5dGVP1dmLWPotqxySqc95k
9HKLioTcjtsrEsVsazECsGuOmkS1MuoWeshNmJpEtQ5JrTTV28Wao11EtdgenmITpiZR3QvmTKJa
B1fbhHdYE6YmUV0H9zQ1YV6F7u+PJNQkqnXmHtxHbiXEJKq5f+Y14UGHHfixasLEJKofzJb+ACxz
JlF9v5qwjGzbrgkTk6juQ02YmES1UqSmmrD36DVhcreo1hfOA/rYNddnUU1aRfUDSGq9Fctcq6j+
HL0ElkGwaCwrXnuLxK9c52ydseU3loD3svY3CAnty5T/PgbU+VoiRYKTmtqm/I8ljRpY+eCtHJHo
pKjuKzqpqvuKTsrqvqKTurqv6KSw3iG6s79L72MxCmVuZHN0cmVhbQplbmRvYmoKOTkgMCBvYmoK
MTEzMgplbmRvYmoKOTcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA3MyAwIFIgL1Jlc291
cmNlcyAxMDAgMCBSIC9Db250ZW50cyA5OCAwIFIgPj4KZW5kb2JqCjEwMCAwIG9iago8PCAvUHJv
Y1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8
IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjEwMiAwIG9iago8PCAvTGVuZ3RoIDEwMyAwIFIgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVrbUts6FH3nK/bwBNMkWI5zO28hAQolkAbD
nE45D8IWxODYQXKgdPLxZ8s3HGJ1qMy08QOWJVleWvsiLYVH+AqPsDcQBBwBBggHHwkWDPxL2o02
FpwZ7NtgNAzDIGA7QMykXd467WbD7Fpgz7b2bBtfAfsWduCDr90t+x4O7Bjr74BrkRQc5OC2do6D
iPGARfUhp7dRGdLz4WgyLmvAuhHlzhRMg1hZB11wzV4JuGzQj7rrgjM7GwyOtMrBfarnV1IsVNSL
5bxbXFhp+ZQxr8uckQVE0edw0CWc0RmLR1+C/TLHCrywIOuWMGTC4d488sIg7pP9WULf90OHxg3x
K7JFE1y7VxYQOF4+sCwmgA5+RCwQEk6hMUOV3pcwDn3PeYkf82664DqKgCjYJykWKv6UWdttRUCg
fYbDSd3+NkaeiNlN2TJSSkaXp/bxoH9h148m55fjuux8cHGxymll5lqKgFjCQWax5Bv5l7C6WM56
JfeVlvxB16yWMiBKmSMxBoyWg3/t+ufzV8pSjDinH3PGk8RdGVxTGRCazE3Yk8ee0zmkkHWZI4qA
KPU5s262WvjBJVwGVAjvLmBu+v309rHMGcqA+PvMtXqKgChkjr+WSlpdRUCsWqvik6bPtTqKgEjg
2PTGZ9D+B/quy5kQsI9r0wPYp1fJSpY43owFEdyGPE+NuUekk9IF11IEREWuVl/XBWcpAmJ19IpP
uuCaZQGB+3uAvvMQhM8+c++YtJuoAFAXnLnJAUEUAWFPGdBFNA25gOdw4bvgew8MohCiKQ0wJqbh
jAoY+HQhWBCHw9QT4OGe6i6a3i78ItGazFk9RUDweBUSQAMXnHAWGxZtrXfpgutucEBYnbKA0ONH
/ZYuc7moLmoI0kELTtgt4yxwWJU4TQDrgisV1WoO9Fp0wZWKamSOIHdnIZ+hjnpiVVnUBbfJotpS
iervk8OBSUjvP4B9Tt2A8RpcNGqw/YW9YOLjrohzGyY5zG2AnYXMgceB66FoZW+sr8ucSlQXhp+w
x4XH4zUMTtkT88V2TcIBCb4G+4MxEKuWnt+QXk9G0+qlCa6pEtWro1d80gWnEtXSrM1mp41mHVAv
QILQpkPGuBfcJQb+Ei6QRSpqcIxNhyyITS+7yVWlX6RPF5xKVBe4sqcv9I5yek8R43Z2dgdHPFzM
0ZgBTbYtMOZhFDqhX4MrxuNji2wQXXAqUZ2Ni/dm6mKSyBqcO1F4wzgeDhpmkZ3CC2tFXXAqUb32
gSoVuuBUojr2uS4x0OeuPJdieDZiXzptwCAUEVZsjxZ+hIlDRHDqCTyAQjqHnnDCJ8aTU6Z8Prrg
VKI6HxjBpR5kwvXO6HT4ZF7vxjnuePzUziyO06jBySJg0tzWurl14alkdQFe9aImOFMlq6VhW8Tq
ymSS7HdrYMf5hHIfbVeDQZo29hsoHelMhDKaT7wIj+LfTkcX3Dtk9SDE3bfLeHyaKvfiMApvPFS0
fRc+hw6csQhXtAch7d4/O7DF9S7ae/XShfdrYR1/Q65WkkaZbW/4gqLLo3N1151rFVHhSRfcJgtr
UyWsY6+zLOvXXjdkcuU4Sf1vIP3v3pu+taruibpZKqwLFsHi9pHMY9T3fuKJXOxXMKbOA4v2RniE
ggsYHMY70zS1tHBKb+DpmvUdwrroab3f8LTXKeqCUwnr15E/oKQJDveH5T8xSZ9rt02CPjeSNsTN
sHSt7QtvNve9W09aOF/C0KzPlLu4o0pNK98smFYX3DuE9YjK3EHevQ9Zp1oX3CYLa1IqrNfnXq1G
l7lNFtakVFhX42n9bV3mNllYE5WwXp9+hRpd5kqF9TevBiwC6r9ZD/CHN1TYAi7YPGIzKXVQ9RT/
FSKZwPexXNNMuS4nlya4RFcbJv5zSfEcLBv1o+6a6BJhvanoEmW9qegSab2p6BJtvanoEnH9B9F9
/R+YaEIJCmVuZHN0cmVhbQplbmRvYmoKMTAzIDAgb2JqCjE0NjAKZW5kb2JqCjEwMSAwIG9iago8
PCAvVHlwZSAvUGFnZSAvUGFyZW50IDczIDAgUiAvUmVzb3VyY2VzIDEwNCAwIFIgL0NvbnRlbnRz
IDEwMiAwIFIgPj4KZW5kb2JqCjEwNCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAv
Q29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5k
b2JqCjEwNyAwIG9iago8PCAvTGVuZ3RoIDEwOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K
c3RyZWFtCngBzZpdc9o4FIbv+yvO5CqdgovBQJjZ6QwNaZtM2XzgprOb9MLYArS1LSLLSbOTH79H
lg1OY8VE7exYF8HIwno40nukV+QGzuEG3h4mNvgJdCDx8a2NFx38aw+sAV74Ebx3oWN1Oh0bXB/s
rrovX4aDntU9cMCNXr11XfwIuAvYh99cXr9y/4EjN2N9CVzfzuFgA/dq/zgWhMdEtCfcW4gq0tPJ
9OKs6gbWTT3ur6DbsZ2igSlcb1QBVzz0d72awnWHDYaz+xVwNhJbAMfxgvHIE/SWwAVZEE5inyQG
4TSNXKcQRHnOGfT/7EcM4QajKkFgT1cfPk7PvmVdHq6oFy9bcGi14CPhodeCKV56cQCfLfh7ld3c
+8D4nccDGi/hI2fpukxrCjesF8Q0DQX1vUTAGWeC+SyE633Jfv0acNwhu79ia2RmcxoS+Eo5CUlS
ngCmeIN6SfxJxB3j35O9FoxvOQ3BHo0OcFLuXkzh+lWS2L3b3VqawjkaSVwdtycWJWLRjjyZkFmY
8Nuumoa7EZVamcL1NJIoPfow9NKExC1wUQgT4vGQ3RKlkBPPv0mJaMFZrpEvFnwifE44SmhbTOHs
eknsuSsCp2tBI/ovQY3S+DvMhCcw/bFUSIFupHJLeEJZDF2cn6ViCtepF0Qgl9j2kyFu2yPUrZQK
0BjWnC05avT6Ncq2WF57G9kY4vVHDZZE/0AniWzv0T5hKY+90FAKxdiaRm5YL4nPBAUwwzk/S1vw
NZ/7U6tYMfZO4/aEoKoDlZKzlF1gqVdTuH69JJ5MfJxkxcqwXRFKyfoxGb4zhXPqJZEPLbBFsUYV
INkaO16vQ1zhBOo0acElC9OIwPARoClcr14Qx0mSEhhgOvOWuGtyHBva4PR7Mu35JMK0hlvfjtxn
6YopXFcjCF0/RvWmcLZGEFcXHw57/YGNOj0j/DuVQyb3Te9JKLdG7Qt2T3gLjnJ9zCyYeNhkbxzA
ivmAIil9DUM4Z1QviFyKE5oID7fDcEl8gbul6/3x6eQSt065YHBZwC8E8hs9WiAySFO8gx0kkYb3
cl5tc34pLDtdmsIN6yWxU//PNjKF21jrBjoJp9JaY/IicUB/wBgzBE6lvuM4cBT7LDMKzwap8qZp
5JpsrR2dtXZXNIEElSm3aAFJfE7nmIMFbu/Qw6oQ4qKhDici3C9lKTpN5BbvSTGNXKW1xqfLTCdH
89szqf8JhK7CFK7J1rpXaa3Hlo0BO2G4ATlPCb//FTHIaBpGrreDtdYN1u71pnA6Y50JAs2B8vkB
WdA410MpoLkQQNyvCYb6kzzuwdMK32fqdKLAN4XTGWvBtprA/sKwPMobdXqcwJLEhKMfC1rS6eBh
VII2Te6Mt8UUTmesBffiJKICO8VjkTBkdzJJiCzBrIlPF/kOEwPmenM8JhlCsmJ3KtlE3npdzimm
cDpjPcdDEkLiLLGVBhKPaSISi2ST+gLpDWd5PhxadhYzzIaUbwNnLAidsS4yLUZmjGNaDVXEbPpl
5sKcIKcfpgHGGoHLxTRyOmNN0MDfV8wzhH15MYTrNtlWd3W2+k27ulTUV1Spz74pYmwaOZ2tfsgf
fHIOR0oEqgLrN3uovP4BDtEX0kAmFOkQCyQonmEqiK7OVuvCUVFfUfWbIqez1dm3Pjm3xkEgD5A+
k3gpVhiTB/gjSpZtD6vboap8UEsvLiALziL8nQoTuD3I2uZBNB1Wna3eDMlmkNTFA7z7qQZ55/cC
0SSwXB8247p5himczlYXkZvhQZNP8vghFtZnoWOcqvi9206tp9R5jSmczlb/3NEvvTeEw5P7ih+Z
fomk4sOmcDuY6oreXlhlCtdkU2032VTblab6haNW29x0WJtsqm2dqa6NxksamEZOZ6pf0ndtW1O4
SlP9F20BEWhrftpaHv1Y4w+qCW7L10IdB+NZcfmfIRTmlTw+hm5/8/uFIZzy1J0u/ntJA8/AlKlu
Kp1y1U2lU7a6qXTKVzeVThnr/5Hu/D+RpXs/CmVuZHN0cmVhbQplbmRvYmoKMTA4IDAgb2JqCjE1
MDIKZW5kb2JqCjEwNSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEwNiAwIFIgL1Jlc291
cmNlcyAxMDkgMCBSIC9Db250ZW50cyAxMDcgMCBSID4+CmVuZG9iagoxMDkgMCBvYmoKPDwgL1By
b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8
PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iagoxMTEgMCBvYmoKPDwgL0xlbmd0aCAxMTIgMCBSIC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1abW/aSBD+zq+Yj60SqN+B06kSR7gmaUgC
OHetqupkzAK+MzaxTZNI/Pib9Ttkl4jFtOwHvB7bs4/HO7Mzz/IIA3iED91QBjsECUIbT2XsSPgr
Gw0DO/YC/jBBakiSJINpg6wk1+mhaagNpaWBuah9ME18BMwpvIOK2/ua+S/0zBjrPuB0OQUHObja
uysvIoFHovpFYE0jFtK7i/7wnnUBZX0rsOegSLKW3SAKTm0zwGVKqzqKglOaJwxO1tng1nA9aPRX
buTYVhh9CvzVsjOZBLCm1qQ9EobgePRsDVchEM/2J2QC4xd4sl7An8YX6GVsopaTMocozznUtwYS
641/EEfWEJyVQhu7vv0fnOGtlrclfHKiOdWRNkFwRpvlEKgzV5wNkB5zuXnzVy6ywtC3HStCyy3Q
otYsebH8XlFwTY5D5Ip54Ar5GqKXJamHS2I7U8cGCruSz2oYHIfYGxx0Li6GdfPrfQ+/8iSGnusQ
tZzOdYjCNOVePmAhXMMPy12Vpmh2Kb9XFJzGdYhsiM1jPmAhXkP/4ca86nZGZv3T8O7hvk6N2BsV
81YUnCrqEGVwo0ZxVurlLyIKTt7hEBjpRuRxhSGM3K4WYxLgwHTA3xfhrB6Sx7q3WnykItmAsROF
5zCn9+bwDgYnVeEQ/c6X98Bb22tJ4lGkGyp1Qr3dAoMxOLz7501VrBxGbWoNzZDaHKWj3uBNtSWE
baMhGZrOUSaGUKNLiqEbHKW3D31wQjB0XdXTSRB/5WLWxeldd4Tp2qjLTO9KhjVgAWoT40liZwNc
GMGgxkoK1eJl6VOapGXvnj7FGqvGTSX19usoFqeSZ3V2Y8gZouTZs2ziF1ZhvRIfXIsTxTK9lRxF
wTU5UWwblGmNXQLN3+DaxzRosCLBC/TTJbznkgXxoiIx2X5YFJzOiWLb+g86FwWnsaJYp6FgRI9t
NCRL9wV6NFF0vJkgRFFw6muHqJ1KbaUrHIcw5xiMloEf+bbvwoRMHY+EEM1J2aBZ3kizNTT1JV2a
zsGybT/YsLOo5WSOQ0Q+fBv+2dU1TfuO47kuA1QIVkBgRjwS0Bz3nL6MjU6C6W6WsCXzQBCc1uY4
RBRYXrhwIppYT33X9Z/olIuoPbOE1ooc30ODJY7cgnDuPyXGXVjLZXmGioJrsRwC33dMoidCvO0P
SbKoMSGhHThjhI6RZURsChRQV2wz/PoOTVCyJgqOrksx2bBVW+H0if0TLfM3LZTobCPPNlnGKLAA
oIJO9/OwN3i4GvYuaF2QfP4cfwZNuPDTciZkC9yGZbIP138YmWhTNJbtrmgNilYjP2g8LoWd1Evw
rfImajkmE5JrragjCo7HhPBWc4acIapm4dd4TEiWQF8PIV06EyuiPI0wuXwNXd8LnQkNKOgWxRKb
6RAlGzQeE8IzB0POEFVkOT4Tgpa6HjZSRuaGeDNKbmCtEhcvlA2pu4lwnSy9uIBMA3+B7CIGcCxo
SoSF4JxT92dCsJrabGskjiKEltI32EvboZ9V3cmEoOVG/iqwSWo/HBQHjE3nB86sTuF8jGvBDM/G
8WBwfCYEkf1i9k3lMyFF6Qu/iH1ThZmQn8C+qZUwIUdi39RdTMjG7E5P8kleXEyowSOwbyqDjIjT
dAaIGA5DfjT2TWEU1fuDOxL7pvCKaoaF+JY7Evum8IpqCo7G4LfYN7ztaOwbsjPsTHgvywmyb6zB
D2bf2EoF2Te2sgPZN7bSt9k3Fs+UE26K3ioTbvQ0JtxeUWeUDM0Jt+SpnHDjP7Vz71ZJyI+auSgq
lphwS2f4LXmOLv14C41unKVJV5Z1HHkfTeGRHztmeJqIwdH30RQe+bEDXBzA4g2ppIebfMfZR1N4
5Meb4BJg9Pdo+2gyj/zYG9wRVnKZR37sBe5I+2gyj/zYC9xt74tZv7zLNtCytTPXIVhOyTzyo5hS
FfREwZ0y+SHzyI8K7FWoELUcj/woNFfQEwXHIz8qgFSoEAXHJD++OudAIuSdy5QejtV7Xjr45xTk
TZcRiTdzjfON/xgleL7d0/9aKMb3DJ4guIT7kBT811ax8p/MzkJCfpwquoT9OFV0Cf1xqugS/uNU
0SUEyE9EN/gfQllYBgplbmRzdHJlYW0KZW5kb2JqCjExMiAwIG9iagoxNTgwCmVuZG9iagoxMTAg
MCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMDYgMCBSIC9SZXNvdXJjZXMgMTEzIDAgUiAv
Q29udGVudHMgMTExIDAgUiA+PgplbmRvYmoKMTEzIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAv
VGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+
PiA+PgplbmRvYmoKMTE1IDAgb2JqCjw8IC9MZW5ndGggMTE2IDAgUiAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PgpzdHJlYW0KeAHNml1v2zYUhu/7K87dUtR25e+kwy6cxsHS1WviqgWKpheMTNtcZdEV
paQp8uN3SIqSbYjDeiIUUYBIpiXq4SEP9b6Uv8EVfIOXr1UXIgUBqAg/dvEgwP/dUWeEB9EGTkMI
OkEQdCGMoNuz3+vdeNTv9I4HEG6evQxDvATCJRxBw9vzZ+E/MA0N68/ADbsFHJRwz44ukoynCc/a
ZylbZnWk785m88u6L7BsxtJoDb2gO3AnUOH6JzVwrtKm9lS43vgJw3WH9XAPJmpv5p1J9HXOv+Ui
5QtdhOWT13/Np1cfLubTMwjffsSiaRLJBX5/cw937B7kElhxrqkFqJELXELsjjkLYSs++G+h9wof
YMaVYivezu63vK22PBJLEZmG2BOJcKOTuoTAKmsgzI1qyh9M/DBcmm0XuzyXCjf2JERZ8e7d6qEf
9jo6W7MM1kztnkuFG3kS4qfgEgm3LM55B+BiWbWmrIMKN/zPhKhu5I7KG7oCPQIO8kYoUDxrVUOD
CjdoIiGyNd/rWp3DuJUNocL1m0iI2Yf3IdxwEEkU5zin/G7D+mi4bhMJITF06Z1QvAUiA4P697vw
8ZELmkiInaBVQ/Hx3To88STEi3b9VlNeU2SvfeFIiWNueOxJCFdvI3sq3NiTEIdQIbuJORy/gjdS
JDDn2/jePbVgGvMNTzI979ZvVLihJyHq70IspcINPAlBxKi/jArXr0uIyXbLk4X4Dqf6gRTHucpS
lgmZ+HuunqoopcL1nnJCdD0JEa7NEzLS8QK1lncK+He22cZcaTFpPUQkkyyVMWysnsNTCtWZK5Gs
qmASIzc48STE5/n56+FgMPiCHVseQyEkEdAoIwZbFn3lGWBDljLdWDFclpZ0VLhjT0KsOVvwtAUs
AbnV4WOx0ZQ3sYy+YukCfvBUgkxhI1Nexg6bYmJecpkDKty4LiGwRie2TR7AQmKwEplBrrgGSq2r
QMh7FzxUIkg2WSyEbUp83yoJqXClqT7wEFoFbUQiNhixou9sMB2YsTN26OnRiaMyQVUC52KVYyS7
CFptVLhaU11V28wRFc5rqoNmuEwtVDivqdaLLT3owwCGMILxo1CpcD5T/aJ98PcYOiqc31R/5Okf
AarZy3PcVaqWAkmE6/tM9UHc2qVw/JVwPlNNYfBeQ42cz1R7buSmsVdwaR9cf5oniedsV0yF85lq
V28jeypcrak+7egZ3gjyq5ynlSAnolLhfKaaiFF/GRXOZ6rfXJVKAxg+LEWiMpZEVs1VGsopOadG
FLcKcB+SCucz1cKJc8RB2VQITa0zZcJB5bgkXYDtPeL3odwnIlzPZ6pdvY3sqXA+Ux2iZKq69jcF
VjDhwTJmK5BRhgJYrxEyuzSnY3rSwmiyRCt0I5TLhlHhfKZa6zmFkhJdAYck39zw1OhfJfMUS9hi
kaJxgKXg8QIJcVRusQCtdcsaiSY8RM9nqvFOuPCciVuO1t5Hqssdpl4T1gI1jzMRMbX3aoUaOZ+p
LiJkukemYiUSlqF/Mfe3XgsTYV+U76LGPFlla9evVLhaU42Vmv6C66PZ5O31c+2ucCEVMgn9FkQy
1XGVaLv16JI6m138CigMY/luyRBS8Xy22ox5hXyiwzstE7Pq1shzcXk7cFDXz81Eh+bnlqcsLp2s
Cx3uqXg+Y63ED5x9FfT6NjvV/5jSdnD2D4lwXZ+x3q/9kZ+ocD5jPTFjqfChbjWuHer3NM7Wun4F
a7YxzOWMcieqjMCGUeF8xlo/qNxI1x6f7U7A10eT03PMlTW71XlhXpJAcDAN6wQuNyqez1o7NBsX
/UDAlzVaX2rbHzIRA7ermkU+zMTClRSLOjuLZlQ4n7XWLZ+V0+oqlfnWxbLAYUrJSJg5UL8awX7V
s7Hu+cnZ2bwdfrqcutBR4bzW2lXcxJ4K57XWTUC5OqhwPmvt6m1kT4WrtdafBCqMDFh8MPdOv2/x
pbqC93ybcSNXRq29H0PYpny+xJfX0Bt/cS0jwllnHfTw5yUHK2Gu4kb2RDprrZ8qnfXWT5XOmuun
Smfd9VOls/b6F9Jd/Qs2N7FCCmVuZHN0cmVhbQplbmRvYmoKMTE2IDAgb2JqCjE1NDIKZW5kb2Jq
CjExNCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEwNiAwIFIgL1Jlc291cmNlcyAxMTcg
MCBSIC9Db250ZW50cyAxMTUgMCBSID4+CmVuZG9iagoxMTcgMCBvYmoKPDwgL1Byb2NTZXQgWyAv
UERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDgg
MCBSCj4+ID4+CmVuZG9iagoxMTkgMCBvYmoKPDwgL0xlbmd0aCAxMjAgMCBSIC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlID4+CnN0cmVhbQp4Ac2aXXObOBSG7/Mrzt0mU9sFjO14Or3IZ5NOnLg23dlO0wuC
ZZtdDA7CabLjH79HAuEvNEkOnh3wTAwSoIdXOge9ch7hGzzCxzNugsfBAO7hoYk7Bv4124027ngz
OHXAaBiGYYLjgWml9eKr0242rGMbnNnBR8fBS8AZwyHseTs6cP6GC0eyvgeuZWZwkMMdHF6HCYtD
ltTPY3ecFJHenfcG/aIKLOu5sTcFyzBtdQIVrtktgFM33dc3Fc7qVBjObBXDueEIntxgwcCogd9g
Deyu7zfO9dnJ0Kl/Gdx979dPzs8HF8Mh1ry2UZUzVECsj7nXGntvPRGu3S0KCNG4UUBgFpRZBWXN
rTIqXEcXECIXWdAEG1rQhg4cQxeB3162zkeFa2sC4kO95GcfcC1NQCwBvkZ+CAM2D16woWWWPJfQ
O7n53ASsF1uPce5OGNywcJJM4TNYWZdm9elZVOVsTUCU1K3+IcUqB9fUBMTGk2cN9RZB4nsuT2AY
LWKPwcloFKN06xxqf+N6qnKmJiAqoZyhCQj55GpEDdnjgoUo1e1i9sBioU6ujHPzJ4dADbk8AeX1
4mSicq2uJiCqoFzrWBMQS6GSHFQcY9BMlTo5vcQDqU6uzGogfomjxVwIBY1GI68Xx1TlOpqAqIRy
LU1ALPHp8Zm18bjMq3DQwWkQef+skh3mur0oZ2sCohLKNTUBIZ5czInqzo/+Be5nbwgx/5cfpYwK
T3WMp+5u1DFnaQLi3crtIq1KqHCmJiBWd97DHhHO7hYFxGnDwmhYe/GrbEwEpcIdawKCiFF8GRWu
owmIrwOYpdMhDm7MwA954uIbjEM0hp+Dy7OWbdu/8nNQaGfqc+DMS/wo3GKkwuWmestD+EGw4Ens
JojjhsCe3dk8YIIsChnwBTrTDF6kw1c2KlyhqX6lrXdXU+F0ptqZMlh17R8cpswdsRh3xoE7gchL
WAJTF2XNHCRq2q2hmm7ohxNIpu7aSgEVTmeqE4TjaqYUpjMl4WV5Os10s2nm2GfBKB2Vc5x3sjCp
AU6uopEgzDcqnM5UY0tzMbifGFoIHakoV5ionDic5bPlHI08K7F1pjpTSHZPFPsTP8TYGKXtp1GM
gYDTAl8EpxsELzVZp1Cz2WcGSFSuqTPVsr/g/hC91v0RyCSRQBJBswZeFAtdo1D2HZZhNG9BoYz5
EpMEpOLpbLUc8xz5xEpJqkumBzaNPNf9J1tB3R/JRIep5onFqKNKM+W7tqkz1tz/F7Mvh6adRid/
Q0pbw9ncpWqnM9abdy95RIXTGWvnN46nfMwrd193XuaYZjCW/bHvqY6FBzEZ3koqDxGuAmQbFU5n
rH/7eG/xtlLDXSQ6dz0L3x+i58GAmbpPIrHlC3qFuZiKp7PW64lMSiNfCmEEV/i+gCgGx/UDYAGb
YfrFEXmJReKasR/juoB6ppLa6ay1BEojteePFEX6DsAZgeBYWcOJtIYZ0SdZqfpUfhOVs3TW2uU8
8nyZfrP5phxx9XzECeuF8SxeD2IkrlzHatk2B6TC6az1G9aDHVQPZ3GYkvNulHrjFEGIvbZR4XTW
OhtNG/14y54TuIrmiuUT+AlGqUbjPcDprPV7us9MV91rcHvxl1O/uuvX18DELlU5nbV++2r+FkjR
IRVOZ62L2iCXUeF01poMUnQhFa7K1tostNZFT1+mjKicWWVrbeqsdRmhdq6lKqez1jsNlCmgwlXZ
Wps6a11GqJ1rqcrprPVOA2UKqHA6a12GZedaKlyhtf7h49ICzmeDLdN18Tz30bjCkM0TJn/Radc2
/hkixfrZFz8nWse/FCURLnXWhoX/XrK1EqZuvJdvIl1qrKtKl/rqqtKlxrqqdKmzripdaq3/R7pv
/wGGWZX5CmVuZHN0cmVhbQplbmRvYmoKMTIwIDAgb2JqCjE0MTEKZW5kb2JqCjExOCAwIG9iago8
PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEwNiAwIFIgL1Jlc291cmNlcyAxMjEgMCBSIC9Db250ZW50
cyAxMTkgMCBSID4+CmVuZG9iagoxMjEgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g
L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVu
ZG9iagoxMjMgMCBvYmoKPDwgL0xlbmd0aCAxMjQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+
CnN0cmVhbQp4Ac2aa1PaQBSGv/srzrfaUTA3QDrjTEHtxRGrkrbDdPohxlVjQ4K5tDrDj+8uIRFk
T+wemM6GGZPsZtknb84beIkPcAEPsHeYmuCnYEDq812Tbxj8r9lutvmGP4a+C0bTMAwTXB9Mq+gX
q07bblr7DrjjrT3X5UPAvYFt2PDydsu9h2N3xqoC1zLncFDBbW1/jjKWRCxrHCXeTSYj/XI0uDyX
dfC2gZf4d2AZplMeQIWzuxK48k03tabCWR2N4cwWAmdIZDMlbZakzX7RRlXOKA2xWHPivYWjLLDB
gRa0oQP70FVqW+QjwrW7MkPwN95prPnaBFwHMcQU4CQOIrhkk/CJTzSd3wKmMOidHtjA+8UyYGnq
3TI4ZdFtdgcHYM8tOu8vjqIq10YMsaZujZ0Caz24FmKIpTOfTzTIwyzwvTSDYZwnPoPe9XXCpVvk
KLeXxlOVcxBDaKGcjRhiduZlRQ3ZQ84iLtVZPr5iiVCnUsY9/ZZCWJZcdQOq+sXBVOVMxBBaKGcg
hpgKlWZFlXIPmoVSvf4HvjNTp1LmuRA/JnE+EUJBs9ms+sU+UblWFzGEDsq19hFDTPnZ83NG/Tit
unjRQT+M/V8LN7uFmlxHuQ5iCC2UayGGEDXTOzq6bLij82O+Pf+EEN9iZ6+ipipzippcKtKN1JyD
GEIL5WzEELMzl7lT1FC5nLHHDD7FhUXLRr7elFstxBBaKGcihijc+mxWrmS5I7WnUHqpRheEpN7n
nC5iCB2Uc/YRQ8jdyT8q5suSG8tGbE38hHA6iCFeVQ4DkbVT4apQ/TJDyCahtlHhpKGaCoGNo8JJ
Q3Uvz+7iJH1TGpRJv+xiKKvtVDidQ7WDhepRHt3n0S2MglUhlFuoymGh+msU/GZJGmRPEN/AoRcG
N3ESBd4unMYp9KJbFv77xSbC2VioVlanbgAVDgvVdXMp91HhsFA95AXXOMn5t1umzLIygAqHhWot
ag4L1Stnv04DVTksVK/DsjKWCoeF6u9BGAbeGIb5ylTqDVQ4LFS7dwz6MQv4ffgwHk+8SPwORl2I
cBYWqqkc0nFUOCxUH4+9IHwHf4qr20zz91czHZt+PJYC1DVS4bBQXTeXch8VDgvVygB1A6hwWKiu
m0u5jwqHhWplgLoBVDgsVNfNpdxHhcNCtTJA3QAinImF6rq5lPuocFioVgaoG0CFw0J13VzKfVQ4
nUO1qXOoNqWhWvm6vTKAell1DtUmFqpf0UKtm6qcNFSPgl1gGXiheBSxsBw/TgL+mBCGbJKx2VOw
9u7Sv0EUx/44F49gre7PcigRrsjUhsX/sUTD38CKUK0rXZGqdaUrYrWudEWu1pWuCNb/ke7iLxbz
3ewKZW5kc3RyZWFtCmVuZG9iagoxMjQgMCBvYmoKMTAyMAplbmRvYmoKMTIyIDAgb2JqCjw8IC9U
eXBlIC9QYWdlIC9QYXJlbnQgMTA2IDAgUiAvUmVzb3VyY2VzIDEyNSAwIFIgL0NvbnRlbnRzIDEy
MyAwIFIgPj4KZW5kb2JqCjEyNSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s
b3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2Jq
CjEyNyAwIG9iago8PCAvTGVuZ3RoIDEyOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry
ZWFtCngBzZpbT9tAEIXf+RXzSNVgdn2NeSIEepGKCsWtVFV9cJ0NuPIl2AbBv++mJpFb7YjkEKHN
Q7wZ7+x8ms2xdeLc0iXd0uG0lZS1JKjN9EepB0K/y9AJ9SAr6SQh4QghJCUZSbc/vzxEoee4Y5+S
cu8wSXQKJXPapx2/3uwlv+ks+cu6DVwgn+BoDbe3/7HqVFOp7uC0SeedifTz6fmXC9MJHTtPm+yG
XCH91QQUzosNcKtFd3VE4dzIYjgZmOH03uQ1vVdNkb68f2jnxEoQw++cxvla5feqafPukeo5TdMi
n9dNlacj+lS3NKmuVaHaTbFBuDA2CUIX9SLPfUcntSq0NuhDWhSbkhjmoXARI4hpXS7ullxXWa6q
TNGpWqRNV6rKqF4D0SCEwoWMILhtHZTcfIjCBYwgBt+sEU0nFAsRBwcyiMPR5lCrmSiczwniarJa
+uVHFM5jBPFyosEKKJxkBHFxU1fqiN5K8qSgsRsc+F4YDQpuM0ThBCOIszLNiyO6Xl6Fj7PWucuK
1FGzu22Y1nNBuCBmBLFeeBcDFG7MCGIXTOs1ULiIEcTkQRU0rYu8opmib6qZ5apR63LbDVC4gBEE
dxF+zXtr4DOC2K41z8xGO+cxgnhSa6p393j5ls3unawun6FgTqNwrs2CkIwgmB5gYbBzfswIAqNg
slC4scWC8CNGEEwPsDDaubWp/s9DYBRMFgpnNNVMDTiMwtlsqn2bTbXPmWp4C02J6LZyptpUA46B
cB5nqmEQUyIKx5lqUw04hsJxphoGMSWicJypNtWAYygcZ6phEFMiCmezqfY4U21qABxDO8eZahjE
lAjCuTabatdmU+1yptq0O3AM3VbOVMMgpkQUzmZT7XKm2tQAOIZ2zmZT7dpsqqXNplrabKqlzaZa
2myqpc2mWtpsqqXNplrabKql0VR/z0ekOkoL59871tnDIm/0A+ortehU+Us/jdXPEId/g+in/7hI
rxV54ucqG7x99Z5auPqPJRb+BtabalvpeldtK11vq22l6321rXS9sX5Fuss/JlqQqQplbmRzdHJl
YW0KZW5kb2JqCjEyOCAwIG9iago3ODYKZW5kb2JqCjEyNiAwIG9iago8PCAvVHlwZSAvUGFnZSAv
UGFyZW50IDEwNiAwIFIgL1Jlc291cmNlcyAxMjkgMCBSIC9Db250ZW50cyAxMjcgMCBSID4+CmVu
ZG9iagoxMjkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwg
L0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iagoxMzEgMCBvYmoK
PDwgL0xlbmd0aCAxMzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac3avYrC
QBSG4T5Xccq1iXN+ZiZpXbwAYe4gsIVgIbl/2NkdtV+Q5U1hIiJ8Rd7iCbnLRe5y/NxVtl2S7Fv/
qv0i9U8tc+kX201OTdKcUlJpm6iN339OtfhsS0i7TcfW+l+kfcmHvPk4TO0q5/a79S/jsj7GyWvc
hBnnK3icVfA4zeBx6RkE8J4rKziIUsFBlAIOomRwECXIQTg5CCUHkcBB5BUcRF7AQeQKDiJncBA5
yEE4OQgjB6HgIGIFBxELOIio4CDihWqgIYKM6iCjOsioDjKqg4xqJ6Payah2MqqdjGono9rJqHYy
qp2MaiOj2sioNjKqjYxqI6PayKg2MqqNjGolo1rJqFYyqpWMaiWjWsmoVjKqlYxqJaN6mDpZf7EE
+AxsoJq6bqiaum6wmrpuuJq6bsD6H9ddvgFuxEXDCmVuZHN0cmVhbQplbmRvYmoKMTMyIDAgb2Jq
CjMyMgplbmRvYmoKMTMwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTA2IDAgUiAvUmVz
b3VyY2VzIDEzMyAwIFIgL0NvbnRlbnRzIDEzMSAwIFIgPj4KZW5kb2JqCjEzMyAwIG9iago8PCAv
UHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250
IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJl
bnQgMTM0IDAgUiAvQ291bnQgOCAvS2lkcyBbIDIgMCBSIDExIDAgUiAxNSAwIFIgMTkgMCBSCjIz
IDAgUiAyNyAwIFIgMzEgMCBSIDM1IDAgUiBdID4+CmVuZG9iago0MCAwIG9iago8PCAvVHlwZSAv
UGFnZXMgL1BhcmVudCAxMzQgMCBSIC9Db3VudCA4IC9LaWRzIFsgMzkgMCBSIDQ0IDAgUiA0OCAw
IFIgNTIgMCBSCjU2IDAgUiA2MCAwIFIgNjQgMCBSIDY4IDAgUiBdID4+CmVuZG9iago3MyAwIG9i
ago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCAxMzQgMCBSIC9Db3VudCA4IC9LaWRzIFsgNzIgMCBS
IDc3IDAgUiA4MSAwIFIgODUgMCBSCjg5IDAgUiA5MyAwIFIgOTcgMCBSIDEwMSAwIFIgXSA+Pgpl
bmRvYmoKMTA2IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDEzNCAwIFIgL0NvdW50IDcg
L0tpZHMgWyAxMDUgMCBSIDExMCAwIFIgMTE0IDAgUiAxMTggMCBSCjEyMiAwIFIgMTI2IDAgUiAx
MzAgMCBSIF0gPj4KZW5kb2JqCjEzNCAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFsw
IDAgNjEyIDc5Ml0gL0NvdW50IDMxIC9LaWRzIFsgMyAwIFIgNDAgMCBSIDczIDAgUgoxMDYgMCBS
IF0gPj4KZW5kb2JqCjEzNSAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMTM0IDAgUiA+
PgplbmRvYmoKOCAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VG
b250IC9PWENZTFErTW9uYWNvIC9Gb250RGVzY3JpcHRvcgoxMzYgMCBSIC9FbmNvZGluZyAvTWFj
Um9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMjQgL1dpZHRocyBbCjYwMCAw
IDYwMCAwIDAgMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDAgNjAw
IDAgNjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAw
IDYwMCBdID4+CmVuZG9iagoxMzYgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250
TmFtZSAvT1hDWUxRK01vbmFjbyAvRmxhZ3MgMzIgL0ZvbnRCQm94IFstNjEwIC00MjEgODA0IDEy
MjNdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgMTAwMCAvRGVzY2VudCAtMjUwIC9DYXBIZWlnaHQg
NzgwIC9TdGVtViA5OCAvTGVhZGluZwo4MyAvWEhlaWdodCA1NjEgL1N0ZW1IIDc2IC9NYXhXaWR0
aCA2MDYgL0ZvbnRGaWxlMiAxMzcgMCBSID4+CmVuZG9iagoxMzcgMCBvYmoKPDwgL0xlbmd0aCAx
MzggMCBSIC9MZW5ndGgxIDI0NzY0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZV8
B2AU1br/OdNn62zLtiS7m02BBEggtEBIFkhCkyKCEDRSQ0fpCiKCgmjAC1eKKE2lCIIaAmIoiheR
K6BXsQvWR7CgKN4bkZLd/H9nNkHIu/e9/9vkm5kzc2bmlK9/35mZ02eVEzNZQHgyYNjIqWOJ/hvW
jBBp1egpI6fGy9pl7D8YPXtmMF6W1hLCXxo7ddyUeNmwghDRM27ynIb77fcRUnJ0fPnIMfHrpA77
9uNxIl6mbbFPHT9lJuqxn3U7IXTA5HtGN1y3vYOTL0wZeV/D+8kXKAfvHjmlnNUmZJiCTXDqPTNm
6kVSmo/9O1OnlzfUp0PRngJCcXYQmUpMpB8RCUc0/KGm/AOu8bjKrnOE7Dt8VBpuzf+d2thjCbnr
v95awPbvbnS1vRaoe066R30bRVWvzy7gPoXECNkpnL4WiM6U7rl+hV1lv0HVpE1WJJTd78F+L7d6
eZyQPSl7dc6k9ya9t/riJCm7S06X97q83+ViF7GaTqxq2T7wGv2dXiIhEqC1tKYqJTCgq5/OwEMv
6tsRdCaZClgA+AYgkCC2KwAXAZg4bCsBHP0t4lbaBG5VXAGzMTcgS7kBVWkd4LnWgWr65r5Ub+AN
QDXNrtJ3R9iuq5kepgfJQrz7NXpQodgfaigfrOq0MHCIHqD7yUCc3l8VaIebq6vSF2L3alWnjri4
DxfYPa9UBbqjuIfu1evurUpthUq7q1LZLZV7MxYGlMhBug1Do8a7XE0zq1q2DHQ10hQyiqbhEaGG
fTIJC3Rf4FwgHDjbqVqgEX/gm3DvwOuovT9cGKgOtw9sxfGWljsDmwfielXguVH67tn4blO4muLk
xjBO7gusCxcHlsQPF4c7B+6O1xkd390Wv79n/HqPcI9A93C1gpu7sTNVgeajqmlaVaBZvHZ6/GQa
20WMgZRw90AIkKSXOwcGe1SPuuJeecUIeUV/eUVEXlEgr2gtr8iRV2TJKzLlFcmyU7ErmmJRTIpB
URRJERROIYqzuv6bSBZDK6eksZ0ksK2gH2tAUMqwFFvMsMKR3qTKGXQWjyjy7CeU1i9+PGF2oafQ
XmDLKyn6N5sR+skRRVl//jx/HtI+A+YcwuBPJjK25n1y4Ec50FtmFfrchisr9Csr2JUVP8or4lc8
SZVr+tw2tPKFpNLKNuygPqm0T+XG24J3Dt1Pt9NtxUX76fNsVzp0P7+Fbi8eyM7zW4pKr1fDy7aj
GmnJdqzaJhJg1UiA38SqYYj1x5FU+jyrl8t2qOeNkFS9Xqo3ckO93aMCxUW7A9igjjtCRul1Rrnj
dRT9WbsHtkSdltigTpsFZKBeZ2CbBXqzRrLX7Q6HUaUTNqhCT5GwXiVMT+mv4uOP0etkxOtYHm2s
Y3n0v9XJ+7d1/hz7/3hU3m1PlwcmrS4uDxePCBeXA0ZULp093lO5YFQwuHvSA+xCsJJPHzFq9Hi2
H1le+UC4vKhyUrgouLuLfl+Ty6vZ5S7hot1kdfGgobtXR8qLqrpEuhSHRxaV7mk1oN+4m9712PV3
9Rvwb941gD2sH3tXK/2+Ju8axy63Yu8ax941jr2rVaSV/q7iCbd1+0/dnjFz1oyZuDhjxgxIn34k
AGLIBrQSykiAkPpTgG/ZPtav/lsJkie2DBQxhbjJ66AOBvHfOnIAfz3IPPytIycA7O8A2UMn0iP1
1eyMUED+Si7TPTjmyOz6etKT7EWdnWDBrch86iRWcoQGcGY9F4DMCJH5ZB3tRXfHioiRdCRDOHP9
NFJAjpPj/D9wtYw8QB4nq8kGsovaaISW0BX0WP0teOchOo2eEk7U78B7AiQbrXpKb8sR1OlPp0GM
BPDG3njCk7Sanyksqx9d/1B9Rf37xIkr/XF+InqBt+NvL/mQfM4ZuBP8Zv5E7JXY2frb6mfUz68H
92B/6MNMvR2r8I7NZJ8+CsfJf6Gfa+lvfDm/UygRBta3rB+HN9SDmwRJS/ShBxlMbifTySwyF/cd
IGfIWXKZXKUBmkFb0e50MJ2L3nzKBbiuXF8+gy/hq/gTQkDIFsqF+6Up0W9iM+ot9ZWQr7lowSBS
Tu5BK+aTBzHCbEQP4P0Eo+KmmXjWULqZ7qA/coRzcy24HK4X148r56ZwV3gnP4gfzI8UlslVseax
DbHL9XJ9j/qn6p/VuZ+AkVKIlySTDNKc5JD2pBBv66+3fTgZTcaSyej9bLKYrCJr0Y9D+Psb/k7i
713yPnp1kfwT/bqCniloTbx37dG/IXQ0nUUX0Cp6kP6dnqIf07P0R3qZ68Ot5XZyh7iLvMJP5mfy
y/id/An+c/5b/F3m6zACASFDuF28tU6MrY29Hfu1/m+YtWZo2zgyhSwiK8kOzNgB8hY5Rk6RDzAP
59GGi+R3ylMr1dAGD1qRS9vSjvgrpL3p7bSUjqdT0Jp5dCFdRdehTVX0BNr0GydyHq43t4xbxb3A
nea+RZsy+ELMRQnatZm/hrYU4K8QczJFWCRUCFuEE+JM8WdJkxfJ34I2TpDXyJFGAtH3O8lm+Qja
uQGzVIUR2kmeBgYc1GdsMjSbY+QC2heg02kiLeHakzM0SO7mfHQpPUr7cSmcPo/0Pl4BhbDfCVJN
3+XKxPXkKjeF9uc44PcpLhlPWgwM3nzt+7p1fGrdmdgi/qG6AdF1ogL8m0OWki/5J4QA2UUewshl
EhJp0zonu1XLFlmZzZtlpKelhlNCwUByUqLf5/W4E1xOh92mWS1mk9GgKrIkCjxHSYvicMmIYGX6
iEohPdyzZ0tWDo/EiZE3nBhRGcSpkpvrVAbZfSNx6aaaEdQc26RmJF4zcr0m1YL5JL9li2BxOFj5
blE4WE2H3ToUx48XhUuDlRf04776sZCuF8wohEK4I1jsGV8UrKQjgsWVJbPHV0CWt2xB90cwjIaW
Lch+DAMxsidXku4jHwDfJ91ZjeJKX7iouNIbxjGu8WnFI8dUDrh1aHGRPxQqbdmiknYfHR5VScLd
Kq1ZDbfrT66Uu1dK3fHo4IRKdIAsDe5u8UbFsmqNjBqRZRoTHjPyzqGV/Eg8orjSllXpDhdVuufW
eFq2qKbbBg2tVLtXUzIIstlXv2C3d0ERBF1jzeJlDbXPoXYll1YysryipDIyYilmgRVHsNLIZShR
TzbezxrNOhDvSlyMpY2YGKxUw93C4ysmjsDI+yoqycA5oSqfL7IfbM1XHKwYNDQcqiz0h0tHFiXu
dpKKgXP2eCNB781XWrbY75nfOYSB29+ya8uubN855Jkf33//cPz8B2+wvWf+0W+w7zPw+thR1rRw
LzS9Mjg6iAYMDaP9HdmmvCOpGN0RQ4xfKUXPJ2BERlRondCpSjFNCwcrfof+PSJ84eebz4xsOCOl
ab8TdpFN+XW0qaQjG48rs7IqMzMx85ilckwWmlagn2jXssXsSn94qhas9EPikwFDcVdpp2wMdijE
Jm5pNXQdFCoX3Do0Xg6SUf4qEsnOKq3kRrArbzRecQ1mVxY0Xrl++4gwcHIvUy+Jq1JJv/5v1RIc
xeM7VdKE/+FyuX4d1k6LPtVEHTB0N6V/Ka2GVlpNipL2w2bih9/VsprkMqSfUIT+o9C2BU5khnDU
rkWwBONegtEuDVYEK3qNqQiWBMcDrYU0fY8L5RWl2ej6bUMnYDtoaKgyUuq/flheWtoJz2nPnoNb
UL2iFE+Y2PAE7PVT2VFU6tCiD9NUBgy9dWjlgiJ/JXRDTCoI6Q0M6xugIaB1Nel4vaVo8QMTPA1t
zkObO2bieqf4U6D0LsAjSisq2DNvY/j5RkWFv4KRfrwMmml6ItJwopqwKowWqumCAbgXu3DIz06E
Q+EQmlVahFd1bgHduoG4hXfJSgAR3qU2wCEcM9gA2ALogXPbsT+L/ZvYh+Ln9DqrcfxXQA6A1R8L
YPcsBrD7UF+/F8esrAOHPXvGLsBswDrASQCer5fnY8+u3Q1gzzwD6Ahg59kzKhv27N3sOns3u8ae
mdhQbov9XLx7NPbdAew+1rbHAax90wEPAZ5vOGZt2Ahg730XMAfA7mHnhwDYfeyeqwA2FiMAywHs
nU4Aa18QgH5zLiB73P4n8A5I5CjKQWhbjAiYrRX/8TC1RVyVoXuoxADdzwRfiQXaoUZsxE4c0NJc
JAEaqAe6iQ83+UkiSYKWEsDTQiSFhEkqSSPp0FqaQW/JJFmkBbSuVtAEc0hr0gY6U1vSDtoMIR0A
HQF5pBPpDC9FF+hmhZADXUk30p0UkWJSAl2tJ+kFbbEPuYX0hU+jPxlAboW9TchtAPbriL/xkKUn
qJ3+BZb7z5zEZXJD+SA/T9CEKlEQZ0seaZU8FgZokfIX5W3ln2oLg8fwvvEhY61pkGmj6RPz7ea/
mE9YPJZHLC9Z77K+oZVoz9n+Ym9v/8yhOMY4vnK+7SpyVbmuJrRKuCthrjvorvQ08+z1dvM+7bvL
977f7l/gv5SYmfhRUiTp9eSByV8F2geDwUeDl0J3hX5OuTslFi4Kj0JLOWhIhJ8C/Z7H+BZHVFlK
ooKYxHPVdHPEjukxCHIST3yqKCVx1KscoC0oJZ6sflptft9ofj/tEtuRwnwtmh9lm9Y5zaktJIds
IX5KNJ07vSY2kL4kaWuuJbKR4UA3Af4Q7Ar2vrYRk0iLJJ4TbpXFW+Vq+uU+idzK01t5HFZxqpL9
zhcXarSar9jGg5ewx9Mwn6vDqQWRK3T2g3m1QoDLjp7isvF8Sg9BM7Tpz/dEjPQSxxHK38WJQvZH
n0Tz8kjhBf0JIW7nIxPoYP5bWC6UHIotE3Jgy9hIJJIpGSSjZJU0l8GlFRuLraVcqWQgNoeapmi2
NGJX5ppvE7z2jvP0Qeh74QKeWXiB2vPy8OQymkq4dm3tJM0lCZzLaRfcQk7sp9iis2ehT7pOxT7c
tYu2PBVbxlTx07/8Qk9Tt32941+xRz/9NPboP51sjCjZgPbY9PYURVqpBtWoWlXNZ/BpvY29rbdz
t0tDjUOtJkU1oz0a2mVHi+YSr33yyHiboje3ySEQu8vJEbFd+1R7u7ZcasYG6qLzzp6NLYr9dIq2
fPHF2IenpCn22I+x9F9+iaXHfrStc/6T3vfpp/S+fznQni3cSqGZVIDxeT5SolFikAVBVMwmzWBT
KcjSapGkZnZRtBpNHNfMzvNGqwWTKthMRiiHipnYys1CuaoQnLdJHOEtpmra7hVVtTVToLC22yfy
aHx8QPP71jJEqs23YUQZYNpr8+tQdKPozltiaZW1xPLAUew9+gFtrGhn1Qm7Ky+POsSMlrSDyOfy
aW4zldMcnOyKnSujubF3y6jfdchHQ3fF3qFt74p97eNW0jtef27N2k2v0TtjW17btHbNc6/HtqLf
PcDpF8NKNZL0iNNQTuQkKpULBlJu4JNUoVwyaZ+wxtaQQn2H+XeFbGFbqF3IlmsTFsey18ey6an1
3JT4np6KxXF0e6wfn0ozMJ4ZERcNkeHGXqKR3qKIoy3TFa+9TZ/GadTw6Au1DGXbFXDtUtLbtW2f
2wb6t4XS7T37tCwbOqrroLkjtsb6zXP0mNJ3Qn7x8L/Ov/vNCoZDZ7kM/ifuCOjMFzHRJML5ROIV
XtvFHl2jfUey+0Zb5zjahVxnYTxkrFvHaOfN+lO8St3orzdikqYSo3oX7zU1NochVesc8c9WSNzY
7iNGdus2ckT2iO5Fw4cXdR8Rx99Q/SnhReALTwojPo7SJDASHrT/Ic+DrVNO4H0i5xWqaf/daz1Z
Xr1B+lR7CvP7alFb3hKxVdYD2tHWOe4wzf3sVf7M7mzmamBP6YFnL8azjeD5ydQZ2e41ey0J7gRP
KtdCbqHk0Byui9xFKaIRrrfcTxlEb+XukIcro+lIbqJ8tzLBND5hOp3OzZEfUFZy64X1ykrDNsue
xDcTP1JOGz42fWn/OPFX5ZyhVqlNbNn46DSaxk00jTOPsxyy7LHt8Rzyv2W3dAcBmLrb3SanG683
mwSf1o2Ivm6SWS85kgbyvqBj4IMqVb2BvZ/qU1rW9wI4Zt8LNjfjRIVsv0RplWXR++rpPieS40mk
dr+YNIJ6ZTjQPG4rNUeoxWwzOkZAZPtGEI/iixALp0Wo3aCNoIT5cWiWls/+sxYupGWkjAaJDe4S
fcvDfRBO4WzOBJUm09w2dltbbixVaULsfOyP2OXYj9SdwXlz7408/5LCzY3+lDW1+PVnpIJY99iS
2COx7vBGz6Vz6GvX5vO9yrrGHo+d7bqG0+qqevWCA4F/Bnh2CDQyDvLDTB6KFBqogfNTP+fn/QIM
aq5EvF2cQxfTJ+mT3Da6jbsk2iSIF0niqSB0B8eQRYHysmAwdzeaTIZq+sAeRR1lZnsqc2AND7xC
BCp4LQdokPJxsVPW95I7v0anOtBeIUawAVfItLI0m4XK7dp3yLWFXKF2XMdBGyvOPHuAzqobvE54
qftdrbeXrbq6VMd1+ImIEAEehcnByG3N1eaJOzx8upgupcvpSomjV2iIozQ0MXFi0sTkiYHJoVni
vdK98hz/vMR5SXOT5wbmhNZ6nkp8PvmY/0fV71WCiXZVFFMcCZagKvIpiT6jpZoe2pMghlOq6cGI
kVCTcaBvIfGloRx61bGQelNLV8WpvEZHiVpQF+vOBcbOwOZIfNc6B0ihub0msyfN7DZGqMlriVBM
OKYaE13WnLZrWwC/BbhD2/RwCut9AWY5mbqckpVDMSRE6ga3Xzt4YvCz4mfG5D0+8d750YFzTo5+
sHL6iDumStz5nd2ePDRkcujigoIxU3zh9lvzW/bfdteEL16cdtedu+7F/P4V9NYH45ROTkVm9LYN
CdyeMtF2XHjXfDz8qXDa/FH4F/NVOAKUJHARS1uxk9zW0kcudg1zTiJjXPeT++VZrlneCrLItcj7
NHlaXu3aSba4tnirlbfIW/S464x4xnVePC8nS1RyqUkJLm+SSElqkupyuk1JECgYx72qmtrDjoMq
twjN4FDElGq2DvTNlgaGfM2M1XT4q66FxJvROKC1NTqNsREFic2252V79FFlQ5oHIcEENXCFTivr
0C4ht017jFwo3C5+EE4B+uQGwWIlORnym4RS0v96bvvTx7+M/TFu+Zsv/WXl1tdf30j9n05/aklF
j9hr9aT3y4lHZx5cuerAupcnjVxctrvH18snHujVbObGUadjNQmMZ3HQMomwATRiAJWMjQS+NtGn
TF+ZuI/M9ClhlZkzmc2jIDQFXubM3RVoXg9F3MQkCGbCybLVYBI4Mko0WHnOask++km+9lF+1J2v
2fKy0SFSyGSPO18WtSzhAe0jiIrp08j0adC/2lGdDGy8jXJvRqdwKw/SQOzbg7FcWrWeP1JXsD7W
D36/7dGhaCN0Dsxzf7TRRyoibfOMnV1Tual8hSz6PGmuFp4S7XZtknWuda6nwrrOuk3Zad2WsE8+
5rpq1YxWxctpDl81fW2vKJp5sPWDezgqONhMuc1mjud7uAeqvkRBHEXJQqvXf32igPD6VM3GFEGH
vMAoANN1wdYwQ2UORse23CDBfAjhlIx2jIUVAOdTQ4f48ujgINxbE5+IXVqz5vzgD0pLX7grVh+r
5jO4H/dAtfnhwppflvQ62arz7Vtv/+txNg9jG2SHB9bAW5Hend3t/Z2T+1j6ufsk90kZQ8bQWWQW
XU1W023KW9Jbyvumsya735plzPJnBfL8gxLuDEywjk1bLLxjPMOdEb601qRZSdDrcOlIqd4TfDnI
BYMGF8NUTfSy/ocNZkfSc5oclHNkXvZlkDAcFeEcuFkGhseEF4SVcA8POELEoJmD5hwzb/amV1P3
7kZpEZ39TpkHQ1TWNxoXGBidMshHTDxTNsEBGqmdhONMv43bBT7A2ag+TDiUXM4Emtrz4wVzPp8e
O/d97GLsX/Bxpm5YtW3l+zV0Sp+1Q1Y++vgru7nPJi2Z/eGyL2P74X8dThfRN1sd6h97KHYmOrl0
/5S/7PvwybV/0/FkC3D5AeCJh2yNFCt8R76jq486UZ0nzZPnKfPUedpj0lPSU/JTylrtGH9aOi2f
l87LTklVRbtDsxiIxWdyaNooO044NJEnKrj+wUiaySgQXFBFAaivmTiTz+ce+CCl9L+IQTNwBq+3
tHFQasvAMb8r02Uo9IVoPpOi0AohRBnzZGQuW/KXaBboD7QsBJ3JXsi17wCtjFG1ZKUWLonSwt4H
Oj7XqVtO3Rn+886rU8Pjx4xovXTzV1Tr/Umf0lkH5/We/4/WrZ94fPu+VUvRb54sBu7cDj7ogxWZ
S5XICzDyIOF6kWFkSNaw7DHSjpR33W/730780n2uxRVyhV7hrkl2WRUNqifDluZL96dn5PFF/pLE
kqSStJL0ooySrJLsQf5BiYPSB2UMzhqcXe4vT5wYmBguTy/PmNRsSvMxWWOyJ7ee0mZS7kzDNP+0
xGnp0zLmNpvXfF7reW3m5S4yVLReZ33evJ/sp/u5/b7Ptc/afJZ7LvFc0rnW59pcyrqUXeAnzaxC
yxD8GoeqZLElw8dggpk04zKT/VYuJzX5OePsHjkDHb52qc8Js3tkDvR621ZT/+4GwXRhdq0nrq6w
g0b9O663QEKBiUIA0YxWIEdopUzkQN64ddETZkoicFMXSgwD3bKAbZzHZtCTKT0erT00o3pMqzuW
DFo5trb291pOfLzHovFTZ42aLMQuv3TvlF2nmvPF3jZvzlp35rbnRnS7f87d3e97afL2P77fWU+7
TVpR0Of+R3qWzOtbc3L3hBUV48rfDzL6ZrrhWMwRo+/jkSHpye3c3WH8TiQT6Vwyl64n6+kLyg7H
QekV9xcp51PZLF1LdYgp1G71p6UpacY0f3ulrb9dYKxxlu+Y8pb6pvEt/wfcafV96wX1fJrDwbuI
N07sI4LPMGLXGJVXGcQ4zZt1Wg5nhTuH+4bLwpPC94eXhleFt4TVsGz2ZTjACpbLVPam793/pzZz
IS8bFG7Lg26ojy0j8Qu6LaOTOASVBRocG2UCRsgUO/BBDKXdRiHvr48qvz1O49T/PdWoOfZC7Is4
jcdWNtI433HSklkfLfuC9ojlxZ6NzYt1yT7Yj86HcruytPrux/d9uEancS5uBwjzoGO7SbOIyzTV
LjNrwHWXVZ3K81avp8EkgLJ+QYu3+mbDgP93RkL3psYCX37dbOCobhPhnTZ4bjpGWB4Cs4rsUz2y
aPRPdcWtozGK4vIm//n26AXYMmhAIZrxb80kxw0Nuclk6tDQmKamk/D59Tb9af+JpF/EDTkGO4YX
CBXiRzCo6dvQUT9+VTQgj4UTkEdyrorIEoR0bX5+vg0s21t7zsM0fIjmo9h79APYXdSlUlcPoSDq
475DUC/wYmx5bOlOHYdpQFjMu8FxZJK5n/D0cBV3D1wjh2GRifDDyBzUzRa66pgP5wuz4y4xAxH6
LgNh8bUjQsG1I7x73brYZqbqQrY32rF6P/5s/Z89EuP9oOiHCG2D9YPq/aj5n/uh0nb4Z+/kvo96
uUD02xcRap21E7TIgRbfAS22I12pI9L6LwoViKdt+xQX37HQ1T6FBgvTPB57WuoloeM3geEtQkbS
NiQYO7RPCqwIHgZpVdO/Rdzd6T3NQhZf9/y0TTArvsgJKd5ubdvH9eboJSYHLvWNfjf7UpkHmoNO
PbUXtCjcB3E1mskC5jWA1qcr0hPzuoq5bdIRCUhPT0tJz0xvldYpLVfM6U/SbM2SadgRTCZOlzvi
SqZd2ye4Crz5ySTL1Kw/bWlAnbwkFFvLbfuTDGtqMgk5U5O5hK6eZK6LrzCZNDe36E+zVWw6J3ZM
hoIe/+kHWn6DfdZ4Ftp7mouRdSrXYKmBd4JpZuhb+I86U5uzUdfhmBRnviQQPW9jSn6c6PmnBj3U
5/3YHxtoP0QHvbTHoIpRt4zwJM4cPW7J3+oOm5t7Mvo3n3vx4aUfLnmkZtmmPqmzx+fnZHa+/+0N
HcIn6SQq0cn0rdjU2IEV+6d0n9P1/oOPPk+TY72H9Erv89iA52nnR56PVZ04Gdv2DHeWmntvHN53
0GOY1xDk/4uQ/zIx0faRtRJRRS7buNyw3LjctMmwybjJdNhw2HjYZGjGNxeyDemmcWQcHc+N4ycK
j0qL5UXKY2qFYTV5WlytPK0+ZVhj2slt5d+WjsmfkM/Fc+S8+Dv5g14RLotBWeF5IqlGIxFFTlZM
RhQMRqMoI/tGUsVtRg4OVaMoptoFBCCNhDS3U8oZFZ7jJBBMZaSLGlCo8gsVBQE+SwUOCF40Cp2F
ScL9wk7hoCAJvxmNnY2TjPcbdxoPGiXjb+/RXym8nD3MndfofonZtWWevtGyC2UeZjmAnjGR+IuW
MVMNqirzUyyBL4q5oh44mgXTAsiWx1QPMT9/CbZHjy7RFBSwO6qrI5CZ03Lh1IAHM9QhxGfIZ4/Q
r96l3348MfpVDn3rYIsMSbtykQ5ex/Vdv57pHbsw3h0x3jbih1S7GLnnYXGVuMa5RdziPGY45jzm
+sTwifMT1/eGc85zrmvKNVUzKkaVe5h/3fl58k/J11LEgUpKkiHN6XekOB0GwZ2Y1JP4e9K0nlYH
DTgOO752/OoQHHDzcURx50oTg7nm1Rn+xFTGOLpkpGcfjZYxx27N77Xgs0w4TQOz1QmswUqFRaVT
Vyc+rKS70oQ0a3pKulN1F/Be3l1Ak7VgAQ0bgwV8guwogL7ndHhEXwENWJIKSMiUWkCNBua7gAMD
u+uEk8VcGdPKYMIEG1SL+A7eX93YzaI2XZ1oBWt4F82mtv13tp9Yvv/he97+4uWPxg3PXnjw8cPP
PDWo8hAG77bnxg9cOad9788mjzsynh+cNXxWyd2Tr2U8ObHfw31ZN2eDV0WkQkQPHo/k/y4CTUwy
N51MM00zT/e+IryivKv+wv+iqq0U81mTyZpn4L1nCXHncSpcQAg5+B25ktfXZWWcMTGulI++kMK+
F/I0mKDY6AMU1BJ41ZUupNnSlPQE3pEF5y02TtGdReyylfW9ofu6HwfuDIlxCLCD1Ny4Xt/IBjoI
kZcq9sX+8cJ22qa64qVnN93397nzj9678Tl71zfpwn/9Rhcc61pdtiX25oHXYm9sKmNyBZJAmAc8
MsBvNiOS/ab1K/GU/Kt4Vj5r+dUu8wJdallq57IU01ni6slwQcuVVrtdxlRggTsh++jvQHnt9wZZ
q3cnmXco6RbMtz3drGpZ1MFjY5VNWcQmOm/sTONEtklgbmgpnIGJgx+azdw6OjX2x7yHL8a2LXn3
5T5Dtxx8UtJ2x57+/YfYs6/tfILyNV9fXAgRhjk6ifbb0H4jGbNvgHmFmVMYje8zGFSVEyWW3Qgm
QOANqIz4KKesUJ9RK9U3VEGdKBYSn1kypvKcF96E8O4n4sIzHr3oW1tTFve8xG3PeAiDlqXB7mS2
JwPBVneAbx9dxbWKfrBzp6Stj/62Lvot2gQk0GlTJT0izSQxQ1FkGRpCBsfGb4X8jFwpvyEL8kTO
ZxRUDKTXcCiOIw2hk77s3Q1Gb/zFcYudvfQsPzg6i+sb3dPwvvY34GkieSbSa5+wT3lP/UL9CZgp
SS76hZ1mKYk9+/tooY9m+2jAR30+0oiwnsIEHV0LiX+D15OaSHzJDGmTbkJaDEkNPO+kMFqjYy2j
dvzi2JusuXg1jruuG3A3oQnu6n6p/4S6uW062MLt4JPa8tiR2KldwN5X49g757vLwdbraDnNeYM+
XPsn/h6qi40SaS1TY9D/+Rhv5qMwwq8cEPgM1dDDIHJg+YqopMqy5DNzDF+9pi4P3DjHzKeMToFj
582Go4EFkXLhoGdOejjrbfNPcAXHj0ePSFp0DLf+ykXu82hG/H2M9wb19/WMZAgiRwxGsyQLGZLI
GWiGkSjSeUUFXp0n5DBIzGu6I45bZXoMA757XUxE86+HKPDidswzE8esXXRwbCc/M7YT7F74fP36
axkN/bwbfvhDeK+NlEWSf7JdteHZCtEor6gZRgPH52lIu0k1GXs4YDznVBGHHSpnjTb7k0Y1CO+1
NSo9mmC1pItpglUuoJKZLyA6k9G9h7r/C1aaHrHQNZC7T6/s+2Cf2GYuY9o7m6pSXp+R//j3/JD1
dcrl07PiY7IBY/IO2mYgOyKh89IViesidBGXyEuUNcoOYb98RvhBuKQYDLLu562meyMldl4Cg1FS
7ZgiKRWWv6KqvACpzHFIwJWRgivwqvgwkTV4SUbIU2VR9pl4RjCI8OZABnqNw17WJ7SMEQ7iBVD4
+tYwLykTyAy8kLvZkMaQw5qYpWvaS8QHmMSdBi8Jm22aq9IwtW04wXX9JPohd380uhYTLnNXooG6
U7y77kfg1xn0LYS+iaTVHjAT6POVEQ3MhPhkQWT8Qzp0I/P4Dq9Hewpb5zBugYhPqO7ACcYgrjbM
IyLJwmo8z049kYEibxATeK/gE9OgGWWKHYWO4hzLY5Z1wl/FtaYN5nWWncJWcZd5p+WgsFc8ZD5k
OcqfNJ+0JC4yL7VwXgu1Ir+spTBf+IvwqEUimmasrr8YsfCaxdLcXgwVSDSa4TnfG7HbixCeE8wW
yFXbzyLPKXBG50R8RBHNCm8hwnJ5k8zJzUsU42eGwgVQkarp0YhhgbBCeEaoFAQ48I5GNNJD+8xW
uJxsIi8DuQXYBN/v60G9jkkPxqXc7GiZp/a72V6ttgxKUu132mxoSUz70fWkGsxKVLcdmI40O8sT
15LiB7Rjx7gHdjrke9iGiWGE2CEs82E+I+w+s/kkHUvHHjsgii0unvhXhihKWh3Hx65c5L989NFo
Kff8o4/ezA8sZEmk+TLTk8LTps2CsFrYwW8VdpoPmEVTc+ZXFZrbjUaTYMJEQjmErJgXSYVWqehn
jDIbgeY9DKpP4y3LgQXNe0AFtF5nIayj+UeZTO+Lw/yjzKRgeAdvJTuUmQooaFm6sV4WQneoOzeD
sRaa4aYdD+zj0vJF8cCB6Pk+gqRd++PppwUVPbm8+VnWh7jPIh7PcoOiSreat9pecLzg/on+JNbI
Ncar9Kr4u/y78Q/HH27LIstSbalzUcITlg3aBucTCW9aTmonnW8mfMB9IXxg+UL7wvlBgr2DYs+T
eFMeUa25qs/ryuW9nkmr45MWd+fohpIuwjOp22yE4uGmLkhtpoI4RBxZDBDiCRw2mmLPok4BG2a6
6Budc4g3hJjS4IrQOOZ01Ozc2HhMCemdDTGmJ9588wlAdmMkqTGytJ72oQPw1wc5tJX4ewVjUQl6
uRv0YkI2x4RIswPGL5w/O3lOpM2UhJ68qafFwkG5V+y5QeUN5Oyv9sCzyXVxa7VQTWANxvVT6KZ6
3xJFpyFdS5PSrEbWB9FeQG2qJYs4ZFcBOqL3BUom/CtMCuj+K05guonutgqF6dwT9KFfTs9cH/vx
14FDDu4b9XIsNodrHz0haZP+8eDqWGzpupH7Jj6yns1hrJ9wUvc7pdIhkR0CQfDbwz/ufzjp4dDj
4TXmNZ6N/ieSnghtDL9Atpk3W7a5X/DsTN4ZPGr5h/9I0pHQP8IfWs5oZ5xf+D9M+jD0Rfhncs5y
Tjvn/DXhZ/fPnlrLVX9tUoZoMSEwKIVMYRGhApGXeNmgGFRN0EQNGaZj6GhuDL+KrKKr1FWGVcad
vq2pe9RPDT+bfjb/avvGcYlcs/3LkXQXgvApiaKU7pLzQOgTIgFjII948+zwxBrVlNygi7p86Ym5
QSu1etMa8CYettQdVLqrRbuk29e6saOPdXfMQ7qaZk5zp/MKUmaQIpDqSMmiPltiFkk2YRP0oIhk
EgTcnN4s6tewSbIEsojJGErAzgNeH49hNkwNMwbYL24G0GliMteZupgjDB5Hrl08vgltkup4x9xh
GsedL7m7cpI9+2+V6yOvfjwPjjMbENHda0/sywY0TJo5rMW6AduWO9+gT3xPB9J3YkWxxXtjr14R
n2jEw0a8xLyyGOFe4KMVlkFt5P5HTNsMR9WjhqOmo46P1Y8NHztq1BpDjeOc06ya6H7zq5bvrOdh
jIoYSZNqNrvF1orJ6zXbvZrNbrJYral2kwlZE8Tbk7eSDJsGic5ZzGaqmOCUduUOByPasNxMB5ip
2ef30lQWM+e8vmEwRpFv86fwg35R5omySFZcAEL2gdtq8NE2Rs5ZOgpzhMe94CyyHBTdhnQHyMFu
dIHgRRCBU7VlEaPJbkuQPQWIJN9ggDG6YDGy66QB1y7EZ0aowfaiw0/QTSffmFBy/0z6t4ux8hPU
P7wsZ9OpJ7mVUWQT3bZ95LB9yyPRLG7l+raT53aZwpT4xhgTiyW+F3n4FvMtnmGecutc88zA1OAS
01bl7fTz6UbFqmhyihxO96cF+wil4jDzWP/Y4GtaVfiMZoG171bDPIsVJyUHEoMG3pyQGAik2g0G
UyDRZBASeOfZiGOiPSHPxtOzETLRzuelqvol2et8WM5FxNCba4GplzEsriP2rY0zxZo4X7+AbNRK
4iut88Fw+/OYXWyIMRA9/IIIQ76sWVg+EtMwGjWptunZXCr84aEGew2emgCPaCKLI264eHTgmr4T
nxg7LnbxX5Tbtm7ncws3zR3eb+TA+tjV2Nd3Ph96fXrh7OJbHx/cufOzv778a86L3R4dMXx+u+zO
Oet/3huLsQxvej2WKJP83SJihZWvMLtHAS133ivJ0JlwEDHfw/3K1YNZepXOcXl9XSVlchmNbtRC
ORrLFqbEWonlO3dCbYGODVuY6dguMjWS8Y3lnPOSckn93SJmKUbKSXk21WhobjabfG7KpbrgDk+4
LiihZOtSUle2IR0bjESnNV1JE4B6smYooKKdgw/AAmbJO7Fp5MMgc1LmyL3u9IL81PXRVhTqefel
g4c93v3Awvc3PvHVdOgC4vGVfW/bXcvvqjN+/vu8yZ9RH9odAq0yv5RCjkVS98gfyt8rfDOSwWXy
GWKG1EyZQ+4VmXkGX5IiE0kWq+uHRUbIPBeE54NrDt0Urk+eZ0qqKPNxlxEGUMEh4YwwVTvT++lO
LE/4CZTwm1HOkjvL98s75YPyT7Is/yYgsS9VaCvMRNL/XqFGUASv2uBEavQhNbqQ4k6k/+Y8gruI
/cNdFFclmI8I4O7A/3QklvJuLPAxvTXuHYIacXTjBvQZKXXCbjZX9OFI5WKe9iIl/C1ysVKi9tKW
yo+aFKfiUhNNw5Q7VVGDdNYcmvN+4X5R8sleW4KzmZxpS3fm2do7S+RblF5aL1uJs8RVqgzTSm2D
XROk8fJ88gDPbpgjzzBNsy4gC6Xl6nLrcm2Baw2/Wt3Gvyy9LG9TXza9bD4sHZJfUQ6bXjO/I70j
v6UcVd8xvWP+mD+DCODH6hem0+bv+fPSOeV79ap01RSBBcBUVaO9h6bZZCmA6H813fOqvcTlcsKn
wq41t5dYrRD4fHM7/NfIgVFkcEOXZiWKzanIJtWqSTxRZJd2gH5GrPTziEuzRCwDLMstmywvWw5b
3rMoFp/bxa4SXFXfQzTRm8AmhTFTnexBFQg2M5WVaa4MwFDzobuyH+h9dpbIHPdINbt+hIPp8XPx
Uw2TNX3atFw+1+HO7eBo2OrKrMy/v7d6okV0bq4+4BBNszYeOvy2S3RAqNT137CB313XfM2T/CdX
LgqJGzdeq7mRvo1kf+ThDuLD4tPGbeLfoQOL1K2259sLHUQsOBH6qH0M4zFDj4p/5/4unpa+Uy5x
l1UbRyWYGVQSkGwnC6qRyLxBkuOuUVwxMOtLgBXGPKbwnDC3qEGG+UUkGlCHq8vVTerLqqj6zBob
LBNjHiw9q6wh3or8LCYk4tslYl896Nrg/bTipw/GNGjBUOn1/zA8sh/QY7Gx52hzmvNhbCw98SNs
3izuXPRHzh3NrDvGTWJ6MEUGLhGe0ul3Z+R2ActnVgpbhdP0tPwjPS/Dd0t4q2iVFnAL+OXicmkF
t4LfJG6StnE7JAs0/FQ7zE2KNE/o+jISKWClU14SRSScgTlCHSOiAgzrGlFpEOklSoR5j7ruC3Kg
0ngfa30w5XweMC+fF5IUOIH4jQfeGdZhMH8EcXRcYEEcdhCf95BuV+ZSG8fF2pzD0qGh78VyuX/w
3aJrufF1r0fb6H2bi77dhr6pZHTE3ZMbyo3n7uMEeKlltBsOZ1niEFWs3IvYi+7VirhUgjXAnCxI
hQp8RxBXhgY221dPbqnRkRa4ytzQ0Xw0tcETzVqV244yDwMNueZy30bb83uiQe7XncJxOBg67GTt
oaORX1qBhDoZfhSbJKscLyC5V5PEJJnYIVNWRExEEJuhqleZ1hBrYj4UFmpreKXu0sDbGpxkdDSf
EV3JTYktk79df+X2Bvu3e2wZP1F/T4dIIl6CHGIY+QKfRDm7KDQD9p2UEM2qjxsneL7upon3iaKL
+vN1hwk/se5zbkp0pTTlcmCd9AI84wxnetSXY10T85IHIlaeoA8GpDlSrxAPkLE0R91CRx4hBgTh
tnUsIMbyQL4V7hKmIG88SM5G7jzmOifXyjx5TNjhe109HRDMKg1Ekvk0xZXgSTYm+PEuzW4P2OEl
J5on2VrsCRsNssNuSO7EG4kjwZ5id0xICGjWWVPt1O5L8becCobmDfWbH+c1etafLoGhZTA2wyww
zNwFVoxPnfLA9eQFdJspbD5vEqg4PUnwtyZe1Z9JEsXk1vBEeDIbrBd42noNmhOxB4KUC9Lk3kiD
dvWmUODRWuBsFmHpgLoal9YYVkKcHsmKkK3ucDpvY4kiDaGkOYN/HbPs61WXX203SQsezDySYB49
eNe5BwYM+eDasr/889IR2no3wi11P52YfyfymL/2xS6d27YD5hpHHq+/KNyBfGsWt30t0ucxcZf7
E/d58YJ8RbwKmbpHPapyAhtP3p+mOBBA9buMHodG/J145Da5MJBGjz5cvoDNEdCyrc9YOas3uVXD
0DV4SnXbI/8CrI/ChhwPloDARinBx0YpQcWw+ARPa+qWXZnEK/pbNxmlRCBdEvX3FhM5e2+SZP/v
o6Tn0kBXg4c6JSM9A5a8l7I4ezyJgfa4/Zcxy75ZffnVtpO14IED5YN3fD9/wJBT/Ch9gGLvsQGS
+tV1iIV8VP3u+e0YHYajW4BrPRDX9pANkX5jjDONqzw7yVbjQY+0T6hSqrR9jr3Od/h3lDP8GUUV
FZi6Jo/FZXrWaLSEVdnzLCGuThzcF1PxLJ/P3jJbOixxktfbasCNuMUEVzzaEEW0gWFV3Aa2OnlF
SNPSnLw9k1gVbGDgZ8LUtzRiUQOSXI81kIZQA4sy2uGo7yD0OLhje+zaE7TP+Rf/9ubTY/eOeu1E
l9mbgoXrqLojRgd03VNa/sm0J2O/2LCAgiPT0d8I8MGO9RevRLrVyJdkrkI4oJ5UP0/6RRUDkUTQ
ldNB+IREh9NmtxQbrCQhbJDthkQQk9Ue0Gy+oLflg4yAAj3aoZezmbj26DTEsIHRDv61Gp0F6RHe
OCa4/QwT/IK3NXGr3kziExNbE4+c0NjTRnpJSqZcMk3sDZ7n6E2THTdhAnT5JtTCXDleegOtLL6J
Vg7+O0Khv12pop/dRCcP1X8j3AI8cIFOXo30L3ENdh0w8UuStghblB0mFmR6xXYi4YwRGVA0D/LO
5UjwWC0BkzuhByxHzo8hcoQ5o+dZV/FUEzX5AtZns6VChgrJ7W5mMzXg0jBe4kYhGyTGcJg404ep
uTeJt9sQhFLS7bwVo2QE0SSqCZkkSRMdIB0TSCdJ9rNRy6JxG/xGHEln8SjwEbvNFdJD1B0gbVju
qSTkf/33J39Z/mjtmr//VhcbubF872nkBLR8ZOq0rb0nrqHuTU9R34ZYTeyzZjPfGHEffd7/2HNb
4zTyPOTjo5ATblIeSVI1qhk1U9AYNLXHqpfB2ivKUUWVZGqyOCElqyPJLsh0SwOFwNMg0ECCw+hw
cs4BXq6VR6vV6tDjd5hJzDJD4vTASnrSHGOISNJvl8sSZ6/jehKkJWT5psuXx5za9dAjf51a+mhf
ejBWzJeva/vlR4/6d+d0W13Vc10dE2zAcdhMEciPFKwhuhJJ39asRv4u+XdZeEx4Ta1yv6N+3vJX
9afknwI/BeEHAOtrwRcrjur6q5FcT4KXT0wNY+VZC2Nqc2txOhMkLYD4ieEEa0pqwDHB6svxFjeP
43/2Tfgfl/xxAoD4uKATwI0ZDrQjGGKbjKykkNMlqMFQIJQc4iUlPUto3pokuVIyqdORoTbPJJli
i9bIX0jMJM3k9Ew9h1xPIc/KylyIX1ystISbpRVt0VtoyYV701bhm8iE2bxN6CTXpiG77nqWZvsO
8KP9D3RjtTWLnT1x8v3+308evDY7O+XfkVHd+dh3D0RW7xp/qP1t7XNzl0yFCfan7KF6TLMAvMZN
VkVyjsoYackRUPgENyWOTpLsthgYBZnNU40rjJzR5+XcAZoNPur1NHLPRvECeamzFiRgF+qKB0Yy
ATzJqCKazku2dMRnWwMvHRArIIzMhjHCOIsuwdFbdIoJvYkrQeBvEL162IHhWAJLioMnBRFPkIls
W3dgwH9NG74h4LUfCNzWetS3vaR+Uf/CJ0YWt7v3QHQFt+TZcd0OLIvq8RaObIR685auQzlIQcRh
O2eExpgu8JIkpsvEoJyDc/835Ab9IAa4H4jXWX48rk3VRGtqo9fVNX3Zk27zQ2GjDatIIOfS6Uex
E/Qi7RC9eHt6xu23Z6Tfzh9ZV1ewTrxYWFCA/wKG77tirfi9aAOT8fdHXAYLfcv6g/iDhffCzcv7
z7moAnOuOmIwGiQ+rFnt55AI9xu+YkKMvgCtpo59+iqI5MP76ZDGJP7vWBSnL7K2dF0IOh+TWjqH
+jNglckCVliux1gR/IDTHCzvrTFepTGl5sau7Fo/qeyhXrF0btUjr2+9ly4ZnJExmEGs90utuj59
mL9rXV1mrObLEfKR610DLrDVnNuAQwayL7JAloZKs0V+sfik+KT0vPi8dFo8L16WlE+ljxTubYmu
FZ+SuE+l7yWItApxp7xTOSi9Jp+EC6BOVhXJIHMu0SmtkuCcFWQ5YFfAuKD2imftAi+oPGSxKEhY
K29QoG4a8N0Zg4njVd4QoExVMBmz3/kKqSXufJvGYgxuqIgsyJCX/ZaMqJamwuOEnQLPCiInZNp0
5F9Om94Y3ApR27sHOO/l6A9cej2JfgtdxMCJ0WvR7dzQ6HZdF5kDXPoKfZVJ90gIbg+gEYmjEdCH
/wE6f4D2x5cjvmYxN0SFOu3+JK5kMOLQftZ+vo5P0MzBRdlCJ6DT32NVnELLxKr1V/uCQTbmm81D
vsrZyFS2FsSf4g+34FsILVJahMfIY5Qx1jHaJN8k/6TwpNSZ8kxlpnWmNs83zz8vPC91EXKEFlkX
aSvllcpK60ptq7xV2eXbFT7sOxx+1/el7yffVd/VcFaq38ALaaFOkqeTxQLpIKUlJSUmOgxIO38l
YuppC9ppxE7vgT5eTU9XJfZMYufNPVV/MJFGEuk9iTSRXejJpeHCKz3BFNL77qelcfRkoZ58pJVN
m5afPzs6G5iKo9lRtgRRt3+xQ5gBeccsCZZNgE7mSViGwZZn3UDqIHomGmVbj819FxfdOjpUNqZr
z7GbTamutvcWrO/kzp3VTiirJ5vnPTgrf+yDfebuq9vLXburOHVTdXQ1d3VV26ql0fvjMhIDi29L
MP1heSOvs3kV3umygdNh7YTJYDYFkB41VV2hcqrPzbkaeF3Cf+Z1oLkGRVGTNQV5O5psbk0tqi3O
5bIauJzdIYgOwdZbtIvO3sThvJnLEfQfzmQ9A/iGnutMbvRzXRtYnFBWu/CJCS9c+W/8bQj0xdno
F8s13REZsoZ7WnhaWWMQjtFj3DHhmHhcPq4cNxw3HjcftxzXjtuOOZD0lHDMfYFe0ANkdbRO/Jf8
L6MHca+wJJvCWGTYcioWXSH01XIqTxH96jfuRlW5Ic1WZzXx+Be2VFeKrZks/pXJ4l+ZLP6VyeJf
kJoCNiwWoW/0JVZiCmH5uG2wMIFk6EtIMMuwpbhxF2Pf0ODFX2kw9s2vqysrV6+prARR1dfTfrGq
+vrY7nU/nDzxww8nTv7AbCfEje5A35mufDRy617kq5ziPkoCa1no2eX5wPOT+LP8nfuarMB6Soxr
zYkJDqfXCq0Z2rJsk6A5GzWLN25ABe3WgKZl256xcTZv4E8LCmZ1nNkydQj//0l1ZlozZfozZVqz
rj+jxzrzbcCERtVZZKozuVl11rPBdTq4bkIBHf7vNlSsn2SNNbvBimL6Vj9d32LypzpS/KS81X0O
doVQAX0LdkWiYGRalh+GBTMwXX6jzWMtZqalDCvTaLM4bBgXqy/giatVyTepVX/6rDE4N2pVcasi
bl8y05IwI1M3LQkzMpsMTaN9KTD7Eise/3d16f9sVVz5ja+4Sf+5Cp4QAf7YkNGVBeXHjGXcRrNB
kTiDgXBmMAZOIhDKAaRc+BycDWLGaz8cNxwbNJ+G3BhgBZMzAPzrmSNxJdBiFUSrYO4tWkStN7HC
d/OngtNI925o03Emd/XAkG8rysv3ZPvHvz0cFF/xWCA2pV7ZsiV6ry5/toPW26K9zenQyG4uJZtk
02wuu3lntbOhfXL7wJgUfEsj9T7rfdqM0IyUGeEZqSsdT2fszDhgr3bsbf6R+pHhnIqVmWqtIZkJ
TbYoWk1SsXKMWhOsbh+W9TdLaObOx8L84mBx6A4yKDgoNJlMME4wT7BMsJYHyoNzyRzjHNMc8xzL
HPccz6zArGAFPrizi+wP7g8dM3+CZffpvZWUgMUgeAWLzRBITJHdG4cnzPKGnTL0mMSIQSBCuJnR
/UoP+A/37ZuaRtN8WRAk+yLGbBu1TSDezFYvxhUwfZkKU3Fms6XrMEOQU4WoEvxaGGH4FllISUex
tr4M0eFzJOYQMUPOoVgrkEOTrSj67d4cKqULOURJNWDde4pqSNICOSQ5YLXoHh5908iWWFyeLWlL
BivGmjZkbnLpGfEVw/qaILAnd0KAYq0qlsGEU7ZPvTrk8XlJSTMiC99v3+HjX/c8U/3c7MWd8hbO
f7Gk5OvfP+n8Vq/OdxS1DAazfbm3FheNqqhqu6PbbQX5qanZrQp7977nrwfjcmkE5rSreAT+jXkR
RwVZIj5NVosvEBEJS7xHTUBGSt4rBk1NtyJV6cmIIQHROzIhCBuvmj4SsZrtAZP8Q4CtkfX2a/Ro
sMXUtWVs6bP+TQHmJLuuGrqcyGVyCfbWxCEltG5UDRuMESyS0HWSeBZd3DoVuj48u8OsI6PZStcD
9LeYNTKp15LVLTu4hlVW0yPr6JFYwbpY1yX3tB0c789y9KcNvnXmIk9E2p6QP3dwAfhIdUlrAl1B
2hpdHL62eBh6js9tMgeMBkO2+iAc57zqTWiY/LK4PcG4bgOBge/m/ylrWUiMyVrCZG1jQpbuzGuU
tQKTtbSprEU8th1Te1lHG4Jl7TvYhDYHhn1x96jNEcjanFHf9hbKrm3+vaJiws7L3NToHFgT+x/n
ljK9TI+RoW8S2RJpvoBfwT/Dn+ev8mIPbgg3no4Tt0MH/E68TC6JqiKqcErDcY7Mn/plkWZQFINQ
XEkACTVY6SBJ7ABWCDzu+MiUBDaDWLUgiQdohPA0ErHCCYlvsFVSASuZFzyphxH0QNiF/yUMBkWk
Maga0oMIiDrG/O/QB+mSAzG3UFa3jJ95bXN8rvC5BKEa/XEgnrwBUXr9eyCCTJD1aVXtXoPX7Len
q83NzSx55t5mRJKRIzHZON40CwvA7wcjWEwW07XSGutbVixBlb5D+P6KeEX6w/KHNQWfh7SWcCX8
J4ZPjadNsmBDooXZBJe9EZ+skBwWM/R3TRU05j43WwTiuMf0IFat1VgC5qlyQJqaaqKOQI978AE2
jtRQJz4UUIYEqbpo9IInWhZns4zTerOzu2SDPUDVh9avcwQ9nqzHkvRQEjYNkaQT+16cmOivev54
2D1p+SsvfZIiBg4IZdGhGzeyRZxse20z997GDdEcNtcs92wDxsaIeOjjjPvySjOxudRczlTy5LHI
xx8nzOBnCGu5HdwO8QXpBblaPCjtl4+Ln4nfG/+QLxl9YbGdOI4bKz7CLRK3iZ9yPyjqfwovBRDG
YOGlwJ/hJSkeXkIiYDy8hJjSy3pMqUHLbggrsVV8/3tUiekWNwWVrJ/SV2Njf0GE1P9hbB5999fY
LnzFzhl7jN4bjUW30tdYj0kw1kp4EWNgJx9HVjyGD9K9QD7FAp5epJQ8Rir4ZcJj4mP2tWQt/6T0
pPwCv0t4Qazm9wv7xePCcfGMcEZ0qVAgdSJgA8hzdrtgslsa6IBoSCZDukcA69ixop3wiGnoxGA3
wHVrtaPfWKhAC8X+4nDxHnG5KIo+pwnhF2TR9Y1TRE1Z3vXIWl/GIhhHZ6kGLKmMfeSCRZtYImM8
lwOOMKxr1APEzP4rS2skELY0VjeNOyBBqe5dpFUPPRjr/9gfRwd371sybNlMT0shBznMJdf+GXv1
M+sWT0lVVzY+iJ3ga3VliEsNjzh2cG9zHItJsclsjElVIyYlsZhUNYtJGeIxqWIWkypGTIp5Z+Gc
/T/FpBZzL0ZH8yuj/bjjO9kipbof9ZgU56o/xVWztADCYjkf4k18EtroFZZ9pL+kkY9ioRlYH+fa
jC9CXMHHa5h/Qv/V72H+oH/zG4RzWNcEDvW/fTno5u8G/f9+NagDaO3G7wVFSLf/5UtBt+ELjex7
j0PIUKDiMHIHuRNfPRqut50CW8Fn8ZOwWpz0H9q99JZbs/rec/fI0fewOWv4sW8r0zGAmYBFgFWA
LYC9gKOAjwA1gFoMkABwAlIBbQFFgEGAMYCZgEWAVYAtgL2Ao4CPADWAWgyeAHACUgFtAUWAQYAx
gJmARYBVgC2AvYCjgI8ANYBa4JgAcAJSAW0BRYBBgDGAmYBFgFWALYC9gKOAjwA1gFp8Q1oAOAGp
gLaAIsAgwBjATMAiwCrAFsBewFHAR4AaQC0GUgA4AamAtoAiwCDAGMBMwKL6hh8b3OvH4B9NyilN
ynqa+A31ETG96f7mTcr4suJN17OalFs0KbdsUm7VpMy+JnNje8H4byq3blJm0egb6+c2KWNsbrre
rkmZfSHrxvvZ17JuLEPm3FTOa1Lu1KTcuUk5v0m5S5MynJE3PT/SpAymdtP1bk3K3ZuUgQc31S9u
Ui5pUkYeyk31ezYp92pS7t2k3KdJ+ZYm5b5Nyv2alPs3KQ9oUr61SXlgk/JtTcqggZv6o6vAN+Dz
7U2uD2lSBg+66f7SJuVhTcp3NCmXNSnrHPCG949scn1Uk/LoJmXQ803tKW9SHtukPK5JeXyT8oQm
5YlNypOalCc3KU9pUr67SRkM/ab2Tm1SntakPL1JeUaTMnjZTc/TQwg3jOfsJteZVX4j/d7XpAx/
8U3XkcdyU3keK/8/cFqyGQplbmRzdHJlYW0KZW5kb2JqCjEzOCAwIG9iagoxNzQ2MgplbmRvYmoK
MTM5IDAgb2JqCihNYWMgT1MgWCAxMC45LjEgUXVhcnR6IFBERkNvbnRleHQpCmVuZG9iagoxNDAg
MCBvYmoKKEQ6MjAxNDAzMDUxMTQ5MzVaMDAnMDAnKQplbmRvYmoKMSAwIG9iago8PCAvUHJvZHVj
ZXIgMTM5IDAgUiAvQ3JlYXRpb25EYXRlIDE0MCAwIFIgL01vZERhdGUgMTQwIDAgUiA+PgplbmRv
YmoKeHJlZgowIDE0MQowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwODA3NTEgMDAwMDAgbiAKMDAw
MDAwMTY5MSAwMDAwMCBuIAowMDAwMDYxNjQ1IDAwMDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAK
MDAwMDAwMTY3MSAwMDAwMCBuIAowMDAwMDAxNzcxIDAwMDAwIG4gCjAwMDAwMDUzMDkgMDAwMDAg
biAKMDAwMDA2MjMxMCAwMDAwMCBuIAowMDAwMDAxODY4IDAwMDAwIG4gCjAwMDAwMDUyODggMDAw
MDAgbiAKMDAwMDAwNjkwNSAwMDAwMCBuIAowMDAwMDA1MzQ0IDAwMDAwIG4gCjAwMDAwMDY4ODQg
MDAwMDAgbiAKMDAwMDAwNjk4OCAwMDAwMCBuIAowMDAwMDA4MDg1IDAwMDAwIG4gCjAwMDAwMDcw
ODYgMDAwMDAgbiAKMDAwMDAwODA2NSAwMDAwMCBuIAowMDAwMDA4MTY4IDAwMDAwIG4gCjAwMDAw
MDk5OTggMDAwMDAgbiAKMDAwMDAwODI2NiAwMDAwMCBuIAowMDAwMDA5OTc3IDAwMDAwIG4gCjAw
MDAwMTAwODEgMDAwMDAgbiAKMDAwMDAxMTg2MCAwMDAwMCBuIAowMDAwMDEwMTc5IDAwMDAwIG4g
CjAwMDAwMTE4MzkgMDAwMDAgbiAKMDAwMDAxMTk0MyAwMDAwMCBuIAowMDAwMDEzODEyIDAwMDAw
IG4gCjAwMDAwMTIwNDEgMDAwMDAgbiAKMDAwMDAxMzc5MSAwMDAwMCBuIAowMDAwMDEzODk1IDAw
MDAwIG4gCjAwMDAwMTU2NDEgMDAwMDAgbiAKMDAwMDAxMzk5MyAwMDAwMCBuIAowMDAwMDE1NjIw
IDAwMDAwIG4gCjAwMDAwMTU3MjQgMDAwMDAgbiAKMDAwMDAxNzQ4NCAwMDAwMCBuIAowMDAwMDE1
ODIyIDAwMDAwIG4gCjAwMDAwMTc0NjMgMDAwMDAgbiAKMDAwMDAxNzU2NyAwMDAwMCBuIAowMDAw
MDE5ODE0IDAwMDAwIG4gCjAwMDAwNjE3NjkgMDAwMDAgbiAKMDAwMDAxNzY2NSAwMDAwMCBuIAow
MDAwMDE5NzkzIDAwMDAwIG4gCjAwMDAwMTk4OTggMDAwMDAgbiAKMDAwMDAyMTMyNyAwMDAwMCBu
IAowMDAwMDE5OTk2IDAwMDAwIG4gCjAwMDAwMjEzMDYgMDAwMDAgbiAKMDAwMDAyMTQxMSAwMDAw
MCBuIAowMDAwMDIzODMxIDAwMDAwIG4gCjAwMDAwMjE1MDkgMDAwMDAgbiAKMDAwMDAyMzgxMCAw
MDAwMCBuIAowMDAwMDIzOTE1IDAwMDAwIG4gCjAwMDAwMjY1MjggMDAwMDAgbiAKMDAwMDAyNDAx
MyAwMDAwMCBuIAowMDAwMDI2NTA3IDAwMDAwIG4gCjAwMDAwMjY2MTIgMDAwMDAgbiAKMDAwMDAy
ODkyOSAwMDAwMCBuIAowMDAwMDI2NzEwIDAwMDAwIG4gCjAwMDAwMjg5MDggMDAwMDAgbiAKMDAw
MDAyOTAxMyAwMDAwMCBuIAowMDAwMDMwODc2IDAwMDAwIG4gCjAwMDAwMjkxMTEgMDAwMDAgbiAK
MDAwMDAzMDg1NSAwMDAwMCBuIAowMDAwMDMwOTYwIDAwMDAwIG4gCjAwMDAwMzI5NjQgMDAwMDAg
biAKMDAwMDAzMTA1OCAwMDAwMCBuIAowMDAwMDMyOTQzIDAwMDAwIG4gCjAwMDAwMzMwNDggMDAw
MDAgbiAKMDAwMDAzNDcyMSAwMDAwMCBuIAowMDAwMDMzMTQ2IDAwMDAwIG4gCjAwMDAwMzQ3MDAg
MDAwMDAgbiAKMDAwMDAzNDgwNSAwMDAwMCBuIAowMDAwMDM3MDMzIDAwMDAwIG4gCjAwMDAwNjE4
OTUgMDAwMDAgbiAKMDAwMDAzNDkwMyAwMDAwMCBuIAowMDAwMDM3MDEyIDAwMDAwIG4gCjAwMDAw
MzcxMTcgMDAwMDAgbiAKMDAwMDAzOTQyMiAwMDAwMCBuIAowMDAwMDM3MjE1IDAwMDAwIG4gCjAw
MDAwMzk0MDEgMDAwMDAgbiAKMDAwMDAzOTUwNiAwMDAwMCBuIAowMDAwMDQxNTk0IDAwMDAwIG4g
CjAwMDAwMzk2MDQgMDAwMDAgbiAKMDAwMDA0MTU3MyAwMDAwMCBuIAowMDAwMDQxNjc4IDAwMDAw
IG4gCjAwMDAwNDQxODIgMDAwMDAgbiAKMDAwMDA0MTc3NiAwMDAwMCBuIAowMDAwMDQ0MTYxIDAw
MDAwIG4gCjAwMDAwNDQyNjYgMDAwMDAgbiAKMDAwMDA0NjI1NyAwMDAwMCBuIAowMDAwMDQ0MzY0
IDAwMDAwIG4gCjAwMDAwNDYyMzYgMDAwMDAgbiAKMDAwMDA0NjM0MSAwMDAwMCBuIAowMDAwMDQ4
MTM0IDAwMDAwIG4gCjAwMDAwNDY0MzkgMDAwMDAgbiAKMDAwMDA0ODExMyAwMDAwMCBuIAowMDAw
MDQ4MjE4IDAwMDAwIG4gCjAwMDAwNDk1NDUgMDAwMDAgbiAKMDAwMDA0ODMxNiAwMDAwMCBuIAow
MDAwMDQ5NTI0IDAwMDAwIG4gCjAwMDAwNDk2MzAgMDAwMDAgbiAKMDAwMDA1MTI4OSAwMDAwMCBu
IAowMDAwMDQ5NzI5IDAwMDAwIG4gCjAwMDAwNTEyNjcgMDAwMDAgbiAKMDAwMDA1MTM3NiAwMDAw
MCBuIAowMDAwMDUzMDc3IDAwMDAwIG4gCjAwMDAwNjIwMjIgMDAwMDAgbiAKMDAwMDA1MTQ3NSAw
MDAwMCBuIAowMDAwMDUzMDU1IDAwMDAwIG4gCjAwMDAwNTMxNjUgMDAwMDAgbiAKMDAwMDA1NDk0
NCAwMDAwMCBuIAowMDAwMDUzMjY0IDAwMDAwIG4gCjAwMDAwNTQ5MjIgMDAwMDAgbiAKMDAwMDA1
NTAzMiAwMDAwMCBuIAowMDAwMDU2NzczIDAwMDAwIG4gCjAwMDAwNTUxMzEgMDAwMDAgbiAKMDAw
MDA1Njc1MSAwMDAwMCBuIAowMDAwMDU2ODYxIDAwMDAwIG4gCjAwMDAwNTg0NzEgMDAwMDAgbiAK
MDAwMDA1Njk2MCAwMDAwMCBuIAowMDAwMDU4NDQ5IDAwMDAwIG4gCjAwMDAwNTg1NTkgMDAwMDAg
biAKMDAwMDA1OTc3OCAwMDAwMCBuIAowMDAwMDU4NjU4IDAwMDAwIG4gCjAwMDAwNTk3NTYgMDAw
MDAgbiAKMDAwMDA1OTg2NiAwMDAwMCBuIAowMDAwMDYwODUwIDAwMDAwIG4gCjAwMDAwNTk5NjUg
MDAwMDAgbiAKMDAwMDA2MDgyOSAwMDAwMCBuIAowMDAwMDYwOTM4IDAwMDAwIG4gCjAwMDAwNjE0
NTggMDAwMDAgbiAKMDAwMDA2MTAzNyAwMDAwMCBuIAowMDAwMDYxNDM3IDAwMDAwIG4gCjAwMDAw
NjE1NDYgMDAwMDAgbiAKMDAwMDA2MjE0OSAwMDAwMCBuIAowMDAwMDYyMjU3IDAwMDAwIG4gCjAw
MDAwNjI4MzEgMDAwMDAgbiAKMDAwMDA2MzA3NyAwMDAwMCBuIAowMDAwMDgwNjMyIDAwMDAwIG4g
CjAwMDAwODA2NTUgMDAwMDAgbiAKMDAwMDA4MDcwOCAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXpl
IDE0MSAvUm9vdCAxMzUgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDw1NDE3M2FhM2IxYjVkMTE0NWI4
NzI2NWIyMDE0NWIyZD4KPDU0MTczYWEzYjFiNWQxMTQ1Yjg3MjY1YjIwMTQ1YjJkPiBdID4+CnN0
YXJ0eHJlZgo4MDgyOQolJUVPRgoKMSAwIG9iago8PC9Qcm9kdWNlciAxMzkgMCBSIC9DcmVhdGlv
bkRhdGUgMTQwIDAgUi9Nb2REYXRlKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKT4+CmVuZG9iagox
NDEgMCBvYmoKWzMxNzEgMyA4MzgxMCA4MzgwNCA4MDgyOSA4Mzc5OCA4MzgxMCA4MzgwNCA4MDgy
OSA4Mzc5OCA4MDgyOSA8NkRGMTBBMzVDNUUxODJEQUYyM0Y2M0Q4QUJDRDBBNEQ+IDEgMCAwIDAg
MF0KZW5kb2JqCjEzNSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAxMzQgMCBSIC9QaWVj
ZUluZm8gMTQyIDAgUj4+CmVuZG9iagoxNDIgMCBvYmoKPDwKL2dyZF9Hb29kUmVhZGVyX0luY3Jl
bWVudGFsVXBkYXRlPDwvTGFzdE1vZGlmaWVkKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9Qcml2
YXRlIDE0MSAwIFI+Pgo+PgplbmRvYmoKMTQ0IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBl
L0Zvcm0vRm9ybVR5cGUgMS9CQm94WzE2LjYwMCA3MjQuMjg0IDI0Ny4wMzcgNzM5LjI4NF0vTWF0
cml4WzEgMCAwIDEgLTE2LjYwMCAtNzI0LjI4NF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jl
c291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0
R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDQ+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAw
MCByZwoxNi42MDAgNzI0LjI4NCBtCjI0Ny4wMzcgNzI0LjI4NCBsCjI0Ny4wMzcgNzM5LjI4NCBs
CjE2LjYwMCA3MzkuMjg0IGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjE0NSAwIG9iago8PC9UeXBl
L0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzE2LjYwMCA3MjQuMjg0IDI0Ny4wMzcg
NzM5LjI4NF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1sxNi42MDAgNzM5LjI4NCAy
NDcuMDM3IDczOS4yODQgMTYuNjAwIDcyNC4yODQgMjQ3LjAzNyA3MjQuMjg0XS9BUDw8L04gMTQ0
IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDIgMCBSPj4K
ZW5kb2JqCjE0NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsyMjgu
NDM3IDc0Ni4yODQgMjU4LjQzNyA3NzYuMjg0XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAw
LjAwMF0vUG9wdXAgMTQ3IDAgUi9Db250ZW50cygiTmV0d29yayBXb3JraW5nIEdyb3VwIiAtLSBz
ZWUgUkZDIEVkaXRvciB0dXRvcmlhbCBzbGlkZXMsIHBhZ2UgMjApL1QoVENsYXVzZW4pL00oRDoy
MDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgMiAwIFI+PgplbmRvYmoKMTQ3IDAgb2JqCjw8L1R5cGUv
QW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjYzLjQzNyA2NjQuMjg0IDUxMy40MzcgNzc2
LjI4NF0vUGFyZW50IDE0NiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxNDggMCBvYmoKPDwvVHlw
ZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMzA0LjY0OCA0ODQuMjg0IDQ3
Ny40NzYgNDk5LjI4NF0vTWF0cml4WzEgMCAwIDEgLTMwNC42NDggLTQ4NC4yODRdL0dyb3VwPDwv
Uy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9C
TS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAg
Z3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMzA0LjY0OCA0ODQuMjg0IG0KNDc3LjQ3NiA0ODQuMjg0
IGwKNDc3LjQ3NiA0OTkuMjg0IGwKMzA0LjY0OCA0OTkuMjg0IGwKZgpRCgplbmRzdHJlYW0KZW5k
b2JqCjE0OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzMw
NC42NDggNDg0LjI4NCA0NzcuNDc2IDQ5OS4yODRdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQ
b2ludHNbMzA0LjY0OCA0OTkuMjg0IDQ3Ny40NzYgNDk5LjI4NCAzMDQuNjQ4IDQ4NC4yODQgNDc3
LjQ3NiA0ODQuMjg0XS9BUDw8L04gMTQ4IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAx
OTI0NDkrMDEnMDAnKS9QIDIgMCBSPj4KZW5kb2JqCjE1MCAwIG9iago8PC9UeXBlL0Fubm90L1N1
YnR5cGUvVGV4dC9GIDQvUmVjdFs0NzMuMjc4IDQ5NC4yODQgNTAzLjI3OCA1MjQuMjg0XS9OYW1l
L0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMTUxIDAgUi9Db250ZW50cyhOb3cg
dGhhdCBJIGhhdmUgdGhvdWdodCB0aGlzIGJpdCBvdmVyLi4uLlxuXG5JbiB0aGUgZW5kLCBhIHRy
ZWUgaXMgY29uc3RydWN0ZWQsIHRob3VnaCwgaXMgaXQgbm90PyBKb2luIFF1ZXJpZXMgZmxvb2Rl
ZCwgdGhlbiBKb2luIFJlcGxpZXMgc2VudCBiYWNrLCBpbiBhICJUcmVlLWNvbnN0cnVjdGlvbiIg
ZmFzaGlvbj8pL1QoVENsYXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgMiAwIFI+
PgplbmRvYmoKMTUxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3Rb
NTA4LjI3OCA0MTIuMjg0IDc1OC4yNzggNTI0LjI4NF0vUGFyZW50IDE1MCAwIFIvT3BlbiBmYWxz
ZT4+CmVuZG9iagoxNTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3Rb
MzU4LjA1OSA3NzAuMjg0IDM4OC4wNTkgODAwLjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4w
MDAgMC4wMDBdL1BvcHVwIDE1MyAwIFIvQ29udGVudHMoR2VuZXJhbCBDb21tZW50czpcblxuSSBm
aW5kIHRoaXMgc3BlY2lmaWNhdGlvbiB2ZXJ5IHdlbGwgd3JpdHRlbiwgd2VsbCBzdHJ1Y3R1cmVk
LCBjbGVhciBhbmQgZWFzeSB0byB1bmRlcnN0YW5kLiApL1QoVENsYXVzZW4pL00oRDoyMDE0MDMx
MDE5MjQ0OSswMScwMCcpL1AgMiAwIFI+PgplbmRvYmoKMTUzIDAgb2JqCjw8L1R5cGUvQW5ub3Qv
U3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzkzLjA1OSA2ODguMjg0IDY0My4wNTkgODAwLjI4NF0v
UGFyZW50IDE1MiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxNTQgMCBvYmoKPDwvVHlwZS9Bbm5v
dC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDE1NSAwIFIvUmVjdFs0NC4xMzEgNzUzLjc0OSA3NC43
OTAgNzg0LjQwOF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKEV4
ZWN1dGl2ZSBTdW1tYXJ5OlxuPT09PT09PT09PT09PT09PVxuSSBmaW5kIHRoaXMgc3BlY2lmaWNh
dGlvbiB2ZXJ5IHdlbGwgd3JpdHRlbiwgd2VsbCBzdHJ1Y3R1cmVkLCBjbGVhciwgYW5kIGVhc3kg
dG8gdW5kZXJzdGFuZC4gSSBiZWxpZXZlIHRoYXQgdGhlcmUgYXJlIHNvbWUgY2xhcmlmaWNhdGlv
bnMgdGhhdCBjb3VsZCBiZSBtYWRlLCB0aG91Z2gsIGFuZCBhIGZldyAiZm9ybWFsIiB0aGluZ3Mg
dG8gY29ycmVjdCAtIGJ1dCBhbHNvIHRoYXQgdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gaXMg
ZmFpcmx5IHN0cmFpZ2h0LWZvcndhcmQuXG5cbk5vdywgdGhlIG9uZSBwb2ludCB0aGF0IEkgdGhp
bmsgaXMgbmVlZGluZyBhIGJpdCBvZiBlZmZvcnQgaXMgcmVnYXJkaW5nIHJvdXRlcnMgd2l0aCBt
dWx0aXBsZSBpbnRlcmZhY2VzIGFuZC9vciBtdWx0aXBsZSBhZGRyZXNzZXMsIHdoaWNoIHNlZW1z
IHRvIG5vdCBiZSBmdWxseSBzcGVjaWZpZWQuIEF0IGxlYXN0LCBpdCBzaG91bGQgYmUgbWFkZSBj
bGVhciB3aGljaCBwYXJ0cyBvZiB0aGUgaW5mb3JtYXRpb24gYmFzZSBhcmUgcGVyIGludGVyZmFj
ZSwgYW5kIHRoZSBwcm9jZXNzaW5nIGFkb3B0ZWQgYWNjb3JkaW5nbHkuIFRoZSB3YXkgdGhlICJi
bGFja2xpc3QiLCBmb3IgZXhhbXBsZSwgaXMgd3JpdHRlbiBhY3R1YWxseSBwZXJtaXRzIGFuIGlt
cGxlbWVudGF0aW9uIHRvIGV4cGxpY2l0bHkgImRvIHRoZSB3cm9uZyB0aGluZyIgd2hlbiBmYWNl
ZCB3aXRoIHJvdXRlcnMgd2l0aCBtdWx0aXBsZSBpbnRlcmZhY2VzLiBJIHRoaW5rIHRoYXQgaXQn
cyBmYWlybHkgZWFzeSB0byBjbGVhciB1cC5cblxuXG5HZW5lcmFsIENvbW1lbnRzOlxuPT09PT09
PT09PT09PT09PVxuSSB0aGluayBJIHVuZGVyc3RhbmQgdGhlIGdlbmVyYWwgaWRlYSwgdGhvdWdo
LCBvZiB0aGUgd2F5IHRoZSBzcGVjaWZpY2F0aW9uIGlzIG1hZGU6IHlvdSBkZXNjcmliZSwgaW4g
YWJzdHJhY3QgZm9ybSwgdGhlIHByb3RvY29sLCBzaWduYWxzLCBldGMuLCBhbmQgdGhlbiB5b3Ug
cHJvdmlkZSB0aGUgbWFwcGluZyB0byBSRkM1NDQ0LWVsZW1lbnRzIGluIGFuIGFwcGVuZGl4Llxu
XG5UaGF0IGlzIG5vdCBlbnRpcmVseSBzdHVwaWQgYXMgaWRlYSwgYW5kIHRoZSByZXN1bHRpbmcg
ZG9jdW1lbnQgaXMgYWN0dWFsbHkgbmljZSBhbmQgcmVhZGFibGUsIGJ1dC4uLi4uYXBwZW5kaWNl
cyBjYW4ndCBcKG9yLCBzaG91bGRuJ3RcKSBjb250YWluIG5vcm1hdGl2ZSB0ZXh0LiBJbmRlZWQs
IHRoZXJlIGFyZSBtYW55IE1VU1QvU0hPVUxELyogaW4gQXBwZW5kaXggQS4gXG5cbkkgc3VnZ2Vz
dCBwcm9tb3RpbmcgQXBwZW5kaXggQSB0byBhICJudW1iZXJlZCBzZWN0aW9uIiBzb21ld2hlcmUg
XChwZXJoYXBzIGFmdGVyIHNlY3Rpb24gNz9cKSBcblxuV2hpbGUgSSBrbm93IHRoYXQgaXQgaXMg
ZWFybHksIEkgdGhpbmsgaXQgd291bGQgYmUgaGVscGZ1bCB0byBoYXZlIHNvbWUgcmVmbGVjdGlv
bnMgb24gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiBSZWNlbnQgZXhwZXJpZW5jZXMgd2l0
aCB0aGUgU0VDLUFEcyBpbmRpY2F0ZSwgdGhhdCB0aGV5J3JlIGNvbnNpZGVyYWJseSBtb3JlIHN0
cmljdCB0aGFuIHRoZXkgd2VyZSBldmVuIGhhbGYgYSBkZWNhZGUgYWdvLCBzbyB1bmRlcnN0YW5k
aW5nICJ3aGF0IHdlJ3JlIGdldHRpbmcgb3Vyc2VsdmVzIGludG8iIGlmIHRoZSBXRyBnZXRzIGlu
dm9sdmVkIHdpdGggdGhpcyBwcm90b2NvbCBtaWdodCBiZSBoZWxwZnVsLlxuXG5BcyB3YXMgZGlz
Y3Vzc2VkIGR1cmluZyB0aGUgTUFORVQgd2cgbWVldGluZyBpbiBMb25kb24sIGFuIEVYUEVSSU1F
TlRBTCBkb2N1bWVudCBpcyBzdXBwb3NlZCB0byBlbmFibGUgYW4gZXhwZXJpbWVudCwgYW5kIHRo
YXQgZXhwZXJpbWVudCBzaG91bGQgYmUgZG9jdW1lbnRlZC4gU2VlIGUuZy4gUkZDNjk3MSwgc2Vj
dGlvbiAxLjIuIEknbGwgdHJ5IHRvIGFkZCBhIGNvdXBsZSBvZiBteSB0aG91Z2h0cyBvbiB3aGF0
IHdvdWxkIG1ha2UgZm9yIGdvb2QgImV4cGVyaW1lbnRzIjpcblxuSSBkbyBiZWxpZXZlIHRoYXQs
IHBlcmhhcHMsIGEgZGlzdGluZ3Vpc2hpbmcgcG9pbnQgb2YgT0RNUlAgdnMuIFNNRiBhbmQgb3Ro
ZXIgc3VjaCBwcm90b2NvbHM6IHdoZXJlYXMgdGhlc2UgcmVseSBvbiAiZ2V0IGEgY29weSBvZiB0
aGUgbWVzc2FnZSB0byBlYWNoIHJvdXRlciwgdGhlbiBoYXZlIHRoZSByb3V0ZXIgZGVjaWRlIGlm
IGl0IGRlbGl2ZXJzIHRob3NlIHRvIGFwcGxpY2F0aW9ucyIsIE9ETVJQIHdvcmtzIGJ5IG9ubHkg
Z2V0dGluZyBjb3BpZXMgb2YgbWVzc2FnZXMgdG8gcm91dGVycyB0aGF0IGFjdHVhbGx5IG5lZWQg
aXQuIFNvLCBhbiBleHBlcmltZW50IGVzdGFibGlzaGluZyB0aGUgYm91bmRhcmllcyB3aGVyZSAi
ZWZmb3J0cyB0byBjb25zdHJ1Y3RpbmcgdGhlIG92ZXJsYXkiIGFyZSBvdXQtd2VpZ2h0ZWQgYnkg
dGhlIGJlbmVmaXRzIG9mIG5vdCBoYXZpbmcgdG8gZGVsaXZlciBhIGNvcHkgb2YgdGhlIG11bHRp
Y2FzdCBtZXNzYWdlIHRvIGVhY2ggcm91dGVyLlxuXG5cblxuKS9UKFRDbGF1c2VuKS9NKEQ6MjAx
NDAzMTAxOTI0NDkrMDEnMDAnKS9QIDIgMCBSPj4KZW5kb2JqCjE1NSAwIG9iago8PC9UeXBlL0Fu
bm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzM5My4wNTkgNjg4LjI4NCA2NDMuMDU5IDgwMC4y
ODRdL1BhcmVudCAxNTQgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAv
UGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSL0Fubm90
cyAxNDMgMCBSPj4KZW5kb2JqCjE0MyAwIG9iagpbMTQ1IDAgUiAxNDYgMCBSIDE0NyAwIFIgMTQ5
IDAgUiAxNTAgMCBSIDE1MSAwIFIgMTUyIDAgUiAxNTMgMCBSIDE1NCAwIFIgMTU1IDAgUl0KZW5k
b2JqCjE1OSAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJv
eFsxNi42MDAgNjY0LjI4NCA1OTIuNjk1IDY5MS4yODRdL01hdHJpeFsxIDAgMCAxIC0xNi42MDAg
LTY2NC4yODRdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8
PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGgg
MTc4Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKNDEyLjY2NiA2NzYuMjg0
IG0KNTkyLjY5NSA2NzYuMjg0IGwKNTkyLjY5NSA2OTEuMjg0IGwKNDEyLjY2NiA2OTEuMjg0IGwK
ZgoxNi42MDAgNjY0LjI4NCBtCjE3NS4wMjUgNjY0LjI4NCBsCjE3NS4wMjUgNjc5LjI4NCBsCjE2
LjYwMCA2NzkuMjg0IGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjE2MSAwIG9iago8PC9UeXBlL0Fu
bm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzE2LjYwMCA2NjQuMjg0IDU5Mi42OTUgNjkx
LjI4NF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1s0MTIuNjY2IDY5MS4yODQgNTky
LjY5NSA2OTEuMjg0IDQxMi42NjYgNjc2LjI4NCA1OTIuNjk1IDY3Ni4yODQgMTYuNjAwIDY3OS4y
ODQgMTc1LjAyNSA2NzkuMjg0IDE2LjYwMCA2NjQuMjg0IDE3NS4wMjUgNjY0LjI4NF0vQVA8PC9O
IDE1OSAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCAxOSAw
IFI+PgplbmRvYmoKMTYyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0
WzUuMjAwIDY4Ni4yODQgMzUuMjAwIDcxNi4yODRdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAw
IDAuMDAwXS9Qb3B1cCAxNTYgMCBSL0NvbnRlbnRzKFNvLCBpdCBpcyBhY3R1YWxseSBub3QgY2xl
YXIgd2hhdCB0aGlzIG1lYW5zLCBzcGVjaWZpY2FsbHkuIFRoZSBtb3JlIEkgdGhpbmsgYWJvdXQg
aXQsIHRoZSBsZXNzIGRvIEkgdGhpbmsgb2YgdGhpcyBhcyAib24gZGVtYW5kIHJvdXRpbmcgdGVj
aG5pcXVlcyIgYW5kIHRoZSBtb3JlIGRvIEkgdGhpbmsgb2YgdGhpcyBhcyAib24tZGVtYW5kIHRy
ZWUgY29uc3RydWN0aW9uLCB3aXRoIHByb2FjdGl2ZSBtYWludGVuYW5jZSIsKS9UKFRDbGF1c2Vu
KS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDE5IDAgUj4+CmVuZG9iagoxNTYgMCBvYmoK
PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs0MC4yMDAgNjA0LjI4NCAyOTAu
MjAwIDcxNi4yODRdL1BhcmVudCAxNjIgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMTYzIDAgb2Jq
Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzUuMjAwIDY4Ni4yODQgMzUuMjAw
IDcxNi4yODRdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAxNTggMCBS
L0NvbnRlbnRzKFRoZSBtb3JlIEkgdGhpbmsgYWJvdXQgaXQsIHRoZSBsZXNzIGRvIEkgdGhpbmsg
b2YgdGhpcyBhcyAib24gZGVtYW5kIHJvdXRpbmcgdGVjaG5pcXVlcyIgYW5kIHRoZSBtb3JlIGRv
IEkgdGhpbmsgb2YgdGhpcyBhcyAib24tZGVtYW5kIHRyZWUgY29uc3RydWN0aW9uLCB3aXRoIHBy
b2FjdGl2ZSBtYWludGVuYW5jZSIsKS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEn
MDAnKS9QIDE5IDAgUj4+CmVuZG9iagoxNTggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1Bv
cHVwL0YgMjgvUmVjdFs0MC4yMDAgNjA0LjI4NCAyOTAuMjAwIDcxNi4yODRdL1BhcmVudCAxNjMg
MCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMTY0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9U
ZXh0L0YgNC9Qb3B1cCAxNjAgMCBSL1JlY3RbNS4yMDAgNjg2LjI4NCAzNS4yMDAgNzE2LjI4NF0v
TmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKFRoZSBtb3JlIEkgdGhp
bmsgYWJvdXQgaXQsIHRoZSBsZXNzIGRvIEkgdGhpbmsgb2YgdGhpcyBhcyAib24gZGVtYW5kIHJv
dXRpbmcgdGVjaG5pcXVlcyIgYW5kIHRoZSBtb3JlIGRvIEkgdGhpbmsgb2YgdGhpcyBhcyAib24t
ZGVtYW5kIHRyZWUgY29uc3RydWN0aW9uLCB3aXRoIHByb2FjdGl2ZSBtYWludGVuYW5jZSIuXG5c
bkl0IGlzIGNsZWFyLCB0aGF0IGEgc2Vuc2libGUgcm91dGluZyBwcm90b2NvbCBjcmVhdGVzIGFu
ZCBtYW5hZ2VzIGZvcndhcmRpbmcgdHJlZXMvZ3JhcGhzL2dyb3VwcyBvbmx5IHdoZW4gdGhlcmUg
aXMgYW4gYWN0dWFsIG5lZWQgZm9yIG9uZSB0byBleGlzdCAtIHNvLCBpbiB0aGF0IHJlZ2FyZCwg
YWxsIHNlbnNpYmxlIG11bHRpY2FzdCByb3V0aW5nIHByb3RvY29scyBhcmUgInJlYWN0aXZlIi5c
blxuQXMgSSB1bmRlcnN0YW5kIGl0LCB0aGlzIHByb3RvY29sIGlzIGdlbmVyYXRpbmcgdGhlIGZv
cndhcmRpbmcgdHJlZS9ncmFwaC9ncm91cCBmcm9tIHRoZSBcKGV4cGVjdGVkXCkgc291cmNlLCBh
bmQgdGhlbiB0aGF0IHRoaXMgaXMgbWFpbnRhaW5lZCBieSB3YXkgb2YgcHJvYWN0aXZlIHNpZ25h
bGluZyBcKGZvciBhcyBsb25nIGFzIHRoZXJlIGlzIGEgbmVlZCBmb3IgdGhlIGZvcndhcmRpbmcg
dHJlZS9ncmFwaC9ncm91cFwpXG5cbkknZCBzdWdnZXN0IGJlaW5nIGV4cGxpY2l0IGFzIHRvIHRo
aXMsIGJvdGggaW4gaW50cm9kdWN0aW9uIGFuZCBpbiB0aGUgYWJzdHJhY3Q/KS9UKFRDbGF1c2Vu
KS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDE5IDAgUj4+CmVuZG9iagoxNjAgMCBvYmoK
PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs0MC4yMDAgNjA0LjI4NCAyOTAu
MjAwIDcxNi4yODRdL1BhcmVudCAxNjQgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMTY1IDAgb2Jq
Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Qb3B1cCAxNjYgMCBSL1JlY3RbMTEzLjIx
OCA0NzAuMjg0IDE0My4yMTggNTAwLjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4w
MDBdL0NvbnRlbnRzKEkgdGhpbmsgdGhhdCB5b3UgYWN0dWFsbHkgYWxzbyBhcmUgaW1wb3J0aW5n
IHRlcm1pbm9sb2d5IGZyb20gUkZDNTQ0NCBoZXJlLCBhcmUgeW91IG5vdD8gIEF0IGxlYXN0LCBz
ZWN0aW9uIDcgIlBhY2tldHMgYW5kIE1lc3NhZ2VzIiBzZWVtcyB0byBiZSBoaW50aW5nIGF0IC0g
YnV0IG5vdCBjYWxsaW5nIG91dCBleHBsaWNpdGx5IC0gdGhhdCB5b3UgYXJlLlxuXG5JIHRoaW5r
IEkgdW5kZXJzdGFuZCB3aHkgeW91J3JlIG5vdCBjYWxsaW5nIGl0IG91dCwgd2l0aCB0aGUgd2F5
IHRoYXQgdGhlIEktRCBpcyB3cml0dGVuIGFuZCBSRkM1NDQ0IG1lc3NhZ2UgbWFwcGluZyBiZWlu
ZyBpbiBBcHBlbmRpeCwgYnV0IGFzIEkgaGF2ZSBzdWdnZXN0ZWQgaW4gImdlbmVyYWwgY29tbWVu
dHMiLCB0aGF0IG9yZ2FuaXphdGlvbiBtaWdodCBub3QgYmUgaWRlYWw/KS9UKFRDbGF1c2VuKS9N
KEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDE5IDAgUj4+CmVuZG9iagoxNjYgMCBvYmoKPDwv
VHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxNDguMjE4IDM4OC4yODQgMzk4LjIx
OCA1MDAuMjg0XS9QYXJlbnQgMTY1IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjE2NyAwIG9iago8
PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsyOTAuMjQ2IDI2OC4y
ODQgMzE5LjA0OSAyODMuMjg0XS9NYXRyaXhbMSAwIDAgMSAtMjkwLjI0NiAtMjY4LjI4NF0vR3Jv
dXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZh
bHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpx
Ci9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoyOTAuMjQ2IDI2OC4yODQgbQozMTkuMDQ5IDI2
OC4yODQgbAozMTkuMDQ5IDI4My4yODQgbAoyOTAuMjQ2IDI4My4yODQgbApmClEKCmVuZHN0cmVh
bQplbmRvYmoKMTY4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1Jl
Y3RbMjkwLjI0NiAyNjguMjg0IDMxOS4wNDkgMjgzLjI4NF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0v
UXVhZFBvaW50c1syOTAuMjQ2IDI4My4yODQgMzE5LjA0OSAyODMuMjg0IDI5MC4yNDYgMjY4LjI4
NCAzMTkuMDQ5IDI2OC4yODRdL0FQPDwvTiAxNjcgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDE0
MDMxMDE5MjQ0OSswMScwMCcpL1AgMTkgMCBSPj4KZW5kb2JqCjE2OSAwIG9iago8PC9UeXBlL0Fu
bm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFszMTQuODUyIDI3OC4yODQgMzQ0Ljg1MiAzMDguMjg0
XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMTcwIDAgUi9Db250ZW50
cyhUZWNobmljYWxseSwgdGhhdCdzIHByb2JhYmx5ICJpLmUuLCAiIGFzIHRoZXJlIGFyZSBvbmx5
IHRob3NlIHR3byBtZXNzYWdlIHR5cGVzLCB5ZXM/KS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAx
OTI0NDkrMDEnMDAnKS9QIDE5IDAgUj4+CmVuZG9iagoxNzAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T
dWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFszNDkuODUyIDE5Ni4yODQgNTk5Ljg1MiAzMDguMjg0XS9Q
YXJlbnQgMTY5IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjE3MSAwIG9iago8PC9UeXBlL0Fubm90
L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFs0NzMuMjc4IDU1NC4yODQgNTAzLjI3OCA1ODQuMjg0XS9O
YW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMTcyIDAgUi9Db250ZW50cyhJ
IHdvdWxkIHN1Z2dlc3QgYW5zd2VyaW5nIHRoZSBxdWVzdGlvbiwgd2hpY2ggaXMgb24gZXZlcnli
b2R5J3MgbGlwcywgYWxyZWFkeSBoZXJlOiBkb2VzIHRoaXMgaW50ZWdyYXRlIHdpdGggInJlZ3Vs
YXIgSVAgTXVsdGljYXN0aW5nIiBvciBkb2VzIGl0IHJlcXVpcmUgImFwcGxpY2F0aW9uIGxldmVs
IHR1bm5lbGluZyI/IFxuXG5JbiBvdGhlciB3b3JkcywgY291bGQgSSBleHBlY3QgYW4gbWNhc3Qt
Y2FwYWJsZSBhcHBsaWNhdGlvbiB0byAianVzdCB3b3JrIiwgYW5kIGNhbiBJIGltcGxlbWVudCB0
aGlzICJvbiBhIGNvbW1vZGl0eSBPUyIsIG9yIHdpbGwgSSBoYXZlIHRvIGRvIGtlcm5lbC1sZXZl
bCBoYWNrcz8pL1QoVENsYXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgMTkgMCBS
Pj4KZW5kb2JqCjE3MiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0
WzUwOC4yNzggNDcyLjI4NCA3NTguMjc4IDU4NC4yODRdL1BhcmVudCAxNzEgMCBSL09wZW4gZmFs
c2U+PgplbmRvYmoKMTczIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0
WzQ3My4yNzggNTU0LjI4NCA1MDMuMjc4IDU4NC4yODRdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEu
MDAwIDAuMDAwXS9Qb3B1cCAxNzQgMCBSL0NvbnRlbnRzKEkgd291bGQgc3VnZ2VzdCBhbnN3ZXJp
bmcgdGhlIHF1ZXN0aW9uLCB3aGljaCBpcyBvbiBldmVyeWJvZHkncyBsaXBzLCBhbHJlYWR5IGhl
cmU6IGRvZXMgdGhpcyBpbnRlZ3JhdGUgd2l0aCAicmVndWxhciBJUCBNdWx0aWNhc3RpbmciIG9y
IGRvZXMgaXQgcmVxdWlyZSAiYXBwbGljYXRpb24gbGV2ZWwgdHVubmVsaW5nIj8gXG5cbkluIG90
aGVyIHdvcmRzLCBjb3VsZCBJIGV4cGVjdCBhbiBtY2FzdC1jYXBhYmxlIGFwcGxpY2F0aW9uIHRv
ICJqdXN0IHdvcmsiLCBhbmQgY2FuIEkgaW1wbGVtZW50IHRoaXMgIm9uIGEgY29tbW9kaXR5IE9T
Iiwgb3Igd2lsbCBJIGhhdmUgdG8gZG8ga2VybmVsLWxldmVsIGhhY2tzIHRvIG1ha2UgaXQgd29y
az9cblxuSGF2aW5nIHJlYWQgdGhyb3VnaCB0aGUgZG9jdW1lbnQsIEkgdGhpbmsgdGhhdCBJIGlu
ZmVyIHRoYXQgaXQncyBwb3NzaWJsZSB0byBidWlsZCBhbiB1c2VyLXNwYWNlIGltcGxlbWVudGF0
aW9uIG1hbmlwdWxhdGluZyB3b3JraW5nIGJ5IHNpbXBseSBtdWx0aWNhc3Qgcm91dGluZyB0YWJs
ZSBlbnRyaWVzLlxuXG5Xb3VsZCBiZSBnb29kIHRvIGhhdmUgaXQgY29uZmlybWVkIHRoYXQgbXkg
dW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0IC0gaWYgaXQgaXMsIHRoYXQgaXMgO1wpKS9UKFRDbGF1
c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDE5IDAgUj4+CmVuZG9iagoxNzQgMCBv
YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs1MDguMjc4IDQ3Mi4yODQg
NzU4LjI3OCA1ODQuMjg0XS9QYXJlbnQgMTczIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjE5IDAg
b2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAyMiAwIFIgL0NvbnRl
bnRzIDIwIDAgUi9Bbm5vdHMgMTU3IDAgUj4+CmVuZG9iagoxNTcgMCBvYmoKWzE2MSAwIFIgMTYy
IDAgUiAxNTYgMCBSIDE2MyAwIFIgMTU4IDAgUiAxNjQgMCBSIDE2MCAwIFIgMTY1IDAgUiAxNjYg
MCBSIDE2OCAwIFIgMTY5IDAgUiAxNzAgMCBSIDE3MSAwIFIgMTcyIDAgUiAxNzMgMCBSIDE3NCAw
IFJdCmVuZG9iagoxNzcgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlw
ZSAxL0JCb3hbMTE3LjQxNyA1MzIuMjg0IDE4Mi4yMjYgNTQ3LjI4NF0vTWF0cml4WzEgMCAwIDEg
LTExNy40MTcgLTUzMi4yODRdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9F
eHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+
Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMTE3LjQx
NyA1MzIuMjg0IG0KMTgyLjIyNiA1MzIuMjg0IGwKMTgyLjIyNiA1NDcuMjg0IGwKMTE3LjQxNyA1
NDcuMjg0IGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjE3OCAwIG9iago8PC9UeXBlL0Fubm90L1N1
YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzExNy40MTcgNTMyLjI4NCAxODIuMjI2IDU0Ny4yODRd
L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMTE3LjQxNyA1NDcuMjg0IDE4Mi4yMjYg
NTQ3LjI4NCAxMTcuNDE3IDUzMi4yODQgMTgyLjIyNiA1MzIuMjg0XS9BUDw8L04gMTc3IDAgUiA+
Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDIzIDAgUj4+CmVuZG9i
agoxNzkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMTg1LjIzMCA1
NDIuMjg0IDIxNS4yMzAgNTcyLjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBd
L1BvcHVwIDE3NSAwIFIvQ29udGVudHMoSSBhbSBnb2luZyB0byBwaWNrIG91dCB0aGlzIGhlcmUs
IGJ1dCBpdCBhcHBsaWVzIGVsc2V3aGVyZSBhbHNvOiAiYWRkcmVzc2VzIj8gXG5cbkkgYmVsaWV2
ZSB0aGF0IHlvdSBhaW0gYXQgImFkZHJlc3MgbGVuZ3RoIGluZGVwZW5kZW5jZSIsIHY2L3Y0L3No
b3J0LCBhbmQgdGhhdCdzIGEgZ29vZCBpZGVhIHdoaWNoIGlzLCBJIGJlbGlldmUsIHN1cHBvcnRl
ZCB3ZWxsIGJ5IFJGQzU0NDQuIEFsYXMsIEkgYmVsaWV2ZSB0aGF0IHlvdSBwcm9iYWJseSB3YW50
IHRvIHN0aWNrIGluIGEgZGVmaW5pdGlvbiBhbmQgZXhwbGFuYXRpb24gb2YgdGhhdCBpbiBoZXJl
LiBcblxuQWxzbywgSSBnYXRoZXIgdGhhdCB0aGVzZSBhZGRyZXNzZXMgYXJlICJpbnRlcmZhY2Ug
aWRlbnRpZmllcnMiIGFuZCBub3QgIm11bHRpY2FzdCBncm91cCBhZGRyZXNzZXMiLCB5ZXM/IEdp
dmVuIHRoYXQgdGhpcyBkb2N1bWVudCB0YWxrcyBhYm91dCBtdWx0aWNhc3QsIEkgZG8gcmVjb21t
ZW5kIHBlcmhhcHMgY2FsbGluZyB0aGlzIG91dD8pL1QoVENsYXVzZW4pL00oRDoyMDE0MDMxMDE5
MjQ0OSswMScwMCcpL1AgMjMgMCBSPj4KZW5kb2JqCjE3NSAwIG9iago8PC9UeXBlL0Fubm90L1N1
YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzIyMC4yMzAgNDYwLjI4NCA0NzAuMjMwIDU3Mi4yODRdL1Bh
cmVudCAxNzkgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMTgwIDAgb2JqCjw8L1R5cGUvQW5ub3Qv
U3VidHlwZS9UZXh0L0YgNC9SZWN0WzE5OS42MzIgMjQyLjI4NCAyMjkuNjMyIDI3Mi4yODRdL05h
bWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAxODEgMCBSL0NvbnRlbnRzKEkg
YWN0dWFsbHkgd291bGQgbG92ZSBmb3IgeW91IHRvIHJlcGVhdCB0aGUgZXhhbXBsZSB0ZXh0IGZv
ciAiVXBzdHJlYW0iIGhlcmUsIGFsc28uIFllYWgsIGl0J3MgcmVwZXRpdGl2ZSwgYnV0IHdoZW4g
cmVhZGluZyB0aHJvdWdoIGEgZG9jdW1lbnQgYW5kIGxvb2tpbmcgZm9yIGEgZGVmaW5pdGlvbiwg
aXQncyBuaWNlIHRvIG5vdCBiZSBodW50aW5nLikvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTky
NDQ5KzAxJzAwJykvUCAyMyAwIFI+PgplbmRvYmoKMTgxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi
dHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjM0LjYzMiAxNjAuMjg0IDQ4NC42MzIgMjcyLjI4NF0vUGFy
ZW50IDE4MCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxODIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T
dWJ0eXBlL1RleHQvRiA0L1JlY3RbMTU2LjQyNSAxODIuMjg0IDE4Ni40MjUgMjEyLjI4NF0vTmFt
ZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDE4MyAwIFIvQ29udGVudHMoSSBh
bSByZXBlYXRpbmcgbXkgY29tbWVudCBmcm9tIHRoZSBpbnRyb2R1Y3Rpb24gaGVyZTpcblxuVGhl
IG1vcmUgSSB0aGluayBhYm91dCBpdCwgdGhlIGxlc3MgZG8gSSB0aGluayBvZiB0aGlzIGFzICJv
biBkZW1hbmQgcm91dGluZyB0ZWNobmlxdWVzIiBvciBhICJyZWFjdGl2ZSIgcHJvdG9jb2wsIGFu
ZCB0aGUgbW9yZSBkbyBJIHRoaW5rIG9mIHRoaXMgYXMgIm9uLWRlbWFuZCB0cmVlIGNvbnN0cnVj
dGlvbiwgd2l0aCBwcm9hY3RpdmUgbWFpbnRlbmFuY2UiLlxuXG5JdCBpcyBjbGVhciwgdGhhdCBh
IHNlbnNpYmxlIHJvdXRpbmcgcHJvdG9jb2wgY3JlYXRlcyBhbmQgbWFuYWdlcyBmb3J3YXJkaW5n
IHRyZWVzL2dyYXBocy9ncm91cHMgb25seSB3aGVuIHRoZXJlIGlzIGFuIGFjdHVhbCBuZWVkIGZv
ciBvbmUgdG8gZXhpc3QgLSBzbywgaW4gdGhhdCByZWdhcmQsIGFsbCBzZW5zaWJsZSBtdWx0aWNh
c3Qgcm91dGluZyBwcm90b2NvbHMgYXJlICJyZWFjdGl2ZSIuXG5cbkFzIEkgdW5kZXJzdGFuZCBp
dCwgdGhpcyBwcm90b2NvbCBpcyBnZW5lcmF0aW5nIHRoZSBmb3J3YXJkaW5nIHRyZWUvZ3JhcGgv
Z3JvdXAgZnJvbSB0aGUgXChleHBlY3RlZFwpIHNvdXJjZSwgYW5kIHRoZW4gdGhhdCB0aGlzIGlz
IG1haW50YWluZWQgYnkgd2F5IG9mIHByb2FjdGl2ZSBzaWduYWxpbmcgXChmb3IgYXMgbG9uZyBh
cyB0aGVyZSBpcyBhIG5lZWQgZm9yIHRoZSBmb3J3YXJkaW5nIHRyZWUvZ3JhcGgvZ3JvdXBcKVxu
XG5JJ2Qgc3VnZ2VzdCBiZWluZyBleHBsaWNpdCBhcyB0byB0aGlzLCBib3RoIGluIGludHJvZHVj
dGlvbiBhbmQgaW4gdGhlIGFic3RyYWN0PykvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5
KzAxJzAwJykvUCAyMyAwIFI+PgplbmRvYmoKMTgzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw
ZS9Qb3B1cC9GIDI4L1JlY3RbMTkxLjQyNSAxMDAuMjg0IDQ0MS40MjUgMjEyLjI4NF0vUGFyZW50
IDE4MiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxODQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0
eXBlL1RleHQvRiA0L1JlY3RbNS4yMDAgMjQyLjI4NCAzNS4yMDAgMjcyLjI4NF0vTmFtZS9Db21t
ZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDE4NSAwIFIvQ29udGVudHMoSnVzdCB0byBi
ZSBjbGVhcjsgYW0gSSBjb3JyZWN0IGluIHVuZGVyc3RhbmRpbmcgdGhhdDpcblxuQSBNdWx0aWNh
c3QgR3JvdXAgQWRkcmVzcywgaXMgdXNlZCBieSBhcHBsaWNhdGlvbnMsIGFuZCBqb2luZWQgXChl
dGNcKSBieSB3YXkgb2YgSUdNUC9NTEQuXG5cblRoZSBPRE1SUCByb3V0ZXIgaGVhcmluZyB0aGVz
ZSwgIG1hcHMgdGhhdCB0byBhICJNdWx0aWNhc3QgU2Vzc2lvbiIuXG5cblRoYXQgT0RNUlAgcm91
dGVyIHRoZW4gcHJvY2VlZHMgdG8gY29uc3RydWN0IGEgTXVsdGljYXN0IE92ZXJsYXkgZm9yIHRo
YXQgbXVsdGljYXN0IHNlc3Npb247IHRoZSBNdWx0aWNhc3QgT3ZlcmxheSBvZiBhIG11bHRpY2Fz
dCBzZXNzaW9uIGlzIGEgc291cmNlLXJvb3RlZCBtdWx0aWNhc3QgdHJlZT9cblxuQWxzbywgYXMg
SSB1bmRlcnN0YW5kIGl0LCAiRm9yd2FyZGluZyBHcm91cCIgYW5kICJNdWx0aWNhc3QgT3Zlcmxh
eSIgYXJlLCByZXNwZWN0aXZlbHksICJsaW5rcyIgYW5kICJyb3V0ZXJzIiBmb3IgYSBnaXZlbiBN
dWx0aWNhc3QgU2Vzc2lvbj9cblxuSSB0aGluayB0aGF0IHRoYXRzIHdoYXQgaXQgaXMsIGJ1dCB0
aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlc2UgdGVybXMvY29uY2VwdHMgIGNvdWxkIG1lcml0
IGJlaW5nIHJlbmRlcmVkIGNyeXN0YWwgY2xlYXIgaGVyZS4pL1QoVENsYXVzZW4pL00oRDoyMDE0
MDMxMDE5MjQ0OSswMScwMCcpL1AgMjMgMCBSPj4KZW5kb2JqCjE4NSAwIG9iago8PC9UeXBlL0Fu
bm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzQwLjIwMCAxNjAuMjg0IDI5MC4yMDAgMjcyLjI4
NF0vUGFyZW50IDE4NCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyMyAwIG9iago8PCAvVHlwZSAv
UGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMjYgMCBSIC9Db250ZW50cyAyNCAwIFIvQW5u
b3RzIDE3NiAwIFI+PgplbmRvYmoKMTc2IDAgb2JqClsxNzggMCBSIDE3OSAwIFIgMTc1IDAgUiAx
ODAgMCBSIDE4MSAwIFIgMTgyIDAgUiAxODMgMCBSIDE4NCAwIFIgMTg1IDAgUl0KZW5kb2JqCjE4
OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgMTg2IDAgUi9SZWN0
WzE3MC44MjggNjg2LjI4NCAyMDAuODI4IDcxNi4yODRdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEu
MDAwIDAuMDAwXS9Db250ZW50cyhTdWdnZXN0IGFkZGluZyAiVGhlc2UgbXVsdGljYXN0IG92ZXJs
YXlzIGFyZSwgdGhlbiwgcHJvYWN0aXZlbHkgbWFpbnRhaW5lZCBmb3IgYXMgbG9uZyBhcyB0aGUg
b3ZlcmxheSBpcyBuZWVkZWQgXChhcyBsb25nIGFzIHRoZXJlIGFyZSBtZW1iZXJzIGluIHRoZSBt
dWx0aWNhc3QgZ3JvdXAgQU5EIGFzIGxvbmcgYXMgdGhlcmUgaXMgZGF0YSB0byBiZSBkZWxpdmVy
ZWQgdG8gdGhlIG11bHRpY2FzdCBncm91cFwpIikvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTky
NDQ5KzAxJzAwJykvUCAyNyAwIFI+PgplbmRvYmoKMTg2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi
dHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjA1LjgyOCA2MDQuMjg0IDQ1NS44MjggNzE2LjI4NF0vUGFy
ZW50IDE4NSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxOTAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T
dWJ0eXBlL1RleHQvRiA0L1JlY3RbMjYuODA0IDY1MC4yODQgNTYuODA0IDY4MC4yODRdL05hbWUv
Q29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAxODggMCBSL0NvbnRlbnRzKElJUkMg
dGhlcmUncyBhIHNwYWNlIGFmdGVyIGFuZCBiZWZvcmUgYSAiZGFzaCIuLi4uLi4pL1QoVENsYXVz
ZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgMjcgMCBSPj4KZW5kb2JqCjE4OCAwIG9i
ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzYxLjgwNCA1NjguMjg0IDMx
MS44MDQgNjgwLjI4NF0vUGFyZW50IDE5MCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoxOTEgMCBv
YmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMTg5LjQyOSA1
MjAuMjg0IDI3NS44NDIgNTM1LjI4NF0vTWF0cml4WzEgMCAwIDEgLTE4OS40MjkgLTUyMC4yODRd
L0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJ
UyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJl
YW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMTg5LjQyOSA1MjAuMjg0IG0KMjc1Ljg0
MiA1MjAuMjg0IGwKMjc1Ljg0MiA1MzUuMjg0IGwKMTg5LjQyOSA1MzUuMjg0IGwKZgpRCgplbmRz
dHJlYW0KZW5kb2JqCjE5MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0Yg
NC9SZWN0WzE4OS40MjkgNTIwLjI4NCAyNzUuODQyIDUzNS4yODRdL0NbMS4wMDAgMS4wMDAgMC4w
MDBdL1F1YWRQb2ludHNbMTg5LjQyOSA1MzUuMjg0IDI3NS44NDIgNTM1LjI4NCAxODkuNDI5IDUy
MC4yODQgMjc1Ljg0MiA1MjAuMjg0XS9BUDw8L04gMTkxIDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6
MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDI3IDAgUj4+CmVuZG9iagoxOTUgMCBvYmoKPDwvVHlw
ZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMjQ2LjQ0MCA1MzAuMjg0IDI3Ni40NDAgNTYw
LjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDE5MiAwIFIvQ29u
dGVudHMoLT4gIm92ZXJsYXksIG9ubHkiKS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkr
MDEnMDAnKS9QIDI3IDAgUj4+CmVuZG9iagoxOTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl
L1BvcHVwL0YgMjgvUmVjdFsyODEuNDQwIDQ0OC4yODQgNTMxLjQ0MCA1NjAuMjg0XS9QYXJlbnQg
MTk1IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjE5NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5
cGUvVGV4dC9GIDQvUG9wdXAgMTk0IDAgUi9SZWN0WzQyMi44NzAgNTE4LjI4NCA0NTIuODcwIDU0
OC4yODRdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhDb3JyZWN0
LCBidXQgbm90IGNvbXBsZXRlLiBUaGUgb3ZlcmxheSBpcyBjcmVhdGVkLCB0cmlnZ2VkIGJ5IGRh
dGEgdG8gZGVsaXZlciB0byB0aGUgbWVtYmVycyAtIGJ1dCwgbm8gb3ZlcmxheSBpcyBhY3R1YWxs
eSBjcmVhdGVkIHVubGVzcyB0aGVyZSBhY3R1YWxseSBhcmUgbWVtYmVycyBvZiB0aGUgZGVzdGlu
YXRpb24gc2V0LiBcbikvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCAy
NyAwIFI+PgplbmRvYmoKMTk0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4
L1JlY3RbNDU3Ljg3MCA0MzYuMjg0IDcwNy44NzAgNTQ4LjI4NF0vUGFyZW50IDE5MyAwIFIvT3Bl
biBmYWxzZT4+CmVuZG9iagoxOTcgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9G
b3JtVHlwZSAxL0JCb3hbMjI1LjQzNSA0ODQuMjg0IDMwNC42NDcgNDk5LjI4NF0vTWF0cml4WzEg
MCAwIDEgLTIyNS40MzUgLTQ4NC4yODRdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJj
ZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0
ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcK
MjI1LjQzNSA0ODQuMjg0IG0KMzA0LjY0NyA0ODQuMjg0IGwKMzA0LjY0NyA0OTkuMjg0IGwKMjI1
LjQzNSA0OTkuMjg0IGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjE5OSAwIG9iago8PC9UeXBlL0Fu
bm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzIyNS40MzUgNDg0LjI4NCAzMDQuNjQ3IDQ5
OS4yODRdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMjI1LjQzNSA0OTkuMjg0IDMw
NC42NDcgNDk5LjI4NCAyMjUuNDM1IDQ4NC4yODQgMzA0LjY0NyA0ODQuMjg0XS9BUDw8L04gMTk3
IDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDI3IDAgUj4+
CmVuZG9iagoyMDEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMjc4
Ljg0NiA0OTQuMjg0IDMwOC44NDYgNTI0LjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAg
MC4wMDBdL1BvcHVwIDE5OCAwIFIvQ29udGVudHMoLT4gIm92ZXJsYXkgb25seSBmb3IuLi4uIikv
VChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCAyNyAwIFI+PgplbmRvYmoK
MTk4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMzEzLjg0NiA0
MTIuMjg0IDU2My44NDYgNTI0LjI4NF0vUGFyZW50IDIwMSAwIFIvT3BlbiBmYWxzZT4+CmVuZG9i
agoyMDIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbNDU4Ljg3NiA0
ODIuMjg0IDQ4OC44NzYgNTEyLjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBd
L1BvcHVwIDIwMCAwIFIvQ29udGVudHMoYW5kIHVudGlsIHRoZXJlIG5vIGxvbmdlciBhcmUgbWVt
YmVycyBvZiB0aGUgbXVsdGljYXN0IGdyb3VwPykvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTky
NDQ5KzAxJzAwJykvUCAyNyAwIFI+PgplbmRvYmoKMjAwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi
dHlwZS9Qb3B1cC9GIDI4L1JlY3RbNDkzLjg3NiA0MDAuMjg0IDc0My44NzYgNTEyLjI4NF0vUGFy
ZW50IDIwMiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyMDMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T
dWJ0eXBlL1RleHQvRiA0L1JlY3RbMTc4LjAyOSAxOTQuMjg0IDIwOC4wMjkgMjI0LjI4NF0vTmFt
ZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDIwNCAwIFIvQ29udGVudHMoU3Vn
Z2VzdCAiaWYgdGhlIHJvdXRlciBiZWxvbmdzIHRvLCBpLmUuLCBoYXMgYXR0YWNoZWQgaG9zdHMg
d2hpY2ggaGF2ZSBzdWJzY3JpYmVkIHRvLCB0aGUgbXVsdGljYXN0IGdyb3VwIC4uLiIgKS9UKFRD
bGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDI3IDAgUj4+CmVuZG9iagoyMDQg
MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsyMTMuMDI5IDExMi4y
ODQgNDYzLjAyOSAyMjQuMjg0XS9QYXJlbnQgMjAzIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjIw
NSAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFsyMjUu
NDM1IDE3Mi4yODQgMjk3LjQ0NiAxODcuMjg0XS9NYXRyaXhbMSAwIDAgMSAtMjI1LjQzNSAtMTcy
LjI4NF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1Iw
PDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+
PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoyMjUuNDM1IDE3Mi4yODQgbQoy
OTcuNDQ2IDE3Mi4yODQgbAoyOTcuNDQ2IDE4Ny4yODQgbAoyMjUuNDM1IDE4Ny4yODQgbApmClEK
CmVuZHN0cmVhbQplbmRvYmoKMjA2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGln
aHQvRiA0L1JlY3RbMjI1LjQzNSAxNzIuMjg0IDI5Ny40NDYgMTg3LjI4NF0vQ1sxLjAwMCAxLjAw
MCAwLjAwMF0vUXVhZFBvaW50c1syMjUuNDM1IDE4Ny4yODQgMjk3LjQ0NiAxODcuMjg0IDIyNS40
MzUgMTcyLjI4NCAyOTcuNDQ2IDE3Mi4yODRdL0FQPDwvTiAyMDUgMCBSID4+L1QoVENsYXVzZW4p
L00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgMjcgMCBSPj4KZW5kb2JqCjIwNyAwIG9iago8
PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsyNDYuNDQwIDE4Mi4yODQgMjc2LjQ0
MCAyMTIuMjg0XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMjA4IDAg
Ui9Db250ZW50cyhUaGlzIGlzIGEgcmVhbGx5IGRldGFpbC1vcmllbnRlZCBjb21tZW50LCBidXQg
Im9yaWdpbmF0ZXMgYSBKb2luIFJlcGx5IiBoZXJlIC0gYW5kICJKb2luIFJlcGx5IEdlbmVyYXRp
b24iIGFzIHRoZSBzZWN0aW9uIHRpdGxlIGZvciBzZWN0aW9uIDkuMS4yIGlzIGEgbGl0dGxlIGlu
Y29oZXJlbnQgO1wpICkvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCAy
NyAwIFI+PgplbmRvYmoKMjA4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4
L1JlY3RbMjgxLjQ0MCAxMDAuMjg0IDUzMS40NDAgMjEyLjI4NF0vUGFyZW50IDIwNyAwIFIvT3Bl
biBmYWxzZT4+CmVuZG9iagoyMTAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0
L1BvcHVwIDIxMSAwIFIvUmVjdFsxMTcuOTgwIDM0OS42MDIgMTQ4LjYzOSAzODAuMjYxXS9OYW1l
L0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vQ29udGVudHMoSSdkIHByb2ZmZXIgdGhhdCBh
IGxvdCB0aGlzIHBlcmhhcHMgc2hvdWxkIGJlIGdvaW5nIGluIHRoZSAiU2lnbmFsaW5nIE92ZXJo
ZWFkIiByYXRoZXIgdGhhbiBpbiB0aGlzIHNlY3Rpb247IGluIHBhcnQsIGFzIHlvdSBkZXNjcmli
ZSBtZXNzYWdlcyBhbmQgc2V0cywgYmVmb3JlIHRoZXNlIGFyZSBkZWZpbmVkLlxuXG5BcyBvdmVy
dmlldywgaXQncyBxdWl0ZSB0b28gZGV0YWlsZWQsIHNvIHBlcmhhcHMganVtcGluZyBzdHJhaWdo
dCB0byA0LjIgYW5kIG1lcmdpbmcgNC4xIGludG8gNC4zIGlzIHRoZSBiZXN0IGFwcHJvYWNoP1xu
XG5PciwgcGVyaGFwcywgaGF2ZSA0LjIsIHRoZW4gNC4zIGFuZCBmaW5hbGx5IDQuMSA/KS9UKFRD
bGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDI3IDAgUj4+CmVuZG9iagoyMTEg
MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsyNTYuMjM2IDMwNC4y
ODQgNTA2LjIzNiA0MTYuMjg0XS9QYXJlbnQgMjEwIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjI3
IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzMCAwIFIgL0Nv
bnRlbnRzIDI4IDAgUi9Bbm5vdHMgMTg3IDAgUj4+CmVuZG9iagoxODcgMCBvYmoKWzE4OSAwIFIg
MTg2IDAgUiAxOTAgMCBSIDE4OCAwIFIgMTkzIDAgUiAxOTUgMCBSIDE5MiAwIFIgMTk2IDAgUiAx
OTQgMCBSIDE5OSAwIFIgMjAxIDAgUiAxOTggMCBSIDIwMiAwIFIgMjAwIDAgUiAyMDMgMCBSIDIw
NCAwIFIgMjA2IDAgUiAyMDcgMCBSIDIwOCAwIFIgMjEwIDAgUiAyMTEgMCBSXQplbmRvYmoKMjEz
IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzExNy40
MTcgNzAwLjI4NCAxNjcuODI0IDcxNS4yODRdL01hdHJpeFsxIDAgMCAxIC0xMTcuNDE3IC03MDAu
Mjg0XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8
PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+
c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjExNy40MTcgNzAwLjI4NCBtCjE2
Ny44MjQgNzAwLjI4NCBsCjE2Ny44MjQgNzE1LjI4NCBsCjExNy40MTcgNzE1LjI4NCBsCmYKUQoK
ZW5kc3RyZWFtCmVuZG9iagoyMTQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdo
dC9GIDQvUmVjdFsxMTcuNDE3IDcwMC4yODQgMTY3LjgyNCA3MTUuMjg0XS9DWzEuMDAwIDEuMDAw
IDAuMDAwXS9RdWFkUG9pbnRzWzExNy40MTcgNzE1LjI4NCAxNjcuODI0IDcxNS4yODQgMTE3LjQx
NyA3MDAuMjg0IDE2Ny44MjQgNzAwLjI4NF0vQVA8PC9OIDIxMyAwIFIgPj4vVChUQ2xhdXNlbikv
TShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCAzMSAwIFI+PgplbmRvYmoKMjE1IDAgb2JqCjw8
L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Qb3B1cCAyMDkgMCBSL1JlY3RbMTI3LjYyMCA3
MTAuMjg0IDE1Ny42MjAgNzQwLjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBd
L0NvbnRlbnRzKFRoaXMgaXMgdG9vICJpbXBsaWNpdCI6IGEgIm5leHQgaG9wIGFkZHJlc3MgY2Fy
cmllZCBpbiBhIHBhY2tldCIuIFlvdSBzaG91bGQsIGF0IGxlYXN0LCBpbiB0aGUgcHJldmlvdXMg
YnVsbGV0IHBvaW50IGluZGljYXRlIHRoYXQgYSBKb2luIFJlcGx5IGNhcnJpZXMgYSAibmV4dCBo
b3AgYWRkcmVzcyIgXChhbmQsIHBvc3NpYmx5LCB3aGF0IGVsc2UgaXQgY2FycmllcyAtIEkgdGhp
bmsgdGhhdCBmb3IgZHVwbGljYXRlIEpSIHN1cHByZXNzaW9uLCB0aGF0J3MgaW1wb3J0YW50P1wp
KS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDMxIDAgUj4+CmVuZG9i
agoyMDkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxNjIuNjIw
IDYyOC4yODQgNDEyLjYyMCA3NDAuMjg0XS9QYXJlbnQgMjA4IDAgUi9PcGVuIGZhbHNlPj4KZW5k
b2JqCjIxNiAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJv
eFsxMDMuMDE0IDY3Ni4yODQgMTE3LjQxNiA2OTEuMjg0XS9NYXRyaXhbMSAwIDAgMSAtMTAzLjAx
NCAtNjc2LjI4NF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0
ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0
aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAwMCByZwoxMDMuMDE0IDY3Ni4y
ODQgbQoxMTcuNDE2IDY3Ni4yODQgbAoxMTcuNDE2IDY5MS4yODQgbAoxMDMuMDE0IDY5MS4yODQg
bApmClEKCmVuZHN0cmVhbQplbmRvYmoKMjE4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9I
aWdobGlnaHQvRiA0L1JlY3RbMTAzLjAxNCA2NzYuMjg0IDExNy40MTYgNjkxLjI4NF0vQ1sxLjAw
MCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1sxMDMuMDE0IDY5MS4yODQgMTE3LjQxNiA2OTEuMjg0
IDEwMy4wMTQgNjc2LjI4NCAxMTcuNDE2IDY3Ni4yODRdL0FQPDwvTiAyMTYgMCBSID4+L1QoVENs
YXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgMzEgMCBSPj4KZW5kb2JqCjIxOSAw
IG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgMjE3IDAgUi9SZWN0Wzk1
LjIxNSA2ODYuMjg0IDEyNS4yMTUgNzE2LjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAg
MC4wMDBdL0NvbnRlbnRzKFN1Z2dlc3QgIklmIHRoYXQgbmV4dCBob3AgYWRkcmVzcyBpcyBhbiBh
ZGRyZXNzIG9mIHRoaXMgcm91dGVyLi4uIlxuXG5BbHNvLCB3aGF0IGRvZXMgImlzIGFuIGFkZHJl
c3Mgb2YiIG9yICJjb3JyZXNwb25kcyB0byIgdGhpcyByb3V0ZXIgbWVhbiwgcHJlY2lzZWx5PyBU
aGlzIG1heSBzb3VuZCBsaWtlIGEgc2xpZ2h0bHkgc2lsbHkgcXVlc3Rpb24gO1wpIGJ1dCBpbiBO
SERQL09MU1J2MiB3ZSd2ZSBoYWQgdG8gYmUgZXh0cmVtZWx5IGNhcmVmdWwgd2l0aCB0byB3aGF0
IGFkZHJlc3NlcyBjb3JyZXNwb25kOiBhIHJvdXRlciwgaW50ZXJmYWNlcyBvbiB0aGF0IHJvdXRl
ciwgb3IgYWRkcmVzc2VzIG9mIGhvc3RzIHJlYWNoYWJsZSBieSB3YXkgb2YgdGhpcyByb3V0ZXIu
XG5cblRoZSB1cHNob3Qgb2YgdGhpcyBpcywgdGhhdCBpdCdzIHJlYWxseSBlYXN5IHRvIHNvcnQg
b3V0LCBmb3IgZXhhbXBsZTogIklzIGFuIGFkZHJlc3Mgb2YgYW4gaW50ZXJmYWNlIG9mIHRoaXMg
cm91dGVyIiwgb3Igc29tZXRoaW5nLikvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAx
JzAwJykvUCAzMSAwIFI+PgplbmRvYmoKMjE3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Q
b3B1cC9GIDI4L1JlY3RbMTMwLjIxNSA2MDQuMjg0IDM4MC4yMTUgNzE2LjI4NF0vUGFyZW50IDIx
NiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyMjAgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5
cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMzU1LjA1NiA2NTIuMjg0IDM2Mi4yNTcgNjY3LjI4NF0v
TWF0cml4WzEgMCAwIDEgLTM1NS4wNTYgLTY1Mi4yODRdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+
Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBl
L0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAg
MC4wMDAgcmcKMzU1LjA1NiA2NTIuMjg0IG0KMzYyLjI1NyA2NTIuMjg0IGwKMzYyLjI1NyA2Njcu
Mjg0IGwKMzU1LjA1NiA2NjcuMjg0IGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjIyMiAwIG9iago8
PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzM1NS4wNTYgNjUyLjI4NCAz
NjIuMjU3IDY2Ny4yODRdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzU1LjA1NiA2
NjcuMjg0IDM2Mi4yNTcgNjY3LjI4NCAzNTUuMDU2IDY1Mi4yODQgMzYyLjI1NyA2NTIuMjg0XS9B
UDw8L04gMjIwIDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9Q
IDMxIDAgUj4+CmVuZG9iagoyMjQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0
L1BvcHVwIDIyMSAwIFIvUmVjdFszNTAuODU4IDY2Mi4yODQgMzgwLjg1OCA2OTIuMjg0XS9OYW1l
L0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vQ29udGVudHMoRm9yIHJlYWRhYmlsaXR5LCBn
aXZlbiB0aGF0IHRoaXMgaXMgdGhlIG92ZXJ2aWV3IGFuZCBmdW5jdGlvbmluZzpcblxuIklmIDxj
b25kaXRpb24+LCA8Y29uZGl0aW9uPiwgPGNvbmRpdGlvbj4sIHRoZW4gdGhpcyBPRE1SUCBSb3V0
ZXIgYmVsb25ncyB0byB0aGUgZm9yd2FyZGluZyBncm91cCBmb3IgdGhlIG11bHRpY2FzdCBzZXNz
aW9uLiBDb25zZXF1ZW50bHksIGl0IGluc3RhbGxzIC4uLiIgXG5cblxuQSBzZWNvbmRhcnkgY29t
bWVudCBoZXJlIGlzLCB0aGF0IHlvdSBoYXZlIGRlZmluZWQgIk11bHRpY2FzdCBTZXNzaW9uIiBp
biB0aGUgdGVybWlub2xvZ3ksIGJ1dCB5b3UncmUgbm90IHVzaW5nIGl0IGhlcmUgXChyYXRoZXIs
IHlvdSBzYXkgIi4uLi4uLkZvcndhcmRpbmcgR3JvdXAsIHdoaWNoIGNvcnJlc3BvbmRTIFtzaWNd
IHRvIHRoaXMgbXVsdGljYXN0IGdyb3VwIGFuZCBzb3VyY2UuLi4iXG4pL1QoVENsYXVzZW4pL00o
RDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgMzEgMCBSPj4KZW5kb2JqCjIyMSAwIG9iago8PC9U
eXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzM4NS44NTggNTgwLjI4NCA2MzUuODU4
IDY5Mi4yODRdL1BhcmVudCAyMjAgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMjI2IDAgb2JqCjw8
L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Qb3B1cCAyMjMgMCBSL1JlY3RbMjQ2LjQ0MCA1
MTguMjg0IDI3Ni40NDAgNTQ4LjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBd
L0NvbnRlbnRzKFRoaXMgaXMgY29uZnVzaW5nLiBXaGF0IGlzIGFjdHVhbGx5IGRpc2NhcmRlZCBo
ZXJlPyBJLmUuLCB3aGF0IGRvZXMgIml0IiBjb3JyZXNwb25kIHRvIj8pL1QoVENsYXVzZW4pL00o
RDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgMzEgMCBSPj4KZW5kb2JqCjIyMyAwIG9iago8PC9U
eXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzI4MS40NDAgNDM2LjI4NCA1MzEuNDQw
IDU0OC4yODRdL1BhcmVudCAyMjIgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMzEgMCBvYmoKPDwg
L1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDM0IDAgUiAvQ29udGVudHMgMzIg
MCBSL0Fubm90cyAyMTIgMCBSPj4KZW5kb2JqCjIxMiAwIG9iagpbMjE0IDAgUiAyMTUgMCBSIDIw
OSAwIFIgMjE4IDAgUiAyMTkgMCBSIDIxNyAwIFIgMjIyIDAgUiAyMjQgMCBSIDIyMSAwIFIgMjI2
IDAgUiAyMjMgMCBSXQplbmRvYmoKMjI4IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zv
cm0vRm9ybVR5cGUgMS9CQm94WzMwNC42NDggNTgwLjI4NCA0NDguNjcxIDU5NS4yODRdL01hdHJp
eFsxIDAgMCAxIC0zMDQuNjQ4IC01ODAuMjg0XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVz
b3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRH
U3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAw
IHJnCjMwNC42NDggNTgwLjI4NCBtCjQ0OC42NzEgNTgwLjI4NCBsCjQ0OC42NzEgNTk1LjI4NCBs
CjMwNC42NDggNTk1LjI4NCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagoyMjkgMCBvYmoKPDwvVHlw
ZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFszMDQuNjQ4IDU4MC4yODQgNDQ4LjY3
MSA1OTUuMjg0XS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzMwNC42NDggNTk1LjI4
NCA0NDguNjcxIDU5NS4yODQgMzA0LjY0OCA1ODAuMjg0IDQ0OC42NzEgNTgwLjI4NF0vQVA8PC9O
IDIyOCAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCAzNSAw
IFI+PgplbmRvYmoKMjMwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0
WzM5MC40NjQgNTkwLjI4NCA0MjAuNDY0IDYyMC4yODRdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEu
MDAwIDAuMDAwXS9Qb3B1cCAyMzEgMCBSL0NvbnRlbnRzKFN1Z2dlc3QgYWRkaW5nIHRoYXQvaWYg
dGhhdCBjYW4gYmUgZG9uZSBieSB3YXkgb2YgYW4gb3B0aW1pemVkIGZsb29kaW5nIG9wZXJhdGlv
biwgaWYgYXZhaWxhYmxlIG9uIHRoZSBuZXR3b3JrLikvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEw
MTkyNDQ5KzAxJzAwJykvUCAzNSAwIFI+PgplbmRvYmoKMjMxIDAgb2JqCjw8L1R5cGUvQW5ub3Qv
U3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbNDI1LjQ2NCA1MDguMjg0IDY3NS40NjQgNjIwLjI4NF0v
UGFyZW50IDIzMCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozNSAwIG9iago8PCAvVHlwZSAvUGFn
ZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMzggMCBSIC9Db250ZW50cyAzNiAwIFIvQW5ub3Rz
IDIyNyAwIFI+PgplbmRvYmoKMjI3IDAgb2JqClsyMjkgMCBSIDIzMCAwIFIgMjMxIDAgUl0KZW5k
b2JqCjIzMyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUG9wdXAgMjM0IDAg
Ui9SZWN0WzIyMS4yMzYgMjU0LjI4NCAyNTEuMjM2IDI4NC4yODRdL05hbWUvQ29tbWVudC9DWzEu
MDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhUaGlzIHByb2JhYmx5IG5lZWRzIGEgYml0IG1vcmUg
b2YgZXhwbGFuYXRpb24uIEFzIEkgaW5kaWNhdGVkIGluIHRoZSBnZW5lcmFsIGNvbW1lbnRzLCB0
aGUgc2VwYXJhdGlvbiBvZiBhYnN0cmFjdCBtZXNzYWdlIGNvbnRlbnQsIGFuZCA1NDQ0LWVuY29k
aW5nIGlzIGEgcG9zc2libGUgd2F5IHRvIGdvLCBidXQgaXQgaXMgbm90IGNsZWFyIGF0IHRoaXMg
cG9pbnQgdGhhdCB0aGF0J3Mgd2hhdCdzIGJlaW5nIGRvbmUuXG5cbkFzIGEgY29uc2VxdWVuY2Us
IGl0IGlzIG5vdCBjbGVhciB3aHkgdGhlIHNlY3Rpb24gdGl0bGUgaXMgIlBhY2tldHMgYW5kIE1l
c3NhZ2VzIiAtIHRob3NlIGFyZSBcKGluIE1BTkVUXCkgNTQ0NC1jb25zdHJ1Y3RzLCB0eXBpY2Fs
bHkuXG5cbk9uZSBwb3NzaWJpbGl0eSBjb3VsZCBiZSB0byBzdGljayBBcHBlbmRpeCBBIGFmdGVy
IHNlY3Rpb24gNy4gQW5vdGhlciwgdG8gaGF2ZSBhcHBlbmRpeCBBIGJlIGEgc3Vic2VjdGlvbiB0
byBzZWN0aW9uIDcuXG5cbikvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykv
UCAzOSAwIFI+PgplbmRvYmoKMjM0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9G
IDI4L1JlY3RbMjU2LjIzNiAxNzIuMjg0IDUwNi4yMzYgMjg0LjI4NF0vUGFyZW50IDIzMyAwIFIv
T3BlbiBmYWxzZT4+CmVuZG9iagozOSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDQwIDAg
UiAvUmVzb3VyY2VzIDQzIDAgUiAvQ29udGVudHMgNDEgMCBSL0Fubm90cyAyMzIgMCBSPj4KZW5k
b2JqCjIzMiAwIG9iagpbMjMzIDAgUiAyMzQgMCBSXQplbmRvYmoKMjM2IDAgb2JqCjw8L1R5cGUv
WE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzI5MC4yNDYgNDg0LjI4NCA0MDUu
NDY0IDQ5OS4yODRdL01hdHJpeFsxIDAgMCAxIC0yOTAuMjQ2IC00ODQuMjg0XS9Hcm91cDw8L1Mv
VHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0v
TXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdz
CjEuMDAwIDEuMDAwIDAuMDAwIHJnCjI5MC4yNDYgNDg0LjI4NCBtCjQwNS40NjQgNDg0LjI4NCBs
CjQwNS40NjQgNDk5LjI4NCBsCjI5MC4yNDYgNDk5LjI4NCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9i
agoyMzcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFsyOTAu
MjQ2IDQ4NC4yODQgNDA1LjQ2NCA0OTkuMjg0XS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9p
bnRzWzI5MC4yNDYgNDk5LjI4NCA0MDUuNDY0IDQ5OS4yODQgMjkwLjI0NiA0ODQuMjg0IDQwNS40
NjQgNDg0LjI4NF0vQVA8PC9OIDIzNiAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTky
NDQ5KzAxJzAwJykvUCA0OCAwIFI+PgplbmRvYmoKMjM4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3Vi
dHlwZS9UZXh0L0YgNC9Qb3B1cCAyMzkgMCBSL1JlY3RbNDAxLjI2NiA0OTQuMjg0IDQzMS4yNjYg
NTI0LjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKFNvbWV3
aGF0IG9mIHRoZSBzYW1lIGNvbW1lbnQgYXMgb25lIEkgaGF2ZSBtYWRlIGJlZm9yZTogInRoZSBh
ZGRyZXNzIG9mIHRoZSBNdWx0aWNhc3QgU291cmNlIlxuXG5GaXJzdCwgaXMgdGhlICJNdWx0aWNh
c3QgU291cmNlIiB0aGUgcm91dGVyLCB0aHJvdWdoIHdoaWNoIHRoZSBtdWx0aWNhc3QgZGF0YSBt
ZXNzYWdlcyBpbmdyZXNzIHRocm91Z2gsIG9yIGlzIGl0IHRoZSBob3N0IG9uIHdoaWNoIHRoZSBh
cHBsaWNhdGlvbiBnZW5lcmF0aW5nIGRhdGEsIGlzPyBEb2VzIGl0IG1ha2UgYW55IGRpZmZlcmVu
Y2U/ICJNdWx0aWNhc3QgU291cmNlIiBpcyBub3QgZGVmaW5lZC5cblxuU2Vjb25kLCB3aGF0IGFi
b3V0IG11bHRpcGxlIGludGVyZmFjZXMvYWRkcmVzc2VzPyBcblxuSSBjYW4gcHJvYmFibHkgaW5m
ZXIgaG93IGl0IHNob3VsZCBiZTogdGhpcyBpcyB0aGUgSVAgYWRkcmVzcyB0aGF0IG9uZSB3aWxs
IGZpbmQgaW4gdGhlIHNvdXJjZS1hZGRyZXNzIGZpZWxkIG9mIElQIG11bHRpY2FzdCBkYXRhZ3Jh
bXMsIHllcz8gSWYgc28sIHBlcmhhcHMganVzdCBjYWxsIHRoYXQgb3V0IHNvbWV3aGVyZSBzbyB0
aGVyZSdzIG5vIGRvdWJ0LikvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykv
UCA0OCAwIFI+PgplbmRvYmoKMjM5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9G
IDI4L1JlY3RbNDM2LjI2NiA0MTIuMjg0IDY4Ni4yNjYgNTI0LjI4NF0vUGFyZW50IDIzOCAwIFIv
T3BlbiBmYWxzZT4+CmVuZG9iagoyNDAgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9y
bS9Gb3JtVHlwZSAxL0JCb3hbMjU0LjI0MCA0NDguMjg0IDUxMy40ODIgNDYzLjI4NF0vTWF0cml4
WzEgMCAwIDEgLTI1NC4yNDAgLTQ0OC4yODRdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNv
dXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdT
dGF0ZT4+Pj4+Pi9MZW5ndGggMTA2Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAg
cmcKMjU0LjI0MCA0NDguMjg0IG0KNTEzLjQ4MiA0NDguMjg0IGwKNTEzLjQ4MiA0NjMuMjg0IGwK
MjU0LjI0MCA0NjMuMjg0IGwKZgpRCgplbmRzdHJlYW0KZW5kb2JqCjI0MSAwIG9iago8PC9UeXBl
L0Fubm90L1N1YnR5cGUvSGlnaGxpZ2h0L0YgNC9SZWN0WzI1NC4yNDAgNDQ4LjI4NCA1MTMuNDgy
IDQ2My4yODRdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMjU0LjI0MCA0NjMuMjg0
IDUxMy40ODIgNDYzLjI4NCAyNTQuMjQwIDQ0OC4yODQgNTEzLjQ4MiA0NDguMjg0XS9BUDw8L04g
MjQwIDAgUiA+Pi9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDQ4IDAg
Uj4+CmVuZG9iagoyNDIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVw
IDI0MyAwIFIvUmVjdFsyNjQuNDQzIDQ1OC4yODQgMjk0LjQ0MyA0ODguMjg0XS9OYW1lL0NvbW1l
bnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vQ29udGVudHMoSnVtcGluZyBvbiB0aGlzIGp1c3Qgb25j
ZSBtb3JlLiAiVGhlIGFkZHJlc3Mgb2YgdGhlIG5laWdoYm9yIE9ETVJQIHJvdXRlci4uLiJcblxu
VGhlIHdheSBpdCBpcyB3cml0dGVuLCBvbmUgZ2V0cyB0aGUgaW1wcmVzc2lvbiB0aGF0IE9ETVJQ
IGlzIGRlc2lnbmVkIGZvciBzaW5nbGUtaW50ZXJmYWNlLXNpbmdsZS1hZGRyZXNzIHJvdXRlcnMu
IFxuXG5JIGRvIG5vdCAqdGhpbmsqIHRoYXQgdGhpcyBpcyB0aGUgY2FzZSwgYW5kIGl0IGNlcnRh
aW5seSBkb2VzIG5vdCBoYXZlIHRvIGJlIG1hZGUgYSBjb25zdHJhaW50LCBzbyBJIHJlY29tbWVu
ZCBjbGVhcmluZyB0aGF0IHVwLiBcKENvbnZlcnNlbHksIGlmIGl0IGlzIHRoZSBjYXNlLCBjYWxs
IHRoYXQgb3V0IGFzIGEgY29uc3RyYWludCBpbiBhcHBsaWNhYmlsaXR5IHNlY3Rpb25cKS4gVGhp
cyBhcHBsaWVzIGFjdHVhbGx5IHRocm91Z2ggdGhlIGRvY3VtZW50LCBzbyBsb29raW5nIGF0IGdp
dmluZyBpdCBhIHBhc3MgdGhyb3VnaCB3aXRoICJyZW1vdmUgZG91YnRzIGFzIHRvIG11bHRpLWlm
L2FkZHIiIGFzIG9iamVjdGl2ZSB3b3VsZCBiZSBncmVhdC5cbikvVChUQ2xhdXNlbikvTShEOjIw
MTQwMzEwMTkyNDQ5KzAxJzAwJykvUCA0OCAwIFI+PgplbmRvYmoKMjQzIDAgb2JqCjw8L1R5cGUv
QW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMjk5LjQ0MyAzNzYuMjg0IDU0OS40NDMgNDg4
LjI4NF0vUGFyZW50IDI0MiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyNDQgMCBvYmoKPDwvVHlw
ZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMzguMjA0IDQ4NC4yODQgOTUu
ODEyIDQ5OS4yODRdL01hdHJpeFsxIDAgMCAxIC0zOC4yMDQgLTQ4NC4yODRdL0dyb3VwPDwvUy9U
cmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9N
dWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTAyPj5zdHJlYW0KcQovUjAgZ3MK
MS4wMDAgMS4wMDAgMC4wMDAgcmcKMzguMjA0IDQ4NC4yODQgbQo5NS44MTIgNDg0LjI4NCBsCjk1
LjgxMiA0OTkuMjg0IGwKMzguMjA0IDQ5OS4yODQgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMjQ1
IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMzguMjA0IDQ4
NC4yODQgOTUuODEyIDQ5OS4yODRdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzgu
MjA0IDQ5OS4yODQgOTUuODEyIDQ5OS4yODQgMzguMjA0IDQ4NC4yODQgOTUuODEyIDQ4NC4yODRd
L0FQPDwvTiAyNDQgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcp
L1AgNDggMCBSPj4KZW5kb2JqCjI0NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9G
IDQvUmVjdFs5MS42MTQgNDk0LjI4NCAxMjEuNjE0IDUyNC4yODRdL05hbWUvQ29tbWVudC9DWzEu
MDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAyNDcgMCBSL0NvbnRlbnRzKFdoeSBpcyBpdCBQX211bHRp
Y2FzdF9zb3VyY2UsIGJ1dCB0aGlzIGlzIFJfc291cmNlPykvVChUQ2xhdXNlbikvTShEOjIwMTQw
MzEwMTkyNDQ5KzAxJzAwJykvUCA0OCAwIFI+PgplbmRvYmoKMjQ3IDAgb2JqCjw8L1R5cGUvQW5u
b3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbMTI2LjYxNCA0MTIuMjg0IDM3Ni42MTQgNTI0LjI4
NF0vUGFyZW50IDI0NiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagoyNDkgMCBvYmoKPDwvVHlwZS9B
bm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbNTM4LjA4OSA2MzguMjg0IDU2OC4wODkgNjY4LjI4
NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDI1MSAwIFIvQ29udGVu
dHMoRnJvbSB0aGlzIGRlc2NyaXB0aW9uLCBpdCBhcHBlYXJzIHRoYXQgaXQgYWxsIGlzICJwZXIg
cm91dGVyIiBhbmQgd2l0aCBubyAicGVyIGludGVyZmFjZSIgc2V0cywgaXMgdGhhdCBjb3JyZWN0
P1xuXG5BcyBJIGhhdmUgaW5kaWNhdGVkIGZvciB0aGUgIkJsYWNrbGlzdCIgdGhpcyBtYXkgYmUg
cHJvYmxlbWF0aWMsIG9yIGF0IGxlYXN0IG5lY2Vzc2l0YXRlIHNvbWUgZXh0cmEgY2FyZSB0byBz
cGVjaWZ5IGNvbXBsZXRlbHkuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAn
KS9QIDQ4IDAgUj4+CmVuZG9iagoyNTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVw
L0YgMjgvUmVjdFs1NzMuMDg5IDU1Ni4yODQgODIzLjA4OSA2NjguMjg0XS9QYXJlbnQgMjQ5IDAg
Ui9PcGVuIGZhbHNlPj4KZW5kb2JqCjQ4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNDAg
MCBSIC9SZXNvdXJjZXMgNTEgMCBSIC9Db250ZW50cyA0OSAwIFIvQW5ub3RzIDIzNSAwIFI+Pgpl
bmRvYmoKMjM1IDAgb2JqClsyMzcgMCBSIDIzOCAwIFIgMjM5IDAgUiAyNDEgMCBSIDI0MiAwIFIg
MjQzIDAgUiAyNDUgMCBSIDI0NiAwIFIgMjQ3IDAgUiAyNDkgMCBSIDI1MSAwIFJdCmVuZG9iagoy
NTMgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMjkw
LjI0NiA2NzYuMjg0IDQwNS40NjQgNjkxLjI4NF0vTWF0cml4WzEgMCAwIDEgLTI5MC4yNDYgLTY3
Ni4yODRdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9S
MDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTA2
Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMjkwLjI0NiA2NzYuMjg0IG0K
NDA1LjQ2NCA2NzYuMjg0IGwKNDA1LjQ2NCA2OTEuMjg0IGwKMjkwLjI0NiA2OTEuMjg0IGwKZgpR
CgplbmRzdHJlYW0KZW5kb2JqCjI1NSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvSGlnaGxp
Z2h0L0YgNC9SZWN0WzI5MC4yNDYgNjc2LjI4NCA0MDUuNDY0IDY5MS4yODRdL0NbMS4wMDAgMS4w
MDAgMC4wMDBdL1F1YWRQb2ludHNbMjkwLjI0NiA2OTEuMjg0IDQwNS40NjQgNjkxLjI4NCAyOTAu
MjQ2IDY3Ni4yODQgNDA1LjQ2NCA2NzYuMjg0XS9BUDw8L04gMjUzIDAgUiA+Pi9UKFRDbGF1c2Vu
KS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDUyIDAgUj4+CmVuZG9iagoyNTYgMCBvYmoK
PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMzA3LjY1MCA2ODYuMjg0IDMzNy42
NTAgNzE2LjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDI0OCAw
IFIvQ29udGVudHMoU2VlIHByZXZpb3VzIHF1ZXN0aW9uIHJlZ2FyZGluZyBNdWx0aWNhc3QgU291
cmNlKS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDUyIDAgUj4+CmVu
ZG9iagoyNDggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFszNDIu
NjUwIDYwNC4yODQgNTkyLjY1MCA3MTYuMjg0XS9QYXJlbnQgMjU2IDAgUi9PcGVuIGZhbHNlPj4K
ZW5kb2JqCjI1NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFs1MjMu
Njg2IDM3NC4yODQgNTUzLjY4NiA0MDQuMjg0XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAw
LjAwMF0vUG9wdXAgMjUwIDAgUi9Db250ZW50cyhDb250cmFyeSB0byBwcmV2aW91cy4uLi48c29t
ZXRoaW5nPl9zb3VyY2UsIHRoaXMgaXMgdW5hbWJpZ3VvdXMgO1wpKS9UKFRDbGF1c2VuKS9NKEQ6
MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDUyIDAgUj4+CmVuZG9iagoyNTAgMCBvYmoKPDwvVHlw
ZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFs1NTguNjg2IDI5Mi4yODQgODA4LjY4NiA0
MDQuMjg0XS9QYXJlbnQgMjU3IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjI1OCAwIG9iago8PC9U
eXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFszOC4yMDQgNjc2LjI4NCA5
NS44MTIgNjkxLjI4NF0vTWF0cml4WzEgMCAwIDEgLTM4LjIwNCAtNjc2LjI4NF0vR3JvdXA8PC9T
L1RyYW5zcGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JN
L011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDI+PnN0cmVhbQpxCi9SMCBn
cwoxLjAwMCAxLjAwMCAwLjAwMCByZwozOC4yMDQgNjc2LjI4NCBtCjk1LjgxMiA2NzYuMjg0IGwK
OTUuODEyIDY5MS4yODQgbAozOC4yMDQgNjkxLjI4NCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagoy
NTkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFszOC4yMDQg
Njc2LjI4NCA5NS44MTIgNjkxLjI4NF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1sz
OC4yMDQgNjkxLjI4NCA5NS44MTIgNjkxLjI4NCAzOC4yMDQgNjc2LjI4NCA5NS44MTIgNjc2LjI4
NF0vQVA8PC9OIDI1OCAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAw
JykvUCA1MiAwIFI+PgplbmRvYmoKMjYwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0
L0YgNC9SZWN0WzkxLjYxNCA2ODYuMjg0IDEyMS42MTQgNzE2LjI4NF0vTmFtZS9Db21tZW50L0Nb
MS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDI1NCAwIFIvQ29udGVudHMoV2h5IGlzIGl0IFBfbXVs
dGljYXN0X3NvdXJjZSwgYnV0IHRoaXMgaXMgRl9zb3VyY2U/KS9UKFRDbGF1c2VuKS9NKEQ6MjAx
NDAzMTAxOTI0NDkrMDEnMDAnKS9QIDUyIDAgUj4+CmVuZG9iagoyNTQgMCBvYmoKPDwvVHlwZS9B
bm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxMjYuNjE0IDYwNC4yODQgMzc2LjYxNCA3MTYu
Mjg0XS9QYXJlbnQgMjYwIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjUyIDAgb2JqCjw8IC9UeXBl
IC9QYWdlIC9QYXJlbnQgNDAgMCBSIC9SZXNvdXJjZXMgNTUgMCBSIC9Db250ZW50cyA1MyAwIFIv
QW5ub3RzIDI1MiAwIFI+PgplbmRvYmoKMjUyIDAgb2JqClsyNTUgMCBSIDI1NiAwIFIgMjQ4IDAg
UiAyNTcgMCBSIDI1MCAwIFIgMjU5IDAgUiAyNjAgMCBSIDI1NCAwIFJdCmVuZG9iagoyNjMgMCBv
YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbNTAyLjA4MyA0NTguMjg0IDUz
Mi4wODMgNDg4LjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDI2
MSAwIFIvQ29udGVudHMoSSB3b3VsZCBwcm9iYWJseSBzYXkgIi4uLm92ZXIgd2hpY2ggdGhlIEpv
aW4gUmVwbHkgd2FzIHNlbnQiKS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAn
KS9QIDU2IDAgUj4+CmVuZG9iagoyNjEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVw
L0YgMjgvUmVjdFs1MzcuMDgzIDM3Ni4yODQgNzg3LjA4MyA0ODguMjg0XS9QYXJlbnQgMjYzIDAg
Ui9PcGVuIGZhbHNlPj4KZW5kb2JqCjI2NCAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9G
b3JtL0Zvcm1UeXBlIDEvQkJveFsyODMuMDQ0IDIzMi4yODQgMjk3LjQ0NiAyNDcuMjg0XS9NYXRy
aXhbMSAwIDAgMSAtMjgzLjA0NCAtMjMyLjI4NF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L1Jl
c291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0
R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDY+PnN0cmVhbQpxCi9SMCBncwoxLjAwMCAxLjAwMCAwLjAw
MCByZwoyODMuMDQ0IDIzMi4yODQgbQoyOTcuNDQ2IDIzMi4yODQgbAoyOTcuNDQ2IDI0Ny4yODQg
bAoyODMuMDQ0IDI0Ny4yODQgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMjY1IDAgb2JqCjw8L1R5
cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbMjgzLjA0NCAyMzIuMjg0IDI5Ny40
NDYgMjQ3LjI4NF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1syODMuMDQ0IDI0Ny4y
ODQgMjk3LjQ0NiAyNDcuMjg0IDI4My4wNDQgMjMyLjI4NCAyOTcuNDQ2IDIzMi4yODRdL0FQPDwv
TiAyNjQgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgNTYg
MCBSPj4KZW5kb2JqCjI2NiAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1U
eXBlIDEvQkJveFszOC4yMDQgMzQwLjI4NCAxMzEuODE4IDM1NS4yODRdL01hdHJpeFsxIDAgMCAx
IC0zOC4yMDQgLTM0MC4yODRdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9F
eHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+
Pi9MZW5ndGggMTA0Pj5zdHJlYW0KcQovUjAgZ3MKMS4wMDAgMS4wMDAgMC4wMDAgcmcKMzguMjA0
IDM0MC4yODQgbQoxMzEuODE4IDM0MC4yODQgbAoxMzEuODE4IDM1NS4yODQgbAozOC4yMDQgMzU1
LjI4NCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagoyNjggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0
eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFszOC4yMDQgMzQwLjI4NCAxMzEuODE4IDM1NS4yODRdL0Nb
MS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbMzguMjA0IDM1NS4yODQgMTMxLjgxOCAzNTUu
Mjg0IDM4LjIwNCAzNDAuMjg0IDEzMS44MTggMzQwLjI4NF0vQVA8PC9OIDI2NiAwIFIgPj4vVChU
Q2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCA1NiAwIFI+PgplbmRvYmoKMjcw
IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzkxLjYxNCAzNTAuMjg0
IDEyMS42MTQgMzgwLjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVw
IDI2NyAwIFIvQ29udGVudHMoV2hhdCBpZiB0d28gcm91dGVycywgQSBhbmQgQiwgaGF2ZSB0d28g
aW50ZXJmYWNlcyBhMSwgYTIsIGIxLCBiMj9cblxuSWYgQSBjYW4gaGVhciBCIG92ZXIgYVxuXG4p
L1QoVENsYXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgNTYgMCBSPj4KZW5kb2Jq
CjI2NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzEyNi42MTQg
MjY4LjI4NCAzNzYuNjE0IDM4MC4yODRdL1BhcmVudCAyNzAgMCBSL09wZW4gZmFsc2U+PgplbmRv
YmoKMjcxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Qb3B1cCAyNjkgMCBS
L1JlY3RbOTEuNjE0IDM1MC4yODQgMTIxLjYxNCAzODAuMjg0XS9OYW1lL0NvbW1lbnQvQ1sxLjAw
MCAxLjAwMCAwLjAwMF0vQ29udGVudHMoV2hhdCBpZiB0d28gcm91dGVycywgQSBhbmQgQiwgaGF2
ZSB0d28gaW50ZXJmYWNlcyBhMSwgYTIsIGIxLCBiMj9cblxuSWYgQSBjYW4gaGVhciBCIG92ZXIg
XChhMSwgYjFcKSBhbmQgQiBjYW4gaGVhciBBIG92ZXIgXChhMiwgYjJcKSwgd2hhdCBhZGRyZXNz
ZXMgZ28gaW50byB0aGlzIHNldD9cblxuQWxzbywgd2hhdCBpZiBBIGNhbiBoZWFyIEIgb3ZlciBc
KGExLCBiMVwpIFwoYW5kIEIgY2FuIGhlYXIgQSBvdmVyIHRoZSBzYW1lIHBhaXJcKSwgYW5kIEEg
Y2FuIGhlYXIgQiBvdmVyIFwoYTEsYjJcKSBidXQgQiBjYW5ub3QuLi4uP1xuXG5JbiBvdGhlciB3
b3JkcywgaXMgdGhpcyBzZXQgcGVyIGludGVyZmFjZSBvciBwZXIgcm91dGVyP1xuXG5BbmQsIHdo
YXQgYXJlIHRoZSBhZGRyZXNzZXMgeW91IHB1dCBpbiB0aGVyZSwgaW50ZXJmYWNlIGFkZHJlc3Nl
cywgb3IgIlJvdXRlcklEcyI/XG4pL1QoVENsYXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScw
MCcpL1AgNTYgMCBSPj4KZW5kb2JqCjI2OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9w
dXAvRiAyOC9SZWN0WzEyNi42MTQgMjY4LjI4NCAzNzYuNjE0IDM4MC4yODRdL1BhcmVudCAyNjgg
MCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNTYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0
MCAwIFIgL1Jlc291cmNlcyA1OSAwIFIgL0NvbnRlbnRzIDU3IDAgUi9Bbm5vdHMgMjYyIDAgUj4+
CmVuZG9iagoyNjIgMCBvYmoKWzI2MyAwIFIgMjYxIDAgUiAyNjUgMCBSIDI2OCAwIFIgMjcwIDAg
UiAyNjcgMCBSIDI3MSAwIFIgMjY5IDAgUl0KZW5kb2JqCjI3MyAwIG9iago8PC9UeXBlL0Fubm90
L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsyNDIuODM5IDI1NC4yODQgMjcyLjgzOSAyODQuMjg0XS9O
YW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMjc0IDAgUi9Db250ZW50cyhB
bHJpZ2h0LCBzbyByZWFkaW5nIHRoaXMsIGl0IHNlZW1zIHRoYXQgdGhlIGJsYWNrbGlzdCBtdXN0
IGJlICJwZXIgaW50ZXJmYWNlIiwgeWVzPykvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5
KzAxJzAwJykvUCA2MCAwIFI+PgplbmRvYmoKMjc0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw
ZS9Qb3B1cC9GIDI4L1JlY3RbMjc3LjgzOSAxNzIuMjg0IDUyNy44MzkgMjg0LjI4NF0vUGFyZW50
IDI3MyAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iago2MCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy
ZW50IDQwIDAgUiAvUmVzb3VyY2VzIDYzIDAgUiAvQ29udGVudHMgNjEgMCBSL0Fubm90cyAyNzIg
MCBSPj4KZW5kb2JqCjI3MiAwIG9iagpbMjczIDAgUiAyNzQgMCBSXQplbmRvYmoKMjc2IDAgb2Jq
Cjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzIzMi42MzYgNjc2
LjI4NCAzMDQuNjQ3IDY5MS4yODRdL01hdHJpeFsxIDAgMCAxIC0yMzIuNjM2IC02NzYuMjg0XS9H
cm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMg
ZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFt
CnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjIzMi42MzYgNjc2LjI4NCBtCjMwNC42NDcg
Njc2LjI4NCBsCjMwNC42NDcgNjkxLjI4NCBsCjIzMi42MzYgNjkxLjI4NCBsCmYKUQoKZW5kc3Ry
ZWFtCmVuZG9iagoyNzcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQv
UmVjdFsyMzIuNjM2IDY3Ni4yODQgMzA0LjY0NyA2OTEuMjg0XS9DWzEuMDAwIDEuMDAwIDAuMDAw
XS9RdWFkUG9pbnRzWzIzMi42MzYgNjkxLjI4NCAzMDQuNjQ3IDY5MS4yODQgMjMyLjYzNiA2NzYu
Mjg0IDMwNC42NDcgNjc2LjI4NF0vQVA8PC9OIDI3NiAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIw
MTQwMzEwMTkyNDQ5KzAxJzAwJykvUCA2NCAwIFI+PgplbmRvYmoKMjc4IDAgb2JqCjw8L1R5cGUv
QW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzI2NC40NDMgNjg2LjI4NCAyOTQuNDQzIDcxNi4y
ODRdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAyNzkgMCBSL0NvbnRl
bnRzKFdoaWNoIGFkZHJlc3M/IEFueT8gQWx3YXlzIHRoZSBzYW1lPyBEb2VzIGl0IG1hdHRlcj8p
L1QoVENsYXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgNjQgMCBSPj4KZW5kb2Jq
CjI3OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzI5OS40NDMg
NjA0LjI4NCA1NDkuNDQzIDcxNi4yODRdL1BhcmVudCAyNzggMCBSL09wZW4gZmFsc2U+PgplbmRv
YmoKNjQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0MCAwIFIgL1Jlc291cmNlcyA2NyAw
IFIgL0NvbnRlbnRzIDY1IDAgUi9Bbm5vdHMgMjc1IDAgUj4+CmVuZG9iagoyNzUgMCBvYmoKWzI3
NyAwIFIgMjc4IDAgUiAyNzkgMCBSXQplbmRvYmoKMjgxIDAgb2JqCjw8L1R5cGUvWE9iamVjdC9T
dWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzIzOS44MzcgNjY0LjI4NCAzMTEuODQ4IDY3OS4y
ODRdL01hdHJpeFsxIDAgMCAxIC0yMzkuODM3IC02NjQuMjg0XS9Hcm91cDw8L1MvVHJhbnNwYXJl
bmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkv
VHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEu
MDAwIDAuMDAwIHJnCjIzOS44MzcgNjY0LjI4NCBtCjMxMS44NDggNjY0LjI4NCBsCjMxMS44NDgg
Njc5LjI4NCBsCjIzOS44MzcgNjc5LjI4NCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagoyODIgMCBv
YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFsyMzkuODM3IDY2NC4y
ODQgMzExLjg0OCA2NzkuMjg0XS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzIzOS44
MzcgNjc5LjI4NCAzMTEuODQ4IDY3OS4yODQgMjM5LjgzNyA2NjQuMjg0IDMxMS44NDggNjY0LjI4
NF0vQVA8PC9OIDI4MSAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAw
JykvUCA2OCAwIFI+PgplbmRvYmoKMjgzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0
L0YgNC9SZWN0WzI3MS42NDQgNjc0LjI4NCAzMDEuNjQ0IDcwNC4yODRdL05hbWUvQ29tbWVudC9D
WzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAyODQgMCBSL0NvbnRlbnRzKFdoaWNoIGFkZHJlc3M/
IEFueT8gQWx3YXlzIHRoZSBzYW1lPyBEb2VzIGl0IG1hdHRlcj8pL1QoVENsYXVzZW4pL00oRDoy
MDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgNjggMCBSPj4KZW5kb2JqCjI4NCAwIG9iago8PC9UeXBl
L0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzMwNi42NDQgNTkyLjI4NCA1NTYuNjQ0IDcw
NC4yODRdL1BhcmVudCAyODMgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMjg1IDAgb2JqCjw8L1R5
cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzQ0OC42NzIgNjQwLjI4NCA1
MTMuNDgyIDY1NS4yODRdL01hdHJpeFsxIDAgMCAxIC00NDguNjcyIC02NDAuMjg0XS9Hcm91cDw8
L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2Uv
Qk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1Iw
IGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjQ0OC42NzIgNjQwLjI4NCBtCjUxMy40ODIgNjQwLjI4
NCBsCjUxMy40ODIgNjU1LjI4NCBsCjQ0OC42NzIgNjU1LjI4NCBsCmYKUQoKZW5kc3RyZWFtCmVu
ZG9iagoyODYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs0
NDguNjcyIDY0MC4yODQgNTEzLjQ4MiA2NTUuMjg0XS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFk
UG9pbnRzWzQ0OC42NzIgNjU1LjI4NCA1MTMuNDgyIDY1NS4yODQgNDQ4LjY3MiA2NDAuMjg0IDUx
My40ODIgNjQwLjI4NF0vQVA8PC9OIDI4NSAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTQwMzEw
MTkyNDQ5KzAxJzAwJykvUCA2OCAwIFI+PgplbmRvYmoKMjg3IDAgb2JqCjw8L1R5cGUvQW5ub3Qv
U3VidHlwZS9UZXh0L0YgNC9SZWN0WzUwMi4wODMgNjUwLjI4NCA1MzIuMDgzIDY4MC4yODRdL05h
bWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAyODggMCBSL0NvbnRlbnRzKEkg
YXNzdW1lIHRoYXQgd2hhdCB5b3Ugd2FudCBpcyB0byBmb3J3YXJkIHRvIGFsbCB0aGUgbmVpZ2hi
b3JzIG9uIGFsbCBPRE1SUCBpbnRlcmZhY2VzIG9mIHRoaXMgcm91dGVyLCB5ZXM/XG4pL1QoVENs
YXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgNjggMCBSPj4KZW5kb2JqCjI4OCAw
IG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzUzNy4wODMgNTY4LjI4
NCA3ODcuMDgzIDY4MC4yODRdL1BhcmVudCAyODcgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKNjgg
MCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0MCAwIFIgL1Jlc291cmNlcyA3MSAwIFIgL0Nv
bnRlbnRzIDY5IDAgUi9Bbm5vdHMgMjgwIDAgUj4+CmVuZG9iagoyODAgMCBvYmoKWzI4MiAwIFIg
MjgzIDAgUiAyODQgMCBSIDI4NiAwIFIgMjg3IDAgUiAyODggMCBSXQplbmRvYmoKMjkwIDAgb2Jq
Cjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzQ0MS40NzEgNTY4
LjI4NCA1MDYuMjgxIDU4My4yODRdL01hdHJpeFsxIDAgMCAxIC00NDEuNDcxIC01NjguMjg0XS9H
cm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMg
ZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+Pj4vTGVuZ3RoIDEwNj4+c3RyZWFt
CnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjQ0MS40NzEgNTY4LjI4NCBtCjUwNi4yODEg
NTY4LjI4NCBsCjUwNi4yODEgNTgzLjI4NCBsCjQ0MS40NzEgNTgzLjI4NCBsCmYKUQoKZW5kc3Ry
ZWFtCmVuZG9iagoyOTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQv
UmVjdFs0NDEuNDcxIDU2OC4yODQgNTA2LjI4MSA1ODMuMjg0XS9DWzEuMDAwIDEuMDAwIDAuMDAw
XS9RdWFkUG9pbnRzWzQ0MS40NzEgNTgzLjI4NCA1MDYuMjgxIDU4My4yODQgNDQxLjQ3MSA1Njgu
Mjg0IDUwNi4yODEgNTY4LjI4NF0vQVA8PC9OIDI5MCAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIw
MTQwMzEwMTkyNDQ5KzAxJzAwJykvUCA4MSAwIFI+PgplbmRvYmoKMjkyIDAgb2JqCjw8L1R5cGUv
QW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Qb3B1cCAyOTMgMCBSL1JlY3RbNDU4Ljg3NiA1NzguMjg0
IDQ4OC44NzYgNjA4LjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRl
bnRzKE92ZXIgYWxsIE9ETVJQIEludGVyZmFjZXM/XG4pL1QoVENsYXVzZW4pL00oRDoyMDE0MDMx
MDE5MjQ0OSswMScwMCcpL1AgODEgMCBSPj4KZW5kb2JqCjI5MyAwIG9iago8PC9UeXBlL0Fubm90
L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0WzQ5My44NzYgNDk2LjI4NCA3NDMuODc2IDYwOC4yODRd
L1BhcmVudCAyOTIgMCBSL09wZW4gZmFsc2U+PgplbmRvYmoKMjk0IDAgb2JqCjw8L1R5cGUvQW5u
b3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzI3OC44NDUgMzk4LjI4NCAzMDguODQ1IDQyOC4yODRd
L05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Qb3B1cCAyOTUgMCBSL0NvbnRlbnRz
KEhlcmUsIHdlIGFyZSBnbGVhbmluZyBhIGJpdCBtb3JlIHByZWNpc2VseSB3aGF0IHRoZSBSX3Nv
dXJjZSBpczsgc28gaXRzIGFuIGludGVyZmFjZSBvZiBhbiBPRE1SUCByb3V0ZXIgb3ZlciB3aGlj
aCB0aGUgSm9pbiBSZXBseSB3YXMgc2VudCwgeWVzP1xuKS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAz
MTAxOTI0NDkrMDEnMDAnKS9QIDgxIDAgUj4+CmVuZG9iagoyOTUgMCBvYmoKPDwvVHlwZS9Bbm5v
dC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFszMTMuODQ1IDMxNi4yODQgNTYzLjg0NSA0MjguMjg0
XS9QYXJlbnQgMjk0IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjI5NiAwIG9iago8PC9UeXBlL1hP
YmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFs2Ny4wMDggMzA0LjI4NCA5NS44MTIg
MzE5LjI4NF0vTWF0cml4WzEgMCAwIDEgLTY3LjAwOCAtMzA0LjI4NF0vR3JvdXA8PC9TL1RyYW5z
cGFyZW5jeT4+L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRp
cGx5L1R5cGUvRXh0R1N0YXRlPj4+Pj4+L0xlbmd0aCAxMDI+PnN0cmVhbQpxCi9SMCBncwoxLjAw
MCAxLjAwMCAwLjAwMCByZwo2Ny4wMDggMzA0LjI4NCBtCjk1LjgxMiAzMDQuMjg0IGwKOTUuODEy
IDMxOS4yODQgbAo2Ny4wMDggMzE5LjI4NCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagoyOTcgMCBv
YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFs2Ny4wMDggMzA0LjI4
NCA5NS44MTIgMzE5LjI4NF0vQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUXVhZFBvaW50c1s2Ny4wMDgg
MzE5LjI4NCA5NS44MTIgMzE5LjI4NCA2Ny4wMDggMzA0LjI4NCA5NS44MTIgMzA0LjI4NF0vQVA8
PC9OIDI5NiAwIFIgPj4vVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCA4
MSAwIFI+PgplbmRvYmoKMjk4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Q
b3B1cCAyOTkgMCBSL1JlY3RbNjYuNDEwIDMxNC4yODQgOTYuNDEwIDM0NC4yODRdL05hbWUvQ29t
bWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cyhFbHNlIC0+ICJPdGhlcndpc2UsIGlm
IGEgdHVwbGUgZXhpc3RzLCAuLi4iKS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEn
MDAnKS9QIDgxIDAgUj4+CmVuZG9iagoyOTkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1Bv
cHVwL0YgMjgvUmVjdFsxMDEuNDEwIDIzMi4yODQgMzUxLjQxMCAzNDQuMjg0XS9QYXJlbnQgMjk4
IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjgxIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQg
NzMgMCBSIC9SZXNvdXJjZXMgODQgMCBSIC9Db250ZW50cyA4MiAwIFIvQW5ub3RzIDI4OSAwIFI+
PgplbmRvYmoKMjg5IDAgb2JqClsyOTEgMCBSIDI5MiAwIFIgMjkzIDAgUiAyOTQgMCBSIDI5NSAw
IFIgMjk3IDAgUiAyOTggMCBSIDI5OSAwIFJdCmVuZG9iagozMDEgMCBvYmoKPDwvVHlwZS9Bbm5v
dC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDMwMiAwIFIvUmVjdFs4OC4wMTQgNjYyLjI4NCAxMTgu
MDE0IDY5Mi4yODRdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAwXS9Db250ZW50cygi
T3RoZXJ3aXNlLCAuLi4iKS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9Q
IDg1IDAgUj4+CmVuZG9iagozMDIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0Yg
MjgvUmVjdFsxMjMuMDE0IDU4MC4yODQgMzczLjAxNCA2OTIuMjg0XS9QYXJlbnQgMzAxIDAgUi9P
cGVuIGZhbHNlPj4KZW5kb2JqCjg1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNzMgMCBS
IC9SZXNvdXJjZXMgODggMCBSIC9Db250ZW50cyA4NiAwIFIvQW5ub3RzIDMwMCAwIFI+PgplbmRv
YmoKMzAwIDAgb2JqClszMDEgMCBSIDMwMiAwIFJdCmVuZG9iagozMDQgMCBvYmoKPDwvVHlwZS9Y
T2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbNTkuODA3IDQxMi4yODQgODguNjEx
IDQyNy4yODRdL01hdHJpeFsxIDAgMCAxIC01OS44MDcgLTQxMi4yODRdL0dyb3VwPDwvUy9UcmFu
c3BhcmVuY3k+Pi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0
aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4+Pi9MZW5ndGggMTAyPj5zdHJlYW0KcQovUjAgZ3MKMS4w
MDAgMS4wMDAgMC4wMDAgcmcKNTkuODA3IDQxMi4yODQgbQo4OC42MTEgNDEyLjI4NCBsCjg4LjYx
MSA0MjcuMjg0IGwKNTkuODA3IDQyNy4yODQgbApmClEKCmVuZHN0cmVhbQplbmRvYmoKMzA1IDAg
b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9IaWdobGlnaHQvRiA0L1JlY3RbNTkuODA3IDQxMi4y
ODQgODguNjExIDQyNy4yODRdL0NbMS4wMDAgMS4wMDAgMC4wMDBdL1F1YWRQb2ludHNbNTkuODA3
IDQyNy4yODQgODguNjExIDQyNy4yODQgNTkuODA3IDQxMi4yODQgODguNjExIDQxMi4yODRdL0FQ
PDwvTiAzMDQgMCBSID4+L1QoVENsYXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1Ag
ODkgMCBSPj4KZW5kb2JqCjMwNiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQv
UmVjdFs1OS4yMDkgNDIyLjI4NCA4OS4yMDkgNDUyLjI4NF0vTmFtZS9Db21tZW50L0NbMS4wMDAg
MS4wMDAgMC4wMDBdL1BvcHVwIDMwNyAwIFIvQ29udGVudHMoLT5PdGhlcndpc2UpL1QoVENsYXVz
ZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgODkgMCBSPj4KZW5kb2JqCjMwNyAwIG9i
ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvUG9wdXAvRiAyOC9SZWN0Wzk0LjIwOSAzNDAuMjg0IDM0
NC4yMDkgNDUyLjI4NF0vUGFyZW50IDMwNiAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozMDggMCBv
YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1RleHQvRiA0L1BvcHVwIDMwOSAwIFIvUmVjdFs1Mzgu
MDg5IDQxMC4yODQgNTY4LjA4OSA0NDAuMjg0XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAw
LjAwMF0vQ29udGVudHMoUmVhbGx5IG5pdC1waWNraW5nLCBidXQgIiBpLmUuICIgLT4gIiBpLmUu
LCAiIGlzIHRoZSBSRkMtRWRpdG9yIHN0eWxlLi4uLikvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEw
MTkyNDQ5KzAxJzAwJykvUCA4OSAwIFI+PgplbmRvYmoKMzA5IDAgb2JqCjw8L1R5cGUvQW5ub3Qv
U3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbNTczLjA4OSAzMjguMjg0IDgyMy4wODkgNDQwLjI4NF0v
UGFyZW50IDMwOCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iagozMTAgMCBvYmoKPDwvVHlwZS9Bbm5v
dC9TdWJ0eXBlL1RleHQvRiA0L1JlY3RbMzQzLjY1NiAzMTQuMjg0IDM3My42NTYgMzQ0LjI4NF0v
TmFtZS9Db21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL1BvcHVwIDMxMSAwIFIvQ29udGVudHMo
U3VnZ2VzdDogIi4uLnJ1biBpbiBjb25qdW5jdGlvbiB3aXRoLCBhbmQgYmVuZWZpdCBmcm9tIHNv
bWUgb2YgdGhlIGZlYXR1cmVzIG9mLCBTTUYuLi4iKS9UKFRDbGF1c2VuKS9NKEQ6MjAxNDAzMTAx
OTI0NDkrMDEnMDAnKS9QIDg5IDAgUj4+CmVuZG9iagozMTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T
dWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFszNzguNjU2IDIzMi4yODQgNjI4LjY1NiAzNDQuMjg0XS9Q
YXJlbnQgMzEwIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjMxMiAwIG9iago8PC9UeXBlL0Fubm90
L1N1YnR5cGUvU3RyaWtlT3V0L0YgNC9SZWN0WzE2LjYwMCAyOTIuMjg0IDU5Mi42OTUgMzE5LjI4
NF0vQ1sxLjAwMCAwLjAwMCAwLjAwMF0vUXVhZFBvaW50c1s0NzAuMjc2IDMxOS4yODQgNTkyLjY5
NSAzMTkuMjg0IDQ3MC4yNzYgMzA0LjI4NCA1OTIuNjk1IDMwNC4yODQgMTYuNjAwIDMwNy4yODQg
MjgzLjA0MyAzMDcuMjg0IDE2LjYwMCAyOTIuMjg0IDI4My4wNDMgMjkyLjI4NF0vVChUQ2xhdXNl
bikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCA4OSAwIFI+PgplbmRvYmoKMzEzIDAgb2Jq
Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzE5LjYwMiAyNTQuMjg0IDQ5LjYw
MiAyODQuMjg0XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzE0IDAg
Ui9Db250ZW50cyhJIHdvdWxkIGJlIGhlc2l0YW50IHRvIGNhbGwgdGhpcyBzZWN0aW9uICJTTUYg
Q29uc2lkZXJhdGlvbnMiXG5cbldoaWxlIFNNRiBpcyBhbiBpbXBvcnRhbnQgYW5kIHVzZWZ1bCBw
cm90b2NvbCBzZXQsIEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoaXMgc2VjdGlvbiBiZSBnZW5lcmFs
aXplZDogd2hhdCdzIGF0IHN0YWtlIGlzLCBhbmQgSSB0aGluayB0aGF0IEkgc2F3IHRoYXQgaW4g
dGhlIHNsaWRlcyB0aGF0IHdlcmUgcHJlc2VudGVkIGluIHRoZSBMb25kb24gSUVURiwgdGhhdCBp
ZiB0aGVyZSdzIGEgIm1vcmUgZWZmaWNpZW50IHRoYW4gY2xhc3NpYyBmbG9vZGluZyIgbmV0d29y
ay13aWRlciBicm9hZGNhc3Qgb3BlcmF0aW9uIGluIHBsYWNlLCB0aGVuIE9ETVJQIHdvdWxkL3No
b3VsZCB1c2UgaXQgLSBjb3JyZWN0P1xuXG5UaGlzIG1pZ2h0IGJlIGJ5IHdheSBvZiBTTUYsIG9y
IGl0IGNvdWxkIGJlIGFzIGFuIGV4dGVuc2lvbiB0byBPTFNSdjIncyBNUFIgZmxvb2RpbmcsIG9y
IGl0IGNvdWxkIGJlIFwoYXMgaXMgc2VlbiBpbiBmb3IgZXhhbXBsZSBITkNQXCkgc29tZXRoaW5n
IGJhc2VkIG9mZiBvZiBUcmlja2xlIC0gb3Igc29tZXRoaW5nIGVudGlyZWx5IGRpZmZlcmVudC5c
blxuU28sIHBlcmhhcHMgIkZsb29kaW5nIGNvbnNpZGVyYXRpb25zIiBhcyBzZWN0aW9uIHRpdGxl
LCBhbmQgYSBiaXQgZ2VuZXJhbGl6ZWQgdGV4dCB3b3VsZCB3b3JrPykvVChUQ2xhdXNlbikvTShE
OjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCA4OSAwIFI+PgplbmRvYmoKMzE0IDAgb2JqCjw8L1R5
cGUvQW5ub3QvU3VidHlwZS9Qb3B1cC9GIDI4L1JlY3RbNTQuNjAyIDE3Mi4yODQgMzA0LjYwMiAy
ODQuMjg0XS9QYXJlbnQgMzEzIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjg5IDAgb2JqCjw8IC9U
eXBlIC9QYWdlIC9QYXJlbnQgNzMgMCBSIC9SZXNvdXJjZXMgOTIgMCBSIC9Db250ZW50cyA5MCAw
IFIvQW5ub3RzIDMwMyAwIFI+PgplbmRvYmoKMzAzIDAgb2JqClszMDUgMCBSIDMwNiAwIFIgMzA3
IDAgUiAzMDggMCBSIDMwOSAwIFIgMzEwIDAgUiAzMTEgMCBSIDMxMiAwIFIgMzEzIDAgUiAzMTQg
MCBSXQplbmRvYmoKMzE2IDAgb2JqCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5
cGUgMS9CQm94WzEyNC42MTggNTkyLjI4NCAxNzUuMDI1IDYwNy4yODRdL01hdHJpeFsxIDAgMCAx
IC0xMjQuNjE4IC01OTIuMjg0XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vUmVzb3VyY2VzPDwv
RXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+
Pj4vTGVuZ3RoIDEwNj4+c3RyZWFtCnEKL1IwIGdzCjEuMDAwIDEuMDAwIDAuMDAwIHJnCjEyNC42
MTggNTkyLjI4NCBtCjE3NS4wMjUgNTkyLjI4NCBsCjE3NS4wMjUgNjA3LjI4NCBsCjEyNC42MTgg
NjA3LjI4NCBsCmYKUQoKZW5kc3RyZWFtCmVuZG9iagozMTcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T
dWJ0eXBlL0hpZ2hsaWdodC9GIDQvUmVjdFsxMjQuNjE4IDU5Mi4yODQgMTc1LjAyNSA2MDcuMjg0
XS9DWzEuMDAwIDEuMDAwIDAuMDAwXS9RdWFkUG9pbnRzWzEyNC42MTggNjA3LjI4NCAxNzUuMDI1
IDYwNy4yODQgMTI0LjYxOCA1OTIuMjg0IDE3NS4wMjUgNTkyLjI4NF0vQVA8PC9OIDMxNiAwIFIg
Pj4vVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5KzAxJzAwJykvUCA5MyAwIFI+PgplbmRv
YmoKMzE4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9SZWN0WzEzNC44MjIg
NjAyLjI4NCAxNjQuODIyIDYzMi4yODRdL05hbWUvQ29tbWVudC9DWzEuMDAwIDEuMDAwIDAuMDAw
XS9Qb3B1cCAzMTkgMCBSL0NvbnRlbnRzKFBhY2tldHMgLT4gUGFja2V0KS9UKFRDbGF1c2VuKS9N
KEQ6MjAxNDAzMTAxOTI0NDkrMDEnMDAnKS9QIDkzIDAgUj4+CmVuZG9iagozMTkgMCBvYmoKPDwv
VHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsxNjkuODIyIDUyMC4yODQgNDE5Ljgy
MiA2MzIuMjg0XS9QYXJlbnQgMzE4IDAgUi9PcGVuIGZhbHNlPj4KZW5kb2JqCjMyMCAwIG9iago8
PC9UeXBlL0Fubm90L1N1YnR5cGUvVGV4dC9GIDQvUmVjdFsxMjAuNDE5IDMyNi4yODQgMTUwLjQx
OSAzNTYuMjg0XS9OYW1lL0NvbW1lbnQvQ1sxLjAwMCAxLjAwMCAwLjAwMF0vUG9wdXAgMzIxIDAg
Ui9Db250ZW50cyhPSywgSSB0aGluayB0aGF0IHRoaXMgZG9jdW1lbnQgc2hvdWxkIHN0YXJ0IGJ5
IGFjdHVhbGx5IHJlcXVlc3RpbmcgdGhlIGFsbG9jYXRpb25zIGZvciB0aGUgdHdvIG1lc3NhZ2Ug
dHlwZXMuIENmLiBob3cgaXQgaXMgZG9uZSBpbiBzZWN0aW9uIDE4LjIgb2YgUkZDNjEzMFxuXG5U
aGVuLCBJICp0aGluayogdGhhdCB0aGUgY3VycmVudCAxNS4xIGlzIHRoZSBNZXNzYWdlLVR5cGUt
U3BlY2lmaWMgVExWIFR5cGUgUmVnaXN0cmllcyIgdGhhdCBhcmUgYmVpbmcgc2V0IHVwLCBmb3Ig
Sm9pbi1RdWVyeSB5ZXM/IEkgc2VlICJFeHBlcnQgUmV2aWV3IiBtZW50aW9uZWQsIGJ1dCBubyBn
dWlkZWxpbmVzL3JlY29tbWVuZGF0aW9ucyBmb3IgdGhlIEV4cGVydCB0byBmb2xsb3cuIERvIHlv
dSBpbnRlbmQgdG8gbWlycm9yIHRob3NlIGZyb20gUkZDNTQ0NCwgb3IgYXJlIHRoZXJlIHNwZWNp
YWwgY29uY2VybnMgdG8gdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24/XG5cbkkgd291bGQgYWN0dWFs
bHkgc3VnZ2VzdCBtaXJyb3JpbmcgdGhlIHN0cnVjdHVyZSBvZiB0aGUgSUFOQSBzZWN0aW9uIGZy
b20gUkZDNjEzMCAgaWYgZm9yIG5vIG90aGVyIHJlYXNvbnMsIHRoYW4gdGhhdCBpdCdzIGFsbG9j
YXRpbmcgZnJvbSBSRkM1NDQ0LXJlZ2lzdHJpZXMsIGFuZCBoYXMgYmVlbiBnb2luZyB0aHJvdWdo
IHRoZSBwcm9jZXNzIGFuZCBzbyBpdCBtYXkgYmUgYXNzdW1lZCB0aGF0IHNvbWV0aGluZyBtaXJy
b3JpbmcgaXQgd2lsbCwgdG9vLiA7XClcbikvVChUQ2xhdXNlbikvTShEOjIwMTQwMzEwMTkyNDQ5
KzAxJzAwJykvUCA5MyAwIFI+PgplbmRvYmoKMzIxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw
ZS9Qb3B1cC9GIDI4L1JlY3RbMTU1LjQxOSAyNDQuMjg0IDQwNS40MTkgMzU2LjI4NF0vUGFyZW50
IDMyMCAwIFIvT3BlbiBmYWxzZT4+CmVuZG9iago5MyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy
ZW50IDczIDAgUiAvUmVzb3VyY2VzIDk2IDAgUiAvQ29udGVudHMgOTQgMCBSL0Fubm90cyAzMTUg
MCBSPj4KZW5kb2JqCjMxNSAwIG9iagpbMzE3IDAgUiAzMTggMCBSIDMxOSAwIFIgMzIwIDAgUiAz
MjEgMCBSXQplbmRvYmoKMzIzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9UZXh0L0YgNC9Q
b3B1cCAzMjQgMCBSL1JlY3RbMjY0LjQ0MyA0NzAuMjg0IDI5NC40NDMgNTAwLjI4NF0vTmFtZS9D
b21tZW50L0NbMS4wMDAgMS4wMDAgMC4wMDBdL0NvbnRlbnRzKEp1c3QgYSBjb21tZW50LCBhIGN1
cnNvcnkgcmV2aWV3IG9mIHRoZSBtYXBwaW5nIHRvIFJGQzU0NDQgZG9lc24ndCBoYXZlIGFueXRo
aW5nIGp1bXAgYXQgbWUgc2NyZWFtaW5nICJwcm9ibGVtcyIsIHdoaWNoIGlzIGdvb2QuXG5cbkkg
d2FzIHdvbmRlcmluZyBvbmUgdGhpbmcsIHRob3VnaDogaWYgcnVubmluZyBPTFNSdjIgKyBPRE1S
UCwgdGhlbiB0aGVyZSdzIGFuIG9idmlvdXMgb3B0aW9uIHdoaWNoIGNvdWxkIGJlIGNvbnNpZGVy
ZWQgXChhbmQgY291bGQgYmUgY29uc2lkZXJlZCwgaW4gb3JkZXIgdG8gYmUgZGlzcmVnYXJkZWRc
KS4uLi5cblxuQ291bGQgb25lIGltYWdpbmUgY2FycnlpbmcgT0RNUlAgc2lnbmFscyBpbnNpZGUg
VEMgbWVzc2FnZXMgaW4gYW55IG1lYW5pbmdmdWwgd2F5LCBhcyBUTFZzIGFuZCBhZGRpdGlvbmFs
IGFkZHJlc3NlcyBpbmNsdWRlZD8gKnRlY2huaWNhbGx5KiBpdCBzaG91bGQgYmUgcG9zc2libGUs
IGRvZXMgaXQgbWFrZSBzZW5zZT9cblxuQSBzZWNvbmQgdGhpbmcsIGlzIHRoZXJlIGFueSByZWFz
b24gdG8gcmVxdWVzdCBib3RoIEpSIGFuZCBKUSBtZXNzYWdlIHR5cGUsIG9yIGlzIHRoZXJlIGEg
d2F5IG9mIHVzaW5nIGp1c3QgYSBzaW5nbGUgY29kZS1wb2ludCwgYW5kIGFyZSB0aGVyZSBwb3Rl
bnRpYWwgYmVuZWZpdHMgaW4gZG9pbmcgc28/XG5cbkEgZGlmZmVyZW50IHdheSBvZiBwaHJhc2lu
ZyB0aGUgYWJvdmUgaXM6IGdpdmVuIHRoYXQgY29kZS1wb2ludHMgYnkgZGVmaW5pdGlvbiBhcmUg
bGltaXRlZCwgSSdkIGxpa2UgdG8gYXNrIGZvciBhIGJpdCBtb3JlIG9mICJqdXN0aWZpY2F0aW9u
IiBiZWZvcmUgdGhleSBhcmUgYWxsb2NhdGVkLlxuXG5GV0lXLCBJJ3ZlIG5vdCBoYWQgdGhlIGN5
Y2xlcyB0byByZXZpZXcgdGhlIGFwcGVuZGljZXMsIG90aGVyIHRoYW4gQXBwZW5kaXggQS4pL1Qo
VENsYXVzZW4pL00oRDoyMDE0MDMxMDE5MjQ0OSswMScwMCcpL1AgMTA1IDAgUj4+CmVuZG9iagoz
MjQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL1BvcHVwL0YgMjgvUmVjdFsyOTkuNDQzIDM4
OC4yODQgNTQ5LjQ0MyA1MDAuMjg0XS9QYXJlbnQgMzIzIDAgUi9PcGVuIGZhbHNlPj4KZW5kb2Jq
CjEwNSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEwNiAwIFIgL1Jlc291cmNlcyAxMDkg
MCBSIC9Db250ZW50cyAxMDcgMCBSL0Fubm90cyAzMjIgMCBSPj4KZW5kb2JqCjMyMiAwIG9iagpb
MzIzIDAgUiAzMjQgMCBSXQplbmRvYmoKeHJlZgowIDMKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAw
MDgzODExIDAwMDAwIG4gCjAwMDAwODk1ODYgMDAwMDAgbiAKMTkgMQowMDAwMDk1OTgzIDAwMDAw
IG4gCjIzIDEKMDAwMDEwMDMwMSAwMDAwMCBuIAoyNyAxCjAwMDAxMDYzNjAgMDAwMDAgbiAKMzEg
MQowMDAwMTExMDgxIDAwMDAwIG4gCjM1IDEKMDAwMDExMjMyNSAwMDAwMCBuIAozOSAxCjAwMDAx
MTMyNzkgMDAwMDAgbiAKNDggMQowMDAwMTE3OTU1IDAwMDAwIG4gCjUyIDEKMDAwMDEyMDQ4MSAw
MDAwMCBuIAo1NiAxCjAwMDAxMjM0MjkgMDAwMDAgbiAKNjAgMQowMDAwMTI0MDA0IDAwMDAwIG4g
CjY0IDEKMDAwMDEyNTExOCAwMDAwMCBuIAo2OCAxCjAwMDAxMjcyNzggMDAwMDAgbiAKODEgMQow
MDAwMTI5ODE0IDAwMDAwIG4gCjg1IDEKMDAwMDEzMDMyMSAwMDAwMCBuIAo4OSAxCjAwMDAxMzM0
ODAgMDAwMDAgbiAKOTMgMQowMDAwMTM1Njg5IDAwMDAwIG4gCjEwNSAxCjAwMDAxMzcwODYgMDAw
MDAgbiAKMTM1IDEKMDAwMDA4NDAyOCAwMDAwMCBuIAoxNDEgODQKMDAwMDA4MzkwMyAwMDAwMCBu
IAowMDAwMDg0MDk4IDAwMDAwIG4gCjAwMDAwODk2ODAgMDAwMDAgbiAKMDAwMDA4NDIxMyAwMDAw
MCBuIAowMDAwMDg0NTcxIDAwMDAwIG4gCjAwMDAwODQ4MjMgMDAwMDAgbiAKMDAwMDA4NTA4MyAw
MDAwMCBuIAowMDAwMDg1MTk5IDAwMDAwIG4gCjAwMDAwODU1NjEgMDAwMDAgbiAKMDAwMDA4NTgx
NiAwMDAwMCBuIAowMDAwMDg2MTkzIDAwMDAwIG4gCjAwMDAwODYzMDkgMDAwMDAgbiAKMDAwMDA4
NjYxNiAwMDAwMCBuIAowMDAwMDg2NzMyIDAwMDAwIG4gCjAwMDAwODk0NzAgMDAwMDAgbiAKMDAw
MDA5MDk2MiAwMDAwMCBuIAowMDAwMDk2MDgwIDAwMDAwIG4gCjAwMDAwOTE0NTEgMDAwMDAgbiAK
MDAwMDA4OTc3OSAwMDAwMCBuIAowMDAwMDkyNTAxIDAwMDAwIG4gCjAwMDAwOTAyMTEgMDAwMDAg
biAKMDAwMDA5MDUyOCAwMDAwMCBuIAowMDAwMDkxMDc3IDAwMDAwIG4gCjAwMDAwOTE1NjYgMDAw
MDAgbiAKMDAwMDA5MjYxNiAwMDAwMCBuIAowMDAwMDkzMjM5IDAwMDAwIG4gCjAwMDAwOTMzNTUg
MDAwMDAgbiAKMDAwMDA5MzcxNyAwMDAwMCBuIAowMDAwMDkzOTczIDAwMDAwIG4gCjAwMDAwOTQy
NTMgMDAwMDAgbiAKMDAwMDA5NDM2OSAwMDAwMCBuIAowMDAwMDk0OTE1IDAwMDAwIG4gCjAwMDAw
OTUwMzEgMDAwMDAgbiAKMDAwMDA5NTg2NyAwMDAwMCBuIAowMDAwMDk3NTU4IDAwMDAwIG4gCjAw
MDAxMDAzOTggMDAwMDAgbiAKMDAwMDA5NjIyNyAwMDAwMCBuIAowMDAwMDk2NTg5IDAwMDAwIG4g
CjAwMDAwOTY4NDUgMDAwMDAgbiAKMDAwMDA5NzY3NCAwMDAwMCBuIAowMDAwMDk4MDcwIDAwMDAw
IG4gCjAwMDAwOTgxODYgMDAwMDAgbiAKMDAwMDA5OTIwNyAwMDAwMCBuIAowMDAwMDk5MzIzIDAw
MDAwIG4gCjAwMDAxMDAxODYgMDAwMDAgbiAKMDAwMDEwMDkyMCAwMDAwMCBuIAowMDAwMTA2NDU3
IDAwMDAwIG4gCjAwMDAxMDEyODEgMDAwMDAgbiAKMDAwMDEwMDQ4OSAwMDAwMCBuIAowMDAwMTAx
MDM2IDAwMDAwIG4gCjAwMDAxMDEzOTYgMDAwMDAgbiAKMDAwMDEwMjIyNyAwMDAwMCBuIAowMDAw
MTAxNzU4IDAwMDAwIG4gCjAwMDAxMDI3MjkgMDAwMDAgbiAKMDAwMDEwMjAxNCAwMDAwMCBuIAow
MDAwMTAyMzQzIDAwMDAwIG4gCjAwMDAxMDI4NDUgMDAwMDAgbiAKMDAwMDEwMzY4MyAwMDAwMCBu
IAowMDAwMTAzMjA3IDAwMDAwIG4gCjAwMDAxMDQwNTUgMDAwMDAgbiAKMDAwMDEwMzQ2MyAwMDAw
MCBuIAowMDAwMTAzNzk5IDAwMDAwIG4gCjAwMDAxMDQxNzEgMDAwMDAgbiAKMDAwMDEwNDQ3NyAw
MDAwMCBuIAowMDAwMTA0NTkzIDAwMDAwIG4gCjAwMDAxMDQ5NTUgMDAwMDAgbiAKMDAwMDEwNTIx
MSAwMDAwMCBuIAowMDAwMTA1NTc5IDAwMDAwIG4gCjAwMDAxMDc3MzIgMDAwMDAgbiAKMDAwMDEw
NTY5NSAwMDAwMCBuIAowMDAwMTA2MjQ0IDAwMDAwIG4gCjAwMDAxMTExNzggMDAwMDAgbiAKMDAw
MDEwNjY0NCAwMDAwMCBuIAowMDAwMTA3MDA2IDAwMDAwIG4gCjAwMDAxMDcyNjIgMDAwMDAgbiAK
MDAwMDEwNzg0OCAwMDAwMCBuIAowMDAwMTA5MTc5IDAwMDAwIG4gCjAwMDAxMDgyMTAgMDAwMDAg
biAKMDAwMDEwODQ2NiAwMDAwMCBuIAowMDAwMTA5Mjk1IDAwMDAwIG4gCjAwMDAxMTA1NjYgMDAw
MDAgbiAKMDAwMDEwOTY1NyAwMDAwMCBuIAowMDAwMTEwOTY1IDAwMDAwIG4gCjAwMDAxMDk5MTMg
MDAwMDAgbiAKMjI2IDk5CjAwMDAxMTA2ODIgMDAwMDAgbiAKMDAwMDExMjQyMiAwMDAwMCBuIAow
MDAwMTExMjg1IDAwMDAwIG4gCjAwMDAxMTE2NDcgMDAwMDAgbiAKMDAwMDExMTkwMyAwMDAwMCBu
IAowMDAwMTEyMjA5IDAwMDAwIG4gCjAwMDAxMTMzNzcgMDAwMDAgbiAKMDAwMDExMjQ2NSAwMDAw
MCBuIAowMDAwMTEzMTYzIDAwMDAwIG4gCjAwMDAxMTgwNTMgMDAwMDAgbiAKMDAwMDExMzQxMiAw
MDAwMCBuIAowMDAwMTEzNzc0IDAwMDAwIG4gCjAwMDAxMTQwMzAgMDAwMDAgbiAKMDAwMDExNDgx
NiAwMDAwMCBuIAowMDAwMTE0OTMyIDAwMDAwIG4gCjAwMDAxMTUyOTQgMDAwMDAgbiAKMDAwMDEx
NTU1MCAwMDAwMCBuIAowMDAwMTE2MzE5IDAwMDAwIG4gCjAwMDAxMTY0MzUgMDAwMDAgbiAKMDAw
MDExNjc5MCAwMDAwMCBuIAowMDAwMTE3MDQwIDAwMDAwIG4gCjAwMDAxMTcyODUgMDAwMDAgbiAK
MDAwMDExOTAyMSAwMDAwMCBuIAowMDAwMTE3NDAxIDAwMDAwIG4gCjAwMDAxMTkzOTkgMDAwMDAg
biAKMDAwMDExNzgzOSAwMDAwMCBuIAowMDAwMTIwNTc5IDAwMDAwIG4gCjAwMDAxMTgxNjAgMDAw
MDAgbiAKMDAwMDEyMDM2NSAwMDAwMCBuIAowMDAwMTE4NTIyIDAwMDAwIG4gCjAwMDAxMTg3Nzgg
MDAwMDAgbiAKMDAwMDExOTEzNyAwMDAwMCBuIAowMDAwMTE5NTE1IDAwMDAwIG4gCjAwMDAxMTk4
NzAgMDAwMDAgbiAKMDAwMDEyMDEyMCAwMDAwMCBuIAowMDAwMTIwOTE3IDAwMDAwIG4gCjAwMDAx
MjM1MjcgMDAwMDAgbiAKMDAwMDEyMDY2MiAwMDAwMCBuIAowMDAwMTIxMDMzIDAwMDAwIG4gCjAw
MDAxMjEzOTUgMDAwMDAgbiAKMDAwMDEyMTY1MSAwMDAwMCBuIAowMDAwMTIyNTUxIDAwMDAwIG4g
CjAwMDAxMjIwMDkgMDAwMDAgbiAKMDAwMDEyMzMxMyAwMDAwMCBuIAowMDAwMTIyMjYyIDAwMDAw
IG4gCjAwMDAxMjI2NjcgMDAwMDAgbiAKMDAwMDEyNDEwMiAwMDAwMCBuIAowMDAwMTIzNjEwIDAw
MDAwIG4gCjAwMDAxMjM4ODggMDAwMDAgbiAKMDAwMDEyNTIxNiAwMDAwMCBuIAowMDAwMTI0MTM3
IDAwMDAwIG4gCjAwMDAxMjQ0OTkgMDAwMDAgbiAKMDAwMDEyNDc1NSAwMDAwMCBuIAowMDAwMTI1
MDAyIDAwMDAwIG4gCjAwMDAxMjczNzYgMDAwMDAgbiAKMDAwMDEyNTI1OSAwMDAwMCBuIAowMDAw
MTI1NjIxIDAwMDAwIG4gCjAwMDAxMjU4NzcgMDAwMDAgbiAKMDAwMDEyNjEyNCAwMDAwMCBuIAow
MDAwMTI2MjQwIDAwMDAwIG4gCjAwMDAxMjY2MDIgMDAwMDAgbiAKMDAwMDEyNjg1OCAwMDAwMCBu
IAowMDAwMTI3MTYyIDAwMDAwIG4gCjAwMDAxMjk5MTIgMDAwMDAgbiAKMDAwMDEyNzQ0MyAwMDAw
MCBuIAowMDAwMTI3ODA1IDAwMDAwIG4gCjAwMDAxMjgwNjEgMDAwMDAgbiAKMDAwMDEyODI4NCAw
MDAwMCBuIAowMDAwMTI4NDAwIDAwMDAwIG4gCjAwMDAxMjg3NDEgMDAwMDAgbiAKMDAwMDEyODg1
NyAwMDAwMCBuIAowMDAwMTI5MjEyIDAwMDAwIG4gCjAwMDAxMjk0NjIgMDAwMDAgbiAKMDAwMDEy
OTY5OCAwMDAwMCBuIAowMDAwMTMwNDE5IDAwMDAwIG4gCjAwMDAxMjk5OTUgMDAwMDAgbiAKMDAw
MDEzMDIwNSAwMDAwMCBuIAowMDAwMTMzNTc4IDAwMDAwIG4gCjAwMDAxMzA0NTQgMDAwMDAgbiAK
MDAwMDEzMDgwOSAwMDAwMCBuIAowMDAwMTMxMDU5IDAwMDAwIG4gCjAwMDAxMzEyNjMgMDAwMDAg
biAKMDAwMDEzMTM3OCAwMDAwMCBuIAowMDAwMTMxNjQ2IDAwMDAwIG4gCjAwMDAxMzE3NjIgMDAw
MDAgbiAKMDAwMDEzMjA0NCAwMDAwMCBuIAowMDAwMTMyMTYwIDAwMDAwIG4gCjAwMDAxMzI0NTkg
MDAwMDAgbiAKMDAwMDEzMzM2NSAwMDAwMCBuIAowMDAwMTM1Nzg3IDAwMDAwIG4gCjAwMDAxMzM2
NzcgMDAwMDAgbiAKMDAwMDEzNDAzOSAwMDAwMCBuIAowMDAwMTM0Mjk1IDAwMDAwIG4gCjAwMDAx
MzQ1MDcgMDAwMDAgbiAKMDAwMDEzNDYyMyAwMDAwMCBuIAowMDAwMTM1NTczIDAwMDAwIG4gCjAw
MDAxMzcxODggMDAwMDAgbiAKMDAwMDEzNTg0NiAwMDAwMCBuIAowMDAwMTM2OTcwIDAwMDAwIG4g
CnRyYWlsZXIKPDwvU2l6ZSAzMjUvUHJldiA4MDgyOS9Sb290IDEzNSAwIFIvSW5mbyAxIDAgUi9J
RFs8NTQxNzNhYTNiMWI1ZDExNDViODcyNjViMjAxNDViMmQ+PDc3NDRFNUFEMzhBOTk1NzM5NTIx
NjFENkY0Q0MwNEQ0Pl0+PgpzdGFydHhyZWYKMTM3MjIzCiUlRU9GCgoxIDAgb2JqCjw8L1Byb2R1
Y2VyIDEzOSAwIFIgL0NyZWF0aW9uRGF0ZSAxNDAgMCBSL01vZERhdGUoRDoyMDE0MDMxMDE5MjQ1
NCswMScwMCcpPj4KZW5kb2JqCjE0MSAwIG9iagpbMzE3MSAzIDgzODEwIDgzODA0IDgwODI5IDgz
Nzk4IDgzODEwIDgzODA0IDgwODI5IDgzNzk4IDEzNzIyMyA8OTIyRDIwQUMwMDREQjIxRDY0REQ1
OTE5RjIxQkI4Mjg+IDIgMCAxNDE1NzEgMTQxNTY1IDE0MTU1OF0KZW5kb2JqCjMyNSAwIG9iago8
PC9MZW5ndGggMj4+c3RyZWFtCnEKCmVuZHN0cmVhbQplbmRvYmoKMzI2IDAgb2JqCjw8L0xlbmd0
aCAyPj5zdHJlYW0KUQoKZW5kc3RyZWFtCmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q
YXJlbnQgMyAwIFIvUmVzb3VyY2VzIDYgMCBSIC9Db250ZW50c1szMjUgMCBSIDQgMCBSIDMyNiAw
IFIgMzMxIDAgUl0vQW5ub3RzIDE0MyAwIFI+PgplbmRvYmoKMTQzIDAgb2JqClszMjcgMCBSIDMy
OCAwIFIgMzI5IDAgUiAzMzAgMCBSXQplbmRvYmoKMTkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh
cmVudCAzIDAgUi9SZXNvdXJjZXMgMjIgMCBSIC9Db250ZW50c1szMjUgMCBSIDIwIDAgUiAzMjYg
MCBSIDMzOSAwIFJdL0Fubm90cyAxNTcgMCBSPj4KZW5kb2JqCjE1NyAwIG9iagpbMzMyIDAgUiAz
MzMgMCBSIDMzNCAwIFIgMzM1IDAgUiAzMzYgMCBSIDMzNyAwIFIgMzM4IDAgUl0KZW5kb2JqCjIz
IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDI2IDAgUiAvQ29u
dGVudHNbMzI1IDAgUiAyNCAwIFIgMzI2IDAgUiAzNDQgMCBSXS9Bbm5vdHMgMTc2IDAgUj4+CmVu
ZG9iagoxNzYgMCBvYmoKWzM0MCAwIFIgMzQxIDAgUiAzNDIgMCBSIDM0MyAwIFJdCmVuZG9iagoy
NyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSL1Jlc291cmNlcyAzMCAwIFIgL0Nv
bnRlbnRzWzMyNSAwIFIgMjggMCBSIDMyNiAwIFIgMzU0IDAgUl0vQW5ub3RzIDE4NyAwIFI+Pgpl
bmRvYmoKMTg3IDAgb2JqClszNDUgMCBSIDM0NiAwIFIgMzQ3IDAgUiAzNDggMCBSIDM0OSAwIFIg
MzUwIDAgUiAzNTEgMCBSIDM1MiAwIFIgMzUzIDAgUl0KZW5kb2JqCjMxIDAgb2JqCjw8IC9UeXBl
IC9QYWdlIC9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDM0IDAgUiAvQ29udGVudHNbMzI1IDAgUiAz
MiAwIFIgMzI2IDAgUiAzNTkgMCBSXS9Bbm5vdHMgMjEyIDAgUj4+CmVuZG9iagoyMTIgMCBvYmoK
WzM1NSAwIFIgMzU2IDAgUiAzNTcgMCBSIDM1OCAwIFJdCmVuZG9iagozNSAwIG9iago8PCAvVHlw
ZSAvUGFnZSAvUGFyZW50IDMgMCBSL1Jlc291cmNlcyAzOCAwIFIgL0NvbnRlbnRzWzMyNSAwIFIg
MzYgMCBSIDMyNiAwIFIgMzYxIDAgUl0vQW5ub3RzIDIyNyAwIFI+PgplbmRvYmoKMjI3IDAgb2Jq
ClszNjAgMCBSXQplbmRvYmoKMzkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0MCAwIFIv
UmVzb3VyY2VzIDQzIDAgUiAvQ29udGVudHNbMzI1IDAgUiA0MSAwIFIgMzI2IDAgUiAzNjMgMCBS
XS9Bbm5vdHMgMjMyIDAgUj4+CmVuZG9iagoyMzIgMCBvYmoKWzM2MiAwIFJdCmVuZG9iago0OCAw
IG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDQwIDAgUi9SZXNvdXJjZXMgNTEgMCBSIC9Db250
ZW50c1szMjUgMCBSIDQ5IDAgUiAzMjYgMCBSIDM2OCAwIFJdL0Fubm90cyAyMzUgMCBSPj4KZW5k
b2JqCjIzNSAwIG9iagpbMzY0IDAgUiAzNjUgMCBSIDM2NiAwIFIgMzY3IDAgUl0KZW5kb2JqCjUy
IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNDAgMCBSL1Jlc291cmNlcyA1NSAwIFIgL0Nv
bnRlbnRzWzMyNSAwIFIgNTMgMCBSIDMyNiAwIFIgMzcyIDAgUl0vQW5ub3RzIDI1MiAwIFI+Pgpl
bmRvYmoKMjUyIDAgb2JqClszNjkgMCBSIDM3MCAwIFIgMzcxIDAgUl0KZW5kb2JqCjU2IDAgb2Jq
Cjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNDAgMCBSL1Jlc291cmNlcyA1OSAwIFIgL0NvbnRlbnRz
WzMyNSAwIFIgNTcgMCBSIDMyNiAwIFIgMzc2IDAgUl0vQW5ub3RzIDI2MiAwIFI+PgplbmRvYmoK
MjYyIDAgb2JqClszNzMgMCBSIDM3NCAwIFIgMzc1IDAgUl0KZW5kb2JqCjYwIDAgb2JqCjw8IC9U
eXBlIC9QYWdlIC9QYXJlbnQgNDAgMCBSL1Jlc291cmNlcyA2MyAwIFIgL0NvbnRlbnRzWzMyNSAw
IFIgNjEgMCBSIDMyNiAwIFIgMzc4IDAgUl0vQW5ub3RzIDI3MiAwIFI+PgplbmRvYmoKMjcyIDAg
b2JqClszNzcgMCBSXQplbmRvYmoKNjQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0MCAw
IFIvUmVzb3VyY2VzIDY3IDAgUiAvQ29udGVudHNbMzI1IDAgUiA2NSAwIFIgMzI2IDAgUiAzODAg
MCBSXS9Bbm5vdHMgMjc1IDAgUj4+CmVuZG9iagoyNzUgMCBvYmoKWzM3OSAwIFJdCmVuZG9iago2
OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDQwIDAgUi9SZXNvdXJjZXMgNzEgMCBSIC9D
b250ZW50c1szMjUgMCBSIDY5IDAgUiAzMjYgMCBSIDM4MyAwIFJdL0Fubm90cyAyODAgMCBSPj4K
ZW5kb2JqCjI4MCAwIG9iagpbMzgxIDAgUiAzODIgMCBSXQplbmRvYmoKODEgMCBvYmoKPDwgL1R5
cGUgL1BhZ2UgL1BhcmVudCA3MyAwIFIvUmVzb3VyY2VzIDg0IDAgUiAvQ29udGVudHNbMzI1IDAg
UiA4MiAwIFIgMzI2IDAgUiAzODcgMCBSXS9Bbm5vdHMgMjg5IDAgUj4+CmVuZG9iagoyODkgMCBv
YmoKWzM4NCAwIFIgMzg1IDAgUiAzODYgMCBSXQplbmRvYmoKODUgMCBvYmoKPDwgL1R5cGUgL1Bh
Z2UgL1BhcmVudCA3MyAwIFIvUmVzb3VyY2VzIDg4IDAgUiAvQ29udGVudHNbMzI1IDAgUiA4NiAw
IFIgMzI2IDAgUiAzODkgMCBSXS9Bbm5vdHMgMzAwIDAgUj4+CmVuZG9iagozMDAgMCBvYmoKWzM4
OCAwIFJdCmVuZG9iago4OSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDczIDAgUi9SZXNv
dXJjZXMgOTIgMCBSIC9Db250ZW50c1szMjUgMCBSIDkwIDAgUiAzMjYgMCBSIDM5NCAwIFJdL0Fu
bm90cyAzMDMgMCBSPj4KZW5kb2JqCjMwMyAwIG9iagpbMzkwIDAgUiAzOTEgMCBSIDM5MiAwIFIg
MzkzIDAgUl0KZW5kb2JqCjkzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNzMgMCBSL1Jl
c291cmNlcyA5NiAwIFIgL0NvbnRlbnRzWzMyNSAwIFIgOTQgMCBSIDMyNiAwIFIgMzk3IDAgUl0v
QW5ub3RzIDMxNSAwIFI+PgplbmRvYmoKMzE1IDAgb2JqClszOTUgMCBSIDM5NiAwIFJdCmVuZG9i
agoxMDUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMDYgMCBSL1Jlc291cmNlcyAxMDkg
MCBSIC9Db250ZW50c1szMjUgMCBSIDEwNyAwIFIgMzI2IDAgUiAzOTkgMCBSXS9Bbm5vdHMgMzIy
IDAgUj4+CmVuZG9iagozMjIgMCBvYmoKWzM5OCAwIFJdCmVuZG9iago0MDEgMCBvYmoKPDwvVHlw
ZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA3MDEuMDAwIDg1
LjAxNSA3MjIuMDAwXS9EZXN0WzIgMCBSIC9YWVogMC4wMDAgNzkyLjAwMCAwXT4+CmVuZG9iagoz
MjcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAu
MDAwIDc3MS4wMDAgMjUuNDUzIDc5Mi4wMDBdL0Rlc3RbNDAwIDAgUiAvWFlaIDYwLjU2MiA3MjIu
MDAwIDBdPj4KZW5kb2JqCjQwMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3Jk
ZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDY2NC41MDAgODUuMDE1IDY4NS41MDBdL0Rlc3RbMiAwIFIg
L1hZWiA1ODYuNTQ3IDUzNS4xNjMgMF0+PgplbmRvYmoKMzI4IDAgb2JqCjw8L1R5cGUvQW5ub3Qv
U3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1ODYuNTQ3IDUxNC4xNjMgNjEyLjAwMCA1
MzUuMTYzXS9EZXN0WzQwMCAwIFIgL1hZWiA2MC41NjIgNjg1LjUwMCAwXT4+CmVuZG9iago0MDMg
MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2
MiA1OTIuMDAwIDg1LjAxNSA2MTMuMDAwXS9EZXN0WzIgMCBSIC9YWVogNTg2LjU0NyA3OTIuMDAw
IDBdPj4KZW5kb2JqCjMyOSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJb
MCAwIDBdL1JlY3RbNTg2LjU0NyA3NzEuMDAwIDYxMi4wMDAgNzkyLjAwMF0vRGVzdFs0MDAgMCBS
IC9YWVogNjAuNTYyIDYxMy4wMDAgMF0+PgplbmRvYmoKNDA1IDAgb2JqCjw8L1R5cGUvQW5ub3Qv
U3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgNzAxLjAwMCA4NS4wMTUgNzIy
LjAwMF0vRGVzdFsyIDAgUiAvWFlaIDAuMDAwIDc3MS4wMDAgMF0+PgplbmRvYmoKMzMwIDAgb2Jq
Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA3NTAu
MDAwIDI1LjQ1MyA3NzEuMDAwXS9EZXN0WzQwNCAwIFIgL1hZWiA2MC41NjIgNzIyLjAwMCAwXT4+
CmVuZG9iago0MDYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAw
XS9SZWN0WzYwLjU2MiAxNzIuNTAwIDg1LjAxNSAxOTMuNTAwXS9EZXN0WzE5IDAgUiAvWFlaIDAu
MDAwIDcyNS4yODQgMF0+PgplbmRvYmoKMzMyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9M
aW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA3MDQuMjg0IDI1LjQ1MyA3MjUuMjg0XS9EZXN0
WzQwNCAwIFIgL1hZWiA2MC41NjIgMTkzLjUwMCAwXT4+CmVuZG9iago0MDcgMCBvYmoKPDwvVHlw
ZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiAxMTIuMDAwIDg1
LjAxNSAxMzMuMDAwXS9EZXN0WzE5IDAgUiAvWFlaIDAuMDAwIDcwNC4yODQgMF0+PgplbmRvYmoK
MzMzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFsw
LjAwMCA2ODMuMjg0IDI1LjQ1MyA3MDQuMjg0XS9EZXN0WzQwNCAwIFIgL1hZWiA2MC41NjIgMTMz
LjAwMCAwXT4+CmVuZG9iago0MDkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9y
ZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA3MDEuMDAwIDg1LjAxNSA3MjIuMDAwXS9EZXN0WzE5IDAg
UiAvWFlaIDAuMDAwIDY4My4yODQgMF0+PgplbmRvYmoKMzM0IDAgb2JqCjw8L1R5cGUvQW5ub3Qv
U3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA2NjIuMjg0IDI1LjQ1MyA2ODMu
Mjg0XS9EZXN0WzQwOCAwIFIgL1hZWiA2MC41NjIgNzIyLjAwMCAwXT4+CmVuZG9iago0MTAgMCBv
YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA1
MzIuNTAwIDg1LjAxNSA1NTMuNTAwXS9EZXN0WzE5IDAgUiAvWFlaIDAuMDAwIDUxMS40NzggMF0+
PgplbmRvYmoKMzM1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAg
MF0vUmVjdFswLjAwMCA0OTAuNDc4IDI1LjQ1MyA1MTEuNDc4XS9EZXN0WzQwOCAwIFIgL1hZWiA2
MC41NjIgNTUzLjUwMCAwXT4+CmVuZG9iago0MTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl
L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA0MzYuMDAwIDg1LjAxNSA0NTcuMDAwXS9E
ZXN0WzE5IDAgUiAvWFlaIDU4Ni41NDcgMzMwLjI1MyAwXT4+CmVuZG9iagozMzYgMCBvYmoKPDwv
VHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4Ni41NDcgMzA5LjI1
MyA2MTIuMDAwIDMzMC4yNTNdL0Rlc3RbNDA4IDAgUiAvWFlaIDYwLjU2MiA0NTcuMDAwIDBdPj4K
ZW5kb2JqCjQxMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd
L1JlY3RbNjAuNTYyIDM5OS41MDAgODUuMDE1IDQyMC41MDBdL0Rlc3RbMTkgMCBSIC9YWVogNTg2
LjU0NyA1OTUuMTYzIDBdPj4KZW5kb2JqCjMzNyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv
TGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTg2LjU0NyA1NzQuMTYzIDYxMi4wMDAgNTk1LjE2M10v
RGVzdFs0MDggMCBSIC9YWVogNjAuNTYyIDQyMC41MDAgMF0+PgplbmRvYmoKNDEzIDAgb2JqCjw8
L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgMzE1LjAw
MCA4NS4wMTUgMzM2LjAwMF0vRGVzdFsxOSAwIFIgL1hZWiA1ODYuNTQ3IDU3NC4xNjMgMF0+Pgpl
bmRvYmoKMzM4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v
UmVjdFs1ODYuNTQ3IDU1My4xNjMgNjEyLjAwMCA1NzQuMTYzXS9EZXN0WzQwOCAwIFIgL1hZWiA2
MC41NjIgMzM2LjAwMCAwXT4+CmVuZG9iago0MTQgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl
L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiAxNzAuNTAwIDg1LjAxNSAxOTEuNTAwXS9E
ZXN0WzIzIDAgUiAvWFlaIDAuMDAwIDU4OC41MTggMF0+PgplbmRvYmoKMzQwIDAgb2JqCjw8L1R5
cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA1NjcuNTE4IDI1
LjQ1MyA1ODguNTE4XS9EZXN0WzQwOCAwIFIgL1hZWiA2MC41NjIgMTkxLjUwMCAwXT4+CmVuZG9i
ago0MTYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0
WzYwLjU2MiA3MDEuMDAwIDg1LjAxNSA3MjIuMDAwXS9EZXN0WzIzIDAgUiAvWFlaIDAuMDAwIDI4
OS41MjcgMF0+PgplbmRvYmoKMzQxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0Jv
cmRlclswIDAgMF0vUmVjdFswLjAwMCAyNjguNTI3IDI1LjQ1MyAyODkuNTI3XS9EZXN0WzQxNSAw
IFIgL1hZWiA2MC41NjIgNzIyLjAwMCAwXT4+CmVuZG9iago0MTcgMCBvYmoKPDwvVHlwZS9Bbm5v
dC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA2NTIuNTAwIDg1LjAxNSA2
NzMuNTAwXS9EZXN0WzIzIDAgUiAvWFlaIDAuMDAwIDIyNi41MDIgMF0+PgplbmRvYmoKMzQyIDAg
b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAy
MDUuNTAyIDI1LjQ1MyAyMjYuNTAyXS9EZXN0WzQxNSAwIFIgL1hZWiA2MC41NjIgNjczLjUwMCAw
XT4+CmVuZG9iago0MTggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg
MCAwXS9SZWN0WzYwLjU2MiA0NjAuMDAwIDg1LjAxNSA0ODEuMDAwXS9EZXN0WzIzIDAgUiAvWFla
IDAuMDAwIDI2OC41MjcgMF0+PgplbmRvYmoKMzQzIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw
ZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAyNDcuNTI3IDI1LjQ1MyAyNjguNTI3XS9E
ZXN0WzQxNSAwIFIgL1hZWiA2MC41NjIgNDgxLjAwMCAwXT4+CmVuZG9iago0MTkgMCBvYmoKPDwv
VHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiAyNjcuNTAw
IDg1LjAxNSAyODguNTAwXS9EZXN0WzI3IDAgUiAvWFlaIDAuMDAwIDczMS41MTAgMF0+PgplbmRv
YmoKMzQ1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVj
dFswLjAwMCA3MTAuNTEwIDI1LjQ1MyA3MzEuNTEwXS9EZXN0WzQxNSAwIFIgL1hZWiA2MC41NjIg
Mjg4LjUwMCAwXT4+CmVuZG9iago0MjAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv
Qm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiAyMDcuMDAwIDg1LjAxNSAyMjguMDAwXS9EZXN0WzI3
IDAgUiAvWFlaIDAuMDAwIDY4NS40MjkgMF0+PgplbmRvYmoKMzQ2IDAgb2JqCjw8L1R5cGUvQW5u
b3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA2NjQuNDI5IDI1LjQ1MyA2
ODUuNDI5XS9EZXN0WzQxNSAwIFIgL1hZWiA2MC41NjIgMjI4LjAwMCAwXT4+CmVuZG9iago0MjEg
MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2
MiAxNzAuNTAwIDg1LjAxNSAxOTEuNTAwXS9EZXN0WzI3IDAgUiAvWFlaIDAuMDAwIDU4MC44MDMg
MF0+PgplbmRvYmoKMzQ3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclsw
IDAgMF0vUmVjdFswLjAwMCA1NTkuODAzIDI1LjQ1MyA1ODAuODAzXS9EZXN0WzQxNSAwIFIgL1hZ
WiA2MC41NjIgMTkxLjUwMCAwXT4+CmVuZG9iago0MjIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0
eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiAxMzQuMDAwIDg1LjAxNSAxNTUuMDAw
XS9EZXN0WzI3IDAgUiAvWFlaIDU4Ni41NDcgNTYyLjY5MSAwXT4+CmVuZG9iagozNDggMCBvYmoK
PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4Ni41NDcgNTQx
LjY5MSA2MTIuMDAwIDU2Mi42OTFdL0Rlc3RbNDE1IDAgUiAvWFlaIDYwLjU2MiAxNTUuMDAwIDBd
Pj4KZW5kb2JqCjQyMyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw
IDBdL1JlY3RbNjAuNTYyIDg1LjUwMCA4NS4wMTUgMTA2LjUwMF0vRGVzdFsyNyAwIFIgL1hZWiAw
LjAwMCA1NDcuMDcyIDBdPj4KZW5kb2JqCjM0OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv
TGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNTI2LjA3MiAyNS40NTMgNTQ3LjA3Ml0vRGVz
dFs0MTUgMCBSIC9YWVogNjAuNTYyIDEwNi41MDAgMF0+PgplbmRvYmoKNDI0IDAgb2JqCjw8L1R5
cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs2MC41NjIgNDkuMDAwIDg1
LjAxNSA3MC4wMDBdL0Rlc3RbMjcgMCBSIC9YWVogNTg2LjU0NyA1MjQuMTcxIDBdPj4KZW5kb2Jq
CjM1MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb
NTg2LjU0NyA1MDMuMTcxIDYxMi4wMDAgNTI0LjE3MV0vRGVzdFs0MTUgMCBSIC9YWVogNjAuNTYy
IDcwLjAwMCAwXT4+CmVuZG9iago0MjYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv
Qm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA3MDEuMDAwIDg1LjAxNSA3MjIuMDAwXS9EZXN0WzI3
IDAgUiAvWFlaIDAuMDAwIDI0MC4wMTQgMF0+PgplbmRvYmoKMzUxIDAgb2JqCjw8L1R5cGUvQW5u
b3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAyMTkuMDE0IDI1LjQ1MyAy
NDAuMDE0XS9EZXN0WzQyNSAwIFIgL1hZWiA2MC41NjIgNzIyLjAwMCAwXT4+CmVuZG9iago0Mjcg
MCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2
MiA2NTIuNTAwIDg1LjAxNSA2NzMuNTAwXS9EZXN0WzI3IDAgUiAvWFlaIDAuMDAwIDIxOS4wMTQg
MF0+PgplbmRvYmoKMzUyIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclsw
IDAgMF0vUmVjdFswLjAwMCAxOTguMDE0IDI1LjQ1MyAyMTkuMDE0XS9EZXN0WzQyNSAwIFIgL1hZ
WiA2MC41NjIgNjczLjUwMCAwXT4+CmVuZG9iago0MjggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0
eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA2MDQuMDAwIDg1LjAxNSA2MjUuMDAw
XS9EZXN0WzI3IDAgUiAvWFlaIDAuMDAwIDM5MS40ODEgMF0+PgplbmRvYmoKMzUzIDAgb2JqCjw8
L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCAzNzAuNDgx
IDI1LjQ1MyAzOTEuNDgxXS9EZXN0WzQyNSAwIFIgL1hZWiA2MC41NjIgNjI1LjAwMCAwXT4+CmVu
ZG9iago0MjkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9S
ZWN0WzYwLjU2MiA0OTUuNTAwIDg1LjAxNSA1MTYuNTAwXS9EZXN0WzMxIDAgUiAvWFlaIDAuMDAw
IDc1Mi40ODYgMF0+PgplbmRvYmoKMzU1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5r
L0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA3MzEuNDg2IDI1LjQ1MyA3NTIuNDg2XS9EZXN0WzQy
NSAwIFIgL1hZWiA2MC41NjIgNTE2LjUwMCAwXT4+CmVuZG9iago0MzAgMCBvYmoKPDwvVHlwZS9B
bm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzYwLjU2MiA0MzUuMDAwIDg1LjAx
NSA0NTYuMDAwXS9EZXN0WzMxIDAgUiAvWFlaIDAuMDAwIDcyNi4yMTcgMF0+PgplbmRvYmoKMzU2
IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAw
MCA3MDUuMjE3IDI1LjQ1MyA3MjYuMjE3XS9EZXN0WzQyNSAwIFIgL1hZWiA2MC41NjIgNDU2LjAw
MCAwXT4+CmVuZG9iago0MzEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVy
WzAgMCAwXS9SZWN0WzYwLjU2MiAzMTQuNTAwIDg1LjAxNSAzMzUuNTAwXS9EZXN0WzMxIDAgUiAv
WFlaIDU4Ni41NDcgNzExLjczMiAwXT4+CmVuZG9iagozNTcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T
dWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4Ni41NDcgNjkwLjczMiA2MTIuMDAwIDcx
MS43MzJdL0Rlc3RbNDI1IDAgUiAvWFlaIDYwLjU2MiAzMzUuNTAwIDBdPj4KZW5kb2JqCjQzMiAw
IG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYy
IDE4Mi4wMDAgODUuMDE1IDIwMy4wMDBdL0Rlc3RbMzEgMCBSIC9YWVogMC4wMDAgNTY4LjgwMyAw
XT4+CmVuZG9iagozNTggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg
MCAwXS9SZWN0WzAuMDAwIDU0Ny44MDMgMjUuNDUzIDU2OC44MDNdL0Rlc3RbNDI1IDAgUiAvWFla
IDYwLjU2MiAyMDMuMDAwIDBdPj4KZW5kb2JqCjQzMyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5
cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNjAuNTYyIDE0NS41MDAgODUuMDE1IDE2Ni41MDBd
L0Rlc3RbMzUgMCBSIC9YWVogNTg2LjU0NyA2MzYuOTYwIDBdPj4KZW5kb2JqCjM2MCAwIG9iago8
PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTg2LjU0NyA2MTUu
OTYwIDYxMi4wMDAgNjM2Ljk2MF0vRGVzdFs0MjUgMCBSIC9YWVogNjAuNTYyIDE2Ni41MDAgMF0+
PgplbmRvYmoKNDM1IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAg
MF0vUmVjdFs2MC41NjIgNzAxLjAwMCA4NS4wMTUgNzIyLjAwMF0vRGVzdFszOSAwIFIgL1hZWiAw
LjAwMCAzMDMuMDM5IDBdPj4KZW5kb2JqCjM2MiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUv
TGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgMjgyLjAzOSAyNS40NTMgMzAzLjAzOV0vRGVz
dFs0MzQgMCBSIC9YWVogNjAuNTYyIDcyMi4wMDAgMF0+PgplbmRvYmoKNDM2IDAgb2JqCjw8L1R5
cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS43MzcgNTU2LjUwMCA4
NS4wMTUgNTc3LjUwMF0vRGVzdFs0OCAwIFIgL1hZWiA1ODEuNzIzIDUzOS44NjYgMF0+PgplbmRv
YmoKMzY0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVj
dFs1ODEuNzIzIDUxOC44NjYgNjEyLjAwMCA1MzkuODY2XS9EZXN0WzQzNCAwIFIgL1hZWiA1NS43
MzcgNTc3LjUwMCAwXT4+CmVuZG9iago0MzcgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp
bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjczNyA0MTIuMDAwIDg1LjAxNSA0MzMuMDAwXS9EZXN0
WzQ4IDAgUiAvWFlaIDAuMDAwIDUwOS43MjYgMF0+PgplbmRvYmoKMzY1IDAgb2JqCjw8L1R5cGUv
QW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA0ODguNzI2IDMwLjI3
NyA1MDkuNzI2XS9EZXN0WzQzNCAwIFIgL1hZWiA1NS43MzcgNDMzLjAwMCAwXT4+CmVuZG9iago0
MzggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1
LjczNyAyNzkuNTAwIDg1LjAxNSAzMDAuNTAwXS9EZXN0WzQ4IDAgUiAvWFlaIDAuMDAwIDUzMy42
MjggMF0+PgplbmRvYmoKMzY2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRl
clswIDAgMF0vUmVjdFswLjAwMCA1MTIuNjI4IDMwLjI3NyA1MzMuNjI4XS9EZXN0WzQzNCAwIFIg
L1hZWiA1NS43MzcgMzAwLjUwMCAwXT4+CmVuZG9iago0MzkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T
dWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjczNyAyNDMuMDAwIDg1LjAxNSAyNjQu
MDAwXS9EZXN0WzQ4IDAgUiAvWFlaIDU4MS43MjMgNjc0LjI4OCAwXT4+CmVuZG9iagozNjcgMCBv
YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4MS43MjMg
NjUzLjI4OCA2MTIuMDAwIDY3NC4yODhdL0Rlc3RbNDM0IDAgUiAvWFlaIDU1LjczNyAyNjQuMDAw
IDBdPj4KZW5kb2JqCjQ0MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJb
MCAwIDBdL1JlY3RbNTUuMDAwIDE3MC41MDAgODUuMDE1IDE5MS41MDBdL0Rlc3RbNTIgMCBSIC9Y
WVogNTgwLjk4NSA3MzguMzY4IDBdPj4KZW5kb2JqCjM2OSAwIG9iago8PC9UeXBlL0Fubm90L1N1
YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTgwLjk4NSA3MTcuMzY4IDYxMi4wMDAgNzM4
LjM2OF0vRGVzdFs0MzQgMCBSIC9YWVogNTUuMDAwIDE5MS41MDAgMF0+PgplbmRvYmoKNDQxIDAg
b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAg
MTM0LjAwMCA4NS4wMTUgMTU1LjAwMF0vRGVzdFs1MiAwIFIgL1hZWiA1ODAuOTg1IDQxMS4yNDUg
MF0+PgplbmRvYmoKMzcwIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclsw
IDAgMF0vUmVjdFs1ODAuOTg1IDM5MC4yNDUgNjEyLjAwMCA0MTEuMjQ1XS9EZXN0WzQzNCAwIFIg
L1hZWiA1NS4wMDAgMTU1LjAwMCAwXT4+CmVuZG9iago0NDIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T
dWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCA5Ny41MDAgODUuMDE1IDExOC41
MDBdL0Rlc3RbNTIgMCBSIC9YWVogMC4wMDAgNzI1LjU3NiAwXT4+CmVuZG9iagozNzEgMCBvYmoK
PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDcwNC41
NzYgMzEuMDE1IDcyNS41NzZdL0Rlc3RbNDM0IDAgUiAvWFlaIDU1LjAwMCAxMTguNTAwIDBdPj4K
ZW5kb2JqCjQ0MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd
L1JlY3RbNTUuMDAwIDYxLjAwMCA4NS4wMTUgODIuMDAwXS9EZXN0WzU2IDAgUiAvWFlaIDU4MC45
ODUgNDk2Ljc1NyAwXT4+CmVuZG9iagozNzMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp
bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4MC45ODUgNDc1Ljc1NyA2MTIuMDAwIDQ5Ni43NTddL0Rl
c3RbNDM0IDAgUiAvWFlaIDU1LjAwMCA4Mi4wMDAgMF0+PgplbmRvYmoKNDQ1IDAgb2JqCjw8L1R5
cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgNzAxLjAwMCA4
NS4wMTUgNzIyLjAwMF0vRGVzdFs1NiAwIFIgL1hZWiAwLjAwMCAzODkuNTc2IDBdPj4KZW5kb2Jq
CjM3NCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb
MC4wMDAgMzY4LjU3NiAzMS4wMTUgMzg5LjU3Nl0vRGVzdFs0NDQgMCBSIC9YWVogNTUuMDAwIDcy
Mi4wMDAgMF0+PgplbmRvYmoKNDQ2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0Jv
cmRlclswIDAgMF0vUmVjdFs1NS4wMDAgNjI4LjUwMCA4NS4wMTUgNjQ5LjUwMF0vRGVzdFs1NiAw
IFIgL1hZWiAwLjAwMCAzNjguNTc2IDBdPj4KZW5kb2JqCjM3NSAwIG9iago8PC9UeXBlL0Fubm90
L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgMzQ3LjU3NiAzMS4wMTUgMzY4
LjU3Nl0vRGVzdFs0NDQgMCBSIC9YWVogNTUuMDAwIDY0OS41MDAgMF0+PgplbmRvYmoKNDQ3IDAg
b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAg
NDg0LjAwMCA4NS4wMTUgNTA1LjAwMF0vRGVzdFs2MCAwIFIgL1hZWiAwLjAwMCAzMDQuMTYyIDBd
Pj4KZW5kb2JqCjM3NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw
IDBdL1JlY3RbMC4wMDAgMjgzLjE2MiAzMS4wMTUgMzA0LjE2Ml0vRGVzdFs0NDQgMCBSIC9YWVog
NTUuMDAwIDUwNS4wMDAgMF0+PgplbmRvYmoKNDQ4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw
ZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgNDQ3LjUwMCA4NS4wMTUgNDY4LjUwMF0v
RGVzdFs2NCAwIFIgL1hZWiAwLjAwMCA3MzcuNjc0IDBdPj4KZW5kb2JqCjM3OSAwIG9iago8PC9U
eXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNzE2LjY3NCAz
MS4wMTUgNzM3LjY3NF0vRGVzdFs0NDQgMCBSIC9YWVogNTUuMDAwIDQ2OC41MDAgMF0+PgplbmRv
YmoKNDQ5IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVj
dFs1NS4wMDAgNDExLjAwMCA4NS4wMTUgNDMyLjAwMF0vRGVzdFs2OCAwIFIgL1hZWiAwLjAwMCA3
MjYuMTc4IDBdPj4KZW5kb2JqCjM4MSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C
b3JkZXJbMCAwIDBdL1JlY3RbMC4wMDAgNzA1LjE3OCAzMS4wMTUgNzI2LjE3OF0vRGVzdFs0NDQg
MCBSIC9YWVogNTUuMDAwIDQzMi4wMDAgMF0+PgplbmRvYmoKNDUwIDAgb2JqCjw8L1R5cGUvQW5u
b3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4wMDAgMzc0LjUwMCA4NS4wMTUg
Mzk1LjUwMF0vRGVzdFs2OCAwIFIgL1hZWiA1ODAuOTg1IDY4OC43NTcgMF0+PgplbmRvYmoKMzgy
IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1ODAu
OTg1IDY2Ny43NTcgNjEyLjAwMCA2ODguNzU3XS9EZXN0WzQ0NCAwIFIgL1hZWiA1NS4wMDAgMzk1
LjUwMCAwXT4+CmVuZG9iago0NTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9y
ZGVyWzAgMCAwXS9SZWN0WzU1LjAwMCAzMjYuMDAwIDg1LjAxNSAzNDcuMDAwXS9EZXN0WzgxIDAg
UiAvWFlaIDU4MC45ODUgNjE5Ljc4MiAwXT4+CmVuZG9iagozODQgMCBvYmoKPDwvVHlwZS9Bbm5v
dC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU4MC45ODUgNTk4Ljc4MiA2MTIuMDAw
IDYxOS43ODJdL0Rlc3RbNDQ0IDAgUiAvWFlaIDU1LjAwMCAzNDcuMDAwIDBdPj4KZW5kb2JqCjQ1
MiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUu
MDAwIDI4OS41MDAgODUuMDE1IDMxMC41MDBdL0Rlc3RbODEgMCBSIC9YWVogMC4wMDAgNDUwLjY4
MiAwXT4+CmVuZG9iagozODUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVy
WzAgMCAwXS9SZWN0WzAuMDAwIDQyOS42ODIgMzEuMDE1IDQ1MC42ODJdL0Rlc3RbNDQ0IDAgUiAv
WFlaIDU1LjAwMCAzMTAuNTAwIDBdPj4KZW5kb2JqCjQ1MyAwIG9iago8PC9UeXBlL0Fubm90L1N1
YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDI0MS4wMDAgODUuMDE1IDI2Mi4w
MDBdL0Rlc3RbODEgMCBSIC9YWVogMC4wMDAgMzUxLjgxMiAwXT4+CmVuZG9iagozODYgMCBvYmoK
PDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDMzMC44
MTIgMzEuMDE1IDM1MS44MTJdL0Rlc3RbNDQ0IDAgUiAvWFlaIDU1LjAwMCAyNjIuMDAwIDBdPj4K
ZW5kb2JqCjQ1NCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd
L1JlY3RbNTUuMDAwIDIwNC41MDAgODUuMDE1IDIyNS41MDBdL0Rlc3RbODUgMCBSIC9YWVogMC4w
MDAgNzAxLjMyNCAwXT4+CmVuZG9iagozODggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp
bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDY4MC4zMjQgMzEuMDE1IDcwMS4zMjRdL0Rlc3Rb
NDQ0IDAgUiAvWFlaIDU1LjAwMCAyMjUuNTAwIDBdPj4KZW5kb2JqCjQ1NSAwIG9iago8PC9UeXBl
L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDE2OC4wMDAgODUu
MDE1IDE4OS4wMDBdL0Rlc3RbODkgMCBSIC9YWVogMC4wMDAgNDU5LjMwOCAwXT4+CmVuZG9iagoz
OTAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAu
MDAwIDQzOC4zMDggMzEuMDE1IDQ1OS4zMDhdL0Rlc3RbNDQ0IDAgUiAvWFlaIDU1LjAwMCAxODku
MDAwIDBdPj4KZW5kb2JqCjQ1NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3Jk
ZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDEzMS41MDAgODUuMDE1IDE1Mi41MDBdL0Rlc3RbODkgMCBS
IC9YWVogNTgwLjk4NSA0NDYuMjM3IDBdPj4KZW5kb2JqCjM5MSAwIG9iago8PC9UeXBlL0Fubm90
L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTgwLjk4NSA0MjUuMjM3IDYxMi4wMDAg
NDQ2LjIzN10vRGVzdFs0NDQgMCBSIC9YWVogNTUuMDAwIDE1Mi41MDAgMF0+PgplbmRvYmoKNDU3
IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1NS4w
MDAgOTUuMDAwIDg1LjAxNSAxMTYuMDAwXS9EZXN0Wzg5IDAgUiAvWFlaIDU4MC45ODUgMzYzLjg0
NyAwXT4+CmVuZG9iagozOTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVy
WzAgMCAwXS9SZWN0WzU4MC45ODUgMzQyLjg0NyA2MTIuMDAwIDM2My44NDddL0Rlc3RbNDQ0IDAg
UiAvWFlaIDU1LjAwMCAxMTYuMDAwIDBdPj4KZW5kb2JqCjQ1OSAwIG9iago8PC9UeXBlL0Fubm90
L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDcwMS4wMDAgODUuMDE1IDcy
Mi4wMDBdL0Rlc3RbODkgMCBSIC9YWVogMC4wMDAgMjg4LjUzNSAwXT4+CmVuZG9iagozOTMgMCBv
YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDI2
Ny41MzUgMzEuMDE1IDI4OC41MzVdL0Rlc3RbNDU4IDAgUiAvWFlaIDU1LjAwMCA3MjIuMDAwIDBd
Pj4KZW5kb2JqCjQ2MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw
IDBdL1JlY3RbNTUuMDAwIDU0NC41MDAgODUuMDE1IDU2NS41MDBdL0Rlc3RbOTMgMCBSIC9YWVog
MC4wMDAgNjQ0LjYwMSAwXT4+CmVuZG9iagozOTUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl
L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzAuMDAwIDYyMy42MDEgMzEuMDE1IDY0NC42MDFdL0Rl
c3RbNDU4IDAgUiAvWFlaIDU1LjAwMCA1NjUuNTAwIDBdPj4KZW5kb2JqCjQ2MSAwIG9iago8PC9U
eXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDUwOC4wMDAg
ODUuMDE1IDUyOS4wMDBdL0Rlc3RbOTMgMCBSIC9YWVogMC4wMDAgMzY3LjU5MiAwXT4+CmVuZG9i
agozOTYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0
WzAuMDAwIDM0Ni41OTIgMzEuMDE1IDM2Ny41OTJdL0Rlc3RbNDU4IDAgUiAvWFlaIDU1LjAwMCA1
MjkuMDAwIDBdPj4KZW5kb2JqCjQ2MiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C
b3JkZXJbMCAwIDBdL1JlY3RbNTUuMDAwIDM1MS41MDAgODUuMDE1IDM3Mi41MDBdL0Rlc3RbMTA1
IDAgUiAvWFlaIDAuMDAwIDUyMS42NzQgMF0+PgplbmRvYmoKMzk4IDAgb2JqCjw8L1R5cGUvQW5u
b3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFswLjAwMCA1MDAuNjc0IDMxLjAxNSA1
MjEuNjc0XS9EZXN0WzQ1OCAwIFIgL1hZWiA1NS4wMDAgMzcyLjUwMCAwXT4+CmVuZG9iago0NjMg
MCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvVFpQV01W
K0hlbHZldGljYSAvRm9udERlc2NyaXB0b3IgNDY3IDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5j
b2RpbmcgL0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgMjIzIC9XaWR0aHMgWwoyNzggMCAzNTUgMCAw
IDAgMCAxOTEgMzMzIDMzMyAzODkgNTg0IDI3OCAzMzMgMjc4IDI3OCA1NTYgNTU2IDU1NiA1NTYg
NTU2CjU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCA1ODQgNTg0IDU4NCA1NTYgMCA2NjcgNjY3
IDcyMiA3MjIgNjY3IDYxMSA3NzgKNzIyIDI3OCA1MDAgNjY3IDU1NiA4MzMgNzIyIDc3OCA2Njcg
Nzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgMAoyNzggMCAyNzggMCA1NTYgMCA1
NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2CjU1
NiA1NTYgNTU2IDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDUwMCA1MDAgXSA+PgplbmRvYmoKNDY0IDAgb2JqCjw8IC9UeXBlIC9F
eHRHU3RhdGUgL0JNIC9NdWx0aXBseSA+PgplbmRvYmoKNDY1IDAgb2JqCjw8IC9UeXBlIC9FeHRH
U3RhdGUgL0JNIC9Ob3JtYWwgPj4KZW5kb2JqCjQ2NiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3Vi
dHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9RSEZCS08rSGVsdmV0aWNhIC9Gb250RGVzY3JpcHRv
ciA0NjkgMCBSIC9Ub1VuaWNvZGUgNDcwIDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAzMyAv
V2lkdGhzIFsgMjc4IF0gPj4KZW5kb2JqCjQ2NyAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0
b3IgL0ZvbnROYW1lIC9UWlBXTVYrSGVsdmV0aWNhIC9GbGFncyAzMiAvRm9udEJCb3ggWy05NTEg
LTQ4MSAxNDQ1IDExMjJdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgNzcwIC9EZXNjZW50IC0yMzAg
L0NhcEhlaWdodCA3MTcgL1N0ZW1WIDAgL1hIZWlnaHQKNTIzIC9BdmdXaWR0aCAtNDQxIC9NYXhX
aWR0aCAxNTAwIC9Gb250RmlsZTIgNDY4IDAgUiA+PgplbmRvYmoKNDY4IDAgb2JqCjw8IC9MZW5n
dGgxIDI0MjY4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNjQ2OT4+c3RyZWFtCngBvXx5
fFXF2f/M2e+au2+5S25u7r1ZICF7AoFcISHsIqAkCMi+KWURwqLQqOxSXFgLqOCCCCIBogQRaxGL
qK3gLi6tFSldUtu+aKtwT37fOTcgpH376x/9vLl5zpk5y5yZZ5555nm+85xDKCHERJoIT4aOGj97
Chk58iSOfEqItGHizPGzlx1q20yIPJsQapvYOC/joXi/fYQoywjh10yZPXXmBWHzu4QYLYToA1Pv
WDRlSuLsx4S4uhGSeH3a5PGThP/ZGyTkln+gzLJpOKDPlO8gZCTOk6xpM+ctnFQd9CM/AuUPvWPW
xPFNz935MCH1T+L8npnjF85WWg2FhDQMRT7jR+NnTr556V2oT8Ns5DNnz7pznrJY+RvyG5B/Y/bc
ybP37o4dJGTUOEKEGYS1Tfuj9Sh/EmgeCHWnuJ7iGbQFdAL0Hugc6CIhnABygLJAJaAa0AjQJNA8
0DLQBtCToBbQCdB7oHOgi+CLAHKAskAloBrQCNAk0DzQMtAG0JOgFtAJ0Hugc6CLqLcAcoCyQCWg
GtAI0CTQPNAy0AbQk6AW0AnQe6BzoIuEiALIAcoClYBqQCNAk0DzQMtAG0BPglpAJ0Dvgc6BLqLf
BZADlAUqAdWARoAmgeaBlrV3/DHWXk1TktEpn9kpH++Uz+6Uz+mUz+2Uz+uU79Ip37VTPr9TvqBT
nsngtfWHnF2XL+qUL+6UB2+uu760U76sU768U76iU76yU757p3yPTvmqTvmenfK9OuWrO+Vv6JTv
3Snfp1MecnBde2s75ft2ytd1yvfrlO/fKT+gU35gp/ygTvnBnfJDOuVv7JRnOuTa/r6pU35Yp/zw
TnmMgevuv7lT/pZO+ZGd8tBB193f0Cl/a6f8mE752zrlx3fKT+iUn9gpj/F73fMnd8pP6ZSf2ik/
rVN+eqf8jE752zvlofeve/7MTvkfdcrP6pRnOv/a/pvTKT+3U/7OTnnoruvun98p39gpv6BTfmGn
/KJO+cXX5y9ps88P+vESx87jj3bMS0YkpdShf7elRLuRF0RJVnR6g9FkTrNYbXaH0+X2eH3pxB8I
hjLCmZGsaCyenZOb16VrfkG3wqLiElJKykg5qajs3qOqZ6/qxA29+9TU9q3r13/AwEGDh9w4VBsA
/+7R/4Vzw7RR9O8LEl8hFvEYyRabiE8oICH00segs2yv3tx+XjxJLOrM9r/yTAMeYcSp1VXkFfIT
so3sJxLZjXQ2GUu2kFN0BjlCR5MW8gENknzSRATSSgaRt2h7+xkyhTyJ6+eR42QjOUCMuGcmceLs
OhptX4x8AukJZFn74ySLVJAV5BipRKnrSFv7M+2HcHYYuZnsIXtx/5s0wh0Q7O3PtZ8jCrkJZS7D
mTPtg9r3ExvpQnqToTi6jLxMo/zZ9mnEQ3qgdtvJY2Qn+Tn5E72XtrRPa29sP93+BbrXQ/xkOH5L
aAv9gt8vrGjf3v6HdhWcyCa5eOo4sp48gfL34/cKxKeW3k7n0fV0I5fg7uVahOWiW02CDzmkDr9+
ZBZZBQ4cISfI38h39GvOw1v4efxr7aXt/0MMZCBayVoymTTitxK/dWjTUSrRbrQPHUqX0A10I32X
y+Vu5uq5BdxC7jw/hB/NL+LfFe4UDoprxS2SQf2m/Wj7yfb3iZsEyK1kLlmK1h0np8lF8j3lUZaf
RmkP2puOxa+JbuOO0J30CDeUvkJPc3vor+mX9Gt6iRM5I+fk8rh53HpuL3ec+xU/nd/I/5T/Nf+N
0EvkxJ3iV1JU/kSdoK5Wf9Xeo/2L9n/AUlVIGD3Tmwwht5HxaO1sUkJ+jFbsw28/eu0EeY2c0n5f
Uj9pI/8AF2C/Uh8tooPxG0JvpFPodPoofRG/l7W6fMuhIzgdZ+XcnJ8bzk3gZnJN3PtcE5/O5/ID
+FH8fvxe5z/gL/GXBFGwC06hTuhP1gozha347RJ2CweFt8VKsZc4RLxFbBJXi2v5ieIZ8QNpqbRO
Oih9Lf1FzpYHybPkteidU5DZn183LgSahdoXkR+RibSGTiCb0Bs76XiyBtI1ia4Cv2aT7PYx/FK+
jusGaXiZ3AVp3UqWkNX8aLKz/SN+D/kQksL0bBN5WuhNAuJm9M69pBuk6MpvPfp8B3kWo2IvuERI
nnqzNurC4ssEFloiJzcnOx6LZkUywxmhYMCf7vN63C6nw26zWkxGg16nyJIo8BwlXWojfcdlNMfG
NQuxSL9+XVk+Mh4Hxl9zYFxzBg71vf6a5gx233icuu7KBK6c0unKROrKxNUrqSWjilR17ZJRG8lo
/mVNJKOVjrqpHumf1EQaMprbtPRgLf2gljYhHQ7jhoxaz7SajGY6LqO2uW/jtDW142q6dqFHEmCC
vmsXplgSxMAKbiZ9xi+Z5sGOXVHb7IvU1DZ7I0jjHB+tHT+peehN9bU16eFwA47h0LB6PKNrl+nN
qCe53zgpMun+1gSZMI6lxo+ub+bHNzRz41hZ1rxmd6Sm2b34K88P2Sup2rXXnGzmon3HT17Ttzkx
7n4wl2XHsdz4tcgNHJ6BYrnlDfXNdHlHJVgdZ6CmrLqTI7WsXuNmZDTrIr0j09bMGAfmkmH1B30J
X21kfE1DMxlaf9Cb8GqZrl2OeJb2CKP1R7re0PUGtu8R9ixN7X93X+r4O6+wvWfpid9gP3DYVQZQ
9qRIf9SzOWOi9pAIKlvBNpMryJqJFeAT/hoomjkd9enTzEFm+GizGO0/vrlp+JVqTKtJVW7cjJqD
Oq+PtWFc7wZcP26NpTt6CtdbIhlrviHowkjbn64/Mr7jiBS1fEPYSdbRV2WlmY6/km7UGINWT/NE
prH+bdT6FPmIp/aaA8gz1rA6NzuaiwYOrQ83ZzTgQCvJ6zKwleiG1h+gdF1DK21f3kpqAkeIjvC3
jcXpLkzUptfg+ch07YIDuWGk8rtk9EWr+zJZyViTsab/pDUZfTOmQZiEqLbHiclrGgrAweH14BMZ
gScmGtKvJic3NHRHOQWsHNyCy9c0oIQZHSVgrx0qSOKibl0GoldiQ+tvqm9uqklvTtQ0oBcgvq8M
rW9+BZLb0ICrCq/WFDVeMt3TUeci1LkwF+eLU6UMRxkoomHNGlbm8PpIuPmVNWvS17Dxlsq3UtL5
QKLjQCthl6Dhta20aSjuxS4STmcHIuFIGNVqYDwtgUhfkahWUvrvOVx2td64sxy1LdM4XPFf4nDl
f8Lh7v8Rh3tcrel1HK5CnXswDvf8v+Nwr+s4XP3vOZy4Wm9U8gbUNqFxuPd/icN9/hMO1/xHHK69
WtPrONwXda5lHK77v+Nwv+s43P/fc3jA1XqjkgNR2wEahwf9lzg8+D/h8JD/iMM3Xq3pdRweijrf
yDh80/8dh4ddx+Hh/57DI67WG5W8GbUdoXH4lv8Sh0f+Jxyu/4843HC1ptdxeBTq3MA4fOtVDifS
m8m1eripk9ol/3XFPPoalsNSgpHcGzjjafhrPJHJ9FYyPK+VKAWtRAApllZCToNY3nKE8PTFi8gh
JWspHud1n5JW+nxtfSuhBelHCKWv9sIkqh0g7AChx3o1HCECPYJbKW4VkepWWGwNW+Og3sK61su/
FY9936dVGHzpEOozjJ/Dje2oTzTh4KRHBJ6QHF7Ikb2KTg0f7efJyxtycXDbB0lSXZWsKuxG+Yj2
48YGF4V2BhaFxGPJFm4QI/jm2/k5dJhWXixh5x7hieh2+1CeVxB/frWw5JDayTXnSfXgtlRxdFh4
XjhVDFpA1qljufHi+8RBeiV0DqvO7kIZuqN0O3wXB92eMCdIkzDI4nW6/h6+Y5inVS5anqqj7zNf
23ttHYVXo2xOlqwWt8seyafxWDxWaikvs3NjHymou6lo/aKH++ZUuAxjehwV31fffvAT9Qv1879s
UP9wbukdG3aPvJFm/249jaLPKKlBfdyoj52UJYyKldidqI8wKM3OqkSIDlXSKV6H8+/h6rs6uPVe
22fX1MNuKy+zWuIxvjhI3UHqtMgSX/dYfl9Wi603xLrljO3xojqWlq37kIZp+C8bqOvbOycvuThH
/ejCRvVzrQ5D0E8nwFczOZSYslLaLHAjhQXCSYU3GY3lNoNBbzTIcC6UcptOp1d0MuAOqdwmioIk
cpTjablNEHgjHBDBZIALwgk8ZQ4JXBHZLAyWzUSWLGgVv5maTZsN3rRq9PsQy8XByarPrvRWtXew
5U9WdyW12tyVjISV+Z48ZYnlNeVfJwScQieMIWOos9wtu+W4HC+Pl7tL6fGz2WdXTrxv2ZTVn2Z/
JB779aBZdS/VvfoqNrOGfKG1dzTGySzBCY+7POHnF4tchmJYrNebUEdpsaDL4PWLiddYPSxVy4uQ
zItXhErLFHazl4atkHtn2BqxjqYte2mLOmgvfWE3Paz2360OoC9oz9mjnqZN5Cz42jXhIhGzfpKi
Z4yQS/STiOJNmzg59YSq5JX+HAwRK+zmLisvKy2JxSOlxU6HJO+p9adRbuYH4xrPGG/umisb5LNv
LGhx4hGQn5vp59xAbjPGfEZCTwp46hMJxkMr7X0o/KI2vs5ZzpMCNhrsqO/N9FtVz21mWA2FT0u0
+vEE44nm8no2nugkdv+kMKscG5xXeoiVUF7sjOw/c+YsACB2P/64Gdp4zEu4ZeqmmwEwcJzfxvOE
4/UMH+O9BZ73MLirq8SV+XlLLCfoGFpMI/SdLWr+FqYrmN5KtH8s+MUtJA1oy5yEe6VI+yrO0jTR
XyqbbBX8LE+FIVgXsDSe8LzXlmwj1W3VqEufRYkSkm6K0agvpouKMZfZk41Rbcum6QpSFgkpt9GZ
Te0cNl69P5tYBWzy8EfZRvu7h4whbpfVInPhjHjMWlJuC9vKrCVcJJOzOtyuYj5x97iRS9XfqurS
6dWNtHTNroX7Hltf0O85cctXB9S31E9/pv75N0dpj4v7ad/vv/oHHXaR9lDfVz/7ZPmbKR6dQAPf
Fx+GdokcUGgrLU4YBUE2CvImkejrdKxRJ95PVpLq6ou/ZHLVi5YXQ6hOvLo1tu4V/ts19oZd3/+I
/1bjdwJyGxQfIZlkV2JImdBXGCneHvhRcHFwGV3JKbnKKO/t3ru9d/uf94okk6YJfrM3LPu9AiVi
KC0t064vtYsZofnhTGP4x3KFa1amOZ52T6giM6sukmLuxTbLN23nNF1c3Wa1VRZgIGJEVtoqK63Y
kDEa2/2C1xi1xgw2czbROWQwVzBZ9NlUcWID/losGn/B2jJbNU3JciQTWiOCdLjI5nTIUhqVcAAC
OWD5z1+5p2TYpiVH6mLCYb73fJr97ZeL+j6/ekLFJB9vvpxzhNpmzxpYOvz2JevXDlx+tPG0+u0T
zy6umzyorHDkjD0aXwohPz5xKykkJxKh/sbhXSfnTOw6P2d+V2lTjA5U8vSePIeJ/67QUWoCKBFJ
OKyllh+bTIXppVmiXFpo8myK11hb6YBEmr4ifxYXysm4h49zxXVF13Cl7WJK8MCUi8nzljYL4w/j
jcaSsoJu3hjRibFANDMmET6bCLzSDezwR0LZxBf1ZFOBymBXATbBcDp4FsPmqjBaqpg03nMPeEbH
CFxpsQuyV8SUQCRTkkuDtLhIUwkpNpYwNgL5AQeh8B0kQl1fvWTM7nt43bPP77RF7f6Ya/INc7dM
bqmNiQcTP6LOT/5S16XvnB+rf/tHnLpfv796zpaFGxopfYznMioevH3ewt6Ld8x+/dUjy4YVB0IH
mn6pqkx2OWB3sB3E7UiZyOhEpo7TKyaM75dtkiRzEhVlBXiirOfmG8SveaMs8K3U/TzdZFKe1bfS
+kNiWp1Z4+A30JqQqmqmPK2VGtfAuEooBKbF06DGrTpqDZfSYisUjJV7Si2lv0qu5R7c8u67gCJX
JxeoIh3bzK+7fNsj6uOsbpT0bv8UOqOJZJCjibx+tlUhrtLY1z7SPtUudFeMJpkY9Wlm83yb3W4z
p2XY7DKxu/XuUlQsM+Ez/dhsDti6pwlCacbJgMkqV/hmkYqMzLpwqse/aTsBLdNWnURvn7t4pafZ
MNCU2Gsk1fXoew/UULYnRHVcjA8CFKYklCH6MSZ0HmxoSMgmUjo2ijc1NpjqsVSx7mZ9PQbWxzX9
HGcamscgKS4SnA4unJkVT9qWJEbs2Hq4aczygu0zuQvJx3oWdR06/TVqu6S27Vf/x0Jnbu0RfOvu
TU/2S+h4/jl1bsweVl99U33jtbe0Phzc/okQER8l6cAQn0lULvBRtxJV4t567wqykq7SyXWKPhwP
l5rNDv6kXJouxksxVnK4e4IV1lluPVelzyp059Rla4xJVt49cNjCxQUeqImO8dAGFjEGpRRyNObP
SHMRSYxlpAWzacyZlU38dqTYmKACH7KEs2nUFc8mARs2bExouoKmBgAbAfewOZ24nBHYVNDCP7Aj
kkmsFk0/p4aF0wH1XHfsoCVyw7LNB/W9xt4yo4Ua1T+eUj+9YQkddM9Plu6at/+xn4iPfrfs5m6j
1N+rl2/tmn3+3Kvqu7QQELPhRTrp+89+du+PTm7dtio1H2JdE/LehHloeKJMNHi5CkN3Y6VpgOlm
7hZhAndY1t9tajG9ZuI5HTWZu5M0QWfkTAohs8xKhe5Zs7XOorEJavQrJuAQeUg8xIZCccJOkWAy
MjVos5eVh0uFgtqv6kd2DeSfrLmwevPlC2LTI33UlleObp34Kd1KN/153/MIO4Ccfwjdth22ihsI
9JuJulvoSN2otAb7JDpZd3vadPuCqK6/5S5vY2Ru9M743YV3F63yrsxYGV+Vv6pwi9dUpxQpUTMX
LTKUWq1dxNKg6C7tYuIqAPasOGyuyJlVoFSkI/28o6KgpK44Jf7aNPCDvmtLDdmOPi7Nzfdn2Fy8
ydXVkU2MeeZsqrcpEPMANkKIy6bOfHc2MeViI/vFbMpnYHNV02laLtXHHeqN9aPtmjSBLV2CIZBS
cBggGAqRzCwcK+eeXNF0373zNk1Z9dSe5fc8sXG7+nzujRfe/9UfamJDG4pvUy+cUX9992I+sXz0
0BUrRk2em+yxcsX9D66/d/YT3I68oU07zn/80IrhBV1zSiftOKZ+9+VHPz6C0AKO9G//SLBi/mBj
ZG8i3yvmidmuflK9OE1c7V3l2+LT9VXkcDxeqtd7wqUWUShNP+kxyVyVHCx0tNKbEwYTyUm/J6vC
dGWgYHRYvklWLkmNFk2XXD9QQjGvz2CnvC3KxTLTMEoyrBglvBcqJGZANmLGQAnZsaE+qI+oEaOF
TREdlktqnNCU9rCbKQZKaYmtOMPugv0PxRHDAuMPo4RalNvLa+95IVZ1YMrbf/3zBVq5oPeN96kn
3znLFR147K5l21ZtpKM2VgY/pP1vG0y5N1+l2er5bb9Xv3tTfe7TXTT2k+ZHtx3YsPYpxqsvoXxb
hLDmYxYlfGKuzOcSTAI6mI4inSQQeHaTwgvvThmPEP8rHtNgTJkwcJiCB315Bn9C+GxyvWZLolzY
yq0oNw2eUGUiQCJpsJbtuRZJ0TOPSC6x6SdZoEYdrGjmPFSh7CtmM5w9yz9bzhhq2qP6ppspnfl+
qOTe998/YxqaWyTKxrNv3N6v0S3ehKdT4m9vE/aByxKZkUiM5KfyK2HAZsCK5bgMG9anJKQFXsiA
yyPxkgCrVhQplUQ9T6jAibC5FYl4ZWVV+LbntXZXWb51V0EDkJ7V1cyZKRAGe1Za8iwr87DFP3Nc
7NSpo07qFx66XMO/dGkWN5a+0aJuVje10DfB59Hkc2EWX6bxOZ5w0gzySzkDEUA+ncyBxaPDzD2B
fY5HVTHzPplEoU7MoSBh1qU2wX6pjS/bvVsdvnfv9W28I9G7ntTz0/hVCIhCyzietY8XWPvg0KHF
lHS0kqLBlLVSIj6FCiLPXdtKN3s2WtkTeq6jlSstnutbqaOl+KfCvkuz+KOXa4WH6AtqeQudQae3
qGVMnuDkCm7xNPNfyPZEXbatn73ePtk03yRONy4ycjElzWJyphl0HqfNZBAyLCOZn5LxRnqWRG1p
hZYQncTzugxPhc6XGSrM8IYz3w1PvAIrDLF8O1gzY9suMgubTejnUz6mZtHatDnL5w0KSiDqF0M3
EJ/suYEGhfQbqFfBBiOOjbeUVRaF1BKbppYk2UydkZKy641b2nbypLr/4vuvtY1cNq7yYM2dQ7Nc
2fNXPp3IEg+ePi2covIX+2csaxpzz9IH9s+5MTN6Q98JD95dey9ajjg8sSf8KI7ooefPJob2o/V0
GkUHbRa26J/Rt+pa9VI2/ClZkiin6HTY6Iks0rUUUunQ66NwzKlDFKOwzKjBIPI6PXxzauAoHLGg
rLTShoQOS4OSTs+LyO1O2EzM2xUfpY/qvUbTzvDasZAm75CLnsHJpFcbsn1rPKTaDccNbjoz26qZ
savxrbJAs4IGYgVDeCW9WTjRwFz0JRZ2gMcB/kRDXse1Ky1VVTKICTxz1Q3UDu+PD/MRyq/7ddvy
Lzjn2Y3Jo4+9xT3IjWKGHj/x+z60Ve2neZWIJxQFpPSIBcgm9yYqRplGWWdwM0wzrIu5BWG5v6mf
lQsooTQhZAcP40rQzRmCcUUoTJ+eVhjx5eqc0WyXNye3ld52KNw4JTVg0B5NMNgEl6xmajn5gyFv
8/hExRuVYrJHyKOiT8mDFKSEAC2gmhUOuyRsvSbJhzPYJAV1o01WspRDuRNL+/5ofu971UfovsND
Ch8YtESd/yq3AF584sacwXMqJjYsVz9PrueHRsofeLDIr1YmR83oc9uO7qHkJdG+9dYF9zcUxPPK
xj2z7s5nIRWj2s+Kc8SvSACSciDRI13cTDeJfAjW5b10pbjaLg5X+BUBq9UpdQ/wxu5OXZALBr18
IdfDUmj1ZegKvd5Qxs7wjBQDBrd1NB8tx8iFM40E080wZbsTvztqj5mj6TGDS1dETA5LEbVZ0yyy
HzmR8EWUAt7Re4xFJM2GjeKTiuDaYKPNTinTNrVlB+6BO6NQNyAyzXrD8CkvKy+GEaR520DMwhEh
SEusx8OvHfxY/eavX396Z8/gcd/D+9UP28lzXz37Iq3LFr9Szx5dt0t9W31NVdWfPdPw0IVHjm37
JX2W1p7+rWbjYmISJ0JOTIjXmJoIrbRusnFFiiGYxpGgW1EK7T6fKWr2en0fhBtXa0IAVIPpBiYA
0JtoeIy6rFFnTJJFWZB5mZNFSW9R0FoXNjqboYjKDthfmkLIZe2KspYw39bCQRo0EbA6ZA5df3ry
DfMG9PClffxX9bHXueG04OmN9dvUFcn9e5zxWQ33D6+jVpp/aYto//C4euYPx1RExaKPgcUIbWiD
AdEuQxJZclAQDHwQEIpOCeoNipEzGjkiTed66HxmXokSr8ncSg2HwhuvNEgT6ovnMPBYr2LIVldp
sp3CfTSsCt4F3S8UXF7P511+n7/70nEO+GqL2nuPat6PR+NPw4SEPcjoMAt7WC10HbWQbqc+g/Zk
vaGVjsSTP+1gpfZk5t/90wMj+/lLl9/iziQLTmoP2p+cxNo6sf1jFj8CHCNCziR6pUsr6HKOD9CQ
uIKu9r+QISaUNMHp4i0zXUtdXJrLahJWZFqsQbvN5pS7Z/JOxdTdp4twkQgftLXSgQkLLxTyPSxR
uy+qLwx6s6KtdOqh8IzZqQp2yHtSc9lTIq/JPHikHaoc06HaNEnokh4mRn80A8CSMV0PCQ9jIxGh
CEinKBgCpiKiC8lFVOSwYTYZfJcO7wUzBeQdeBLDhFMCHy7KsocBFkbiEPoIg5iY0Mf585s/KXwt
67fPvqX+/jwVTlKRV0u45U3dJg+57w310ku/fP1lmh8Wvxx6p/qbnevVX6ln1O/Vw7+j3FOX/3xs
Vt6AZ96jc+mcs6c5rc92Qv4LNNmpToQVXRB2i0A5vawIclQSfSaqjxoAaBpNO8KNjCcWmA0pLch2
GjpXWQBuMPMMQD7Dn1Djnae4y6dOJYVTAM93crd934fbn2SBaRQRMoQ+jOfxxI0197wXcYiQ/DxE
rrDlBQ4xbigncuoU7gTAR0mk/WN+Jq63k95AESSvNNWwWNrMiQsFqtMJNs70sKCzRonPqY/KgLpb
6U2Hwmuv6zyG+UGwNTcKihYGbk8KbBS+M0agtZifWT5F/e1Tfzh6+5zHCoOv0RdenPrSoa+mT1+4
aGafF/l3WZ1hZyD6h42vFxOLJTEqxpV+cr28QFzFb+FbET70O9mwi98Fc07MVnJ0u3XfcSKUgSLq
+Pc4ZgcpiqzjuGyejwLt1klsssUhUUDYDYu6kSWdInKCHtg3OC8pt0t3SRdgLV7lvgnKh02yKd57
h1jOj8EEW4VhWqWhbO5KZeXg/DwRiAibTgUL8x1esyhVCvqFzJ0zhs4ZA7bSsA44vmyNbD/OvUXt
yUe4eWoyqf7xOHqphHsr2Xx5PffFFwzA0dosDESbRVKYsAOR5YKCqPA+mXJRgMSS3EqHY1r8oVKo
E2oEkcDyBpMEZ3j7Se7C5ZvQjX/bj/IwH0turR/fTDTU0IEwKKiOd1Ev/yEV7dTPOwzpxpG0nn+P
fsK/Z/jEqAc/TLXcCk64idvMcTn6bFOFvsJUx43kGjk5Osmk53gbGGYw2nhJ0VY+GHS9LWHSh3iD
lDRSLmkKYYhve8FOvA4mvDD9UcNz3ouVlfj3nGOTeWrBh9kq4OTAYYsOmIytdE8L1iaYqtpzkOP4
leLg/MVJYcmJlWJqD56OmTuHzh0zx844CpEvKSsFMA2hclojm2mA7qJPUN8xQR3zmjpKfFk8dikm
nP2+Dz+x6+kFl3KED7uWfVZy+RHwWbNhxVzwRQdLpTHhKKcV8PQBh8dpHa2HGAEzY41ya7gZA804
BW4Nr9dTSUGv4NzzouAzMjttW0KvI16DsWOkXjdQmU2VUu5oaCVbIclbuQSLIAwzhFnFxi3F//Y/
cueP/TqZ9jLXHZUeJez6vo/w1KVbUT+GJwxtf1+8AN2bBm/XT9YkuqxEEOdJ+ir3unJKL/VRnN3T
+PTuss7P+f0GWyHvC3oKDd5A8KNO5sNV40FTmkXEx5D4Dhy+iOHwRfCKPEUMhy9iOHwRw+GLgMOn
FwGHx0azF9iG/QELuxaGZzAPsZVaCFOiDluYF7YdffjpE+pGdd/xfRteRohl+h/Vv/7xnPqbv1On
Wfzq+1fV0+rhs+3kNx/RATT3PWr5/nG66BusRlSpJ9W3L6oHxLEdc+w/wAc96jc+UTrdON22yLjY
JvRz1DumORY7BFkJWi0WPTWnsZlXr3CSzSjoHI5CwedK02HSdbr+xaSbZM5Pas61gC1QpBreY9cw
WgnWQQSQBnZhALr7uY0n/vLB52rRSb5pYe871Xl07YqnxWOfvf5se3K9cKR7SOXnPshkamj7/Vo/
OYFJnEvcPp2f4VzEL7dvSj+ZLg3wN6SP8k9yzncu9B/2vu5TKhRPOpfu9VKnL93n8xHqpcQbtCHl
9SEQ2ePk8M4ItQadhBNN7IAAyK+7iY93p6IuCBsxJ6tQ583O6dzJpLoY5iFrniZ7qWmSKap8bWmO
wpWtyqvC9kQelJSGhYZiksUQS4vK0UxjVhHJMAeLaExCKqIPF1Hgf0UU8CPe4ECvXwUzGOQXlePA
MVIzpI1Z1DCnJFkoY4t6ZVdkwULC4qeTvhz2sznqnuN7NUlYfvThSOlSdeQd2TsnvXLrDRCLP6t/
gKPBCYv2dS37zVnaLyUQEJF1972+1Gf1Lr1r4zTKNWrScQZG5d/VX2BogOctmCMWauM4TjYkbLKp
P+0nNtB6cbo4ybFQVFxHEYjrJenUn+gdCWfExtnm2OY7eFsw5PA7+XDQ5RBitqxokOh06XLQwMX8
6UpG1BmKuvjCtOnpvhwlFo3rwecPwhuvd0YuAr14D+YopgOGOUOEKjscVeZxjQH3NcyAsiUBTZb4
cBHzOdgCQIjBQG4nTI4CyjBTyBtft/aJuT2nqL6T3O7dM9+eOeGWkaLMG2z5F/VGwShPqlys9jjJ
+2c//EhlEMuBOwvHJpftLo7MbXptRE5fR9hedcs3DxamJ9eAJ+Pa3xe+hb4oQKyqmhibkxaPxGJl
5tJwXWxCbLF5QZbudsVjdke5BvM0855MXm/unpmVqecFv2eFo6Agz9/dwQvd83TdOL1ZsWZlhrK7
dbN6ou7+SjTbVxSKWvuTaIG3sGhHeEaHJQvs7AcHxYb1AkbXOCpMHPOTxWPmaJpncHa+NUQULsbF
ukYlrAXyXUge6Zqv7cRc+G8BeyiPpDs9edTroV2FPKKLG/Jo1EDzkZZzsAna/DjpwkbTShaLZtQx
vfSDYcdWZjS4ja3DxGMaq0tLshhSn0KqJSfWC7W+cDoEJsfllAblkonfzx59cOCgx0++etNagPa/
o32OphXeerZ566gep3+18aa16iN/VP+8bRvPDaZnlwx5OKPXjoXFRdGuXUpHH/6F+utvGqvv3DDh
jqKMbgWZPaaeuPjO2vv/LBjY3B6GvwD7CpEeJQkflYJE5gSFgXDkEsdHReGS5FWYU8+gsmtXsLX5
XYOKmJVXKpxSrW+oVvHY/u//JprhhLBxsAf2ObMnncRFqhIRtxgXKyy8Hsqju0Xn4l0uhy5q9Hlo
1OF1e3aEN15nql2ZGKpgrFFtDTVlo6XWWPmYF+bLvKqGd5O3Fr7Rf4W6Vl27vD/XRzx2ed6OGTv2
jX2MX3v5pPrXh9Vvqf5hmsZXoq1YhxLLUB+JPJCoeZDuoFyCjqCci9KF4nnKTRWmiasE3pvNRRmO
RRgKIsI+5yWgH6KgKOCKwPGPioQ+KnnldeAKzC8GdVRW4j8FdzBbDHAHsHpmhTELDIZEAgYIwDAs
oFJOElciHOGEtmFwBhkzZ85cHccWs6kFxsLOXycvvJv8PabcgPDl92gQ4yUlUbyjOQcZI70lsVHR
0YXyIt1Cw0q6QhDr6ECuhu8nDFZ661crK/WvcyexBPO6wVhvmCpPM6zmVvAr5NWGn3Kb+I3yVsMz
3C7+KXmPIQ1mp14xeBWXfqQsGRRBz/XKrs0Wo1iVA1BsNOgEyhvgrEhGkQAoMvCyYmYQqiitSCi8
cFHP6S42GQhdYfSarmOGL8UQtrvKFFhV4AqWgcGWtpX5beBKiw6hHlhI25pIA1bIARYUJFmHN2Bg
v2xN6FkwCA4To2HlEovCjFlRmy1WKpplm8oMvGnRIeCMsH22voDiBBSiFahDEIlWHmM5SlAsr2hk
ERcnPcoJoKhILFFOoAfmjhkzBzacXUeL8U8jOvREEojqoI/oIOo8qy49o+5T955Rm9AlNwt7GcES
On6pF3qDIuoe72AiZSAvJWZn0zIORik/UpjKTxUauYXKKnSQIW4o58rFCmWaCGEClsYsf1HBuz4y
RAwegQ7JqE1v0GtRMFEbIQZOVAxoviyxQHygbUTRA7RlR9H3ss5n4inwtlZqPBRmrGeQ22DPCcsQ
77fYpewIZsdWAVdN8TwPHGChE9rOcs0uZfeF0WzWfNZ46vsLZ1bt39EFdF6baufEv6vzuL/CJ/gV
V5QsSaZxozG2Wbvr0G4F1uoDidxVAnVkCxg3HI9xg24TFU6RASti6KB1PPwzYoDw8AIiiRM6ieNE
KUoVuA7keeLVXxEfqJhKDyatngUWWOYafog5y8OcbW1QVeYj/uOHcXUYQUK8gh4WICIntA0bUnat
I6GX7LkXMKJ2/T75/skp8Gt6cccvr082c0N59mYaJU3qTI7AbJVJKeJ3/MQi+GVbagGiHoCozNYg
/hK+o/iqt3XxyirEYA3vwTIrW4QIN9GmDz6AfJxc/91b61FugTqT7tfK7ZXIQGAcx/tFwUI6Cpcy
OLytzGtlV6XWN6qYar0SGpRkoAvFXKU5TxE4/eGC99+nTWpTO17XXf+PXVrdSTsR7myfDEs87Xna
F5JBgB6QAsBv1tKwE6fI5MnMTh+G9W32Fksa3k+qIp8lKnK7Ub0F/pU/XtzPMl03wyJXKjajjk8v
krN0AYsx0COPy8/pcbgH16MoN2qzyKLij2e6/a10DVR4ICTHA/kGLlBqqJKrqvwOOSd3d5avV3qO
f0BavMLbs9dLdDMmlSN0E9HYNrhjGj6XPHFFo8MUBKLEBJMZJPlt+W3MIISdok3E2WXlzkxYnlFa
lhYmniBgFFeGI0zDmaScCxNfwB3G2gQ2muWXmlixjMWclyzNj+9JzVQLC3FeFzPSC7EPMHWszNnH
I9haF8Lt2I4tE5bbqXnukNsaNoWnFc2cUDictvRyGu9b/JMeYf1u8e9PHGuc744ag9bcLrExuS5d
+a/u3njsxc1r3h7Vpf+uh5x+yWzyF0yldyhdPF1HDx+UO/wX2/r125Lc7M/k+eVGqXck0W/G86s2
Pmmn59i82Nj+uRAVjxMrcNjZifxd8tP+D/18ppIWRDcSd0CUrfpgwGBwxBVfhi/fkk9ziBXQ68rw
sTFXZPHcuQ7ksY1Br1bE1Wjc89hckt4lOWLUpsfGKbtj1K4LxsAsWMmMTXDIGStsVrYaCg44I1lX
l/gQRNC4v8eT417/7tuzi0cUVe7ipjz00E/uOhKrOy4eT/5x8E1qm3pRVZt7RAavXnLh5Wc+f+HM
5rEHII8cwZtb/GlhCPHBH3w6UfC0l27x7Fb2ePgBinWbg+cdUsAnmwLw7OX0dLclbqMIjbH6Avq4
2+sPtFL5UHjukg6JQcuqBmO1mOGO1xhsWgNLMCijRqc+Rsx2C1rJMGUvcsCUwxqmbHCZYsCUsdF5
pBjDlMP/AlPW5IW4UoiyDJtLk4piJg4c/MVimfvgS/d+y9ylzw7oturh2fd59wf/cvSd76ntPb8w
pPnDifftnrlj56erF7z/Gi0+j9fOumOKJBXtZ/k29KuBBMiCRFG5uc480vy08Ey6GFUcXFoA646B
gGzXcwG3Qcy351tyrDZfyBDH0lFoZXhu72ubnzwHJPT6vvV5/Do9wmk9BrTNjw3xcjGiT1diaKDW
u2iVjTWkY8kWrrCbefOlrFmELex++/DOJTt3LV71DF0zvFvPfY9XPzvrkPr915/T2y58eOrNV0+/
wZWXBAdyge97bZxYT7t+/wc6EjqkX/tZwQcd4sdbk1FqTCzarPzU93SIF81cmuhwmm1pTkfCmHAo
OT460PACf5L+gj+Z/pHyse6D0EeRC+4LEcNJ60kbN1oRw1lpW12BrEpJll3hgF/WB1yGqLzZ/7T/
MMaAEHWlYQXNqzfKVsSUBeKiL56VL8e93lj8vfCulPADtdFE/71kavWNLSYVjLkqJ1CeGhqrSUtf
EoEZgNcMKYJMQwBNbRa7xWERJGM0Mz0rRjJIIEaDAZ1bjhGD0xxDOEbEF8YhERvFA7lCRBoYzWx4
LbZE0ze5ebn3AEUjc7AWxXwmlzOciqwqhwDB2ZQ0zJYUa24U4q4o1/JBRZnNcvlr8cHNPxnRzXFA
vrFw2KIbhr0OD9PzWxoyZA/Yd/dukUaEuttvvumOAY8/8dqYsroeD+UP9VswIWOxjvZWY/P73nto
Df0Uww1zjB+Dzi2+g2iOwYk8OSDpAzxNc1S6TJJN78VEazZZc9w22ZZmDpk582WH1+O9HJ66NCVi
yTGVJ5hzaLmyqK6BddrKt41FDcENzIfISE62yo5faXHp85HqFmuW2+81DMs42HJw40axd8lojnuS
ozc/t+7yJH77ut2oF096qj34C5CVEOmKt3MPJwaXOfor/XX1SoNulfGZ9N2BZ+K78o6kG2BBujJz
zCf0mZhSBCkn4NXbAvq0fDk/X/Tz+a78rjmir5vRHDf1isX93oJu1wyQi22VTAKS577BvNGhIaAF
UyC81u9dItm+oMGaFbXEIsFYjGT7sLEazIgLMBtN0UBmjMbTc6AnjACIOiaSDh9Nm0vYyCktZsgB
IOJ4KoquvEybLbKsUA8EIUUdWgN+HOXuHltcuqtqtnpq35/Mh03xnve9nYjxZVuWPKdeovKLtObJ
H7/cN7r+7uM3dlHPCL17RfqsvFz0VuPZbU/1i1c9fMtnw4b+HUChiearO185eNvW54/tn7iMY1+7
oHjDmGg6xYVYoi4YNQpilJW4ELfPl+crit3E2RHAaw1IstOoN+Xo4U05c4gL/lQrlQ6FJ6R0Cuve
jumiSpstKimLwtEmAy1MjE2MQC7h9aPTrZFlLYnikff+fnjXI8HClbNfaIHy//SmcOUTDY8mb+Ke
aCyv3/pB8nUmhxyrH+0BO5C9K1CW8MtfCai0xGtxHJDbHJlnVtSeH2pyIll14qrYadH1DORnARbL
DuNPyL30gXhMizlrP6sOpRVa2VYylr2HcBQPY6sEI/FGAsWbBjJ7E4G9cXD6yhsHHHvBgLvmjQMz
O2CmP7v6CoKVHbBqBwiHlw+I9vIBhYzTXhRrAKzTYRPEaUVLi/r4osKWWHWzKRAS2k5/VyJERgsv
XCqf330CzFzYj+gbhgMaMONNauBod4V6EasuuaWR4lRxkbRQXike4U/xZxERnQL+eW4ZtwGDhucq
sdSOF/6hlmba0Ksa+C+msH94yAj7lID+6wH7I1oyhxhg7B8MTzhCXSmrinVoFcP+O6B/LW6CwqJi
xjHcy59rYe9jsAjwSgfyD0dzDpwcAP+ajQ/gv2kf/dV5dQo9cF49uHkfHOe99KQ6KzmB869R2Zca
KFmNDYsn4ElOAlLWEdfN5cB4FcRruvSH4JyUybq6pSUVko0yIB9SVKgjMbI80QPR/2Ypza24ze60
uBKHiu/nvcUw1WCMRPW+QMSr5wR3NBxwB0xwQaV0f5S367OhzKw5CI+iB305MBRoAnNgfhSD1xvP
bqWma4X8nOUiQjQ6pAv+D0CKNg12ZAbmFYl3dki8+4pFCMHvkPtrRsDBREnDnKYhXbKqHp/80ZDc
o7cPnvHTw76c2VOebhEKttyY1bM6q+8tw7ePWJcs5y7cPnTdruRD3NGZRQMffZuNDG1c8G3Qg15Y
RGMThYelkxInSA4p7miU5smiw8g5PBZYekTyGPQ+GRCrMUfn89N8T46XeNNhbl83fFNTXkrboV1t
LPw11SDm7jivaQobw5iDEFkCDH/Z3kF7pp0b2uVwoNvSRM6Aiq7pLfRp1H/ssMdGPs7G8oSqSSZX
79I505Nvo7Lo6R6IgQ7DjjNiDdxLHkwUb1E2WX7qekrYreyyPONqVV5XPhS+Mv/eYeyuSAGPbAzY
DF7Z63Vy8TRfui7uBCzcSnWw5jpm6xQId1VPp9QzcQsxg12HmdXKxajsRko0IaV3GGMY2dgoLhhv
vBkbbe5lG4buZ9k04BJaikX7IZATQWokZbD9Znm3QS8+tWnTE/gwxGX175+pl6ntd9I8mrZr09gN
lw/uPcefVf8E8zWpPkfzLsNJSDCbrVG9WYii6WasIs9LdHlGedrNZSsZfqtZCjjlNMkc8BsyzVzc
48vSwxIP52SmeSNZ/9IS18w1Ft+utdHvSieiLybESDoaJrqwoV5zjPBurU1as5g9zqzvVJ8x4K8Y
y5GafOJlfKaHYKBbI9wvno72ffFobRRbNX9/WeLWu15QD8/bumhYtx4ti959p2n0gaOTtt49chd/
YF3/7CqEqCbVxzfdVhrsn/yMyWKVejNksQ5tzCCLE8UVnn6ees9u+rS42y9lKzY3bwhkyHaJD/gM
LrMMw9SV43T4ENUfQBzUNfOuZpdrhmlHUztamh4ymqB0Y1w62mcMYUP8PEynoKHDMmXxuDBNWYxy
CvZk00zHHBuxatYpTLPif8RrD75UF8/r3zr/afrArUX5e5/v+tiCverfkqfo0rFPN4/ffP+Yx958
j+vVJ6vvxu+B1Pa7mRrx1QdKB1zRV9zDaKeV3JiIxfmYqZyvEwSzYuHMOqvOGFfYcLPqFZ+dMtub
eG32VloLBZIyi9h6oLZ0WT24+kQSKEoqXjU1T2pD7KpdZI2s3ut88nbRE7CkW1Y9DJVwpGwbx7/M
c/vnJrcwniPeln9BGAgbqIDmJx6o0G0RN9l+6tji3JIrZWdF42XhvuG6rLr4LVkj41OypsYWGReZ
FpkbI/Oy5kXnxXYFd3ex8zBJxa5Cvh0r2uluv8fZ1ZGfnWaYDvS/LMpFM016Ic/u+YU/YJeFQP7W
PEOBrDNbOJkUhAt8IY/LE3f3yo7J8WxfoTkUt/Qi8Xxvt8KDV+1oFs2m2VGVFqRYcysLsO1AyZmX
znz0FDw+iHblYk7A4mFzKEx0MTlMgYyHCeI2wzRgw7F0hydMM9IywyScaTYpcX2YxqI6PZDyMJFy
sAla/WGGjqc891T0uhbyoA2FKwOcrUFq+Pi18DhMUrdL/md8PDVRf61Ea3ZP2tIzfucDq2+Y98mR
v93eh9sjxnr9dMr02uwhC473nv7x51+flOlhOnRUt5Ejb63NggeSmdv/ni0vrRs1rWdR3ZBE31yv
PVDQpXbDA6c/3sF9h3nL3f41pxNHQQsOe96Ur3/FjHduqhNRwVXp5iWz3upjYBaVcojT7EzjQ8C9
LrsQGQQbu8OL7WRjF7DJCJGmluQ5bZJkljUb71ewiFgpM7N3v7B3b8xZaAo6Qn3iS0c99JA4Sn1/
fbK2wo6FqHU65Z6p3GvrNburqf1L/nPoLTdqODbRvdXxuoPT2RWH1+51ZEsL+A9hVBDRrCeSSS9C
R3tkjweucb4+x2jw+WgOq+w7V6wyLZSLiT+6vyOwBQtHV+aX69D3SLnm3yC22hqlFb5u971UE23Z
w0VKpq7/anhXFhaUrBxWMm73qEc486Uzj/bMHfHTYau5j3zMnsCCA/8HoYDALkzk96avAdydSqZx
0/ip0kphlfg02c0p+LoNVysMEFcIq8WTwuui0j/7zmy2oo0pRXNfABy3ts9ugUOXASzxvsM8P9MG
3BTL/fclghKsKTxJBGxKO5B7mFh6htzz+7kXKbNWlx2i+yVvKkbxN7/piFL8AbZHs22VMswoy5Bz
g+XULg8wcyLK5WjLAjnXLAtcKRyxbPuxLHC13H+1ICDKljz8A6CE64hwAQ1spp/SIM17Tb3jFXU+
Iqq28NMunQGHKL4xRMSdSBlpRmJpnbBHh+6nfeX+hpX8GmW5/g3uBP8L+ZTyC/0pg2GKPEOZrJ9u
aJQXKY36RYbl8hqDnl3L1fELyEKRH5ntygZCIPSgPYQH6AOCdC20jxACQPv6Dmh/G5D9E0D2TwDY
3wZgn/EchubVVY5Oax1XYP0xjENGEbyR8ZUiG1YPRCzn4v8anP/+hJ0hw8C0RXbhVaz//oSZYf0G
I5qt3ZpaOrEsOeEBYp16e1NLMJD36hEG9M6ZMwdWbTpXnM6AewNc5Q9/deaNdz5pUU8dPfvuUfVN
sLSFH3T5CF936Qzf8/KrYGiHHH6BpCH1dvMV36Hj5eSfX3UVeOYq8PSHAxI7ILHXlzveZ9axAzp2
4EXofAnmjK3yRXyR6kpK6UixSKZ06ga6zgD24O+//e4TdTNddF79VlXP0UVCgbqSLhKTl5Kf0IfV
H3FY7GFziFPtr/nSzBJ7I/GjNc5Vnqc9PPMvKmz9bPW2qfICfoG81rGFbBa3ODe7Nrt3k90uSz8y
0FnnPuUUasRfiNxKcRfZxeZ6t5iVLXqcbhf8M6fRkBZQzMxwc6VjcDDZdTs9+40PuGC/vZcaaWxN
4Zznug5PqQcseBXhfUy2vMDmSLbAZXNikc810+Z2exDSzgahB4sNrAvZTsEevVXYbQ5b76LFEuKc
OE15a6+klZXjbUX0IM+HT8bum9B7e9P2WE6wINdSVGARe5nVeW9hcVoomKo+pP7pOXVKi6Q8aZLC
HmVDljAEQ+Zexius7fEt0IcsdgaR6eVSPzKS1NOREjQMnSotEHXQClIO0w4sXgagEOUq4WUhFroS
S056Wewl+4z8ABY0c/Cq8aqZ3VpIIhYltJdwtNgFLXJZi5mhY8op4vKclMVElnB3JVv4XsnV3JrL
TfTtdTzZuT6JUdwfdjXwGn6hhtekAxsZnyhL/8pLfsBtAgBuQlZ9GH2RHszxhP4JvskIvxOe2oEQ
Xp1aPgCG0+HtsMUeFnEFEKe6jRZ2+99wnCjeBZbhcP8TnsPZW/D3z6hO6K23Tl76QJNH1oZ5aANr
TX2ikAPuYHEFTNQvVXp1EhH1QVSf5FCf15+jk6xSmi/k43yXZYT9/KvKX3HUUPUrNUfFw8ACaApz
0t7eSUFRshSAZRzh57W0JL8G+rT+Lk/cCzBqkDct5WwCgHp5wZ28sJOjXbyVy9exca79rbn385tu
S6v6hljxghX+3u7NAOvUHghDD6yqfoWs7sr1bC/lqDn45i39x+TLbYaHrp7R7sNmhGgjvblKiN2H
ZBhdSbZze8g6UA0fIEOEZ8lonNuD/M3Y72fXCXeSBOhEx74Q+xJQb9Bg0MCOdH9c+yUjlOFn5Wj7
O8l28RYSBG3GmtIo0FNI7xe+JPulSjIR+Z2455RASATHt6Os7dIe7drtOD+UXavtT5IWpMfhvjDu
2YN0ifwTEsU+lxHKaAIV4H5W32GgRpTZA/sKUD+c82PfE7SMnmQEVBjfIUN6NZ63jB0HsesbQVVo
/2qcZ3xyI9+EtAHPtbE9yAkqAfkZgaf98JtNHiZn8V25DfR1+j3n4Sq40dwb3F/4u4VsoVHUizvE
P0jb5SJ5rLxdPq+YlVHKp7ppuj/p79Z/bsg0jDBcNpYYBxnXmRRTN9NLZpv5QfP5tB2WXMu31izr
HdY3bJvsNvs8+w77O/bzjmanz7ndpbjecQfdv4CtXOPZ4BW8Me/jXtXX6LuQPjr9cf+9/ncCXQLH
g7ODJ0KjQnsyjBmTUFMmVyPIJoyC24F5ccSC3xiszl/QB6D52Vk2e6ekT8I5MmLU0JGDb8nrN/mO
xsnzpk8cjytYvC3+sH6HRbp/8TcCx/BZCugyFsdtgueWhpKsKNeOmDMWT8HsPoYtsOg7Fs8fIhkw
xzMZQg+sJY73HHKwRptHumg4LIu6KUTceTH0ZMc3I/F9ve7ammAvkiC9SQ2pJX21bwv2JwO0LwgO
xtf3btS+cjgMXy4cge8J3sJUKmkgo/A9wNFo8yvs+3YMlwMoJ1J8giWP/gzJXnhIDioFXUtuzfsZ
PYrirz/yEh597RHyM3zpYDDpiW9ZZl+97TAZh+ezI+kdBeFbP7jm2qKPdCqavEiPoRNG5WF+Tn3w
qpX0B1hYDSoF5eXd4IHI7iIPgnaAeDKd3k8WgVaDfgoSrqaeQe4Ivf+goCRepIuIDy92G4TQCIc3
5NEbQu8AoWl5NPSx58ujiOUykS+o96CJ6G7Q0x30MTKJhOhTWCxZDLHOplsP5dwRGodTz5DZoCYQ
r20pfeZgsCj0Mu1CoogOCdEYCQr0hdDvCruGvips5ejB0PF4q4Ddz4PIJdJCrwQeDf0sMDX0Mmhv
6tSeHFzxQuiZwB2h9UFEPxwMPcxwsoOhh1K7+QHc+kJoZs6m0KRC7fygTa3c3oOhSpy/JWEIlVWE
Q6WBc6GCeKtCke8aGBTKLfxlKAs34rIMFBpNWEP+wPpQd5wKBmrj3UFH6R66jeTSbQejA0IvIonm
HuqfU7Gpld51qF92IaLnFyfK+mVvyukXj+YMCkVz+sbjSN/yurxMvlW+ASM5D99LhC8pp8sOxaZY
MKaNil4BGtpKnz1YHZKO0r2kGmzZewiRrjDxn8NB4Sjdpx3cd1gREGVAFEdr+28Qc0cJUMK9LRhx
FCbd3hckLSW10n2HUof2JULQNhQfrmFbCwYhIkcgWxirHFU4yH0z/UmrRJa7Gqs91bZe1sq+Nf/b
Zpx25spW817/9cZDA82bBuIDaXsCDfjKHBLtgYYrl2I55v/zN28+LpjcO48Z0ocaZ8+Yon01L1I7
eVykdlzz/Y34imHThIyMAzNmsxPsc23jJkycxvbjJzfPjkyuaZ4Rqck40Kjd1+n0FHa6MVJzgEyp
HVF/YEpics3BxkRjbQRfDzw0offcMdc9a/XVZ83t/S+e1ZsVNpc9a4J2X6dnjWGnJ7BnjWHPGsOe
NSExQXsWY0Ht9OG975wH6cSX9fBlu+zhzf1vGlWPD0g21LTSXexze/MJ+X8r1OMSCmVuZHN0cmVh
bQplbmRvYmoKNDY5IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL1FI
RkJLTytIZWx2ZXRpY2EgL0ZsYWdzIDQgL0ZvbnRCQm94IFstOTUxIC00ODEgMTQ0NSAxMTIyXQov
SXRhbGljQW5nbGUgMCAvQXNjZW50IDc3MCAvRGVzY2VudCAtMjMwIC9DYXBIZWlnaHQgNzE3IC9T
dGVtViAwIC9YSGVpZ2h0CjUyMyAvQXZnV2lkdGggLTQ0MSAvTWF4V2lkdGggMTUwMCAvRm9udEZp
bGUyIDQ3MSAwIFIgPj4KZW5kb2JqCjQ3MCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9M
ZW5ndGggMjIyPj5zdHJlYW0KeAFdkL1uxCAQhHueYstLcQJfjZCii05ykR/FyQNgWFtI8YLWuPDb
B4hzkVJswcx8MKy89k89hQzyjaMbMMMUyDOucWOHMOIcSHQX8MHl49Q0t9gkZIGHfc249DRF0FoA
yPeCrJl3OD36OOJD1V7ZIwea4fR5HZoybCl94YKUQQljwONUrnu26cUuCLKh594XP+T9XKi/xMee
EEqjQnQ/lVz0uCbrkC3NKLRSRt9uRiD5f9YBjNORvHRG11FK+Zb/dSpav3iv5Dbm0qbtoRWtBQLh
fVUppvpgm299CnBECmVuZHN0cmVhbQplbmRvYmoKNDcxIDAgb2JqCjw8IC9MZW5ndGgxIDUyNzYg
L0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDI4NTY+PnN0cmVhbQp4Ab1Ya3AUVRY+p7vnkQRk
giCThKFnHCbvCEHB8BCGYSYkJEAgwM7w0JkkE5NIJIUxK1hgygVXBqRwWVDBUtmHC0SkM2GxhwhE
FkutXRW1dFfXKmV91paU+5AtVzS9X3eSMaFWKj8o+9bte1733HO/e7qnzxAT0UhqJ5GqVkZa6okp
F5L30XNrmyMtZKWZRCyBt9e2tTofzik7An48kRirb7m9+XPpkbeIpINEqY7b126ov+/b1ReJrnkZ
9rsaopE6IfFMN9GoIPhpDRCkXm/JBL8L/MSG5tZ7LBXkA38MvHXtutoIlaHRqOfBm5sj97RYo2nF
4M+Cd94ZaY5WNLZtBv8x+Otb1t3VqjVSlMhmBZ/dsj7a0nEwOw5+MmJqwl4GLhuI8Vr/pQsH02C5
33YEmWkEeJcuMfWQzXSSck3tlClNIhmz3kV/Tx97l2ufml4iW2+z9k8RCFFC70LvnFnUQw/RfjoK
TwdB59Kt9Ci9wk2U4NV0jN7hCXQD8JZIpUr6E2vaG1RPv4F9K52hPdSJ9XOpmcZCu5M92kbwXtA1
tEX7FU2kEnqATtJ0eN1JF7RDWhe0S2k5HaYOzP8ju4VO6VrtWe1jnNwS+NwCzRtapXaURlMhsK6C
dAudYo/4ntZAdpzuo/Q4PUkH6AX6gu/nY1qD1qad086TAO14qkbbxMf4vHhUekB7XPu71gskcikf
q4ZpN/0a/o+i9QCwAN/Brbyb9whe4X7hmLTVNK73O+CQR/PRymgdPQgEEnSW/kX/5S8Fu2gTW8UX
tanavymNKrBLfSdRakP7OdpO7KmbzTyZ53EVb+Jf8h5+S8gXlgtB4afCPcKn4iJxtbhBfEu6S4qb
dpgeNaf1XtS6tZe0t2kcOWgVrafN2N0ZOkdf0Tcswtd49vBM9vGtaO28X0jwAU4IVdzD54TD/AF/
xF/yJcEkjBDGCgVCq7Bb6BDOCK+JjeIe8THxA/GiNNskmA6YPjF7LH/trend1vuaNlM7r32NJ8iK
vJkOjBfRbRTBblvoJroPuziCdhSndpZepFeM9hGeoAv0NVAgHs2ZPIUXoi3ixVzPjfwEn0A7ZcTy
HwEHIaQI6cI4YbxQLdQIzUK78LbQLmaJ+eICcaV4FO1l8R3xknhJMknXSmOl+VI57ZCapX1oT0sH
pbj0umm6abZpkWmFqd20zbRDrDW9YXrHvNm80xw3f2n+hyXXUmlZZ9mB03kFOfsCcvn7S+KJiH4K
3Um17Oca2ovTOMARiiG76vhB4NVCudoacbM4X5iMbDhF9yJb99Em2iaupgPaX8TD9Gdkylq4bKff
ST5ymB7B6dxPk5FFA203zvwpegZPRQdQIiroXW48dS7TKcoh8ubl5+XmZHsmuq93OeUJjvFZmRn2
cdeNHXPt6HTbyBFpqSlWi9kkiQJTYcBdGnYq2WFFynaXlRXpvDsCQWSQIKw4ISodaqM49XkRqIZY
emFZf5mlt8/Sm7Rkm3MWzSoqdAbcTuVVv9up8solQdAP+d0hp3LBoBca9C6DHgna5cIEZ8De4Hcq
HHYGlNK2hlgg7C8q5IQXIKQWFeovFi+l6Y4VmhfZ1GDHoFsElEy3P6BkuEFDJ3oCkTqlakkw4M9y
uUKQQbQ0iDWKChsVxEnbR9S567arXqoJ61RkdVARIyFFCOu+0guUcW6/Mm7jJ/bv2QEqsGOQUhE8
pZForFTxhrcDXJ0N61xkB7iKaifcCltDQYW39gehx9iESPVwo+6AHle4yamkuH3uhlhTGODS0mA8
05sZcEf8IYWqgvEMb4bBFBUm7JtnurD7RNHcorn6ONNl39w3fvazPvmbPfpo33z2Q4wVS5MAsL6S
uxxxKs5aYxE3gi3Rb9ESitWWACdcIcY2GxHPPEVAzogexeQpjyjt1QNhNPj7ggs3+eMpGZn6HsK+
EOzDMdsMnBTsbW5n7CLhCN0XvhgqifRLzB7bRdKV+kEnc0XhyADdZgCDXTfY3Q36+bYZZwrebQ8M
EoDXodFjVsYoUyqqgi7FGYJApYLCCpVSqoKdzDtDKmtbVfI7EpRC4m23Ql2op1qjH+uDKSqEIN8F
6oZCZyl2XarnijPmjJXXxZylzgYkk+QxRiiisdAkIFgdBE60DCt6Q1lJMhoKzYCfSbofTIF5LAQP
Tf0eMBqiSd/BaHJhBU4luyq4JKi0+7MUrz+EU0D69lQFlR5kbigEq+JkpIh4U6O9P+YpiLk4H/ob
+7xUwwdchGIx3Wd10O1SemKxrJj+vPXxKtPlAm+/QCXdBBsPqNxehbkY3K4sXeB2uV0IK6RjehNS
eiCjVJp6ZYSnJePGzJsR7TQD4ZKrhPD04SA8Y1gIz0xGOgThWYh5po7wLT8ewrOHIDznygh7k3Ej
yLmI1msg7LtKCM8bDsL+YSEcSEY6BOFSxBzQEZ7/4yFcNgTh8isjvCAZN4KsQLQLDIQrrxLCC4eD
8KJhIbw4GekQhKsQ82Id4SU/HsJLhyBcfWWElyXjRpDLEe0yA+EVVwnhnwwH4eCwEA4lIx2C8ErE
HNIRXpVE2Jul0OD3cPtlr1266i/m1YMgx5cSPpJ9qPnOoV4TyUKNKlUXqGSdpJKEbrWpROfQdd6W
IJFPfAUOlMWgROhT3ieVfx8IqsSTshLE/IfZ+BE1BKQLiE/ODiVI4gSmMqaaQE0uvjHdlZ6D7pN2
qt/+zXTym3mqtPBSV389SfNvqLz3tlGzLlK6XqISve7r/H4ciJjwGz1Qq2I05/XmEY3gr6PfXkh7
OKkx5uEmmEaTT5husEa1bFgItBcY3IG9C2RDW0Nk+TzVgTpT98yo/vpWMENHS8pKfRWLC8qia9ui
rY21Ed2r4Y+0qF5P/5+rX6/jyiewd6RuAZ8GORtFTh4+50dj0qqC09yNgxgqeZ5mDJHQaT5OC+kW
uhl15MC05yhMiw1JVr8jvCNhM9h14jLXdIJPYoMrC3BOfR8KKpXj2OegT0UvKJhrp3Z+mnahP4Uu
UiNvpw3o29AfQ5eS1CFwCd4el6zeE7yBMnmBN02Sl43JkO2pafKbKpuPPSG/a/+omzPwh8l5zoiP
pJS5qfwUP0l1JPNvycMbUeTm8r6uvLVyGKpD1ILeji4ad+ZD8QlT5FNcSB6JMSebJkh8XP6suEj+
pFgVOC6fyVElDC9MAOcdJfc4npBPO26XT6F39KkO58HiuHzIsVbePUHlfXH5Fw6VMefhvuFuB6Ye
l5vz9sp1xYa+cq8qdMTl6dCv8KbJ00pc8lTHx/KkHNXK4IsclXJ+8avyREyEmRNOPd50ebxjtzwD
qgmOQM4M9G4+zPspn/fHPQvkEyCx3a7yvJK9Kt/bVZZb7FF5o3daWe7evLIcT16l7MkrzckBveJl
yxbLKstcyxRLAerMbIvLkmUZYx1ttVmvsY6wplqtVovKz8TnyOZu7qA5gKWjy2q2mlR+FkKpm48Y
wiPPWSWrYCXrGFX7EP8XMY1RueMYspnx4HYcNxuUWeUjXX2iI15Z0inJUNiQwGxkOZ4Dga0CLcAH
+0OqmbZe1zbHPmf07PTppf4fuoUNzcC94IcvOzuUvfhkVA47Qvg6B6E5QgPm9gHiB8fWu6GK+goK
KpZu6Gpraao3qg13IBpG0aFsb0P1117jdHY2tfSXUtnhmtoG/XM3ElVa3FG/0uT2OzvbjHm6eJC6
Xle3uf2dVB9YFuys90b98TZvW0CvurpqfOvXDFlrW3Kt9b7/s5ZPd7ZeX6vGmHfZWmt0dY2+1hp9
rTX6WjXeGmMtffOBxmrfXa3ITlQkqAhyq5XyJSuDKLxDfpWf1suUu4n+B9K1n64KZW5kc3RyZWFt
CmVuZG9iago0NzIgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9u
dDw8L1RUMSA0NjMgMCBSPj4vRXh0R1N0YXRlPDwvR3MxIDQ2NCAwIFIvR3MyIDQ2NSAwIFI+Pj4+
L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDYx
Mi4wMDAgNzkyLjAwMF0vTWF0cml4WzEgMCAwIDEgMCAwXS9MZW5ndGggMTQ0ND4+c3RyZWFtCngB
jVg9jxw3DO31K1ieixuPvmdaA4GBdI4XSBGkWsR2sRfAdpG/n0dJJLU3u+e9A+yZdxRFUu+J0nyn
T/SdVvwWH6jugX78Q3/Sv+Txu9KPr/T+409PX3+SL0uhGtIStuTphUKqyxqrQu5iUNy71WWMsvdv
9KXNttIfH9l1YNcIYKm54c/tKcR1iRxPTUtad+/OL5SWlX92qsuOn7IjhiN2MSwvdV+3EKg/lEBx
jHRb8+UVoDOFA3YhRBEwezG7GMZIce4U0bDOdMQeQNw0zu8t0kqIQWYMoQWDLCSq0POpFrsg8KX5
CPYQciYvdZBxWFeBotewvB+FEDOEKmYTpKUXzOmSaT6KaNZnW0TFDlbmSW3O9I0+gNCB/vs1pwic
GhG7Xu5GKa2bYpaYl4KD/ZKsYmrmfKdCZZHEUSbFLvQZEYqo4pqWkjZKW9MVU7rWJdUiCKqvyN5U
xZyQUYqwrDyyvquoVPPic6SMsl8ryouiqilqxkRRwPpqRlFUFUXVXRS1D6nAl1LQrFrojcXV7AbB
xWkMIinIv9ONfamVYg8gJqlAgySbSSrQoGAUSUFJfYU3WV/YDMQkZdjR6gaikrJxJinUq2uK4xqa
Mjtgg2a7xgGsLwOqr7F1cWCFNCNFNG8RFawUO1gNUc02b4rqNa0mUe1DVRvLoKcRqIuKk9XEhoCu
zBQzO1FVs+uqwqJ2NrA/VhUr4NBLYsakMaG3bY35CFGyBDg6gvYSP2HK/DRKHrz0EuFv2YT5SZrE
dmR+aayTbbsTCpgyeDQT/5r52JAOzAem4zT6A3KD+VMzAXN+2UyUXfUG87XlmJWt8WBlReyjmZiV
MR/1eqibJGE5xz/aieq02kpqRoPTSVjOcRyxA2KeHmsnN2glnE43+olQH8unnEaIh4YCTgtmdsL9
qaMo97ksd7mfyhJjTtjhN17wmKeDVDySf50wIT+wQU/ZoYudhwb5VyV/3/ZFCpzrOK1MFto/cDTD
s5C4UVbf5r9cPbMgbGn5fHQgc3JKwYCdXOrJDcne7j0zac3qMmU403WyGKuOGuhMStRiWCfcGt0r
oqK+E+HEyrD7iJvGvXHuOXDA9mjELKccx5u0vilHYaF8bBb6Juxki76EnZ36BqkzL9v1Yik43es/
uFSElJfEl4fi7T4hUFjitqF0KS05+Qyj2IxcSHGM6gDvtAnWMWDXHkZA/DBSPwKMuXhUg1wt6+Lr
nic36BbtgqNzCcCjJCDBLI3uBxFKEjpXu/Fo7q0KuPqo+6kAGJr7rScuGeULCNKApnNYp7KyoMu+
rHXLaFyGVUSxRUJSueQVt7WKUzqMHOIdwwaCyuVtiTnvkLxgGSfP7nw4MkBmO7sJw7LXiFOhOiq4
EXJMNp0g5ymogTmLG0jzNCEjOz58fJn9adZBq5XDq2ox0KoVcehdM+9+WVhmELZGZlnEFdOXiGJt
tbMsVhwv2qgOoFYRJdpzAsuGUUO6kfpBree5+ihAruJw31g2uRkEtrmU0VNAaiRpdD/Okhh59TKZ
M003bwUaQtOpSIqLkneQQ4Gm0QQo1I3y2u8XuIMI4nEN5yKlbcdDKJRxRoU8AGx9zHg/u4TK+Ipz
lpmUYaJOBjDmQVtGdH3mjQvEbrsTl9dWe5tnvPMYCUVMJNhVnCjQ8kFfYQ5pxJql1ibzp42C7W8q
z4R9xn0S5aOwDjn66vCRhC9c4xMJawjbIM6XTa7Ystrf+atK+4Ty4US+v+A/7Gco9umF3p9O8OBO
X+gvevLvCJ8+Aj094+lvOv1Ov52mLbNtG7xvUs1oeBZJn6lF4vB3RIJL3uOR5GqR0FUk7uk5vRVJ
xjoIke4ExF+PJr5dVahX8E6Fdgi4c3Qq1HV4KFTs4bmbhdLweCE9L+7tol3FmNHJmu1UwIcCzdiq
20Bd1kO04Z2TZf30P10H4j8KZW5kc3RyZWFtCmVuZG9iago0NzMgMCBvYmoKPDwgL0ZpbHRlciAv
RmxhdGVEZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8L1RUMSA0NjMgMCBSPj4vRXh0R1N0YXRlPDwv
R3MxIDQ2NCAwIFIvR3MyIDQ2NSAwIFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9y
bVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDYxMi4wMDAgNzkyLjAwMF0vTWF0cml4WzEgMCAwIDEg
MCAwXS9MZW5ndGggMTc0MD4+c3RyZWFtCngB7Vm5jhw3EM35FQylQO0mm0d3KsAQ4EzeARwYjhaW
FKwMSAr8+37FOsg5enZ27MCAJAFSs6ZYfCy+Opr9xb/3X/yMvyVEX7fov/7pf/N/+YC/s//60f/0
7lvwH7/5FOJUSvGllimuKfjPPm8QbdlE7qmLtsBaT31iF33yH3woE4yVpMZCzdMcYUxEMGaiuqkx
ntXHZInQz/7XdwQ1ElRsaKq5Sd+0pzrNGNeQpjRvwT1+9snXacOfGrGPYQC4Pk91m9eoDyX6RXXX
/vjo4+rshye/zFOE8dQ1lthN4dkWfPTjaHh2w7NvWmHjlT3sRx9jWwJ4dK0oAIDF23NDZqPxl/H5
0YdhzpPH1oItFoKZwzkc6bF34BRbIXVgyRviR3jSBv3R9Uds8ZN/CwJG//dzZ+ZxZqsXb9CZwfk2
IoRBPUE/9VH7STxPsxaQynb5gLUDre2u8oXWHihyNLjIl06LE750bryAL26XL0c8uoUvzs7smAnj
aO/5hC9ujy+g6j18wS4HZlx+fAFfKMZP+NLZcxdfEAfGl+v55Va+OAslSyP38uU8c1i2GXPK+HyF
L+75/NKj/ya+tCRyOb98j3wJAbVuW3zaVqpIjTDTjD8BpEV+sWekF34WrmQtShWT/Sp6CZkUx5Co
SnBlyBjgsJlgmITnlSsKahY9d0Gcj4pL7iZQAelwxbqNVBZWBxliSVDAJEp2kNHRT23AYAAcI92h
VLTsTDAD5jC4/Hg1EZw4t2UCARXmVjk8/u+4UbK5ZoybQW3karFCk+Ke2iCH3iJu8HAqPpaVehJo
Lahyc9pMgkNQybo0nac+SyWutUCoPbs9y4JWp8aK4yjHHEENk+DuXImLM5lyBnrs8iXIQy1agFY5
NehI7iF6RD7KqPWL9i6EAg4um0Sd5k1lF6ybxDBQcmGtjkslHf25pM/T3qFhUFtCF4BmmldNQ6Cp
YO+Svp8uUy0thJfnhTNbyhbyF3dJhEvIHru1QU9KLekJ80EadiJClZ2DWOCWDtEsEic9E52Hyrov
bpFYcLgLXdUFVslmF62PjfnqAemxVkrgillarSM9k416TAeOJJ6s3RfZ262mCW8CIYO9a2z9+pAe
NyVPReCxM8KmFKtwtcqU+up76+Gr5qtNGV0vMJ9MGceE+QiBE+Z3gRCfTKlSR6WSjv1c0uf1wwaE
/w3xA9x1C/GhZyQ34tu7ghKftI6Jj1M8Iz60TGbnekVylfiXSMWMxjLCciKVZgiTGfMJjsbvoGcy
ZT7p/WA+Xq2HgLH4UEb3WPjB/O+M+e3CaSq4n7F/cM1E+cDXWW6NEF88jtOyriicYVrmlCs0WksV
XEQHYCOkXeSFecsJvZFo4HqjaYgFGYl9epltv85TqFumE+DZZZOrpmbfRuglFIHJBCFbULxsHy+z
7WLKNti2ihsqQd13maeUF7p5Q5dX6VYNvWI4kbVa+UL/6ErsrcE/7h7/dO/23cP/zkYv9A/wkH+O
vOFw5uqNsqJlOvHGIHs49jZl7ZEtzs7K9vqv2ILTPGLLjjf87d5wx6d5wRu0J/MGbkTPvCGyxo1A
rQreWBLcxu8kXVI4gELcpiXGAp3adAIKHc/h8aMLsU4hLHg5MxXc9DazZkQFvA78ElWSKJBwbSNG
XJI3nb4OvwvRHIPCog5WjRzvR6KpW9JdmocSLqJRb/IYPYPsAS/a8FBdXS4S3ugeWeRzndlFaQWu
FS7KVeIzrfBRXbsALTl8E+qS3KAEFzQlsyMCXYtmqWht+cbM+Fya+wP8JWuJACHSAanMMOPlk/JW
30Rf65P7gJlqzLabASGnsmEzuHgvcYOvMlxwKjNfARpPRmDaunf5yvyHTf4XvtLt4TTZeff7CklI
fDVSo/sq53NfddmDX9AUrxn97cZUxm0AS1zcEtNqAZm3jA8ncWPeLuA/z9EoWhCLNVVct5hKFRU2
gjsbFWgUdUnkyBuMNPri5UHX4TEaLYECcKJi8NWICXQdytPdku5SPeQWvAPXjKAZ2DTIkKlbaWsf
jJCEudiFSl+Z8AlIvzFR1ZajRKYVpeyaEn/dQYfw9kD3NvQX/9HXHInSw2f/0+FAtg4f/O/+VXrt
8dUn+ldvwmv/hz/84n8+4IL/rOHwVFGeBVaIslSKbgZWKLHQjH1g8Rlg+lXsmsdKEfS3A9MksQ9s
uQ6McmqiPHsNWEIsNKWbgaWt8ox9YDjU/aPMyNyWxwLltn18Q85DJifdW2Fi77zIGnjiPtry2gna
ocltFASPO1pkkpvR5nIn2oIGlba5j7behJaiOlKk3+BbdLSs+1Lf0vVUW2Qfbe5o3/8DprogeQpl
bmRzdHJlYW0KZW5kb2JqCjQ3NCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJj
ZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFI+Pi9FeHRHU3RhdGU8PC9HczEgNDY0IDAgUi9HczIgNDY1
IDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAg
MC4wMDAgNjEyLjAwMCA3OTIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCAxMzE2Pj5z
dHJlYW0KeAGVmE1vGzkMhu/6FTy2h05HHGk0cy2wKLC3bgzsYbEnY9Me4gXaHvr3+1ISScXjOmkC
JNZrSuLHI1rjr/SJvtKM3zUylZ3p23/0N/1PEb8zfftM7z9+j/T5O8VYphQL5YUn3lKkC8UNL3k1
KTy5lEqzgqQTXfpCj3XPmf76KBuwbAA3ppKr/q6+iluZ4pwpl3lK8x7D+UJpmuVnozLt+Ckb3Dhq
T67lqezztlD7v0Za2sQSNl1KFToTN9Gt6ImWeWLsvtpMQgbEidgXXYIJ5tXZjUw7Wh2UMMyLe/V0
Exd0Q0bC4cviTnHzfnPXVcFaFo5qr1LOqGIPUOehsp6uaH7FeGUHX81O50Kz5KsWrGYWkSkW99mr
aNrBylcymzN9oQ/gmunHy1ARoFKXQ8t4hcpSZ9oQWtSkXzyhprldAPlCqUCKyBszpj3RA5yMt5zk
OU55LsSNfPjYw4wG/m7gj5qCD62Dz/1FMab3Tj5sOvm7k8+uGfnFtQ6iLrqwoo/e0c6VrGVWpr1C
cfSZrJSGPpOB0s8jsqNV6LWCTVccfde0UncVQ9+tDH3J1wF9tzP0Yad+GPrIvmpeSYuoQY15Frei
P2oHK19pmHcH/SNVnfy4KflClWWzk7+PkRnlg51pSj7WM8qNfFRVT8Md8mPepoU41o4vZ7NHHUOf
zM597MxtDA/VTrlP2nRSpxdWvavF0DFh515PR13rquNDswbcTxUW7S3Z/TLuB7/Uyj09Kj4vWB2N
e3DzGy1/iCcob1pPJ/CGYtwPVlZN5OvA/U07Y9y4X5NrWqFgEalyg3tcP/Tj72iliufrfsu/Zko5
oL4FmApX/b5yYHZGuFEP/7T7eJ6M8GDUw+4V1Jdpxs3Huz0la6dYygfCuQKuPXgdWvZVR/e+bb08
dfbLDoJ9Kby2Xi08+uhXr8XK8y+8Hkgdas9DT5RriVMxvEYNXBcifYQcP2++z98y1u2qwc4/3NAj
lJwqdFgf3H7ZoQo37xGHkm2dJmRWKPGR+K6wCBg+ksbqfAgzPmo9sl7OpxW3YvuDKznPCGgJOfc7
NmZWhbKQvm0rxnFaloSred7bPZxnXGNxDdYx8rvvU+QMoLqGcm7Npq9i476PzOkW6xTLnsc18rgP
fOtjVNt9MRvxH/v2Vcx726c+IGjIoQaPJwWLwePOU8oLnlzkGWGOW0JKOR61B6jrtAJZbkmTGjWF
2JIW0d2XFdlrCYFFkjk2RiwoZOYCpJpJ4MjdRDNvQnVSOrIpNVzM9UVqQnQf+NbGMsdcUZPqPva1
RVTQfSRn3eMxSs0QF1zWGSgNGRo0ZAhFwfptOaSnDVtYiHNa5pRx6dLcACcbCBjTvOeEj+7+Ph4h
5H0lqY3q2ric9Td7KMPcHmxb25Nhe/f3m2ttev04wU7P0tAWsFAsBxmUXOfAtPCA47dMiYVrneuK
hlIYCOxrZR8PwpgD4OqcetRQ8QgYF54TDlST4rp3E13EBHXbTTQrfRHsU6PGlUr30cREd6VJ7qwt
8jweaWmPw0oaJVuGZvnQkwuVHSM2CYxQhudZDhrjilaPXiwB3xk8+jcGONnwvRqh0N0oyxcL+tSP
HvbhRFG+dpjlnzzjpzojnC70/nTCxyadHukfepPfEr4NYHrzLr6lf+n0J/1xGrphbQ3SEuunZ5ba
3nNMgK9Gr3aMS64z7jjGLziWkLEXHQOFv+lYRsaw7B3H0guOzQVPmcjcnUpK8cXm9flCt5MJp0v4
RR0X9+rTT3xGrOwKZW5kc3RyZWFtCmVuZG9iago0NzUgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUvUmVzb3VyY2VzPDwvRm9udDw8L1RUMSA0NjMgMCBSPj4vRXh0R1N0YXRlPDwvR3MxIDQ2
NCAwIFIvR3MyIDQ2NSAwIFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUg
MS9CQm94WzAuMDAwIDAuMDAwIDYxMi4wMDAgNzkyLjAwMF0vTWF0cml4WzEgMCAwIDEgMCAwXS9M
ZW5ndGggMjc4Nz4+c3RyZWFtCngBzVrLjiS1Et3nV3jJLEjSr3xskRASO5iWWFyxat1hFj1IwILf
54QdccJVWVVd7IaR7s08HQ6Hwycedtaf4efwZ1jwb40pbEcKf/0//Br+CBH/lvDX7+1vS/jlRxGb
t9rev21PcUvztuSwxTKX5YjT65dQ5kX+g6r5wH9bCrewN5er83YseyqhP9Qaso6cdtNlSHgNaeff
w1vIy5wwsY8JOakiaMSzWTG9jm93n5tUPLoBoj+FlNoUiXNNSc0RW/jcLOPb+Jfx+TXEYczbsMLI
OWN0rW+BPqDuN/cUMfP6RGsNCVzNq/uc2FnKkIkyr+Fz+B4sSeGf9ykQQAGarH5M0xdxlb3BrZSI
5somwbdRQncQNEo5RH2b3sJHmBRvmZT2ed2OsG57I6VYZIsyOuSBlJOqzLCLckrKVV29kmDZbM9G
w3xBygzLlJTgX99TiJKU60A9GekUbVK0ZcA7dbkdN0lZnDKXdBvf0n6PuhekHFb4Dimz6zNSwlMn
UnoI0b9cjZPSCXeWOiMPSXnFAElLyrhsLBQGOCdl7ylBFt7hZJ6MhZechA7h5Hc//h3D738j0I+5
pCPUhBy1lyjCW533Ai4Y9DYRyrVLvflAhz6HT43r0J1E9ykTp7LPGWmw1k56z8TROL+T8wNklI9K
9GwPK/m9a5KKRue9Eb6l5gEj7cHwTnsk6qRSPZxynIgo0UXXGXsCaUGh2pVMOzaAIzUPYhW9QqxG
S6TfvtPMsjt0nbCnEMnmaoOSfkf4G5R79IhZMV6JkW9uBaDuJrie2jrxIdSLUNYMhdrcs6n4z2QI
3QMswmTQg5R+zSVP6dGiZ28ZXdekeV3WaUvXEBLK0bPEBrHOgqYt22YqBm13M3xJZd4K2F7WqxQf
N0vnh9N9sxA4oFSds10TfnPa6iq2iUQmQdAFGLlJ+GGk0s+yPaLJEDeLhGdzclDKDbVxjvg430cS
nm0KCb+RRLYFkOnGDwGcLIMzLAYp3boBIeEHjNsJf50Yf1PO7TDKD8ba/lgnQ8pvNzg/YDbOpQxx
dz2k/S1SGROM94fzPhFz3sMc8zCJnxxzT1kfMzAfcpfMtzqSUp1LrqHsRSoEaJ2XMq9lIyJMbMhU
jqPJvCFh6Cgi79eQHU19QgFAsrns5tGRar4eomrAGFVWPdjvrGyCDisjrBnHjToiEcqMraHG8HDt
pzoiupj7aesTyNdfR+CvU1hdVA0l6QWmlYRt4T5pNJxLya1aMmAcZ+XFNRnyTjm5otVQTuJkVYzh
YiVmqCYw5hRVA8aoitaXtbLzn+rJKsdZ0CsuwnxYqIvMhxK/OvFHzIgPrHscR+j+gHN0N7oa8SFj
iBPfwgP6SfxBTglsZ+OYjPjF7SLxB4zjeihA+wlx4hdLmavY0Fs2EKd3HGBfb6AOy9ropDrjSK7V
GyjHzlI3ENYTH8cGSvzViS92aQflcsC6GZDTuiZy9L5hvpNcUac0ximBV+zHGTshrmkY96CPKidW
0WLl/er9UdFyImvgupT3F2LEXM543+Q677GnfetF390+Km6IvwU+7Rnfeb9Yy7TLsaV7YsSM98C6
w7NR1Lr/Pdrdht3XQBXbKKsBwEh7H2kkZL4vRnurOU2XUnXAnkCc9kOOI+2H7MgqxKaJnawhTvsh
956kjPaDDGnvGGm/wF/P5HvImR2kvR9ylKvYH2W9tVFAhrTNnSV2QlwTZR62UWdOKZ+X3bJ9Owpr
1VLaNyJ0CAt7Kt9DHzsmlI87+f66i5Iry95FpWObS1kRKA3BBhDZt6suKhJ5v4vSk3jqteR8EN/9
RpTUTdjC7nnnvEYWD+J7sg5K6wgUnQNKNJG6WjZRiq4O4ueAEl2U6qkD+p9AvvqAerZ/uhFOX8lB
XKk0NE4WNf1m9eIcjl2zyjA0SUN/xeAaxHTD5XRzJ45u3rRG3GPFHQfxjLvWpeLuT+5a7axQoc5f
hOFKady79apBbuOrgpUJPAqr7Zxdnc/VzuOYz9osEeQ5WkaOb/eeRcoPhZL8LUuC8fZBgckVU/C5
Wca34S/T8Awr/D619bGXGd3VYQfGF3OKn8mlNOvXB3Zp7crHk/iAD4+aoqfbd/a3to3387U1JXa6
Ff97Qm7HX0/P7U/KHRnF+3lZtXQd7dPSDF4s/B98UJJsuuMyelui5FkpBwqFbUlz3ndk5X2dj5xW
ILkLxR2Xp3AzAXEz7oFSLtBEoaxC1GOAziWjDAJ7t6NSTVj7YRkHCZ3LgLalahAxt5l62rpgIef6
PH0a1t68gA9ppp6C8B2O6zXLFzjE5xLxUQ31KF5hqFEfQ4H16NnWVS+MEWSGrN13JaGr2+sGmVbI
YihRx+j761Rgy3GU7DL5UBnVwnedB1FjEqX7zXRM66ru5zz6jr7abTEZs9a02HufB/VEaiw1cZX0
0LpiJxI4MnhowD6GBHMKkk1RjfCuIbq2tKa5SvGvRT2SVjhbxpiHMGaZc64Dlipu9Mskt46No/2d
80jeahJAdG2DDl095+nv0kK6LZRR+6nlYj2YRzxETb5K41CFyrwgrQ0eGjB46JAPEVj+0u+L4CFD
0LbI4qZ0lPmoC2Rw9JKOKR3YKBmj77D8wOffEuEhioBnTaQrgUQDJptHxqjIsguJRK0pWZrrAeg8
+i5jzJQOwTYzn0oM6OtRD1ETV0kPoU2vW6zS9VmUVcVa7or4+JIXJIe8YnL5tIIk5dg6L3mV+ooP
3xEZLAsnITXFnG1cRyR1oI1KS8F5VqWARJdSTUT6fGDGIAWXpBUHVteEuBKrhvkUkXG0qmOwiquh
JiK6vu6zQR/XzcjLaJWP/dJrhnWvYWMWfPPCN/nGGfjMEOUVALA6ZxxVOmlQiJHwZAx5FcGRIyEa
DRKgiyivCOg8WHMXmZLxypUojzgPeeWmUMTM77yCbQaMvHJNtkp6KIFNNSKtDrwyrGVvzUQRhw89
hvTUFA98wJPCx3QQ9eZW49xeJWH0xATr+vyadVxFz0I2B0YYsGrMWWqT9cGMiXO0V0lklpRUAkDL
QfGgCn3v6xhTEuzi4ize0rKc/eKYVDUUF9wmIHy0JejIVEHm5piS9/nYJLvYd9GSUW9lTM+AMLvk
dd5WydmG4ea8y3QtE991HhmjEkmrmuvQMs55WNbNFlhHGbWfWi7X0x1ETVxlRZ+DgnKgqiAu5Jcs
uMM64CxgvY50DB6Sj8fbGgq964hyp2yI2X1Z+R2gbAj3Nsb4W+QnO/i9DtR0qGxIyE2ESgxou4g8
5CK6+YOSThifxwhkpmAeE2nmwzQquVyPeogWG4fMQyhWFT/skBsjcxDqikGoaWidUNWldUJ/25up
uMmvmeTbuf6WSX6rlLsQPt2qUIWQ9GntH/rT719C7C/4v4oRWx/x8iV89/Iiul4+hf+Fb9YPAb+D
SuGbb+OH8Ft4+Sn88NK6vemi3U3osfCdUjqWR4ZJs9aEnjYMzugj7huWHhtW0fXs0ig8Mkw6hyb0
tGEV620j7huW3zFMrtFQnx8blo4u9LxhSC9N7X3D6mPDpNwVlMCHhmWQuAk9bVjesPmi9r5hx2PD
pMosUnkebaVc9Dahpw1LCa2OqL1v2PaOYUjz7xuGI9N/NAyh/45h+yPDKn6eo0k24yj0cEct37SE
3GQH/00tw9xJHmhudRL8KE0mue/G8mEac8hwbERKcmux7IgkeH+X3dhFMi3SlSe652xFqybj7puK
xPfb1NPdz/8CkpVoRAplbmRzdHJlYW0KZW5kb2JqCjQ3NiAwIG9iago8PCAvRmlsdGVyIC9GbGF0
ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFI+Pi9FeHRHU3RhdGU8PC9HczEg
NDY0IDAgUi9HczIgNDY1IDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlw
ZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEyLjAwMCA3OTIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBd
L0xlbmd0aCAxNDA0Pj5zdHJlYW0KeAHNWD1vHDcQ7fkrprQL08vv3dZAYCCdowNSBKmE2CpOBmwX
+ft5Q84M926l8wVIEQmQbt8Nh4/D9/ix3+gTfaMFvzVEaluk73/R7/SVAn4X+v6F3n/8EejLDwqh
+RwatWXxcc2BninU5teYDXLnCYUyogBpwwk90efe50K/feQOIncAGr6Vjr/rn0LcfN4KtbT6vGzB
PT5T9gt+AjW/4acxiwN0Nqj4ti1rTDQ+1ERJ2rlVEilAjxQP2JkSBouuqzWkFKWlJneGGKnHGWXY
MeqAuF27sA2mBA7aY4ydTJysotCf3BVBLhuPYnchjxS0DtoO86pQCkYrBCmEhoGqhu0gK71iTifM
hqOAjfnRZtCgQ4wAziIe6Yk+QM6R/v65lghaUrJS6eCeZ4EU240paK13YYbNoUPtXZqcLUmFFEO2
BzA0Sy0ICJlqq2apbpY6IfVPdXULZiltOCG2VMDIX3XT1vyyUQv5yksMDsbRzLTH1E3ARPFZPjQI
UVpe2ym+YKfIUh52KtZwiluTH+zEucwCRvUO5N/aqfCE9bmbOlDkf2YnlN6YDSNgeq78BGTnDYsy
7ICIMS/b3fDUpaJecFR8wVGsAjWeuec/c1QqxS8F9ilYKscmlSo+ljYhqHBArmL/6lGAtOGEfuqo
hE5aSlS35dpT2BOHktL01A4zT6mVYhFPgahoMImnlmxIN9V8OtoJ+1tUl8Jj2NCFRbeCPe2/ufjM
RpuiQX7I7GrPKU6FB5OYCAezF7+5jAq7NufdCPfbysyqUkENLPd5VsowkXJ2xlaRORrdU5Dr2gIv
IHduK9cSmCZAN7KHpO4CezL9MxFdb9gA82k3bNs5eDchfcKGzPsIr/eHU1PMq08Besq1q5IpjWrY
qWkzUQYnCtlAS6PGSpyCFHqemlZzrvBed8u8M8x0aaemFUq6ODUhuSHGYC7zk9Ux6ojMdjqzK281
0qNqAt7Qs5zoBlLUlciQ46lpRqnyJ6Kq5Dpcn5qYg6aXUxNDemqayWaYsVCNo/SG6eyIxJNNl6h5
hcc1RqE7gJunpmst8QlcxyTqZi1ZGQ2bYxKJr/swxXbnSlF2D7s6NXHVWO39ouIrbgj2B9eTkLOv
0bUo9w3cSjpCLVaf1rXiOfkWcwUiy33IEW3mMyYvB19CwRItMS5kdMMxlkWepR9uI0j2oeGassuR
xrYy+gE3eeY2xsVimD/6sSzybP30y5IO2fXB49ZkY7BxowK5JL7FJVhxxU5yphiO2AM0iEU9FNcW
OVGiaAPCVS5K1SDUFDZUDWfNvkmGAP9gYTEAw1k2DzgjkwYtqwRpHgOkL26lMYtUTtJgJ916X077
UoD9pYQMm5w1jw3C+npyOBYbcRvurNXSfAstX9RqYg8Ua/IZ2zRqylXgtVyRPCoVcZooGfoqSeYi
VpSd29gcxrr4lKAvw2LB5Ta7kjRLf7Z+eGFVJI4q7XLIOKyf8cxn1MnFYoS/ZbkYD/phfVmmOUpV
UymgvuAksFPTDnvAaQpvAcqKK4vY63kHYS+CB12q1W818r1mzDBCirQSAKt4zXgBkPg+ZEFJgkYe
hHTAWV/cSmPqqNMujdR/9mUTooSQyYJ0GJZHARnXKNVMZsMta4UC6oYrGuqXsFFjAcehkDFo2jCo
qZszszkjDo3drningncufHuTNy4JQbilcRA2FQkqrgfxm5r+WubDCT7qD/gn70i4xemZ3p9OnOv0
mf6gN+0t4W1KpDfvwlv6k06/0i+nsYj0laT/wTIKYlB9ZCfcJNati6D7iXVPosXrxOJtYiVvfmUB
3iLGiuxBdxMrJY8WrxPLt4iVddMJ5msAJv11fhdi6LH30tx4bekqwjrFnbzONr11Mr/06R/7SfNT
CmVuZHN0cmVhbQplbmRvYmoKNDc3IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL1Jlc291
cmNlczw8L0ZvbnQ8PC9UVDEgNDYzIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMSA0NjQgMCBSL0dzMiA0
NjUgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAw
MCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDUxMD4+
c3RyZWFtCngBjVQ9bxsxDN31K96YDFH0fdIaoAjQLc0BHYpOhzoZ7AJJhvz9PEknyqmH5g6w5edH
8pEi+YIHvMDwTdZhKQ6vf/ATf2H5Grw+4fb+zeLpDd4EnUJGzEa7HCxOCCHrtFiB1HFCJXbWcRpO
6BmHFtPgx30N4GoAytBLbPhNO/nitPeFyrIOpli1MaQ2fGzCogufJVUZFxh1DCzqpZjsqLsdUoHv
llHlwRkINrgOOmGhJqAdw6eJeddM3e7UZSWI6NpwiX0BUWd2tjSpuWoYEZ1rYihwqHJdfp7aB0Jf
ks/AvoRsYMlroR2GHe921suKLmv/4VGr8IYtMan+wJTckGQkiOS9zXsU7II1PQlnwzPu2NkO7/9v
K7CthmTVK97aSkon2FlqdhT9NAsq2OQp2/shs02ZeS+pYEc8UmQbQJ3Y+fLBsQtm0SEFJNMHSbHP
BUra55wIJB0TD4n/tJkMZHerHWAFObc+luqpYyoYv5PEzwD2oa1WAwraLiWeu/GfYqlEagterUSQ
kEYa4mcAEqttA+auZgG4FmYqO/HEPUP3gSPcNkIsdTBiMRfYo4q5DJQXUJnO6BA9d5xd6oo7zAX3
yUPj1n3TuVE1bt2PbRnerbD9B78i91OXwxZuhusJt+taV+d6wC9c5WtwlTlc3dhr9Rvrd3xb8fAB
YdcXeQplbmRzdHJlYW0KZW5kb2JqCjQ3OCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9S
ZXNvdXJjZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zv
cm0vRm9ybVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDYxMi4wMDAgNzkyLjAwMF0vTWF0cml4WzEg
MCAwIDEgMCAwXS9MZW5ndGggNDU3Pj5zdHJlYW0KeAGNVMFOLCEQvPMVddSDPLoZBrhuYky8qZN4
eHmnyVs97Jroxd+3gaFZXRMdkl2oqW6qmh5ecYdXOBkzMWJmvP3HI15AMhzenuo7h/ubQrMx1PVV
nTF7S0TgxHZy2axHTNaVJyPaLE/M+A47DF6wMbvkGW0yM/wWaVLNRQpglZ2+Ygd4Z9llmgfP88bq
yY0iKmvFOfYLxJzEUa5KE0RD35G5ivFDldSoVCIN7R2RXOqnY79CVlCvQ48zB3TIk8oi2grRaSK1
004gLX3HjB6j+lFEXa/jEBU7Y41MylnxjJ10HeP9x5aCtNQm2LRq147Ssik2fFGv93HUUjGlGWqd
kKQ/xXXpWWn4jh3wIALrh2Fn6Xj9kc+BfbLsZ/CcLacJR6NIdNanJK98tH5yMolUOcJvMdtaDt4H
S56mE8pUKIZHkgroPiWmI8lSzBKrSeb4eZ+2Lg2mUpTS5WuSDjQ/5Xj2J5ar+fsbcbl56L7BwU7B
y60hZbBBnEt3MZ1jD3LUheIKhd1GoGjkptmPe8YLKTSStHfLTKFcRyKnDqn+bgG1hfwFicg1wixH
/FmWcmcte/zFRb6E3FGMiyu6xD8st7hecPcB/Wz6dwplbmRzdHJlYW0KZW5kb2JqCjQ3OSAwIG9i
ago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFI+
Pi9FeHRHU3RhdGU8PC9HczEgNDY0IDAgUi9HczIgNDY1IDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1
YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEyLjAwMCA3OTIuMDAwXS9N
YXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCAxNDM5Pj5zdHJlYW0KeAGNWD1vHDkM7fUrWMaFlZFG
GmnaAAcD1yVe4IpDqsUlKewDkhT39++RFKnxrr9sYFd6Q1H8eKQ0+5M+009a8L+lTG3P9Osf+ov+
pYT/hX59p493vxN9/015X2IuG5VeYu6FHqksNZatGBIeJrLvIvMwVznyg77Jfgt9uWPlmZXDhNiq
4LcyKssaU0lUc45l2VM4Y7+44C9t1OKOv7azDVcYrDCsxrYvfc2kg22ndawM3WQMoTNlBbNL0QOt
cBrbbxNbsyw1pWsOjrhdZ7rG3oGEw7q0i6mdbbAdEQs2Zp1WZTW/T9sNgS73x7B3IWdKFgdbh8zO
eCW3K6URCZODrS53wDz6hgXPkHvkiPt9nnl07EpqanKZM/2gT2B1pv/ephWBVmZysIg/zjgZdHAs
WcgPYo5NuZCUDR0khd/M3EyOPdA9TPTSqigp1FHpo7IqFJaek0FIwIS21WprLHOASyvB7RerKm9b
XFNHxW5cVVJUxBYWfKJwRqHUw4CfFCkOfHk9VEy8riCOKugQAtQPHwLkRShMI9XVyFsJLmcwd2j3
We5BMNiJb0SUNT5QSjYVVEmFrTHDh1YGm4X9QB3+4o8wgFc4cREUoQSlhfPW+ZstSOh3gadqEEzj
rKJS8PSYyRUZXLwjQmivsaOxWtN8GEAo3g9tiQNvZnFncuzPtMYlXbfGI2atEdhla0QKvTX6UNNu
D+Dq6IZTmFPjqjB+0gGDz45PjmMhiFcudzrLpPc45G8UHMffxmqZz45PjmPuZXONUGm0L1QUE8pq
mR8dJqNjzb1HL0LgLjrWkoLbbx0LUo5px3od8Y4VnulYF8lWdlpbEoraRHhqsVLyHt3z3qPMte6k
/OWucXUG1xWqcb5v6BpPz+DimZZ7gHS3I2ZEA6ahzNsY7Kh/JVoZZzBkDJGsqrKJOev89OZ2M6RM
u53BxRjITcWlBg8P615G5hlcLIuNmW87jvzDaL0Z7MabZqeGs6bNM3hi11LPIH4Gz3V+BnO8rs7g
KcftyvIxGM32a6AQfcPGyQlt7pFyFchgb0MMr7ErZGo6rHul317Sap7BJY8zuDGtxvWlkBIc2MG1
ceK2o5xjU85OYZHTUxhpHdmHPu7dcgGOG26f/oFrb1p63NDu66JX2cfgSFri2vsGkRZbwqDiJsRX
4rRsumbMkUZckaEBalyksEioU4kAvg+vMaTH1LB2KsGGT/bROWg2TXERM9+VGKD+cNPBRdxdltGX
O3g5fDC/heitrexDjSm3DXHLW8yX2D0ylmIpK5UmV5TAOTSkaMxyX2It0FFaFV9y28canePa2npc
V4RzijQWCaWZkiaA7cNtw5GsMTso0dzMfWQupemmDBE31pQ4oFcujdnUZF5yK5BolB2acn0SoQN2
T7XWuODs3qqsTaDvhNS7UHGtS/taISQhwWENaV01gDMg9IBe0JynEK7jonpEiUUABN9LV6mMeFiP
aiQGx70GwKvUIGhyIXPD9Rgw/NJQTcOnu4hpy7lBGXpSR5rRnDqGwMSZgd1TwXsI7mZeGbilGmLF
U1DKa1s2lJNYBgkQk9d4BRYmrRSyi+CyLSKjjEsagDIezJjIKJ6pZJSX7zPmvEZNgblapMPYUNFI
pIzd+lFZGqKpafQZREMjhAteiissnQEKE0K1wUt0Ci7IDF4IAVPj93d+Cxhv76tUrQohBypUIRTs
LRy97tMJDURevvEFUqCPy4rTI308nVjX6Rv9TR/SDaGyNxngNT3Th9v1hr6G05/0x+myl0Av7r34
0aBxQbxmIVeICk0Lg7ihRl1bWHCtlhXvsDDfhK/0koUVP2Y48zKz8WVDDywFyUT2nfZ2nBNC7w1B
44VvmR0+3BYE9m2za15iB0VetDq41UwdEZ1GK1deCLIZXaGb150ew1tkAD/M5s//A2DwqMkKZW5k
c3RyZWFtCmVuZG9iago0ODAgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvUmVzb3VyY2Vz
PDwvRm9udDw8L1RUMSA0NjMgMCBSPj4vRXh0R1N0YXRlPDwvR3MxIDQ2NCAwIFIvR3MyIDQ2NSAw
IFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzAuMDAwIDAu
MDAwIDYxMi4wMDAgNzkyLjAwMF0vTWF0cml4WzEgMCAwIDEgMCAwXS9MZW5ndGggMTA5MT4+c3Ry
ZWFtCngBlVc9jxs5DO31K1hmiyj6HGnaAIcA1+Vi4IrDVUZ2U3gP2KTI38+jRFKT9e7FsQFbeqao
R/KJIz/RR3qigPcWE7U90dfP9Df9RxHvQF8f6N2Hb5EevlHag09lo61tPvUS6ZFKqL5sxSB3WdAe
p9VlLVzQF7ofewb66wNvkHgD0PCtDvztGOWw+5oqtVh8CXt0Z2zpA14JVP2OV0tM4woDD8Wqb3vo
qdAcYIMsK12fNtkQOlMScGEXyggc27eF5TSXitNUnCHG60zX2A2IO6yL+6RK4KA7pjTIpMUqSUCL
uyLwZfEodhNypqh50HWo7cpXNF4xSibUDlzN7oBZ9hVzViGLyBCL+7zqaNiV1fJkNmf6Qu+h7ETf
fy0rgqyUspOMs6wsdYYdQoua9IOdYcvORdED+8uSKsMu9Akk40skoXtft4jzlFj74OiKsAyVNb8m
ELvosDYdFElcgN0ashxshoKKsKthkJl6gNrT2oNFuWavjId0KYURZhyiJSkuTt08RJXSLGBkLjYe
zGyWujuMj1bxsAZZZlYXivClThk8TKbsaln+yqKEoXKF0Nbk5aFoyr2oqetygUcMQ0X8zbRikWmZ
06m56FgZet44a6wJbbq547SvBgsHe/Udndq68MUQaa9cV1n1c8Nlnb3aa/fsS9+t1fKZmCkN0VlL
W9hqv9pqQ7RmKAM8GLTVcqW0645S6wzhijAOxiiqdW2MbfshQpvltIhdWVkn4M6pFbeeiQLr8WUR
ynh0S5sNeb5ghWcEi1B/GSI8tkP7iRumTRDnDAlJsbWa4MXPEOOvHRBlMOza6hr53w74rNj8XO1k
XY472poN5Wq046djmyPrZVPFUh3EzioeVwu/4ZluH7hQxND9hsPQglwRHg9Q8rn3DUDzLWLQQh73
CBfDJqsmwHXA9aOGnT0JFkMRI/OjgOzFqwbkWgg+tr0uN9u+zzuL7mUArxJChq0wph8wfBYX1wD3
HIt9jHDhUfeHBGQ8RmNBphr2CW1DAhMGR2h0hozeNqwsdYZIxBnyahX3NE0KriZprrHE5RR9LfWQ
uIxOOPyaF5lb2qbFypr5sITIPjbn4ypcDDO2kjOb2z6cMmNsUdYe/N6ZMU5BR/PjA9XLz9hQXS1g
DuHkPoqJjmkILrBDXDXvfCnEM2k2SKpomGONzM+u5uZrh0iXCeTHbpcTAWSfM7wo0llYeCiLE5d7
Y2GtfWTOa5SKmhh9dWLAiAdNijNkjFeUmqG8J99KPSZoQZ9wJWo4SRUZTJsILDaHS//9uvLnIcNh
g84yRBgr/zHQWztO8fsTdDwu6/jiOzokBaenR/fudOI/D6d7+ofexDvCZT7Rm6SDt/mO/qXTn/TH
6fnZgNva0Wu00JkL/TrNJQCod9reSLdvsgmOEy90p0f6FW1EcgNtTnVC9m9gndGGh+lvks471FTq
LZyRdOX88QcxIcOSCmVuZHN0cmVhbQplbmRvYmoKNDgxIDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEgNDYzIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMSA0
NjQgMCBSL0dzMiA0NjUgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBl
IDEvQkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0v
TGVuZ3RoIDg0Mj4+c3RyZWFtCngB7VY9b9wwDN31KzgmQxR9WvIaoAjQLT0DHYpOhyYZ7gokGfr3
+0hJtINLe+nc3AE29URS1NOTrCe6oydy+E8+UJkDPf+gr/STPP6Onh+kz9GXW3azJUv7Sqzsop1z
pVQnm9xs9kdKVKk9D7CzLbOrWY0o/Yn2FBBFB4rOBjf7jEYMq3sMpsIJUN08BAiOwwKF0CM1RUic
FU/Jrq1QjWBe+g4t44G8Z1duyqtXGrmFPCM5TId88uKH6cAj3YC3QL/OkkIgpZJ3YAXV4c1D+kRH
w81WAUpDbyS8D7RD4uvbF08PL4iI1iWMGVFQRRCFudiUJkUOA8Eki/gAGVGKPNI9xQrCQHMC5ZLK
R28rhhwIOGmIiTn3VCNIAc7kMW1UGLjCE03M0aY6UyxVJWEd/zwVO+MHBUEgJxjkMrC2FqCnGROK
7pFQxTDbKmtLpbQ6r4pCKihGh2cdGW1te7a2qM3PMjKvC/q6LMKQLS9M6+fFHHbXX+8RTb5l73m5
NUZ06Xuyps4RJBpdG0qKxipxWt9AjNYPDQ96FXsPsqcudfOG1F+vdVN6I0wWGZxoS1TfJ2HaVlin
hI3QlmPsg9Fqu4H19qEz3js4yjaaaefcoHHbs7U/dKZb+IzO5ENoJ3zh9IHPn3fVTj6ZOLVD8TgQ
itNkY60TgGKLhxGndgZ7N3GMtrEGLtvsZoWMd6m7aJIBtHE4ZiDJ+oLYTZIoB3QfB7W1NsdoKcNF
ykcpmmQAYxw+03XKRix87dc5jHnj6+B8Aj+xwCoTDsVQTqAdIv8HxlbuT/nJ7oQfhXaUcQK7irtQ
aUt0HIhJJTVFZV+tr6A4lZY944RsMWPVss92LhVXJ3XJ3aUlMeyxHWePcQYSmqI2Sbwoah2ntTmm
lYLihssoX5MMYKiQFbVm0llWZ2fcBpEJd5FcAgSUaxIMs1Bsh4tVLM5mzD9MXWC+8MWULx/9WhpF
huKDD5no0mcjPnyblavrzQIxSgMv1i02IZIuR7peFs603NM3uvCXhAttoIs4jKtwab7T8pk+LevW
aBaOBJSX5vPlYcn/rbyc3lte/Ft5Gfc/5hmc4jBgnv/M4iv+m+872cSdvw1SQxvkHKvm4gpED1bv
fgNu4XyICmVuZHN0cmVhbQplbmRvYmoKNDgyIDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
L1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEgNDYzIDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUv
Rm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEyLjAwMCA3OTIuMDAwXS9NYXRyaXhb
MSAwIDAgMSAwIDBdL0xlbmd0aCA0NjE+PnN0cmVhbQp4AY1UPY8UMQzt8ytc3hUXYieTj/akExLd
cSNRIKoRC8Uu0l3D3+dNEnsHFglmpN3kzbPz/BG/0jO9UsCbWag0obev9Il+EOMN9Patfwv08f1O
82Xp+4e+kpR84URSxafQ3Hah5AMeOPINT2n0F+hsrMWXFmoUGosSKU47V6cjBWjDMX9iZ4rBS2hc
zJCiTJY6d4aYqO3KMuyWdYO4gx23rrQSNOiJIl0MolBVMuTXq3ZF4MviUey/kI1Y86B27kwKRTZZ
zDMRSoNUpR0gS71iTmto4ShgMW9WQYNuOBNwxtjoOz2i24R+/rOVCK2kWkeiS3OXa34UO4TEmuoD
zbBr5DwKXndvcSZIMXh7gcB+IXxGp9sProEszdfYSHLzUhMaeyJOSvCx1gyg+pYiFoU7R5YybOYe
NV+yLzHhzhhlmZThxMkygXnObqNI9VwabM1JLr+fM/e7zZDixCgq35woMOLZy3M6hNyDx623GIYe
5A09FjghP1IXnzMu3xnh3GIvKPVO4Z0ieRKwxoQ5Ebs5XyJIeZLQNN0zL4O0z6U+hB5X4rHBH05u
YVisF3q3rruv9USf6Y7vCbNJ6C7p4gHQF1o/0NNKz78AFcH7CAplbmRzdHJlYW0KZW5kb2JqCjQ4
MyAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxIDQ2
MyAwIFI+Pi9FeHRHU3RhdGU8PC9HczEgNDY0IDAgUi9HczIgNDY1IDAgUj4+Pj4vVHlwZS9YT2Jq
ZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlwZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEyLjAwMCA3OTIu
MDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBdL0xlbmd0aCA0Nzg+PnN0cmVhbQp4AYVUsW7dMAzc9RU3
pkMUkZIleQ1QBOiWxkCHopORlwx+AZIM/f2eZEtyptqATZ5IHkVSescj3uH4RlGkWfHxjF94g/B1
+HjB3cOn4OUT6tVGHxFTtJqD4Arvgo0hdchsA5plt9qG44BecamcDj8fCoEWAqZh01Tx2yppjNZL
RpJgg5vFrFcEJDvzSUr+k7JRmWyaXdYmTAG+2eYhrtBs+kLJ2CqDT8PC6whFuROuOGsn2ZxkVCuZ
d2YwvkK1Uujg0iMB5sL6HLY1s66dV87yCpakW23g1qSTifQlNuOL3V4dFqX7UmyJBfSMV1ayK0M0
Q+QWX3HPwVH8/X/XwK5lHPUoXWP5u1ZylLb/sjS0unTUvnh5SNM2PJG9Dq6Nk3H8cHb44bhqFhuC
R3LHAJaoDVLrc44EnJ1CijTy+5RqmouX6QB7kbL1PnPGhlE6Qrc4qQEHV/FqkLOS5sn0MHGev3Ch
A6XvR0IdGznvcdommGHnqqeo770WgMfp2Mq5ABwQJ4H1SWysJJ5dnsq0Y+aEPbGjSbKNxUTj4SSp
3AmXcSOwuIyzG4VmxOI/m3aq2Yf7BVKuFVd+ZObUVY/lirtlKbfLcsFv3Mg38LQrbqYm3BL6Y5Yf
+L7g8R/GEO5tCmVuZHN0cmVhbQplbmRvYmoKNDg0IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlL1Jlc291cmNlczw8L0ZvbnQ8PC9UVDEgNDYzIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMSA0NjQg
MCBSL0dzMiA0NjUgMCBSPj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEv
QkJveFswLjAwMCAwLjAwMCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVu
Z3RoIDgzMz4+c3RyZWFtCngBjVY9bxsxDN31Kzimg5XTt7QGKAJ0S2OgQ9HJaJLBLpBk6N/v40ki
zw7SxAZs3TuSeiQfdfdMd/RMC77ZeSrN08tv+kF/yOG70MsjXd++Onp8JR+araFQztH6Gh2dKDhn
a6wCmaNCpXWrozoq9EQP654Lfb/lDTxvABq2pBXfrStfgk2uUVm8jUtz5nCiaBd8nKNiGz7Fg8Zb
7KhYsqUt1SfqixwpDE9TZ6yJ0IH8AMWKkNNiPbbPigXfXUdQn4wgwutAb7FPIGbj51qnyhzmjt6v
ZLyy8oO+cp8IYkk+E/sUciA36zD90FutlxNeUMDaEHRZMLHbYFL9iRnpmmQkiOR90D4K9sZKI4nN
gZ7oBsr29PdjWRFkNSmbUXGWlZROsE0J3Ex3YyeY2hk39MDxwiiVYEe6B8k5YDFWmyHoHKG3PmAJ
IWP1TjB0QbGU5oiJq0I8Yg7pvztdaUEKCcNbqk7XHKvAY6UXmKcp9TwWKcxxCFR1yYozozZBZyep
RfAaCutRn4DZ215t1pitCyvpM88FiX7GnCbVoq+6XplN9YGl3tmuWfl6B43EiSbCxrEzA/A4yAXy
7PpGUaYBKibEIgljKFovdGl0iUL8R7yXXVvFS0Oh3DWUX66Yo4iSb+nVemurTbpQ5fpYsDmZBT84
mfGDh4Gv0GiMlOs43jnqgNpiQ60ZQLElYpGb6wL1NbOXEYB7kWwKDZHUKPbQGmcAcy/2mlC1rrRk
NAw2XYdm7AWGA2CvSWhiwhncOQ5M1iSM5MVNwDNKcl9XeFhpeCkABLK4iPqUpWCAq4McfOmY2WD3
GN1mlxrwvByTe9pAuVcv4eR1taB6eSSQ0Bl4GQEO8Eq2lZq2RmmEljgTGHt1r7597NXbhAm9emMv
xB0AewkhMZpp9DgzCTCUvbh6GkzTrYttNaHtBYdcwmmH0UFTLzBzj6ObS+e4nD6PArvCbyd8ro13
kwAj7iAb4bmwdsFBqGzE7zT8AmNu9uT6Bf7QJee7x/5E1/s9x9o/0E+6cl8I7x2ervJc7AD9ov03
+rpfpXA+C6ninFtzyQ0vLsjlfaJnOXZb5WvO+NI5X4zOKE7sm3xE21ztvNK++wewNPtNCmVuZHN0
cmVhbQplbmRvYmoKNDg1IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL1Jlc291cmNlczw8
L0ZvbnQ8PC9UVDEgNDYzIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMSA0NjQgMCBSL0dzMiA0NjUgMCBS
Pj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAw
MCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDExNjM+PnN0cmVh
bQp4AY1Xu24cORDM+RUdyoHGwzcnNXAQ4MzWAhccLlqc7UBrwHZwv+9qkt1N7Vq2tIB2WNtsFpvF
IucbfaBvtONTfKB6BPr+H/1NX8njs9P3z/T24Yenzz8oJb+l6imXtoWWPF0o7wWPBrkng1ocUU/W
0aAv9KmPudPHBx4g8ACgsdXc8fv+lAp/eSoYJu2Hd+cLpW3HXzyobgf+agGNWwyDSlze6rG3cNB4
wATj7OmaxAhCZwoDTBpFTxT3LWD4w7AYetc0k4bDKaK8znSLvQJxSz9/dKqNOciIIXQymIawCoN+
M+6CIJfOR7BXIWfyUgfph7W1ennl5f2shMSBq8YtmFZfMKcrpDNSROd9tnVU7CbKMmnMmb7QOyg7
0P9/lhVBVkLZjYp3WWnpFFum5qXoFyuoYhbn/NBDg0wxc9ZuIsWe6BEk/a9IhgbtB0qhSx8U5yy9
n1yRR5S/YqJ8YKPkucyHkmYx9ziVj5hRzD2a8hdMlV8sburQsovyF16q4AXTfqPSYH+DmPI9hd00
j9bQfBbNFwpJyo5f08p++cUtzyNqqrr3kUVCFWLAaFPJ178hB1ytm0hJnHGUDL2UlSE7mKytl56h
T/eiPm+Wfq44hvQ762iUsLdsEs6zIOw3pj0DEbnor7eG8sTaS4UyG6qb2LPdhY68NRwHE0AmAbDD
EAFAuijAls5KftHN+7GBJUyBzdy8fM/i5VUVvWKiaGBjGdTLCyg/9/K9KLJqQqLAe7rm4u+qQ8lu
ip5eXpFLoxR7BbIqWr1JvVwVpF4OUYut6EIKYl6Ofi9GmQA0Rr3c+qmXc71uvNziVEKI03y6G3Dg
TB7Tm7BCV14OROctO2PFxv5YEMu09PuNlz8XlTn5Xn7h5J5unBwTU9ded48UWPYQ8qlrq5NjJ4m7
j/3Ur1JbwR1G/+ECFXjzpEwJI/HmuThD0hZbQ3GPtB3pgM/63GPCEWef0cZBfoStJvimhXgOcclr
kg7oONxHkLD5ekBelsRfjdPbLDKjIiFCX5MIMObDhy2uczrl/vTxAbOUOcx5s9Z2n1CfhM3jW/AQ
WID3XGOPhKsibpgxdLuBIc02dm+vVwtb9ilXikjJNW24myJ+ts6E0zPuOWGbT6geI2AkcLM58mN7
S7uNOll30FvyzxbyK4EBOSEsCVb+yM8VmhznmBerRoxxi97XpRpuwR4pVVQcd5KMioINX70Nmquf
KiTUoOcMufWgVFH/WpwC2IEVIqo4KRTDjX6m1jwCzLG4l0BdAZCcpenlx51hjIW8E+BeSkiDZBoj
D0I6AIY6FhfKkul0M1bkaDnhXYCT9VrlxgM8w9wjrnwJS15YXLg7DWkhHG81fD7Nd5rYFTiC4EFd
fz6PIH4X4hcf9+7E5y1/8MWaLSPt6UJvTyfOdfpE/9Cdf0N4Xwl0d8jDfXhD/9LpPf116vvC2eZg
P4AoA85XsPodQ1bACHrG0MmbEzJdMYyxjh6vYBjB0BnDZfsib4aaZ2VxC+Vqv0z02SqMWOPretml
old8W5FBcPLyIH+i7e7uUWsp7Iefkd3rGAplbmRzdHJlYW0KZW5kb2JqCjQ4NiAwIG9iago8PCAv
RmlsdGVyIC9GbGF0ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFI+Pj4+L1R5
cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vRm9ybVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDYxMi4w
MDAgNzkyLjAwMF0vTWF0cml4WzEgMCAwIDEgMCAwXS9MZW5ndGggNDU2Pj5zdHJlYW0KeAGNlLtO
7DAQhns/xV9CgfGME19apKMjnQ6IRIGoIpYtdpGg4fXP2LHHQSBBIu06X/65euI33OINTu5AjJgZ
7894wCtIbof3l/rO4e5vkdk41+erukrZppQRsrOTy2TWMybryhUQbZYrenzHTkM325hd4hnbImT4
ZmnS5isqwQreIA12gneWJfw0mOdqSs0pz0aJ5rXiK/sFMTs7yluqkBx6ROaaDI+suBU0cu9EfGk9
nf2KrKDeh25nThj9Is2LqHWi6yRX1e2Ydr8zozupFSnRutexj8q+qIYn1aw44kYGj/Hx41RBpqpn
bFrDy1Rp55TtKqPe851O2dAZauNQ/PnWKWUn3EuO9fOwQeZef+SjIDdbJyMXYrScJjLnHUrWpxQE
TJZIFiHmKhIiQapVA7KRTjbL5eJpY6aQTaR+OthiyWcwNMFSzPPezfwplgmxgWKlCamol6F+OtBY
Rxxq7WY0QA6DUUoTnuFrmtKpkNgmnmTUOJZSPqF72fUi8CLg0F5TNHLsHMah40XjN40MVHVBczma
JJd6yx7cLJJFfZC/EjVWg+VsrpelHF/LAY+44EvIccW4cH1xRZd4wvIPfxbc/gcqTf3ICmVuZHN0
cmVhbQplbmRvYmoKNDg3IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL1Jlc291cmNlczw8
L0ZvbnQ8PC9UVDEgNDYzIDAgUj4+L0V4dEdTdGF0ZTw8L0dzMSA0NjQgMCBSL0dzMiA0NjUgMCBS
Pj4+Pi9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0Zvcm1UeXBlIDEvQkJveFswLjAwMCAwLjAw
MCA2MTIuMDAwIDc5Mi4wMDBdL01hdHJpeFsxIDAgMCAxIDAgMF0vTGVuZ3RoIDE0MzY+PnN0cmVh
bQp4AZVYO48cNwzu9StYOoVlvTXTGggMpHNugRRBqkXOLnYD2C7y9/NRIqnZe3mze9gRORRJkR8p
6b7RZ/pGAd8WE/U90fe/6Q/6hyK+gb5/oQ+ffkT68oPq7rfQqcTk01boStvmW4zKcBdjpD4kLjbF
GF/pcdgK9PsnVpxYMcz7Xgf//Ri16AMslBp8Cbs7X6nQ5gN/MuweiAuI6vsetlpl0DKVKZtoW8Mz
pc3Ziwvl4FPYI6yocE5LFcZm8ExH6jB2hzENqRQImhMlhAjK67KSCuwTftkPfh5/zy4OHiLIsy+E
qEKEyfGYK8TCQGGmKscwQN942I8701f6iKQm+vdnkSVEdqMYEFO4gydbREgmWTijBM9AZn5e6AF6
40t6a9793uBd3jhlrHjGtaxAuhd40GlykscmWdirpiZLLqBLkpWxyjQTZAnM0CVJ3U0O4RzpNZS0
xdEEQ5dJKe8uzmGeJH7acpYh82ckXDzB+OD9kze2qiEVZY0OFJIxFSQ4ByqiSPBB4m/eDWqGEhEE
ZfFVr6QKEM0JH9UKasnejt/E1JPcc7map4It8XQiTO0J0PTdzSoEdfMdV8cb2Mul+poj5ZJusQcD
3e/49M5dYyiLxRlPsQe5GbC0aw/plOfMJmuBjHEse8kZz7AHgOlMQZW2FWg3jvlgGErLr+dSzzlr
HkWUHj4cI5VTBAIqs801lLBICcKQfeWs9SyeSjmTUs6SOaMpzKAunqKU4xXNL8FqXNoOcmYB+8Vo
5a0vfZo17XraApBHWzdaoOR2xeIejqHavdApX0CVLLbQDHhvo1EO08l43DTNG40wN1SRi8o7yk04
zE6rcsKDvtl1eYvGblw6MgrTOeI5tuG6J99Q68rhbVc50XfIAOhzlsvIxOTwThybBzD2TRSlLftQ
sMsI5wKvlbPLNJkySLg2tGBDsMPCs708RV9Qf2lbxalVuXNVGgFtWofob4IEVPWsph1bkQ0ZsIuy
0rMS3XlnnhowwJ+UG/alG+r45jgeUgov+IV30jyzFhTariaSd3IdD8+MOr45jLHhoKOZFIBwWyu3
rw5yFhTlObgxTwM49Czw85lA3X9laNh/aTe/zdlo6IpvzhmWIhWwA1o4Iujq57lBqfHqiGyKt5ge
B0/fcPKzHwC8Nz474SQxD5HXxdh83rZGvfocc8VJFIcOlIDrRWYMEjnu2cdQgGSRoD6CNE4nU4XS
0wZmDIYrufnYd4ByaaijOszGJDFjeSES6vdU4Z6sgwOOs6+tdIxwCDbFuly0zRALolJK4AN3AwBx
fr7ljf0QzrYAaLa57ispA8U+lpkBmNAQqdTjiFQuc8YkuRqyL3vnmhcWdpCh01QILTbGtgMBl9o2
I7U0tLkCtSEkZpgXKqF+TxVO3TYbHClTY4vTuCT4FnKNiIHFRXmI1QPVWnF/AITSzMz1wGkzMrUW
H/eMIMvVpFZ0ujFHIOFqxf61FRygTISvJazWlChDQcFzpgjUM45UiSsoWW7Xy86kz+CYKyqi7psS
ZQw744T/eNBkq9wCPK7T454bnwjqVp7xHgAUhl9Dm7ToTg4AYdhBj28BGw0AyZ7niuteXTQntnss
EK+miMsVmR0ipkQYYofnKEfxY0okzGIHvmlxZtw8pysqos5iVx1hlvWgUWsLGBCaHh9WWTVCvLvn
0o8BWqwH3J24+DKKD9UlpRc7bsYOm6bei9FeShQhHDdGzeLKh+uz3nHRzT6e+F7FXzy4pmGX1Z6u
7sPpxLpOj/QnvUu/EO6+id5FHbzH6C86/Ua/np62DeidZV+5DA4eumH84CHXxRS618OEhsQz3OlK
P/OwvOVhxdnB0JgYja87ekApDiND9k5/tyZG0Lh44j1uI9avB9bczqX4DRC5w2uGzhD9n07ngn+p
lH6Pz3n5/Pk/N3CBfAplbmRzdHJlYW0KZW5kb2JqCjQ4OCAwIG9iago8PCAvRmlsdGVyIC9GbGF0
ZURlY29kZS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFI+Pi9FeHRHU3RhdGU8PC9HczEg
NDY0IDAgUi9HczIgNDY1IDAgUj4+Pj4vVHlwZS9YT2JqZWN0L1N1YnR5cGUvRm9ybS9Gb3JtVHlw
ZSAxL0JCb3hbMC4wMDAgMC4wMDAgNjEyLjAwMCA3OTIuMDAwXS9NYXRyaXhbMSAwIDAgMSAwIDBd
L0xlbmd0aCA3Nzk+PnN0cmVhbQp4AZVWuW5bMRDs+RVbxoVpLq9HtgYCA+kcC0gRuBJiu5AC2C7y
+xleS0rKKQE2OW8vzs5b6pXu6ZUMvpEtbdnS2zf6Qt+J8TX09kw3d+9Mz+/E1uvIiUK22ibPdCTe
gjY2CKQOAkWzNStA3XGBXuip5jT0+a4ksCUBytBbqPh1XbGLOuaNojPam8xqfyRPm874wPBkc8CT
oLdskkWJdRE8uWGb5nJPNil5cCAEtwgepoWzMxTWknBP625Zq2VN1YpzzZwI8S1ZMIYUduayrYCE
WkjWtTLZrU/W9Z7QBLE6EI7GkoxZHqEZJ3ZCivj6WZgnqXgPJmUzl2ouccQXuoVwLP34e9cIXUvU
+KhdA/2yKzXy4OJY2JBdfdS4T+i1ddCWnPMB2blkV+eaKVxndD74opmSXCQTV8lEtEYkk3vDoxvK
iJS0wYeHLCJObS8wkY9oLaLhzVN1PWZBhpRKrGE1sd8jqkvwxE96VCTWaz0XGjo8yB21K0GW8wg2
rC79JlIE2E8ofmjWoGsV4yhrFDHNFs9GE6gX7L+Eucq1C1P9WpiX0hhFdz0WgQgDAyvvUT+HaHMx
E2wxGzotqh2uHUO0ot06dHXEtJM/GLUcWCdrMYr78MSIFShpl1IEYHS2McIo1wmr2Ofu1QCIi33S
G29ejIBs3WjEEaDnKl7VRkWOmrcc1jChTfOZqwPwmgUNI6m5xVHzEJKr3gBy9soCroIZXgjAcDPs
wVS0iGZMBIN2O8PwLj9gcmzaM942z6VY9HIitpOHGyVYh3fUu2Kj2IXuU/eFOue1Y4/3uZkAcN1E
ggyg5Sk+FVHOm0IcJqUEcbUnAHqevi8+oxQxGeW3IKhtACNPIU0iySmFIQchmIxBuTA0sKo7KMsG
HUEigcxGK2/lxkfccd+7ynQz8sMoNKPyO8EoKPV2R1w35R96g0u0euyOdLPblVi7J/pKH+wV4S63
y+Kar+iRdp/o466KHwN8vAaIiysS0sVPDPfHCsupmtFJhWr8qris0AXXPP6hQhT9qFqF9z8BtgXS
ZwplbmRzdHJlYW0KZW5kb2JqCjQ4OSAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9SZXNv
dXJjZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFI+Pj4+L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0v
Rm9ybVR5cGUgMS9CQm94WzAuMDAwIDAuMDAwIDYxMi4wMDAgNzkyLjAwMF0vTWF0cml4WzEgMCAw
IDEgMCAwXS9MZW5ndGggMzkyPj5zdHJlYW0KeAGFU7FOBCEQ7fmKV2pxCAMsbHuJMbHT28TCWBnP
K/ZM7hp/3zew7F20MCQzzOPxGGbghCec4DgGL8ij4PyBF3zBczicP+uaw/OD0mxONd7UmQyDDb4g
jsVGN5r3IyIKmp05TzaPrqSria5HvEPUzQjOiht9YhDkQg9iCkmEypWpgDjdJhBZdq4SElWVtqqv
kRRTMeZJPzfFGd73sKJrpoyo08U5ddSrTo1ZgAO2rJvg+9+igEUp8I5VYXb0moGPOBoNW0JMjasB
9DN2FK4tsQNrvRo2Qoq3MQbEkqwUSnTExMJGlDIQcDbFPJCTK0fyuOxpMWuTiw2B2y+UvFCaiJHc
gXaO7ulItD6PLMJFJPw6p8Xag5YKk1soa/pdZAX6OQfsr65cL893d7lD5ZkjgrfOR9YnucCEtIqS
/0A7Nig5sQMJMizLPusD37fnbVjVUEUqJ3ZOahz9FfULbCftnA46PTVX0emIu2nSjzLtzStu5Bb8
GIKb1Ccbf4s3TI+4n/D0AxJErSAKZW5kc3RyZWFtCmVuZG9iago0OTAgMCBvYmoKPDwgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDExNDY+PnN0cmVhbQp4AdVXy47cRBTd11dcZlWWaONXlbuz
QQIFRBaRJrLEArEgnZkQMpMQewDxs+FXuHbVOX61u3sbRUrXVN3nuU9/klv5JNnwr30rzkldFuKy
QnJp7+S+v6my6cV3jWRplilFc5S8Gjj1Z+Dcm+ZRvmmaXLmbe7EvPz7ddYk0fyiVUj9vRLnzoE1/
nCvTut6XqrOWOee7xCiXMmSpd5P/1EZfpM7nrpA6K6XI0sqVuZpbB3t71Zn0ZCXJKsn3IHNmcIse
zwzyjjz7uUG/iM0T2WVpIXanp1+leWGCP/sBgr0cFJa8Umvr3G0zZ5Aiibql0h5/CzfGth3uChCR
msorPIGWLwe8PEvMIJlSyPN11Km8eZ3WYpt48T14H3CgVX/hprvD6UPwvw/PxGmNQZ6lGhQNQOpC
NGbojrSZEsxTRfG9eQn5VPQUzfsHLx9xaN/D/58TE3yZvL0DmVoaYvYWB7D9GEW3ZIuOGvsnaG9A
vNvhNIJAI/H0Cmw/EFQTlIPi+RuQ0EB4SCtaEOOFZuFiJKWUGCyxDB+kdLwh8ZskmkUPukleDJlD
BCiY+JEpaDCWWaa52lfFhaL13mtynCpbMy9b72slnBRuyKgLhevr/ERqsUZ2ai2M1Nxcla6v96p0
2orMtPJZjoAXxSvXFK+xFeIPfho2Kd7QFggreSZB6hPeXC5esVcWr6+18c3KN3TJ0+XrfTWDSBQi
1i6zkzUrsR0hf38HCEwuvACVn2IB4e8JR0zdvxdpKBYySEtDiAFzONIYMkHRSgiLhq35NaznU2Ay
FkKoeDSyTcRVfb9No2cbv0Nq6vwsTJifXw2zczk22Ue9DsGQq/247gfuJYYqW7VdgM1WCT9WYCww
N5YX5GWDmyTr0FEY66X0NgqZSAMJESb4R2JLjR3MbBnn41PMONq3aRaYz2ZNzDnSLH1b28kbyIdL
H9B76QgovkVegfQFSSiNTgcaY29jOtF1etySiVdE8T9K5mE9E66HjAqieWMlXHZB7Cv4TTEcPg8A
64wv4zwmOEAUQMaKNZY5eHy/GUJKATeZ9CJODrPRFov1znjTJFL6dK/zgf7xsNN0jrlFtafTOYwE
wsCwkU03lbDz3ceMoNkd0/YMuyYfpmK/b6soLN3TfdsdqpODe7Fvu8NsbF+1b7vDYTVSOBt3ZTBv
a9/2md9m3hzZX/i+7fXj59p92x1OLUXYgJmPzCbetEyjB5QpWg+/GJiMj4/koyTUYvcs5CUHHOdV
/Mw7XVKuPnAdu3LEuX5t3BxyqOrPtJB9Dk8wmUsC64YNtGOLosdHUn0+EjSIim/GEiuqh9bJrvAv
7rhBUQujwNa4oh0bP7Tjl1KoPHTBsV+fVRg/pKDwdKMKTYjjaGx6hHnZeY/0ifZF/LRAoYyI0nTK
A8mSW2xHILEPEH4w0dC1XMpr6SntWlOnse2qYDTSyedFVbpUP4sL0U/j5bfFmflHc1uEEHZzk6WV
XCx4M9YuuPm0Ao9LbYTMWDQH2sADmdeWM0ykucOA0w0YwNz+DxrOkE4KZW5kc3RyZWFtCmVuZG9i
ago0OTEgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDUwMzE+PnN0cmVhbQp4
AeWc2W4cxxWG7/sp2rxRMyDHM8NZyABBoNiyw8DyEjFwgNgXNiPZjkwvM44svazzKjk9df7v1FT1
LKQvHCAxEI66qs7yn7Wqlx/bT9of2/Hmv9VX7XzeLi+m7Xw8bSft6nn7or8yG+cX/nTTjkfjsc24
uW0ns81K+7NZednc3LVv39xMbPXNi7b78Pufnq9P25t/2Syb/eSm3V6d+E6M/nwyms8XC+O+bJ1G
k2h8880WgfFoMTcB9H8m82I6mi8m82m7HF+00/FoNr+YmPjLJH8vyrjpp10wbdZOLjVtnqaBgAlo
8vT/2Z/FnDWX22L9o+0mp+35eDRtu/PZaft5e/MX1+9ys/qyvTKYJjMTdDmZa3HCJRY33VhU2lNT
y6jdfaErq7WuTXWJ2TA33kmK9rTZrGfkSiO/d8pQYc2ZjxifyXK0bLsbv/DOaZOofisiSPVvXVk/
16/vQv9MabPBZDwyo5gBRvNm401b6MbcsU2oIHryGga3MP1pI2DTmVMkAV8xSWA9Y/JdhuUbR2Fj
KHPR3sF7F33rtDH3TJ4Zhke0xeVlKVr3h+J/G//sSbrHvrW5sJvkclGSNIe4DlOYGZvuFwM1afhP
/ZCCCYO2+1oDgIHDrH/Q2HNZ8pZZv9xiTJFi7Hutg724GtDuE6s3uvazZmME/IUf1dyVM2s6cddf
qMA8c9CNc+9k2HQVw7XIrnCIW13iygqewHzmgSTBb6HMXPBbnbbzWR84paA+o+lQBfqiW1NbA6zk
xByKbgSv6UJvhebIWc5uutGWv5X+13Zf7jYtzuIcm64OQimAjyKKRgSD/u0zmy704JfNzRLsUJgu
ZlVMNR08w8riugbZu5zLxsnC4FhRPtt29wseAjK09CBCNo1Islskw9Y4YOFDzYCVRCZSH4tQtHTW
n9zjMVYtwldyB+aURMCq9LW2k0zorAsv3AmRjPhOM5ruRFMQaRWagcuJCApMpMRXv1P2QpPKNrAQ
tTDFKjzIckgqtJp1rh+EDIaTOJoBAEhufugOoTlagwos0sjOmWRom3EgXubWNFUVl6KxQirxBJvA
BB0kT150vHap6Fg9e1DRwXwY64WjDypMWSEQaZREuKqnux80UUal63ntc/gldFaElWfSzxvrALca
i77v3d0FzKLniV4kLWmG26TFtOpFrHH4UJGJiUxYK0rzvihte6oUxLWIO5kQGgRxNiURw0mYiwVY
JEYiq3/D+At5vUY087ooSxpnZc3spWojQzgLAqEFPzAfq3xy05EhJBRG1wUincWSUzMcnKaTL2kA
AWwg9dyaAZ6rkphzaToUi3SEsAgZnol04IDTSxyLdA/VKmkhaexDCAMoKxliHxG+gx5hKbVYjCv5
lKz2iwxzUUFUQjwBCAK3JEIAYww6OMDb7nIgsTLmkT6boXZjMtTCH1a56UqV22h3pDKiIiE/wuxr
23154VifFTGDlTAKKN5ySdy0i8uwvwM1YQ00WgWKjGiqgpEQwU5aK3PVDoKneAI3hwcvyKikWCvG
NQAaBRSWAq/a7nGSq6EHgQeLwZtqUQIKfCWxNXCCQ60VwgmADJqi9kdrwyLE1OroThlyDZqu99zt
fRICokPtAmAMEpaBUrLHE9BP1jNOESPZkUnsnMdZS552xlat5CbIhRISHUHxMbF0GUzNwEn0WIWg
LBdhYEfNiCHNYSgiTUOghMSg7cyzzZ7EirlSAg6WpDzzlu5GcUQFvEHCiP5uGF1cAwtEguN6DV7w
oJCIB5I696aDElhIDnSpJIXKbXSOVqHc8feIQaC+ObVTwX6PPYrgzk+rsg4OMaQDqRAx6A0legZh
EY0neAyyQOb2JdfQgfxxkjVe+4NkfjXUh8tXwuGlDwq+RpI7jIFEzDoLxDZp4RvhTlwDUOxwBYz+
Qg1XSdJk++v6XAXxEIofWADBKWWrO8AUdySFYiFGG2eBgiI7DEL42OazXiygrAsIwTaINTKEphIS
GoDha9RzzbNDy6hholOjc0IoVTyUnTPX9VQiKcKsLEaFItDjGA5y6F+vYacNB1ZhRVZJGvkzQEcm
QkmbeyBULvtT5K37C1ZPEAOZhShySYpIhF6jQ3OMtr/VTbW1Imx9n2cOrCghkKp0hoG+z+c+tIqs
R0WwXx/a/SEcBrOtVNJR8qMrNUkjmgkRDTzqSUza2KtU1icLDezYsQS+svdQtJe26Xa3RG20RDRm
mMIB27hd2rg36Y7A3o37fBG78HLj3t/eGtgu2J0tXPfYJbOse+Ku0fsb82StOpYDtzjpwBllqnfU
cJAT7iwruutCSXZc77xhsh+eC6to22G6+4YJ92D2k7SbegXJ6obJQGeJZ6Kau3dT3GxpO3yDqeSl
AJbyjmtypshsQS0QiR/IaAZZ2EeysGfuHluiHKxZRaieFQmhEgo/QH+kcsGb6sYGaxTWUqiijkBp
RhO5GgBpBQ4ttnRC2OKyUUV/1eFidqwS+4oaVt1Flb5vQAL0tPetF69vo7+iqwSg0lBu3MwljOmB
6jiOrOR33y1GAPpLhTlOHL5F8ybNZFkUXN1tSxiFc7d/Y64ouzIydG1HUBbObUZmdhwd1yRG0e7b
lNjMkOVyIBbv25EHRTkTYk6+6bCicBGNWmlE0tTcOYpdxQAwr1ASngguion5vr1OOC8s+AEDJP1K
0G8zaGOTp4G/qmy859BRR+YamYnYLK54R3qOJm6lrPMZ7MmLg4dacslVWmxzn2l/lMyuohAPRAlw
8QPhwQ0LuWBN93qUcMn6CH+yYG9Vm11GhU9NQWMPI+xfshzaLd64WXBLCoAcVoiBJZsq1CImyzVk
W6ZqBtTirAQTk9jJN54ksxNQ1gOp5MSyyFnPRS4mH4rodl9Ee5Bib4kSuq1J82hZIeEYDdxCQEeA
jmdaBsMg9eGqKOgPIqhN+kY+hhDUfzQddsGaUI49mXSHDpPRQnIFPExmDlcoeMgDzGcb392czh6I
3EXcLovIhTK6a2s88qA49BchCXl+4GG1+gOgYZi4z8m6R/1OzLZE8hcB/Fkk250PklRHzE10q+AJ
5hnLtAsTy89OxTSO4WhfNQkw0A96Ws0F/JjD2OgKWL77uRA84LWYj9xiiVP06HBESdbyg6HkT/HE
QSI+VDXDc6Ua2tdDUVrBjEh6+jfVvGc3rsLb/vfZnzX0kV9h7gdppOne1RQt+p0umFwHYmKW9Xyc
sAM+wBkhvxmCb/MDCJldn82+DgLbRkryHX/Pe3YR5ffIffBsGlUy4v56A2fc1IncTJfIDzSkFMng
gGAtquf/O9xablnDCeWABUr+Y2iHjo9CMcNVj5FJNHFHMA3gpLpwguHIgXekRXSXSw90tboB2HZU
EiQEDZhw/hcPrkT54jCOVqQSIELzs7gXSqZdsRA9gZYEy5D2KQLLmWW3we6nmyBdKgL/KLcge963
x5tEw3bk06GzwWdhP/X84fhkR8nUAKCWGilIAvCXGBGz/iwFtUZQ1nbQiGbiIzGQOncGMBiSYbns
4E83d7Yzd6R/8RMbJIMPanF6yVBaFHkCBwUBggYciVNxzqKp2MohCxpCBbeVk5aMQihphkxiDHlw
q+vpUBhqvYK+7f6DgHtj3NXDcEgExCItmRERBmmGbcW5Eo1unIFofV9F9xe5i/4B7O3zRDvYyJsY
32jGSQEWRIQ47FB/iIvUOlYH6WyAoadeOTuhkUZCiLlxH4hLgQOX6CtEOjtAx2sRWsyAX1zTwFC/
oxnPnrB9P39M84HJYeEmzwoGQ9HhSg7U2I7i6Hhd0OyWoZZKLv0blaD55lGf/Kx9Dn/W9uPBbkBM
f6sMSD8XLUDOL23HaCHCggSUZKoUIXrzKDrg9P0rApXTV5QDIqGIqzAkJSLfMBTZJJdsc6MYKyA8
mU0PYIolM3ShDr9wmHIspIIM7RWRWTpVPLstlp5cs3AsGZn3YDxYoTaz8XHiEXHE6wSMa5BkIc31
qVk7OOTLybdghH1ETX9duExL1oghmFFuVpGIMaEMn518Z4p7PhVXSNL6MVe1bafro4rk+9T7mPf9
r66jCK2g2PeZ6UCwDDz7z0MBGViv0KQCYuBoCCujrUoHZpfwEpUBlpBWaQd0Gh6bZaSKZIZ84hCP
RQAUzCSW5pLaKvBZwgiM2LfIpPgPU0bJZPfsgC/6B809kx255bvInoyOLd9jx3LoNhIw13G8ju6j
f2TSfdvnRfZhIXpHhidLgL2gDsPvOj58+vhD8Xxyowd+tRwXKwg3XWypEFm88K3dYmVTiob1AwmD
00EFBOqhs43lA6w6f0qjJ3//+And0rXH+NMnYGAQ2KNcV0332CTpDwNid1LzD8sFHIgrOJR60Blf
iDMBgo8f6DjsEgfyzeBj+BII0pIMCyI7+BGqBBmThajPzdKYRpi6t8GsoIvEk8waFkAsBMUm4ikl
PZPsaefuL527qliIZXX+md2tB7ZC0H3vRTEVQx3ws7SrRR/Wj4oS9owp/JAOfiFeuiPgSyIEz3tO
nWZ9odD113qbbqkrvPFbWjS8my6VOEF9Oh1JCzkJNxUjXdBMRfijXlhr0GmmMYzNPBBMg0/SJyew
gxy6crkFYksGvBbD8COmFGkwKi3pntSA6JUVnXX9SsddJSWVFnFhhOm/1s5DqpG5WPSdgJcmVAwY
kB9EpZoKNURAxQopO+d2qF5W6qszgB6PP6MSQ/4j2zxKrBPoPjRtrU8e9mDShT+P3hx/Xj0dfDpX
Xq8ED4qoL2XJ7ygN9MShDz3sHdqzIgfRxsFw74lquZxYkgL1vQA2USiAk+IGOBpzlMSzc8t6mZgS
iuAJHRaVTS9T5aUi9pEj9K5C6Skp9uNNP7boC2DK8a+qk59nT5WHRQ+IEAXzpynZU/IKSYI1rCJy
0aQMvZbhsag9QxynoG5kMjxLz+3xxosnjaFDIR0OZE8K9Vlof8qeDj6Iu1vZqELSOti61NmNaVQD
YK06wcHAUUw1hfSlC4EPXkWyhlPpM4nqEF4iG13Veo1H1OJpurwVjhpAEYjUbhDW97iKDo7lK90/
KiNaANUu6PBGV88UZNExQbSIu8kphippw2lDWqlP6DCkR/qyysGYVpENSrsxIDHTiiFaRAtrQtl4
Blx0gIbbcbVPa25u4wNx1D9IXB3ygT4Oy49a6DhYk4uhD3IQR2t7LSUdNQnJj3Ylx6bLkmNaQ+sB
4dVLOhYKXR1ctJdIz5w6YASi/qIN3soa6TAQ4azCdRAU4ctTzCMjGkKS0AlGGB0VABUZPIwMJgbS
E7+glafMMgTE/iNLq3gBmPCDKBQr8JMMo+JNgmfAWHoUosDPiB4Ig+zh+DjuQbr7tYl9tknFXMpA
iM4FGfFacEPzezUsggkjwlNCOKesN8B4AIUZkC+OoCCI43DntmYa1VXso+m2lDn40rlttaQFLHQB
Y4tchBzCA659a8e7FvwUUJldBbFYlcpEWCFElqcxG4i94YyaS0JjgBQ2EPtzkhyAIzwyV/s25mJB
AYWD9SnvQBT073tUxUCClbhERYYFUjjK2T2HX0QG04JmWUIxETPKeEIUEI6nl1kNWEIiSZD5vwbA
DPmxKtBnJtcy0qQuhE9SLqkz6FJqK6nQCSFE9vAr/XYvGiQsCraTz5FVRdxkJxc4XBa5YHVEn5h3
XtpJqE8cpcq/8cl77Iezd3uOPMyf9u/u+IdmyiU7PnMyzV5lKJdYL6Iv/21+5Z//myz7R8WyDwCm
T871NWXc5h8AnCzts373/gTgZHk1EKEz7SvP7dgsC/HqI4CTy/64O399sbHnGDhrG4uOfCEeOYx+
lIM4Zvv6pkMOrYfy/T8D2GSfAfQbJgQlDkjyjFbYwl8I8BWAyaV9dvHoDwFOlvZVyfwLkgbR7maD
9wgVN9KdzEHCQ2yqEvL7UPbOMMqSQUhspJKSZf4KogcbPDkoo7yQcJhT0kv/zvagtU6RXKCCnNWL
MPb6lItFLtFea+ubZujOj4HX75v89fvsO4SQliH2PUtxvUlBkeOEANigMVrxgBcKU/7YmWFX0ZMs
kNPAWbEb0nUKfKUOmDCyxsMoZLhIYvzrnmSDWCpdx6DVS6QwHH4ddbKwr7He9eeg0W+DKAqdwBv8
BSW6Og52w5L1TGaSVu3ZGWEbdos7Oojs5aGogLCEzI8pm2aPyofF6haR9ZXIh11in4dDDiR/Q5fY
PNaDlQat7AniHLkB7RjzCqtouFkuD4gmDcjzjYPXGlI05iS4WVbGLpmVNRKHdGJC9GHR7Pwi22TG
N3554ZpmMpwXDE3O1O3BMxpVaRzAMQkdJCFBxAgsuBJPBfaHOArvfc2QfZL5mFbIPk18328hTyZX
1UZlpvbl3HoUiWfZp26DpoutCv//0QRNL45vgSb2JewtiFprgm68VuHNOA2eRpJRAMYm8XpnpfOQ
c+fMnjLYW2p91Z5S66lELl6Gq66X6oTIWal1WodLbf0R24LP0O0nFAW/4V1i1uaAFlmUgOXKParn
5pPfriQBTw6WfSMBVbCXqWXg9UMBQUo+onr2D1q4WCxbP6x6bhwmO5GQUg+pnr2V2WVnqWbguxtX
tmOrQklQuO/9tj6xp9ZmwVg5g3SIUMdCgjavtYogluFCQ7XWoxtX3A7e7Pk7/E50CWcJ8b9dPrP6
NLuYj+xD9dPWPlZftsbcMAZj1CJncHoqzb1/zXwePCGTv5WQbrIwVFmcDziwJ33fkzoy8IPFteSe
qIZuia2icH/yX5tJy2YKZW5kc3RyZWFtCmVuZG9iago0OTIgMCBvYmoKPDwgL0ZpbHRlciAvRmxh
dGVEZWNvZGUvTGVuZ3RoIDUwMTg+PnN0cmVhbQp4AeWc25LbxhGG7/EUyN4IW6VdESSw5CYXKcc5
MVVObGerchHlIl5LsiyvHZO2bOVh/SwZcPr/ejgDkFg5uUq5ysJipnu6/+nTHMBv60/qb+vF4b/d
q7rv6/VqWfeLZd3Wuxf1y+FNt0hf/OauXlwvFqHH3X3ddgfK8M+BclPdPdTP7u7aQH33sm7+/M13
L/aX9d2XoVfo/bu7+pg6jtsG/t3t9Wo1DL6ujUUVWbx+/fqIweL6pg8C6H9B5pvldX/T9st6vVjV
y8V116/aIP46yh9EqRb10G1Ft65uN+rWx24gEAQM8gz/hX9uemg2x3L9vW66y/pqcb2sm6vVZf2P
+u5Ppt/mQL2pbwNMbRcEXbe9iCMugbiNxFWzEJf6MqgVuD38U292e71b6hW9jT6Ror6sDvS03Iro
l8YZLkj+1FrCOO36el03d/biw8sq6vaVmCDV93qzf6Gnr13/ROkwB+3iOkxKGxTrq4M1HaHrfReh
QwGRZPlCw9h4VSNYHr5R0w5Z1LZ11Q6wfGd/wy2Y1aBi1QTpo65vRIuun6mJgdBe/ETzWoipIcF2
XIBCZLB+IV57LODzQhINfEbRqjFF6xFFUevlbLSQCJB4cwE7IJWQiI/SwczNxOhMJ1HtYFjAnitV
Na+EkKg1EQx5z9wzJGy+FfX3Eguy/YU4ojL0hcga1IaqGtiIySmjhR2Ki2pr3h3+TkKNRyp86Waz
GfGlQiwURxWsn7H/V0ZxhZqAo6CXeCOdBIF0cF+HXF3ukf1rTeMeMmzoXq8AISGzWHDsvVXzg+wD
GjHBqCTEv9TVzRfDCUPHKA2bt4USwqIe8VwNakQJXAzBhN7D+eI6uvfBckJ6HpL7kJ5/ccish6xc
jZnS+gZTGiFJ8qRb300XQv1RERCS3daii6QXUoBACLlPYqCFZxTbXYYyYUhSx3NTN2LLTECiljhg
1dAgCY5yWMwCe6Qi+udC1SEDxWn0Kca6NCZsmJAiQpmlVI2zETUW6SaNFBL+3j3BFKvAgrkHWnRH
nsLD3PJwH6gQvuSsOIHMO7wFuXYMNgMXgeD6+aDPDHnk2SEijoch7J+Z5XlvhLQJqxrIgIo+QAX2
7wL4ZwJwH+rRwgVABNlQiUE0r1LfuiY5xAFRX9BEeOAo+JJxCYAYLUQoqgHggrz2UDVMqfqWhqCW
ElHYyZWkNV1FS88fXVl1Vp+r+FA1e8ifZiUNxGgkYjFjarBatain449BgZxbeD4yuAMuD2L8qDiU
GIToH5hJWEt29L5HVHKisPf4A5+CHNhQXYO/ZxgbLPaMK3XDwiHPJqjhsyFJLvwVvTB2KnRPuTMS
42iWW4Yay+Samxhbz6W2Og6J8QPz2ooUKU2YB2DH2/CHHfOIssRteoshZqCJza1U7/EC8CK0ECnd
XkSF203mq2QhAkNMCZ1Qlzce3zUWgtEZPtJWXVEGdurhscqWIUXSqht3adA7N2TI5QzFw7MiCzFh
QIqk3lmCgS1GAVWujU/Mg5oiFFXDAIilHs99kfIjnOmF/9ibJO4/vxQLD7vIuPP6MzG1Mw6/GCsf
AQvwC+uemu+kQJaoRVfYq2Wi55gBYxeYtNdQtCG2BiAhlF2AvVCRanQoQQ47ClZTJGUtTZiMzFw0
zK9bCvrPWZx4dYzPoR6MLAclgNEHKgn0vJGIyLxTGwwDurHeJrvReZpzSh0Bi/iPuYI7rcZmaphZ
+KkLwZZJ46GYvWklp4UK45x2l/42lJrFvtlLwwqIfl5k8zWFg4Sezx4X2eIkYgNug0QN7PP5pWk/
f73ab3wbcWZa7m88k3ta3ppWT4Z/27osdPfIiy72kNRmZGfZCx4MfBjZmBVHsOjroRkngPyeJ4UY
jWlGGwpjvVEPzCNvIFHAdJ8E8MOWKZrARFwhFleYoGLWkoRoMXG7wI8AnHQEY2TAHzUCHsvY8FMX
uNAltrjVoxEzIVrYAwdT7kULQfXX7s1+fHF4Ss8w+lXIgKOnGOFUYfeq4hSjX4WziUefY/SrW48Y
8YTl6CSjcyHDVn1xktF3Y1Vsq722hXa+hJAnw8ecZfgG/3/hLKNqPpRU+A0Th1Udrb8UdNnV6rtw
djT7NKMPB2j5mmVrEUXAyNK/EHSlHbIf631tbxLx1SKTfYcroJgGhAb/oQtN4POVpKKeKPt4xVcM
4XlCgqHdA/EdUXfSgk64IsFVQ2j3FFfcPZRUcEYf3sAwKBbDq/KyhxwK509lN7+3ycOQerV08aHy
s0B7M+wQxpqjDB8Oz3FYrcP2pEp+FBSbE1MLXKgZEa2aEHLinqa4hH/DFuptWHgKdLWAFSMz5SGo
Raxycd1pMCpmA1mQLow0OFYVD4FHtpv7ZTgkTo+PQ2Ra5xpcfIxc9284J5M2JDk6MXwR+T9C0/3e
uieHSN7I6Y+rS+MDA0oC09tDGLkBIkGOZQAawoqbtSQpEgsWFzQVjRpsS6xukMA83lObujIus5Yz
870jDMUeZhX58CXo5AMYOlXzuDIHaYhUqC2rBeZJpE74FobhTnsdHfuQJMZr07Eto36hCwRLu9jw
Cz98GSPobm8Kb9gWWSQ6JiqWlkQWyWmZCZv8ZFmPpY5uMFlIKfwp2eG2KMacjAD8ZFAllNaO65Qx
luY6bYxjR2aJx0S0ACm3wWkrzSPfDwrUBS+mQupoEBpAVz1ghoECXEFMF7WIif6moCiGkQFc/TaP
qShBNGNnYUebBtC/8Cd4SBRkpOVzwaUu81NrcsGlU7INXFSijd8n6TZd4TsPCHwy3EtCr1ypWHgA
ExR8lStIzGXUMaIsO1uXJNoHaSxfMzgPcEYKXJKxfnxqqVtqIRfur/lUD2YPY9gSdbJoQ1ffUBeX
6QVyrc3GsCTV2KiCBuKDJiiplgv8miqAPvDzZRiJQvS+T/3gpsEKUpLtL3LXVwv+DApq0QjfyCh2
iEpfREXBf9MmPjRRU0AVhjjjAetyDeKlMuaKEhpTsjMSMTHvgSUBv2iRm9lkPtCR6chWxcHCxm72
davN9JrYb/Z1q9t0RRyvnJ252dd1qyJWdIqQV/1R0Vqsh7u+LFlZsy7ERcAopoQzApyLO3n0hh4p
RE9LcrMvuiRcoEnMNr/ZZ1GHKbBJqRpigle6wQ5kaKyGu259tBaOFygnIvGwS1Gc4N2F64ZtSP7Y
xambWWm2t8IC0d9dhhuj73cl5MkQGYMMzASB1ZeC2Dh2yxsXIc5O1Vxg99cWMFFPL5JJOWzgs7SA
f5Amzuh3xgMPhVlZMUGdN1UN7otD54KPXJ+ByO0gF4tij74yUg+m5Nna7+aZFr48kp7vgB9Fs13H
unnnTR42kohRbKZ1i/bUZloSOBbDRnpyKXhe6FiM7Ybhglc3Z4JHO+wq5StenJyAALK+PYDR4vj0
hh45RE+LhY+qea+LwT87fIRLwcebaacCyOr2tggfWwqSuMVSGiORDGu3XOSGN6NCCcFB5ikMcTUq
hT2jY51eNON1VABiJMbm38mxgXp8q/SBMgyAWIQc3BC58liDmEQUiD36amxrSk4NkgGyqhWpvArc
vSNOGl2yunz3ZJi+NPIySUhEMChiAD4AkQc9JofCg4UUSiNtILNsIi+Q8lCjM0T4XTF9iE4X3mAE
IoIdVuF1qnYt6BOkUgYeT7GrDZ9M8HWBTXayN6OxAULaJldmEAeLA2Rg52x2a0748eHTgRvf8Pyo
pNbgBknVeE4vTRm4EIc0yYQgBStLmgCunAiJIdXdcszXkhKI2fNOIrvAzjBTHgCMOyquqoaHNTKj
soaAjWlTNe5ctKmz+II77HgAFHb2EYI+Dne+bXywv5GtrmrCINfKajMPYVc3q8kYj3jSFtCkNhYN
VlgHMQ8iv9FTRBZfEAIkaBESJMU2S0EA7NuXvLLNcU892E+h3INbC45x5e/MzJILH8RZrIJhJSqj
YaQ8oB/W4GMJXprAsJA6dk2KTQ198WWRw1BLfUbm6E1YdMcqWJ3QgbGLGXHJ6ROpy7t1qOSnUSV8
XsfCT7FZUgkiLBDGxJ7JT2KSOQzszkT4PlzXzw5G3FofwgcllskABUEkIonwL2a4fy02Nmx+w+JU
+jE1sAMmHtR3mzmEYZKo6RFMNBIOy1IDeiQt0SDCkY+VHzumhVcIdcUTbT46Rq/RmD6s7P7N3hcY
oVjRlkSxwFiFrwyTLw7jqmG4R3L8xeGq3aSLi1lfHK6WyyIodlL+an1kM8W+xGp5e2QxVThKo/xf
iIsA0L5E2I3HcCcXFslZp+jhnOxLxMocLkj+1O1k2Jeoki8OJxYW9dx9idXy5mhf4tQXh6t2uGaR
O1VuxDgAHpakBhMXWxUaMxYWydanqLA9zHruwsJ8X4zkVFg1LqAekwuLRCw8Hg9ErmQG01uItV8w
9doHITQ2fDG0cgD1NcHT2qdcWCSXs84vLNJvPXI1mABih1d+tDHZIZ7GgISGwOxksxcWyTqrmL4S
Md4wJSJiSUMtly4soksiZ4D5TNoZNkWKGIRPIIZGBwpNYLm0SApsYAZc8s7WYsTHp5YWZvYaHGm8
DqDUoA3AwMeWFkntghTMNRYKdBgvnCWGzMKNoPQ2iLwTiAGG1WiJxQIY9K6qhqcJmVFZksEGbdLU
mK3txZewZ+ySIyrYwBghGNvhLpYWVfhsfmRpMfxOwMgVkWXYhFbYzhcXE6uR5Xrse9itmRgiagYM
OD90xqpRFAvBFUB7dHkRA4UXbIAJYpiapJB4+tvGTm9HIA53b9QZGyqUO15eRLnK5cVwD8nsYP7y
IjHUZHlhbLCIeRY7kdFAWYqeX14k3+1CvRuWFzEWihH6glgxI0FyE4s+os4nC22nlxdVM7q8OJZK
zocFwpj4E5YXU1KhUxDzdJxf3sRt7Cr4od+BdnsdFhh5sYMoEjJbYFTN5AIjVJlCDgeCHS7Bg+LW
NpszUEFRj2PiL+GQX8yY3qQlgv+4BUaybeujJ6JHnqWoYYFRypiZvVflLpOIwEsaqsEQTfPZG8Xc
qW2cqVgbbh4MsXYwizzWTpF0Y98j/FHWgwu9RX6ciRQhTTw5MsHMWuwzEqP96I4gC2NmQSMIu+kr
MwyImdzDd9KBq+L79Nx0feA8PgKHXdsaURE0xEXq5KPkGFd8aEPqwBHFC4wmRzGuLtiTwS/T3XzC
P6Dt/aOhsYSS2b1kgVwKQsscoKK5XHLKICIUAVq1wMVPOXdXe+ouCP0ztkB5JpKuvDxRJE324Kfz
QfjVHyYFQQUEkmj/CbWBCBop58GDJqhQEQSIWMlQMXRBBBv8SUNxfQ1pdm9mkDGbZI5gJWYKI0DR
a+aXzsaJNYCkHYkQwnlSaN+5VVdwQgsgZB41Ii8MQncdPyekz/46prnHxupwdK2l2txYPXp4/bf4
Q1BJ/iiNhKgoDQEBNdTCRSNsg4eCi7Clh5hYUDq5lcjciYuIvYzBgn/aBWcz+5iU4nwkfDCTTNa0
DAFbEJl1lRYHgFHhbShKAeEa7jxnhkVBLO+FA9eiYaAvH9SDhhxCpCqOTNTzPFgwD2JHwX5l9Rzf
+YXvAk7stLbrobRI9loPm6jhKnW+19qGC0FHVzlm7ba26zUOpMhdN70ql6uwxZmE/mK/td3k24n/
Fzuu7Wa4XzP3V97adXlZbptV9QTW8BVOtBM8gLiALU17iQzTaDyAU5zA5J4b8gxAyBMbuYicCnuH
C95Ik3s+T0+PlK2KDzP8KpYGhH8uCTiRzNGMTAQxAiAlb+jsRRD5/JQqEhA5nBEwxu1Px97PzQmP
PHjk2rsk+wstXexrquqRabHt+egi+8Wric2i8HONZw8F8mxXNeheIu6rQiGmmQRdIJR1qefIVxNq
goYRg7/Eis2avMpQw1z41R+tSJalvxXKiBi5oLGpTlbMWCzWmHdObojS5OV4cUr8Nly4i9+7PTMw
3nb5mz24Y6f2AWK5bgNlBsdepWcBQAF/sT6Cq3iUEQ7RAE19wRVJAK/gy+4KKpPJJ298hStvT4+i
lP94WxAhSYEjm7PtqitOC3Jnqec5S37+72dqGA0PgMWHpEBSwAckdMHKeRDUiM7S41NVjWc/CC2/
Wqmba8d1+Kajaj5gSKbuFPiHwzaEShSwUhbToOlxwWcIHx6sTwQfkPe1FGKhyWfCCiWBkUmgM/4l
d9IcxL+T1YgaWNehtedxXsFWVGxA6UXpRT9BBBsJxQuzuOQQRPxKjRghdDnjPiMH/kylXysCz3Is
3iiT5BInPwErifGefDkgrdkdS7jHTCMWjAJ0aiHwmB7pjyNduzsMlv3YzN4uLNbMXO7eqhLw6t79
L3zLbk709Fiq4me5iNUFGomuxus9dtccdEtk5F6vigQuEmBiPIxXU6qoIfRu4unfMDCXEglT3EVL
SZbjnpLFB5NAJMgLxiSln+ize9RP7sKRWZTMEudi5qaRgW7BxYMhs+4RjzUC0VCDAS+6c0nVAT+q
cnOjO/7OgS/4LXxMlK6bsnL9gxkzs+EJwTBzFQUZZowaapF++puexj65xIDmRJcZ++Z+g1jhCxGI
eX5sQhuph7GYmiip6/heVpD+3GxckW6zGFFqK6h8vn2Thq8Nk/QBBxFiVO4SwI3mdGJPxY9XQYwH
jAB3wao1qvBiKGhYOE6BXA+/NZHkN+2QdOH7r/AD8Mt61Ra14aeqzVESjRiGmk4ymtDJMgJ9YHPi
0kuBNHUK5Ym8Bhl4gLiU3CYlOYBwaRyYT/4Db2aj1wplbmRzdHJlYW0KZW5kb2JqCjQ5MyAwIG9i
ago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggNDMzNT4+c3RyZWFtCngB5ZzZjhvHFYbv
+yk6vFET0FBssrlMAiSQ7cQYI/ISMxdBlAt7LMnbeCG9SC+bZ0k16/zfKXZ1kz1SEhswDHgoVtVZ
/rNWdTW/Lz8qvy/nx//2L8rVqtwsF+Vqvijrcv+sfN5+08zTL97alfPZfB5m7G7LujmuDH+OK7fF
7q58tNvVYfXueVm9/+0Pzw7TcvdlmBVm/3lXnq6OfOtAv9nONpvtMnDflEajiDS++OmEwHy2XgUB
9L8g83oxW63r1aLczJflYj5rVss6iL+J8reizIt22pJpTVlvNW0Vp4FAEDDI0/4X/qxXrNmeivXP
slpNy6v5bFFWV4tp+a9y957ptz2u3pbXAaa6CYJu6pUWR1zC4jouLqq5qJTToFagdveJvtkf9F1g
EFkx29aXVaOhcloc1zNyrZHfG2WosOahjQQ+9Wa2KaudffH2tIgMvxYRpPpR3xye6dM3rn+idLBB
PZ8FowQDzFbF0ZtO0PW58zAhg+jGhTsqhgS3P5iqiMIQ4vLhlTD8WdJ+qw+2vKiY/JmGtIgRFv2E
1prz3OT8VpjtNfKKVUiqoR9YZJbVwN7oF9V3EgaOqKnVWqR/f54tiTOKChovIXIHA7RkVpcwAy+F
vWa49qYI2k/+LmlgdJCgrqWLMxHJXAtNL6uHQ07xtdA/APrM50bv/se0vK5n29LRgDs8I4OikjBf
SAmJ/qClWpcVwenCoSdwCa2MCl+4P3VV+1Sc8VOJEGRL8o2nKwJqvd32BBQR8LmwQs4QwTHepbYr
BUQEB7LbqqJ60V0uSYF1j1UIBRYxSSkMlpIG1lC5hcxdrkTk7jaEHmpCUBwIATjw4asvBBfLEV3L
h6MA3nFqUcEauf8NXZAVfnyBNMx9aElQIjBVazNHZSlTb00Gh0qL4SfyLGZEUzXD/DXJNRrBwBgN
aiKCSIy8EOoz93av+8dPafFfr5rg8v3lv9y/KCj/61Uo6vduANara4+o2JmctABLFzLUuKwFWK/X
vjxpAqzKzrvx83pNgJvxv9AEFNXbkorgwJkx5PkmYN2iProNWIce7qR/DAjfeA4/bQLulCw8U+Xp
F3nPudkx8zl0d3QMt7j63WCSKSkUSgEh05lVg4ixpRN34oDQ14zc/eOaovLESeIA/NAIRQYsR2LC
SBzynO/AWYN4rCmhe297/7Z7/92x8Y5Ne1+RaebW7o9dsKCJJgR2pkEungS/QycXWGNd7xBoAA0w
4PGV1uIb1FkYAbDKt9ZATsB3a7a+R4DE0rE9J5YYOdBJYGEkEeNTRYsq44NkuaIQk4eK6DBaSARI
fDOBHJxE7zM5Pqp5GmMyOmqVO3gCe+vWRZUrlRVeAQHLW6CHJfX7eyU0OLHsQPeJfjSygBBFLqqJ
eyJjeSx6Z9fSvtCw1evTrXNIfaQzR0jaIqOnKPyq2xcgIXhkJhBZoAMWJdlzQQg5pJJpf9Vee2Vy
J/3KGHcVVu4CGVhuFCD3jQ+ulzsM+NmyItvt0METGRIH0wn7zHuKCk/IWbuvar1jAS+0UVpEc0Zg
wTdqMctqMou5/rTMFBfLzLyxrmBkmVldL7JYkicKLmmJbuS3WwLJtEtw20/DQVV7THIx7YPDKcOE
liQ4aaDiHuyAVJSmrlBt2xHriScHPEs8IYMxsvRpXpK2GVqNN7o7I4WEv/UoMI29NOEcQAsoyEPq
EEH3um9UTFiF8DllVTZk3hMpyLWH2QhcBILr50wfGfLIs0dEgo5wPDyyBsdnI6QZLDnpASrmABXY
t+3p+WKy2qoxs3PYUEzAA8lQCBYygpS3qUmCdDg0FywRHTAyup/IpOQfXJZFqCkGUEFe+5DspDU3
dwON5HhCToEkrZmqtcx86cpqsuZcxQ9F5adPD83wmsJiNNKIiGEafFYjmun4404g5/7d5QzugMsH
Eb5XFkocQuvvsCSkJTt63yIq1VDY/yJJrPXYC4G07jzQCIGEEm4LgXChLbRdoZfa/oJ4cd+1WqlX
HFsQG1VQzwePLV6LbIeNJfFTEieRsMeCwEG+ZrZgwQHkEV3/1Pf4Pw07SYXE6p6iVcTrYJ1KNhIQ
JH7QCXX5xvO6eCEYk6EjbTUVZSCnGZ6lzCOyYlVWHsygd4llqOGw4sOjrPpgMCBFUp8swcAWp2BV
Vxs3TOfYo6hggFha/NRP4l9CmVmUCfsmyfhPpyLhCRcZ995zJq52IdSXedMIVECf+faQtYuKNRI0
mwp5jQzM7HNfvAKH9s6JMUQQAwpBPgXQMxXpQTkXs14iaWYZwmHk5NIJ67qfoH+wc+xlEctzpNZ7
T0zEoR6ErPYkgDGHVSL4tJKIyJxv+AO6nVMbJg9TRhxsE/HvCwQPWckFBqyGnqaQajEaHzLrDSs5
LFTgcyFYFuFxfvqgP9TF54YUAL1ZVvN9hEOElo/ul9WiCfEA90AyBt75dGq69x+DFj3HoKu5TjVH
luPmeh3QK/yaREDvxjR60P4NDxczOx6QFT348Ex9NVVZnkLsAh3uNeS/SXPnKZmmjuW3fFJyEU/c
leDRDFxDUzVAgYDoIUncx3P/T6UjRLLFogoRVOyMJMlZRNwnQB7AKUMQRgYiURxQHt7Q0xSoMCWO
uMcDB1bTWshjWEzuzQrp9E8ex2cenDXrxfBjM78106yX6UOzeJ3jwq2ZZs1lHg78VzqDvWqieEV8
wJA9Mms2edfKY625qAgZlb/QBZE4ue/CbNYH3qfPuxlJbs3EvAEV1iS+2b01Y1SJFzNYUeFNJzst
pVke3Deb0KInt2bi5aT+WzNN+0gyO+l6zznJuYWR/o37asC8KQl9jWSnYekG6A+WtDQZ7+TZ3E1n
hrfoe0/rxJfodCPEn82hG7FDeBErvXsTswtPKLosyhFXGFAv4lhUr/fYrGk2PAqOFePiEWizbB9Z
dyvuY51GCrcnPypJ4n8yOfr2bsLjQ8R3zVjKhYnTUh8Dq3ACel1WjwGeD27RQyd9Jw0ZwYkpPSCg
JIXIcvSXdLBIxAd07tE1g8FCIKkEHZETP899TfJ9qSzCI194swi/zLRLNj+S77bd18S0k+vOER6O
CCxEtNq9KKFv7mXbJx8+Mis/+auEf0cfZnHomJS6/Y9l6Z7+p1m0z/ijc47tgOq6J3PtTLLh8veB
zUDiJ3+LshfVh8cbjGt/HC8vLj31CmVMQsOfsLStLxjvc5PSeMkPRDghY5cK3Lkfmuxao78qXMnz
PmLE6Xal0oio6N84ggbQQ19M3jBLfAx6h7AnM7lgi9u/5tnW8tpr2khnWm49n/r51u4Id7LlAghB
JUAGnapMnSoG5b2cSoxyrwAlyUAScwZ+hgHgZJDEQaJc4C+CXmjh5Z0iqbdTeZMNvegEZ+m2NFKL
uOgtKVEuYev7+T1pGoOQxZS80Mbis6czZrGkkcCXD6KLqlfgWAM9XlvvNtWRByxj5+N9iaTomvqY
jtTk9Xdxy02o7VkX93/FHf1kgAhmjztcRrfsRze6w0h0ZUsMgL+b2R3486d/Vx5O6ChTWVQlZ4pi
+4ZKioG3QwRw2JAddx29FdbeHuipsMv2Fp25yNikuAoVNu8YLfjOPaYisgD9plO5SAkWDgmEaHq+
Cbe4EuDYWeeA3Vo5+YuJgBXHHC4lzV1WsdUPuYOgFbmYG0E0ncQ/mVgqtFV1dKIM8MtJtP4DU/B8
okwkMmbByawEdzFz9zugEeYh8QO9GCcvQ7yahrdx+m47TMjhLAeZr/wi1XnYLmTFZXLd9nh2UIRT
skmPuYQkuu1dAuUzd5uId09mw0NQSYiU+VF+amyDX2Kw/EyROW2hzJJsIYDydbPFIvRD98wWdd/+
8sZaKPmoVKTIoSsic7kym0vm1sggVRKQZpKI2ACZBIkZNVdUEW1woLPfKyo2XERyd63+DQD4nNgq
6JIoytRBNLwS+A5QZtJ3im+xQEyYSyzgYYQPxsHrptbAkKleo8VRc5myvwu3WmJF7+kzvXEl74gC
lhRpLU+OGsgtWY71O9i+JxNlEeSYGGFBEpQJdS2S1ZJIN+bJiZhPSgW7kMXmvjWueWngdv+K/I93
oLaEOnvypkOC3Hwu5mzU6e9i3Sba5LWJeLDbbqTm4bUJP/9dbNp39O773uRiE97KyLrbtWrlVTh2
TSDMzoAX224b05YBzmrnoiPQfDM94hS4SN+djO0/lJNT4Dhy8RS4SN6d7HYCWJnU4lEW3FIIcAq8
2LSvb6XnwOfenlz0nLJ/DCe83T4kLo0XCj7kxMX50BdGVvq0erKzJib3SldXk7Mm2zd5sDpTQsmd
XqXTnaVJ9oqEg2YeH92GSamkK33SRnaXkOC8L4FRb4tlchHsbH3dcdGefCXBIG1TEsHIdthLOA+1
QMn5ZgApJnPEAl1kwItEF2GAOIqZnLgglNZAtt9oFjVgwulSy0Ix0r+JXoS3z7vH48huciSOD0qI
yDeS9alf9ELDBB8zJDxG41Nmt2HSezviDrrurhryKnjXbQXSZ1+5G4mA3Knr5350GmKz66haBNkz
sQkWioqkuhMxQRp7kPC+kvg7+iBJQSGxgAmGK72BBRKHyGFGUXjjIoglUNjoSHANIKUGuhYbcT60
aJZZ/UQU/BfXRO4kxpjF4y/JMyioBn5ZJ3k6nXjkn3mEvZhfj2phwtnKvRuYusng9/YldAVJYsrb
l0V4kS65J/PbaF7q7fjWZd73WuyN9RH6aw95yvBCqoV/139zN/WIftBSS9/Xt/j1zZAfkBDavokR
K4ZUURUinMDwNImpJCcCVtTyRBDJFhU5wzXQIujqiwl0GfItZHgCE8v6zOA881dOfCbG6k34mZUx
UVaHQ6P7bxTqjZ9a+FMcj7QL71fX2/bt799crNXH/dHYjUK9ya/tXf0RZ8LzVDpCP0FdwcEGTwVZ
jtez+NVkWoxxseU6dbDk93tOdqJ1+ImgJI2PuolUN6eZuAzbSHeuJqbxoZtIdaMbfu6Z7BQH96Bp
N8bukdmsD7x/lTeR6uZ0B3ruJlK99AcUDhE/H4Bn9F36eWjZSW5omTHpGZVoNQP/gm53ho6Vwo8p
cX6GM9INaRVfKEEGRqf3uqy8JA2jZEEExUy4ug8njxlNpzsLXaUdoHmaZ3omGGm+C1acGTwNwjTf
fEA9qEgaihBbLhrETBa+0GIJCQIagA2FEUCQMkFLywbpSce8xmvpmS1RMAcNPO9ooTeHJGLexTd3
tcBTmeytXd914HrRPbJqcw0oJZoDi2FbVNgBoBAe/DlXQHiGIMhvIUEwf1Gz5DcEhh3EWCQHDbBg
kf96gUDMDeU+LrdH5nHqdI8GQCylHA/qRjoDBlHfJWca1kIzEgc3uThIM7slgKGo6GJaJMDJxMBP
y/RANMlM7W3oowd2b2i1z4/P9G/HWzIjznmPvxyVlNdRP493HXrDM9ukVRo0+Y/jtHd+fnu923W7
9Rnbum1PAWpTyv07N/lX7nmENQlDuxweS+5121S+OPR34sbO3LHgtxpX9ZhWL/wg0KArFidHgfxS
46p9uSL5DcqTRi+0fJ69c0dc50ct9Gl0bkLRj2y9xCR9nu1UWd+M6fP6nzWc/A7EaWdCj4UFSTjU
B08n4XUFqc+zhnU4Exl74fzkR+WK8BNBAVz4kcbIj0IKSZjSSYbJ41Kt0YzzxSTiBVmcVVRAJXf5
vD/q7t9DW0WVE8H/fXXJHox4oaa63OfwNbn/yuGrvxjSBpGOrdpb5uHHOhdl+MHObghxBAMiEDNo
A1qymcDKIcZSkPHXVrSatjHzI/o2stS7tnnAvHywxUWVS47HwsCl8fzw0X8A7Zi/igplbmRzdHJl
YW0KZW5kb2JqCjQ5NCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggNDI0Nz4+
c3RyZWFtCngB5ZxbsxvFEcff91Ns9OI9VVhopdXlkFQoCJeYChiwqlIpzAM52FxtsEQcnA+bfJXM
7vT/17MzKx0dSJ4oqtB6p6fv3dPTM3te1J/UL+rF8N/hq3q9rrerZb1eLOu2Pjypn/ZvukX64u19
vZgvFgFif1O33TAz/Awzd9X+Wf36ft+G2fundfPRDz89OV7V+28DVIB+d1+H2W2kFn7W6zaQ29bj
SS+HCe/uq8V8sw609L/A3mY5X2/a9bLeLlb1cjHv1qs2cLqNrPZUF3UPtgKsq9udwNbVIBHCjnjZ
rJmzGzP0Wd1srur7i/mybu5vr+rP6/0HVRRlN0i/q6+DRtouMLpt18XkVpMXeqivglgB27Mv4puq
ORz1bikgoJnfaUiwjFxr5I2roLWAGSzMec1ohrntdr6tm729+JPmfq8HuPqH3hyf6Ol5lL83ZSJ0
sEG7mAejBAPM19EaI+067CIAjL0k6PcRlL4SIR4gffzJRRiEnH1zVUWzPM1GBPm1sIFEqjv8oCEj
XTWaBOxBwH8XLEPoCjRBMZGXr8QUJhViYBNbDIJ8o7lzkwM6c7NnPgPBzFZ1AzXeiKx+vxBjN8yG
zpfiQCIDAtOo3yhVzT81CWAEcRIFQvh7CfXapDziBmj8eHMAKS+ZWLD9k2GC61xxUgYsg0uMPoOJ
76UwTYKTG4RAK2F6nxiKHIfnb3a7Cc/HzQuHrJsfpV+xJveIv1Wjf88S4p4vh6c0aW7WXQjOqbRZ
jdPmZh2SYZo4Y0Tfkjg36+sJAT117kYaKlLnZrMJRNOloAqZgRRHOpQylDzrS5Jn1XS5MsGcJM+Y
lm9NntXtybNucKPzyXPTL1aj9BlXqen0uQlrX6qiOqhob0kDl8ZNQ6TG5SB9E2XEgaXOA4HAEEnO
HqrmlaAJPGYpRpgNTdDcJypDTFvmZv5z2UeIGIGWiN+A59kzg6qaYn4e+WQPDCNKwjszvGE5hnni
kzcQQlLhgeMkF5uYIvEBrJf4BPOpNAE+SwRVgypf9SE/rB1YHWi3pGDu6wGWn0v/hXJnv4TFynOV
syii7+eLGhp0lmFMCRz1oDBmpdnuRJSEitWipBoK0RAlUMA4MlupQXHukXtzAV+aJbyIoBeo5om0
rymqXxCW0mPEQrQ4eHFXVCN8pLS56Z5kpxfkOE0xrNVEISEQ+IcDSaZfIMyyVaO5TIFXj+LSAO7C
gMsAQvh7k+zxVXijlffc4rfYpEtfTLLljmGz2N594WvboqL1ZS/YQuwFby2XvXa83fhtLHphm5Tu
GM4ueYt+gcwXvQdm/nv9b1s3SR6LSx7FkxdWIcri1kfh5vlHXiVHNpesPG1oRJDkE73A9wni8RTf
YODvBAU5Ca6dNaCh+KPSB9OOAEGcVQ6+EhXFRGIrYtVATLKw6oEOVglIYDSJNR0QjUgRcFkQnD2C
gOFNVnQERxSAIVVw89AcJOwybA0+lOTBjG5YVw+MZdwn6iJLZyDJagOD0kXCelYbFEgAdTujuLAg
jVaDqsFUkFSKnCBte9UwkuQmb8ywaVlftxM1PV6Kjg5i5zVjSzSBMBlCDQmjuKiAsQJintv++eKi
KjDsgo8QxCMcmegAY6qq0vQR1errriQ75qJRUELgab779HVMpIWt9EWnGGGT3FOiKTX1b8wOOwBZ
F2EwdejO9b29vjv3O2u0jZtybvtt2M9Z4vUpVWjm5X08n7LZMsV6gKH0egv/xfTa+4dS+yVuDuOh
sTBsVZtc5YBKjfcs/QcKMe2/UPGMcxVzIJPbBO5+UMoQBJpkrhjAlSBDkjLYxLlycY5QFCEiC0Ke
tejfAIRevy2kfgYQjOEgZFhRpYnhSY9ZhBEeK9E1W5VZIUwnruaWFIqiE+3B25e56j22D7ACc0xj
SEwZbe+RUAELokQiwU4J4shWkqxAhkmEDLVh0Tinasr8gR0CyC15eejQnNzjYHwevApC596je9PE
+bwKDaw7JIjOKzNPEH23PzTvp3dmoV8/kSAemn8chrgPvelxoCS7S5SYhoUtZshaZGpsQAgp/9Rs
UE4765iZmj7x13JVmMId5RYF0sJxzBpJtUOuERLP7JiOHMMDnZlOXCnoCscP1pZzndkvddd9Kk+a
had2TN116Gveec8UTpgmCotwumLnLIFrMTm1a1ovfG2KC81vYt+0XvQ90kt3Tt21lm9fi/cWaoQE
aZAlNH0TiyHlMhIjD/LRcBRjltPCkzSrGLvhSRhnbxg/QoSL68WMVhVh9rNmCwZh4ItcIBDijPDi
waurI9nbG/wH7wXCgE31AhS5igxQyANnjNx8xxZFgs0UvIH9uGX921UdSvFd7WU+BY5E1CYw2QoA
Q55A6jyrwY54iGgTMyI+oKxXObIpfcT6TNgxGVglBgpyu3iJaAauku665rGclkIjPcTERigbkzQz
sQHqdqui9wCHuJvJm2RxJzDaptXep8YSKMudTiUV/EpIoUV92EIjgmRAlfEv6esmZ1Cmw+QMwNmd
ihFCKWEkqiJE9JArko30r4jovvVjG2k06p5zPLKhf+y9HKKUGe7AWfcIEx+P2AlPw69eXYV7DP2h
uuPpZZ06IkUducGwNVjTHWFkCxbyyRfawg4CquZBlnaFD7+CErr6LnjWLbGyLfugBeKT8qspR4jT
XcFKRDYRiK7g1zUh0mRXhcYHnLDojR88g5mH1JloceEWqGds+bRKtIWxEPxev2UNrUsiBRm0hibZ
ngYLaKAc5awaVfHN4yu31LkKL9y8Seo77tBkh8Hdanfn6q7rOKbkAMZru7ANTByp6Ih33XWRcq2I
rZqF6gyZ7k7HwHV6DBxDivKYMxOVJOxWO9FMbJzfobEUhD9iJnzWozlYTvLTOem6zeV13ao/x887
4qfv0CSJlhVb6ps9sEyg8NOAooeMYBJ5G1uQOCIZ7PJ07iUUCiPaeUgjUESJFaKHvR38CPaOqElA
t6qkZMK32di9WMvZ5c5N9fnvzPxjYid+YlvdLcNuqmjVxZ34ie5eFy5slRex3sKBvTeVeP1w4lxe
+znpGpiQfImPYDffOvDq/2dKqgEYYpWZ+YHkIfE41gHcAv9COhhX0IAdehohnFhKmDzpO7FkQmtw
620xlA9fucEQwcXynZinJUz/6k1VVCGCxokuYd+WNdj3REwvQj6UlOswifIUpZAnqsK+yIgIBscI
L5RCpxtNq6ErkefIY0LEMjadQ0STqYB1eWCNMXtIyuIXYpoMgBhkX/DgKOhF5boOb4bz7SHuKDtB
LE6lHtAaNs+uH4mpP+vhHT18/LqloYf2+xeNPKJOerlMPGKcBBDuXj89lDNlaw3N4qqF8SUJ+pBI
CA0djdiLqmG1cff26MBQGNELRIePmT5xU6aJGkkPHYtlpBNoHEh24RoAB1NYmYRMoAyYppJDBOf6
6LHbR+EtAbGL1+sqv54djmYuy3lTu1bdNC441ouL0lls+FbZvqlu0DJxIQ3hBwctz+jqhkqfpIQ/
gUfsCd8pW3js3EGQfANIAR/OuUQYdgkCHk6adgg5k6VqJLgwIgLSkmhQhKOGfuj/Ww7kFdGG/6Nu
EQOEgDK3Ts4rGYKhnOVC+xg8cBwL8zupfR5z1xACo7Lp7HHlauuFdH6AcaJsWvWfIBS3ffaWOrFE
oTZyNovxRLtOWpGu76y+5PaWK/Q1Y05YRQVmMb9GImTlUagB5fhzboXr8BDcIZoUrUDxiKuIBDKL
XRUR4Z5vhPHIBBbtCksus/yPGRaOydboZ5jy7TciwLk2h+KO/RN+C5oi5TBCwPPg4akedLJ+iHnR
BE9BAaMzIpUhwGTazMostJRT1l4G14Fg7xG3LEDr/tOQtCLrj2wuivJZbk4YxIzuJb72yxlKblEP
1d8c9oOr6ouj4Sm9Qb9q+0V0qmmSfXi0CmXz6FAsnp7dcoN+tZw6Hd2qHrsfTg97HZ/6+Gi17E/i
Ug3318NpcEy1TmwB+N98flQ1io47tU7M+Yg1c++kGvM6JxhOXkbrZLUcvla48AOkVdsV6fs9y5C5
WwX3JG4IOmIWPlkSiQZk4Y188USnuG7ME5Ok64U07qoMIGx4NtxpRClX/wYSjsjh5ZtsUpIkxQCa
ciZPXOSJ57maxwYOkVCnQJRzyOmAXnLnDWGYRYibc5Y1QuiTWEhNHACt+g8dh48aL6wQlteLwsFY
JSSchP2DF+AwjEZMFu+4IRzqZ9If8xQ5jdniHUSyNC/ugjk57sp59v73ZZhjfSBucFaiDzmluAIU
OizEDy2q31H+/JD97MdDX2Pjtz8YQX5zP1c+vFDJE/cMEfeggfELPgs8KRv4BVFeNGRvSSY4lDZJ
mBmt+JWyz+R6TMXq1GNXCiF7jVhaPtGgXG7Ht9z7hakwYSZm1aSf4hnDmoS5fTvPpkd8+rLRH96Z
68M0yphn9TEfxJagwlg1Z7o8IBaveMVE8o+OjzSaIhEYAClSYmhDn5zUk9olWv6rtuRkLjx9e2u5
2dwxF6612F6aPP3gKF5SDX7ylm6FaU2TFdL2BfrB69HPgT2GJ9v+wzFzCGbmui+zkFcDmX3CvivP
v8IGFvjRiHAUF6J9g1NO9vVW0xGY8PELYwgJkGbNPmR9xT3FGE43iq3oqZr/CGrJwXgZMHI030qa
ul1GUUVWMIuWIBg4PINFbgdBG3F4QwUwEX8xk1kmT0pO0RQPhZHq5l6fN0LDc+QVt6TBFR+m4d74
H/yOaSdM+RUEJiGbGEUzYyx1Q7fH1ciTJj9u/Aaw5pd2OVxV4Xp2cduhPne13+/lE412yclv1c4t
EZ/6Lcv0fNULbTY8HUWc1tX7RnBiE8o3NnlcQxK9QMgv1EqfSjiBL/eSIwsqFodFuH8kFJ8Zj7J9
1dx8bq8EIkuBLh8oWbUV4lcvsbhfUKHlU/IKYgZ2LCxONNWWE9/AkS5L3Ug83/ND8xB6wFYpRC8q
vWtm3IzahHZUembr3+66dON/6jZsuxtt+y/6cL7dXRc7Bt/0dyPtFbcl2mutyb+he7Dt9eri2xLt
bqqpsrcYykNjsoMqh1M4J+ch2tDhgYrTHsYigiCJLum7jr/mTOD0CmlRpnyltAOUXTEsMMRSyIMl
3+Q4iex19NXekyjRRGISR6a4pDfgGY6bSAJ+YIJKAaDVi5hlvSgosyxC5aqBM9KfYU9M6XcMNJvC
xG16LkVPbXUlnFBCf3buhn3F3zBqu+yGPTewsmZi203fsA8XtYa/2zE6AefvGIU/kzTRDQx/hGPq
hn1V5pX+r3ncrZk4YA5LHT5KG3AhqjQjO72RFhlJ7mHFkhMszEnW5PH1BLZuOLy5TVpE4XzPPbPS
TGzX+Q37aJWRjh26K8+CTt/Dqv1DW3ZxEh8+cWceiNDAr/7EkD1otlyQbEafTSOvWwSCTInrDAoj
oqa/ID1PwJCGyo6IRkya5FSDydhDsGChVCQdkAXCUPQOoi4XCFAICT9TqFAkItrxDca/YA+DCM9/
QMQDYoIJ6qwCms4k2IBUWoVnHQJmgTiJhuGcGNKlRmxBeolugM0DpvbP0xiCvSjBlC0lm9wOh0zn
ni8G29WqqIaQFTQigGegl8N3c4/rt/dktm61noc/ULaswx8py89IaP+BH5s4XjmJZMSgTCrZTA0Z
t5oGnKzAwle6/fsWtPDAA774qYoMmMC2wDB0cMV88l80C0zrCmVuZHN0cmVhbQplbmRvYmoKNDk1
IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCA0NTA0Pj5zdHJlYW0KeAHVnNuO
3MYRhu/5FMzemBtoxzMczmGdIIYd28EakE9aIBeRYdhryQd5rWjGJ72snyVFsv6vero5u6PIQBAY
8FLs6uo6V3V1c17Un9Yv6vnw3+6berWqN8u2Xs3belHvntRP+zfdPH3x7nU9n83nBnF9Uy+6Yab9
GWZuq+vb+s3r64XNvn5aNx89/+nJ/ry+/t6gDPr969pmL8bV7M+q2842m+3S1tzUhzN/+e68smk2
Yz5br5L/GZHrdrZaL1ZtvZkv63Y+61bLhdG7GQnu157XPdgSsK5ebAW2qga+YPmAovWKOdtDiv5V
N5fn9cV81tbNxeK8/ry+/rAaGdoOMtjWlyaXRWfUbharYrJNGSfP9VCfG1uG7fbL8U3V7PZ61woI
aOZ3GhIsI9D31nk1YAYLcx74mjZ3sZlt6ubaX/xdWH/QA1T9rDf7J3r6ceS/V0/CtOlgMZ+ZUkwB
s9WojQPpBuzcAA5txeQrWr7VMt/pAbn8W292z/X01fhQNU5w3fibuoGXl5KVET5qAVZ4+FpDttgo
PhBqNogh7KeQ56hLyNo54qrRbIaeZpMg4TfYg3Jo+PG8GinnjdaGGBaAy1mstOpml3Xzjkuyaq5i
aKAcLExGIAzdFGs/EVUAi1smgU8johs1F5L6RqpAMiDhzQ5akJUWuHkuqm5vgQeDlt8/yCSggeN0
hQOgKKgIeoQHCSR6cR2KUkYSk+gDSxEp8Zz1dmuu5bGyGqKseQ5UYKF7URF03eiVVg/h7PdfSmSl
7AVuYnXnKWSZS7lqtFYuZCgFR2E5Ky3TjQ9V4w91PFzkK9ZNkAdGNOCLVQ3ciSlACDFQKBB0Df/7
vWWn0RsROFYIZZr/q/gBM+FolFLVgFlzoJORXJAsTHgWMuGAtXGgJhAxAM8og+VyZDclf7Cz04q8
yVf8ySMqrlWSUEoZGKjLidIyoJ0i4B5/2qwnMtH9iN/og8eibhCha7lqjhNTzEGH2EzCsxsYliAh
Y93oCvmAZjaGtoF1K8faMVA0fxpKsbwKi9iy7ogtff3XV3D3TVlZLVYkcmWZJDCJ+vBSqI6o+kJe
hU3DEdA3vMo9AtnlZsIAygIbMpTGoTOx9zzxYu94NjrPPLsOa3CyoxwItgnMEApZECq6RCcBSC8S
ej1KawpYYf/sExzl5hkpXJgAAwgqsD3hfog2+hQyLJwE2Rg804QLPWg1RAfPIZiiEFNRFbHscQN7
UKklHr7zkULv+9cegR6f2+g9IaHrq9eD7Yil2CQruT10Qs7DxZR1i9EdRo2+rQQZK01RLNiXREO4
i9oLTfPw8tx2ULNN1cwyvz/RiduoKUa/r+71+4WFzUJGH3tFhSawLTEIX6Fty6VusIRD3sChv4m6
AkcLkSNfZhXmygoFYZI8dIliCimIunlmY15OOz9VA2PYPEKACjD8FggGTLYP03LUYaoIRRh4iT7h
JxgUKzgbVQMVWmAjabut9Cs7M8AiBC3+rQJzUCHCH7jOhV9TwKEBHB0WfwGbYIg4iJMHYKHS5VpF
BLhDronms/DImoo2ewyJSSeIuj4Q9efVnUX8PBKtt0oswhyRXNW88urDhi5XdB/0qr4YOC0orC4t
s7uHF1P6noxFLjVm+saRdROWm6W1gfpY0q5m7WaztLZL3pSxYYe77OGWgru7K2NdhQF539Ipoo71
Pyz6revGGyEV/RnfRhX9mdVmKsLTR5nLRWQR6tDUr9ehqaKD9JZ7zWt0aJKGBwYblmJeoixHfbda
b0x8Uz2aKnpyAb1aF6J+hFfH3jEvghK6ZNFyb2YruGlAgMQI9/akWsJNY2XNjhRwfL8fmEBEnQNZ
hBaCjZa4OohyU0V+GczCasgABd6visAq0UBU1DwyGhF1lomtagr8MAsJPATefSmJp0cKk1xBkbge
YoSkX5FHrRo1DFlVvIRlgWcXpf6ZW/Ppe5lV1x0LXtMtydWyLfYxH7jWSas76M7THiAuy6hUjovs
7E6ZeZoymXm9ydonykxgUoMTMmEl0UxF+JqERe3KhD/WroKEzwlsbGIBEnEePRKPQpI3BXCxFNQJ
3e3PktaEFYZE/amQKM7hfhNaxJFYibXZ+dTRXopBweMEBBmEMuWJBaupVPPWAILKrTKCiJGhfHDE
/tt5Yf+oggDBG9En9vRvJ2XCyCASogrxM4KMlIHzJFNH0Xe6mUzkAMpLHrAbWI2oJSbR5RTB46EO
ysUS4Ik3as2GlbEmwOCRoHMTjboRm82tAKz7t6OyGcl8Ty/gBOpM56ODM13si5RIcNZEOFZVOydV
w44NDkBsOW88jVLyA124BhKxrOD2X3BzakAN92f7fY9zzMvTwCJj2fldkrEkJJjEh+AEmeeC/Voc
IoffmcQrxDgbs9TAwUR9X037e3ep8q6o7o9M2HZFgHgENVGDQSkE5vZYxnyiay4JBtiKIbQkVaHF
8QyOEXxZaFFG6e7OScQIYGFIWGB6J3uFzDCA/ZvuPowhDx7CuvdRuRdO2iv2FTZu3cZO5odT+FMV
uy4j/9VBvWuHK3CBNGTgiFIZqooDWGahPlRCOCjlLKni6LQ8yhxCYhA5oJO2xgHbRZeTS0NBNUIH
4Shdh+uC0DqghwI8vnwTkzyWgV5or1wDnwyx0Xa3GkCm0OoPFn/AEiV9rORRj/kaEWI8i6Nm0AkE
acMR+uRBsApZVQOhGmJ2YUyiCWFmJJgaIRPtJWH3Au5YlIdD6Ywx43fwQz/wopYFZZc2cHe66Lrs
Iox1d47q00pW1wwkSAoupypxv6Jmglw412xeUENYweHmdlucfr9EEkUAgvZEABZpU108yOIFQQGs
O1QKXQBRanwvUSCTgt+IRIiLh1FjUU6VS0o2hW5Z8BAi5TEaD7gBCwSbPGkJGWxkFi1x1+w3eoGm
54u4CpcbtAAWgKHCDNFLS87CdI/38Dq7znV/B6+zS06v2L/rFpdFSynv3tntqva8Svyr6N51rSqX
6J1O9e7GCteKVLf5P+Z2VdWoDfMavTsORqsGXUUFYKoW/3TjunY52blLbtMF7GIxcSj7ISvd4nhl
ICZWyLowNwxQI7IpzBhsJL7cn82dNEtYMFrwRw0lmFuAIobPsg7V2bWHIMgpPJHAg8f4w3TmZNHD
sBcbrqmVxrQCL9CAbBAws3FSFvR6p2o+dp7eU1x8+JmeirpA5VcdJiVZRyGlJs7MEed/z9z0JvYR
h1c3MbblpTXyfWNwYsG53PZ96PyAddRf0ghCdjIDwi6KLItIsVxsXrFJsOzQiSbpLyu7Hqsmz2+o
qtS0qEXRYBvRmw8IROthCoAKAhLDZ8MFkmtIJT3CUKyB8DQiyI/do04xNuiCF3zKeTA2AUIUpbSY
JirkbHBkzjA6VeADDYgpAZDgBasDLfkDc9f+7eKE5ZIu1+mFJ7F9epu93NgV5GKjfadze/m428/c
q12Wr7hxXCanaxOePHVGtFxZpik8+eqQjKj/XadRCaEatJ0b5Z8V7zSAr7h+kyPuZwDLmIpJR41f
tpGjT254YVDYfIEey5LNRrUa6T2PJdCENDKnSE64taIYjFy50xDooBe8P6gUIm6yEgqABbhkOjAS
lqhAaKxdnoaJPJBosqe/xJc0Ev1FyIQ6wbCiXlgjyus96KbmUMM16R4DJPoOtZPW/1ohMW+VaUdc
edmfced3dSN+R89s6twSnrWurmAmkoL7yGUwRGzUfHGYaMslpRFBUilSKM4yl37c8MGAKzTxw1D+
LqyeCO2Xleoip2Kv+eEjAzmdDGCrgoBHSh/xdopHBgxU+0OErmIldKERrYjFI9YRInAxFT54IyRh
Kyg4NWtXJAIBKCemhNAKvmRylQntIwVmh4SoXhlLoDP76sPOPS7TTpWGZkWO6ehNp+T6zePzxFoP
v3Jxs0gCailxuOYhYchTLWHIpo/FCQqDQrTNEHh4IA7LIrDbiYSPQwMk1UnJDCAvQRBMMMYb6Iu+
RmE1Dwa3D0NVLyO6kbACYh6eYRHg/UZ6FF3IRixoAGZBYl+EufQdXXLRVLMAydGxjiBRro9YoMcU
NBlxvpIyfhWPBTHgExFnkQtiixvR02zrHm9ZWK2oBDNe67JOY6lrV3XSmBeL8IyAeCMQ9CmqTzlj
j+pb9fybnkFYyMlM2sM7bgkDBDVQQbyht4AzmuuNzojkU1mO7SB2fyDEDzBlKBPHrMlSGsFMQ5PQ
LgF6p2JQ5dS+Ou7RDU/JZbp225fXh6246qkp2r9w1GW6dtvf1UuaceO3d0c+cfTLdO126suHiXbc
8iBoF+249nK8lNcfUZ3YkGPDIjHSSpuPPl7pLl/yyY9gafUlnzuOugVLp0iR3K8+TARULygdtWEP
UbtYwOm113/uSd+jtafpy3RTLbl2c9j5rMxP/+keQVggG2C/mD9vZFSSxidfKNzcf46QHuNRPHwh
WVls9ySLBJKDlTETRNzHJQA+pGyiCQ8PJVe8ob11Ill2BUAh8g436g6caPz+t3Sibv3KLrQqT04n
HMjMUUTaRqF0oBUfP/NBH0buDhGCj03R3f1s1yWuIIMB80nu0zvWkP7/APex27hVuM/KLgef+LVw
28VVZEWYqvnA3SeS8614lCniWaXpkSQplfY3sYmiOhAmEJA2qGkOPSMpLTVXVBFhwM4DeQWYXrlj
MhMamAFGI1oAIvMBjkCIdjwUc3HFs5I6+tIh88L9YWUimyMzpC8mScsFD7AtSkGCKjRiFLvVBxEa
Ay/TJaSAVaniArZjV8aoTCIpaH5xkspSiFJ1CbwcVWFs83ZRUbCl8AtPY1U4VUpM9yHaZVx3zxt7
R24HtfZ7CWVlGd/1XbnzSbzOWXL3uyy9kAsqwAwYin2lZIYKANaaUhd2wDURqQZ54+Sae/YuHoAu
bp7xDnpIkxiA6AJ3wAp5hGgyOukSdkbgZLcdPgUw9DArUItHlr9Jip3hHlQpF1jVZFFcLkTIQAKC
RXsQFW7Sn0h4caclcCa9YJoQxqYydqIaA/g3TY87DIIJmwmX0ZhmIQsbSHLxxGcP7XyqLN6XwfAG
VmWIaDu82I5tPCSVIhZt8AgILbJZUDt1XG+3JofCf+2/OzLxtY2B9OV52wlk/F2O6tjewOCnOjBU
DdTY9/0GymI79Y0TeOayE2nKLNsldXdd4+bV5fPB7HXN/+icfjFs2U6tbBabsoB8hD3wIBlhhGHo
0RUpy3fyzwsJi2wNatwba3ZXSfq5Wj5WZdtLRNkRnkFEoCi6Pg+hA5OXMzA7vBoSRzqq5hHeDJ5h
pyLHntoJ1IullfeZo1i5zU7aADaFmww/7DP8mNBBZl3P7YeP7Pv45LeO+g0dJhhOYk+iaqr0X3Tl
veKF/GDKRe7dOSdUuItE9w76Ti79h21HWvpX0fdHddgA2ogiyWxA/FP6L2w7ljrIuB87EHDALqe+
+GP3jiG4rcWuM456doRl2RizZNjTfuXhCOhgz8LykGGP/f1rmdKCsrJwcOKTz0f+lm5/Xecs39u6
0/YgK8PEYbkGsQAH8zfJDSToQKO3lCJMw/WhJxGQk8Vif3H6Hp+HHUx6Z3+JJHPPw0aXNVX6IjbP
Y3c4aPqNbbmvDhe9p7216C9ThatX9qMYqau/npMmP20jW3wNJ634BS0c5L930nm/ATjVTS/pYNCF
vqu7lZsJxiX7lTCsu+XWf7S7lWy4J1IG88MjsduiuxWRErMHOKdM/z7qaQlduINaFidS9fboNH3b
cdJp1vbrd1lGS3vD9dqucR7UfeZSR+u+9VQmcuGbi4y/dqSir2/lTOWzTeIp/c/HnOQp/++/e2db
6hMbWWsLYcXVnqsshtMKSeKqix9v9mIrDDYyGLOwYaI5b8BDaozf/+LV2bHsxgqxxWfn7cQnt/jw
7dO/04tm54cUtaAhSSlGfCbjpKZFGDmfVYNwEQrOeVC0jOYuJz+L7JVYfbdczey3Dtt6uSiUegdR
iI8bO+LEU2tyvwNm4S3qGhHHEBW48PFxOTr9h9saNPDA5JJyF1VyUMeSuxDMp/8BHhczFAplbmRz
dHJlYW0KZW5kb2JqCjQ5NiAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggMzEy
MT4+c3RyZWFtCngB5Vvbjhy3EX3nVzD7xAG0k77PTALYsBIlkQE7cTyAH6IgsNeSY1srxT2yk/3Z
fIurmzyn2E329IylJwsGvK3mrVg8derCnh/sZ/YHW4z/9d/YtrW7urJtUdnS9s/ti+FNU8QvHh9t
sS0K6XG8s2UzjpQ/48i9Od7b3x6PpYw+vrDu09dvnp829vid9JLeT45WRpd+NfnTNt22bbtO1tzZ
ych/WPfTtxtzW2wr677d2H/a48fD8GLbtdH/Bol3dlfUtuq2RdlIY7nzcg8iFHbosJcOja0adGjN
uDHueSJSV0jvfSJMubFelhoPt5VIZbxUMsN+1MPeHkQ3oxy7sl2epcAsdiO7kS3ef4nN9ie8kwX8
muxNKRo0oS9bDr7FuN+FmTkLxzwKLTK23G131h3Diz9g1pd4+BKz/Yg3p+d4eqWnEm1acFMWWzkR
0f629UcxUbD2LaTDFC9y6l8EWf6NZYII1r1RsYEKr54XY4Nx0AU6/hdTvMYDevR8w31hUNiecf0p
0lPbbA/WfbQRxA4KwzyUTXThZfkaD+jy+NHGjOLiRbqxn6hS9IEw8x3oHsUk/IJcGWM4We/1Yh2l
vGObYMxLxTYCKNr1KDd7EEjzHl8BuotzfAVpOceH4c1o10IYA90MhPGbjRGymPMEMdPt9wIqzxQ6
ZOCX5SE74ZgEZk8DmKAj0fzCGd9RAUHVegg8SuqVfXsc5WM8EHJ63NJpegqpNs5vrWtUGwYKDEOy
TNnVg1Ge5cquLocuF7NlV7cUItC+mDGhoHxZbwxYPMeXXVOdm4cc6PVpBsYMJvDWjBnczDtgTKPG
RmY5z5hdfZBt5zjTqJ9U/Fepa7qEMT3MSBoR6kcbB3fM+UaZLmbMoC4MIvh/CWMal2NM7xNhOTQz
nriaEPq8CZa0vANufpUxo0OcMKaXikIQ4nM+ZI8KxDjvQT5cnIM9Isb0er+WI8oux5dmmS8lVpqH
YmtsqZSYsKVCiMdIwFBRMVt6qObZ0p/AMzWyNf0ZJaJnG2CFyxIJKQbRN95PwD2aVvaz4E7CxoxT
DHP30cZ47IvQYY9nm3mIQSOgiNwyjBabYANV8DVA2/OcTkphDE6/AfvypDBlZGgzpki6QhrKybFc
B0sbxn/LocNZZ9keJGEZk5Nq7irz8Wm7l5wlzmbErX30Ets+8SDnJ3SF9rndKIRdwE0MxOD3oHBq
jwemyQT6rIQh5wzLGyQmIjHR9NSwIvwumZZxlOTKHcHZiyBQkZGHKBonvDKmlSCNuvIbM+5EU7if
tVn3H5w6+/Dk+sH8Yn8VeY+sEiD8LJXIasOrPne+kTZGD06tLighylQzYUXbpWFFdJg8ar9T4wiC
iIQSgDAAgu7Rg7LKngNDUFN84D4wehu0vPT3wzDXlf5Ryg+gBaYgwiPL/rFtlv0jpcdWSRLYRXqW
ZH/yBrfek5SjXHQWypEokxUIUXYBlyKXVrdNgBP6FIvTcHNYSfu+mOUxTuOmmSas48SLa0ruTRUk
INJFL/ADuRC6lfLWVQlkWw1+wGhVa/ADVAaPaMoC1vE4eeSBPNSTQTdkFXW5aIKuOQn373tEbENJ
+KDT5Tz4w1zJGTgk6odcKSrQ4iU2LpVYxZnrKp0N+34OhjhXzcDS1CM1wAesLTyvVhBZlWdwaoQg
vfk7qJ9tQSd6jDyS/mngqD9i0OlmFaVDni42jbKmr2g2++58lt7sd3GO7utsUtE0Y8lzEtBIRbM5
SHFgFsqQ1BsIeyuvNEM3SUWzOaRegrPM8vOxogknJQTkWYvugr05nlLgMNkSKpo2VDSN4ywcE+Hp
woqmdT8CWYoHMWrsnxl3c8hn51EVW/vu60ypSWPGnjhn9EwrAeCjrYhjF7gSd1AMoBwV9ghzLkB+
4ko4AyzElTkmMQe2YAxEEJUFx03s39PLoDMXoFmiBdP4f+eoAj0YaLwESDnZ3fd8RzlPKANg/D0J
TJriKM1qDMMtYNBN8EzGsYl8wKWoYMyrfVFdUVGprpvp8Vr3wGEnYQqgT+lgfAqc0AyVoqh2568x
4nuOph3Le1q7Iy/4q5CEFyQYHcqpU+dGy2uh9CkzpHcdTTfUDAPD+OwqrgHS2qHhS2t3AWQN5MB4
SjjjBrvIDaNvu4IbAnXluMGovbdDNTpXu8uyQzO/4zLpbQfxdUfzwaYJJ1o7H4QSgqpOA4z8zYCM
C7kGsfqQaaQVMWBhVP6wbNOELaTLpU9hNY0r6BdJapyHS1EDMCysoFdkaMFfTtKv2lA5uSnMWJDc
ZEa17zX7KekRU9R3OIhV66loO2MKYt6J7YwoMO4d2M5Ywhtsx6zfFA5+9Yzt6PVoU01vCv1RTAhK
7UxuFKcqsqKiLwKh01ACcoy71nYgcGI7Jgr0L7WdMNncds55uTO2o+XTyHbmvvci2wlywWb839jF
rdlOPVykxf7HGwf8j5F79nq3G7pc7H/qfeQ3fPo9Yj9sUC1IQj74RoFIEpnW0bVgcgdl3C/2P0Fn
kQ35OPZ6/0Mbim/bwzbJwGT4C22o3g9Xb7H/OWdF9W65cAGOpQSnE+PjtBwGDNHyOAwtmC/4lAj8
i12TdFShn3omerT5gvQetAn0oMuBbChasKGP1gknrxUYjFqYLsrDeZx8mI+l3ui40CPsKzJLboiB
PEczONYdcNd89QqRAZbgAVA8PqDLX+dp7CchCzbub+M3I52eDeVLjoSby6buiFewJgVG9IwGKJzb
5ophsxeWi/DtxiPNAyJKyRRF665KPhuYhutjnDVOMvmCIXsBb3wQX8sFbhTCTyl0+FSprg7XEGhd
JzKm5LQWgNTygdd7F7zX8slZTJ3+KPIBSF2l3zgYBzPJXDdcZWTBFGBkNjWypwGzqzYW0ZCWYBnW
XAjV8aM5KS8dxg9B9Lu6NFquDsM3G5f7++owhBCL+SazufHbuvDFX9bfF1JoeQ8hO3wxdzFoq/0B
KgqhlXF/QXCu5MyniBjHKyV6Q/YAJTNB1FIUmuil6FQ4mjZBFAcmN45vOBzzcRBe0OnRDcBB+B7y
YRBdSSpeqOzILQTFuuNEmuwH4Y17wLJUBt0QJZuuj7sVmxTANQ0O3tS6f+E4tMrH0K9XA4YQKunv
Q0EVLToeb9gX4jE0oOBB6yoXx/A8MJjayvryECyhwkj9z135fGWNIkClTHKEDAMtJhHHRZdDogb1
7rlroGo3r8ZYR8EzjB4AEEWy1FaabkJtBAv1h+P5+DX2x2modPQhTDia8KV1BYAavW6iknngimsu
AQHnNi/xDQKzULzxalyPb+A0mpUCSyXXp1c4jOZMgUXdhXxkqKedpoeVfJseX3+8FwWWqr28wFI1
uQLLE6JMEeSxadztB0DpDWwXmEpBr4kVwY4ZjZtDkF0W2QMrY8FAmUY/06DgtByM4Yv/cR3eDET3
Hz7N34awa/73RuGWrdRXxaxSkomciusqJVXpKyXTSr2URXytt8DDWqhflfoBdZnWLDkP9PUrqdRX
5bxSci7cr5JPII17O5jbCOZvh61yV8QJZIqscldeQbDljtRINBBVzCTXUFXu8U2Fr769FwRb7g6T
WPxc7a3sBnOPfdBQwb79YIE7o/rPAnfC3WX5p6yH9CgqM2RQUg83f5c74rL2vLHAP4oUAQ9ky2Vu
ZRNl0kQch/9a+accf9xwabmhlB9PTbFiXBoMMtCjt+MD0xYGfPR2uCG/ZSzJprvv+chxTMjmbjrk
YUbve+CO4Tpu8MBZ4UfphPHC9xSSxZAovMCr9VlURE+xnI1DGRJD1jRWwXJB38b9KQQB/HHc7RPe
u3JizMcMgh8MMLp4eInQOtk+1BD9hQ1l7fsgxZlzZRn5TucKyx5+yOm/DaI9ZjzASohdFtNiw/vh
AYruYg9w0J9q6Q3V58z2aWfhIfIARBB+nwSI3kR4GSs2+HfPaV/5uPBcio/Z7ojdMMi67xBVRvOF
9PAOiKcJpMMxM2sn7OsHR7m0mq7/SIfcRlloc5iVhaBgTlEViQb2f0iJQcgptIZwjyYtociFV9gl
2rg3jEcD5l/mEdwyUSZuDWOpXK1JkadmC6fZ0uefCD+VZWkdDn/+N0pWIofcyK/25De6la3L5AIh
dTX0FZSnh/TQRIpbHh233id7Z1PmeMMZ0Jf9ORAxZeADB6eShxWjn5lxyV4jlc9+BgktCmgKZW5k
c3RyZWFtCmVuZG9iago0OTcgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDQ0
NTk+PnN0cmVhbQp4Ab2c23IbxxGG7/cpNrzRMhFhHAkwqUpKtqxEimTJFiq+iHwR05YPEm0L8EHM
wyqvkl5M/18PdnZB0HGlXGWtdnp6uv8+TE/PQm/qj+s39Xj33+arerGol7NpvRhP60m9+bJ+2b6Z
j/MX76/r8Wg8Nor1ZT2Z72baH7uZq2p9Vb+3Xk9s9vpl3Xz0/Y9fbk/r9bdGZdQfrmubPUmr2R+L
+Xw0m7VLLuu9if+sm5+/Oa3OxqNp3XxzWvPwWb1+1LIZj84X2f9ayZf1cjyrp+ej8WRug5Nlkr8V
ZVy1BCsjmNfTuQgWiQDd90Q7Hxv1qpBqKqEmEupsflpLKuOw2uGxqi8Mo50cy8mi4OKTq2YsLvWp
aWO6Xv1LbzZbvZvqFdQsbmsnaOrTajefkQuN/NE5w4U5d33E1pksR8u6WfuLD6TkazFBqp/0Zvul
nr4L/TOlzX8m45FZxNAfLaqdK+0BHLRjIyggehjC7RT7Rct9L+EQBSm/EI2Q+1wvEFYjX6eRqmFk
i5v96EujtGmYUNaIuOjv34ubBi6Zi3A8iEaTXZTMz83yyZoB8qWokdLXrBukE+OT508e7KFXNR9I
g3JW6A18YLJBjVjeg7KH0Yk7gsV/mz3a+P/dLva7YY/pz1cr840U+cdOWZ73eMunO32rpsQS2FFK
MHVR6jMA+hcgY4erHwpsN0LLp1dhI41IiHIBrCAS/Ny8wcF/6eZlCC01CaE2GEpL+4uquWSomB6O
p1l39zyqbvbjs2qy+PRgKYUrVNtC85VA/Eo6Yq+tRJBu+jvGBkSNBGWKIyixGsk1NL05xKpGjIcT
C4ogP67DGwsrNyTAI9i/oQItZXBbPNtoYheNcDqfE06+A9tGimVAocDrTmvcSd2ACo7bRRRjwOMV
AgscdNmG0yQ7MAlMUFKT9/2qbiQAwlMWwOOV5ha0rKcRUcYqnmihBC2RaioCQKoRUZaSaUSU8Cgw
23Y9oWqABmLMU/AblMnVyfa5DewkXeQKhiIqQFlrkoSQT3ywO3M0orld/SOgHiv+yUkwYZ1ySPwf
+n754dqzlO1/k4k5dDhgKq8KQXqASx6BMsq1ttYN0beYdnamyqKvWBGMwxBD4VeTb06uKHtimrSH
o0R9d4n0jAFnEiiQLwQEEqZooUucFJqtlQ+eyy5F9h8MxQM2RDCYkzBPVPUwhPCSkeCE8ebVGS/h
7avlTi/ZSNyxL6ILQkb15uku0GJhggYh+4ol3wqZ9Z3AkjzIjNIaYYES9Etfs7rZv5Gu4P/UQ+V+
iryqefKJYvDZ7kBwvnO/G3x+Xtbut6wF3nM5tiQH0PpJaAEBJhJKFBCRsTQEtF2PPxNFFECbiCrK
gL84HDsE9mrays6zwzXt1GpaP84cW9NOrKbdPzlb5lg7MOCCQuwDV7wiipy6IvFIWTwflyhGrvWG
kPLYqBqGMI6SjebsyunepMuUjSIcsRXYYhIWwbBDtq+aYY0IaZDiTREH7GdvJQwAQRtnJHRhTKLL
y6DQwFO342OF13MC7WcO5cUW8OTZJ/J+MfqVefXubv2eFGbmSLvi7czh6b4IxWFzvGiAvzVIpJSq
r4gdWxFbtAMQEYtGwJMNC5swqxiR92ItwIDbW4SOIx7OiI8Iw7/Juh/pgTP3sxencvwt613BQW5X
xjlSE91ptcz1kTHgKAzDmqZ0avRIe4mVU+y6LbYOLaHZ+WhVNxuwvHw1hELVkFrhCK63Vd3drKN6
HQ0b0BGASBjJ3CXN8hfoQF2ggmWCT7ZWKg9HKXTKvaHtdQ7uDYuLKBFtb6iOaJEsVuUOWzfPwbcb
3ZQNoQWOhbNARDSdPPBc8FpZhxV4KKEDlsJKSuRZ6yOSKIxCRkQrjMny1E5bqxRT4mIWekQYsI9j
6JKT+BSL6kXp6QnvqMw5yoMF2ok7UuoFmRLR0nqRo8EThGDPm6g3kRJ+1kUYStNSDT7sexKP3d8B
q5obN+OsywDKm1dWQSnX06+38LHmfOrXL+ZtL6+/Y78jWdkNwbIl6e3Zt039vZay9ewXi0nP7sE2
y8OZNcol2/vrqujaLxZRxUUrhe76WElemKlvXzW37dsnT4Zz1rdPmQaR51ozc0GS9C5rs+PgEO56
mQUjQMyjhAAdpMViYfDlnft0R7IHc1DP50XV+gxvv4zOkHyOMD37s4Dbp3enNXqJhuMYTuE4Vjcc
dhs7/GdOk64fBi96Fj1XNMDOw5k9fVal66e+i57F1G7E8tsvq+Exa5/DuLK/jcNUjdqECPx/cZjJ
xfHuMrZYLhzmqefyv2duvfPmhz4gT5ETsZ3ReSA3/opOYHB1c5BDcVYSOqntkoQYZRxC/OjNKMnd
e7D1xgCByhrMSoJVUTpzqyASthEOZxF7UgtB2adYkgemR73zRrmG+WwX1hLpdMjQnF1LEkoKTAYX
URwQK9BGLfHDRtC4DFW0sFXjQkIlKi7DUiWKvkaG5A67b7eIh/65mm0iqwYrwvlFm3C7aUMSXlOo
wXE76rgXSV8Kjzpxg5ogwQav+h88tbDUZOBAMAA9Mhaz8RCNxC7UV6Z5JBazyKYruad0JedpAde1
aoSKBj7RVBW84HeuEZaZ6Y1n72q3Ke21gg6W+/PVDON2W0FV/5Y6X/bVL2s3KaYEasC/KXv+XrrI
xPDCxvB6BbFQKybh8xoZoMx6sKKI5Jl13bB1lx/GWKiilc0ZEWMUwVnFDF0dtyi0n4DkwTg+W59a
Kdqeg4uQtEPv8zJMowP/ru2L79dpj0/ti5eR9Vf/kQ+1/O2gWvKSfrguMpNwQnWpbOd1DyOo49wk
InAZNKcPWFkLG4nD9sMIUmBNBNQkC3wXSzLYiGq9gZBYXBBFUYr7xlQ14NWNAEU+aY8N4BGvMold
rLOPPdbKnW/DRnmNylt1ibmq0V1UprFv9kzS0MmHb5Gewc42XzWl2e3TqC5LUjpn49ihiGtBznRw
wGCIQUHShdXNnh0pxFZqwQz2GsEdANdF6bvtfC0lERfGSLl9z60V7mmdBzflVQFBHZeqhcezClKD
G/lk2KWEARGFiKZ7+Hdfw3O+O+J2S4CjXEOrIrKALgQFTB6YY65jqWdRNaNO4XBfBoBU7K95gyE1
hEExloQEEUbwMU0WKezTQNXERccmLu6IZ00DfOZHnSFOQibYXGl1Au2BA0FpsBAS83hwJ+NNN06Q
ATFxuXBWSVVoAFhdWvtIo8wZsduU9bS0U0cu+2BM94jW3cUm+LrKfPQQI8mKOnHOFwmx5GzjNirn
FmGRfRJKc2E+66uMI7pDYlbDnwI9hJTUELskWYNSqfy2Vd40VXnVLQrDSV+V95D4SwcscjqgEW1E
MSoLehT2wjrL0wwxmwd2tt4vsths3Of5CEiL9ocnUGMq8r8OHrIKkYvlxJq1NijPkcHf9BUnQKZ4
F7+bVqz4su3eRwr2e7sMaR/IikmkFWRBWVamX61ZEuVWqcdPJVW0krqnkhBLCyGLVtRA+nvVICO5
CRMxpDm86EHO/aHlcjiYZxd9NVzkNtJW3BIhUfYVWeqVFoLg2D4nyvthUo1ITTDTwJ02GidZQ4FV
iBoewCi+HBEb+OIOWRAkfWSlW/hF1fRtSR6nc/ntWQDMosjDpy1xs0fwFZCjO1YpEs/XKrugZSsp
TwqsBD/ZwQXNfBSJoUUZTRLYpJGAkm9ImATR4GykE4XvuJZowtIQbdETzZE0R+mGCFn1NUcjHCQK
aEhnDegGwo6o6VV2S4ysIkbSbST8qJZzqXetWNUCQMf8rhQhcLATjc+u4gcd4IRxJOBxO0rVFBMH
8WE3hYLw9Yfhz6mwOg8j9uoUw3/yv784TamwtxjovcuYLdry4eBtxqytz29xnzHrvbyaKi2QOuwS
LLW0UnuyuASbnfeVYPRdxmIofwsX/J/vNHxn+Q3uNLIOOhVE7N/mgYpLKs/ZeXtL33cJ1nd8my3s
pw6da59HsZKcX47tkRNbVNTlfedVTb/b8TcCUJVU1lWLGIyORewEh5oHYoaba2uS9BKHRFBklvCB
H7QhcF4h8objXgsggXzrdoez7k4o+b+QTPBHgS1C3dnt/PHpriajNDb8mdmiwS5wu5ZKTO+Dwf1d
bL5VaOFI8Q2SaFhKC6QBOyznUsm7+3trs9lF4bzbSzlLFjqRj1GsSL0nGDq2SbpFJFuEu9qedL2a
HF1idemvInCAkf0XibAuD2xpoxRILSy9OXoAp6l+oNjt4+9/gRA5ZFLedD7sxDDaYkk0YcgVyE6p
aAKQUcAN2wYgKEOZLn+SG5XYl2yT4cIWxVzWw4ExDvyV3OW3GLSbdeLohyQ8MIk3/IJIij113B8r
qPo+wBTxH/SQZlXNfc3a/z7avvK9OOL3BaAM7uJfQAapwq9ulInwCzIP2oodgFNsR6JnDGPAkGYp
sSu5AJbZxZp4KbHJJIXrEd+Qz8azIgdFmweRSSAEgFRHYxDUiPbWLHwOfoUGg2INPmHNWBVEWq4+
5oOpz7UVsWhX6qxTd4PUvnsgUDevYpbChBh345OzCzuaA3IJiCXpMPJwY+ltuDWpgMSn1bPPO1Hm
xeloF8DRoE5/r9Ww3m1xxzffphf24eWuYDsyl0+X5SZJa5gAOsJRwQ8zdGyfHY2ijgItoByaXjfR
f9hsrrkBhB5WMuBTT433+5Pcsr2kTLTWCGF92MAYQxKlZBhmQWyMug6b47B/VwrQEjmqG25ss2Mg
jA6sL04IjWR2ck6t11ikJCoVAg9tXO4LVQMcWpOUCd/r3WWwNRe7QQuFqVLtg/KYC2TUhBplCCBb
O6rAviPM9FzVTdyvwg82PDgA0dQHkdLBYVMgwQg1OQtEptjGSQ1NWQ1N43dpdHvghUPwRm1+url8
7aA853PsF9LUKqzF6hFqqMbDNSyT3bO41hpyiNt+HZb8czjxso9ji/Ynen4eYppLmiX7u53iFLjg
A5KlJdQfklKRvMq7obAomMYrt81tP7SZ2j8+0p/SBz6zmc7LmuPegS6/g3Bo85dhcRlQR0/yxN3O
N1yQAm3BDfQjOORbRBILcZ0TxBBFdwBymU1mxOQaCDZv5EpsdwjGTY3kwtvgV2ilBR5xvNcb5KVw
xiNF8kifauhFZG22hjo6hES1yCVNzyc33WhAA2oiN1l2PyB2OADIBHxaGu304hdtiYxgQ9bW7qI5
mCAC3E2abYhGHMm/7551av9CS7d/lbUffKfuGLeOz1IlTSFEBn2ZbjQrSmbMC2xnZS4jUPAKod61
GDji5SygtSEx+3T6L+J6jC27Usa+iCbIIL7ogQwOkcqtWr9uzFI0XOD7TvzIGzCGWNqyzeJPJS0J
SpMiWWjXpNiujvoXXqb2fXh/Zh5onEzHy+IT8XvdzIwpUcFiI5VIChLHKL8bBhKhJi17ijINAdbL
TsrG6rhI/B7nUCgkxuEjTMeoWhrXKPNo3ndMBQFAbPe7KlkQQhKzQWRQKoToYnZD4Ho8AR+Ls6QY
4rqoSeZzM2ch8I7pMBQfXrAmtIGoi1UmZMIPNtHx1ApYCLm6SeehF1F32j/tn5/ATyVBuYwKpLKX
hh6ajC22/M5B3g6t7U/5lU7P72snF6qVeop9LeW2OFC32j9I4UVlCSZDEk/HqpNsY/HZbCwA/y4q
ayHPmHPO6jC+d8R9MJNWR5xSUlU8ZRTihKBezmbIzZqd91izVAb58I5RchtS63G/DJ2sVMMe2ceY
LNX4CMs/cI/91P+UB9vf0/fOwy5uicdcPJKJfIewAwOZURSg7QBmX3+KRFMgBTVRXF7HsY9BSyYp
H2o+MmhaWDH6o0xnI0jUt8rSbAg8wJZiBYvj0PEJXvHNBaJLF8ciS4dUox2SrDzDGqaSWdR61vcQ
kBu6TFIPy1LSt8HA/DWrKXVt3H6wZ//c37SelW5Gec9KCIGanQ+f2bkyfVEGNrHpCgKGUEGmp+NK
bP/VvR4ZeGByKXnptCy5CWA+/i+WAuyWCmVuZHN0cmVhbQplbmRvYmoKMzMxIDAgb2JqCjw8L0xl
bmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5kc3RyZWFtCmVuZG9iago2IDAgb2Jq
Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4g
L0ZvbnQgPDwgL1RUMSA4IDAgUgo+Pi9YT2JqZWN0PDwvR1JGb3JtMCA0NzIgMCBSPj4+PgplbmRv
YmoKMzM5IDAgb2JqCjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5kc3Ry
ZWFtCmVuZG9iagoyMiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj
ZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4vWE9iamVjdDw8L0dSRm9y
bTAgNDczIDAgUj4+Pj4KZW5kb2JqCjM0NCAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9H
UkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKMjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERG
IC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBS
Cj4+L1hPYmplY3Q8PC9HUkZvcm0wIDQ3NCAwIFI+Pj4+CmVuZG9iagozNTQgMCBvYmoKPDwvTGVu
Z3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjMwIDAgb2Jq
Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4g
L0ZvbnQgPDwgL1RUMSA4IDAgUgo+Pi9YT2JqZWN0PDwvR1JGb3JtMCA0NzUgMCBSPj4+PgplbmRv
YmoKMzU5IDAgb2JqCjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5kc3Ry
ZWFtCmVuZG9iagozNCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj
ZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4vWE9iamVjdDw8L0dSRm9y
bTAgNDc2IDAgUj4+Pj4KZW5kb2JqCjM2MSAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9H
UkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKMzggMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERG
IC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBS
Cj4+L1hPYmplY3Q8PC9HUkZvcm0wIDQ3NyAwIFI+Pj4+CmVuZG9iagozNjMgMCBvYmoKPDwvTGVu
Z3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjQzIDAgb2Jq
Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4g
L0ZvbnQgPDwgL1RUMSA4IDAgUgo+Pi9YT2JqZWN0PDwvR1JGb3JtMCA0NzggMCBSPj4+PgplbmRv
YmoKMzY4IDAgb2JqCjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5kc3Ry
ZWFtCmVuZG9iago1MSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj
ZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4vWE9iamVjdDw8L0dSRm9y
bTAgNDc5IDAgUj4+Pj4KZW5kb2JqCjM3MiAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9H
UkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNTUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERG
IC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBS
Cj4+L1hPYmplY3Q8PC9HUkZvcm0wIDQ4MCAwIFI+Pj4+CmVuZG9iagozNzYgMCBvYmoKPDwvTGVu
Z3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjU5IDAgb2Jq
Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4g
L0ZvbnQgPDwgL1RUMSA4IDAgUgo+Pi9YT2JqZWN0PDwvR1JGb3JtMCA0ODEgMCBSPj4+PgplbmRv
YmoKMzc4IDAgb2JqCjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5kc3Ry
ZWFtCmVuZG9iago2MyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj
ZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4vWE9iamVjdDw8L0dSRm9y
bTAgNDgyIDAgUj4+Pj4KZW5kb2JqCjM4MCAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9H
UkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKNjcgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERG
IC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBS
Cj4+L1hPYmplY3Q8PC9HUkZvcm0wIDQ4MyAwIFI+Pj4+CmVuZG9iagozODMgMCBvYmoKPDwvTGVu
Z3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjcxIDAgb2Jq
Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4g
L0ZvbnQgPDwgL1RUMSA4IDAgUgo+Pi9YT2JqZWN0PDwvR1JGb3JtMCA0ODQgMCBSPj4+PgplbmRv
YmoKMzg3IDAgb2JqCjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5kc3Ry
ZWFtCmVuZG9iago4NCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj
ZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4vWE9iamVjdDw8L0dSRm9y
bTAgNDg1IDAgUj4+Pj4KZW5kb2JqCjM4OSAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9H
UkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKODggMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERG
IC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBS
Cj4+L1hPYmplY3Q8PC9HUkZvcm0wIDQ4NiAwIFI+Pj4+CmVuZG9iagozOTQgMCBvYmoKPDwvTGVu
Z3RoIDE2Pj5zdHJlYW0KcQovR1JGb3JtMCBEbwpRCgplbmRzdHJlYW0KZW5kb2JqCjkyIDAgb2Jq
Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4g
L0ZvbnQgPDwgL1RUMSA4IDAgUgo+Pi9YT2JqZWN0PDwvR1JGb3JtMCA0ODcgMCBSPj4+PgplbmRv
YmoKMzk3IDAgb2JqCjw8L0xlbmd0aCAxNj4+c3RyZWFtCnEKL0dSRm9ybTAgRG8KUQoKZW5kc3Ry
ZWFtCmVuZG9iago5NiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj
ZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4vWE9iamVjdDw8L0dSRm9y
bTAgNDg4IDAgUj4+Pj4KZW5kb2JqCjM5OSAwIG9iago8PC9MZW5ndGggMTY+PnN0cmVhbQpxCi9H
UkZvcm0wIERvClEKCmVuZHN0cmVhbQplbmRvYmoKMTA5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAg
Ugo+Pi9YT2JqZWN0PDwvR1JGb3JtMCA0ODkgMCBSPj4+PgplbmRvYmoKNDAwIDAgb2JqCjw8L1R5
cGUvUGFnZS9QYXJlbnQgMTM0IDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQW5ub3RzWzQwMSAw
IFIgNDAyIDAgUiA0MDMgMCBSXS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFIvVFQyIDQ2
NiAwIFI+Pj4+L0NvbnRlbnRzIDQ5MCAwIFI+PgplbmRvYmoKNDA0IDAgb2JqCjw8L1R5cGUvUGFn
ZS9QYXJlbnQgMTM0IDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQW5ub3RzWzQwNSAwIFIgNDA2
IDAgUiA0MDcgMCBSXS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFIvVFQyIDQ2NiAwIFI+
Pj4+L0NvbnRlbnRzIDQ5MSAwIFI+PgplbmRvYmoKNDA4IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJl
bnQgMTM0IDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQW5ub3RzWzQwOSAwIFIgNDEwIDAgUiA0
MTEgMCBSIDQxMiAwIFIgNDEzIDAgUiA0MTQgMCBSXS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxIDQ2
MyAwIFIvVFQyIDQ2NiAwIFI+Pj4+L0NvbnRlbnRzIDQ5MiAwIFI+PgplbmRvYmoKNDE1IDAgb2Jq
Cjw8L1R5cGUvUGFnZS9QYXJlbnQgMTM0IDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQW5ub3Rz
WzQxNiAwIFIgNDE3IDAgUiA0MTggMCBSIDQxOSAwIFIgNDIwIDAgUiA0MjEgMCBSIDQyMiAwIFIg
NDIzIDAgUiA0MjQgMCBSXS9SZXNvdXJjZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFIvVFQyIDQ2NiAw
IFI+Pj4+L0NvbnRlbnRzIDQ5MyAwIFI+PgplbmRvYmoKNDI1IDAgb2JqCjw8L1R5cGUvUGFnZS9Q
YXJlbnQgMTM0IDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQW5ub3RzWzQyNiAwIFIgNDI3IDAg
UiA0MjggMCBSIDQyOSAwIFIgNDMwIDAgUiA0MzEgMCBSIDQzMiAwIFIgNDMzIDAgUl0vUmVzb3Vy
Y2VzPDwvRm9udDw8L1RUMSA0NjMgMCBSL1RUMiA0NjYgMCBSPj4+Pi9Db250ZW50cyA0OTQgMCBS
Pj4KZW5kb2JqCjQzNCAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDEzNCAwIFIvTWVkaWFCb3hb
MCAwIDYxMiA3OTJdL0Fubm90c1s0MzUgMCBSIDQzNiAwIFIgNDM3IDAgUiA0MzggMCBSIDQzOSAw
IFIgNDQwIDAgUiA0NDEgMCBSIDQ0MiAwIFIgNDQzIDAgUl0vUmVzb3VyY2VzPDwvRm9udDw8L1RU
MSA0NjMgMCBSL1RUMiA0NjYgMCBSPj4+Pi9Db250ZW50cyA0OTUgMCBSPj4KZW5kb2JqCjQ0NCAw
IG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDEzNCAwIFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Fu
bm90c1s0NDUgMCBSIDQ0NiAwIFIgNDQ3IDAgUiA0NDggMCBSIDQ0OSAwIFIgNDUwIDAgUiA0NTEg
MCBSIDQ1MiAwIFIgNDUzIDAgUiA0NTQgMCBSIDQ1NSAwIFIgNDU2IDAgUiA0NTcgMCBSXS9SZXNv
dXJjZXM8PC9Gb250PDwvVFQxIDQ2MyAwIFIvVFQyIDQ2NiAwIFI+Pj4+L0NvbnRlbnRzIDQ5NiAw
IFI+PgplbmRvYmoKNDU4IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTM0IDAgUi9NZWRpYUJv
eFswIDAgNjEyIDc5Ml0vQW5ub3RzWzQ1OSAwIFIgNDYwIDAgUiA0NjEgMCBSIDQ2MiAwIFJdL1Jl
c291cmNlczw8L0ZvbnQ8PC9UVDEgNDYzIDAgUi9UVDIgNDY2IDAgUj4+Pj4vQ29udGVudHMgNDk3
IDAgUj4+CmVuZG9iagoxMzQgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9NZWRpYUJveCBbMCAwIDYx
MiA3OTJdL0NvdW50IDM5IC9LaWRzWyAzIDAgUiA0MCAwIFIgNzMgMCBSCjEwNiAwIFIgNDAwIDAg
UiA0MDQgMCBSIDQwOCAwIFIgNDE1IDAgUiA0MjUgMCBSIDQzNCAwIFIgNDQ0IDAgUiA0NTggMCBS
XT4+CmVuZG9iagp4cmVmCjAgMwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAxNDE1NzIgMDAwMDAg
biAKMDAwMDE0MTkwNSAwMDAwMCBuIAo2IDEKMDAwMDIzNjIwMSAwMDAwMCBuIAoxOSAxCjAwMDAx
NDIwNzQgMDAwMDAgbiAKMjIgMgowMDAwMjM2MzkwIDAwMDAwIG4gCjAwMDAxNDIyNzAgMDAwMDAg
biAKMjYgMgowMDAwMjM2NTgwIDAwMDAwIG4gCjAwMDAxNDI0NDIgMDAwMDAgbiAKMzAgMgowMDAw
MjM2NzcwIDAwMDAwIG4gCjAwMDAxNDI2NTQgMDAwMDAgbiAKMzQgMgowMDAwMjM2OTYwIDAwMDAw
IG4gCjAwMDAxNDI4MjYgMDAwMDAgbiAKMzggMgowMDAwMjM3MTUwIDAwMDAwIG4gCjAwMDAxNDI5
NzQgMDAwMDAgbiAKNDMgMQowMDAwMjM3MzQwIDAwMDAwIG4gCjQ4IDEKMDAwMDE0MzEyMyAwMDAw
MCBuIAo1MSAyCjAwMDAyMzc1MzAgMDAwMDAgbiAKMDAwMDE0MzI5NiAwMDAwMCBuIAo1NSAyCjAw
MDAyMzc3MjAgMDAwMDAgbiAKMDAwMDE0MzQ2MSAwMDAwMCBuIAo1OSAyCjAwMDAyMzc5MTAgMDAw
MDAgbiAKMDAwMDE0MzYyNiAwMDAwMCBuIAo2MyAyCjAwMDAyMzgxMDAgMDAwMDAgbiAKMDAwMDE0
Mzc3NSAwMDAwMCBuIAo2NyAyCjAwMDAyMzgyOTAgMDAwMDAgbiAKMDAwMDE0MzkyNCAwMDAwMCBu
IAo3MSAxCjAwMDAyMzg0ODAgMDAwMDAgbiAKODEgMQowMDAwMTQ0MDgxIDAwMDAwIG4gCjg0IDIK
MDAwMDIzODY3MCAwMDAwMCBuIAowMDAwMTQ0MjQ2IDAwMDAwIG4gCjg4IDIKMDAwMDIzODg2MCAw
MDAwMCBuIAowMDAwMTQ0Mzk1IDAwMDAwIG4gCjkyIDIKMDAwMDIzOTA1MCAwMDAwMCBuIAowMDAw
MTQ0NTY4IDAwMDAwIG4gCjk2IDEKMDAwMDIzOTI0MCAwMDAwMCBuIAoxMDUgMQowMDAwMTQ0NzI1
IDAwMDAwIG4gCjEwOSAxCjAwMDAyMzk0MzAgMDAwMDAgbiAKMTM0IDEKMDAwMDI0MTEyNCAwMDAw
MCBuIAoxNDEgMQowMDAwMTQxNjY0IDAwMDAwIG4gCjE0MyAxCjAwMDAxNDIwMjMgMDAwMDAgbiAK
MTU3IDEKMDAwMDE0MjE5NSAwMDAwMCBuIAoxNzYgMQowMDAwMTQyMzkxIDAwMDAwIG4gCjE4NyAx
CjAwMDAxNDI1NjMgMDAwMDAgbiAKMjEyIDEKMDAwMDE0Mjc3NSAwMDAwMCBuIAoyMjcgMQowMDAw
MTQyOTQ3IDAwMDAwIG4gCjIzMiAxCjAwMDAxNDMwOTYgMDAwMDAgbiAKMjM1IDEKMDAwMDE0MzI0
NSAwMDAwMCBuIAoyNTIgMQowMDAwMTQzNDE4IDAwMDAwIG4gCjI2MiAxCjAwMDAxNDM1ODMgMDAw
MDAgbiAKMjcyIDEKMDAwMDE0Mzc0OCAwMDAwMCBuIAoyNzUgMQowMDAwMTQzODk3IDAwMDAwIG4g
CjI4MCAxCjAwMDAxNDQwNDYgMDAwMDAgbiAKMjg5IDEKMDAwMDE0NDIwMyAwMDAwMCBuIAozMDAg
MQowMDAwMTQ0MzY4IDAwMDAwIG4gCjMwMyAxCjAwMDAxNDQ1MTcgMDAwMDAgbiAKMzE1IDEKMDAw
MDE0NDY5MCAwMDAwMCBuIAozMjIgMQowMDAwMTQ0ODUxIDAwMDAwIG4gCjMyNSAxNzMKMDAwMDE0
MTgwNSAwMDAwMCBuIAowMDAwMTQxODU1IDAwMDAwIG4gCjAwMDAxNDUwMDcgMDAwMDAgbiAKMDAw
MDE0NTI2OSAwMDAwMCBuIAowMDAwMTQ1NTM0IDAwMDAwIG4gCjAwMDAxNDU3OTcgMDAwMDAgbiAK
MDAwMDIzNjEzNiAwMDAwMCBuIAowMDAwMTQ2MDU4IDAwMDAwIG4gCjAwMDAxNDYzMTkgMDAwMDAg
biAKMDAwMDE0NjU4MCAwMDAwMCBuIAowMDAwMTQ2ODQxIDAwMDAwIG4gCjAwMDAxNDcxMDQgMDAw
MDAgbiAKMDAwMDE0NzM3MCAwMDAwMCBuIAowMDAwMTQ3NjM2IDAwMDAwIG4gCjAwMDAyMzYzMjUg
MDAwMDAgbiAKMDAwMDE0NzkwMCAwMDAwMCBuIAowMDAwMTQ4MTYxIDAwMDAwIG4gCjAwMDAxNDg0
MjIgMDAwMDAgbiAKMDAwMDE0ODY4MyAwMDAwMCBuIAowMDAwMjM2NTE1IDAwMDAwIG4gCjAwMDAx
NDg5NDQgMDAwMDAgbiAKMDAwMDE0OTIwNSAwMDAwMCBuIAowMDAwMTQ5NDY2IDAwMDAwIG4gCjAw
MDAxNDk3MjkgMDAwMDAgbiAKMDAwMDE0OTk5MiAwMDAwMCBuIAowMDAwMTUwMjUzIDAwMDAwIG4g
CjAwMDAxNTA1MTYgMDAwMDAgbiAKMDAwMDE1MDc3NyAwMDAwMCBuIAowMDAwMTUxMDM4IDAwMDAw
IG4gCjAwMDAyMzY3MDUgMDAwMDAgbiAKMDAwMDE1MTI5OSAwMDAwMCBuIAowMDAwMTUxNTYwIDAw
MDAwIG4gCjAwMDAxNTE4MjMgMDAwMDAgbiAKMDAwMDE1MjA4NyAwMDAwMCBuIAowMDAwMjM2ODk1
IDAwMDAwIG4gCjAwMDAxNTIzNTAgMDAwMDAgbiAKMDAwMDIzNzA4NSAwMDAwMCBuIAowMDAwMTUy
NjE0IDAwMDAwIG4gCjAwMDAyMzcyNzUgMDAwMDAgbiAKMDAwMDE1Mjg3NyAwMDAwMCBuIAowMDAw
MTUzMTQxIDAwMDAwIG4gCjAwMDAxNTM0MDIgMDAwMDAgbiAKMDAwMDE1MzY2NSAwMDAwMCBuIAow
MDAwMjM3NDY1IDAwMDAwIG4gCjAwMDAxNTM5MzEgMDAwMDAgbiAKMDAwMDE1NDE5NyAwMDAwMCBu
IAowMDAwMTU0NDYwIDAwMDAwIG4gCjAwMDAyMzc2NTUgMDAwMDAgbiAKMDAwMDE1NDcyMSAwMDAw
MCBuIAowMDAwMTU0OTg0IDAwMDAwIG4gCjAwMDAxNTUyNDUgMDAwMDAgbiAKMDAwMDIzNzg0NSAw
MDAwMCBuIAowMDAwMTU1NTA2IDAwMDAwIG4gCjAwMDAyMzgwMzUgMDAwMDAgbiAKMDAwMDE1NTc2
NyAwMDAwMCBuIAowMDAwMjM4MjI1IDAwMDAwIG4gCjAwMDAxNTYwMjggMDAwMDAgbiAKMDAwMDE1
NjI5MSAwMDAwMCBuIAowMDAwMjM4NDE1IDAwMDAwIG4gCjAwMDAxNTY1NTcgMDAwMDAgbiAKMDAw
MDE1NjgyMSAwMDAwMCBuIAowMDAwMTU3MDgyIDAwMDAwIG4gCjAwMDAyMzg2MDUgMDAwMDAgbiAK
MDAwMDE1NzM0MyAwMDAwMCBuIAowMDAwMjM4Nzk1IDAwMDAwIG4gCjAwMDAxNTc2MDQgMDAwMDAg
biAKMDAwMDE1Nzg2NyAwMDAwMCBuIAowMDAwMTU4MTMyIDAwMDAwIG4gCjAwMDAxNTgzOTYgMDAw
MDAgbiAKMDAwMDIzODk4NSAwMDAwMCBuIAowMDAwMTU4NjU3IDAwMDAwIG4gCjAwMDAxNTg5MTgg
MDAwMDAgbiAKMDAwMDIzOTE3NSAwMDAwMCBuIAowMDAwMTU5MTgwIDAwMDAwIG4gCjAwMDAyMzkz
NjUgMDAwMDAgbiAKMDAwMDIzOTU1NiAwMDAwMCBuIAowMDAwMTQ0ODc4IDAwMDAwIG4gCjAwMDAx
NDUxMzggMDAwMDAgbiAKMDAwMDE0NTQwMyAwMDAwMCBuIAowMDAwMjM5NzIxIDAwMDAwIG4gCjAw
MDAxNDU2NjggMDAwMDAgbiAKMDAwMDE0NTkyOCAwMDAwMCBuIAowMDAwMTQ2MTg5IDAwMDAwIG4g
CjAwMDAyMzk4ODYgMDAwMDAgbiAKMDAwMDE0NjQ1MCAwMDAwMCBuIAowMDAwMTQ2NzExIDAwMDAw
IG4gCjAwMDAxNDY5NzIgMDAwMDAgbiAKMDAwMDE0NzIzOCAwMDAwMCBuIAowMDAwMTQ3NTA0IDAw
MDAwIG4gCjAwMDAxNDc3NzAgMDAwMDAgbiAKMDAwMDI0MDA3NSAwMDAwMCBuIAowMDAwMTQ4MDMx
IDAwMDAwIG4gCjAwMDAxNDgyOTIgMDAwMDAgbiAKMDAwMDE0ODU1MyAwMDAwMCBuIAowMDAwMTQ4
ODE0IDAwMDAwIG4gCjAwMDAxNDkwNzUgMDAwMDAgbiAKMDAwMDE0OTMzNiAwMDAwMCBuIAowMDAw
MTQ5NTk3IDAwMDAwIG4gCjAwMDAxNDk4NjMgMDAwMDAgbiAKMDAwMDE1MDEyMyAwMDAwMCBuIAow
MDAwMjQwMjg4IDAwMDAwIG4gCjAwMDAxNTAzODYgMDAwMDAgbiAKMDAwMDE1MDY0NyAwMDAwMCBu
IAowMDAwMTUwOTA4IDAwMDAwIG4gCjAwMDAxNTExNjkgMDAwMDAgbiAKMDAwMDE1MTQzMCAwMDAw
MCBuIAowMDAwMTUxNjkxIDAwMDAwIG4gCjAwMDAxNTE5NTcgMDAwMDAgbiAKMDAwMDE1MjIxOCAw
MDAwMCBuIAowMDAwMjQwNDkzIDAwMDAwIG4gCjAwMDAxNTI0ODQgMDAwMDAgbiAKMDAwMDE1Mjc0
NSAwMDAwMCBuIAowMDAwMTUzMDExIDAwMDAwIG4gCjAwMDAxNTMyNzIgMDAwMDAgbiAKMDAwMDE1
MzUzMyAwMDAwMCBuIAowMDAwMTUzNzk5IDAwMDAwIG4gCjAwMDAxNTQwNjUgMDAwMDAgbiAKMDAw
MDE1NDMzMSAwMDAwMCBuIAowMDAwMTU0NTkxIDAwMDAwIG4gCjAwMDAyNDA3MDYgMDAwMDAgbiAK
MDAwMDE1NDg1NCAwMDAwMCBuIAowMDAwMTU1MTE1IDAwMDAwIG4gCjAwMDAxNTUzNzYgMDAwMDAg
biAKMDAwMDE1NTYzNyAwMDAwMCBuIAowMDAwMTU1ODk4IDAwMDAwIG4gCjAwMDAxNTYxNTkgMDAw
MDAgbiAKMDAwMDE1NjQyNSAwMDAwMCBuIAowMDAwMTU2NjkxIDAwMDAwIG4gCjAwMDAxNTY5NTIg
MDAwMDAgbiAKMDAwMDE1NzIxMyAwMDAwMCBuIAowMDAwMTU3NDc0IDAwMDAwIG4gCjAwMDAxNTc3
MzUgMDAwMDAgbiAKMDAwMDE1ODAwMSAwMDAwMCBuIAowMDAwMjQwOTUxIDAwMDAwIG4gCjAwMDAx
NTgyNjYgMDAwMDAgbiAKMDAwMDE1ODUyNyAwMDAwMCBuIAowMDAwMTU4Nzg4IDAwMDAwIG4gCjAw
MDAxNTkwNDkgMDAwMDAgbiAKMDAwMDE1OTMxMSAwMDAwMCBuIAowMDAwMTYwMDM1IDAwMDAwIG4g
CjAwMDAxNjAwODkgMDAwMDAgbiAKMDAwMDE2MDE0MSAwMDAwMCBuIAowMDAwMTYwMzA5IDAwMDAw
IG4gCjAwMDAxNjA1NTEgMDAwMDAgbiAKMDAwMDE3NzEwOCAwMDAwMCBuIAowMDAwMTc3MzQ5IDAw
MDAwIG4gCjAwMDAxNzc2NDIgMDAwMDAgbiAKMDAwMDE4MDU4NCAwMDAwMCBuIAowMDAwMTgyMjY0
IDAwMDAwIG4gCjAwMDAxODQyNDAgMDAwMDAgbiAKMDAwMDE4NTc5MiAwMDAwMCBuIAowMDAwMTg4
ODE1IDAwMDAwIG4gCjAwMDAxOTA0NTUgMDAwMDAgbiAKMDAwMDE5MTIwMCAwMDAwMCBuIAowMDAw
MTkxODU0IDAwMDAwIG4gCjAwMDAxOTM1MjkgMDAwMDAgbiAKMDAwMDE5NDg1NiAwMDAwMCBuIAow
MDAwMTk1OTMzIDAwMDAwIG4gCjAwMDAxOTY1OTEgMDAwMDAgbiAKMDAwMDE5NzMwNCAwMDAwMCBu
IAowMDAwMTk4MzcyIDAwMDAwIG4gCjAwMDAxOTk3NzEgMDAwMDAgbiAKMDAwMDIwMDQyNCAwMDAw
MCBuIAowMDAwMjAyMDk2IDAwMDAwIG4gCjAwMDAyMDMxMTAgMDAwMDAgbiAKMDAwMDIwMzY5OSAw
MDAwMCBuIAowMDAwMjA0OTE3IDAwMDAwIG4gCjAwMDAyMTAwMjAgMDAwMDAgbiAKMDAwMDIxNTEx
MCAwMDAwMCBuIAowMDAwMjE5NTE3IDAwMDAwIG4gCjAwMDAyMjM4MzYgMDAwMDAgbiAKMDAwMDIy
ODQxMiAwMDAwMCBuIAowMDAwMjMxNjA1IDAwMDAwIG4gCnRyYWlsZXIKPDwvU2l6ZSA0OTgvUHJl
diAxMzcyMjMvUm9vdCAxMzUgMCBSL0luZm8gMSAwIFIvSURbPDU0MTczYWEzYjFiNWQxMTQ1Yjg3
MjY1YjIwMTQ1YjJkPjwxOTBFOUREOUI2RTdFMTg5NTA3N0I4QjBFRTBENEM1MD5dPj4Kc3RhcnR4
cmVmCjI0MTI5MgolJUVPRgo=

--Apple-Mail-C88126A4-C6C2-4016-AEDB-24B595C5CBE3
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit




Sent from my iPad
--Apple-Mail-C88126A4-C6C2-4016-AEDB-24B595C5CBE3--


From nobody Mon Mar 10 12:32:44 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63741A0538 for ; Mon, 10 Mar 2014 12:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOaLb_SWtuFS for ; Mon, 10 Mar 2014 12:32:39 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id C05AF1A056D for ; Mon, 10 Mar 2014 12:32:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 989B2660120; Mon, 10 Mar 2014 12:32:32 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.147.142] (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 071EB66011F; Mon, 10 Mar 2014 12:32:30 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-3EA1AD34-840A-4AEC-86F3-5C9F66DBADC5
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (11B651)
In-Reply-To: 
Date: Mon, 10 Mar 2014 20:32:26 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <33A31C2B-CD52-4FF6-B376-325237B7C585@thomasclausen.org>
References: 
To: Abdussalam Baryun 
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rGXTqYAm9duefxb-aTHPTfn-5Jo
Cc: manet , gerla 
Subject: Re: [manet] ODMRP new draft (was Re:  IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 19:32:42 -0000

--Apple-Mail-3EA1AD34-840A-4AEC-86F3-5C9F66DBADC5
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Dear Abdussalam,


> On 10 mars 2014, at 17:48, Abdussalam Baryun  w=
rote:
>=20
> Hi Axel,
>=20
> Thanks for your presentation. I had a question at meeting but there was no=
 time. =46rom the presentation (still I did not done review), there was one s=
lide showing two paths to its destination, so does this multicast protocol u=
se multipath to reach all its demanded destinations? And how does it optimis=
e overhead?
>=20

Having now reviewed the document in detail, let me venture a reply ;)

I believe that, no, multiple paths to the same destination are not sought no=
r used. Of course, to multiple destinations, multiple paths (but with common=
 path segments, as possible) result.

I am interested, Abdussalam, have you read the document, and what are your d=
etailed comments?

Thomas

> AB
>=20
>> On Monday, March 10, 2014, Axel Colin de Verdi=C3=A8re wrote:
>> Hi all,
>>=20
>> We did not in fact request WG adoption for ODMRP and ODMRP_ASYM at this t=
ime, but we felt that the drafts were in good enough shape to ask for your c=
omments and move in that direction.
>>=20
>> Axel
>>=20
>>> Le 10 mars 2014 =C3=A0 17:08, Abdussalam Baryun  a =C3=A9crit :
>>>=20
>>> Hi Thomas,
>>>=20
>>> Thanks for the update. I don't think the latest multicast draft was requ=
ested to be adopted in the meeting, but Ulrich did request his it for his dr=
aft, and I am waiting for announce on the list for DLEP plan and all adoptio=
n request in WG meeting.=20
>>>=20
>>> AB
>>>=20
>>> On Monday, March 10, 2014, Thomas Clausen wrote:
>>> Ulrich,
>>>=20
>>> Thank you for prompt posting of minutes.
>>> =20
>>> A couple of things that I would like to make more precise, all the same,=
 in the minutes:
>>>=20
>>>> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>>>=20
>>> 
>>>> Teco: Why not make this document standards track?
>>>> CD: If people implement this and it's great.  Then I'm find  fine chang=
ing this to standards track if that's the case.
>>>> TC: I do not think as a working group that we should go down the standa=
rds track document without many implementations as that has happened in othe=
r places within the IETF and document quality has suffered.
>>> I honestly do not think that Chris would make that typo, even when speak=
ing ;)
>>>> CD: If it gets stuck in the queue for 4 years we may have enough experi=
ence that we may want to push for standards track.
>>>> Rick Taylor: Is there any record of this for this draft being experimen=
tal and then changing to standards track later down the line?
>>>> CD: We will post something up on the list.
>>>> TC: I think that experimental should have an explanation on what the ex=
periment is and what the successful experiment is and what the conclusion is=
.
>>>> Ulrich: Do you have intention to add a description of what those experi=
ments are and what will make them successful?
>>>> Adrian Farrel: Yes, he does have that intention.
>>> As it reads in the above, it sounds as if I'm making a demand, that Adri=
an is committing Chris to satisfy. That's not exactly how it went down, so p=
erhaps we should clarify that in the minutes?
>>>=20
>>>=20
>>>=20
>>> I'd like to go on record here, that I did not say that it "should have a=
n explanation" to cater to my whim, but that I (as I actually stated at the m=
ike) I was reciting what I had heard was an IESG statement/requirement (so: I=
 thought it was the IESGs whim to be satisfied).
>>>=20
>>>=20
>>>=20
>>>=20
>>> Adrian then clarified this, that it was not an "IESG statement/requireme=
nt" as such, but that the current routing ADs (which include him, so his whi=
m) who require this"
>>>=20
>>>=20
>>>=20
>>>=20
>>> 
>>>=20
>>>>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>>>=20
>>> 
>>>> Henning: It will also not break anything if different values are used a=
s the values are unit-less so the routes might be crazy but they will work.
>>>> TC: I think experimental is exactly the place for this document
>>>> Emmanuel: I would like to comment to Rick's earlier comment about if th=
is is related to OLSRv2.  It uses building blocks such as sequence numbers i=
n RFC5444 and missed NHDP HELLO messages to calculate the metric, so in that=
 regard it could be used with other protocols and is not only tied to OLSRv2=
.
>>>> CD: There needs to be a section describing the experiments.=20
>>>> TC: I think this draft should be focused to OLSRv2 (and not other proto=
cols) and not make it something overly broad and have it stall out.
>>>> Henning: For AODV this metric would be a problem as there isn't normall=
y control traffic or any unicast traffic on a link, so there is nothing to m=
easure.
>>>=20
>>>=20
>>> I believe that what I said was that my experience with both proactive an=
d reactive protocol deployments leave me to believe that metrics "make sense=
 in very different ways in these two protocol families", and therefore would=
 need to be considered separately. Specifically, constructing an "experiment=
 for a metric for a proactive protocol" (which, as this is going Experimenta=
l, is a requiremen
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--Apple-Mail-3EA1AD34-840A-4AEC-86F3-5C9F66DBADC5
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Dear Abdussalam,

<=
div>
On 10 mars 2014, at 17:48, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote=
:

Hi Axel,

Th=
anks for your presentation. I had a question at meeting but there w=
as no time. =46rom the presentation (still I did not done review), ther=
e was one slide showing two paths to its destination, so does this=
 multicast protocol use multipath to reach all its demanded destination=
s? And how does it optimise overhead?





Having now reviewed the doc=
ument in detail, let me venture a reply ;)

I believe that=
, no, multiple paths to the same destination are not sought nor used. Of cou=
rse, to multiple destinations, multiple paths (but with common path segments=
, as possible) result.

I am interested, Abdussalam,=
 have you read the document, and what are your detailed comments?
=

Thomas

AB

On Monday, March 10, 2014, Axel Colin de Verdi=C3=A8re  wro=
te:


Hi all,

We did not in fact request WG adoption for ODMRP a=
nd ODMRP_ASYM at this time, but we felt that the drafts were in good enough s=
hape to ask for your comments and move in that direction.



Axel

Le 10 mars 2014 =C3=A0 17:08, Ab=
dussalam Baryun <abdussalambaryun@gmail.com> a =C3=A9crit :

Hi Thomas,

Thanks for t=
he update. I don't think the latest multicast draft was requested to be=
 adopted in the meeting, but Ulrich did request his it for his draft,&n=
bsp;and I am waiting for announce on the list for DLEP plan a=
nd all adoption request in WG meeting. 





AB

On Monday, March 10, 2014, Thomas Clausen  wro=
te:
Ulrich,


Thank you for prompt posting of minutes.
 
A couple of things that I would like to make more precise, all the sa=
me, in the minutes:

o draft-ietf-manet-olsrv=
2-multitopology: Dearlove

<SNIP>
Teco: Why not make this docum=
ent standards track?
CD: If people implement this and it's great.  Then I'm find  fine<=
/font> changing this to standards track if that's the case.
TC: I do not think as a working group that we should go down the standards t=
rack document without many implementations as that has happened in other pla=
ces within the IETF and document quality has suffered.




I honestly do not think that Chris would make that typo, even when spea=
king ;)
CD: If it gets stuck in the queue for 4 years we may have enough experience=
 that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being experimental a=
nd then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the experim=
ent is and what the successful experiment is and what the conclusion is.
Ulrich: Do you have intention to add a description of what those experiments=
 are and what will make them successful?
Adrian Farrel: Yes, he does have that intention.
As it reads in the above, it sounds as if=
 I'm making a demand, that Adrian is committing Chris to satisfy. That's not=
 exactly how it went down, so perhaps we should clarify that in the minutes?=





I'd like to go on record here, that I did not say that it "should have a=
n explanation" to cater to my whim, but that I (as I actually stated at the m=
ike) I was reciting what I had heard was an IESG statement/requirement (so: I=
 thought it was the IESGs whim to be satisfied).





Adrian then clarified this, that it was not an "IESG sta=
tement/requirement" as such, but that the current routing ADs (which include=
 him, so his whim) who require this"





<SNIP>

 o draft-rogge-baccelli-ol=
srv2-ett-metric: Rogge

=
<SNIP>
<=
/pre>
Henning: It will also not break anything if different=
 values are used as the values are unit-less so the routes might be crazy bu=
t they will work.
TC: I think experimental is exactly the place for this docume=
nt
Emmanuel: I would like to comment to Rick's earlier comment about if this is=
 related to OLSRv2.  It uses building blocks such as sequence numbers in RFC=
5444 and missed NHDP HELLO messages to calculate the metric, so in that rega=
rd it could be used with other protocols and is not only tied to OLSRv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to OLSRv2 (=
and not other protocols) and not make it something overly broad and have it s=
tall out.
Henning: For AODV this metric would be a problem as there isn't norma=
lly control traffic or any unicast traffic on a link, so there is nothing to=
 measure.


I believe that what I said was that my experience with both proactive and re=
active protocol deployments leave me to believe that metrics "make sense in v=
ery different ways in these two protocol families", and therefore would need=
 to be considered separately. Specifically, constructing an "experiment for a=
 metric for a proactive protocol" (which, as this is going Experimental, is a=
 requiremen






____________________=
___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai=
lman/listinfo/manet
=

--Apple-Mail-3EA1AD34-840A-4AEC-86F3-5C9F66DBADC5--


From nobody Mon Mar 10 15:00:43 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011181A04F8 for ; Mon, 10 Mar 2014 15:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MoQ-B_4nAf1 for ; Mon, 10 Mar 2014 15:00:37 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8626A1A04F6 for ; Mon, 10 Mar 2014 15:00:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 1649E7613AF; Mon, 10 Mar 2014 15:00:32 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.1.47] (cha75-1-78-192-0-189.fbxo.proxad.net [78.192.0.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C51F61C0730; Mon, 10 Mar 2014 15:00:29 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D5EBB47C-6E8C-43C9-901F-D14E8B4208DE"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
In-Reply-To: <33A31C2B-CD52-4FF6-B376-325237B7C585@thomasclausen.org>
Date: Mon, 10 Mar 2014 23:00:27 +0100
Message-Id: 
References:  <33A31C2B-CD52-4FF6-B376-325237B7C585@thomasclausen.org>
To: Thomas Heide Clausen 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RrJjqmj4da_8ZEnkfUoLyKRnKQI
Cc: manet , gerla 
Subject: Re: [manet] ODMRP new draft (was Re:  IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 22:00:40 -0000

--Apple-Mail=_D5EBB47C-6E8C-43C9-901F-D14E8B4208DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi Abdussalam, Thomas,

Thank you for your comments. Indeed there are no multiple paths =
involved. Can you point me to the slide you're referring to? What do you =
mean by "optimise overhead"?

Axel

Le 10 mars 2014 =E0 20:32, Thomas Heide Clausen  =
a =E9crit :

> Dear Abdussalam,
>=20
>=20
> On 10 mars 2014, at 17:48, Abdussalam Baryun =
 wrote:
>=20
>> Hi Axel,
>>=20
>> Thanks for your presentation. I had a question at meeting but there =
was no time. =46rom the presentation (still I did not done review), =
there was one slide showing two paths to its destination, so does this =
multicast protocol use multipath to reach all its demanded destinations? =
And how does it optimise overhead?
>>=20
>=20
> Having now reviewed the document in detail, let me venture a reply ;)
>=20
> I believe that, no, multiple paths to the same destination are not =
sought nor used. Of course, to multiple destinations, multiple paths =
(but with common path segments, as possible) result.
>=20
> I am interested, Abdussalam, have you read the document, and what are =
your detailed comments?
>=20
> Thomas
>=20
>> AB
>>=20
>> On Monday, March 10, 2014, Axel Colin de Verdi=E8re wrote:
>> Hi all,
>>=20
>> We did not in fact request WG adoption for ODMRP and ODMRP_ASYM at =
this time, but we felt that the drafts were in good enough shape to ask =
for your comments and move in that direction.
>>=20
>> Axel
>>=20
>> Le 10 mars 2014 =E0 17:08, Abdussalam Baryun =
 a =E9crit :
>>=20
>>> Hi Thomas,
>>>=20
>>> Thanks for the update. I don't think the latest multicast draft was =
requested to be adopted in the meeting, but Ulrich did request his it =
for his draft, and I am waiting for announce on the list for DLEP plan =
and all adoption request in WG meeting.=20
>>>=20
>>> AB
>>>=20
>>> On Monday, March 10, 2014, Thomas Clausen wrote:
>>> Ulrich,
>>>=20
>>> Thank you for prompt posting of minutes.
>>> =20
>>> A couple of things that I would like to make more precise, all the =
same, in the minutes:
>>>=20
>>>> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>>>=20
>>> 
>>>> Teco: Why not make this document standards track?
>>>> CD: If people implement this and it's great.  Then I'm find  fine =
changing this to standards track if that's the case.
>>>> TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.
>>> I honestly do not think that Chris would make that typo, even when =
speaking ;)
>>>> CD: If it gets stuck in the queue for 4 years we may have enough =
experience that we may want to push for standards track.
>>>> Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
>>>> CD: We will post something up on the list.
>>>> TC: I think that experimental should have an explanation on what =
the experiment is and what the successful experiment is and what the =
conclusion is.
>>>> Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
>>>> Adrian Farrel: Yes, he does have that intention.
>>> As it reads in the above, it sounds as if I'm making a demand, that =
Adrian is committing Chris to satisfy. That's not exactly how it went =
down, so perhaps we should clarify that in the minutes?
>>>=20
>>>=20
>>>=20
>>> I'd like to go on record here, that I did not say that it "should =
have an explanation" to cater to my whim, but that I (as I actually =
stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).
>>>=20
>>>=20
>>>=20
>>>=20
>>> Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"
>>>=20
>>>=20
>>>=20
>>>=20
>>> 
>>>=20
>>>>  o draft-rogge-baccelli-olsrv2-ett-metric: Rogge
>>>=20
>>> 
>>>> Henning: It will also not break anything if different values are =
used as the values are unit-less so the routes might be crazy but they =
will work.
>>>> TC: I think experimental is exactly the place for this document
>>>> Emmanuel: I would like to comment to Rick's earlier comment about =
if this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
>>>> CD: There needs to be a section describing the experiments.=20
>>>> TC: I think this draft should be focused to OLSRv2 (and not other =
protocols) and not make it something overly broad and have it stall out.
>>>> Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.
>>>=20
>>>=20
>>> I believe that what I said was that my experience with both =
proactive and reactive protocol deployments leave me to believe that =
metrics "make sense in very different ways in these two protocol =
families", and therefore would need to be considered separately. =
Specifically, constructing an "experiment for a metric for a proactive =
protocol" (which, as this is going Experimental, is a requiremen
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet


--Apple-Mail=_D5EBB47C-6E8C-43C9-901F-D14E8B4208DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Hi =
Abdussalam, Thomas,

Thank you for your comments. =
Indeed there are no multiple paths involved. Can you point me to the =
slide you're referring to? What do you mean by "optimise =
overhead"?

Axel

Le 10 =
mars 2014 =E0 20:32, Thomas Heide Clausen <ietf@thomasclausen.org> a =
=E9crit :

Dear Abdussalam,


On =
10 mars 2014, at 17:48, Abdussalam Baryun <abdussalambaryun@gmail.com&=
gt; wrote:

Hi =
Axel,

Thanks for your presentation. I had a =
question at meeting but there was no time. =46rom the presentation =
(still I did not done review), there was one slide showing two =
paths to its destination, so does this multicast protocol use =
multipath to reach all its demanded destinations? And how does it =
optimise =
overhead?


Hav=
ing now reviewed the document in detail, let me venture a reply =
;)

I believe that, no, multiple paths to the same =
destination are not sought nor used. Of course, to multiple =
destinations, multiple paths (but with common path segments, as =
possible) result.

I am interested, Abdussalam, =
have you read the document, and what are your detailed =
comments?

Thomas

AB

On Monday, March 10, 2014, Axel Colin de =
Verdi=E8re wrote:
Hi all,

We did not =
in fact request WG adoption for ODMRP and ODMRP_ASYM at this time, but =
we felt that the drafts were in good enough shape to ask for your =
comments and move in that =
direction.

Axel

Le 10 =
mars 2014 =E0 17:08, Abdussalam Baryun =
<abdussalambaryun@gmail.com> a =E9crit =
:

Hi Thomas,

Thanks for the update. =
I don't think the latest multicast draft was requested to =
be adopted in the meeting, but Ulrich did request his it for his =
draft, and I am waiting for announce on the list for DLEP =
plan and all adoption request in =
WG meeting. 

AB

On Monday, =
March 10, 2014, Thomas Clausen wrote:
Ulrich,

Thank you =
for prompt posting of minutes.
 
A couple of =
things that I would like to make more precise, all the same, in the =
minutes:

o =
draft-ietf-manet-olsrv2-multitopology: Dearlove

<SNIP>
Teco: Why not make this document =
standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's =
the case.
TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.
I honestly do not think that Chris =
would make that typo, even when speaking ;)
CD: If it gets stuck in the queue for 4 years we may have =
enough experience that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
Adrian Farrel: Yes, he does have that =
intention.
As it reads in the above, it sounds as if I'm =
making a demand, that Adrian is committing Chris to satisfy. That's not =
exactly how it went down, so perhaps we should clarify that in the =
minutes?




I'd like to go on record here, that I did not say that it "should =
have an explanation" to cater to my whim, but that I (as I actually =
stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it was the IESGs whim to be =
satisfied).





Adrian then clarified this, that it was not an "IESG =
statement/requirement" as such, but that the current routing ADs (which =
include him, so his whim) who require this"





<SNIP>

 o =
draft-rogge-baccelli-olsrv2-ett-metric: Rogge

<SNIP>
Henning: It will =
also not break anything if different values are used as the values are =
unit-less so the routes might be crazy but they will =
work.
TC: I think experimental is exactly the place for this =
document
Emmanuel: I would like to comment to Rick's earlier comment about if =
this is related to OLSRv2.  It uses building blocks such as sequence =
numbers in RFC5444 and missed NHDP HELLO messages to calculate the =
metric, so in that regard it could be used with other protocols and is =
not only tied to OLSRv2.
CD: There needs to be a section describing the experiments.=20
TC: I think this draft should be focused to =
OLSRv2 (and not other protocols) and not make it something overly broad =
and have it stall out.
Henning: For AODV this metric would be a problem as there isn't =
normally control traffic or any unicast traffic on a link, so there is =
nothing to measure.


I believe that what I said was that my experience with both proactive =
and reactive protocol deployments leave me to believe that metrics "make =
sense in very different ways in these two protocol families", and =
therefore would need to be considered separately. Specifically, =
constructing an "experiment for a metric for a proactive protocol" =
(which, as this is going Experimental, is a requiremen


=


_______________________________________________=

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

=

--Apple-Mail=_D5EBB47C-6E8C-43C9-901F-D14E8B4208DE--


From nobody Mon Mar 10 15:01:40 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E531A063D for ; Mon, 10 Mar 2014 15:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXg1X2rvviak for ; Mon, 10 Mar 2014 15:01:34 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id A63391A0647 for ; Mon, 10 Mar 2014 15:01:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8660A7613CB; Mon, 10 Mar 2014 15:01:27 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.1.47] (cha75-1-78-192-0-189.fbxo.proxad.net [78.192.0.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 05A4B7613C8; Mon, 10 Mar 2014 15:01:25 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
In-Reply-To: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>
Date: Mon, 10 Mar 2014 23:01:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>
To: thomas Clausen 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ca_c-gCDqT-WviS0BKAfEZH2kcA
Cc: MANET IETF 
Subject: Re: [manet] draft-gerla-manetodmrp-02 review
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 22:01:37 -0000

Hi Thomas,

Thanks a lot for this thorough review. I'll need a moment to go through =
it and get back to you though :).

Best,

Axel

Le 10 mars 2014 =E0 19:43, Thomas Heide Clausen =
 a =E9crit :

> Dear All,
>=20
> As the authors requested feedback, I have given the most recent =
version of this document a review. My comments are below - but do also =
look at the attached PDF, it's easier to see where each comment applies =
in there ;)
>=20
> For those not wanting to read the whole review: I think that this is a =
well written document, I think it's an interesting idea, and I think =
it's worth taking further, so I'd encourage further further reviews and =
work.
>=20
> There are a few things that need to be addressed, though. Outside the =
obvious, 'security considerations' and 'the experiment', the main issue =
is "multiple interfaces and addresses". While the protocol, as I =
understand it, can work in multiple interfaces/addresses scenarios, I =
think that the specification is unclear on certain things such as which =
addresses go in which information sets (such as the Blacklist) and =
messages.
>=20
> Either way, see below, and see the file attached to this message - and =
I look forward to discussing this further with all y'all.
>=20
> Cheers,
>=20
> Thomas
>=20
> File: draft-gerla-manet-odmrp-02 - flattened.pdf
>=20
> Annotation summary:
>=20
> --- Page 1 ---
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> General Comments:
>=20
> I find this specification very well written, well structured, clear =
and easy to understand.=20
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Executive Summary:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> I find this specification very well written, well structured, clear, =
and easy to understand. I believe that there are some clarifications =
that could be made, though, and a few "formal" things to correct - but =
also that the protocol specification is fairly straight-forward.
>=20
> Now, the one point that I think is needing a bit of effort is =
regarding routers with multiple interfaces and/or multiple addresses, =
which seems to not be fully specified. At least, it should be made clear =
which parts of the information base are per interface, and the =
processing adopted accordingly. The way the "blacklist", for example, is =
written actually permits an implementation to explicitly "do the wrong =
thing" when faced with routers with multiple interfaces. I think that =
it's fairly easy to clear up.
>=20
>=20
> General Comments:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> I think I understand the general idea, though, of the way the =
specification is made: you describe, in abstract form, the protocol, =
signals, etc., and then you provide the mapping to RFC5444-elements in =
an appendix.
>=20
> That is not entirely stupid as idea, and the resulting document is =
actually nice and readable, but.....appendices can't (or, shouldn't) =
contain normative text. Indeed, there are many MUST/SHOULD/* in Appendix =
A.=20
>=20
> I suggest promoting Appendix A to a "numbered section" somewhere =
(perhaps after section 7?)=20
>=20
> While I know that it is early, I think it would be helpful to have =
some reflections on the security considerations. Recent experiences with =
the SEC-ADs indicate, that they're considerably more strict than they =
were even half a decade ago, so understanding "what we're getting =
ourselves into" if the WG gets involved with this protocol might be =
helpful.
>=20
> As was discussed during the MANET wg meeting in London, an =
EXPERIMENTAL document is supposed to enable an experiment, and that =
experiment should be documented. See e.g. RFC6971, section 1.2. I'll try =
to add a couple of my thoughts on what would make for good =
"experiments":
>=20
> I do believe that, perhaps, a distinguishing point of ODMRP vs. SMF =
and other such protocols: whereas these rely on "get a copy of the =
message to each router, then have the router decide if it delivers those =
to applications", ODMRP works by only getting copies of messages to =
routers that actually need it. So, an experiment establishing the =
boundaries where "efforts to constructing the overlay" are out-weighted =
by the benefits of not having to deliver a copy of the multicast message =
to each router.
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> Mobile Ad hoc Networking (MANET)
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> "Network Working Group" -- see RFC Editor tutorial slides, page 20
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> conventional tree-based,
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Now that I have thought this bit over....
>=20
> In the end, a tree is constructed, though, is it not? Join Queries =
flooded, then Join Replies sent back, in a "Tree-construction" fashion?
>=20
>=20
>=20
>=20
> --- Page 4 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> routing                    techniques to avoid
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> So, it is actually not clear what this means, specifically. The more I =
think about it, the less do I think of this as "on demand routing =
techniques" and the more do I think of this as "on-demand tree =
construction, with proactive maintenance",
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> The more I think about it, the less do I think of this as "on demand =
routing techniques" and the more do I think of this as "on-demand tree =
construction, with proactive maintenance",
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> The more I think about it, the less do I think of this as "on demand =
routing techniques" and the more do I think of this as "on-demand tree =
construction, with proactive maintenance".
>=20
> It is clear, that a sensible routing protocol creates and manages =
forwarding trees/graphs/groups only when there is an actual need for one =
to exist - so, in that regard, all sensible multicast routing protocols =
are "reactive".
>=20
> As I understand it, this protocol is generating the forwarding =
tree/graph/group from the (expected) source, and then that this is =
maintained by way of proactive signaling (for as long as there is a need =
for the forwarding tree/graph/group)
>=20
> I'd suggest being explicit as to this, both in introduction and in the =
abstract?
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> I think that you actually also are importing terminology from RFC5444 =
here, are you not?  At least, section 7 "Packets and Messages" seems to =
be hinting at - but not calling out explicitly - that you are.
>=20
> I think I understand why you're not calling it out, with the way that =
the I-D is written and RFC5444 message mapping being in Appendix, but as =
I have suggested in "general comments", that organization might not be =
ideal?
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> e.g.
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Technically, that's probably "i.e., " as there are only those two =
message types, yes?
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> I would suggest answering the question, which is on everybody's lips, =
already here: does this integrate with "regular IP Multicasting" or does =
it require "application level tunneling"?=20
>=20
> In other words, could I expect an mcast-capable application to "just =
work", and can I implement this "on a commodity OS", or will I have to =
do kernel-level hacks?
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> I would suggest answering the question, which is on everybody's lips, =
already here: does this integrate with "regular IP Multicasting" or does =
it require "application level tunneling"?=20
>=20
> In other words, could I expect an mcast-capable application to "just =
work", and can I implement this "on a commodity OS", or will I have to =
do kernel-level hacks to make it work?
>=20
> Having read through the document, I think that I infer that it's =
possible to build an user-space implementation manipulating working by =
simply multicast routing table entries.
>=20
> Would be good to have it confirmed that my understanding is correct - =
if it is, that is ;)
>=20
>=20
> --- Page 5 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> addresses
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> I am going to pick out this here, but it applies elsewhere also: =
"addresses"?=20
>=20
> I believe that you aim at "address length independence", v6/v4/short, =
and that's a good idea which is, I believe, supported well by RFC5444. =
Alas, I believe that you probably want to stick in a definition and =
explanation of that in here.=20
>=20
> Also, I gather that these addresses are "interface identifiers" and =
not "multicast group addresses", yes? Given that this document talks =
about multicast, I do recommend perhaps calling this out?
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> I actually would love for you to repeat the example text for =
"Upstream" here, also. Yeah, it's repetitive, but when reading through a =
document and looking for a definition, it's nice to not be hunting.
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> I am repeating my comment from the introduction here:
>=20
> The more I think about it, the less do I think of this as "on demand =
routing techniques" or a "reactive" protocol, and the more do I think of =
this as "on-demand tree construction, with proactive maintenance".
>=20
> It is clear, that a sensible routing protocol creates and manages =
forwarding trees/graphs/groups only when there is an actual need for one =
to exist - so, in that regard, all sensible multicast routing protocols =
are "reactive".
>=20
> As I understand it, this protocol is generating the forwarding =
tree/graph/group from the (expected) source, and then that this is =
maintained by way of proactive signaling (for as long as there is a need =
for the forwarding tree/graph/group)
>=20
> I'd suggest being explicit as to this, both in introduction and in the =
abstract?
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Just to be clear; am I correct in understanding that:
>=20
> A Multicast Group Address, is used by applications, and joined (etc) =
by way of IGMP/MLD.
>=20
> The ODMRP router hearing these,  maps that to a "Multicast Session".
>=20
> That ODMRP router then proceeds to construct a Multicast Overlay for =
that multicast session; the Multicast Overlay of a multicast session is =
a source-rooted multicast tree?
>=20
> Also, as I understand it, "Forwarding Group" and "Multicast Overlay" =
are, respectively, "links" and "routers" for a given Multicast Session?
>=20
> I think that thats what it is, but the relationship between these =
terms/concepts  could merit being rendered crystal clear here.
>=20
>=20
> --- Page 6 ---
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Suggest adding "These multicast overlays are, then, proactively =
maintained for as long as the overlay is needed (as long as there are =
members in the multicast group AND as long as there is data to be =
delivered to the multicast group)"
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> IIRC there's a space after and before a "dash"......
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> overlay only
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> -> "overlay, only"
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Correct, but not complete. The overlay is created, trigged by data to =
deliver to the members - but, no overlay is actually created unless =
there actually are members of the destination set.=20
>=20
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> overlay for
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> -> "overlay only for...."
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> and until there no longer are members of the multicast group?
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Suggest "if the router belongs to, i.e., has attached hosts which have =
subscribed to, the multicast group ..."=20
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> originates
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> This is a really detail-oriented comment, but "originates a Join =
Reply" here - and "Join Reply Generation" as the section title for =
section 9.1.2 is a little incoherent ;)=20
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> I'd proffer that a lot this perhaps should be going in the "Signaling =
Overhead" rather than in this section; in part, as you describe messages =
and sets, before these are defined.
>=20
> As overview, it's quite too detailed, so perhaps jumping straight to =
4.2 and merging 4.1 into 4.3 is the best approach?
>=20
> Or, perhaps, have 4.2, then 4.3 and finally 4.1 ?
>=20
>=20
> --- Page 7 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> carried
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> This is too "implicit": a "next hop address carried in a packet". You =
should, at least, in the previous bullet point indicate that a Join =
Reply carries a "next hop address" (and, possibly, what else it carries =
- I think that for duplicate JR suppression, that's important?)
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> it
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Suggest "If that next hop address is an address of this router..."
>=20
> Also, what does "is an address of" or "corresponds to" this router =
mean, precisely? This may sound like a slightly silly question ;) but in =
NHDP/OLSRv2 we've had to be extremely careful with to what addresses =
correspond: a router, interfaces on that router, or addresses of hosts =
reachable by way of this router.
>=20
> The upshot of this is, that it's really easy to sort out, for example: =
"Is an address of an interface of this router", or something.
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> ,
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> For readability, given that this is the overview and functioning:
>=20
> "If , , , then this ODMRP Router =
belongs to the forwarding group for the multicast session. Consequently, =
it installs ..."=20
>=20
>=20
> A secondary comment here is, that you have defined "Multicast Session" =
in the terminology, but you're not using it here (rather, you say =
"......Forwarding Group, which correspondS [sic] to this multicast group =
and source..."
>=20
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> This is confusing. What is actually discarded here? I.e., what does =
"it" correspond to"?
>=20
>=20
> --- Page 8 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> flooded periodically
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Suggest adding that/if that can be done by way of an optimized =
flooding operation, if available on the network.
>=20
>=20
> --- Page 9 ---
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> This probably needs a bit more of explanation. As I indicated in the =
general comments, the separation of abstract message content, and =
5444-encoding is a possible way to go, but it is not clear at this point =
that that's what's being done.
>=20
> As a consequence, it is not clear why the section title is "Packets =
and Messages" - those are (in MANET) 5444-constructs, typically.
>=20
> One possibility could be to stick Appendix A after section 7. Another, =
to have appendix A be a subsection to section 7.
>=20
>=20
>=20
>=20
> --- Page 11 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> Multicast Source
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Somewhat of the same comment as one I have made before: "the address =
of the Multicast Source"
>=20
> First, is the "Multicast Source" the router, through which the =
multicast data messages ingress through, or is it the host on which the =
application generating data, is? Does it make any difference? "Multicast =
Source" is not defined.
>=20
> Second, what about multiple interfaces/addresses?=20
>=20
> I can probably infer how it should be: this is the IP address that one =
will find in the source-address field of IP multicast datagrams, yes? If =
so, perhaps just call that out somewhere so there's no doubt.
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> address of the neighbor ODMRP Router
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Jumping on this just once more. "The address of the neighbor ODMRP =
router..."
>=20
> The way it is written, one gets the impression that ODMRP is designed =
for single-interface-single-address routers.=20
>=20
> I do not *think* that this is the case, and it certainly does not have =
to be made a constraint, so I recommend clearing that up. (Conversely, =
if it is the case, call that out as a constraint in applicability =
section). This applies actually through the document, so looking at =
giving it a pass through with "remove doubts as to multi-if/addr" as =
objective would be great.
>=20
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> R_source
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Why is it P_multicast_source, but this is R_source?
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> =46rom this description, it appears that it all is "per router" and =
with no "per interface" sets, is that correct?
>=20
> As I have indicated for the "Blacklist" this may be problematic, or at =
least necessitate some extra care to specify completely.
>=20
>=20
> --- Page 12 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> Multicast Source
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> See previous question regarding Multicast Source
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Contrary to previous...._source, this is unambiguous ;)
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> F_source
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Why is it P_multicast_source, but this is F_source?
>=20
>=20
> --- Page 13 ---
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> I would probably say "...over which the Join Reply was sent"
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> an
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> ODMRP Routers
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> What if two routers, A and B, have two interfaces a1, a2, b1, b2?
>=20
> If A can hear B over a
>=20
>=20
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> What if two routers, A and B, have two interfaces a1, a2, b1, b2?
>=20
> If A can hear B over (a1, b1) and B can hear A over (a2, b2), what =
addresses go into this set?
>=20
> Also, what if A can hear B over (a1, b1) (and B can hear A over the =
same pair), and A can hear B over (a1,b2) but B cannot....?
>=20
> In other words, is this set per interface or per router?
>=20
> And, what are the addresses you put in there, interface addresses, or =
"RouterIDs"?
>=20
>=20
>=20
> --- Page 14 ---
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Alright, so reading this, it seems that the blacklist must be "per =
interface", yes?
>=20
>=20
> --- Page 15 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> an address
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Which address? Any? Always the same? Does it matter?
>=20
>=20
> --- Page 16 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> an address
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Which address? Any? Always the same? Does it matter?
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> neighbors
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> I assume that what you want is to forward to all the neighbors on all =
ODMRP interfaces of this router, yes?
>=20
>=20
>=20
> --- Page 19 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> neighbors
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Over all ODMRP Interfaces?
>=20
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Here, we are gleaning a bit more precisely what the R_source is; so =
its an interface of an ODMRP router over which the Join Reply was sent, =
yes?
>=20
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> Else
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Else -> "Otherwise, if a tuple exists, ..."
>=20
>=20
> --- Page 20 ---
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> "Otherwise, ..."
>=20
>=20
> --- Page 21 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> Else
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> ->Otherwise
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Really nit-picking, but " i.e. " -> " i.e., " is the RFC-Editor =
style....
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Suggest: "...run in conjunction with, and benefit from some of the =
features of, SMF..."
>=20
> Strikeout (red), 10 mars 2014 19:24, TClausen:
> and                benefit from some of its features.
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> I would be hesitant to call this section "SMF Considerations"
>=20
> While SMF is an important and useful protocol set, I would suggest =
that this section be generalized: what's at stake is, and I think that I =
saw that in the slides that were presented in the London IETF, that if =
there's a "more efficient than classic flooding" network-wider broadcast =
operation in place, then ODMRP would/should use it - correct?
>=20
> This might be by way of SMF, or it could be as an extension to =
OLSRv2's MPR flooding, or it could be (as is seen in for example HNCP) =
something based off of Trickle - or something entirely different.
>=20
> So, perhaps "Flooding considerations" as section title, and a bit =
generalized text would work?
>=20
>=20
> --- Page 22 ---
>=20
> Highlight (yellow), 10 mars 2014 19:24, TClausen:
> Packets
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Packets -> Packet
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> OK, I think that this document should start by actually requesting the =
allocations for the two message types. Cf. how it is done in section =
18.2 of RFC6130
>=20
> Then, I *think* that the current 15.1 is the Message-Type-Specific TLV =
Type Registries" that are being set up, for Join-Query yes? I see =
"Expert Review" mentioned, but no guidelines/recommendations for the =
Expert to follow. Do you intend to mirror those from RFC5444, or are =
there special concerns to take into consideration?
>=20
> I would actually suggest mirroring the structure of the IANA section =
from RFC6130  if for no other reasons, than that it's allocating from =
RFC5444-registries, and has been going through the process and so it may =
be assumed that something mirroring it will, too. ;)
>=20
>=20
>=20
> --- Page 25 ---
>=20
> Note (yellow), 10 mars 2014 19:24, TClausen:
> Just a comment, a cursory review of the mapping to RFC5444 doesn't =
have anything jump at me screaming "problems", which is good.
>=20
> I was wondering one thing, though: if running OLSRv2 + ODMRP, then =
there's an obvious option which could be considered (and could be =
considered, in order to be disregarded)....
>=20
> Could one imagine carrying ODMRP signals inside TC messages in any =
meaningful way, as TLVs and additional addresses included? *technically* =
it should be possible, does it make sense?
>=20
> A second thing, is there any reason to request both JR and JQ message =
type, or is there a way of using just a single code-point, and are there =
potential benefits in doing so?
>=20
> A different way of phrasing the above is: given that code-points by =
definition are limited, I'd like to ask for a bit more of =
"justification" before they are allocated.
>=20
> FWIW, I've not had the cycles to review the appendices, other than =
Appendix A.
>=20
>=20
> (report generated by GoodReader)
>=20
>=20
>=20
> 
>=20
>=20
> Sent from my iPad_______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From nobody Mon Mar 10 15:14:11 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBCA1A04C5 for ; Mon, 10 Mar 2014 15:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PnvBoHw7Mya for ; Mon, 10 Mar 2014 15:14:05 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id B2E221A024B for ; Mon, 10 Mar 2014 15:14:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9501B7612E0; Mon, 10 Mar 2014 15:14:00 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.147.142] (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 66D6676150F; Mon, 10 Mar 2014 15:13:58 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (11B651)
In-Reply-To: 
Date: Mon, 10 Mar 2014 23:13:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org>
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org> 
To: =?utf-8?Q?Axel_Colin_de_Verdi=C3=A8re?= 
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/M7I_rtgupETBxN1futDiDOd5iwI
Cc: MANET IETF 
Subject: Re: [manet] draft-gerla-manetodmrp-02 review
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Mar 2014 22:14:09 -0000

> On 10 mars 2014, at 23:01, Axel Colin de Verdi=C3=A8re  wrote:
>=20
> Hi Thomas,
>=20
> Thanks a lot for this thorough review.

I know, I know. I am a pain in the behind like that ;)

> I'll need a moment to go through it and get back to you though :).
>=20

Please do - especially, if there's something that's unclear that needs more e=
xplanation.

Cheers,

Thomas

> Best,
>=20
> Axel
>=20
>> Le 10 mars 2014 =C3=A0 19:43, Thomas Heide Clausen  a =C3=A9crit :
>>=20
>> Dear All,
>>=20
>> As the authors requested feedback, I have given the most recent version o=
f this document a review. My comments are below - but do also look at the at=
tached PDF, it's easier to see where each comment applies in there ;)
>>=20
>> For those not wanting to read the whole review: I think that this is a we=
ll written document, I think it's an interesting idea, and I think it's wort=
h taking further, so I'd encourage further further reviews and work.
>>=20
>> There are a few things that need to be addressed, though. Outside the obv=
ious, 'security considerations' and 'the experiment', the main issue is "mul=
tiple interfaces and addresses". While the protocol, as I understand it, can=
 work in multiple interfaces/addresses scenarios, I think that the specifica=
tion is unclear on certain things such as which addresses go in which inform=
ation sets (such as the Blacklist) and messages.
>>=20
>> Either way, see below, and see the file attached to this message - and I l=
ook forward to discussing this further with all y'all.
>>=20
>> Cheers,
>>=20
>> Thomas
>>=20
>> File: draft-gerla-manet-odmrp-02 - flattened.pdf
>>=20
>> Annotation summary:
>>=20
>> --- Page 1 ---
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> General Comments:
>>=20
>> I find this specification very well written, well structured, clear and e=
asy to understand.=20
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Executive Summary:
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> I find this specification very well written, well structured, clear, and e=
asy to understand. I believe that there are some clarifications that could b=
e made, though, and a few "formal" things to correct - but also that the pro=
tocol specification is fairly straight-forward.
>>=20
>> Now, the one point that I think is needing a bit of effort is regarding r=
outers with multiple interfaces and/or multiple addresses, which seems to no=
t be fully specified. At least, it should be made clear which parts of the i=
nformation base are per interface, and the processing adopted accordingly. T=
he way the "blacklist", for example, is written actually permits an implemen=
tation to explicitly "do the wrong thing" when faced with routers with multi=
ple interfaces. I think that it's fairly easy to clear up.
>>=20
>>=20
>> General Comments:
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> I think I understand the general idea, though, of the way the specificati=
on is made: you describe, in abstract form, the protocol, signals, etc., and=
 then you provide the mapping to RFC5444-elements in an appendix.
>>=20
>> That is not entirely stupid as idea, and the resulting document is actual=
ly nice and readable, but.....appendices can't (or, shouldn't) contain norma=
tive text. Indeed, there are many MUST/SHOULD/* in Appendix A.=20
>>=20
>> I suggest promoting Appendix A to a "numbered section" somewhere (perhaps=
 after section 7?)=20
>>=20
>> While I know that it is early, I think it would be helpful to have some r=
eflections on the security considerations. Recent experiences with the SEC-A=
Ds indicate, that they're considerably more strict than they were even half a=
 decade ago, so understanding "what we're getting ourselves into" if the WG g=
ets involved with this protocol might be helpful.
>>=20
>> As was discussed during the MANET wg meeting in London, an EXPERIMENTAL d=
ocument is supposed to enable an experiment, and that experiment should be d=
ocumented. See e.g. RFC6971, section 1.2. I'll try to add a couple of my tho=
ughts on what would make for good "experiments":
>>=20
>> I do believe that, perhaps, a distinguishing point of ODMRP vs. SMF and o=
ther such protocols: whereas these rely on "get a copy of the message to eac=
h router, then have the router decide if it delivers those to applications",=
 ODMRP works by only getting copies of messages to routers that actually nee=
d it. So, an experiment establishing the boundaries where "efforts to constr=
ucting the overlay" are out-weighted by the benefits of not having to delive=
r a copy of the multicast message to each router.
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> Mobile Ad hoc Networking (MANET)
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> "Network Working Group" -- see RFC Editor tutorial slides, page 20
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> conventional tree-based,
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Now that I have thought this bit over....
>>=20
>> In the end, a tree is constructed, though, is it not? Join Queries floode=
d, then Join Replies sent back, in a "Tree-construction" fashion?
>>=20
>>=20
>>=20
>>=20
>> --- Page 4 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> routing                    techniques to avoid
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> So, it is actually not clear what this means, specifically. The more I th=
ink about it, the less do I think of this as "on demand routing techniques" a=
nd the more do I think of this as "on-demand tree construction, with proacti=
ve maintenance",
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> The more I think about it, the less do I think of this as "on demand rout=
ing techniques" and the more do I think of this as "on-demand tree construct=
ion, with proactive maintenance",
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> The more I think about it, the less do I think of this as "on demand rout=
ing techniques" and the more do I think of this as "on-demand tree construct=
ion, with proactive maintenance".
>>=20
>> It is clear, that a sensible routing protocol creates and manages forward=
ing trees/graphs/groups only when there is an actual need for one to exist -=
 so, in that regard, all sensible multicast routing protocols are "reactive"=
.
>>=20
>> As I understand it, this protocol is generating the forwarding tree/graph=
/group from the (expected) source, and then that this is maintained by way o=
f proactive signaling (for as long as there is a need for the forwarding tre=
e/graph/group)
>>=20
>> I'd suggest being explicit as to this, both in introduction and in the ab=
stract?
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> I think that you actually also are importing terminology from RFC5444 her=
e, are you not?  At least, section 7 "Packets and Messages" seems to be hint=
ing at - but not calling out explicitly - that you are.
>>=20
>> I think I understand why you're not calling it out, with the way that the=
 I-D is written and RFC5444 message mapping being in Appendix, but as I have=
 suggested in "general comments", that organization might not be ideal?
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> e.g.
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Technically, that's probably "i.e., " as there are only those two message=
 types, yes?
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> I would suggest answering the question, which is on everybody's lips, alr=
eady here: does this integrate with "regular IP Multicasting" or does it req=
uire "application level tunneling"?=20
>>=20
>> In other words, could I expect an mcast-capable application to "just work=
", and can I implement this "on a commodity OS", or will I have to do kernel=
-level hacks?
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> I would suggest answering the question, which is on everybody's lips, alr=
eady here: does this integrate with "regular IP Multicasting" or does it req=
uire "application level tunneling"?=20
>>=20
>> In other words, could I expect an mcast-capable application to "just work=
", and can I implement this "on a commodity OS", or will I have to do kernel=
-level hacks to make it work?
>>=20
>> Having read through the document, I think that I infer that it's possible=
 to build an user-space implementation manipulating working by simply multic=
ast routing table entries.
>>=20
>> Would be good to have it confirmed that my understanding is correct - if i=
t is, that is ;)
>>=20
>>=20
>> --- Page 5 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> addresses
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> I am going to pick out this here, but it applies elsewhere also: "address=
es"?=20
>>=20
>> I believe that you aim at "address length independence", v6/v4/short, and=
 that's a good idea which is, I believe, supported well by RFC5444. Alas, I b=
elieve that you probably want to stick in a definition and explanation of th=
at in here.=20
>>=20
>> Also, I gather that these addresses are "interface identifiers" and not "=
multicast group addresses", yes? Given that this document talks about multic=
ast, I do recommend perhaps calling this out?
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> I actually would love for you to repeat the example text for "Upstream" h=
ere, also. Yeah, it's repetitive, but when reading through a document and lo=
oking for a definition, it's nice to not be hunting.
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> I am repeating my comment from the introduction here:
>>=20
>> The more I think about it, the less do I think of this as "on demand rout=
ing techniques" or a "reactive" protocol, and the more do I think of this as=
 "on-demand tree construction, with proactive maintenance".
>>=20
>> It is clear, that a sensible routing protocol creates and manages forward=
ing trees/graphs/groups only when there is an actual need for one to exist -=
 so, in that regard, all sensible multicast routing protocols are "reactive"=
.
>>=20
>> As I understand it, this protocol is generating the forwarding tree/graph=
/group from the (expected) source, and then that this is maintained by way o=
f proactive signaling (for as long as there is a need for the forwarding tre=
e/graph/group)
>>=20
>> I'd suggest being explicit as to this, both in introduction and in the ab=
stract?
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Just to be clear; am I correct in understanding that:
>>=20
>> A Multicast Group Address, is used by applications, and joined (etc) by w=
ay of IGMP/MLD.
>>=20
>> The ODMRP router hearing these,  maps that to a "Multicast Session".
>>=20
>> That ODMRP router then proceeds to construct a Multicast Overlay for that=
 multicast session; the Multicast Overlay of a multicast session is a source=
-rooted multicast tree?
>>=20
>> Also, as I understand it, "Forwarding Group" and "Multicast Overlay" are,=
 respectively, "links" and "routers" for a given Multicast Session?
>>=20
>> I think that thats what it is, but the relationship between these terms/c=
oncepts  could merit being rendered crystal clear here.
>>=20
>>=20
>> --- Page 6 ---
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Suggest adding "These multicast overlays are, then, proactively maintaine=
d for as long as the overlay is needed (as long as there are members in the m=
ulticast group AND as long as there is data to be delivered to the multicast=
 group)"
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> IIRC there's a space after and before a "dash"......
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> overlay only
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> -> "overlay, only"
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Correct, but not complete. The overlay is created, trigged by data to del=
iver to the members - but, no overlay is actually created unless there actua=
lly are members of the destination set.=20
>>=20
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> overlay for
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> -> "overlay only for...."
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> and until there no longer are members of the multicast group?
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Suggest "if the router belongs to, i.e., has attached hosts which have su=
bscribed to, the multicast group ..."=20
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> originates
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> This is a really detail-oriented comment, but "originates a Join Reply" h=
ere - and "Join Reply Generation" as the section title for section 9.1.2 is a=
 little incoherent ;)=20
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> I'd proffer that a lot this perhaps should be going in the "Signaling Ove=
rhead" rather than in this section; in part, as you describe messages and se=
ts, before these are defined.
>>=20
>> As overview, it's quite too detailed, so perhaps jumping straight to 4.2 a=
nd merging 4.1 into 4.3 is the best approach?
>>=20
>> Or, perhaps, have 4.2, then 4.3 and finally 4.1 ?
>>=20
>>=20
>> --- Page 7 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> carried
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> This is too "implicit": a "next hop address carried in a packet". You sho=
uld, at least, in the previous bullet point indicate that a Join Reply carri=
es a "next hop address" (and, possibly, what else it carries - I think that f=
or duplicate JR suppression, that's important?)
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> it
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Suggest "If that next hop address is an address of this router..."
>>=20
>> Also, what does "is an address of" or "corresponds to" this router mean, p=
recisely? This may sound like a slightly silly question ;) but in NHDP/OLSRv=
2 we've had to be extremely careful with to what addresses correspond: a rou=
ter, interfaces on that router, or addresses of hosts reachable by way of th=
is router.
>>=20
>> The upshot of this is, that it's really easy to sort out, for example: "I=
s an address of an interface of this router", or something.
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> ,
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> For readability, given that this is the overview and functioning:
>>=20
>> "If , , , then this ODMRP Router belongs=
 to the forwarding group for the multicast session. Consequently, it install=
s ..."=20
>>=20
>>=20
>> A secondary comment here is, that you have defined "Multicast Session" in=
 the terminology, but you're not using it here (rather, you say "......Forwa=
rding Group, which correspondS [sic] to this multicast group and source..."
>>=20
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> This is confusing. What is actually discarded here? I.e., what does "it" c=
orrespond to"?
>>=20
>>=20
>> --- Page 8 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> flooded periodically
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Suggest adding that/if that can be done by way of an optimized flooding o=
peration, if available on the network.
>>=20
>>=20
>> --- Page 9 ---
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> This probably needs a bit more of explanation. As I indicated in the gene=
ral comments, the separation of abstract message content, and 5444-encoding i=
s a possible way to go, but it is not clear at this point that that's what's=
 being done.
>>=20
>> As a consequence, it is not clear why the section title is "Packets and M=
essages" - those are (in MANET) 5444-constructs, typically.
>>=20
>> One possibility could be to stick Appendix A after section 7. Another, to=
 have appendix A be a subsection to section 7.
>>=20
>>=20
>>=20
>>=20
>> --- Page 11 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> Multicast Source
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Somewhat of the same comment as one I have made before: "the address of t=
he Multicast Source"
>>=20
>> First, is the "Multicast Source" the router, through which the multicast d=
ata messages ingress through, or is it the host on which the application gen=
erating data, is? Does it make any difference? "Multicast Source" is not def=
ined.
>>=20
>> Second, what about multiple interfaces/addresses?=20
>>=20
>> I can probably infer how it should be: this is the IP address that one wi=
ll find in the source-address field of IP multicast datagrams, yes? If so, p=
erhaps just call that out somewhere so there's no doubt.
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> address of the neighbor ODMRP Router
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Jumping on this just once more. "The address of the neighbor ODMRP router=
..."
>>=20
>> The way it is written, one gets the impression that ODMRP is designed for=
 single-interface-single-address routers.=20
>>=20
>> I do not *think* that this is the case, and it certainly does not have to=
 be made a constraint, so I recommend clearing that up. (Conversely, if it i=
s the case, call that out as a constraint in applicability section). This ap=
plies actually through the document, so looking at giving it a pass through w=
ith "remove doubts as to multi-if/addr" as objective would be great.
>>=20
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> R_source
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Why is it P_multicast_source, but this is R_source?
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> =46rom this description, it appears that it all is "per router" and with n=
o "per interface" sets, is that correct?
>>=20
>> As I have indicated for the "Blacklist" this may be problematic, or at le=
ast necessitate some extra care to specify completely.
>>=20
>>=20
>> --- Page 12 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> Multicast Source
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> See previous question regarding Multicast Source
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Contrary to previous...._source, this is unambiguous ;)
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> F_source
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Why is it P_multicast_source, but this is F_source?
>>=20
>>=20
>> --- Page 13 ---
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> I would probably say "...over which the Join Reply was sent"
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> an
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> ODMRP Routers
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> What if two routers, A and B, have two interfaces a1, a2, b1, b2?
>>=20
>> If A can hear B over a
>>=20
>>=20
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> What if two routers, A and B, have two interfaces a1, a2, b1, b2?
>>=20
>> If A can hear B over (a1, b1) and B can hear A over (a2, b2), what addres=
ses go into this set?
>>=20
>> Also, what if A can hear B over (a1, b1) (and B can hear A over the same p=
air), and A can hear B over (a1,b2) but B cannot....?
>>=20
>> In other words, is this set per interface or per router?
>>=20
>> And, what are the addresses you put in there, interface addresses, or "Ro=
uterIDs"?
>>=20
>>=20
>>=20
>> --- Page 14 ---
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Alright, so reading this, it seems that the blacklist must be "per interf=
ace", yes?
>>=20
>>=20
>> --- Page 15 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> an address
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Which address? Any? Always the same? Does it matter?
>>=20
>>=20
>> --- Page 16 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> an address
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Which address? Any? Always the same? Does it matter?
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> neighbors
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> I assume that what you want is to forward to all the neighbors on all ODM=
RP interfaces of this router, yes?
>>=20
>>=20
>>=20
>> --- Page 19 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> neighbors
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Over all ODMRP Interfaces?
>>=20
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Here, we are gleaning a bit more precisely what the R_source is; so its a=
n interface of an ODMRP router over which the Join Reply was sent, yes?
>>=20
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> Else
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Else -> "Otherwise, if a tuple exists, ..."
>>=20
>>=20
>> --- Page 20 ---
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> "Otherwise, ..."
>>=20
>>=20
>> --- Page 21 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> Else
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> ->Otherwise
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Really nit-picking, but " i.e. " -> " i.e., " is the RFC-Editor style....=

>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Suggest: "...run in conjunction with, and benefit from some of the featur=
es of, SMF..."
>>=20
>> Strikeout (red), 10 mars 2014 19:24, TClausen:
>> and                benefit from some of its features.
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> I would be hesitant to call this section "SMF Considerations"
>>=20
>> While SMF is an important and useful protocol set, I would suggest that t=
his section be generalized: what's at stake is, and I think that I saw that i=
n the slides that were presented in the London IETF, that if there's a "more=
 efficient than classic flooding" network-wider broadcast operation in place=
, then ODMRP would/should use it - correct?
>>=20
>> This might be by way of SMF, or it could be as an extension to OLSRv2's M=
PR flooding, or it could be (as is seen in for example HNCP) something based=
 off of Trickle - or something entirely different.
>>=20
>> So, perhaps "Flooding considerations" as section title, and a bit general=
ized text would work?
>>=20
>>=20
>> --- Page 22 ---
>>=20
>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>> Packets
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Packets -> Packet
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> OK, I think that this document should start by actually requesting the al=
locations for the two message types. Cf. how it is done in section 18.2 of R=
FC6130
>>=20
>> Then, I *think* that the current 15.1 is the Message-Type-Specific TLV Ty=
pe Registries" that are being set up, for Join-Query yes? I see "Expert Revi=
ew" mentioned, but no guidelines/recommendations for the Expert to follow. D=
o you intend to mirror those from RFC5444, or are there special concerns to t=
ake into consideration?
>>=20
>> I would actually suggest mirroring the structure of the IANA section from=
 RFC6130  if for no other reasons, than that it's allocating from RFC5444-re=
gistries, and has been going through the process and so it may be assumed th=
at something mirroring it will, too. ;)
>>=20
>>=20
>>=20
>> --- Page 25 ---
>>=20
>> Note (yellow), 10 mars 2014 19:24, TClausen:
>> Just a comment, a cursory review of the mapping to RFC5444 doesn't have a=
nything jump at me screaming "problems", which is good.
>>=20
>> I was wondering one thing, though: if running OLSRv2 + ODMRP, then there'=
s an obvious option which could be considered (and could be considered, in o=
rder to be disregarded)....
>>=20
>> Could one imagine carrying ODMRP signals inside TC messages in any meanin=
gful way, as TLVs and additional addresses included? *technically* it should=
 be possible, does it make sense?
>>=20
>> A second thing, is there any reason to request both JR and JQ message typ=
e, or is there a way of using just a single code-point, and are there potent=
ial benefits in doing so?
>>=20
>> A different way of phrasing the above is: given that code-points by defin=
ition are limited, I'd like to ask for a bit more of "justification" before t=
hey are allocated.
>>=20
>> FWIW, I've not had the cycles to review the appendices, other than Append=
ix A.
>>=20
>>=20
>> (report generated by GoodReader)
>>=20
>>=20
>>=20
>> 
>>=20
>>=20
>> Sent from my iPad_______________________________________________
>> 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 nobody Mon Mar 10 17:03:20 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC73A1A0564 for ; Mon, 10 Mar 2014 17:03:17 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNG7YjxqMEUT for ; Mon, 10 Mar 2014 17:03:16 -0700 (PDT)
Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3A91A0644 for ; Mon, 10 Mar 2014 17:03:16 -0700 (PDT)
Received: by mail-yh0-f43.google.com with SMTP id b6so7906854yha.30 for ; Mon, 10 Mar 2014 17:03:10 -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=4xwdYC5hVQLL+bq3WnyyONeqpQ4+KLpMjDVXXCCRbME=; b=hAulft60w4UXAwijLvNK9XuVUr2TwzE2daUSGZHQrDTNVptDABPrnr/KfJmvdigJnI WxlInbfyHAz/4hvjdDxHvXnit9N9ocwdLvi1Z7oTXJKE5mKGEuKYfd/tW4QE0sE2HI9r aEmiZv640PIjlgIwT6JYtEd+kL1zO5kT2E6z7uopKFAgb7cjXqCyWVTFNYMwNQTmWPLt sVTmNqsjPvjfaPPum/ly/EYt7uniy7IrNzdfSjehGteuGaeui1+8MwUzsMkV/zB2j8rn 2xd7frd1QerlovzHyMWtpwEGNm9nnBdGL+7g6dOsJ6BcKQJapvXKvRo/h2Tge1gp8aoi 1pSQ==
MIME-Version: 1.0
X-Received: by 10.236.191.130 with SMTP id g2mr33939yhn.160.1394496190621; Mon, 10 Mar 2014 17:03:10 -0700 (PDT)
Received: by 10.170.202.7 with HTTP; Mon, 10 Mar 2014 17:03:10 -0700 (PDT)
In-Reply-To: 
References:  <33A31C2B-CD52-4FF6-B376-325237B7C585@thomasclausen.org> 
Date: Tue, 11 Mar 2014 01:03:10 +0100
Message-ID: 
From: Abdussalam Baryun 
To: =?ISO-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
Content-Type: multipart/alternative; boundary=20cf30563d57152f7004f449722a
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_wi91tRVj2Eq54Ap38QAbEoHvoQ
Cc: manet , gerla 
Subject: Re: [manet] ODMRP new draft (was Re: IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Mar 2014 00:03:18 -0000

--20cf30563d57152f7004f449722a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Slide 11 and 18. In the draft page 4 it mentions that ODMRP maintains
multiple paths. Regarding overhead, do you mean there is no overhead in
this routing and if there is with higher mobility how does it optimise it.

AB

On Monday, March 10, 2014, Axel Colin de Verdi=E8re wrote:

> Hi Abdussalam, Thomas,
>
> Thank you for your comments. Indeed there are no multiple paths involved.
> Can you point me to the slide you're referring to? What do you mean by
> "optimise overhead"?
>
> Axel
>
> Le 10 mars 2014 =E0 20:32, Thomas Heide Clausen >
> a =E9crit :
>
> Dear Abdussalam,
>
>
> On 10 mars 2014, at 17:48, Abdussalam Baryun 
> wrote:
>
> Hi Axel,
>
> Thanks for your presentation. I had a question at meeting but there was n=
o
> time. From the presentation (still I did not done review), there was one
> slide showing two paths to its destination, so does this multicast protoc=
ol
> use multipath to reach all its demanded destinations? And how does it
> optimise overhead?
>
>
> Having now reviewed the document in detail, let me venture a reply ;)
>
> I believe that, no, multiple paths to the same destination are not sought
> nor used. Of course, to multiple destinations, multiple paths (but with
> common path segments, as possible) result.
>
> I am interested, Abdussalam, have you read the document, and what are you=
r
> detailed comments?
>
> Thomas
>
> AB
>
> On Monday, March 10, 2014, Axel Colin de Verdi=E8re wrote:
>
> Hi all,
>
> We did not in fact request WG adoption for ODMRP and ODMRP_ASYM at this
> time, but we felt that the drafts were in good enough shape to ask for yo=
ur
> comments and move in that direction.
>
> Axel
>
> Le 10 mars 2014 =E0 17:08, Abdussalam Baryun =
 a
> =E9crit :
>
> Hi Thomas,
>
> Thanks for the update. I don't think the latest multicast draft was
> requested to be adopted in the meeting, but Ulrich did request his it for
> his draft, and I am waiting for announce on the list for DLEP plan and
> all adoption request in WG meeting.
>
> AB
>
> On Monday, March 10, 2014, Thomas Clausen wrote:
>
> Ulrich,
>
> Thank you for prompt posting of minutes.
>
> A couple of things that I would like to make more precise, all the same,
> in the minutes:
>
> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>
> 
>
> Teco: Why not make this document standards track?
> CD: If people implement this and it's great.  Then I'm find  fine changin=
g this to standards track if that's the case.
> TC: I do not think as a working group that we should go down the standard=
s track document without many implementations as that has happened in other=
 places within the IETF and document quality has suffered.
>
> I honestly do not think that Chris would make that typo, even when
> speaking ;)
>
> CD: If it gets stuck in the queue for 4 years we may have enough experien=
ce that we may want to push for standards track.
> Rick Taylor: Is there any record of this for this draft being experimenta=
l and then changing to standards track later down the line?
> CD: We will post something up on the list.
> TC: I think that experimental should have an explanation on what the expe=
riment is and what the successful experiment is and what the conclusion is.
> Ulrich: Do you have intention to add a description of what those experime=
nts are and what will make them successful?
> Adrian Farrel: Yes, he does have that intention.
>
> As it reads in the above, it sounds as if I'm making a demand, that Adria=
n is committing Chris to satisfy. That's not exactly how it went down, so p=
erhaps we should clarify that in the minutes?
>
> I'd like to go on record here, that I did not say that it "should have an
> explanation" to cater to my whim, but that I (as I actually stated at the
> mike) I was reciting what I had heard was an IESG statement/requirement
> (so: I thought it wa
>
>
>

--20cf30563d57152f7004f449722a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Slide 11 and 18. In the=A0draft page 4 it mentions that ODMRP=A0maintains m=
ultiple paths. Regarding overhead, do you mean there is no overhead in this=
 routing and if there is with higher mobility=A0how does it optimise it.=A0=



AB

On Monday, March 10, 2014, Axel Colin de Verdi=E8r=
e  wrote:

Hi Abdussalam, Thomas,

Thank you for your comments. Inde=
ed there are no multiple paths involved. Can you point me to the slide you&=
#39;re referring to? What do you mean by "optimise overhead"?


Axel

Le 10 mars 2014 =E0 20:32,=
 Thomas Heide Clausen <ietf@thomasclausen.org<=
/a>> a =E9crit :




Dear Abdussalam,


Hi Axel,


Thanks for your presentation. I=A0had a question at meeting=A0but there was=
 no time. From the presentation (still I did=A0not done review), there was =
one slide showing=A0two paths to its=A0destination, so does this multicast =
protocol use multipath to reach all its demanded=A0destinations? And how do=
es it optimise overhead?




Having now reviewed the document=
 in detail, let me venture a reply ;)

I believe that, no=
, multiple paths to the same destination are not sought nor used. Of course=
, to multiple destinations, multiple paths (but with common path segments, =
as possible) result.



I am interested, Abdussalam, have you read the document=
, and what are your detailed comments?

Thomas

AB

On Monday, March 1=
0, 2014, Axel Colin de Verdi=E8re wrote:


Hi all,

We did not in fac=
t request WG adoption for ODMRP and ODMRP_ASYM at this time, but we felt th=
at the drafts were in good enough shape to ask for your comments and move i=
n that direction.



Axel

Le 10 mars 2014 =E0 17:08,=
 Abdussalam Baryun <abdussalambaryun@gmail.com> a =E9crit :
Hi=A0Thomas,

Thanks for=
 the update. I don't think the latest=A0multicast draft was requested t=
o be=A0adopted in the meeting, but Ulrich did request his it for his draft,=
=A0and I am waiting for announce=A0on=A0the list for DLEP plan=A0and all=A0=
adoption request in WG=A0meeting.=A0



AB

On Monday, March 10, 2014, Thomas Clausen wro=
te:


Ulrich,

Thank you fo=
r prompt posting of minutes.
=A0
A couple of things tha=
t I would like to make more precise, all the same, in the minutes:


o draft-ietf-manet-olsrv2-multitopology: Dearlove

<SNIP>
Teco: Why not make this do=
cument standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's the case=
.
TC: I do not think as a working group that we should go down the standards =
track document without many implementations as that has happened in other p=
laces within the IETF and document quality has suffered.


I honestly do not think that Chris would make that typo, even when spe=
aking ;)
CD: If it gets stuck in the queue for 4 years we may have enough experience=
 that we may want to push for standards track.
Rick Taylor: Is there any record of this for this draft being experimental =
and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the experi=
ment is and what the successful experiment is and what the conclusion is.
Ulrich: Do you have intention to add a description of what those experiment=
s are and what will make them successful?
Adrian Farrel: Yes, he does have that intention.
As it reads in the above, it sounds as=
 if I'm making a demand, that Adrian is committing Chris to satisfy. Th=
at's not exactly how it went down, so perhaps we should clarify that in=
 the minutes?





I'd like to go on record here, that I did not say that it "sh=
ould have an explanation" to cater to my whim, but that I (as I actual=
ly stated at the mike) I was reciting what I had heard was an IESG statemen=
t/requirement (so: I thought it wa





--20cf30563d57152f7004f449722a--


From nobody Mon Mar 10 17:04:53 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F131A0647 for ; Mon, 10 Mar 2014 17:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9258wfdLtGxQ for ; Mon, 10 Mar 2014 17:04:49 -0700 (PDT)
Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id C68371A0644 for ; Mon, 10 Mar 2014 17:04:49 -0700 (PDT)
Received: by mail-qa0-f41.google.com with SMTP id j5so7832638qaq.28 for ; Mon, 10 Mar 2014 17:04:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PjIf+0uBiWqHRbDpgEWQuNlO3cLj7hatfIGnyalv3hI=; b=Uig6KhmDr9NonbZSCakufVZ7hgcvoV6BALrPssKc+7/JLOnl32jw7bkV4hoDDFvJZU U02ZOpdjZM7zWUvJg+VFggLQ23do4BQ/GouGyJ83kZ+8VChK5sHn/1wMdiPdc+ecbWVN lz0+A7HR9QFNiWSQj+ycB8dL7HCAVCh3XUmgc1njiklt9EeKJ5ELvYtnK7JXT21aZdfg UwLqJeFKJdTjzFC46yHflUtjMZGg6W2lGTrVXVF9ClaBXMbH2nmFLc0dbFD3pJDRmau0 w/s4SBKWt1mPHKYgVL2P0XWOaigokAtF4LZzuMU1/PnnCrWBYwwIJAAsbu3OXmCsivLz bfTg==
X-Received: by 10.140.94.134 with SMTP id g6mr21401739qge.19.1394496284138; Mon, 10 Mar 2014 17:04:44 -0700 (PDT)
Received: from vpn217206.nrl.navy.mil (vpn217206.nrl.navy.mil. [132.250.217.206]) by mx.google.com with ESMTPSA id m14sm62893596qax.9.2014.03.10.17.04.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 17:04:43 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Joe Macker 
In-Reply-To: <335AD6ED-F820-4C3B-9C11-F6593D4EEE43@axelcdv.com>
Date: Mon, 10 Mar 2014 20:04:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140305115333.7635.9928.idtracker@ietfa.amsl.com> <335AD6ED-F820-4C3B-9C11-F6593D4EEE43@axelcdv.com>
To: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/4vuP-x6MRLU5LCL9DYknX1MGivM
Cc: " List" , gerla , Soon Young Oh 
Subject: [manet] Basic initial comment for draft-gerla-manet-odmrp-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Mar 2014 00:04:51 -0000

Sorry I was working with pdf document here are my very basic exported =
comments that might hep with a revision.
More in the second set of comments. The general comments are just for =
general discussio going forward.
There are plenty more things but I did not do a comprehensive review =
yet.

-------
First off nice work!

General Comments:

(1) In a future revision, it would probably be good to discuss the =
design issues associated with finding the right value of Route Query =
refresh flooding intervals.  As you know, there have been plenty of =
published papers on the subject relating to ODMRP.

(2) Might want to discuss any relationship with any SSM from the IGMPv2, =
MLD perspective,etc.  Is there an intention to support SSM?The state is =
certainly source specific.

(3) We could discuss more about how this could work with RFC 6130 =
concepts or where similar security considerations may lie.  This could =
be done down the road as we flesh things out more and consider =
acceptance as a  WG item.


Summary of More Specific Minor Comments on =
draft-gerla-manet-odmrp-02.pdf

Page: 4
Author: macker Subject: Sticky Note Date: 3/10/14, 7:05:03 PM
of a "forwarding group"
also avril -> april in reference

Page: 7
Author: macker Subject: Sticky Note Date: 3/10/14, 7:11:34 PM
disctinct -> distinct

Page: 8
Author: macker Subject: Sticky Note Date: 3/10/14, 7:15:10 PM
neighbour->neighbor
I personally have no issue with British spellings in IETF docs.
But since RFC 6130 and Crhis Dearlove go this way=20

Page: 9
Author: macker Subject: Sticky Note Date: 3/10/14, 7:18:27 PM
Security Considerations for sequencing
Replay etc (see later in pg 22 comments)
Page: 11
Author: macker Subject: Sticky Note Date: 3/10/14, 7:20:36 PM
Fix sentence grammar:
recommend remove "when"
Page: 21
Author: macker Subject: Sticky Note Date: 3/10/14, 7:34:41 PM
I think its great to have some potential convergence of capability here.
The sentence duplication packets and message detection is malformed at =
least in the pdf version of the draft. Perhaps an xml,etc.
Scoped flooding may be assisted by an SMF implementation as well.
We have published and some unpublished improvements to these optimized =
flooding mechanisms (e.g., ECDS) that might provide more stability.
both ipv4 and ipv6.
Page: 22
Author: macker Subject: Sticky Note Date: 3/10/14, 7:36:26 PM
There are likely particular security vulnerabilities that can be =
discussed regarding monotic sequences as used in control plane.. See SMF =
and other documents for similar issues such as replay,etc. Something for =
a future revision.


On Mar 5, 2014, at 7:00 AM, Axel Colin de Verdi=E8re  =
wrote:

> Hi all,
>=20
> We just pushed a new revision of ODMRP out, the -02 version presented =
at the meeting. I got some comments during this week and plan to =
integrate them into a -03 revision pretty soon. I'd be happy to discuss =
additional suggestions or remarks that could be added to that revision.
>=20
> Thanks,
>=20
> Axel
>=20
>=20
> D=E9but du message r=E9exp=E9di=E9 :
>=20
>> De: internet-drafts@ietf.org
>> Objet: New Version Notification for draft-gerla-manet-odmrp-02.txt
>> Date: 5 mars 2014 11:53:33 UTC
>> =C0: "William Su" , "Yunjung Yi" =
, "Axel Coli Verdiere" =
, "Sung-Ju Lee" =
, Mario Gerla =
, "Professor Mario Gerla" , =
William Su , Axel Colin de Verdiere =

>>=20
>>=20
>> A new version of I-D, draft-gerla-manet-odmrp-02.txt
>> has been successfully submitted by Axel Colin de Verdiere and posted =
to the
>> IETF repository.
>>=20
>> Name:		draft-gerla-manet-odmrp
>> Revision:	02
>> Title:		On-Demand Multicast Routing Protocol (ODMRP) for =
Ad Hoc Networks
>> Document date:	2014-03-05
>> Group:		Individual Submission
>> Pages:		30
>> URL:            =
http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-02.txt
>> Status:         =
https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/
>> Htmlized:       http://tools.ietf.org/html/draft-gerla-manet-odmrp-02
>> Diff:           =
http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-02
>>=20
>> Abstract:
>>   The On-Demand Multicast Routing Protocol (ODMRP) is a multicast
>>   routing protocol designed for ad hoc networks with mobile hosts.
>>   ODMRP is a mesh-based, rather than a conventional tree-based,
>>   multicast scheme and uses a forwarding group concept (only a subset
>>   of nodes forwards the multicast packets via scoped flooding).  It
>>   applies on-demand procedures to dynamically build routes and =
maintain
>>   multicast group membership.  ODMRP is well suited for ad hoc =
wireless
>>   networks with mobile hosts where bandwidth is limited, topology
>>   changes frequently and rapidly, and power is constrained.
>>=20
>>=20
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> The IETF Secretariat
>>=20
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From nobody Mon Mar 10 17:09:24 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678C91A0672 for ; Mon, 10 Mar 2014 17:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c0GPReg7Oxj for ; Mon, 10 Mar 2014 17:09:19 -0700 (PDT)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6E81A064F for ; Mon, 10 Mar 2014 17:09:19 -0700 (PDT)
Received: by mail-qg0-f42.google.com with SMTP id q107so9480401qgd.1 for ; Mon, 10 Mar 2014 17:09:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2KfGGuhdsgjUQQToi+e/eu0YMHJSx0FibK+hor0ysx0=; b=yj+zr7RgMAoddmY3jqB5RxtbHlxbhJeAQGOlIckCRSQR+J0TiX/E+qQzuUXkjvcATK bZvB4yhOWCyz8Knurym5xvAhFPqs8/WQf3f9ed1o5FlB+mI5sMXCYsOklU8+IDA7wKIJ vjA60/bciMM+V8rPwmwDipKz44Di6zjzFXD7UtyzLNCG08BSuBMPblaz0FO+cBcEj5ub YVANB8Cp/5hb+pbbxda8gg5ZSDuaOxecNLCBhBaEQ3SccNjaaQY/zVg9JwN7PAL5zeg4 oLcOiBUNtiI1EWbL/qDb5CIbUccCktsHx3esCi4X/iKQT3dAocKxcCti2M3AcqbICjsP pXWg==
X-Received: by 10.140.104.103 with SMTP id z94mr5992447qge.91.1394496553884; Mon, 10 Mar 2014 17:09:13 -0700 (PDT)
Received: from vpn217206.nrl.navy.mil (vpn217206.nrl.navy.mil. [132.250.217.206]) by mx.google.com with ESMTPSA id k6sm29051316qgd.17.2014.03.10.17.09.13 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 17:09:13 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Joe Macker 
In-Reply-To: 
Date: Mon, 10 Mar 2014 20:09:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <86CD3E73-0290-4D15-8D35-F2FDCACDDA41@gmail.com>
References: <20140305115333.7635.9928.idtracker@ietfa.amsl.com> <335AD6ED-F820-4C3B-9C11-F6593D4EEE43@axelcdv.com> 
To: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/iw9afRwkpmUFJFMBJJpmJRMnvzA
Cc: " List" , gerla , Soon Young Oh 
Subject: Re: [manet] Basic initial comment for draft-gerla-manet-odmrp-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Mar 2014 00:09:21 -0000

#3 I misreferenced an RFC although the comment may still apply.
On Mar 10, 2014, at 8:04 PM, Joe Macker  wrote:

> Sorry I was working with pdf document here are my very basic exported =
comments that might hep with a revision.
> More in the second set of comments. The general comments are just for =
general discussio going forward.
> There are plenty more things but I did not do a comprehensive review =
yet.
>=20
> -------
> First off nice work!
>=20
> General Comments:
>=20
> (1) In a future revision, it would probably be good to discuss the =
design issues associated with finding the right value of Route Query =
refresh flooding intervals.  As you know, there have been plenty of =
published papers on the subject relating to ODMRP.
>=20
> (2) Might want to discuss any relationship with any SSM from the =
IGMPv2, MLD perspective,etc.  Is there an intention to support SSM?The =
state is certainly source specific.
>=20
> (3) We could discuss more about how this could work with RFC 6130 =
concepts or where similar security considerations may lie.  This could =
be done down the road as we flesh things out more and consider =
acceptance as a  WG item.

I meant RFC 6621(SMF) sorry for any confusion. 6130 is NHDP of course..

>=20
>=20
> Summary of More Specific Minor Comments on =
draft-gerla-manet-odmrp-02.pdf
>=20
> Page: 4
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:05:03 PM
> of a "forwarding group"
> also avril -> april in reference
>=20
> Page: 7
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:11:34 PM
> disctinct -> distinct
>=20
> Page: 8
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:15:10 PM
> neighbour->neighbor
> I personally have no issue with British spellings in IETF docs.
> But since RFC 6130 and Crhis Dearlove go this way=20
>=20
> Page: 9
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:18:27 PM
> Security Considerations for sequencing
> Replay etc (see later in pg 22 comments)
> Page: 11
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:20:36 PM
> Fix sentence grammar:
> recommend remove "when"
> Page: 21
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:34:41 PM
> I think its great to have some potential convergence of capability =
here.
> The sentence duplication packets and message detection is malformed at =
least in the pdf version of the draft. Perhaps an xml,etc.
> Scoped flooding may be assisted by an SMF implementation as well.
> We have published and some unpublished improvements to these optimized =
flooding mechanisms (e.g., ECDS) that might provide more stability.
> both ipv4 and ipv6.
> Page: 22
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:36:26 PM
> There are likely particular security vulnerabilities that can be =
discussed regarding monotic sequences as used in control plane.. See SMF =
and other documents for similar issues such as replay,etc. Something for =
a future revision.
>=20
>=20
> On Mar 5, 2014, at 7:00 AM, Axel Colin de Verdi=E8re =
 wrote:
>=20
>> Hi all,
>>=20
>> We just pushed a new revision of ODMRP out, the -02 version presented =
at the meeting. I got some comments during this week and plan to =
integrate them into a -03 revision pretty soon. I'd be happy to discuss =
additional suggestions or remarks that could be added to that revision.
>>=20
>> Thanks,
>>=20
>> Axel
>>=20
>>=20
>> D=E9but du message r=E9exp=E9di=E9 :
>>=20
>>> De: internet-drafts@ietf.org
>>> Objet: New Version Notification for draft-gerla-manet-odmrp-02.txt
>>> Date: 5 mars 2014 11:53:33 UTC
>>> =C0: "William Su" , "Yunjung Yi" =
, "Axel Coli Verdiere" =
, "Sung-Ju Lee" =
, Mario Gerla =
, "Professor Mario Gerla" , =
William Su , Axel Colin de Verdiere =

>>>=20
>>>=20
>>> A new version of I-D, draft-gerla-manet-odmrp-02.txt
>>> has been successfully submitted by Axel Colin de Verdiere and posted =
to the
>>> IETF repository.
>>>=20
>>> Name:		draft-gerla-manet-odmrp
>>> Revision:	02
>>> Title:		On-Demand Multicast Routing Protocol (ODMRP) for =
Ad Hoc Networks
>>> Document date:	2014-03-05
>>> Group:		Individual Submission
>>> Pages:		30
>>> URL:            =
http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-02.txt
>>> Status:         =
https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/
>>> Htmlized:       =
http://tools.ietf.org/html/draft-gerla-manet-odmrp-02
>>> Diff:           =
http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-02
>>>=20
>>> Abstract:
>>>  The On-Demand Multicast Routing Protocol (ODMRP) is a multicast
>>>  routing protocol designed for ad hoc networks with mobile hosts.
>>>  ODMRP is a mesh-based, rather than a conventional tree-based,
>>>  multicast scheme and uses a forwarding group concept (only a subset
>>>  of nodes forwards the multicast packets via scoped flooding).  It
>>>  applies on-demand procedures to dynamically build routes and =
maintain
>>>  multicast group membership.  ODMRP is well suited for ad hoc =
wireless
>>>  networks with mobile hosts where bandwidth is limited, topology
>>>  changes frequently and rapidly, and power is constrained.
>>>=20
>>>=20
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of =
submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>=20
>>> The IETF Secretariat
>>>=20
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>=20


From nobody Tue Mar 11 00:02:24 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6F81A04BC for ; Tue, 11 Mar 2014 00:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llN9yko7wUsU for ; Tue, 11 Mar 2014 00:02:19 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 95BF01A03C8 for ; Tue, 11 Mar 2014 00:02:19 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id hm4so410519wib.7 for ; Tue, 11 Mar 2014 00:02:13 -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:from:subject:date:to; bh=lhoZ0NQdne2ttlW7kVOdywsiEAhZPvhKQVmD/E1w1yM=; b=mEJVe8iJARB3IDpzV2s8zxz+95fVAALPiHaBVqJ+1VMWsPfWDBUJAoOyHSkqM2OMQD o6tfeOHcV2lYgZ7VG7GM0Rvt9A0wS4hnATLUb2w813mNLjmJYU0zuUxza3ZQ25zKh41R Sr+81SZ9G4fzN2Yot26QqhaeYYrj8oAQBXynFDehVnbEI2xoMskqvgpvCHwl5GCBteU0 jnZ1AirmmKnuFnxypcvyBCBjyPEphgwlF80qf34cvjoSPKDRkD6yPjIYSvqC4SosOY3K qGH2gS7/MhVYf6biya9zk6yvPZbU8Q10RAlUfW8Z/JFt1jc3NnptEIXmcwDr/U/XtK1+ oJQQ==
X-Received: by 10.194.174.197 with SMTP id bu5mr24940wjc.71.1394521333413; Tue, 11 Mar 2014 00:02:13 -0700 (PDT)
Received: from [10.3.114.109] (dab-far1-h-60-1.dab.02.net. [82.132.220.192]) by mx.google.com with ESMTPSA id ga10sm59014328wjb.23.2014.03.11.00.02.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Mar 2014 00:02:12 -0700 (PDT)
References: <20140305115333.7635.9928.idtracker@ietfa.amsl.com> <335AD6ED-F820-4C3B-9C11-F6593D4EEE43@axelcdv.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <18B34B51-7223-42B5-862D-E5B4150C26BD@gmail.com>
X-Mailer: iPhone Mail (11B651)
From: Christopher Dearlove 
Date: Tue, 11 Mar 2014 07:02:09 +0000
To: Joe Macker 
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/52v_Bh6FV0wur-AfhMtB2TFR3s8
Cc: " List" , =?utf-8?Q?Axel_Colin_de_Verdi=C3=A8re?= , gerla , Soon Young Oh 
Subject: Re: [manet] Basic initial comment for draft-gerla-manet-odmrp-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Mar 2014 07:02:22 -0000

I believe on British English, the RFC Editor's rules can be summarised as:
- British English is permitted.
- But in practice no one does.

So, yes, I have misspelled neighbour in all the drafts I have co-authored.

But it's spelled correctly in my software ;)

--=20
Christopher Dearlove
christopher.dearlove@gmail.com

> On 11 Mar 2014, at 00:04, Joe Macker  wrote:
>=20
> Sorry I was working with pdf document here are my very basic exported comm=
ents that might hep with a revision.
> More in the second set of comments. The general comments are just for gene=
ral discussio going forward.
> There are plenty more things but I did not do a comprehensive review yet.
>=20
> -------
> First off nice work!
>=20
> General Comments:
>=20
> (1) In a future revision, it would probably be good to discuss the design i=
ssues associated with finding the right value of Route Query refresh floodin=
g intervals.  As you know, there have been plenty of published papers on the=
 subject relating to ODMRP.
>=20
> (2) Might want to discuss any relationship with any SSM from the IGMPv2, M=
LD perspective,etc.  Is there an intention to support SSM?The state is certa=
inly source specific.
>=20
> (3) We could discuss more about how this could work with RFC 6130 concepts=
 or where similar security considerations may lie.  This could be done down t=
he road as we flesh things out more and consider acceptance as a  WG item.
>=20
>=20
> Summary of More Specific Minor Comments on draft-gerla-manet-odmrp-02.pdf
>=20
> Page: 4
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:05:03 PM
> of a "forwarding group"
> also avril -> april in reference
>=20
> Page: 7
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:11:34 PM
> disctinct -> distinct
>=20
> Page: 8
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:15:10 PM
> neighbour->neighbor
> I personally have no issue with British spellings in IETF docs.
> But since RFC 6130 and Crhis Dearlove go this way=20
>=20
> Page: 9
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:18:27 PM
> Security Considerations for sequencing
> Replay etc (see later in pg 22 comments)
> Page: 11
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:20:36 PM
> Fix sentence grammar:
> recommend remove "when"
> Page: 21
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:34:41 PM
> I think its great to have some potential convergence of capability here.
> The sentence duplication packets and message detection is malformed at lea=
st in the pdf version of the draft. Perhaps an xml,etc.
> Scoped flooding may be assisted by an SMF implementation as well.
> We have published and some unpublished improvements to these optimized flo=
oding mechanisms (e.g., ECDS) that might provide more stability.
> both ipv4 and ipv6.
> Page: 22
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:36:26 PM
> There are likely particular security vulnerabilities that can be discussed=
 regarding monotic sequences as used in control plane.. See SMF and other do=
cuments for similar issues such as replay,etc. Something for a future revisi=
on.
>=20
>=20
>> On Mar 5, 2014, at 7:00 AM, Axel Colin de Verdi=C3=A8re  wrote:
>>=20
>> Hi all,
>>=20
>> We just pushed a new revision of ODMRP out, the -02 version presented at t=
he meeting. I got some comments during this week and plan to integrate them i=
nto a -03 revision pretty soon. I'd be happy to discuss additional suggestio=
ns or remarks that could be added to that revision.
>>=20
>> Thanks,
>>=20
>> Axel
>>=20
>>=20
>> D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 :
>>=20
>>> De: internet-drafts@ietf.org
>>> Objet: New Version Notification for draft-gerla-manet-odmrp-02.txt
>>> Date: 5 mars 2014 11:53:33 UTC
>>> =C3=80: "William Su" , "Yunjung Yi" , "Axel Coli Verdiere" , "Sung=
-Ju Lee" , Mario Gerla , "Professor Mario Gerla" , William Su , Axel Colin de Verdiere 
>>>=20
>>>=20
>>> A new version of I-D, draft-gerla-manet-odmrp-02.txt
>>> has been successfully submitted by Axel Colin de Verdiere and posted to t=
he
>>> IETF repository.
>>>=20
>>> Name:        draft-gerla-manet-odmrp
>>> Revision:    02
>>> Title:        On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Ne=
tworks
>>> Document date:    2014-03-05
>>> Group:        Individual Submission
>>> Pages:        30
>>> URL:            http://www.ietf.org/internet-drafts/draft-gerla-manet-od=
mrp-02.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp=
/
>>> Htmlized:       http://tools.ietf.org/html/draft-gerla-manet-odmrp-02
>>> Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odm=
rp-02
>>>=20
>>> Abstract:
>>>  The On-Demand Multicast Routing Protocol (ODMRP) is a multicast
>>>  routing protocol designed for ad hoc networks with mobile hosts.
>>>  ODMRP is a mesh-based, rather than a conventional tree-based,
>>>  multicast scheme and uses a forwarding group concept (only a subset
>>>  of nodes forwards the multicast packets via scoped flooding).  It
>>>  applies on-demand procedures to dynamically build routes and maintain
>>>  multicast group membership.  ODMRP is well suited for ad hoc wireless
>>>  networks with mobile hosts where bandwidth is limited, topology
>>>  changes frequently and rapidly, and power is constrained.
>>>=20
>>>=20
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of submis=
sion
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>=20
>>> The IETF Secretariat
>>=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 nobody Tue Mar 11 01:00:11 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93E61A02A0 for ; Tue, 11 Mar 2014 01:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFQL7RVaRVNx for ; Tue, 11 Mar 2014 01:00:07 -0700 (PDT)
Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7E92F1A024B for ; Tue, 11 Mar 2014 01:00:07 -0700 (PDT)
Received: by mail-yh0-f51.google.com with SMTP id f10so8294185yha.10 for ; Tue, 11 Mar 2014 01:00: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=hBY1ghH0AZWrVrsI30BTRry8uDf2wHRMINrRrGnoCNs=; b=ftytLrlEmeu5HrCuGEWqkD1orSDfOy+UobJbEQAFnARooQK66A2lssx+JGjqWdNAnR pw8170ju6AHLjqZ4q4zHfYTserTYPsgYxDqgdu/MpmSJZ5nfwvboADYh6pwvdO/M8fgT /w4nkHqcqdbsZPyMw9yE+q2fcvQi6SXmbnMtqvJZUW0WvjdAC4MDibGD++ZoKs9v8P1/ RqaDkvEQhT2yreBHCoWo1aCLU9PISTU/UceqtuD6dYWxAWzdvrtCEwlCRNhhyAKrVW5s 7J1mP0XyiCEOrMPgxBY3T89NSNJzUpscEWF6bBga81aON+DsW2xYBLT3TbYjKJk3NsTQ HxCQ==
MIME-Version: 1.0
X-Received: by 10.236.85.112 with SMTP id t76mr50091072yhe.74.1394524801722; Tue, 11 Mar 2014 01:00:01 -0700 (PDT)
Received: by 10.170.202.7 with HTTP; Tue, 11 Mar 2014 01:00:01 -0700 (PDT)
In-Reply-To: 
References: <20140305115333.7635.9928.idtracker@ietfa.amsl.com> <335AD6ED-F820-4C3B-9C11-F6593D4EEE43@axelcdv.com> 
Date: Tue, 11 Mar 2014 09:00:01 +0100
Message-ID: 
From: Abdussalam Baryun 
To: Joe Macker 
Content-Type: multipart/alternative; boundary=20cf300e526d6feca504f4501b8f
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vqrjxNBNGW_-wcIeHLFazWhlUFI
Cc: " List" , =?ISO-8859-1?Q?Axel_Colin_de_Verdi=E8re?= , gerla , Soon Young Oh 
Subject: Re: [manet] Basic initial comment for draft-gerla-manet-odmrp-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Mar 2014 08:00:10 -0000

--20cf300e526d6feca504f4501b8f
Content-Type: text/plain; charset=ISO-8859-1

Comments below

On Tuesday, March 11, 2014, Joe Macker wrote:

>
> -------
> First off nice work!
>
> General Comments:
>
> (1) In a future revision, it would probably be good to discuss the design
> issues associated with finding the right value of Route Query refresh
> flooding intervals.  As you know, there have been plenty of published
> papers on the subject relating to ODMRP.


This is important to determine to get less network overhead.


> (2) Might want to discuss any relationship with any SSM from the IGMPv2,
> MLD perspective,etc.  Is there an intention to support SSM?The state is
> certainly source specific.

Agree

>
> (3) We could discuss more about how this could work with RFC 6130 concepts
> or where similar security considerations may lie.  This could be done down
> the road as we flesh things out more and consider acceptance as a  WG item.


I was thinking how the protocol works with 6130 as Thomas mentioned in his
review the multiple interfaces and addresses.


>
>
> Summary of More Specific Minor Comments on draft-gerla-manet-odmrp-02.pdf
>
> Page: 4
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:05:03 PM
> of a "forwarding group"
> also avril -> april in reference
>
> Page: 7
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:11:34 PM
> disctinct -> distinct
>
> Page: 8
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:15:10 PM
> neighbour->neighbor
> I personally have no issue with British spellings in IETF docs.
> But since RFC 6130 and Crhis Dearlove go this way


I prefer shorter words so neighbor is perfect, as long as it is understood.


>
> Page: 9
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:18:27 PM
> Security Considerations for sequencing
> Replay etc (see later in pg 22 comments)
> Page: 11
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:20:36 PM
> Fix sentence grammar:
> recommend remove "when"
> Page: 21
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:34:41 PM
> I think its great to have some potential convergence of capability here.
> The sentence duplication packets and message detection is malformed at
> least in the pdf version of the draft. Perhaps an xml,etc.
> Scoped flooding may be assisted by an SMF implementation as well.
> We have published and some unpublished improvements to these optimized
> flooding mechanisms (e.g., ECDS) that might provide more stability.
> both ipv4 and ipv6.


Please provide reference to the published optimized flooding.

Thanks
AB

--20cf300e526d6feca504f4501b8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Comments below

On Tuesday, March 11, 2014, Joe Macker  wrote:


-------

First off nice work!



General Comments:



(1) In a future revision, it would probably be good to discuss the design i=
ssues associated with finding the right value of Route Query refresh floodi=
ng intervals. =A0As you know, there have been plenty of published papers on=
 the subject relating to ODMRP.


This is important to determine to get less network=A0ov=
erhead.=A0




(2) Might want to discuss any relationship with any SSM from the IGMPv2, ML=
D perspective,etc. =A0Is there an intention to support SSM?The state is cer=
tainly source specific.
Agree=A0




(3) We could discuss more about how this could work with RFC 6130 concepts =
or where similar security considerations may lie. =A0This could be done dow=
n the road as we flesh things out more and consider acceptance as a =A0WG i=
tem.


=A0
I was thinking how the protocol works with 6130 as Thoma=
s mentioned in his review=A0the multiple interfaces and addresses.=A0
=

=A0






Summary of More Specific Minor Comments on draft-gerla-manet-odmrp-02.pdf


Page: 4

Author: macker Subject: Sticky Note Date: 3/10/14, 7:05:03 PM

of a "forwarding group"

also avril -> april in reference



Page: 7

Author: macker Subject: Sticky Note Date: 3/10/14, 7:11:34 PM

disctinct -> distinct



Page: 8

Author: macker Subject: Sticky Note Date: 3/10/14, 7:15:10 PM

neighbour->neighbor

I personally have no issue with British spellings in IETF docs.

But since RFC 6130 and Crhis Dearlove go this way

I prefer shorter words so neighbor is perfect,=A0as long as it is un=
derstood.=A0
=A0




Page: 9

Author: macker Subject: Sticky Note Date: 3/10/14, 7:18:27 PM

Security Considerations for sequencing

Replay etc (see later in pg 22 comments)

Page: 11

Author: macker Subject: Sticky Note Date: 3/10/14, 7:20:36 PM

Fix sentence grammar:

recommend remove "when"

Page: 21

Author: macker Subject: Sticky Note Date: 3/10/14, 7:34:41 PM

I think its great to have some potential convergence of capability here.
The sentence duplication packets and message detection is malformed at leas=
t in the pdf version of the draft. Perhaps an xml,etc.

Scoped flooding may be assisted by an SMF implementation as well.

We have published and some unpublished improvements to these optimized floo=
ding mechanisms (e.g., ECDS) that might provide more stability.

both ipv4 and ipv6.

Please provide referenc=
e to the published optimized flooding.=A0

Thanks
AB=A0


--20cf300e526d6feca504f4501b8f--


From nobody Tue Mar 11 01:38:33 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EB61A0381 for ; Tue, 11 Mar 2014 01:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHzxMkPdUcci for ; Tue, 11 Mar 2014 01:38:23 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id CA8591A0369 for ; Tue, 11 Mar 2014 01:38:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4F7A924090E; Tue, 11 Mar 2014 01:38:18 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.43.129] (unknown [37.160.56.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id ADE4F2408B2; Tue, 11 Mar 2014 01:37:34 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5AA59238-190B-4568-A42E-F810254E7B5A"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
In-Reply-To: <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org>
Date: Tue, 11 Mar 2014 09:37:03 +0100
Message-Id: <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com>
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org>
To: thomas Clausen 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/KnwLR-5S5JBQg7YczLn9z3_Ysfo
Cc: MANET IETF 
Subject: Re: [manet] draft-gerla-manetodmrp-02 review
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Mar 2014 08:38:30 -0000

--Apple-Mail=_5AA59238-190B-4568-A42E-F810254E7B5A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi Thomas,

Thanks again for your review. See inline for the replies point-by-point. =
A couple points I'd like to copy here:

- Your comments confirm there's a real need to clarify the way this =
would work with multiple interfaces: describe the =
router/interface/address relationship, explain which information set is =
per interface and which is per router (presumably few to none), and =
clarify which address comes from which interface of which node (host or =
router).

- You suggest moving appendix A to a section or subsection of section 7. =
A counter-proposal would be to describe only the message contents in =
section 7 (with the required and optional fields), and have Appendix A =
be only an "example encoding using RFC5444" section, that would contain =
no normative text. Would that be acceptable?

- I think this could be implemented in user-space, but I'm afraid that =
having to intercept the first data packet in order to build the =
multicast tree would require a kernel module. I'd appreciate it if =
someone more knowledgeable than me could infer or refute that.

- There's a need to clarify some of the vocabulary, such as the =
Multicast Overlay/Forwarding group relationship. Regarding that, I =
wonder if it wouldn't add more clarity to just drop the "Multicast =
Overlay" term, and only refer to the Forwarding Group. Thoughts?

Best,

Axel

Le 10 mars 2014 =E0 23:13, Thomas Heide Clausen =
 a =E9crit :

>=20
>=20
>> On 10 mars 2014, at 23:01, Axel Colin de Verdi=E8re =
 wrote:
>>=20
>> Hi Thomas,
>>=20
>> Thanks a lot for this thorough review.
>=20
> I know, I know. I am a pain in the behind like that ;)
>=20
>> I'll need a moment to go through it and get back to you though :).
>>=20
>=20
> Please do - especially, if there's something that's unclear that needs =
more explanation.
>=20
> Cheers,
>=20
> Thomas
>=20
>> Best,
>>=20
>> Axel
>>=20
>>> Le 10 mars 2014 =E0 19:43, Thomas Heide Clausen =
 a =E9crit :
>>>=20
>>> Dear All,
>>>=20
>>> As the authors requested feedback, I have given the most recent =
version of this document a review. My comments are below - but do also =
look at the attached PDF, it's easier to see where each comment applies =
in there ;)
>>>=20
>>> For those not wanting to read the whole review: I think that this is =
a well written document, I think it's an interesting idea, and I think =
it's worth taking further, so I'd encourage further further reviews and =
work.
>>>=20
>>> There are a few things that need to be addressed, though. Outside =
the obvious, 'security considerations' and 'the experiment', the main =
issue is "multiple interfaces and addresses". While the protocol, as I =
understand it, can work in multiple interfaces/addresses scenarios, I =
think that the specification is unclear on certain things such as which =
addresses go in which information sets (such as the Blacklist) and =
messages.
>>>=20
>>> Either way, see below, and see the file attached to this message - =
and I look forward to discussing this further with all y'all.
>>>=20
>>> Cheers,
>>>=20
>>> Thomas
>>>=20
>>> File: draft-gerla-manet-odmrp-02 - flattened.pdf
>>>=20
>>> Annotation summary:
>>>=20
>>> --- Page 1 ---
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> General Comments:
>>>=20
>>> I find this specification very well written, well structured, clear =
and easy to understand.=20
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Executive Summary:
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> I find this specification very well written, well structured, clear, =
and easy to understand. I believe that there are some clarifications =
that could be made, though, and a few "formal" things to correct - but =
also that the protocol specification is fairly straight-forward.

Thank you.

>>>=20
>>> Now, the one point that I think is needing a bit of effort is =
regarding routers with multiple interfaces and/or multiple addresses, =
which seems to not be fully specified. At least, it should be made clear =
which parts of the information base are per interface, and the =
processing adopted accordingly. The way the "blacklist", for example, is =
written actually permits an implementation to explicitly "do the wrong =
thing" when faced with routers with multiple interfaces. I think that =
it's fairly easy to clear up.

That makes sense. I actually had comments in that direction during =
IETF-week, so that confirms that the next big point to address is this. =
I hadn't seen the issue with the blacklist though, so thanks.

>>>=20
>>>=20
>>> General Comments:
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> I think I understand the general idea, though, of the way the =
specification is made: you describe, in abstract form, the protocol, =
signals, etc., and then you provide the mapping to RFC5444-elements in =
an appendix.
>>>=20
>>> That is not entirely stupid as idea, and the resulting document is =
actually nice and readable, but.....appendices can't (or, shouldn't) =
contain normative text. Indeed, there are many MUST/SHOULD/* in Appendix =
A.=20
>>>=20
>>> I suggest promoting Appendix A to a "numbered section" somewhere =
(perhaps after section 7?)=20

I have another suggestion, coming from some comments from Justin during =
IETF-week: section 7 could be written so as to contain only the fields =
carried by the protocol messages, stating which are required and which =
are optional (so as to get the MUST and other SHOULDs out of Appendix =
A), and suggest one possible encoding of these messages with RFC5444 in =
the appendix, since any correct encoding should be parsed into the right =
fields. That way the appendix would not contain any normative text, and =
anyone would be free to use his or her RFC5444 parser/encoder even if it =
encodes the fields differently. Would that work?

>>>=20
>>> While I know that it is early, I think it would be helpful to have =
some reflections on the security considerations. Recent experiences with =
the SEC-ADs indicate, that they're considerably more strict than they =
were even half a decade ago, so understanding "what we're getting =
ourselves into" if the WG gets involved with this protocol might be =
helpful.

Ok, I'll take a look at that.

>>>=20
>>> As was discussed during the MANET wg meeting in London, an =
EXPERIMENTAL document is supposed to enable an experiment, and that =
experiment should be documented. See e.g. RFC6971, section 1.2. I'll try =
to add a couple of my thoughts on what would make for good =
"experiments":

>>>=20
>>> I do believe that, perhaps, a distinguishing point of ODMRP vs. SMF =
and other such protocols: whereas these rely on "get a copy of the =
message to each router, then have the router decide if it delivers those =
to applications", ODMRP works by only getting copies of messages to =
routers that actually need it. So, an experiment establishing the =
boundaries where "efforts to constructing the overlay" are out-weighted =
by the benefits of not having to deliver a copy of the multicast message =
to each router.

Yes, I think that would be interesting. It might also be worth it to see =
if there's a way to adapt to network traffic and switch between the two =
modes. Another idea would be to try to figure out the possible scopes of =
deployments of ODMRP, i.e., if ODMRP can be used anywhere where OLSRv2 =
is deployed.

>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> Mobile Ad hoc Networking (MANET)
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> "Network Working Group" -- see RFC Editor tutorial slides, page 20
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> conventional tree-based,

Got it (x3).

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Now that I have thought this bit over....
>>>=20
>>> In the end, a tree is constructed, though, is it not? Join Queries =
flooded, then Join Replies sent back, in a "Tree-construction" fashion?
>>>=20

Yes, basically it wounds up being a tree. I should probably revise the =
abstract and applicability statement that way.

>>>=20
>>>=20
>>>=20
>>> --- Page 4 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> routing                    techniques to avoid
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> So, it is actually not clear what this means, specifically. The more =
I think about it, the less do I think of this as "on demand routing =
techniques" and the more do I think of this as "on-demand tree =
construction, with proactive maintenance",
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> The more I think about it, the less do I think of this as "on demand =
routing techniques" and the more do I think of this as "on-demand tree =
construction, with proactive maintenance",
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> The more I think about it, the less do I think of this as "on demand =
routing techniques" and the more do I think of this as "on-demand tree =
construction, with proactive maintenance".
>>>=20
>>> It is clear, that a sensible routing protocol creates and manages =
forwarding trees/graphs/groups only when there is an actual need for one =
to exist - so, in that regard, all sensible multicast routing protocols =
are "reactive".
>>>=20
>>> As I understand it, this protocol is generating the forwarding =
tree/graph/group from the (expected) source, and then that this is =
maintained by way of proactive signaling (for as long as there is a need =
for the forwarding tree/graph/group)
>>>=20
>>> I'd suggest being explicit as to this, both in introduction and in =
the abstract?

You're right, there's a proactive part - I'll amend the intro and =
applicability statement to reflect this.

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> I think that you actually also are importing terminology from =
RFC5444 here, are you not?  At least, section 7 "Packets and Messages" =
seems to be hinting at - but not calling out explicitly - that you are.
>>>=20
>>> I think I understand why you're not calling it out, with the way =
that the I-D is written and RFC5444 message mapping being in Appendix, =
but as I have suggested in "general comments", that organization might =
not be ideal?

See my previous reply for the organization, but I should probably still =
call out RFC5444.

>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> e.g.
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Technically, that's probably "i.e., " as there are only those two =
message types, yes?

Ok.

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> I would suggest answering the question, which is on everybody's =
lips, already here: does this integrate with "regular IP Multicasting" =
or does it require "application level tunneling"?=20
>>>=20
>>> In other words, could I expect an mcast-capable application to "just =
work", and can I implement this "on a commodity OS", or will I have to =
do kernel-level hacks?
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> I would suggest answering the question, which is on everybody's =
lips, already here: does this integrate with "regular IP Multicasting" =
or does it require "application level tunneling"?=20
>>>=20
>>> In other words, could I expect an mcast-capable application to "just =
work", and can I implement this "on a commodity OS", or will I have to =
do kernel-level hacks to make it work?
>>>=20
>>> Having read through the document, I think that I infer that it's =
possible to build an user-space implementation manipulating working by =
simply multicast routing table entries.
>>>=20
>>> Would be good to have it confirmed that my understanding is correct =
- if it is, that is ;)

I think there are two things here. First, since it uses regular IGMP/MLD =
signaling, there is probably nothing to change on the "host" part of the =
protocol, and an application should work without any changes. However, =
although it seems possible to have an user-space implementation that =
just writes to the multicast routing table, I think there might be an =
issue with the original tree creation: I'm not sure it's possible to =
intercept the first data packet(s) to trigger the Join Query process =
without being in the kernel. But I'm not an expert with this, so =
somebody might correct me. In the meantime I'll dig a little deeper, see =
if I can figure something out.

>>>=20
>>>=20
>>> --- Page 5 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> addresses
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> I am going to pick out this here, but it applies elsewhere also: =
"addresses"?=20
>>>=20
>>> I believe that you aim at "address length independence", =
v6/v4/short, and that's a good idea which is, I believe, supported well =
by RFC5444. Alas, I believe that you probably want to stick in a =
definition and explanation of that in here.=20
>>>=20
>>> Also, I gather that these addresses are "interface identifiers" and =
not "multicast group addresses", yes? Given that this document talks =
about multicast, I do recommend perhaps calling this out?

Ok, will do. I think this will go in the whole "clarifying the =
router-interface-address relationship" part that goes with handling =
multiple interfaces.

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> I actually would love for you to repeat the example text for =
"Upstream" here, also. Yeah, it's repetitive, but when reading through a =
document and looking for a definition, it's nice to not be hunting.

Alright, no problem.

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> I am repeating my comment from the introduction here:
>>>=20
>>> The more I think about it, the less do I think of this as "on demand =
routing techniques" or a "reactive" protocol, and the more do I think of =
this as "on-demand tree construction, with proactive maintenance".
>>>=20
>>> It is clear, that a sensible routing protocol creates and manages =
forwarding trees/graphs/groups only when there is an actual need for one =
to exist - so, in that regard, all sensible multicast routing protocols =
are "reactive".
>>>=20
>>> As I understand it, this protocol is generating the forwarding =
tree/graph/group from the (expected) source, and then that this is =
maintained by way of proactive signaling (for as long as there is a need =
for the forwarding tree/graph/group)
>>>=20
>>> I'd suggest being explicit as to this, both in introduction and in =
the abstract?

Ok, that makes sense (same reply :)).

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Just to be clear; am I correct in understanding that:
>>>=20
>>> A Multicast Group Address, is used by applications, and joined (etc) =
by way of IGMP/MLD.

Yes.

>>>=20
>>> The ODMRP router hearing these,  maps that to a "Multicast Session".

Not exactly, since a Multicast Session is Multicast Group Address + =
Multicast Source Address, hence a router which has an attached host that =
has joined a Multicast Group Address might have several corresponding =
Multicast Sessions.

>>>=20
>>> That ODMRP router then proceeds to construct a Multicast Overlay for =
that multicast session; the Multicast Overlay of a multicast session is =
a source-rooted multicast tree?

Yes.

>>>=20
>>> Also, as I understand it, "Forwarding Group" and "Multicast Overlay" =
are, respectively, "links" and "routers" for a given Multicast Session?

I would say the opposite actually, the Forwarding Group is the set of =
routers that form the Multicast Overlay built by the JQ + JR process, =
and forward the Multicast data packets for the corresponding multicast =
session.

>>>=20
>>> I think that thats what it is, but the relationship between these =
terms/concepts  could merit being rendered crystal clear here.

Agreed. I wonder if it would not be clearer to drop the term "Multicast =
Overlay" altogether, and only refer to the Forwarding Group, since this =
is the most concrete construct used by ODMRP, and only call out in the =
intro and applicability statement that the Forwarding Group forms a =
source-rooted tree. Would that make more sense?

>>>=20
>>>=20
>>> --- Page 6 ---
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Suggest adding "These multicast overlays are, then, proactively =
maintained for as long as the overlay is needed (as long as there are =
members in the multicast group AND as long as there is data to be =
delivered to the multicast group)"

Ok.

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> IIRC there's a space after and before a "dash"......
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> overlay only
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> -> "overlay, only"
>>>=20
Got it (x3).

>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Correct, but not complete. The overlay is created, trigged by data =
to deliver to the members - but, no overlay is actually created unless =
there actually are members of the destination set.=20

Will clarify.

>>>=20
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> overlay for
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> -> "overlay only for...."
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> and until there no longer are members of the multicast group?

Got it, will clarify.

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Suggest "if the router belongs to, i.e., has attached hosts which =
have subscribed to, the multicast group ..."=20

Ok

>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> originates
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> This is a really detail-oriented comment, but "originates a Join =
Reply" here - and "Join Reply Generation" as the section title for =
section 9.1.2 is a little incoherent ;)=20

Got (x2).

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> I'd proffer that a lot this perhaps should be going in the =
"Signaling Overhead" rather than in this section; in part, as you =
describe messages and sets, before these are defined.
>>>=20
>>> As overview, it's quite too detailed, so perhaps jumping straight to =
4.2 and merging 4.1 into 4.3 is the best approach?
>>>=20
>>> Or, perhaps, have 4.2, then 4.3 and finally 4.1 ?

That makes sense. I think having 4.1 after 4.3 would be good.

>>>=20
>>>=20
>>> --- Page 7 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> carried
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> This is too "implicit": a "next hop address carried in a packet". =
You should, at least, in the previous bullet point indicate that a Join =
Reply carries a "next hop address" (and, possibly, what else it carries =
- I think that for duplicate JR suppression, that's important?)

I think this would be solved by having 4.3 before 4.1 so that the packet =
contents are known beforehand.

>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> it
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Suggest "If that next hop address is an address of this router..."

Ok.

>>>=20
>>> Also, what does "is an address of" or "corresponds to" this router =
mean, precisely? This may sound like a slightly silly question ;) but in =
NHDP/OLSRv2 we've had to be extremely careful with to what addresses =
correspond: a router, interfaces on that router, or addresses of hosts =
reachable by way of this router.
>>>=20
>>> The upshot of this is, that it's really easy to sort out, for =
example: "Is an address of an interface of this router", or something.

Got it, will add that to the whole address/interface clarification.

>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> ,
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> For readability, given that this is the overview and functioning:
>>>=20
>>> "If , , , then this ODMRP Router =
belongs to the forwarding group for the multicast session. Consequently, =
it installs ..."=20
>>>=20
>>>=20
>>> A secondary comment here is, that you have defined "Multicast =
Session" in the terminology, but you're not using it here (rather, you =
say "......Forwarding Group, which correspondS [sic] to this multicast =
group and source..."\

Got it.

>>>=20
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> This is confusing. What is actually discarded here? I.e., what does =
"it" correspond to"?

Yeah, I guess there are too many "it"s and possible objects in that =
paragraph, will rephrase.

>>>=20
>>>=20
>>> --- Page 8 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> flooded periodically
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Suggest adding that/if that can be done by way of an optimized =
flooding operation, if available on the network.

Ok.

>>>=20
>>>=20
>>> --- Page 9 ---
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> This probably needs a bit more of explanation. As I indicated in the =
general comments, the separation of abstract message content, and =
5444-encoding is a possible way to go, but it is not clear at this point =
that that's what's being done.
>>>=20
>>> As a consequence, it is not clear why the section title is "Packets =
and Messages" - those are (in MANET) 5444-constructs, typically.
>>>=20
>>> One possibility could be to stick Appendix A after section 7. =
Another, to have appendix A be a subsection to section 7.

Agreed, this is not clear enough. See my previous reply for a =
counter-proposal though (i.e., clarify the separation and keep Appendix =
A as an "example encoding"). Otherwise promoting appendix A to a section =
or subsection of sec 7 would work too I guess.

>>>=20
>>>=20
>>>=20
>>>=20
>>> --- Page 11 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> Multicast Source
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Somewhat of the same comment as one I have made before: "the address =
of the Multicast Source"
>>>=20
>>> First, is the "Multicast Source" the router, through which the =
multicast data messages ingress through, or is it the host on which the =
application generating data, is? Does it make any difference? "Multicast =
Source" is not defined.

I think that provided that the host-to-router relationship is 1-1 and =
well defined, having the Multicast Source be the actual host sending the =
data would work. But it's true that there's a need to be explicit there.
>>>=20
>>> Second, what about multiple interfaces/addresses?=20
>>>=20
>>> I can probably infer how it should be: this is the IP address that =
one will find in the source-address field of IP multicast datagrams, =
yes? If so, perhaps just call that out somewhere so there's no doubt.

Yup, will do then.

>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> address of the neighbor ODMRP Router
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Jumping on this just once more. "The address of the neighbor ODMRP =
router..."
>>>=20
>>> The way it is written, one gets the impression that ODMRP is =
designed for single-interface-single-address routers.=20
>>>=20
>>> I do not *think* that this is the case, and it certainly does not =
have to be made a constraint, so I recommend clearing that up. =
(Conversely, if it is the case, call that out as a constraint in =
applicability section). This applies actually through the document, so =
looking at giving it a pass through with "remove doubts as to =
multi-if/addr" as objective would be great.
>>>=20

Yup, next big item is "clarify multiple interfaces/addresses and =
associated".

>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> R_source
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Why is it P_multicast_source, but this is R_source?

Because I need to make a "consistency pass" through the document I =
think.

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> =46rom this description, it appears that it all is "per router" and =
with no "per interface" sets, is that correct?
>>>=20
>>> As I have indicated for the "Blacklist" this may be problematic, or =
at least necessitate some extra care to specify completely.

You're right, I think most of these sets should be "per interface".

>>>=20
>>>=20
>>> --- Page 12 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> Multicast Source
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> See previous question regarding Multicast Source
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Contrary to previous...._source, this is unambiguous ;)
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> F_source
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Why is it P_multicast_source, but this is F_source?

Got it (x5).

>>>=20
>>>=20
>>> --- Page 13 ---
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> I would probably say "...over which the Join Reply was sent"
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> an

Got it.

>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> ODMRP Routers
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> What if two routers, A and B, have two interfaces a1, a2, b1, b2?
>>>=20
>>> If A can hear B over a
>>>=20
>>>=20
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> What if two routers, A and B, have two interfaces a1, a2, b1, b2?
>>>=20
>>> If A can hear B over (a1, b1) and B can hear A over (a2, b2), what =
addresses go into this set?
>>>=20
>>> Also, what if A can hear B over (a1, b1) (and B can hear A over the =
same pair), and A can hear B over (a1,b2) but B cannot....?
>>>=20
>>> In other words, is this set per interface or per router?
>>>=20
>>> And, what are the addresses you put in there, interface addresses, =
or "RouterIDs"?

This should be per interface, and described as such. Will do that.

>>>=20
>>>=20
>>>=20
>>> --- Page 14 ---
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Alright, so reading this, it seems that the blacklist must be "per =
interface", yes?

Yes

>>>=20
>>>=20
>>> --- Page 15 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> an address
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Which address? Any? Always the same? Does it matter?

I think this should actually be the Multicast Source address, so as to =
map the Join Query to a Multicast Session.

>>>=20
>>>=20
>>> --- Page 16 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> an address
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Which address? Any? Always the same? Does it matter?
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> neighbors
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> I assume that what you want is to forward to all the neighbors on =
all ODMRP interfaces of this router, yes?

Yes, although I should probably call out more explicitly that the JQ =
should be passed to the forwarding mechanism in place in the network (so =
that if SMF with ECDS - or OLSRv2's MPR - is in place it can be used for =
example).

>>>=20
>>>=20
>>>=20
>>> --- Page 19 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> neighbors
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Over all ODMRP Interfaces?
>>>=20
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Here, we are gleaning a bit more precisely what the R_source is; so =
its an interface of an ODMRP router over which the Join Reply was sent, =
yes?

Actually I think I should refactor the document to map this to the =
multicast source. This should help in mapping various information base =
tuples to the multicast session, and avoid issues such as choosing which =
address to put in a newly-generated join query.

>>>=20
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> Else
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Else -> "Otherwise, if a tuple exists, ..."
>>>=20
>>>=20
>>> --- Page 20 ---
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> "Otherwise, ..."
>>>=20

Got it (x2).

>>>=20
>>> --- Page 21 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> Else
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> ->Otherwise
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Really nit-picking, but " i.e. " -> " i.e., " is the RFC-Editor =
style....

Got it.

>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Suggest: "...run in conjunction with, and benefit from some of the =
features of, SMF..."
>>>=20
>>> Strikeout (red), 10 mars 2014 19:24, TClausen:
>>> and                benefit from some of its features.
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> I would be hesitant to call this section "SMF Considerations"
>>>=20
>>> While SMF is an important and useful protocol set, I would suggest =
that this section be generalized: what's at stake is, and I think that I =
saw that in the slides that were presented in the London IETF, that if =
there's a "more efficient than classic flooding" network-wider broadcast =
operation in place, then ODMRP would/should use it - correct?
>>>=20
>>> This might be by way of SMF, or it could be as an extension to =
OLSRv2's MPR flooding, or it could be (as is seen in for example HNCP) =
something based off of Trickle - or something entirely different.
>>>=20
>>> So, perhaps "Flooding considerations" as section title, and a bit =
generalized text would work?

Funny enough, this was the original title - I'll put that back in then, =
and generalize to other possible flooding mechanisms.

>>>=20
>>>=20
>>> --- Page 22 ---
>>>=20
>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>> Packets
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Packets -> Packet
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> OK, I think that this document should start by actually requesting =
the allocations for the two message types. Cf. how it is done in section =
18.2 of RFC6130
>>>=20
>>> Then, I *think* that the current 15.1 is the Message-Type-Specific =
TLV Type Registries" that are being set up, for Join-Query yes? I see =
"Expert Review" mentioned, but no guidelines/recommendations for the =
Expert to follow. Do you intend to mirror those from RFC5444, or are =
there special concerns to take into consideration?
>>>=20
>>> I would actually suggest mirroring the structure of the IANA section =
from RFC6130  if for no other reasons, than that it's allocating from =
RFC5444-registries, and has been going through the process and so it may =
be assumed that something mirroring it will, too. ;)

Alright, will look at that and do so then.

>>>=20
>>>=20
>>>=20
>>> --- Page 25 ---
>>>=20
>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>> Just a comment, a cursory review of the mapping to RFC5444 doesn't =
have anything jump at me screaming "problems", which is good.
>>>=20
>>> I was wondering one thing, though: if running OLSRv2 + ODMRP, then =
there's an obvious option which could be considered (and could be =
considered, in order to be disregarded)....
>>>=20
>>> Could one imagine carrying ODMRP signals inside TC messages in any =
meaningful way, as TLVs and additional addresses included? *technically* =
it should be possible, does it make sense?

Technically that should work, I guess the advantage would be to have =
less duplicate information flooded throughout the network, and overall =
less packets sent, but I'm not sure it would be easy to encode that in =
any way that would 1) prevent too much duplicate information and 2) be =
easy to parse (both for the specs reader and the implementation). So I'm =
worried this would not really be worth it.

>>>=20
>>> A second thing, is there any reason to request both JR and JQ =
message type, or is there a way of using just a single code-point, and =
are there potential benefits in doing so?
>>>=20
>>> A different way of phrasing the above is: given that code-points by =
definition are limited, I'd like to ask for a bit more of =
"justification" before they are allocated.

Well first off, in a more "abstract" sense I think it's clearer to keep =
the JQ vs JR distinction throughout the document. However it could be =
envisioned to have only a ODMRP-message type with a "flags" TLV that =
would have one flag determining whether the message is actually treated =
as a JQ or a JR. After all, the two messages are pretty similar in =
content. For now the only drawback I see is that it would slightly =
increase the message size. But I guess the same reasoning could be done =
with a lot of protocols, no?
>>>=20
>>> FWIW, I've not had the cycles to review the appendices, other than =
Appendix A.
>>>=20
>>>=20
>>> (report generated by GoodReader)
>>>=20
>>>=20
>>>=20
>>> 
>>>=20
>>>=20
>>> Sent from my iPad_______________________________________________
>>> 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=_5AA59238-190B-4568-A42E-F810254E7B5A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


Hi Thomas,

Thanks =
again for your review. See inline for the replies point-by-point. A =
couple points I'd like to copy here:

- Your =
comments confirm there's a real need to clarify the way this would work =
with multiple interfaces: describe the router/interface/address =
relationship, explain which information set is per interface and which =
is per router (presumably few to none), and clarify which address comes =
from which interface of which node (host or =
router).

- You suggest moving appendix A to a =
section or subsection of section 7. A counter-proposal would be to =
describe only the message contents in section 7 (with the required and =
optional fields), and have Appendix A be only an "example encoding using =
RFC5444" section, that would contain no normative text. Would that be =
acceptable?

- I think this could be implemented =
in user-space, but I'm afraid that having to intercept the first data =
packet in order to build the multicast tree would require a kernel =
module. I'd appreciate it if someone more knowledgeable than me could =
infer or refute that.

- There's a need to =
clarify some of the vocabulary, such as the Multicast Overlay/Forwarding =
group relationship. Regarding that, I wonder if it wouldn't add more =
clarity to just drop the "Multicast Overlay" term, and only refer to the =
Forwarding Group. =
Thoughts?

Best,

Axel

Le 10 mars 2014 =E0 23:13, Thomas Heide =
Clausen <thomas@thomasclausen.org> =
a =E9crit :



On=
 10 mars 2014, at 23:01, Axel Colin de Verdi=E8re <axel-ietf@axelcdv.com> =
wrote:

Hi Thomas,

Thanks a lot for this thorough =
review.

I know, I know. I am a pain in the behind =
like that ;)

I'll need a moment to go =
through it and get back to you though :).


Please =
do - especially, if there's something that's unclear that needs more =
explanation.

Cheers,

Thomas

Best,

Axel

Le 10 =
mars 2014 =E0 19:43, Thomas Heide Clausen <thomas@thomasclausen.org> =
a =E9crit :

Dear All,

As the authors requested feedback, I =
have given the most recent version of this document a review. My =
comments are below - but do also look at the attached PDF, it's easier =
to see where each comment applies in there ;)

For those not =
wanting to read the whole review: I think that this is a well written =
document, I think it's an interesting idea, and I think it's worth =
taking further, so I'd encourage further further reviews and =
work.

There are a few things that need to be addressed, though. =
Outside the obvious, 'security considerations' and 'the experiment', the =
main issue is "multiple interfaces and addresses". While the protocol, =
as I understand it, can work in multiple interfaces/addresses scenarios, =
I think that the specification is unclear on certain things such as =
which addresses go in which information sets (such as the Blacklist) and =
messages.

Either way, see below, and see the file attached to =
this message - and I look forward to discussing this further with all =
y'all.

Cheers,

Thomas

File: =
draft-gerla-manet-odmrp-02 - flattened.pdf

Annotation =
summary:

--- Page 1 ---

Note (yellow), 10 mars 2014 19:24, =
TClausen:
General Comments:

I find this specification very =
well written, well structured, clear and easy to understand. 

Note (yellow), 10 =
mars 2014 19:24, TClausen:
Executive =
Summary:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I find =
this specification very well written, well structured, clear, and easy =
to understand. I believe that there are some clarifications that could =
be made, though, and a few "formal" things to correct - but also that =
the protocol specification is fairly =
straight-forward.
Thank you.


Now, the one point that I think is needing a bit of =
effort is regarding routers with multiple interfaces and/or multiple =
addresses, which seems to not be fully specified. At least, it should be =
made clear which parts of the information base are per interface, and =
the processing adopted accordingly. The way the "blacklist", for =
example, is written actually permits an implementation to explicitly "do =
the wrong thing" when faced with routers with multiple interfaces. I =
think that it's fairly easy to clear =
up.

Th=
at makes sense. I actually had comments in that direction during =
IETF-week, so that confirms that the next big point to address is this. =
I hadn't seen the issue with the blacklist though, so =
thanks.



General =
Comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I think =
I understand the general idea, though, of the way the specification is =
made: you describe, in abstract form, the protocol, signals, etc., and =
then you provide the mapping to RFC5444-elements in an =
appendix.

That is not entirely stupid as idea, and the resulting =
document is actually nice and readable, but.....appendices can't (or, =
shouldn't) contain normative text. Indeed, there are many MUST/SHOULD/* =
in Appendix A. 

I=
 suggest promoting Appendix A to a "numbered section" somewhere (perhaps =
after section 7?) 

I have another suggestion, =
coming from some comments from Justin during IETF-week: section 7 could =
be written so as to contain only the fields carried by the protocol =
messages, stating which are required and which are optional (so as to =
get the MUST and other SHOULDs out of Appendix A), and suggest one =
possible encoding of these messages with RFC5444 in the appendix, since =
any correct encoding should be parsed into the right fields. That way =
the appendix would not contain any normative text, and anyone would be =
free to use his or her RFC5444 parser/encoder even if it encodes the =
fields differently. Would that work?


While I know that it is =
early, I think it would be helpful to have some reflections on the =
security considerations. Recent experiences with the SEC-ADs indicate, =
that they're considerably more strict than they were even half a decade =
ago, so understanding "what we're getting ourselves into" if the WG gets =
involved with this protocol might be =
helpful.

Ok=
, I'll take a look at that.


As was discussed during the MANET wg meeting in =
London, an EXPERIMENTAL document is supposed to enable an experiment, =
and that experiment should be documented. See e.g. RFC6971, section 1.2. =
I'll try to add a couple of my thoughts on what would make for good =
"experiments":

I do believe that, perhaps, =
a distinguishing point of ODMRP vs. SMF and other such protocols: =
whereas these rely on "get a copy of the message to each router, then =
have the router decide if it delivers those to applications", ODMRP =
works by only getting copies of messages to routers that actually need =
it. So, an experiment establishing the boundaries where "efforts to =
constructing the overlay" are out-weighted by the benefits of not having =
to deliver a copy of the multicast message to each =
router.

Yes, I think that would be interesting. It might also be worth it to =
see if there's a way to adapt to network traffic and switch between the =
two modes. Another idea would be to try to figure out the possible =
scopes of deployments of ODMRP, i.e., if ODMRP can be used anywhere =
where OLSRv2 is deployed.


Highlight (yellow), 10 mars =
2014 19:24, TClausen:
Mobile Ad hoc Networking (MANET)

Note =
(yellow), 10 mars 2014 19:24, TClausen:
"Network Working Group" -- =
see RFC Editor tutorial slides, page 20

Highlight (yellow), 10 =
mars 2014 19:24, TClausen:
conventional =
tree-based,

Got it (x3).


Note (yellow), 10 mars 2014 19:24, TClausen:
Now =
that I have thought this bit over....

In the end, a tree is =
constructed, though, is it not? Join Queries flooded, then Join Replies =
sent back, in a "Tree-construction" =
fashion?


Yes, =
basically it wounds up being a tree. I should probably revise the =
abstract and applicability statement that way.




--- Page 4 =
---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
routing =
            &n=
bsp;      techniques to avoid

Note =
(yellow), 10 mars 2014 19:24, TClausen:
So, it is actually not clear =
what this means, specifically. The more I think about it, the less do I =
think of this as "on demand routing techniques" and the more do I think =
of this as "on-demand tree construction, with proactive =
maintenance",

Note (yellow), 10 mars 2014 19:24, TClausen:
The =
more I think about it, the less do I think of this as "on demand routing =
techniques" and the more do I think of this as "on-demand tree =
construction, with proactive maintenance",

Note (yellow), 10 mars =
2014 19:24, TClausen:
The more I think about it, the less do I think =
of this as "on demand routing techniques" and the more do I think of =
this as "on-demand tree construction, with proactive =
maintenance".

It is clear, that a sensible routing protocol =
creates and manages forwarding trees/graphs/groups only when there is an =
actual need for one to exist - so, in that regard, all sensible =
multicast routing protocols are "reactive".

As I understand it, =
this protocol is generating the forwarding tree/graph/group from the =
(expected) source, and then that this is maintained by way of proactive =
signaling (for as long as there is a need for the forwarding =
tree/graph/group)

I'd suggest being explicit as to this, both in =
introduction and in the =
abstract?

<=
div>You're right, there's a proactive part - I'll amend the intro and =
applicability statement to reflect this.


Note (yellow), 10 mars 2014 =
19:24, TClausen:
I think that you actually also are importing =
terminology from RFC5444 here, are you not?  At least, section 7 =
"Packets and Messages" seems to be hinting at - but not calling out =
explicitly - that you are.

I think I understand why you're not =
calling it out, with the way that the I-D is written and RFC5444 message =
mapping being in Appendix, but as I have suggested in "general =
comments", that organization might not be =
ideal?

See =
my previous reply for the organization, but I should probably still call =
out RFC5444.


Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
e.g.

Note (yellow), 10 mars 2014 19:24, =
TClausen:
Technically, that's probably "i.e., " as there are only =
those two message types, =
yes?

O=
k.


Note =
(yellow), 10 mars 2014 19:24, TClausen:
I would suggest answering the =
question, which is on everybody's lips, already here: does this =
integrate with "regular IP Multicasting" or does it require "application =
level tunneling"? 

In other words, =
could I expect an mcast-capable application to "just work", and can I =
implement this "on a commodity OS", or will I have to do kernel-level =
hacks?

Note (yellow), 10 mars 2014 19:24, TClausen:
I would =
suggest answering the question, which is on everybody's lips, already =
here: does this integrate with "regular IP Multicasting" or does it =
require "application level tunneling"? 

In other words, =
could I expect an mcast-capable application to "just work", and can I =
implement this "on a commodity OS", or will I have to do kernel-level =
hacks to make it work?

Having read through the document, I think =
that I infer that it's possible to build an user-space implementation =
manipulating working by simply multicast routing table =
entries.

Would be good to have it confirmed that my understanding =
is correct - if it is, that is =
;)

I =
think there are two things here. First, since it uses regular IGMP/MLD =
signaling, there is probably nothing to change on the "host" part of the =
protocol, and an application should work without any changes. However, =
although it seems possible to have an user-space implementation that =
just writes to the multicast routing table, I think there might be an =
issue with the original tree creation: I'm not sure it's possible to =
intercept the first data packet(s) to trigger the Join Query process =
without being in the kernel. But I'm not an expert with this, so =
somebody might correct me. In the meantime I'll dig a little deeper, see =
if I can figure something out.



--- Page 5 ---

Highlight (yellow), 10 mars =
2014 19:24, TClausen:
addresses

Note (yellow), 10 mars 2014 =
19:24, TClausen:
I am going to pick out this here, but it applies =
elsewhere also: "addresses"? 

I believe that you =
aim at "address length independence", v6/v4/short, and that's a good =
idea which is, I believe, supported well by RFC5444. Alas, I believe =
that you probably want to stick in a definition and explanation of that =
in here. 

Also, =
I gather that these addresses are "interface identifiers" and not =
"multicast group addresses", yes? Given that this document talks about =
multicast, I do recommend perhaps calling this =
out?

Ok, =
will do. I think this will go in the whole "clarifying the =
router-interface-address relationship" part that goes with handling =
multiple interfaces.


Note (yellow), 10 mars 2014 19:24, TClausen:
I =
actually would love for you to repeat the example text for "Upstream" =
here, also. Yeah, it's repetitive, but when reading through a document =
and looking for a definition, it's nice to not be =
hunting.

Al=
right, no problem.


Note (yellow), 10 mars 2014 19:24, TClausen:
I am =
repeating my comment from the introduction here:

The more I think =
about it, the less do I think of this as "on demand routing techniques" =
or a "reactive" protocol, and the more do I think of this as "on-demand =
tree construction, with proactive maintenance".

It is clear, that =
a sensible routing protocol creates and manages forwarding =
trees/graphs/groups only when there is an actual need for one to exist - =
so, in that regard, all sensible multicast routing protocols are =
"reactive".

As I understand it, this protocol is generating the =
forwarding tree/graph/group from the (expected) source, and then that =
this is maintained by way of proactive signaling (for as long as there =
is a need for the forwarding tree/graph/group)

I'd suggest being =
explicit as to this, both in introduction and in the =
abstract?

O=
k, that makes sense (same reply :)).


Note (yellow), 10 mars 2014 =
19:24, TClausen:
Just to be clear; am I correct in understanding =
that:

A Multicast Group Address, is used by applications, and =
joined (etc) by way of =
IGMP/MLD.

Y=
es.


The ODMRP =
router hearing these,  maps that to a "Multicast =
Session".

N=
ot exactly, since a Multicast Session is Multicast Group Address + =
Multicast Source Address, hence a router which has an attached host that =
has joined a Multicast Group Address might have several corresponding =
Multicast Sessions.


That ODMRP router then proceeds to construct a =
Multicast Overlay for that multicast session; the Multicast Overlay of a =
multicast session is a source-rooted multicast =
tree?

Yes.<=
/div>


Also, as I =
understand it, "Forwarding Group" and "Multicast Overlay" are, =
respectively, "links" and "routers" for a given Multicast =
Session?

I =
would say the opposite actually, the Forwarding Group is the set of =
routers that form the Multicast Overlay built by the JQ + JR process, =
and forward the Multicast data packets for the corresponding multicast =
session.


I think =
that thats what it is, but the relationship between these terms/concepts =
 could merit being rendered crystal clear =
here.

Agree=
d. I wonder if it would not be clearer to drop the term "Multicast =
Overlay" altogether, and only refer to the Forwarding Group, since this =
is the most concrete construct used by ODMRP, and only call out in the =
intro and applicability statement that the Forwarding Group forms a =
source-rooted tree. Would that make more =
sense?



--- =
Page 6 ---

Note (yellow), 10 mars 2014 19:24, =
TClausen:
Suggest adding "These multicast overlays are, then, =
proactively maintained for as long as the overlay is needed (as long as =
there are members in the multicast group AND as long as there is data to =
be delivered to the multicast =
group)"

Ok.=



Note =
(yellow), 10 mars 2014 19:24, TClausen:
IIRC there's a space after =
and before a "dash"......

Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
overlay only

Note (yellow), 10 mars 2014 19:24, =
TClausen:
-> "overlay, =
only"

Got it =
(x3).

Note (yellow), =
10 mars 2014 19:24, TClausen:
Correct, but not complete. The overlay =
is created, trigged by data to deliver to the members - but, no overlay =
is actually created unless there actually are members of the destination =
set. 

Will =
clarify.



Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
overlay for

Note (yellow), 10 mars 2014 19:24, =
TClausen:
-> "overlay only for...."

Note (yellow), 10 mars =
2014 19:24, TClausen:
and until there no longer are members of the =
multicast =
group?

Got =
it, will clarify.


Note (yellow), 10 mars 2014 19:24, =
TClausen:
Suggest "if the router belongs to, i.e., has attached hosts =
which have subscribed to, the multicast group ..." 

Ok


Highlight (yellow), 10 mars =
2014 19:24, TClausen:
originates

Note (yellow), 10 mars 2014 =
19:24, TClausen:
This is a really detail-oriented comment, but =
"originates a Join Reply" here - and "Join Reply Generation" as the =
section title for section 9.1.2 is a little incoherent ;) 

Got (x2).


Note (yellow), 10 mars 2014 =
19:24, TClausen:
I'd proffer that a lot this perhaps should be going =
in the "Signaling Overhead" rather than in this section; in part, as you =
describe messages and sets, before these are defined.

As =
overview, it's quite too detailed, so perhaps jumping straight to 4.2 =
and merging 4.1 into 4.3 is the best approach?

Or, perhaps, have =
4.2, then 4.3 and finally 4.1 =
?

That =
makes sense. I think having 4.1 after 4.3 would be =
good.



--- =
Page 7 ---

Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
carried

Note (yellow), 10 mars 2014 19:24, =
TClausen:
This is too "implicit": a "next hop address carried in a =
packet". You should, at least, in the previous bullet point indicate =
that a Join Reply carries a "next hop address" (and, possibly, what else =
it carries - I think that for duplicate JR suppression, that's =
important?)

I think this would be solved by having 4.3 before 4.1 so that the =
packet contents are known beforehand.


Highlight (yellow), 10 mars =
2014 19:24, TClausen:
it

Note (yellow), 10 mars 2014 19:24, =
TClausen:
Suggest "If that next hop address is an address of this =
router..."

=
Ok.


Also, what =
does "is an address of" or "corresponds to" this router mean, precisely? =
This may sound like a slightly silly question ;) but in NHDP/OLSRv2 =
we've had to be extremely careful with to what addresses correspond: a =
router, interfaces on that router, or addresses of hosts reachable by =
way of this router.

The upshot of this is, that it's really easy =
to sort out, for example: "Is an address of an interface of this =
router", or =
something.

=
Got it, will add that to the whole address/interface =
clarification.


Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
,

Note (yellow), 10 mars 2014 19:24, =
TClausen:
For readability, given that this is the overview and =
functioning:

"If <condition>, <condition>, =
<condition>, then this ODMRP Router belongs to the forwarding =
group for the multicast session. Consequently, it installs ..." 


A secondary =
comment here is, that you have defined "Multicast Session" in the =
terminology, but you're not using it here (rather, you say =
"......Forwarding Group, which correspondS [sic] to this multicast group =
and =
source..."\

Got it.



Note =
(yellow), 10 mars 2014 19:24, TClausen:
This is confusing. What is =
actually discarded here? I.e., what does "it" correspond =
to"?

Yeah, =
I guess there are too many "it"s and possible objects in that paragraph, =
will rephrase.



--- Page 8 ---

Highlight (yellow), 10 mars =
2014 19:24, TClausen:
flooded periodically

Note (yellow), 10 =
mars 2014 19:24, TClausen:
Suggest adding that/if that can be done by =
way of an optimized flooding operation, if available on the =
network.

Ok=
.



--- =
Page 9 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
This =
probably needs a bit more of explanation. As I indicated in the general =
comments, the separation of abstract message content, and 5444-encoding =
is a possible way to go, but it is not clear at this point that that's =
what's being done.

As a consequence, it is not clear why the =
section title is "Packets and Messages" - those are (in MANET) =
5444-constructs, typically.

One possibility could be to stick =
Appendix A after section 7. Another, to have appendix A be a subsection =
to section =
7.

Agreed, =
this is not clear enough. See my previous reply for a counter-proposal =
though (i.e., clarify the separation and keep Appendix A as an "example =
encoding"). Otherwise promoting appendix A to a section or subsection of =
sec 7 would work too I guess.





--- Page 11 ---

Highlight (yellow), =
10 mars 2014 19:24, TClausen:
Multicast Source

Note (yellow), =
10 mars 2014 19:24, TClausen:
Somewhat of the same comment as one I =
have made before: "the address of the Multicast Source"

First, is =
the "Multicast Source" the router, through which the multicast data =
messages ingress through, or is it the host on which the application =
generating data, is? Does it make any difference? "Multicast Source" is =
not =
defined.

I =
think that provided that the host-to-router relationship is 1-1 and well =
defined, having the Multicast Source be the actual host sending the data =
would work. But it's true that there's a need to be explicit =
there.

Second, =
what about multiple interfaces/addresses? 

I can probably =
infer how it should be: this is the IP address that one will find in the =
source-address field of IP multicast datagrams, yes? If so, perhaps just =
call that out somewhere so there's no =
doubt.

Yup,=
 will do then.


Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
address of the neighbor ODMRP Router

Note (yellow), =
10 mars 2014 19:24, TClausen:
Jumping on this just once more. "The =
address of the neighbor ODMRP router..."

The way it is written, =
one gets the impression that ODMRP is designed for =
single-interface-single-address routers. 

I do not *think* =
that this is the case, and it certainly does not have to be made a =
constraint, so I recommend clearing that up. (Conversely, if it is the =
case, call that out as a constraint in applicability section). This =
applies actually through the document, so looking at giving it a pass =
through with "remove doubts as to multi-if/addr" as objective would be =
great.


=

Yup, next big item is "clarify multiple interfaces/addresses and =
associated".


Highlight =
(yellow), 10 mars 2014 19:24, TClausen:
R_source

Note =
(yellow), 10 mars 2014 19:24, TClausen:
Why is it P_multicast_source, =
but this is =
R_source?

B=
ecause I need to make a "consistency pass" through the document I =
think.


Note =
(yellow), 10 mars 2014 19:24, TClausen:
=46rom this description, it =
appears that it all is "per router" and with no "per interface" sets, is =
that correct?

As I have indicated for the "Blacklist" this may be =
problematic, or at least necessitate some extra care to specify =
completely.

You're right, I think most of these sets should be "per =
interface".



--- Page 12 ---

Highlight (yellow), 10 mars =
2014 19:24, TClausen:
Multicast Source

Note (yellow), 10 mars =
2014 19:24, TClausen:
See previous question regarding Multicast =
Source

Note (yellow), 10 mars 2014 19:24, TClausen:
Contrary =
to previous....<something>_source, this is unambiguous =
;)

Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
F_source

Note (yellow), 10 mars 2014 19:24, =
TClausen:
Why is it P_multicast_source, but this is =
F_source?

G=
ot it (x5).



--- Page 13 ---

Note (yellow), 10 mars 2014 =
19:24, TClausen:
I would probably say "...over which the Join Reply =
was sent"

Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
an

<=
/div>Got it.


Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
ODMRP Routers

Note (yellow), 10 mars 2014 19:24, =
TClausen:
What if two routers, A and B, have two interfaces a1, a2, =
b1, b2?

If A can hear B over a



Note (yellow), 10 =
mars 2014 19:24, TClausen:
What if two routers, A and B, have two =
interfaces a1, a2, b1, b2?

If A can hear B over (a1, b1) and B =
can hear A over (a2, b2), what addresses go into this set?

Also, =
what if A can hear B over (a1, b1) (and B can hear A over the same =
pair), and A can hear B over (a1,b2) but B cannot....?

In other =
words, is this set per interface or per router?

And, what are the =
addresses you put in there, interface addresses, or =
"RouterIDs"?

This should be per interface, and described as such. Will do =
that.




--- =
Page 14 ---

Note (yellow), 10 mars 2014 19:24, =
TClausen:
Alright, so reading this, it seems that the blacklist must =
be "per interface", =
yes?

Yes



--- =
Page 15 ---

Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
an address

Note (yellow), 10 mars 2014 19:24, =
TClausen:
Which address? Any? Always the same? Does it =
matter?

I =
think this should actually be the Multicast Source address, so as to map =
the Join Query to a Multicast Session.



--- Page 16 =
---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
an =
address

Note (yellow), 10 mars 2014 19:24, TClausen:
Which =
address? Any? Always the same? Does it matter?

Highlight =
(yellow), 10 mars 2014 19:24, TClausen:
neighbors

Note =
(yellow), 10 mars 2014 19:24, TClausen:
I assume that what you want =
is to forward to all the neighbors on all ODMRP interfaces of this =
router, =
yes?

Yes, =
although I should probably call out more explicitly that the JQ should =
be passed to the forwarding mechanism in place in the network (so that =
if SMF with ECDS - or OLSRv2's MPR - is in place it can be used for =
example).




--- =
Page 19 ---

Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
neighbors

Note (yellow), 10 mars 2014 19:24, =
TClausen:
Over all ODMRP Interfaces?


Note (yellow), 10 =
mars 2014 19:24, TClausen:
Here, we are gleaning a bit more precisely =
what the R_source is; so its an interface of an ODMRP router over which =
the Join Reply was sent, =
yes?

Actual=
ly I think I should refactor the document to map this to the multicast =
source. This should help in mapping various information base tuples to =
the multicast session, and avoid issues such as choosing which address =
to put in a newly-generated join query.



Highlight (yellow), 10 =
mars 2014 19:24, TClausen:
Else

Note (yellow), 10 mars 2014 =
19:24, TClausen:
Else -> "Otherwise, if a tuple exists, =
..."


--- Page 20 ---

Note (yellow), 10 mars 2014 =
19:24, TClausen:
"Otherwise, =
..."


Got it =
(x2).


--- Page =
21 ---

Highlight (yellow), 10 mars 2014 19:24, =
TClausen:
Else

Note (yellow), 10 mars 2014 19:24, =
TClausen:
->Otherwise

Note (yellow), 10 mars 2014 19:24, =
TClausen:
Really nit-picking, but " i.e. " -> " i.e., " is the =
RFC-Editor =
style....

G=
ot it.


Note =
(yellow), 10 mars 2014 19:24, TClausen:
Suggest: "...run in =
conjunction with, and benefit from some of the features of, =
SMF..."

Strikeout (red), 10 mars 2014 19:24, TClausen:
and =
            &n=
bsp;  benefit from some of its features.

Note (yellow), =
10 mars 2014 19:24, TClausen:
I would be hesitant to call this =
section "SMF Considerations"

While SMF is an important and useful =
protocol set, I would suggest that this section be generalized: what's =
at stake is, and I think that I saw that in the slides that were =
presented in the London IETF, that if there's a "more efficient than =
classic flooding" network-wider broadcast operation in place, then ODMRP =
would/should use it - correct?

This might be by way of SMF, or it =
could be as an extension to OLSRv2's MPR flooding, or it could be (as is =
seen in for example HNCP) something based off of Trickle - or something =
entirely different.

So, perhaps "Flooding considerations" as =
section title, and a bit generalized text would =
work?

Funny=
 enough, this was the original title - I'll put that back in then, and =
generalize to other possible flooding =
mechanisms.



--- Page 22 ---

Highlight (yellow), 10 mars =
2014 19:24, TClausen:
Packets

Note (yellow), 10 mars 2014 =
19:24, TClausen:
Packets -> Packet

Note (yellow), 10 mars =
2014 19:24, TClausen:
OK, I think that this document should start by =
actually requesting the allocations for the two message types. Cf. how =
it is done in section 18.2 of RFC6130

Then, I *think* that the =
current 15.1 is the Message-Type-Specific TLV Type Registries" that are =
being set up, for Join-Query yes? I see "Expert Review" mentioned, but =
no guidelines/recommendations for the Expert to follow. Do you intend to =
mirror those from RFC5444, or are there special concerns to take into =
consideration?

I would actually suggest mirroring the structure =
of the IANA section from RFC6130  if for no other reasons, than =
that it's allocating from RFC5444-registries, and has been going through =
the process and so it may be assumed that something mirroring it will, =
too. =
;)

Alright,=
 will look at that and do so then.




--- Page 25 =
---

Note (yellow), 10 mars 2014 19:24, TClausen:
Just a =
comment, a cursory review of the mapping to RFC5444 doesn't have =
anything jump at me screaming "problems", which is good.

I was =
wondering one thing, though: if running OLSRv2 + ODMRP, then there's an =
obvious option which could be considered (and could be considered, in =
order to be disregarded)....

Could one imagine carrying ODMRP =
signals inside TC messages in any meaningful way, as TLVs and additional =
addresses included? *technically* it should be possible, does it make =
sense?

Tech=
nically that should work, I guess the advantage would be to have less =
duplicate information flooded throughout the network, and overall less =
packets sent, but I'm not sure it would be easy to encode that in any =
way that would 1) prevent too much duplicate information and 2) be easy =
to parse (both for the specs reader and the implementation). So I'm =
worried this would not really be worth it.


A second thing, is there any =
reason to request both JR and JQ message type, or is there a way of =
using just a single code-point, and are there potential benefits in =
doing so?

A different way of phrasing the above is: given that =
code-points by definition are limited, I'd like to ask for a bit more of =
"justification" before they are =
allocated.

=
Well first off, in a more "abstract" sense I think it's clearer to keep =
the JQ vs JR distinction throughout the document. However it could be =
envisioned to have only a ODMRP-message type with a "flags" TLV that =
would have one flag determining whether the message is actually treated =
as a JQ or a JR. After all, the two messages are pretty similar in =
content. For now the only drawback I see is that it would slightly =
increase the message size. But I guess the same reasoning could be done =
with a lot of protocols, no?

FWIW, I've not had the cycles to review the =
appendices, other than Appendix A.


(report generated by =
GoodReader)



<draft-gerla-manet-odmrp-02 - =
flattened.pdf>


Sent from my =
iPad_______________________________________________
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=_5AA59238-190B-4568-A42E-F810254E7B5A--


From nobody Tue Mar 11 01:43:29 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37DF1A03EA for ; Tue, 11 Mar 2014 01:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtOHeb6VlLaF for ; Tue, 11 Mar 2014 01:43:25 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id B09F81A03D9 for ; Tue, 11 Mar 2014 01:43:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6C1582406E2; Tue, 11 Mar 2014 01:43:20 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.43.129] (unknown [37.160.56.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id AD09D240615; Tue, 11 Mar 2014 01:43:14 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3784ACEA-3900-4A4C-B091-A50F9EF17D73"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
In-Reply-To: 
Date: Tue, 11 Mar 2014 09:37:05 +0100
Message-Id: 
References:  <33A31C2B-CD52-4FF6-B376-325237B7C585@thomasclausen.org>  
To: Abdussalam Baryun 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/y8bWgakmRdwfAXCCjIniZP0jtQE
Cc: manet , gerla 
Subject: Re: [manet] ODMRP new draft (was Re: IETF89 preliminary minutes
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Mar 2014 08:43:27 -0000

--Apple-Mail=_3784ACEA-3900-4A4C-B091-A50F9EF17D73
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi Abdussalam,

Slide 11 mentions that there is no *additional* overhead incurred by =
ODMRP_ASYM when there is no unidirectional link, not that there isn't =
any overhead with ODMRP. Slide 18 does not show multiple paths, it shows =
the way ODMRP_ASYM finds a detour paths to forward the Join Reply.
As for page 4 of the ODMRP draft, can you point me to the line where it =
says ODMRP maintains multiple paths? Last time I read it there was no =
such statement...
As for the overhead related to mobility, ODMRP does not incur any extra =
overhead when mobility is higher, except if you shorten =
ROUTE_REFRESH_INTERVAL to refresh the multicast overlay more often to =
increase delivery rates.

Axel

Le 11 mars 2014 =E0 01:03, Abdussalam Baryun =
 a =E9crit :

> Slide 11 and 18. In the draft page 4 it mentions that ODMRP maintains =
multiple paths. Regarding overhead, do you mean there is no overhead in =
this routing and if there is with higher mobility how does it optimise =
it.=20
>=20
> AB
>=20
> On Monday, March 10, 2014, Axel Colin de Verdi=E8re wrote:
> Hi Abdussalam, Thomas,
>=20
> Thank you for your comments. Indeed there are no multiple paths =
involved. Can you point me to the slide you're referring to? What do you =
mean by "optimise overhead"?
>=20
> Axel
>=20
> Le 10 mars 2014 =E0 20:32, Thomas Heide Clausen =
 a =E9crit :
>=20
>> Dear Abdussalam,
>>=20
>>=20
>> On 10 mars 2014, at 17:48, Abdussalam Baryun =
 wrote:
>>=20
>>> Hi Axel,
>>>=20
>>> Thanks for your presentation. I had a question at meeting but there =
was no time. =46rom the presentation (still I did not done review), =
there was one slide showing two paths to its destination, so does this =
multicast protocol use multipath to reach all its demanded destinations? =
And how does it optimise overhead?
>>>=20
>>=20
>> Having now reviewed the document in detail, let me venture a reply ;)
>>=20
>> I believe that, no, multiple paths to the same destination are not =
sought nor used. Of course, to multiple destinations, multiple paths =
(but with common path segments, as possible) result.
>>=20
>> I am interested, Abdussalam, have you read the document, and what are =
your detailed comments?
>>=20
>> Thomas
>>=20
>>> AB
>>>=20
>>> On Monday, March 10, 2014, Axel Colin de Verdi=E8re wrote:
>>> Hi all,
>>>=20
>>> We did not in fact request WG adoption for ODMRP and ODMRP_ASYM at =
this time, but we felt that the drafts were in good enough shape to ask =
for your comments and move in that direction.
>>>=20
>>> Axel
>>>=20
>>> Le 10 mars 2014 =E0 17:08, Abdussalam Baryun =
 a =E9crit :
>>>=20
>>>> Hi Thomas,
>>>>=20
>>>> Thanks for the update. I don't think the latest multicast draft was =
requested to be adopted in the meeting, but Ulrich did request his it =
for his draft, and I am waiting for announce on the list for DLEP plan =
and all adoption request in WG meeting.=20
>>>>=20
>>>> AB
>>>>=20
>>>> On Monday, March 10, 2014, Thomas Clausen wrote:
>>>> Ulrich,
>>>>=20
>>>> Thank you for prompt posting of minutes.
>>>> =20
>>>> A couple of things that I would like to make more precise, all the =
same, in the minutes:
>>>>=20
>>>>> o draft-ietf-manet-olsrv2-multitopology: Dearlove
>>>>=20
>>>> 
>>>>> Teco: Why not make this document standards track?
>>>>> CD: If people implement this and it's great.  Then I'm find  fine =
changing this to standards track if that's the case.
>>>>> TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.
>>>> I honestly do not think that Chris would make that typo, even when =
speaking ;)
>>>>> CD: If it gets stuck in the queue for 4 years we may have enough =
experience that we may want to push for standards track.
>>>>> Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
>>>>> CD: We will post something up on the list.
>>>>> TC: I think that experimental should have an explanation on what =
the experiment is and what the successful experiment is and what the =
conclusion is.
>>>>> Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
>>>>> Adrian Farrel: Yes, he does have that intention.
>>>> As it reads in the above, it sounds as if I'm making a demand, that =
Adrian is committing Chris to satisfy. That's not exactly how it went =
down, so perhaps we should clarify that in the minutes?
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> I'd like to go on record here, that I did not say that it "should =
have an explanation" to cater to my whim, but that I (as I actually =
stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it wa
>>>>=20
>=20


--Apple-Mail=_3784ACEA-3900-4A4C-B091-A50F9EF17D73
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Hi =
Abdussalam,

Slide 11 mentions that there is no =
*additional* overhead incurred by ODMRP_ASYM when there is no =
unidirectional link, not that there isn't any overhead with ODMRP. Slide =
18 does not show multiple paths, it shows the way ODMRP_ASYM finds a =
detour paths to forward the Join Reply.
As for page 4 of the =
ODMRP draft, can you point me to the line where it says ODMRP maintains =
multiple paths? Last time I read it there was no such =
statement...
As for the overhead related to mobility, ODMRP =
does not incur any extra overhead when mobility is higher, except if you =
shorten ROUTE_REFRESH_INTERVAL to refresh the multicast overlay more =
often to increase delivery =
rates.

Axel

Le 11 mars =
2014 =E0 01:03, Abdussalam Baryun <abdussalambaryun@gmail.com&=
gt; a =E9crit :

Slide 11 and 18. In the draft page 4 it mentions that =
ODMRP maintains multiple paths. Regarding overhead, do you mean =
there is no overhead in this routing and if there is with higher =
mobility how does it optimise it. 


AB

On Monday, March 10, 2014, Axel Colin de =
Verdi=E8re  wrote:

Hi Abdussalam, Thomas,

Thank you for your comments. =
Indeed there are no multiple paths involved. Can you point me to the =
slide you're referring to? What do you mean by "optimise =
overhead"?



Axel

Le 10 mars 2014 =E0 =
20:32, Thomas Heide Clausen <ietf@thomasclausen.org> a =E9crit :




Dear Abdussalam,


On 10 mars =
2014, at 17:48, Abdussalam Baryun =
<abdussalambaryun@gmail.com> =
wrote:

Hi =
Axel,


Thanks for your presentation. I had a question at meeting but =
there was no time. =46rom the presentation (still I did not done =
review), there was one slide showing two paths to =
its destination, so does this multicast protocol use multipath to =
reach all its demanded destinations? And how does it optimise =
overhead?




Having now reviewed the =
document in detail, let me venture a reply ;)

I =
believe that, no, multiple paths to the same destination are not sought =
nor used. Of course, to multiple destinations, multiple paths (but with =
common path segments, as possible) result.



I am interested, Abdussalam, have you read the =
document, and what are your detailed =
comments?

Thomas

AB

On Monday, March 10, 2014, Axel Colin de =
Verdi=E8re wrote:


Hi =
all,

We did not in fact request WG adoption for ODMRP =
and ODMRP_ASYM at this time, but we felt that the drafts were in good =
enough shape to ask for your comments and move in that direction.



Axel

Le 10 mars 2014 =E0 =
17:08, Abdussalam Baryun <abdussalambaryun@gmail.com> a =
=E9crit :

Hi Thomas,

Thanks for the update. =
I don't think the latest multicast draft was requested to =
be adopted in the meeting, but Ulrich did request his it for his =
draft, and I am waiting for announce on the list for DLEP =
plan and all adoption request in WG meeting. 



AB

On Monday, March 10, 2014, Thomas Clausen =
wrote:


Ulrich,

Thank you =
for prompt posting of minutes.
 
A couple of =
things that I would like to make more precise, all the same, in the =
minutes:


o draft-ietf-manet-olsrv2-multitopology: Dearlove

<SNIP>
Teco: Why not make =
this document standards track?
CD: If people implement this and it's great.  Then I'm find  fine changing this to standards track if that's =
the case.
TC: I do not think as a working group that we should go down the =
standards track document without many implementations as that has =
happened in other places within the IETF and document quality has =
suffered.


I honestly do not think that Chris would make that typo, even when =
speaking ;)
CD: If it gets stuck =
in the queue for 4 years we may have enough experience that we may want =
to push for standards track.
Rick Taylor: Is there any record of this for this draft being =
experimental and then changing to standards track later down the line?
CD: We will post something up on the list.
TC: I think that experimental should have an explanation on what the =
experiment is and what the successful experiment is and what the =
conclusion is.
Ulrich: Do you have intention to add a description of what those =
experiments are and what will make them successful?
Adrian Farrel: Yes, he does have that =
intention.
As it reads in the =
above, it sounds as if I'm making a demand, that Adrian is committing =
Chris to satisfy. That's not exactly how it went down, so perhaps we =
should clarify that in the minutes?





I'd like to go on record here, that I did not say that it "should =
have an explanation" to cater to my whim, but that I (as I actually =
stated at the mike) I was reciting what I had heard was an IESG =
statement/requirement (so: I thought it wa

=





=

--Apple-Mail=_3784ACEA-3900-4A4C-B091-A50F9EF17D73--


From nobody Tue Mar 11 05:31:26 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028511A041C for ; Tue, 11 Mar 2014 05:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Level: 
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWinjGUhkUQT for ; Tue, 11 Mar 2014 05:31:23 -0700 (PDT)
Received: from mail.tropicalstormsoftware.com (unknown [188.94.42.120]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED331A03F7 for ; Tue, 11 Mar 2014 05:31:22 -0700 (PDT)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 11 Mar 2014 12:30:49 +0000
From: Rick Taylor 
To: Christopher Dearlove , Joe Macker 
Thread-Topic: [manet] Basic initial comment for draft-gerla-manet-odmrp-02.txt
Thread-Index: AQHPPL2H3HjD0DxRi028c0o/nSIHzprbdiiAgABboS8=
Date: Tue, 11 Mar 2014 12:30:06 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F98FA6C8823@tss-server1.home.tropicalstormsoftware.com>
References: <20140305115333.7635.9928.idtracker@ietfa.amsl.com> <335AD6ED-F820-4C3B-9C11-F6593D4EEE43@axelcdv.com> , <18B34B51-7223-42B5-862D-E5B4150C26BD@gmail.com>
In-Reply-To: <18B34B51-7223-42B5-862D-E5B4150C26BD@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
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
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-_f-M8M9cM7mDs7HgOYgbc7Os5U
Cc: " List" , =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= , gerla , Soon Young Oh 
Subject: Re: [manet] Basic initial comment for draft-gerla-manet-odmrp-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Mar 2014 12:31:25 -0000

Surely you mean believe *in* British English  ;)=0A=
=0A=
________________________________________=0A=
From: manet [manet-bounces@ietf.org] on behalf of Christopher Dearlove [chr=
istopher.dearlove@gmail.com]=0A=
Sent: 11 March 2014 07:02=0A=
To: Joe Macker=0A=
Cc:  List; Axel Colin de Verdi=E8re; gerla; Soon Young Oh=
=0A=
Subject: Re: [manet] Basic initial comment for draft-gerla-manet-odmrp-02.t=
xt=0A=
=0A=
I believe on British English, the RFC Editor's rules can be summarised as:=
=0A=
- British English is permitted.=0A=
- But in practice no one does.=0A=
=0A=
So, yes, I have misspelled neighbour in all the drafts I have co-authored.=
=0A=
=0A=
But it's spelled correctly in my software ;)=0A=
=0A=
--=0A=
Christopher Dearlove=0A=
christopher.dearlove@gmail.com=0A=
=0A=
> On 11 Mar 2014, at 00:04, Joe Macker  wrote:=0A=
>=0A=
> Sorry I was working with pdf document here are my very basic exported com=
ments that might hep with a revision.=0A=
> More in the second set of comments. The general comments are just for gen=
eral discussio going forward.=0A=
> There are plenty more things but I did not do a comprehensive review yet.=
=0A=
>=0A=
> -------=0A=
> First off nice work!=0A=
>=0A=
> General Comments:=0A=
>=0A=
> (1) In a future revision, it would probably be good to discuss the design=
 issues associated with finding the right value of Route Query refresh floo=
ding intervals.  As you know, there have been plenty of published papers on=
 the subject relating to ODMRP.=0A=
>=0A=
> (2) Might want to discuss any relationship with any SSM from the IGMPv2, =
MLD perspective,etc.  Is there an intention to support SSM?The state is cer=
tainly source specific.=0A=
>=0A=
> (3) We could discuss more about how this could work with RFC 6130 concept=
s or where similar security considerations may lie.  This could be done dow=
n the road as we flesh things out more and consider acceptance as a  WG ite=
m.=0A=
>=0A=
>=0A=
> Summary of More Specific Minor Comments on draft-gerla-manet-odmrp-02.pdf=
=0A=
>=0A=
> Page: 4=0A=
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:05:03 PM=0A=
> of a "forwarding group"=0A=
> also avril -> april in reference=0A=
>=0A=
> Page: 7=0A=
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:11:34 PM=0A=
> disctinct -> distinct=0A=
>=0A=
> Page: 8=0A=
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:15:10 PM=0A=
> neighbour->neighbor=0A=
> I personally have no issue with British spellings in IETF docs.=0A=
> But since RFC 6130 and Crhis Dearlove go this way=0A=
>=0A=
> Page: 9=0A=
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:18:27 PM=0A=
> Security Considerations for sequencing=0A=
> Replay etc (see later in pg 22 comments)=0A=
> Page: 11=0A=
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:20:36 PM=0A=
> Fix sentence grammar:=0A=
> recommend remove "when"=0A=
> Page: 21=0A=
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:34:41 PM=0A=
> I think its great to have some potential convergence of capability here.=
=0A=
> The sentence duplication packets and message detection is malformed at le=
ast in the pdf version of the draft. Perhaps an xml,etc.=0A=
> Scoped flooding may be assisted by an SMF implementation as well.=0A=
> We have published and some unpublished improvements to these optimized fl=
ooding mechanisms (e.g., ECDS) that might provide more stability.=0A=
> both ipv4 and ipv6.=0A=
> Page: 22=0A=
> Author: macker Subject: Sticky Note Date: 3/10/14, 7:36:26 PM=0A=
> There are likely particular security vulnerabilities that can be discusse=
d regarding monotic sequences as used in control plane.. See SMF and other =
documents for similar issues such as replay,etc. Something for a future rev=
ision.=0A=
>=0A=
>=0A=
>> On Mar 5, 2014, at 7:00 AM, Axel Colin de Verdi=E8re  =
wrote:=0A=
>>=0A=
>> Hi all,=0A=
>>=0A=
>> We just pushed a new revision of ODMRP out, the -02 version presented at=
 the meeting. I got some comments during this week and plan to integrate th=
em into a -03 revision pretty soon. I'd be happy to discuss additional sugg=
estions or remarks that could be added to that revision.=0A=
>>=0A=
>> Thanks,=0A=
>>=0A=
>> Axel=0A=
>>=0A=
>>=0A=
>> D=E9but du message r=E9exp=E9di=E9 :=0A=
>>=0A=
>>> De: internet-drafts@ietf.org=0A=
>>> Objet: New Version Notification for draft-gerla-manet-odmrp-02.txt=0A=
>>> Date: 5 mars 2014 11:53:33 UTC=0A=
>>> =C0: "William Su" , "Yunjung Yi" , "Axel Coli Verdiere" , "Sung-=
Ju Lee" , Mario Gerla , "Professor Mario Gerla" , William Su , Axel Colin de Verdiere =0A=
>>>=0A=
>>>=0A=
>>> A new version of I-D, draft-gerla-manet-odmrp-02.txt=0A=
>>> has been successfully submitted by Axel Colin de Verdiere and posted to=
 the=0A=
>>> IETF repository.=0A=
>>>=0A=
>>> Name:        draft-gerla-manet-odmrp=0A=
>>> Revision:    02=0A=
>>> Title:        On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc N=
etworks=0A=
>>> Document date:    2014-03-05=0A=
>>> Group:        Individual Submission=0A=
>>> Pages:        30=0A=
>>> URL:            http://www.ietf.org/internet-drafts/draft-gerla-manet-o=
dmrp-02.txt=0A=
>>> Status:         https://datatracker.ietf.org/doc/draft-gerla-manet-odmr=
p/=0A=
>>> Htmlized:       http://tools.ietf.org/html/draft-gerla-manet-odmrp-02=
=0A=
>>> Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-od=
mrp-02=0A=
>>>=0A=
>>> Abstract:=0A=
>>>  The On-Demand Multicast Routing Protocol (ODMRP) is a multicast=0A=
>>>  routing protocol designed for ad hoc networks with mobile hosts.=0A=
>>>  ODMRP is a mesh-based, rather than a conventional tree-based,=0A=
>>>  multicast scheme and uses a forwarding group concept (only a subset=0A=
>>>  of nodes forwards the multicast packets via scoped flooding).  It=0A=
>>>  applies on-demand procedures to dynamically build routes and maintain=
=0A=
>>>  multicast group membership.  ODMRP is well suited for ad hoc wireless=
=0A=
>>>  networks with mobile hosts where bandwidth is limited, topology=0A=
>>>  changes frequently and rapidly, and power is constrained.=0A=
>>>=0A=
>>>=0A=
>>>=0A=
>>>=0A=
>>> Please note that it may take a couple of minutes from the time of submi=
ssion=0A=
>>> until the htmlized version and diff are available at tools.ietf.org.=0A=
>>>=0A=
>>> The IETF Secretariat=0A=
>>=0A=
>> _______________________________________________=0A=
>> manet mailing list=0A=
>> manet@ietf.org=0A=
>> https://www.ietf.org/mailman/listinfo/manet=0A=
>=0A=
> _______________________________________________=0A=
> manet mailing list=0A=
> manet@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/manet=0A=
=0A=
_______________________________________________=0A=
manet mailing list=0A=
manet@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/manet=0A=


From nobody Tue Mar 11 11:13:24 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64ED1A0773 for ; Tue, 11 Mar 2014 11:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgZ92_Epoj5E for ; Tue, 11 Mar 2014 11:13:20 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0369D1A076C for ; Tue, 11 Mar 2014 11:13:19 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id z60so25860002qgd.8 for ; Tue, 11 Mar 2014 11:13: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=fw5OSxa1NEKLlGysmF7Js1BC+FP7XSq312VC4a+It/c=; b=JVmZu0LGzEO7ZzWg+MpmNK5GnyujyCwsHvrDJgpGIEU3eDBG4/yUy37HNhlivvoERi wWfNeclM3xSfteJurl8l7te/j2BQpCj+hTiglMh0fyj2zg6pNG6blPJxiBvrnEdtZGmy XoBqLuADltoIGxcAXX82OZg1Uo6+wt6S2pO6tIl9n46a0fJ85q8GdGO8kwpDqFfpjrQO QqcgiFouOLiieaMdgZRaQI5tMla8NEXai00X651JdzMzIeD+FnKURqtiENvt1jkjTgPw jilQBHa2Qm+rJEPLlXzRIDRyvc6zfKXQ+IHH9xQ02W6PrnH/3IiuFPEfXdPuqCAMSEoq o/Xg==
MIME-Version: 1.0
X-Received: by 10.224.96.138 with SMTP id h10mr49931599qan.46.1394561594025; Tue, 11 Mar 2014 11:13:14 -0700 (PDT)
Received: by 10.140.36.103 with HTTP; Tue, 11 Mar 2014 11:13:13 -0700 (PDT)
In-Reply-To: <18B34B51-7223-42B5-862D-E5B4150C26BD@gmail.com>
References: <20140305115333.7635.9928.idtracker@ietfa.amsl.com> <335AD6ED-F820-4C3B-9C11-F6593D4EEE43@axelcdv.com>  <18B34B51-7223-42B5-862D-E5B4150C26BD@gmail.com>
Date: Tue, 11 Mar 2014 14:13:13 -0400
Message-ID: 
From: Joseph Macker 
To: Christopher Dearlove 
Content-Type: multipart/alternative; boundary=001a11c3f5066dfc5304f458accc
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/uQYimqhvw3x2tm7DZLbPEUdXmsY
Cc: " List" , =?ISO-8859-1?Q?Axel_Colin_de_Verdi=E8re?= , gerla , Soon Young Oh 
Subject: Re: [manet] Basic initial comment for draft-gerla-manet-odmrp-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Mar 2014 18:13:23 -0000

--001a11c3f5066dfc5304f458accc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I will not quote Oscar Wilde as that is obvious.

But all those zeds are the real menace.


On Tue, Mar 11, 2014 at 3:02 AM, Christopher Dearlove <
christopher.dearlove@gmail.com> wrote:

> I believe on British English, the RFC Editor's rules can be summarised as=
:
> - British English is permitted.
> - But in practice no one does.
>
> So, yes, I have misspelled neighbour in all the drafts I have co-authored=
.
>
> But it's spelled correctly in my software ;)
>
> --
> Christopher Dearlove
> christopher.dearlove@gmail.com
>
> > On 11 Mar 2014, at 00:04, Joe Macker  wrote:
> >
> > Sorry I was working with pdf document here are my very basic exported
> comments that might hep with a revision.
> > More in the second set of comments. The general comments are just for
> general discussio going forward.
> > There are plenty more things but I did not do a comprehensive review ye=
t.
> >
> > -------
> > First off nice work!
> >
> > General Comments:
> >
> > (1) In a future revision, it would probably be good to discuss the
> design issues associated with finding the right value of Route Query
> refresh flooding intervals.  As you know, there have been plenty of
> published papers on the subject relating to ODMRP.
> >
> > (2) Might want to discuss any relationship with any SSM from the IGMPv2=
,
> MLD perspective,etc.  Is there an intention to support SSM?The state is
> certainly source specific.
> >
> > (3) We could discuss more about how this could work with RFC 6130
> concepts or where similar security considerations may lie.  This could be
> done down the road as we flesh things out more and consider acceptance as=
 a
>  WG item.
> >
> >
> > Summary of More Specific Minor Comments on draft-gerla-manet-odmrp-02.p=
df
> >
> > Page: 4
> > Author: macker Subject: Sticky Note Date: 3/10/14, 7:05:03 PM
> > of a "forwarding group"
> > also avril -> april in reference
> >
> > Page: 7
> > Author: macker Subject: Sticky Note Date: 3/10/14, 7:11:34 PM
> > disctinct -> distinct
> >
> > Page: 8
> > Author: macker Subject: Sticky Note Date: 3/10/14, 7:15:10 PM
> > neighbour->neighbor
> > I personally have no issue with British spellings in IETF docs.
> > But since RFC 6130 and Crhis Dearlove go this way
> >
> > Page: 9
> > Author: macker Subject: Sticky Note Date: 3/10/14, 7:18:27 PM
> > Security Considerations for sequencing
> > Replay etc (see later in pg 22 comments)
> > Page: 11
> > Author: macker Subject: Sticky Note Date: 3/10/14, 7:20:36 PM
> > Fix sentence grammar:
> > recommend remove "when"
> > Page: 21
> > Author: macker Subject: Sticky Note Date: 3/10/14, 7:34:41 PM
> > I think its great to have some potential convergence of capability here=
.
> > The sentence duplication packets and message detection is malformed at
> least in the pdf version of the draft. Perhaps an xml,etc.
> > Scoped flooding may be assisted by an SMF implementation as well.
> > We have published and some unpublished improvements to these optimized
> flooding mechanisms (e.g., ECDS) that might provide more stability.
> > both ipv4 and ipv6.
> > Page: 22
> > Author: macker Subject: Sticky Note Date: 3/10/14, 7:36:26 PM
> > There are likely particular security vulnerabilities that can be
> discussed regarding monotic sequences as used in control plane.. See SMF
> and other documents for similar issues such as replay,etc. Something for =
a
> future revision.
> >
> >
> >> On Mar 5, 2014, at 7:00 AM, Axel Colin de Verdi=E8re 
> wrote:
> >>
> >> Hi all,
> >>
> >> We just pushed a new revision of ODMRP out, the -02 version presented
> at the meeting. I got some comments during this week and plan to integrat=
e
> them into a -03 revision pretty soon. I'd be happy to discuss additional
> suggestions or remarks that could be added to that revision.
> >>
> >> Thanks,
> >>
> >> Axel
> >>
> >>
> >> D=E9but du message r=E9exp=E9di=E9 :
> >>
> >>> De: internet-drafts@ietf.org
> >>> Objet: New Version Notification for draft-gerla-manet-odmrp-02.txt
> >>> Date: 5 mars 2014 11:53:33 UTC
> >>> =C0: "William Su" , "Yunjung Yi" <
> unknown-email-Yunjung-Yi@ietfa.amsl.com>, "Axel Coli Verdiere" <
> axel@axelcdv.com>, "Sung-Ju Lee" ,
> Mario Gerla , "Professor Mario Gerla" <
> gerla@cs.ucla.edu>, William Su , Axel Colin de
> Verdiere 
> >>>
> >>>
> >>> A new version of I-D, draft-gerla-manet-odmrp-02.txt
> >>> has been successfully submitted by Axel Colin de Verdiere and posted
> to the
> >>> IETF repository.
> >>>
> >>> Name:        draft-gerla-manet-odmrp
> >>> Revision:    02
> >>> Title:        On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc
> Networks
> >>> Document date:    2014-03-05
> >>> Group:        Individual Submission
> >>> Pages:        30
> >>> URL:
> http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-02.txt
> >>> Status:
> https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/
> >>> Htmlized:       http://tools.ietf.org/html/draft-gerla-manet-odmrp-02
> >>> Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-02
> >>>
> >>> Abstract:
> >>>  The On-Demand Multicast Routing Protocol (ODMRP) is a multicast
> >>>  routing protocol designed for ad hoc networks with mobile hosts.
> >>>  ODMRP is a mesh-based, rather than a conventional tree-based,
> >>>  multicast scheme and uses a forwarding group concept (only a subset
> >>>  of nodes forwards the multicast packets via scoped flooding).  It
> >>>  applies on-demand procedures to dynamically build routes and maintai=
n
> >>>  multicast group membership.  ODMRP is well suited for ad hoc wireles=
s
> >>>  networks with mobile hosts where bandwidth is limited, topology
> >>>  changes frequently and rapidly, and power is constrained.
> >>>
> >>>
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time of
> submission
> >>> until the htmlized version and diff are available at tools.ietf.org.
> >>>
> >>> The IETF Secretariat
> >>
> >> _______________________________________________
> >> 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
>

--001a11c3f5066dfc5304f458accc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I will not quote Oscar Wilde as that is obvious.
<=
br>
But all those zeds are the real menace.


On Tue, Mar 11, 2014 at 3:02 A=
M, Christopher Dearlove <christopher.dearlove@gmail.com&g=
t; wrote:


I believe on British English, the RFC Editor=
's rules can be summarised as:

- British English is permitted.

- But in practice no one does.



So, yes, I have misspelled neighbour in all the drafts I have co-authored.<=
br>


But it's spelled correctly in my software ;)



--

Christopher Dearlove

christopher.dearlove@gmai=
l.com




> On 11 Mar 2014, at 00:04, Joe Macker <jpmacker@gmail.com> wrote:

>

> Sorry I was working with pdf document here are my very basic exported =
comments that might hep with a revision.

> More in the second set of comments. The general comments are just for =
general discussio going forward.

> There are plenty more things but I did not do a comprehensive review y=
et.

>

> -------

> First off nice work!

>

> General Comments:

>

> (1) In a future revision, it would probably be good to discuss the des=
ign issues associated with finding the right value of Route Query refresh f=
looding intervals. =A0As you know, there have been plenty of published pape=
rs on the subject relating to ODMRP.


>

> (2) Might want to discuss any relationship with any SSM from the IGMPv=
2, MLD perspective,etc. =A0Is there an intention to support SSM?The state i=
s certainly source specific.

>

> (3) We could discuss more about how this could work with RFC 6130 conc=
epts or where similar security considerations may lie. =A0This could be don=
e down the road as we flesh things out more and consider acceptance as a =
=A0WG item.


>

>

> Summary of More Specific Minor Comments on draft-gerla-manet-odmrp-02.=
pdf

>

> Page: 4

> Author: macker Subject: Sticky Note Date: 3/10/14, 7:05:03 PM

> of a "forwarding group"

> also avril -> april in reference

>

> Page: 7

> Author: macker Subject: Sticky Note Date: 3/10/14, 7:11:34 PM

> disctinct -> distinct

>

> Page: 8

> Author: macker Subject: Sticky Note Date: 3/10/14, 7:15:10 PM

> neighbour->neighbor

> I personally have no issue with British spellings in IETF docs.

> But since RFC 6130 and Crhis Dearlove go this way

>

> Page: 9

> Author: macker Subject: Sticky Note Date: 3/10/14, 7:18:27 PM

> Security Considerations for sequencing

> Replay etc (see later in pg 22 comments)

> Page: 11

> Author: macker Subject: Sticky Note Date: 3/10/14, 7:20:36 PM

> Fix sentence grammar:

> recommend remove "when"

> Page: 21

> Author: macker Subject: Sticky Note Date: 3/10/14, 7:34:41 PM

> I think its great to have some potential convergence of capability her=
e.

> The sentence duplication packets and message detection is malformed at=
 least in the pdf version of the draft. Perhaps an xml,etc.

> Scoped flooding may be assisted by an SMF implementation as well.

> We have published and some unpublished improvements to these optimized=
 flooding mechanisms (e.g., ECDS) that might provide more stability.

> both ipv4 and ipv6.

> Page: 22

> Author: macker Subject: Sticky Note Date: 3/10/14, 7:36:26 PM

> There are likely particular security vulnerabilities that can be discu=
ssed regarding monotic sequences as used in control plane.. See SMF and oth=
er documents for similar issues such as replay,etc. Something for a future =
revision.


>

>

>> On Mar 5, 2014, at 7:00 AM, Axel Colin de Verdi=E8re <axel@axelcdv.com> wrote:

>>

>> Hi all,

>>

>> We just pushed a new revision of ODMRP out, the -02 version presen=
ted at the meeting. I got some comments during this week and plan to integr=
ate them into a -03 revision pretty soon. I'd be happy to discuss addit=
ional suggestions or remarks that could be added to that revision.


>>

>> Thanks,

>>

>> Axel

>>

>>

>> D=E9but du message r=E9exp=E9di=E9 :

>>

>>> De: internet-draft=
s@ietf.org

>>> Objet: New Version Notification for draft-gerla-manet-odmrp-02=
.txt

>>> Date: 5 mars 2014 11:53:33 UTC

>>> =C0: "William Su" <william.su@boeing.com>, "Yunjung Yi" <unknown-email-Yunjung-=
Yi@ietfa.amsl.com>, "Axel Coli Verdiere" <axel@axelcdv.com>, "Sung-Ju Lee" &l=
t;unknown-email=
-Sung-Ju-Lee@ietfa.amsl.com>, Mario Gerla <gerla@cs.ucla.edu>, "Professor Mario Gerla"=
 <gerla@cs.ucla.edu>, Willia=
m Su <william.su@boeing.com=
>, Axel Colin de Verdiere <axel@a=
xelcdv.com>


>>>

>>>

>>> A new version of I-D, draft-gerla-manet-odmrp-02.txt

>>> has been successfully submitted by Axel Colin de Verdiere and =
posted to the

>>> IETF repository.

>>>

>>> Name: =A0 =A0 =A0 =A0draft-gerla-manet-odmrp

>>> Revision: =A0 =A002

>>> Title: =A0 =A0 =A0 =A0On-Demand Multicast Routing Protocol (OD=
MRP) for Ad Hoc Networks

>>> Document date: =A0 =A02014-03-05

>>> Group: =A0 =A0 =A0 =A0Individual Submission

>>> Pages: =A0 =A0 =A0 =A030

>>> URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.i=
etf.org/internet-drafts/draft-gerla-manet-odmrp-02.txt

>>> Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.=
org/doc/draft-gerla-manet-odmrp/

>>> Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draf=
t-gerla-manet-odmrp-02

>>> Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org=
/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-02

>>>

>>> Abstract:

>>> =A0The On-Demand Multicast Routing Protocol (ODMRP) is a multi=
cast

>>> =A0routing protocol designed for ad hoc networks with mobile h=
osts.

>>> =A0ODMRP is a mesh-based, rather than a conventional tree-base=
d,

>>> =A0multicast scheme and uses a forwarding group concept (only =
a subset

>>> =A0of nodes forwards the multicast packets via scoped flooding=
). =A0It

>>> =A0applies on-demand procedures to dynamically build routes an=
d maintain

>>> =A0multicast group membership. =A0ODMRP is well suited for ad =
hoc wireless

>>> =A0networks with mobile hosts where bandwidth is limited, topo=
logy

>>> =A0changes frequently and rapidly, and power is constrained.
>>>

>>>

>>>

>>>

>>> Please note that it may take a couple of minutes from the time=
 of submission

>>> until the htmlized version and diff are available at tools.ietf.org.

>>>

>>> The IETF Secretariat

>>

>> _______________________________________________

>> 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





--001a11c3f5066dfc5304f458accc--


From nobody Tue Mar 11 15:58:04 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024351A081E for ; Tue, 11 Mar 2014 15:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mzsh7GYuaof8 for ; Tue, 11 Mar 2014 15:57:55 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA991A0893 for ; Tue, 11 Mar 2014 15:57:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DCA8F240120; Tue, 11 Mar 2014 15:57:49 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.142] (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 maila2.tigertech.net (Postfix) with ESMTPSA id 3498B2400E0; Tue, 11 Mar 2014 15:57:48 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-F3715D03-3F9C-4180-9527-B6C09C241B5B
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (11D167)
In-Reply-To: <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com>
Date: Tue, 11 Mar 2014 23:57:45 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org> <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com>
To: =?utf-8?Q?Axel_Colin_de_Verdi=C3=A8re?= 
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/B9OnGk5wJYsDPtdin1g8r66IfMo
Cc: MANET IETF 
Subject: Re: [manet] draft-gerla-manetodmrp-02 review
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Mar 2014 22:58:02 -0000

--Apple-Mail-F3715D03-3F9C-4180-9527-B6C09C241B5B
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Dear Axel,

Below.

> On 11 mars 2014, at 09:37, Axel Colin de Verdi=C3=A8re  wrote:
>=20
> Hi Thomas,
>=20
> Thanks again for your review. See inline for the replies point-by-point. A=
 couple points I'd like to copy here:
>=20
> - Your comments confirm there's a real need to clarify the way this would w=
ork with multiple interfaces: describe the router/interface/address relation=
ship, explain which information set is per interface and which is per router=
 (presumably few to none), and clarify which address comes from which interf=
ace of which node (host or router).

OK, that sounds good. Let me know if you need comments on an (intermediary o=
r final) text.


> - You suggest moving appendix A to a section or subsection of section 7. A=
 counter-proposal would be to describe only the message contents in section 7=
 (with the required and optional fields), and have Appendix A be only an "ex=
ample encoding using RFC5444" section, that would contain no normative text.=
 Would that be acceptable?

I believe that, at some point in the past, we were told to not put normative=
 bits into appendices - and the encoding into 5444-format *is* normative for=
 interoperability, I would think, so I am not really sure how what you propo=
se would actually work - but, perhaps I do not understand it fully? ;)

> - I think this could be implemented in user-space, but I'm afraid that hav=
ing to intercept the first data packet in order to build the multicast tree w=
ould require a kernel module. I'd appreciate it if someone more knowledgeabl=
e than me could infer or refute that.

OK.

> - There's a need to clarify some of the vocabulary, such as the Multicast O=
verlay/Forwarding group relationship. Regarding that, I wonder if it wouldn'=
t add more clarity to just drop the "Multicast Overlay" term, and only refer=
 to the Forwarding Group. Thoughts?

Well, I was thinking that there were quite a bit of terms that might appear n=
ot redundant, but perhaps extraneous ;) so looking at simplifying that sound=
s good.

Further below...snipping out the things that we seem to be in agreement on..=
.

>=20
> Best,
>=20
> Axel
>=20
>> Le 10 mars 2014 =C3=A0 23:13, Thomas Heide Clausen  a =C3=A9crit :
>>=20
>>=20
>>=20
>>> On 10 mars 2014, at 23:01, Axel Colin de Verdi=C3=A8re  wrote:



>>>> General Comments:
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> I think I understand the general idea, though, of the way the specifica=
tion is made: you describe, in abstract form, the protocol, signals, etc., a=
nd then you provide the mapping to RFC5444-elements in an appendix.
>>>>=20
>>>> That is not entirely stupid as idea, and the resulting document is actu=
ally nice and readable, but.....appendices can't (or, shouldn't) contain nor=
mative text. Indeed, there are many MUST/SHOULD/* in Appendix A.=20
>>>>=20
>>>> I suggest promoting Appendix A to a "numbered section" somewhere (perha=
ps after section 7?)=20
>=20
> I have another suggestion, coming from some comments from Justin during IE=
TF-week: section 7 could be written so as to contain only the fields carried=
 by the protocol messages, stating which are required and which are optional=
 (so as to get the MUST and other SHOULDs out of Appendix A), and suggest on=
e possible encoding of these messages with RFC5444 in the appendix, since an=
y correct encoding should be parsed into the right fields. That way the appe=
ndix would not contain any normative text, and anyone would be free to use h=
is or her RFC5444 parser/encoder even if it encodes the fields differently. W=
ould that work?

Ah...

This has nothing to do with one persons encoder/decoder over anothers. The s=
pecification must, unequivocally, be such that it is possible to create inte=
roperable implementations, regardless of parser/encoder; that's the whole po=
int of RFC5444 ;)

For example, if you decide to put an address in the "originator field", and I=
 decide to not do that, but stick it in an address block with an "originator=
 TLV" associated, then our implementations just won't interoperate...so the s=
pecification definitely has to be specifying normatively so as to avoid such=
 situations.



>>>>=20
>>>> As was discussed during the MANET wg meeting in London, an EXPERIMENTAL=
 document is supposed to enable an experiment, and that experiment should be=
 documented. See e.g. RFC6971, section 1.2. I'll try to add a couple of my t=
houghts on what would make for good "experiments":
>=20
>>>>=20
>>>> I do believe that, perhaps, a distinguishing point of ODMRP vs. SMF and=
 other such protocols: whereas these rely on "get a copy of the message to e=
ach router, then have the router decide if it delivers those to applications=
", ODMRP works by only getting copies of messages to routers that actually n=
eed it. So, an experiment establishing the boundaries where "efforts to cons=
tructing the overlay" are out-weighted by the benefits of not having to deli=
ver a copy of the multicast message to each router.
>=20
> Yes, I think that would be interesting. It might also be worth it to see i=
f there's a way to adapt to network traffic and switch between the two modes=
. Another idea would be to try to figure out the possible scopes of deployme=
nts of ODMRP, i.e., if ODMRP can be used anywhere where OLSRv2 is deployed.

Sounds like this is actually also a good idea.

Something else that I was thinking about just now was the whole notion of th=
e overlays being constructed with or without metrics...is there a clever (i.=
e., simple) way to use link metrics when constructing the multicast overlays=
? If such metrics already are available e.g. for an unicast routing protocol=
 already present in the network?

>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> Now that I have thought this bit over....
>>>>=20
>>>> In the end, a tree is constructed, though, is it not? Join Queries floo=
ded, then Join Replies sent back, in a "Tree-construction" fashion?
>>>>=20
>=20
> Yes, basically it wounds up being a tree. I should probably revise the abs=
tract and applicability statement that way.

Actually, I was thinking more in the introduction or in the overview and fun=
ctioning - not as much in applicability statement.

Given that you are French, let me try with a food-analogy (had you been Amer=
ican, I'd have gone with a car analogy) ;)=20

To me, an applicability statement is something like:

	"This protocol is applicable when making puddings. It works for rou=
nd and square moulds,
	  but has been found to be inapplicable in hexagonal moulds.  For o=
ther shapes of moulds,
	  we do not know if this protocol is applicable for pudding-making"=


The "Overview and Functioning" is where you write if you use a fork or a whi=
sk for mixing the ingredients.



>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> I would suggest answering the question, which is on everybody's lips, a=
lready here: does this integrate with "regular IP Multicasting" or does it r=
equire "application level tunneling"?=20
>>>>=20
>>>> In other words, could I expect an mcast-capable application to "just wo=
rk", and can I implement this "on a commodity OS", or will I have to do kern=
el-level hacks?
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> I would suggest answering the question, which is on everybody's lips, a=
lready here: does this integrate with "regular IP Multicasting" or does it r=
equire "application level tunneling"?=20
>>>>=20
>>>> In other words, could I expect an mcast-capable application to "just wo=
rk", and can I implement this "on a commodity OS", or will I have to do kern=
el-level hacks to make it work?
>>>>=20
>>>> Having read through the document, I think that I infer that it's possib=
le to build an user-space implementation manipulating working by simply mult=
icast routing table entries.
>>>>=20
>>>> Would be good to have it confirmed that my understanding is correct - i=
f it is, that is ;)
>=20
> I think there are two things here. First, since it uses regular IGMP/MLD s=
ignaling, there is probably nothing to change on the "host" part of the prot=
ocol, and an application should work without any changes.

That's excellent.

> However, although it seems possible to have an user-space implementation t=
hat just writes to the multicast routing table, I think there might be an is=
sue with the original tree creation: I'm not sure it's possible to intercept=
 the first data packet(s) to trigger the Join Query process without being in=
 the kernel. But I'm not an expert with this, so somebody might correct me. I=
n the meantime I'll dig a little deeper, see if I can figure something out.

That might also be something that could be established as part of the experi=
ment, also, perhaps?

>>>> --- Page 5 ---
>>>>=20
>>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>>> addresses
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> I am going to pick out this here, but it applies elsewhere also: "addre=
sses"?=20
>>>>=20
>>>> I believe that you aim at "address length independence", v6/v4/short, a=
nd that's a good idea which is, I believe, supported well by RFC5444. Alas, I=
 believe that you probably want to stick in a definition and explanation of t=
hat in here.=20
>>>>=20
>>>> Also, I gather that these addresses are "interface identifiers" and not=
 "multicast group addresses", yes? Given that this document talks about mult=
icast, I do recommend perhaps calling this out?
>=20
> Ok, will do. I think this will go in the whole "clarifying the router-inte=
rface-address relationship" part that goes with handling multiple interfaces=
.

That sounds about right, yeah.



>>>> The ODMRP router hearing these,  maps that to a "Multicast Session".
>=20
> Not exactly, since a Multicast Session is Multicast Group Address + Multic=
ast Source Address, hence a router which has an attached host that has joine=
d a Multicast Group Address might have several corresponding Multicast Sessi=
ons.
>=20

OK, so the fact that I felt the urge to ask this question might indicate tha=
t it could do with a clarification (or, perhaps, that I'm a few cards short o=
f a full deck? ;) )



>>>> Also, as I understand it, "Forwarding Group" and "Multicast Overlay" ar=
e, respectively, "links" and "routers" for a given Multicast Session?
>=20
> I would say the opposite actually, the Forwarding Group is the set of rout=
ers that form the Multicast Overlay built by the JQ + JR process, and forwar=
d the Multicast data packets for the corresponding multicast session.

Ok, same reply as the one above.

>>>> I think that thats what it is, but the relationship between these terms=
/concepts  could merit being rendered crystal clear here.
>=20
> Agreed. I wonder if it would not be clearer to drop the term "Multicast Ov=
erlay" altogether, and only refer to the Forwarding Group, since this is the=
 most concrete construct used by ODMRP, and only call out in the intro and a=
pplicability statement that the Forwarding Group forms a source-rooted tree.=
 Would that make more sense?
>=20

I'd probably want to see the resulting text before saying yes or no, definit=
ively, but it sounds like it's a very very sensible plan.



>>>> --- Page 9 ---
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> This probably needs a bit more of explanation. As I indicated in the ge=
neral comments, the separation of abstract message content, and 5444-encodin=
g is a possible way to go, but it is not clear at this point that that's wha=
t's being done.
>>>>=20
>>>> As a consequence, it is not clear why the section title is "Packets and=
 Messages" - those are (in MANET) 5444-constructs, typically.
>>>>=20
>>>> One possibility could be to stick Appendix A after section 7. Another, t=
o have appendix A be a subsection to section 7.
>=20
> Agreed, this is not clear enough. See my previous reply for a counter-prop=
osal though (i.e., clarify the separation and keep Appendix A as an "example=
 encoding"). Otherwise promoting appendix A to a section or subsection of se=
c 7 would work too I guess.

OK, I think that this needs some thought; I've made my comments in the above=
 to this point.

>>>> --- Page 11 ---
>>>>=20
>>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>>> Multicast Source
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> Somewhat of the same comment as one I have made before: "the address of=
 the Multicast Source"
>>>>=20
>>>> First, is the "Multicast Source" the router, through which the multicas=
t data messages ingress through, or is it the host on which the application g=
enerating data, is? Does it make any difference? "Multicast Source" is not d=
efined.
>=20
> I think that provided that the host-to-router relationship is 1-1 and well=
 defined, having the Multicast Source be the actual host sending the data wo=
uld work. But it's true that there's a need to be explicit there.

Oh, I hope that you mean that the host-to-router relationship is m-1, in tha=
t "one router can serve many hosts", yes?

Incidentally, in case that the m-1 applies, that probably deserves to be cal=
led out in the applicability statement (i.e., no multihoming permitted?). Ev=
en better if you could state what the consequences of multihoming would be (=
would it work, but be inefficient, or would it break the Internet?)



>>>>=20
>>>> --- Page 16 ---
>>>>=20
>>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>>> an address
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> Which address? Any? Always the same? Does it matter?
>>>>=20
>>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>>> neighbors
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> I assume that what you want is to forward to all the neighbors on all O=
DMRP interfaces of this router, yes?
>=20
> Yes, although I should probably call out more explicitly that the JQ shoul=
d be passed to the forwarding mechanism in place in the network (so that if S=
MF with ECDS - or OLSRv2's MPR - is in place it can be used for example).
>=20

That sounds like a good idea, yeah.

>>>> --- Page 19 ---
>>>>=20
>>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>>> neighbors
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> Over all ODMRP Interfaces?
>>>>=20
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> Here, we are gleaning a bit more precisely what the R_source is; so its=
 an interface of an ODMRP router over which the Join Reply was sent, yes?
>=20
> Actually I think I should refactor the document to map this to the multica=
st source. This should help in mapping various information base tuples to th=
e multicast session, and avoid issues such as choosing which address to put i=
n a newly-generated join query.

That sounds sensible.



>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> Suggest: "...run in conjunction with, and benefit from some of the feat=
ures of, SMF..."
>>>>=20
>>>> Strikeout (red), 10 mars 2014 19:24, TClausen:
>>>> and                benefit from some of its features.
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> I would be hesitant to call this section "SMF Considerations"
>>>>=20
>>>> While SMF is an important and useful protocol set, I would suggest that=
 this section be generalized: what's at stake is, and I think that I saw tha=
t in the slides that were presented in the London IETF, that if there's a "m=
ore efficient than classic flooding" network-wider broadcast operation in pl=
ace, then ODMRP would/should use it - correct?
>>>>=20
>>>> This might be by way of SMF, or it could be as an extension to OLSRv2's=
 MPR flooding, or it could be (as is seen in for example HNCP) something bas=
ed off of Trickle - or something entirely different.
>>>>=20
>>>> So, perhaps "Flooding considerations" as section title, and a bit gener=
alized text would work?
>=20
> Funny enough, this was the original title - I'll put that back in then, an=
d generalize to other possible flooding mechanisms.

Hah, first impulses sometimes are the right ones ;)

>>>>=20
>>>>=20
>>>> --- Page 22 ---
>>>>=20
>>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:
>>>> Packets
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> Packets -> Packet
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> OK, I think that this document should start by actually requesting the a=
llocations for the two message types. Cf. how it is done in section 18.2 of R=
FC6130
>>>>=20
>>>> Then, I *think* that the current 15.1 is the Message-Type-Specific TLV T=
ype Registries" that are being set up, for Join-Query yes? I see "Expert Rev=
iew" mentioned, but no guidelines/recommendations for the Expert to follow. D=
o you intend to mirror those from RFC5444, or are there special concerns to t=
ake into consideration?
>>>>=20
>>>> I would actually suggest mirroring the structure of the IANA section fr=
om RFC6130  if for no other reasons, than that it's allocating from RFC5444-=
registries, and has been going through the process and so it may be assumed t=
hat something mirroring it will, too. ;)
>=20
> Alright, will look at that and do so then.

Note, this is not something I'm dogmatic about, but the approval process of T=
LV-Extensions has taught me that IANA appreciates getting very very clear in=
structions (can't blame them ;) ), and that providing such makes things so m=
uch easier for authors, ADs and IANA.

>>>> --- Page 25 ---
>>>>=20
>>>> Note (yellow), 10 mars 2014 19:24, TClausen:
>>>> Just a comment, a cursory review of the mapping to RFC5444 doesn't have=
 anything jump at me screaming "problems", which is good.
>>>>=20
>>>> I was wondering one thing, though: if running OLSRv2 + ODMRP, then ther=
e's an obvious option which could be considered (and could be considered, in=
 order to be disregarded)....
>>>>=20
>>>> Could one imagine carrying ODMRP signals inside TC messages in any mean=
ingful way, as TLVs and additional addresses included? *technically* it shou=
ld be possible, does it make sense?
>=20
> Technically that should work, I guess the advantage would be to have less d=
uplicate information flooded throughout the network, and overall less packet=
s sent, but I'm not sure it would be easy to encode that in any way that wou=
ld 1) prevent too much duplicate information and 2) be easy to parse (both f=
or the specs reader and the implementation). So I'm worried this would not r=
eally be worth it.

That's fair enough, this was just something I thought about in an idle momen=
t.=20

>>>> A second thing, is there any reason to request both JR and JQ message t=
ype, or is there a way of using just a single code-point, and are there pote=
ntial benefits in doing so?
>>>>=20
>>>> A different way of phrasing the above is: given that code-points by def=
inition are limited, I'd like to ask for a bit more of "justification" befor=
e they are allocated.
>=20
> Well first off, in a more "abstract" sense I think it's clearer to keep th=
e JQ vs JR distinction throughout the document. However it could be envision=
ed to have only a ODMRP-message type with a "flags" TLV that would have one f=
lag determining whether the message is actually treated as a JQ or a JR. Aft=
er all, the two messages are pretty similar in content. For now the only dra=
wback I see is that it would slightly increase the message size. But I guess=
 the same reasoning could be done with a lot of protocols, no?

OK, fair enough.=20

As codepoints (almost always) are at a premium, thinking through these thing=
s is just something that I encourage to be done very, very carefully. When w=
e designed OLSRv2, for example, one of the things we did vs. OLSRv1 was to r=
emove 3 message types, and "consume" only one (TC) out of the 5444 message t=
ype space.

I've not really made up my mind either way, but I'd encourage that we keep t=
hinking about this?

Sounds, overall, like the coming revision will be reflecting the bulk of the=
 issues that I've brought up, and that we've got a few marked as "to think a=
 bit further about". Overall, that's fabulous!

Thank you for your reply, and I look much forward to reviewing an upcoming i=
teration of this document.

Best,

Thomas=

--Apple-Mail-F3715D03-3F9C-4180-9527-B6C09C241B5B
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Dear Axel,

Be=
low.

On 11 mars 2014, at 09:37, Axel Colin de Verdi=C3=A8r=
e <axel-ietf@axelcdv.com>=
 wrote:

Hi Thomas,

Thanks again for your review. See inline for the replies p=
oint-by-point. A couple points I'd like to copy here:

- Your comments confirm there's a real need to clarify the way this would=
 work with multiple interfaces: describe the router/interface/address relati=
onship, explain which information set is per interface and which is per rout=
er (presumably few to none), and clarify which address comes from which inte=
rface of which node (host or router).

OK, that sounds good. Let me know if you need comments on an (intermediary o=
r final) text.


- Y=
ou suggest moving appendix A to a section or subsection of section 7. A coun=
ter-proposal would be to describe only the message contents in section 7 (wi=
th the required and optional fields), and have Appendix A be only an "exampl=
e encoding using RFC5444" section, that would contain no normative text. Wou=
ld that be acceptable?

I believe=
 that, at some point in the past, we were told to not put normative bits int=
o appendices - and the encoding into 5444-format *is* normative for interope=
rability, I would think, so I am not really sure how what you propose would a=
ctually work - but, perhaps I do not understand it fully? ;)

<=
/div>
- I think this could be implemented in u=
ser-space, but I'm afraid that having to intercept the first data packet in o=
rder to build the multicast tree would require a kernel module. I'd apprecia=
te it if someone more knowledgeable than me could infer or refute that.

OK.

- There's a need to clarify some of the vocabulary, such as the Multicast O=
verlay/Forwarding group relationship. Regarding that, I wonder if it wouldn'=
t add more clarity to just drop the "Multicast Overlay" term, and only refer=
 to the Forwarding Group. Thoughts?

Well, I=
 was thinking that there were quite a bit of terms that might appear not red=
undant, but perhaps extraneous ;) so looking at simplifying that sounds good=
.

Further below...snipping out the things that we s=
eem to be in agreement on...

Best,

Axel

Le 10 mars 2014 =C3=A0 23:13, Thomas Heide Clausen <thomas@thomasclausen.org> a =C3=A9crit=
 :


On 10 mars 2014, at 23:01, Axel Colin de Verdi=C3=
=A8re <axel-ietf@axelcdv.com=
> wrote:
<SNIP>

=

General Comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
I think I understand the general idea, though, of the way the specification i=
s made: you describe, in abstract form, the protocol, signals, etc., and the=
n you provide the mapping to RFC5444-elements in an appendix.

That is=
 not entirely stupid as idea, and the resulting document is actually nice an=
d readable, but.....appendices can't (or, shouldn't) contain normative text.=
 Indeed, there are many MUST/SHOULD/* in Appendix A. 

I suggest promoting Appendix A to a "numb=
ered section" somewhere (perhaps after section 7?) 

I have another suggestion, coming from some comments from J=
ustin during IETF-week: section 7 could be written so as to contain only the=
 fields carried by the protocol messages, stating which are required and whi=
ch are optional (so as to get the MUST and other SHOULDs out of Appendix A),=
 and suggest one possible encoding of these messages with RFC5444 in the app=
endix, since any correct encoding should be parsed into the right fields. Th=
at way the appendix would not contain any normative text, and anyone would b=
e free to use his or her RFC5444 parser/encoder even if it encodes the field=
s differently. Would that work?

Ah...

This has nothing to do with one p=
ersons encoder/decoder over anothers. The specification must, unequivocally,=
 be such that it is possible to create interoperable implementations, regard=
less of parser/encoder; that's the whole point of RFC5444 ;)

<=
/div>
For example, if you decide to put an address in the "originator fi=
eld", and I decide to not do that, but stick it in an address block with an "=
originator TLV" associated, then our implementations just won't interoperate=
...so the specification definitely has to be specifying normatively so as to=
 avoid such situations.

<SNIP>

=


As was discussed during the MANET wg me=
eting in London, an EXPERIMENTAL document is supposed to enable an experimen=
t, and that experiment should be documented. See e.g. RFC6971, section 1.2. I=
'll try to add a couple of my thoughts on what would make for good "experime=
nts":

I do believe th=
at, perhaps, a distinguishing point of ODMRP vs. SMF and other such protocol=
s: whereas these rely on "get a copy of the message to each router, then hav=
e the router decide if it delivers those to applications", ODMRP works by on=
ly getting copies of messages to routers that actually need it. So, an exper=
iment establishing the boundaries where "efforts to constructing the overlay=
" are out-weighted by the benefits of not having to deliver a copy of the mu=
lticast message to each router.

Yes, I think that would be interesting. It might als=
o be worth it to see if there's a way to adapt to network traffic and switch=
 between the two modes. Another idea would be to try to figure out the possi=
ble scopes of deployments of ODMRP, i.e., if ODMRP can be used anywhere wher=
e OLSRv2 is deployed.

Sounds li=
ke this is actually also a good idea.

Something els=
e that I was thinking about just now was the whole notion of the overlays be=
ing constructed with or without metrics...is there a clever (i.e., simple) w=
ay to use link metrics when constructing the multicast overlays? If such met=
rics already are available e.g. for an unicast routing protocol already pres=
ent in the network?

=

Note (yellow), 10 mars 2014 19:24, TClausen:
Now that I have thought t=
his bit over....

In the end, a tree is constructed, though, is it not=
? Join Queries flooded, then Join Replies sent back, in a "Tree-construction=
" fashion?


Yes, basi=
cally it wounds up being a tree. I should probably revise the abstract and a=
pplicability statement that way.
Actually, I was thinking more in the introduction or in the overview a=
nd functioning - not as much in applicability statement.

Given that you are French, let me try with a food-analogy (had you bee=
n American, I'd have gone with a car analogy) ;) 

<=
div>To me, an applicability statement is something like:

	"Thi=
s protocol is applicable when making puddings. It works for round and square=
 moulds,
=
	  but has been found to be inapplicable in hexagonal mo=
ulds.  For other shapes of moulds,
	  we do not know if this protoc=
ol is applicable for pudding-making"

The "Overview a=
nd Functioning" is where you write if you use a fork or a whisk for mixing t=
he ingredients.

<SNIP>

Note (yellow), 10 mars 2014 19:24, TClausen=
:
I would suggest answering the question, which is on everybody's lips, a=
lready here: does this integrate with "regular IP Multicasting" or does it r=
equire "application level tunneling"?&=
nbsp;

In other words, could I expect an mcast-capable applicat=
ion to "just work", and can I implement this "on a commodity OS", or will I h=
ave to do kernel-level hacks?

Note (yellow), 10 mars 2014 19:24, TCla=
usen:
I would suggest answering the question, which is on everybody's lip=
s, already here: does this integrate with "regular IP Multicasting" or does i=
t require "application level tunneling"? 

In other words, could I expect an mcast-capable appli=
cation to "just work", and can I implement this "on a commodity OS", or will=
 I have to do kernel-level hacks to make it work?

Having read through=
 the document, I think that I infer that it's possible to build an user-spac=
e implementation manipulating working by simply multicast routing table entr=
ies.

Would be good to have it confirmed that my understanding is corr=
ect - if it is, that is ;)
<=
div>
I think there are two things here. First, since it uses r=
egular IGMP/MLD signaling, there is probably nothing to change on the "host"=
 part of the protocol, and an application should work without any changes. <=
/div>

That's excellent.
However, although it seems possibl=
e to have an user-space implementation that just writes to the multicast rou=
ting table, I think there might be an issue with the original tree creation:=
 I'm not sure it's possible to intercept the first data packet(s) to trigger=
 the Join Query process without being in the kernel. But I'm not an expert w=
ith this, so somebody might correct me. In the meantime I'll dig a little de=
eper, see if I can figure something out.
=

That might also be something that could be established as par=
t of the experiment, also, perhaps?

--- Page 5 ---

Highlight (yellow), 10 mars 2014 19:24, T=
Clausen:
addresses

Note (yellow), 10 mars 2014 19:24, TClausen:I am going to pick out this here, but it applies elsewhere also: "addresses=
"? 

I believe that y=
ou aim at "address length independence", v6/v4/short, and that's a good idea=
 which is, I believe, supported well by RFC5444. Alas, I believe that you pr=
obably want to stick in a definition and explanation of that in here. 

Also, I gather that thes=
e addresses are "interface identifiers" and not "multicast group addresses",=
 yes? Given that this document talks about multicast, I do recommend perhaps=
 calling this out?

=

Ok, will do. I think this will go in the whole "clarifying the router-=
interface-address relationship" part that goes with handling multiple interf=
aces.

That sounds about right, yeah.<=
/div>

<SNIP>

The ODMRP router hearing these,  maps that to a "M=
ulticast Session".

=

Not exactly, since a Multicast Session is Multicast Group Address + Mu=
lticast Source Address, hence a router which has an attached host that has j=
oined a Multicast Group Address might have several corresponding Multicast S=
essions.


OK, so the fa=
ct that I felt the urge to ask this question might indicate that it could do=
 with a clarification (or, perhaps, that I'm a few cards short of a full dec=
k? ;) )

<SNIP>

Also, as I understand it, "Forwarding Group" and "Multicas=
t Overlay" are, respectively, "links" and "routers" for a given Multicast Se=
ssion?

I woul=
d say the opposite actually, the Forwarding Group is the set of routers that=
 form the Multicast Overlay built by the JQ + JR process, and forward the Mu=
lticast data packets for the corresponding multicast session.

Ok, same reply as the one above.

I think that thats what it is, but the relation=
ship between these terms/concepts  could merit being rendered crystal c=
lear here.

Ag=
reed. I wonder if it would not be clearer to drop the term "Multicast Overla=
y" altogether, and only refer to the Forwarding Group, since this is the mos=
t concrete construct used by ODMRP, and only call out in the intro and appli=
cability statement that the Forwarding Group forms a source-rooted tree. Wou=
ld that make more sense?


I'd probably want to see the resulting text before saying yes or no, defi=
nitively, but it sounds like it's a very very sensible plan.

<=
/div>
<SNIP>

--- P=
age 9 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
This probab=
ly needs a bit more of explanation. As I indicated in the general comments, t=
he separation of abstract message content, and 5444-encoding is a possible w=
ay to go, but it is not clear at this point that that's what's being done.
As a consequence, it is not clear why the section title is "Packets an=
d Messages" - those are (in MANET) 5444-constructs, typically.

One po=
ssibility could be to stick Appendix A after section 7. Another, to have app=
endix A be a subsection to section 7.

Agreed, this is not clear enough. See my previous r=
eply for a counter-proposal though (i.e., clarify the separation and keep Ap=
pendix A as an "example encoding"). Otherwise promoting appendix A to a sect=
ion or subsection of sec 7 would work too I guess.
<=
div>
OK, I think that this needs some thought; I've made my co=
mments in the above to this point.

--- Page 11 ---

Highlight (yellow), 10 mars 2014 19:24, T=
Clausen:
Multicast Source

Note (yellow), 10 mars 2014 19:24, TClau=
sen:
Somewhat of the same comment as one I have made before: "the address=
 of the Multicast Source"

First, is the "Multicast Source" the router=
, through which the multicast data messages ingress through, or is it the ho=
st on which the application generating data, is? Does it make any difference=
? "Multicast Source" is not defined.

I think that provided that the host-to-router relati=
onship is 1-1 and well defined, having the Multicast Source be the actual ho=
st sending the data would work. But it's true that there's a need to be expl=
icit there.

Oh, I hope that you m=
ean that the host-to-router relationship is m-1, in that "one router can ser=
ve many hosts", yes?

Incidentally, in case that the=
 m-1 applies, that probably deserves to be called out in the applicability s=
tatement (i.e., no multihoming permitted?). Even better if you could state w=
hat the consequences of multihoming would be (would it work, but be ineffici=
ent, or would it break the Internet?)

<SNIP><=
/div>

=


--- Page 16 ---

H=
ighlight (yellow), 10 mars 2014 19:24, TClausen:
an address

Note (=
yellow), 10 mars 2014 19:24, TClausen:
Which address? Any? Always the sam=
e? Does it matter?

Highlight (yellow), 10 mars 2014 19:24, TClausen:<=
br>neighbors

Note (yellow), 10 mars 2014 19:24, TClausen:
I assume=
 that what you want is to forward to all the neighbors on all ODMRP interfac=
es of this router, yes?

Yes, although I should probably call out more explicitly that the=
 JQ should be passed to the forwarding mechanism in place in the network (so=
 that if SMF with ECDS - or OLSRv2's MPR - is in place it can be used for ex=
ample).


That sounds li=
ke a good idea, yeah.

--- Page 19 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:=

neighbors

Note (yellow), 10 mars 2014 19:24, TClausen:
Over al=
l ODMRP Interfaces?


Note (yellow), 10 mars 2014 19:24, TClausen:<=
br>Here, we are gleaning a bit more precisely what the R_source is; so its a=
n interface of an ODMRP router over which the Join Reply was sent, yes?
<=
/blockquote>

Actually I think I=
 should refactor the document to map this to the multicast source. This shou=
ld help in mapping various information base tuples to the multicast session,=
 and avoid issues such as choosing which address to put in a newly-generated=
 join query.

That sounds sensible.

<SNIP>

=

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest: "...run in c=
onjunction with, and benefit from some of the features of, SMF..."

St=
rikeout (red), 10 mars 2014 19:24, TClausen:
and     =
           benefit fr=
om some of its features.

Note (yellow), 10 mars 2014 19:24, TClausen:=

I would be hesitant to call this section "SMF Considerations"

Whi=
le SMF is an important and useful protocol set, I would suggest that this se=
ction be generalized: what's at stake is, and I think that I saw that in the=
 slides that were presented in the London IETF, that if there's a "more effi=
cient than classic flooding" network-wider broadcast operation in place, the=
n ODMRP would/should use it - correct?

This might be by way of SMF, o=
r it could be as an extension to OLSRv2's MPR flooding, or it could be (as i=
s seen in for example HNCP) something based off of Trickle - or something en=
tirely different.

So, perhaps "Flooding considerations" as section ti=
tle, and a bit generalized text would work?

Funny enough, this was the original title - I=
'll put that back in then, and generalize to other possible flooding mechani=
sms.

Hah, first impulses sometimes ar=
e the right ones ;)



=
--- Page 22 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
=
Packets

Note (yellow), 10 mars 2014 19:24, TClausen:
Packets ->=
 Packet

Note (yellow), 10 mars 2014 19:24, TClausen:
OK, I think t=
hat this document should start by actually requesting the allocations for th=
e two message types. Cf. how it is done in section 18.2 of RFC6130

Th=
en, I *think* that the current 15.1 is the Message-Type-Specific TLV Type Re=
gistries" that are being set up, for Join-Query yes? I see "Expert Review" m=
entioned, but no guidelines/recommendations for the Expert to follow. Do you=
 intend to mirror those from RFC5444, or are there special concerns to take i=
nto consideration?

I would actually suggest mirroring the structure o=
f the IANA section from RFC6130  if for no other reasons, than that it'=
s allocating from RFC5444-registries, and has been going through the process=
 and so it may be assumed that something mirroring it will, too. ;)

Alright, will look at=
 that and do so then.

Note, this is n=
ot something I'm dogmatic about, but the approval process of TLV-Extensions h=
as taught me that IANA appreciates getting very very clear instructions (can=
't blame them ;) ), and that providing such makes things so much easier for a=
uthors, ADs and IANA.

--- Pa=
ge 25 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
Just a comm=
ent, a cursory review of the mapping to RFC5444 doesn't have anything jump a=
t me screaming "problems", which is good.

I was wondering one thing, t=
hough: if running OLSRv2 + ODMRP, then there's an obvious option which could=
 be considered (and could be considered, in order to be disregarded)....
=

Could one imagine carrying ODMRP signals inside TC messages in any meani=
ngful way, as TLVs and additional addresses included? *technically* it shoul=
d be possible, does it make sense?

Technically that should work, I guess the advantage wo=
uld be to have less duplicate information flooded throughout the network, an=
d overall less packets sent, but I'm not sure it would be easy to encode tha=
t in any way that would 1) prevent too much duplicate information and 2) be e=
asy to parse (both for the specs reader and the implementation). So I'm worr=
ied this would not really be worth it.

That's fair enough, this was just something I thought about in an idle mom=
ent. 

A second thing, is t=
here any reason to request both JR and JQ message type, or is there a way of=
 using just a single code-point, and are there potential benefits in doing s=
o?

A different way of phrasing the above is: given that code-points b=
y definition are limited, I'd like to ask for a bit more of "justification" b=
efore they are allocated.

Well first off, in a more "abstract" sense I think it's clearer=
 to keep the JQ vs JR distinction throughout the document. However it could b=
e envisioned to have only a ODMRP-message type with a "flags" TLV that would=
 have one flag determining whether the message is actually treated as a JQ o=
r a JR. After all, the two messages are pretty similar in content. For now t=
he only drawback I see is that it would slightly increase the message size. B=
ut I guess the same reasoning could be done with a lot of protocols, no?
=


OK, fair enough. 

As codepoints (almost always) are at a premium, think=
ing through these things is just something that I encourage to be done very,=
 very carefully. When we designed OLSRv2, for example, one of the things we d=
id vs. OLSRv1 was to remove 3 message types, and "consume" only one (TC) out=
 of the 5444 message type space.

I've not really ma=
de up my mind either way, but I'd encourage that we keep thinking about this=
?

Sounds, overall, like the coming revision will be=
 reflecting the bulk of the issues that I've brought up, and that we've got a=
 few marked as "to think a bit further about". Overall, that's fabulous!

Thank you for your reply, and I look much forward to r=
eviewing an upcoming iteration of this document.

Be=
st,

Thomas
=

--Apple-Mail-F3715D03-3F9C-4180-9527-B6C09C241B5B--


From nobody Tue Mar 11 17:14:36 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E171A0887 for ; Tue, 11 Mar 2014 17:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgRva7TPezAX for ; Tue, 11 Mar 2014 17:14:29 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 352401A0899 for ; Tue, 11 Mar 2014 17:14:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AA061240609; Tue, 11 Mar 2014 17:14:23 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.142] (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 maila2.tigertech.net (Postfix) with ESMTPSA id D5579240560; Tue, 11 Mar 2014 17:14:22 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (11D167)
In-Reply-To: <18B34B51-7223-42B5-862D-E5B4150C26BD@gmail.com>
Date: Wed, 12 Mar 2014 01:14:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <92E1E749-448F-405F-B65B-53C0BCD375F3@thomasclausen.org>
References: <20140305115333.7635.9928.idtracker@ietfa.amsl.com> <335AD6ED-F820-4C3B-9C11-F6593D4EEE43@axelcdv.com>  <18B34B51-7223-42B5-862D-E5B4150C26BD@gmail.com>
To: Christopher Dearlove 
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gFVoOJ8w7rU3PY5ZmWKs6cwu-vE
Cc: " List" , =?utf-8?Q?Axel_Colin_de_Verdi=C3=A8re?= , gerla , Soon Young Oh 
Subject: Re: [manet] Basic initial comment for draft-gerla-manet-odmrp-02.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Mar 2014 00:14:34 -0000

https://www.rfc-editor.org/rfcfaq.html#british

> On 11 mars 2014, at 08:02, Christopher Dearlove  wrote:
>=20
> I believe on British English, the RFC Editor's rules can be summarised as:=

> - British English is permitted.
> - But in practice no one does.
>=20
> So, yes, I have misspelled neighbour in all the drafts I have co-authored.=

>=20
> But it's spelled correctly in my software ;)
>=20
> --=20
> Christopher Dearlove
> christopher.dearlove@gmail.com
>=20
>> On 11 Mar 2014, at 00:04, Joe Macker  wrote:
>>=20
>> Sorry I was working with pdf document here are my very basic exported com=
ments that might hep with a revision.
>> More in the second set of comments. The general comments are just for gen=
eral discussio going forward.
>> There are plenty more things but I did not do a comprehensive review yet.=

>>=20
>> -------
>> First off nice work!
>>=20
>> General Comments:
>>=20
>> (1) In a future revision, it would probably be good to discuss the design=
 issues associated with finding the right value of Route Query refresh flood=
ing intervals.  As you know, there have been plenty of published papers on t=
he subject relating to ODMRP.
>>=20
>> (2) Might want to discuss any relationship with any SSM from the IGMPv2, M=
LD perspective,etc.  Is there an intention to support SSM?The state is certa=
inly source specific.
>>=20
>> (3) We could discuss more about how this could work with RFC 6130 concept=
s or where similar security considerations may lie.  This could be done down=
 the road as we flesh things out more and consider acceptance as a  WG item.=

>>=20
>>=20
>> Summary of More Specific Minor Comments on draft-gerla-manet-odmrp-02.pdf=

>>=20
>> Page: 4
>> Author: macker Subject: Sticky Note Date: 3/10/14, 7:05:03 PM
>> of a "forwarding group"
>> also avril -> april in reference
>>=20
>> Page: 7
>> Author: macker Subject: Sticky Note Date: 3/10/14, 7:11:34 PM
>> disctinct -> distinct
>>=20
>> Page: 8
>> Author: macker Subject: Sticky Note Date: 3/10/14, 7:15:10 PM
>> neighbour->neighbor
>> I personally have no issue with British spellings in IETF docs.
>> But since RFC 6130 and Crhis Dearlove go this way=20
>>=20
>> Page: 9
>> Author: macker Subject: Sticky Note Date: 3/10/14, 7:18:27 PM
>> Security Considerations for sequencing
>> Replay etc (see later in pg 22 comments)
>> Page: 11
>> Author: macker Subject: Sticky Note Date: 3/10/14, 7:20:36 PM
>> Fix sentence grammar:
>> recommend remove "when"
>> Page: 21
>> Author: macker Subject: Sticky Note Date: 3/10/14, 7:34:41 PM
>> I think its great to have some potential convergence of capability here.
>> The sentence duplication packets and message detection is malformed at le=
ast in the pdf version of the draft. Perhaps an xml,etc.
>> Scoped flooding may be assisted by an SMF implementation as well.
>> We have published and some unpublished improvements to these optimized fl=
ooding mechanisms (e.g., ECDS) that might provide more stability.
>> both ipv4 and ipv6.
>> Page: 22
>> Author: macker Subject: Sticky Note Date: 3/10/14, 7:36:26 PM
>> There are likely particular security vulnerabilities that can be discusse=
d regarding monotic sequences as used in control plane.. See SMF and other d=
ocuments for similar issues such as replay,etc. Something for a future revis=
ion.
>>=20
>>=20
>>> On Mar 5, 2014, at 7:00 AM, Axel Colin de Verdi=C3=A8re  wrote:
>>>=20
>>> Hi all,
>>>=20
>>> We just pushed a new revision of ODMRP out, the -02 version presented at=
 the meeting. I got some comments during this week and plan to integrate the=
m into a -03 revision pretty soon. I'd be happy to discuss additional sugges=
tions or remarks that could be added to that revision.
>>>=20
>>> Thanks,
>>>=20
>>> Axel
>>>=20
>>>=20
>>> D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 :
>>>=20
>>>> De: internet-drafts@ietf.org
>>>> Objet: New Version Notification for draft-gerla-manet-odmrp-02.txt
>>>> Date: 5 mars 2014 11:53:33 UTC
>>>> =C3=80: "William Su" , "Yunjung Yi" , "Axel Coli Verdiere" , "Sun=
g-Ju Lee" , Mario Gerla , "Professor Mario Gerla" , William Su , Axel Colin de Verdiere 
>>>>=20
>>>>=20
>>>> A new version of I-D, draft-gerla-manet-odmrp-02.txt
>>>> has been successfully submitted by Axel Colin de Verdiere and posted to=
 the
>>>> IETF repository.
>>>>=20
>>>> Name:        draft-gerla-manet-odmrp
>>>> Revision:    02
>>>> Title:        On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc N=
etworks
>>>> Document date:    2014-03-05
>>>> Group:        Individual Submission
>>>> Pages:        30
>>>> URL:            http://www.ietf.org/internet-drafts/draft-gerla-manet-o=
dmrp-02.txt
>>>> Status:         https://datatracker.ietf.org/doc/draft-gerla-manet-odmr=
p/
>>>> Htmlized:       http://tools.ietf.org/html/draft-gerla-manet-odmrp-02
>>>> Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-od=
mrp-02
>>>>=20
>>>> Abstract:
>>>> The On-Demand Multicast Routing Protocol (ODMRP) is a multicast
>>>> routing protocol designed for ad hoc networks with mobile hosts.
>>>> ODMRP is a mesh-based, rather than a conventional tree-based,
>>>> multicast scheme and uses a forwarding group concept (only a subset
>>>> of nodes forwards the multicast packets via scoped flooding).  It
>>>> applies on-demand procedures to dynamically build routes and maintain
>>>> multicast group membership.  ODMRP is well suited for ad hoc wireless
>>>> networks with mobile hosts where bandwidth is limited, topology
>>>> changes frequently and rapidly, and power is constrained.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> Please note that it may take a couple of minutes from the time of submi=
ssion
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>=20
>>>> The IETF Secretariat
>>>=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 nobody Sun Mar 23 19:19:35 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF6B1A00B0; Sun, 23 Mar 2014 19:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF0ntrcR-2d4; Sun, 23 Mar 2014 19:19:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A945C1A00BA; Sun, 23 Mar 2014 19:19:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140324021927.29200.35796.idtracker@ietfa.amsl.com>
Date: Sun, 23 Mar 2014 19:19:27 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/V35ipwsCPw1DnYfmw6J6yAT5QI8
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-smf-mib-11.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Mar 2014 02:19:32 -0000

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           : Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process
        Authors         : Robert G. Cole
                          Joseph Macker
                          Brian Adamson
	Filename        : draft-ietf-manet-smf-mib-11.txt
	Pages           : 64
	Date            : 2014-03-23

Abstract:
   This memo 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 aspects of the
   Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc
   Networks (MANETs).  The SMF-MIB module also reports state
   information, performance information, and notifications.  In addition
   to configuration, the additional state and performance information is
   useful to operators troubleshooting multicast forwarding problems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-smf-mib-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-mib-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Sun Mar 23 19:23:34 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D991A00AA for ; Sun, 23 Mar 2014 19:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.023
X-Spam-Level: 
X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfxJKI_dkAI0 for ; Sun, 23 Mar 2014 19:23:31 -0700 (PDT)
Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E9D151A00B9 for ; Sun, 23 Mar 2014 19:23:30 -0700 (PDT)
Received: by mail-ve0-f170.google.com with SMTP id pa12so5067755veb.29 for ; Sun, 23 Mar 2014 19:23: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 :content-type; bh=8ShUZNmtyUH9WG8VoLxKes6Czm/iBnx1hQg95Z7PFqk=; b=Zjcu5CwzHCOb6sHVl87MqgHni3J7g2t4E1e190k2TxLVblDFnEO2s/7itSGC+LhiYC 06fVXmXcuGft4kTc3XeBoZLxacMbL17/1SXGMfWGjBGCqBHy8b+rE1t1bj9/iD2TwLb1 wI335oj+VuVpx/DYY8rinFBLwh8gssNDeB0IU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=8ShUZNmtyUH9WG8VoLxKes6Czm/iBnx1hQg95Z7PFqk=; b=LlexTjsrdfIgnK1gjvYu8EEcqx9bIcBYPlkJUc/RmeLbZd3xUvGwfItpjlM3GMmSy9 lipYBwDatY6sng2RdbA1V1c0qLD4KX6w8jfkJSATwBxYnXYcqo1fv8PqGhTHj6qPpsrJ qqojgl5798GotfTRrR8u32UrO5IxrMSdspespP/wSaNpMQx2L8dWyRGn3uQsigYVq6fF TB1+PvQGXVbw1PN1+Nq043993cNf7tTKu9pJzSRdvs/FFIT8P3g5ob7E+I2dAUYXt/b0 GmzAEUhKZDL0kgXTZOcoZA21Oec2J6kpx49JtRCZJqnMLLcnLuDxUeijoz+p6twKgVDE xLYw==
X-Gm-Message-State: ALoCoQmdE7KCV4dLekg7qPfT8D7Q6ys4/3VlUqIVolqt0o64CCx6xYfMQOty+9GSNW66ByaAUdMG
MIME-Version: 1.0
X-Received: by 10.52.37.161 with SMTP id z1mr345827vdj.29.1395627810046; Sun, 23 Mar 2014 19:23:30 -0700 (PDT)
Received: by 10.220.230.9 with HTTP; Sun, 23 Mar 2014 19:23:29 -0700 (PDT)
In-Reply-To: 
References: 
Date: Sun, 23 Mar 2014 19:23:29 -0700
Message-ID: 
From: Ulrich Herberg 
To: "manet-chairs@tools.ietf.org" , manet@ietf.org
Content-Type: multipart/alternative; boundary=bcaec51d25b4db5da904f550eb7d
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/r36yr-s4asjbU-fCzJfxcYt5LMI
Subject: [manet] Fwd: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Mar 2014 02:23:32 -0000

--bcaec51d25b4db5da904f550eb7d
Content-Type: text/plain; charset=ISO-8859-1

Dear MANET chairs,

have you seen my email from March 5? Can you inform us whether you intend
to get a consensus call for WG adoption?

Thanks
Ulrich

---------- Forwarded message ----------
From: Ulrich Herberg 
Date: Wed, Mar 5, 2014 at 6:05 AM
Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
To: manet@ietf.org


Dear WG chairs,

as we mentioned during the MANET meeting, Thomas and I would like to
request to get a consensus call on the mailing list for WG adoption of
draft-clausen-manet-olsrv2-management-snapshot-01.

Best regards
Ulrich

--bcaec51d25b4db5da904f550eb7d
Content-Type: text/html; charset=ISO-8859-1


Dear MANET chairs,

have you seen my email from March 5? Can you inform us whether you intend to get a consensus call for WG adoption?

Thanks
Ulrich



---------- Forwarded message ----------
From: Ulrich Herberg <ulrich@herberg.name>

Date: Wed, Mar 5, 2014 at 6:05 AM
Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
To: manet@ietf.org


Dear WG chairs,


as we mentioned during the MANET meeting, Thomas and I would like to request to get a consensus call on the mailing list for WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01.


Best regards
Ulrich





--bcaec51d25b4db5da904f550eb7d--


From nobody Mon Mar 24 08:17:09 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4369E1A01B5 for ; Mon, 24 Mar 2014 08:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.51
X-Spam-Level: 
X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEEGA-BkvJOz for ; Mon, 24 Mar 2014 08:17:03 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id D4AD81A019E for ; Mon, 24 Mar 2014 08:17:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3701; q=dns/txt; s=iport; t=1395674222; x=1396883822; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=B7cHUg1k15tGrsUpsR4T+WX4qSKsZr4s5QDncJOzZHM=; b=fTpCRXBl9L0J8hZtXHW8LjekhOXQuQzsnnqx4iyhVGYzkiGO10KSAMAA Y1+L4UY9+zOgylGUd6tzpaC/kk+fZOws3+12G+5J1BMNKVfRVMu5tqB6I 2DlEQ5ZFoMBIfFZS35JnoAVmRUiTgQeAD4dj/jiuKwCBRTfJ0HFJ0Jp4b 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFALpLMFOtJV2Z/2dsb2JhbABZgwY7V7s4hzWBGBZ0giUBAQEEAQEBGlELEAIBCAQNAwECKAcnCxQJCAIEDgWHeQ3OORMEjmkRBgEGgx6BFASJGo8wkjGDLYIr
X-IronPort-AV: E=Sophos; i="4.97,721,1389744000"; d="scan'208,217"; a="29887310"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 24 Mar 2014 15:17:01 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2OFH17Y003135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 15:17:01 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 10:17:01 -0500
From: "Stan Ratliff (sratliff)" 
To: Ulrich Herberg 
Thread-Topic: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
Thread-Index: AQHPR3QacYoG0lhj10GrVMsxPg9hPw==
Date: Mon, 24 Mar 2014 15:17:00 +0000
Message-ID: <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@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.150.34.203]
Content-Type: multipart/alternative; boundary="_000_7A7416CCAEC14FC791E2CD63494D0D89ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/OsGhgVBJRuC9SLHZZ1nSleqb-6I
Cc: "manet-chairs@tools.ietf.org" , "" 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Mar 2014 15:17:05 -0000

--_000_7A7416CCAEC14FC791E2CD63494D0D89ciscocom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Working group participants,

This is a call for consensus on adoption of the mentioned draft. Please res=
pond no later than April 4, 2014. Lack of response will be considered as a =
vote for adoption of the document.

Regards,
stan

On Mar 23, 2014, at 10:23 PM, Ulrich Herberg > wrote:

Dear MANET chairs,

have you seen my email from March 5? Can you inform us whether you intend t=
o get a consensus call for WG adoption?

Thanks
Ulrich

---------- Forwarded message ----------
From: Ulrich Herberg >
Date: Wed, Mar 5, 2014 at 6:05 AM
Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
To: manet@ietf.org


Dear WG chairs,

as we mentioned during the MANET meeting, Thomas and I would like to reques=
t to get a consensus call on the mailing list for WG adoption of draft-clau=
sen-manet-olsrv2-management-snapshot-01.

Best regards
Ulrich

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


--_000_7A7416CCAEC14FC791E2CD63494D0D89ciscocom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <0DB3451494A4494FAE20129FCD90A43E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable






Dear Working group participants, 






This is a call for consensus on adoption of the mentioned draft. Pleas=
e respond no later than April 4, 2014. Lack of response will be considered =
as a vote for adoption of the document. 







Regards,


stan







On Mar 23, 2014, at 10:23 PM, Ulrich Herberg <ulrich@herberg.name> wrote:










Dear MANET chairs,





have you seen my email from March 5? Can you inform us whether you intend t=
o get a consensus call for WG adoption?





Thanks

Ulrich








---------- Forwarded message ----------

From: Ulrich Herberg &l=
t;ulrich@herberg.name>=


Date: Wed, Mar 5, 2014 at 6:05 AM

Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?<=
br>
To: manet@ietf.org










Dear WG chairs,





as we mentioned during the MANET meeting, Thomas and I would like to reques=
t to get a consensus call on the mailing list for WG adoption of draft-clau=
sen-manet-olsrv2-management-snapshot-01.





Best regards

Ulrich













_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet












--_000_7A7416CCAEC14FC791E2CD63494D0D89ciscocom_--


From nobody Mon Mar 24 08:20:31 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721E51A0226 for ; Mon, 24 Mar 2014 08:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6ih0JyYgswI for ; Mon, 24 Mar 2014 08:20:26 -0700 (PDT)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D8B2D1A019E for ; Mon, 24 Mar 2014 08:20:25 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id r5so6170646qcx.32 for ; Mon, 24 Mar 2014 08: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:from:date:message-id:subject:to :cc:content-type; bh=V8oDMgUYDoYOj1cp7H8w3X+lRCkAhK6n0y0R/kGMwTw=; b=ABeySRE5LOdUIvWsb288qhxq0U+efHn4yQa6vRvQLkN7gMwoDuus667XffbdwNjdXh 241OPz7s8dCPyoHS98KnqXQSsmrw6zSQPLkp9uUMWfePvJjYG7iD/eoeDh731/bx2Psq kOaqfTzOYhEtVXQk2NS0HxW8nYyxSKIwRwzbEawNtXWxutmcfOJA1f7mjFtzN0NFH+rq +/Vzt26gz0PhiyJzJsEwY21RpIJnESxWsQNKLBaOLIUrdIZ5KCJn6tKEwgqAX89otQqo LQ1RB31z9tNHo1GrOiomdgByS9pncl7VTQRkPxTj7QKe/gJKCE0ejeKcR/UO0mZOOR/j /Khg==
X-Received: by 10.140.97.37 with SMTP id l34mr25905510qge.56.1395674424931; Mon, 24 Mar 2014 08:20:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.120.66 with HTTP; Mon, 24 Mar 2014 08:20:04 -0700 (PDT)
In-Reply-To: <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com>
References:   <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com>
From: Henning Rogge 
Date: Mon, 24 Mar 2014 16:20:04 +0100
Message-ID: 
To: "Stan Ratliff (sratliff)" 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UVMnfgA24jl1Cz85uLqwHyf_LFs
Cc: "manet-chairs@tools.ietf.org" , "" 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Mar 2014 15:20:28 -0000

+1 for the adoption of the document.

Henning Rogge

(P.S.: back from a week of sick leave, expect the -00 draft of the WG
DAT metric document soon!)

On Mon, Mar 24, 2014 at 4:17 PM, Stan Ratliff (sratliff)
 wrote:
> Dear Working group participants,
>
> This is a call for consensus on adoption of the mentioned draft. Please
> respond no later than April 4, 2014. Lack of response will be considered as
> a vote for adoption of the document.
>
> Regards,
> stan
>
> On Mar 23, 2014, at 10:23 PM, Ulrich Herberg  wrote:
>
> Dear MANET chairs,
>
> have you seen my email from March 5? Can you inform us whether you intend to
> get a consensus call for WG adoption?
>
> Thanks
> Ulrich
>
> ---------- Forwarded message ----------
> From: Ulrich Herberg 
> Date: Wed, Mar 5, 2014 at 6:05 AM
> Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
> To: manet@ietf.org
>
>
> Dear WG chairs,
>
> as we mentioned during the MANET meeting, Thomas and I would like to request
> to get a consensus call on the mailing list for WG adoption of
> draft-clausen-manet-olsrv2-management-snapshot-01.
>
> 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 nobody Mon Mar 24 14:10:36 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1CB1A0268 for ; Mon, 24 Mar 2014 14:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.45
X-Spam-Level: *
X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLWW47mAErDT for ; Mon, 24 Mar 2014 14:10:28 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4606D1A01CD for ; Mon, 24 Mar 2014 14:10:27 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s2OLAJdR022345; Mon, 24 Mar 2014 22:10:20 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C7B4E716AC; Mon, 24 Mar 2014 22:10:19 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id uTulfNyYTmst; Mon, 24 Mar 2014 22:10:18 +0100 (CET)
Received: from ijon.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D05A8716A8; Mon, 24 Mar 2014 22:10:17 +0100 (CET)
Date: Mon, 24 Mar 2014 22:10:18 +0100
Message-ID: <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr>
From: Juliusz Chroboczek 
To: Axel Colin de =?ISO-8859-1?Q?Verdi=E8re?= 
In-Reply-To: <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com>
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org> <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 24 Mar 2014 22:10:20 +0100 (CET)
X-Miltered: at korolev with ID 53309F3B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 53309F3B.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/
X-j-chkmail-Score: MSGID : 53309F3B.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gvP16shgrFy-cM9mOYwApEzEEkU
Cc: MANET IETF 
Subject: [manet] Reactive protocols in userspace [was: draft-gerla-manetodmrp-02]
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Mar 2014 21:10:30 -0000

> - I think this could be implemented in user-space, but I'm afraid that having
> to intercept the first data packet in order to build the multicast tree would
> require a kernel module.

This is exactly the issue that the reactive protocol people have been
struggling with for over a decade now, and that I mentioned in London
during the discussion of AODVv2.

Historically, AODV has been implemented as a kernel module, which
caused no end of problems.  Recently, it has been implemented in
userspace by playing tricks with tun interfaces.

Henning explained the trick to me as follows.  He puts a default route
through a tun interface, which causes all unroutable packets to go to
userspace.  He then buffers the tunnelled packets, and sets a more
specific route whenever a route is established.  Yes, it's a hack, and
one that only works in the absence of bona fide shorter prefix routes
(HNAs in OLSR parlance).  (I also don't see how it handles AODV's
error case, but that's a different issue.)

As you rightly note, and as I mentioned at the London meeting, the
proper approach would be to have a callback to userspace for the first
packets of a new flow (as well as for the error case).  There is some
precedent for that, the "ARP daemon" interface, which allows
implementing the ARP cache (a degenerate reactive protocol) in
userspace.  See CONFIG_ARPD in your kernel configuration docs.

It would be an interesting research project to design and implement
a minimal, stable API that allows implementing both AODVv2 and ODMRP
entirely in userspace.  Actually, it's more than that -- it's the only
way to save AODVv2.

-- Juliusz


From nobody Mon Mar 24 14:53:31 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C855E1A0295 for ; Mon, 24 Mar 2014 14:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG5hrSwkFIiA for ; Mon, 24 Mar 2014 14:53:23 -0700 (PDT)
Received: from mail4.nrl.navy.mil (scmail.nrl.navy.mil [IPv6:2001:480:20:421::587:27]) by ietfa.amsl.com (Postfix) with ESMTP id EF7ED1A02A2 for ; Mon, 24 Mar 2014 14:53:19 -0700 (PDT)
Received: from aes048190.nrl.navy.mil (aes048190.nrl.navy.mil [132.250.48.190]) (authenticated bits=0) by mail4.nrl.navy.mil (8.14.5/8.14.5) with ESMTP id s2OLrFqQ016599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Mar 2014 17:53:15 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_47E88106-F1EC-4F12-8962-44484F42F9A5"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Brian Adamson 
In-Reply-To: <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr>
Date: Mon, 24 Mar 2014 17:53:16 -0400
Message-Id: <2369CDD6-126A-48BF-B68D-27920B6C64AA@nrl.navy.mil>
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org> <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com> <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr>
To: Juliusz Chroboczek 
X-Mailer: Apple Mail (2.1510)
X-Scanned-By: MIMEDefang 2.72
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/WRKYUy8VwZIdTRZVoOshOYt1k3Y
Cc: MANET IETF 
Subject: Re: [manet] Reactive protocols in userspace [was: draft-gerla-manetodmrp-02]
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Mar 2014 21:53:28 -0000

--Apple-Mail=_47E88106-F1EC-4F12-8962-44484F42F9A5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I recently added a "device" command-line option to our "nrlsmf" user =
space forwarding code (http://www.nrl.navy.mil/itd/ncs/products/smf) =
that does the same sort of think you mentioned that Henning described to =
you with use of a tun/tap virtual interface that is logically bridged =
(by the nrlsmf code) to a physical interface.  This lets nrlsmf be _in_ =
the path of all outbound (and inbound) traffic for the virtual interface =
that is created (and presumably then used by MANET routing code like our =
OSLR code).   I haven't yet had a chance to describe the "device" option =
in the User Guide yet, but the code, etc is in our "nightly snapshot" =
release.  The nlrsmf code works on Linux, MacOSX, Windows, Android, etc =
since it uses a cross-platform framework we developed for various =
purposes.

We have some plans to generalize the control interface of our nrlsmf =
forwarding engine to allow control of a forwarding information based =
(FIB) for multicast (and possibly unicast) packet forwarding for =
protocols like the Elastic Multicast draft we recently presented and =
could be used for the proposed ODMRP as well.  And the concept could =
allow for support of On Demand unicast routing protocols as well.

The approach would be for the forwarding engine (to have a control port =
the routing control plane protocol would monitor to be informed of newly =
detected "flows"  (along the lines of what we described in the Elastic =
Multicast) presentation and allow the control protocol then specify any =
changes to how the flow would be handled.  For the case of Elastic =
Multicast, a default behavior like flooding (perhaps with a token bucket =
restriction like we described) might be used for newly detected flows =
until the control protocol made up its mind on what to do.  For =
something like AODV, I suppose a default behavior of buffering packets =
could be set =85  The idea would be to have some preset default =
behaviors set for different traffic filters (e.g. multicast vs. unicast =
or even special handling for certain traffic classes, including perhaps =
even default flooding of critical unicast flows, etc). =20

The purpose of this generalization is to use the nrlsmf framework to =
prototype the FIB design and determine the control interface =
requirements looking ahead towards future (hopefully) kernel module =
implementation, etc.  The nice thing about the interim research & =
developer user space implementation is cross-platform and development =
flexibility support until kernel support could be available.   It's a =
long term path to get there based on the developer time/resources we =
have available, but this is the direction we're heading.  When we =
support all this stuff, we may need to change the "smf" in nrlsmf to =
mean "sophisticated manet forwarding" ;-).

best regards,

Brian

On Mar 24, 2014, at 5:10 PM, Juliusz Chroboczek =
 wrote:

>> - I think this could be implemented in user-space, but I'm afraid =
that having
>> to intercept the first data packet in order to build the multicast =
tree would
>> require a kernel module.
>=20
> This is exactly the issue that the reactive protocol people have been
> struggling with for over a decade now, and that I mentioned in London
> during the discussion of AODVv2.
>=20
> Historically, AODV has been implemented as a kernel module, which
> caused no end of problems.  Recently, it has been implemented in
> userspace by playing tricks with tun interfaces.
>=20
> Henning explained the trick to me as follows.  He puts a default route
> through a tun interface, which causes all unroutable packets to go to
> userspace.  He then buffers the tunnelled packets, and sets a more
> specific route whenever a route is established.  Yes, it's a hack, and
> one that only works in the absence of bona fide shorter prefix routes
> (HNAs in OLSR parlance).  (I also don't see how it handles AODV's
> error case, but that's a different issue.)
>=20
> As you rightly note, and as I mentioned at the London meeting, the
> proper approach would be to have a callback to userspace for the first
> packets of a new flow (as well as for the error case).  There is some
> precedent for that, the "ARP daemon" interface, which allows
> implementing the ARP cache (a degenerate reactive protocol) in
> userspace.  See CONFIG_ARPD in your kernel configuration docs.
>=20
> It would be an interesting research project to design and implement
> a minimal, stable API that allows implementing both AODVv2 and ODMRP
> entirely in userspace.  Actually, it's more than that -- it's the only
> way to save AODVv2.
>=20
> -- Juliusz
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


--Apple-Mail=_47E88106-F1EC-4F12-8962-44484F42F9A5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I =
recently added a "device" command-line option to our "nrlsmf" =
user space forwarding code (http://www.nrl.navy.=
mil/itd/ncs/products/smf) that does the same sort of think you =
mentioned that Henning described to you with use of a tun/tap virtual =
interface that is logically bridged (by the nrlsmf code) to a =
physical interface.  This lets nrlsmf be _in_ the path of =
all outbound (and inbound) traffic for the virtual interface that is =
created (and presumably then used by MANET routing code like our OSLR =
code).   I haven't yet had a chance to describe the "device" option =
in the User Guide yet, but the code, etc is in our "nightly snapshot" =
release.  The nlrsmf code works on Linux, MacOSX, Windows, =
Android, etc since it uses a cross-platform framework we developed for =
various purposes.

We have some plans to generalize =
the control interface of our nrlsmf forwarding engine to allow =
control of a forwarding information based (FIB) for multicast (and =
possibly unicast) packet forwarding for protocols like the Elastic =
Multicast draft we recently presented and could be used for the proposed =
ODMRP as well.  And the concept could allow for support of On =
Demand unicast routing protocols as well.

The =
approach would be for the forwarding engine (to have a control port the =
routing control plane protocol would monitor to be informed of newly =
detected "flows"  (along the lines of what we described in the =
Elastic Multicast) presentation and allow the control protocol then =
specify any changes to how the flow would be handled.  For the case =
of Elastic Multicast, a default behavior like flooding (perhaps with a =
token bucket restriction like we described) might be used for newly =
detected flows until the control protocol made up its mind on what to =
do.  For something like AODV, I suppose a default behavior of =
buffering packets could be set =85  The idea would be to have some =
preset default behaviors set for different traffic filters (e.g. =
multicast vs. unicast or even special handling for certain traffic =
classes, including perhaps even default flooding of critical unicast =
flows, etc).  

The purpose of this =
generalization is to use the nrlsmf framework to prototype the =
FIB design and determine the control interface requirements looking =
ahead towards future (hopefully) kernel module implementation, etc. =
 The nice thing about the interim research & developer user =
space implementation is cross-platform and development flexibility =
support until kernel support could be available.   It's a long term =
path to get there based on the developer time/resources we have =
available, but this is the direction we're heading.  When we =
support all this stuff, we may need to change the "smf" in nrlsmf to =
mean "sophisticated manet forwarding" ;-).

best =
regards,

Brian

On Mar 24, =
2014, at 5:10 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.f=
r> wrote:

- I think this could be =
implemented in user-space, but I'm afraid that having
to intercept =
the first data packet in order to build the multicast tree =
would
require a kernel module.

This is exactly =
the issue that the reactive protocol people have been
struggling with =
for over a decade now, and that I mentioned in London
during the =
discussion of AODVv2.

Historically, AODV has been implemented as =
a kernel module, which
caused no end of problems.  Recently, it =
has been implemented in
userspace by playing tricks with tun =
interfaces.

Henning explained the trick to me as follows. =
 He puts a default route
through a tun interface, which causes =
all unroutable packets to go to
userspace.  He then buffers the =
tunnelled packets, and sets a more
specific route whenever a route is =
established.  Yes, it's a hack, and
one that only works in the =
absence of bona fide shorter prefix routes
(HNAs in OLSR parlance). =
 (I also don't see how it handles AODV's
error case, but that's =
a different issue.)

As you rightly note, and as I mentioned at =
the London meeting, the
proper approach would be to have a callback =
to userspace for the first
packets of a new flow (as well as for the =
error case).  There is some
precedent for that, the "ARP daemon" =
interface, which allows
implementing the ARP cache (a degenerate =
reactive protocol) in
userspace.  See CONFIG_ARPD in your kernel =
configuration docs.

It would be an interesting research project =
to design and implement
a minimal, stable API that allows =
implementing both AODVv2 and ODMRP
entirely in userspace. =
 Actually, it's more than that -- it's the only
way to save =
AODVv2.

-- =
Juliusz

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

=

--Apple-Mail=_47E88106-F1EC-4F12-8962-44484F42F9A5--


From nobody Mon Mar 24 16:39:42 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCD01A000B for ; Mon, 24 Mar 2014 16:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYFluE7T4anU for ; Mon, 24 Mar 2014 16:39:39 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id A7A5E1A0005 for ; Mon, 24 Mar 2014 16:39:38 -0700 (PDT)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s2ONdb5d030185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Mar 2014 00:39:37 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s2ONdaUP025882; Tue, 25 Mar 2014 00:39:36 +0100
Received: from mailhub.admin.local (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9E2132B6C9E; Tue, 25 Mar 2014 00:39:36 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.admin.local (mailhub.admin.local [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id SJXCgXTV6Ztg; Tue, 25 Mar 2014 00:39:25 +0100 (CET)
Received: from ijon.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 273412B6C9A; Tue, 25 Mar 2014 00:39:24 +0100 (CET)
Date: Tue, 25 Mar 2014 00:39:25 +0100
Message-ID: <87lhvzi2tu.wl%jch@pps.univ-paris-diderot.fr>
From: Juliusz Chroboczek 
To: Brian Adamson 
In-Reply-To: <2369CDD6-126A-48BF-B68D-27920B6C64AA@nrl.navy.mil>
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org> <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com> <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr> <2369CDD6-126A-48BF-B68D-27920B6C64AA@nrl.navy.mil>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 25 Mar 2014 00:39:37 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 25 Mar 2014 00:39:37 +0100 (CET)
X-Miltered: at korolev with ID 5330C239.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5330C238.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5330C239.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 5330C238.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/
X-j-chkmail-Score: MSGID : 5330C239.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5330C238.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7hysNyGrPu_0g0BCoUGQYD9iHKo
Cc: MANET IETF 
Subject: Re: [manet] Reactive protocols in userspace
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Mar 2014 23:39:40 -0000

> I recently added a "device" command-line option to our "nrlsmf" user space
> forwarding code (http://www.nrl.navy.mil/itd/ncs/products/smf)

I see.  The default is to use BPF, right?

> that does the same sort of think you mentioned that Henning
> described to you

Henning claimed that only packets for non-established routes go
through the tun interface -- packets for established routes would
follow the more specific routes.  (I don't see how that can work in
the error case, but Henning usually knows what he's speaking about.)

I assume that your "device" option still pushes all data packets to
userspace, right?

> The approach would be for the forwarding engine (to have a control port the
> routing control plane protocol would monitor to be informed of newly detected
> "flows"

Right.

> For the case of Elastic Multicast, a default behavior...
> For something like AODV, I suppose a default behavior...

Are you putting policy in the kernel?  My choice would be to have just
one behaviour for new flows -- push the packet to userspace, which can
then perform flooding, buffering, dropping, whatever.

> When we support all this stuff, we may need to change the "smf" in
> nrlsmf to mean "sophisticated manet forwarding" ;-).

Heh.  I'm not sure it's specific to MANETs.

-- Juliusz


From nobody Mon Mar 24 18:36:21 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A4C1A004A for ; Mon, 24 Mar 2014 18:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGUiIaCwxAHP for ; Mon, 24 Mar 2014 18:36:15 -0700 (PDT)
Received: from mail3.nrl.navy.mil (scmail.nrl.navy.mil [IPv6:2001:480:20:404::465:27]) by ietfa.amsl.com (Postfix) with ESMTP id 55FCB1A0034 for ; Mon, 24 Mar 2014 18:36:15 -0700 (PDT)
Received: from [192.168.1.109] (c-76-21-150-94.hsd1.md.comcast.net [76.21.150.94]) (authenticated bits=0) by mail3.nrl.navy.mil (8.14.8/8.14.8) with ESMTP id s2P1aCER022003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Mar 2014 21:36:12 -0400
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Brian Adamson 
In-Reply-To: <87lhvzi2tu.wl%jch@pps.univ-paris-diderot.fr>
Date: Mon, 24 Mar 2014 21:36:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org> <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com> <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr> <2369CDD6-126A-48BF-B68D-27920B6C64AA@nrl.navy.mil> <87lhvzi2tu.wl%jch@pps.univ-paris-diderot.fr>
To: Juliusz Chroboczek 
X-Mailer: Apple Mail (2.1510)
X-Scanned-By: MIMEDefang 2.72
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rhAHDqXPk9x1qcQMftOO-0oU9zE
Cc: MANET IETF 
Subject: Re: [manet] Reactive protocols in userspace
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Mar 2014 01:36:18 -0000

On Mar 24, 2014, at 7:39 PM, Juliusz Chroboczek =
 wrote:

>> I recently added a "device" command-line option to our "nrlsmf" user =
space
>> forwarding code (http://www.nrl.navy.mil/itd/ncs/products/smf)
>=20
> I see.  The default is to use BPF, right?
>=20

Yes - there is an option to use IP Tables queues or BSD ipfw divert =
sockets but those aren't as flexible with regard to IPv6 support, etc.

>> that does the same sort of think you mentioned that Henning
>> described to you
>=20
> Henning claimed that only packets for non-established routes go
> through the tun interface -- packets for established routes would
> follow the more specific routes.  (I don't see how that can work in
> the error case, but Henning usually knows what he's speaking about.)
>=20
> I assume that your "device" option still pushes all data packets to
> userspace, right?

Henning's approach would have an advantage that packets that already had =
a route established would stay in the kernel. Yes - the "device" options =
pushes all data packets to userspace.

>=20
>> The approach would be for the forwarding engine (to have a control =
port the
>> routing control plane protocol would monitor to be informed of newly =
detected
>> "flows"
>=20
> Right.
>=20
>> For the case of Elastic Multicast, a default behavior...
>> For something like AODV, I suppose a default behavior...
>=20
> Are you putting policy in the kernel?  My choice would be to have just
> one behaviour for new flows -- push the packet to userspace, which can
> then perform flooding, buffering, dropping, whatever.

The idea would be to explore what makes since for the FIB.  By the time =
you have the SMF duplicate packet detection (DPD), etc in the kernel, a =
default 'policy' for new flows wouldn't be much additional complexity (I =
think!).  We looked at XORP's approach and it pushes packets for new =
flows up, but I was hoping we avoid that and just signal the existence =
of  a new flow and just send the flow parameters up (addressing, traffic =
class, protocol) =85 but it's definitely open to discuss and we haven't =
implemented it yet.  There is interest in having the SMF paradigm in a =
kernel module for performance and to integrate it properly with existing =
traffic control, queue disciplines, etc.  But it's very exploratory at =
this point.=20

>=20
>> When we support all this stuff, we may need to change the "smf" in
>> nrlsmf to mean "sophisticated manet forwarding" ;-).
>=20
> Heh.  I'm not sure it's specific to MANETs.
>=20
> -- Juliusz


From nobody Mon Mar 24 23:36:44 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1791A036F for ; Mon, 24 Mar 2014 23:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.861
X-Spam-Level: 
X-Spam-Status: No, score=-3.861 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50TPXjJHzJxr for ; Mon, 24 Mar 2014 23:36:41 -0700 (PDT)
Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id C41921A036C for ; Mon, 24 Mar 2014 23:36:40 -0700 (PDT)
Received: from rufsun5.fkie.fraunhofer.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 1WSKyU-00060m-Av for manet@ietf.org; Tue, 25 Mar 2014 07:36:38 +0100
Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WSKyU-0002w0-7O for manet@ietf.org; Tue, 25 Mar 2014 07:36:38 +0100
Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 25 Mar 2014 07:36:37 +0100
Message-ID: <533123EA.3000909@fkie.fraunhofer.de>
Date: Tue, 25 Mar 2014 07:36:26 +0100
From: Henning Rogge 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: 
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org> <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com> <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr>
In-Reply-To: <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020309030805020906020904"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.98.1/18683/Tue Mar 25 04:52:38 2014) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: 912e0972ada2ab87c171579937f55793
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3YLnd4rPP6VlEixTFpXBT2wBkU4
Subject: Re: [manet] Reactive protocols in userspace [was: draft-gerla-manetodmrp-02]
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Mar 2014 06:36:43 -0000

--------------ms020309030805020906020904
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 03/24/2014 10:10 PM, Juliusz Chroboczek wrote:
>> - I think this could be implemented in user-space, but I'm afraid
>> that having to intercept the first data packet in order to build
>> the multicast tree would require a kernel module.
>=20
> This is exactly the issue that the reactive protocol people have
> been struggling with for over a decade now, and that I mentioned in
> London during the discussion of AODVv2.
>=20
> Historically, AODV has been implemented as a kernel module, which=20
> caused no end of problems.  Recently, it has been implemented in=20
> userspace by playing tricks with tun interfaces.

Better to play tricks with a stable API to the kernel than having an
"outdated" kernel module after 12 months.

> Henning explained the trick to me as follows.  He puts a default
> route through a tun interface, which causes all unroutable packets to
> go to userspace.  He then buffers the tunnelled packets, and sets a
> more specific route whenever a route is established.  Yes, it's a
> hack, and one that only works in the absence of bona fide shorter
> prefix routes (HNAs in OLSR parlance).

It works for shorter prefix routes if you limit this prefixes to IPs
outside the AODV "main node addresses"... you just need to add a second
route for the whole "AODV node prefix" into the tun interface.

You will still have trouble with overlapping prefixes, but I don't think
there is anything you can do against this with AODV.

> (I also don't see how it handles AODV's error case, but that's a
> different issue.)

It does not.

To handle the error cases you should have a regular look at the IP
neighbor tables. If you loose a "next hop" of a route from the neighbor
table, you can mark the route as "timed out" and create a RERR.

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


--------------ms020309030805020906020904
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
Fw0xNDAzMjUwNjM2MzZaMCMGCSqGSIb3DQEJBDEWBBRoxkQyUHthGOm4JIeGBXl7kIV12jBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy
MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m
ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y
cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA
uuYwDQYJKoZIhvcNAQEBBQAEggEAeiiAh66tpQYAsHJ/xs1SOskzwAXB01v9bLhSHCjBpdQ/
8+jF13oksH8v0jzHCCA3dUNwIsqXNMXXzEoUa5ePQB7y2l/p0+r210z2EI9R646dphnuW6X9
uFixyuyLvfZxnfZUh8Vc63DV1x7tEhtxBDFqmiZUkEopgxZVheVivZt8328ktiOUr6nx4bq7
NO+zGfiloZQE1JMJxJdA7+kIXBRyrYEpVM/Sy1D230o7S3G76xTpmPxqvJBpzvvGOI0I3Cw8
nCaxxGZBUSPXlvwYgq0KlXXmHdwHh/cQY2cFD4DZwzzjwnJPPnyqKRMFSIr/ewB6krxiipRr
eJ1f3wBReQAAAAAAAA==
--------------ms020309030805020906020904--


From nobody Tue Mar 25 03:20:26 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5BB1A017B for ; Tue, 25 Mar 2014 03:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNIXSCCo_5C4 for ; Tue, 25 Mar 2014 03:19:49 -0700 (PDT)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4429B1A017C for ; Tue, 25 Mar 2014 03:19:47 -0700 (PDT)
Received: by mail-yk0-f177.google.com with SMTP id q200so563914ykb.8 for ; Tue, 25 Mar 2014 03:19:46 -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=SH6he12vDf/Bx4PGxbApNxZH9SoYlMi+bKYkM+wdhw4=; b=x+5oBgQk9tLtOmA/jIqzBwDMMsTc2pqnNkKqYJlpzeq1534t8LwOxwUuyfbmPNfve7 9XkLcecNUQxPRFO7gEFEQBm4eGIA/mesxrXSee0Jft8iXIO1YxZzi6oDLZ6IaKa+N2as yUzZrc1N1NNXNZZYTnaW740B8ttp1SyllvXQ8DJnKYvrN6FRgJMdXxGhsXjoia/OOai7 9epoJY+K2pqeJ8bOjkF8q6/CvRCQQ8Y0Vm88vXqAT+Zibsv6qKoZ7OMoey696bayInLv oK+oeClfM54ANb1UEbmzmmGIJvtjPwqKUZSKiap0IZMbeTqGVPfn89k/YNfovtlRevxM uALA==
MIME-Version: 1.0
X-Received: by 10.236.220.72 with SMTP id n68mr3415555yhp.102.1395742786070; Tue, 25 Mar 2014 03:19:46 -0700 (PDT)
Received: by 10.170.87.135 with HTTP; Tue, 25 Mar 2014 03:19:46 -0700 (PDT)
In-Reply-To: <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com>
References:   <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com>
Date: Tue, 25 Mar 2014 11:19:46 +0100
Message-ID: 
From: Abdussalam Baryun 
To: manet 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/AWssFzyrHS-1sPh4QWU3nj9JbII
Cc: "manet-chairs@tools.ietf.org" 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Mar 2014 10:19:50 -0000

I did not get chance to discuss the draft in the meeting, but the
presentation shows important motivations and support for olsrv2
deployments.

I think the draft does not answer fully the first motivation of Bonica
related to use cases of OLSRv2.

Why is the draft requiring=A0only one single management=A0parameter C for
the olsrv2=A0MANET within its=A0all use cases? I just need to make sure WG
agrees on this, or the OLSRv2 document has no other parameters to be
used as requirement.

Overall, I support the draft. Thanks

AB


From nobody Tue Mar 25 03:45:08 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438841A039A for ; Tue, 25 Mar 2014 03:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKsaNobuqrVq for ; Tue, 25 Mar 2014 03:44:38 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id C11C31A018A for ; Tue, 25 Mar 2014 03:44:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E5C481C80661; Tue, 25 Mar 2014 03:44: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 507891C80660; Tue, 25 Mar 2014 03:44:35 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Clausen 
In-Reply-To: 
Date: Tue, 25 Mar 2014 11:44:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <790C5319-08B3-43C4-A779-996F751E71D9@thomasclausen.org>
References:   <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com> 
To: Abdussalam Baryun 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kiGVO8liDEoUXAM-5wHmcvNxreA
Cc: "manet-chairs@tools.ietf.org" , manet 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Mar 2014 10:44:41 -0000

On 25 Mar 2014, at 11:19, Abdussalam Baryun  =
wrote:

> I did not get chance to discuss the draft in the meeting, but the
> presentation shows important motivations and support for olsrv2
> deployments.
>=20
> I think the draft does not answer fully the first motivation of Bonica
> related to use cases of OLSRv2.
>=20
> Why is the draft requiring only one single management parameter C for
> the olsrv2 MANET within its all use cases?

Because, if you read the OLSRv2 specification, you would notice that the =
only operational parameter (which is not a parameter, but a constant), =
which requires agreement by all OLSRv2 routers for interoperability, is =
C.

The protocol was explicitly designed to accommodate deployments with =
heterogeneity of all other parameters.=20

> I just need to make sure WG
> agrees on this, or the OLSRv2 document has no other parameters to be
> used as requirement.

As that's an artefact of the protocol, which has been approved a good =
long time ago, this is actually not something that requires agreement ;)


> Overall, I support the draft. Thanks

Thank you,

Thomas

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


From nobody Tue Mar 25 04:13:10 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799D91A01A9 for ; Tue, 25 Mar 2014 04:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj1GDCQ4OXSJ for ; Tue, 25 Mar 2014 04:12:37 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id EC72A1A0198 for ; Tue, 25 Mar 2014 04:12:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,728,1389744000";  d="scan'208,217";a="359251685"
Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 25 Mar 2014 11:12:20 +0000
From: "Dearlove, Christopher (UK)" 
X-IronPort-AV: E=Sophos; i="4.97,728,1389744000"; d="scan'208,217"; a="51530700"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 25 Mar 2014 11:12:15 +0000
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.106]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Tue, 25 Mar 2014 11:12:14 +0000
To: "Stan Ratliff (sratliff)" , Ulrich Herberg 
Thread-Topic: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
Thread-Index: AQHPR3QiPy2QLqd2YUi4idgOIG+vqJrxpvXA
Date: Tue, 25 Mar 2014 11:12:14 +0000
Message-ID: 
References:   <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com>
In-Reply-To: <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40287E89GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5dYtk5hzPg8XqLe7UHWdgx7di9w
Cc: "manet-chairs@tools.ietf.org" , "" 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Mar 2014 11:12:41 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40287E89GLKXM0002VGREEN_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

I support adoption of this document as a WG item. Work to be done on it of =
course (and yes, I know what making that comment means).

--
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 [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff (srat=
liff)
Sent: 24 March 2014 15:17
To: Ulrich Herberg
Cc: manet-chairs@tools.ietf.org; 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-s=
napshot-01?


*** WARNING ***
This message originates from outside our organisation, either from an exter=
nal partner or the internet.
Consider carefully whether you should click on any links, open any attachme=
nts or reply.
For information regarding Red Flags that you can look out for in emails you=
 receive, click here.
If you feel the email is suspicious, please follow this process.
Dear Working group participants,

This is a call for consensus on adoption of the mentioned draft. Please res=
pond no later than April 4, 2014. Lack of response will be considered as a =
vote for adoption of the document.

Regards,
stan

On Mar 23, 2014, at 10:23 PM, Ulrich Herberg > wrote:


Dear MANET chairs,
have you seen my email from March 5? Can you inform us whether you intend t=
o get a consensus call for WG adoption?
Thanks
Ulrich
---------- Forwarded message ----------
From: Ulrich Herberg >
Date: Wed, Mar 5, 2014 at 6:05 AM
Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
To: manet@ietf.org

Dear WG chairs,
as we mentioned during the MANET meeting, Thomas and I would like to reques=
t to get a consensus call on the mailing list for WG adoption of draft-clau=
sen-manet-olsrv2-management-snapshot-01.
Best regards
Ulrich

_______________________________________________
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40287E89GLKXM0002VGREEN_
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable











I support adoption of thi=
s document as a WG item. Work to be done on it of course (and yes, I know w=
hat making that comment means).


 <=
/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 [mailto:manet-bounces@ietf.org]
On Behalf Of Stan Ratliff (sratliff)

Sent: 24 March 2014 15:17

To: Ulrich Herberg

Cc: manet-chairs@tools.ietf.org; <manet@ietf.org>

Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-manag=
ement-snapshot-01?






 




 




*** WARNING ***=








This message originates from outside our organ=
isation, either from an external partner or the internet.

Co=
nsider carefully whether you should click on any links, open any attachment=
s or reply.

Fo=
r information regarding 
Red Flags that you can look out for in emails you rec=
eive,
 click 
here.

If=
 you feel the email is suspicious, please follow

this process.






Dear Working group participants,  



 






This is a call for consensus on adoption of the ment=
ioned draft. Please respond no later than April 4, 2014. Lack of response w=
ill be considered as a vote for adoption of the document. <=
/p>





 






Regards,






stan






 






On Mar 23, 2014, at 10:23 PM, Ulrich Herberg <ulrich@herberg.name> wrote:=


















Dear MANET chairs,




have you seen my emai=
l from March 5? Can you inform us whether you intend to get a consensus cal=
l for WG adoption?




Thanks

Ulrich








---------- Forwarded =
message ----------

From: Ulrich Herberg <ulri=
ch@herberg.name>

Date: Wed, Mar 5, 2014 at 6:05 AM

Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?<=
br>
To: manet@ietf.org












Dear WG chairs,<=
/o:p>




as we mentioned durin=
g the MANET meeting, Thomas and I would like to request to get a consensus =
call on the mailing list for WG adoption of draft-clausen-manet-olsrv2-mana=
gement-snapshot-01.




Best regards

Ulrich






 








_______________________________________________

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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40287E89GLKXM0002VGREEN_--


From nobody Tue Mar 25 13:25:16 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BA21A020B for ; Tue, 25 Mar 2014 13:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AHJKTg4YPuz for ; Tue, 25 Mar 2014 13:25:11 -0700 (PDT)
Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A17A91A023C for ; Tue, 25 Mar 2014 13:25:10 -0700 (PDT)
Received: by mail-qa0-f45.google.com with SMTP id hw13so1208220qab.32 for ; Tue, 25 Mar 2014 13:25: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 :cc:content-type; bh=bEke440YouqMSA1NbBZYITdTHa/bwkHwEH5o209oMKE=; b=sydJRfah7FACRAgpwnbaBRwsam8e2SMuYV5UXUWcvDV2g8l+VN4CWHVQXsKnQtwYLU q2yBKcQPvHlbyiNadkZfcCYKfvwmY/kV/TiEHA7pCpkBqqn+s72B4Eo608GF7n3x2aIl aQQybJUY1jQF0tqJPVA/d3NL2FZNXqNo+JxwKpHQofHSaa1V4sRthqPFqN1dGOZCmDuf sA0Vlbmy8JwZxtPBzBJsnhSshVRm0uBWl09A2OBNQZPMiPcV18VYe1hQZyRl4PsmNNtT kva6HIyenhbFEMQAt63etTA0OkXnKgO6IoJdfVqsCEdf555NDgUAPN+SmvihqzMcY2cj SILA==
MIME-Version: 1.0
X-Received: by 10.140.94.134 with SMTP id g6mr81843373qge.19.1395779108796; Tue, 25 Mar 2014 13:25:08 -0700 (PDT)
Received: by 10.96.156.1 with HTTP; Tue, 25 Mar 2014 13:25:08 -0700 (PDT)
In-Reply-To: 
References:   <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com> 
Date: Tue, 25 Mar 2014 16:25:08 -0400
Message-ID: 
From: James Nguyen 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=001a113a48f2f6fe1904f5742556
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gQdn32jwlt5mGs3KFO8zZlYzplY
Cc: "manet-chairs@tools.ietf.org" , "" , "Stan Ratliff \(sratliff\)" 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Mar 2014 20:25:14 -0000

--001a113a48f2f6fe1904f5742556
Content-Type: text/plain; charset=UTF-8

I find this draft helpful in how typical OLSRv2 network should
fundamentally be configured prior to deployments using management patterns
and legacy management protocols and why OLSRv2 network needs to be
managed/monitored.

I support adoption of this draft as a WG document.



On Tue, Mar 25, 2014 at 7:12 AM, Dearlove, Christopher (UK) <
Chris.Dearlove@baesystems.com> wrote:

>  I support adoption of this document as a WG item. Work to be done on it
> of course (and yes, I know what making that comment means).
>
>
>
> --
>
> 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 [mailto:manet-bounces@ietf.org] *On Behalf Of *Stan Ratliff
> (sratliff)
> *Sent:* 24 March 2014 15:17
> *To:* Ulrich Herberg
> *Cc:* manet-chairs@tools.ietf.org; 
> *Subject:* Re: [manet] WG adoption of
> draft-clausen-manet-olsrv2-management-snapshot-01?
>
>
>
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> * Consider carefully whether you should click on any links, open any
> attachments or reply. For information regarding **Red Flags** that you
> can look out for in emails you receive, click here
> .*
> * If you feel the email is suspicious, please follow this process
> .*
>
> Dear Working group participants,
>
>
>
> This is a call for consensus on adoption of the mentioned draft. Please
> respond no later than April 4, 2014. Lack of response will be considered as
> a vote for adoption of the document.
>
>
>
> Regards,
>
> stan
>
>
>
> On Mar 23, 2014, at 10:23 PM, Ulrich Herberg  wrote:
>
>
>
>   Dear MANET chairs,
>
> have you seen my email from March 5? Can you inform us whether you intend
> to get a consensus call for WG adoption?
>
> Thanks
> Ulrich
>
> ---------- Forwarded message ----------
> From: *Ulrich Herberg* 
> Date: Wed, Mar 5, 2014 at 6:05 AM
> Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
> To: manet@ietf.org
>
>   Dear WG chairs,
>
> as we mentioned during the MANET meeting, Thomas and I would like to
> request to get a consensus call on the mailing list for WG adoption of
> draft-clausen-manet-olsrv2-management-snapshot-01.
>
> Best regards
> Ulrich
>
>
>
> _______________________________________________
> 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
>
>


-- 
James Nguyen
Email: james.huy.nguyen@gmail.com

--001a113a48f2f6fe1904f5742556
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I find this draft helpful in how typical OLSRv2 netwo=
rk should fundamentally be configured prior to deployments using management=
 patterns and legacy management protocols and why OLSRv2 network needs to b=
e managed/monitored.


I support adoption of this draft as a WG document.

<=
div class=3D"gmail_extra">

On Tue, Mar 25=
, 2014 at 7:12 AM, Dearlove, Christopher (UK) <Chris.Dearlove@=
baesystems.com> wrote:













I support adoption of thi=
s document as a WG item. Work to be done on it of course (and yes, I know w=
hat making that comment means).



=C2=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=C2=A0|=C2=A0 Fax: +44 1245 242124<=
u>



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




=C2=A0






From: manet [mailto:manet-bounces@ietf.org]
On Behalf Of Stan Ratliff (sratliff)

Sent: 24 March 2014 15:17

To: Ulrich Herberg

Cc: manet-chairs@tools.ietf.org; <manet@ietf.org>

Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-manag=
ement-snapshot-01?






=C2=A0




=C2=A0




*** WARNING ***








This message originates from outside our organ=
isation, either from an external partner or the internet.


Co=
nsider carefully whether you should click on any links, open any attachment=
s or reply.

Fo=
r information regarding 
Red Flags that you can look out for in emails you rec=
eive,
 click 
here.

If=
 you feel the email is suspicious, please follow

this process.=







Dear Working group participants,=C2=A0 




=C2=A0






This is a call for consensus on adoption of the ment=
ioned draft. Please respond no later than April 4, 2014. Lack of response w=
ill be considered as a vote for adoption of the document.=C2=A0







=C2=A0






Regards,






stan






=C2=A0






On Mar 23, 2014, at 10:23 PM, Ulrich Herberg <ulrich@herberg.name> wrote:

















Dear MANET chairs,=





have you seen my emai=
l from March 5? Can you inform us whether you intend to get a consensus cal=
l for WG adoption?




Thanks

Ulrich








---------- Forwarded =
message ----------

From: Ulrich Herberg <ulrich@herberg.name>

Date: Wed, Mar 5, 2014 at 6:05 AM

Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?<=
br>
To: manet@ietf.org<=
br>











Dear WG chairs,




as we mentioned durin=
g the MANET meeting, Thomas and I would like to request to get a consensus =
call on the mailing list for WG adoption of draft-clausen-manet-olsrv2-mana=
gement-snapshot-01.





Best regards

Ulrich






=C2=A0








_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet




=C2=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.

********************************************************************



_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet





-- 
James Nguyen
Ema=
il: james.huy.nguyen@gmail.co=
m



--001a113a48f2f6fe1904f5742556--


From nobody Tue Mar 25 13:32:17 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F311A0212 for ; Tue, 25 Mar 2014 13:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFbTbpx4Or9h for ; Tue, 25 Mar 2014 13:32:14 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 10A761A00BE for ; Tue, 25 Mar 2014 13:32:13 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id w61so698007wes.18 for ; Tue, 25 Mar 2014 13:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4W0a/Ea8Qu3aCW9uveWfE3PY7sCiGLAi8SBbXHUO3mM=; b=0nPOq2maIARKSvCbtkS60SCEkDvpQQKfzt351hiu39Qv3I0X31IzdbNvgPoHrbjyjZ ebK9E0leHzbPj8K4fQF5Tb8dpTVUPDWBcg470cbeJVhUBDXgIKYPJ1eUkeIOPoawuYTR AmF8ONVapGvu2wBnvr1h8ML3noDS1IMmIHXVellENC5T4g1vRgr5LoFxXIqtN9CUdq3x XJVREDh+7VjvpICbC0uNU0mqE5d7YUG6cnRZOVcADKgRkMBFBb5lpCbY2a+KI9NOFKks KNnrAS96C/myLpwhhXPzPK3QHFbqPgqqgzPSQfXmZJTJlvM1tD9LB+mJPofeZv4Q1w5G QkIg==
MIME-Version: 1.0
X-Received: by 10.180.85.234 with SMTP id k10mr26058682wiz.32.1395779532395; Tue, 25 Mar 2014 13:32:12 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.217.37.133 with HTTP; Tue, 25 Mar 2014 13:32:12 -0700 (PDT)
In-Reply-To: <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com>
References:   <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com>
Date: Tue, 25 Mar 2014 21:32:12 +0100
X-Google-Sender-Auth: 3PuHsVMO2FN5U-Jhcbyh46kt6ww
Message-ID: 
From: Jiazi YI 
To: "Stan Ratliff (sratliff)" 
Content-Type: multipart/alternative; boundary=f46d044473bd369a3104f5743f51
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ExK9PFds4ME4JZbCXhqBC4KzoFQ
Cc: "manet-chairs@tools.ietf.org" , "" 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Mar 2014 20:32:16 -0000

--f46d044473bd369a3104f5743f51
Content-Type: text/plain; charset=ISO-8859-1

+1 for WG adoption.

Jiazi


On Mon, Mar 24, 2014 at 4:17 PM, Stan Ratliff (sratliff)  wrote:

>  Dear Working group participants,
>
>  This is a call for consensus on adoption of the mentioned draft. Please
> respond no later than April 4, 2014. Lack of response will be considered as
> a vote for adoption of the document.
>
>  Regards,
> stan
>
>  On Mar 23, 2014, at 10:23 PM, Ulrich Herberg  wrote:
>
>   Dear MANET chairs,
>
>  have you seen my email from March 5? Can you inform us whether you intend
> to get a consensus call for WG adoption?
>
>  Thanks
> Ulrich
>
>  ---------- Forwarded message ----------
> From: Ulrich Herberg 
> Date: Wed, Mar 5, 2014 at 6:05 AM
> Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?
> To: manet@ietf.org
>
>
>  Dear WG chairs,
>
>  as we mentioned during the MANET meeting, Thomas and I would like to
> request to get a consensus call on the mailing list for WG adoption of
> draft-clausen-manet-olsrv2-management-snapshot-01.
>
>  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
>
>

--f46d044473bd369a3104f5743f51
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


+1 for WG adoption.

Jiazi


On Mon, Mar 24,=
 2014 at 4:17 PM, Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:








Dear Working group participants,=A0






This is a call for consensus on adoption of the mentioned draft. Pleas=
e respond no later than April 4, 2014. Lack of response will be considered =
as a vote for adoption of the document.=A0







Regards,


stan







On Mar 23, 2014, at 10:23 PM, Ulrich Herberg <ulrich@herberg.name> wrote:









Dear MANET chairs,





have you seen my email from March 5? Can you inform us whether you intend t=
o get a consensus call for WG adoption?





Thanks

Ulrich








---------- Forwarded message ----------

From: Ulrich Herberg &l=
t;ulrich@herberg.n=
ame>

Date: Wed, Mar 5, 2014 at 6:05 AM

Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01?<=
br>
To: manet@ietf.org<=
br>









Dear WG chairs,





as we mentioned during the MANET meeting, Thomas and I would like to reques=
t to get a consensus call on the mailing list for WG adoption of draft-clau=
sen-manet-olsrv2-management-snapshot-01.





Best regards

Ulrich













_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet













_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/manet





--f46d044473bd369a3104f5743f51--


From nobody Wed Mar 26 08:40:38 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0711A036E; Wed, 26 Mar 2014 08:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CddKBySdk3i6; Wed, 26 Mar 2014 08:40:33 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 739FC1A0364; Wed, 26 Mar 2014 08:40:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140326154033.21439.5955.idtracker@ietfa.amsl.com>
Date: Wed, 26 Mar 2014 08:40:33 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/nU6rR8f0YrFqSdzcnD0LNiPkX2I
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-00.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Mar 2014 15:40:35 -0000

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           : Packet Sequence Number based directional airtime metric for OLSRv2
        Authors         : Henning Rogge
                          Emmanuel Baccelli
	Filename        : draft-ietf-manet-olsrv2-dat-metric-00.txt
	Pages           : 16
	Date            : 2014-03-26

Abstract:
   This document specifies an directional airtime link metric for usage
   in OLSRv2.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-dat-metric/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Wed Mar 26 11:34:48 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B63A1A0354 for ; Wed, 26 Mar 2014 11:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y72VCVCISo3C for ; Wed, 26 Mar 2014 11:34:37 -0700 (PDT)
Received: from ucol19pa09.eemsg.mail.mil (ucol19pa09.eemsg.mail.mil [214.24.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id CA5D41A01F3 for ; Wed, 26 Mar 2014 11:34:36 -0700 (PDT)
Received: from edge-cols.mail.mil ([131.64.100.11]) by ucol19pa09.eemsg.mail.mil with ESMTP; 26 Mar 2014 18:34:28 +0000
Received: from UCOLHP3G.easf.csd.disa.mil (131.64.100.146) by edge-cols.mail.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 26 Mar 2014 18:33:51 +0000
Received: from UCOLHP9D.easf.csd.disa.mil ([169.254.2.236]) by UCOLHP3G.easf.csd.disa.mil ([131.64.100.146]) with mapi id 14.03.0174.001; Wed, 26 Mar 2014 18:33:51 +0000
From: "Cole, Robert G CIV USARMY CERDEC (US)" 
To: "Stan Ratliff (sratliff)" 
Thread-Topic: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01? (UNCLASSIFIED)
Thread-Index: AQHPSSHvYM1/Vk5O4UKdArDgDd7KQA==
Date: Wed, 26 Mar 2014 18:33:51 +0000
Message-ID: 
References:   <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.64.201.78]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lbfrTPfZzSbCajyoSAliA3XGGR0
Cc: "manet-chairs@tools.ietf.org" , "" 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01? (UNCLASSIFIED)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Mar 2014 18:34:39 -0000

Classification: UNCLASSIFIED
Caveats: NONE

I agree that this draft should be adopted by the WG.

Thx, Bob

US Army CERDEC
QUEST Program, S&TCD
APG, MD

(c) 443.910.4420
(o) 443.395.8744
robert.g.cole@us.army.mil


-----Original Message-----
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi YI
Sent: Tuesday, March 25, 2014 4:32 PM
To: Stan Ratliff (sratliff)
Cc: manet-chairs@tools.ietf.org; 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-s=
napshot-01?

+1 for WG adoption.

Jiazi


On Mon, Mar 24, 2014 at 4:17 PM, Stan Ratliff (sratliff)  wrote:


	Dear Working group participants, =20

	This is a call for consensus on adoption of the mentioned draft. Please re=
spond no later than April 4, 2014. Lack of response will be considered as a=
 vote for adoption of the document.=20

	Regards,
	stan

	On Mar 23, 2014, at 10:23 PM, Ulrich Herberg  wrote:


		Dear MANET chairs,
	=09
	=09
		have you seen my email from March 5? Can you inform us whether you intend=
 to get a consensus call for WG adoption?
	=09
	=09
		Thanks
		Ulrich
	=09
	=09
		---------- Forwarded message ----------
		From: Ulrich Herberg 
		Date: Wed, Mar 5, 2014 at 6:05 AM
		Subject: WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01=
?
		To: manet@ietf.org
	=09
	=09
	=09
		Dear WG chairs,
	=09
	=09
		as we mentioned during the MANET meeting, Thomas and I would like to requ=
est to get a consensus call on the mailing list for WG adoption of draft-cl=
ausen-manet-olsrv2-management-snapshot-01.
	=09
	=09
		Best regards
		Ulrich
	=09

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



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



Classification: UNCLASSIFIED
Caveats: NONE



From nobody Wed Mar 26 16:25:27 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA451A03F9 for ; Wed, 26 Mar 2014 16:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAmGs6tx0itH for ; Wed, 26 Mar 2014 16:25:24 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 672421A024D for ; Wed, 26 Mar 2014 16:25:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2C609240343; Wed, 26 Mar 2014 16:25:23 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.1.47] (cha75-1-78-192-0-189.fbxo.proxad.net [78.192.0.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 5E9312407AE; Wed, 26 Mar 2014 16:25:19 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DAF52553-6E45-445C-A106-1005228E4833"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= 
In-Reply-To: 
Date: Thu, 27 Mar 2014 00:25:16 +0100
Message-Id: 
References:   <7A7416CC-AEC1-4FC7-91E2-CD63494D0D89@cisco.com>  
To: "Cole, Robert G CIV USARMY CERDEC (US)" 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ha0LLlhdzAq3roh-6u7IDl4AVfw
Cc: "manet-chairs@tools.ietf.org" , "" , "Stan Ratliff \(sratliff\)" 
Subject: Re: [manet] WG adoption of draft-clausen-manet-olsrv2-management-snapshot-01? (UNCLASSIFIED)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Mar 2014 23:25:26 -0000

--Apple-Mail=_DAF52553-6E45-445C-A106-1005228E4833
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

I also support adoption of this document by the WG.

Best,

Axel

Le 26 mars 2014 =E0 19:33, Cole, Robert G CIV USARMY CERDEC (US) =
 a =E9crit :

> Classification: UNCLASSIFIED
> Caveats: NONE
>=20
> I agree that this draft should be adopted by the WG.
>=20
> Thx, Bob
>=20
> US Army CERDEC
> QUEST Program, S&TCD
> APG, MD
>=20
> (c) 443.910.4420
> (o) 443.395.8744
> robert.g.cole@us.army.mil
>=20
>=20
> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi YI
> Sent: Tuesday, March 25, 2014 4:32 PM
> To: Stan Ratliff (sratliff)
> Cc: manet-chairs@tools.ietf.org; 
> Subject: Re: [manet] WG adoption of =
draft-clausen-manet-olsrv2-management-snapshot-01?
>=20
> +1 for WG adoption.
>=20
> Jiazi
>=20
>=20
> On Mon, Mar 24, 2014 at 4:17 PM, Stan Ratliff (sratliff) =
 wrote:
>=20
>=20
> 	Dear Working group participants, =20
>=20
> 	This is a call for consensus on adoption of the mentioned draft. =
Please respond no later than April 4, 2014. Lack of response will be =
considered as a vote for adoption of the document.=20
>=20
> 	Regards,
> 	stan
>=20
> 	On Mar 23, 2014, at 10:23 PM, Ulrich Herberg =
 wrote:
>=20
>=20
> 		Dear MANET chairs,
> 	=09
> 	=09
> 		have you seen my email from March 5? Can you inform us =
whether you intend to get a consensus call for WG adoption?
> 	=09
> 	=09
> 		Thanks
> 		Ulrich
> 	=09
> 	=09
> 		---------- Forwarded message ----------
> 		From: Ulrich Herberg 
> 		Date: Wed, Mar 5, 2014 at 6:05 AM
> 		Subject: WG adoption of =
draft-clausen-manet-olsrv2-management-snapshot-01?
> 		To: manet@ietf.org
> 	=09
> 	=09
> 	=09
> 		Dear WG chairs,
> 	=09
> 	=09
> 		as we mentioned during the MANET meeting, Thomas and I =
would like to request to get a consensus call on the mailing list for WG =
adoption of draft-clausen-manet-olsrv2-management-snapshot-01.
> 	=09
> 	=09
> 		Best regards
> 		Ulrich
> 	=09
>=20
> 		_______________________________________________
> 		manet mailing list
> 		manet@ietf.org
> 		https://www.ietf.org/mailman/listinfo/manet =
=20
> 	=09
>=20
>=20
>=20
> 	_______________________________________________
> 	manet mailing list
> 	manet@ietf.org
> 	https://www.ietf.org/mailman/listinfo/manet =
=20
> =09
> =09
>=20
>=20
>=20
> Classification: UNCLASSIFIED
> Caveats: NONE
>=20
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


--Apple-Mail=_DAF52553-6E45-445C-A106-1005228E4833
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

I also =
support adoption of this document by the =
WG.

Best,

Axel

<=
div>
Le 26 mars 2014 =E0 19:33, Cole, Robert G CIV USARMY CERDEC =
(US) <robert.g.cole.civ@mail.mil&=
gt; a =E9crit :

Classification: =
UNCLASSIFIED
Caveats: NONE

I agree that this draft should be =
adopted by the WG.

Thx, Bob

US Army CERDEC
QUEST =
Program, S&TCD
APG, MD

(c) 443.910.4420
(o) =
443.395.8744
robert.g.cole@us.army.mil

-----Original Message-----
From: manet [mailto:manet-bounces@ietf.org] =
On Behalf Of Jiazi YI
Sent: Tuesday, March 25, 2014 4:32 PM
To: =
Stan Ratliff (sratliff)
Cc: manet-chairs@tools.ietf.org; <manet@ietf.org>
Subject: Re: =
[manet] WG adoption of =
draft-clausen-manet-olsrv2-management-snapshot-01?

+1 for WG =
adoption.

Jiazi


On Mon, Mar 24, 2014 at 4:17 PM, Stan =
Ratliff (sratliff) <sratliff@cisco.com> =
wrote:


	Dear Working group participants,  

	This is a =
call for consensus on adoption of the mentioned draft. Please respond no =
later than April 4, 2014. Lack of response will be considered as a vote =
for adoption of the document. 

	=
Regards,
	stan

	On Mar 23, 2014, at 10:23 PM, =
Ulrich Herberg <ulrich@herberg.name> =
wrote:


		Dear MANET chairs,
		
		
		have you seen my email from March =
5? Can you inform us whether you intend to get a consensus call for WG =
adoption?
	=
	=

	=
	=

	=
	=
Thanks
		Ulrich
		
		
		---------- Forwarded message =
----------
		From: Ulrich Herberg <ulrich@herberg.name>
		Date: =
Wed, Mar 5, 2014 at 6:05 AM
		Subject: WG adoption of =
draft-clausen-manet-olsrv2-management-snapshot-01?
		To: manet@ietf.org
		
		
		
		Dear WG =
chairs,
	=
	=

	=
	=

	=
	=
as we mentioned during the MANET meeting, Thomas and I would like =
to request to get a consensus call on the mailing list for WG adoption =
of draft-clausen-manet-olsrv2-management-snapshot-01.
		
		
		Best =
regards
	=
	=
Ulrich
		

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




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




Classification: UNCLASSIFIED
Caveats: =
NONE


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

=

--Apple-Mail=_DAF52553-6E45-445C-A106-1005228E4833--


From nobody Thu Mar 27 12:12:11 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DDC1A0333 for ; Thu, 27 Mar 2014 12:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 921Y13eW-iVB for ; Thu, 27 Mar 2014 12:12:02 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB141A078C for ; Thu, 27 Mar 2014 12:11:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C6E341CE2CD4; Thu, 27 Mar 2014 12:11: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 B99751CE2C9C; Thu, 27 Mar 2014 12:11:55 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Clausen 
In-Reply-To: <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr>
Date: Thu, 27 Mar 2014 20:11:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <66E0ECBA-2CA5-4746-AFC2-1420C657F723@thomasclausen.org>
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org> <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com> <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr>
To: Juliusz Chroboczek 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Jag2EuQAD-tbQ9gZh-eLDqJtTz8
Cc: MANET IETF 
Subject: Re: [manet] Reactive protocols in userspace [was: draft-gerla-manetodmrp-02]
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Mar 2014 19:12:04 -0000

On 24 Mar 2014, at 22:10, Juliusz Chroboczek =
 wrote:

>> - I think this could be implemented in user-space, but I'm afraid =
that having
>> to intercept the first data packet in order to build the multicast =
tree would
>> require a kernel module.
>=20
> This is exactly the issue that the reactive protocol people have been
> struggling with for over a decade now, and that I mentioned in London
> during the discussion of AODVv2.
>=20
> Historically, AODV has been implemented as a kernel module, which
> caused no end of problems.  Recently, it has been implemented in
> userspace by playing tricks with tun interfaces.
>=20
> Henning explained the trick to me as follows.  He puts a default route
> through a tun interface, which causes all unroutable packets to go to
> userspace.  He then buffers the tunnelled packets, and sets a more
> specific route whenever a route is established.  Yes, it's a hack, and
> one that only works in the absence of bona fide shorter prefix routes
> (HNAs in OLSR parlance).  (I also don't see how it handles AODV's
> error case, but that's a different issue.)
>=20
> As you rightly note, and as I mentioned at the London meeting, the
> proper approach would be to have a callback to userspace for the first
> packets of a new flow (as well as for the error case).  There is some
> precedent for that, the "ARP daemon" interface, which allows
> implementing the ARP cache (a degenerate reactive protocol) in
> userspace.  See CONFIG_ARPD in your kernel configuration docs.
>=20
> It would be an interesting research project to design and implement
> a minimal, stable API that allows implementing both AODVv2 and ODMRP
> entirely in userspace.  Actually, it's more than that -- it's the only
> way to save AODVv2.

I am not disagreeing with you here, the ability to make user-space =
implementations (without tun/tap hacks - which do not solve everything, =
as you point out) is hugely beneficial. You've seen how OLSR(v2) is =
designed for exactly that, so we definitely are on the same page on =
this. Implementability should be a key consideration for any protocol =
designer and specification writer.

I would suggest, though, that we be careful not to mix up reactive =
routing protocol issues with what concerns ODMRP, as I believe that they =
are very different in nature (technically, procedurally, and =
politically).

The technical difference:
	1) 	There's something inherently "on demand" in the =
"subscribe to a multicast group,=20
		have an overlay constructed which includes you". You get =
IGMP/MLD signals sent on the
		segment between a host and a router, which the router =
"does something with", including
		getting multicast routing tables set up. I believe that =
ODMRP tries to tap into this, and=20
		then that the overlay is constructed (and maintained) =
proactively. I do not think that there's=20
		anything (in an implementation of) ODMRP that would =
necessitate data traffic transiting=20
		user-space: contrary to a reactive unicast routing =
protocol, joining of a group is not data
		triggered, but triggered by an explicit application =
action (API call).

The procedural difference:
	2)	ODMRP Is very explicit about being exactly an =
experiment, by way of aiming for publication
		as an experimental RFC. I believe that what we're in the =
process of discussing here is
		exactly the experiments that we would like to have =
happen -- which include "is there a
		way in which this can be implemented without resorting =
to "hacks" and without requiring
		kernel-space coding? (My inkling is "yes, possibly with =
some constraints, once a stable
		spec is out there, I might set forth coding stuff to =
figure it out")
	=09
		(The reactive unicast routing protocol, on the other =
hand, aims for publication on std. track
		  -- for which the bar of "running code" and "known =
implementability" should be much higher,
		  and such issues expected to be uncovered, documented =
and addressed by way of=20
		  also documented solutions -- themselves with =
documented limitations, validated by way of=20
		  running interoperable code.)

I'd like to ask the ODMRP authors if this sort of stuff is part of what =
they're writing up as part of "The Experiment" section for this =
document? It would seem to me that it should be, and that an =
"implementabiity experiment" is a quite viable sub-reason for an =
experimental RFC to be published?

Cheers,

Thomas




From nobody Thu Mar 27 13:15:57 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D973E1A0379 for ; Thu, 27 Mar 2014 13:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BlKOCu5xU3O for ; Thu, 27 Mar 2014 13:15:44 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5A61A0758 for ; Thu, 27 Mar 2014 13:15:40 -0700 (PDT)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s2RKFb6M016580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Mar 2014 21:15:37 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s2RKFa4r015490; Thu, 27 Mar 2014 21:15:37 +0100
Received: from mailhub.admin.local (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A41FD2B7312; Thu, 27 Mar 2014 21:15:36 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.admin.local (mailhub.admin.local [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id zr9lBd-Go4Zn; Thu, 27 Mar 2014 21:15:35 +0100 (CET)
Received: from ijon.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0DBE92B730E; Thu, 27 Mar 2014 21:15:32 +0100 (CET)
Date: Thu, 27 Mar 2014 21:15:31 +0100
Message-ID: <87k3bfflek.wl%jch@pps.univ-paris-diderot.fr>
From: Juliusz Chroboczek 
To: Thomas Clausen 
In-Reply-To: <66E0ECBA-2CA5-4746-AFC2-1420C657F723@thomasclausen.org>
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org> <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com> <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr> <66E0ECBA-2CA5-4746-AFC2-1420C657F723@thomasclausen.org>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 27 Mar 2014 21:15:37 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 27 Mar 2014 21:15:37 +0100 (CET)
X-Miltered: at korolev with ID 533486E9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 533486E8.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 533486E9.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 533486E8.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/
X-j-chkmail-Score: MSGID : 533486E9.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 533486E8.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PeIZRDutVn6tzBU0lssSSJTMzbE
Cc: MANET IETF 
Subject: Re: [manet] Reactive protocols in userspace [was: draft-gerla-manetodmrp-02]
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Mar 2014 20:15:46 -0000

> Implementability should be a key consideration for any protocol
> designer and specification writer.

Nicely put.

> I would suggest, though, that we be careful not to mix up reactive
> routing protocol issues with what concerns ODMRP, as I believe that
> they are very different in nature (technically, procedurally, and
> politically).

=46rom the technical point of view, I'd really like to see an API emerge
that solves both problems.  Perhaps that's wishful thinking.

> ODMRP Is very explicit about being exactly an experiment, by way of
> aiming for publication as an experimental RFC. [...] The reactive
> unicast routing protocol, on the other hand, aims for publication on
> std. track -- for which the bar of "running code" and "known
> implementability" should be much higher,

Fully agree.

-- Juliusz


From nobody Thu Mar 27 13:41:24 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD50E1A01F9 for ; Thu, 27 Mar 2014 13:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb01_JzXP94B for ; Thu, 27 Mar 2014 13:41:22 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id AD1DA1A01DC for ; Thu, 27 Mar 2014 13:41:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1DBD62403C5; Thu, 27 Mar 2014 13:41:20 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.142] (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 maila2.tigertech.net (Postfix) with ESMTPSA id 95C002401CA; Thu, 27 Mar 2014 13:41:19 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (11D167)
In-Reply-To: <87k3bfflek.wl%jch@pps.univ-paris-diderot.fr>
Date: Thu, 27 Mar 2014 21:41:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F1820DB-0ED2-4894-BB9D-4E06CBEB9802@thomasclausen.org>
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org> <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com> <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr> <66E0ECBA-2CA5-4746-AFC2-1420C657F723@thomasclausen.org> <87k3bfflek.wl%jch@pps.univ-paris-diderot.fr>
To: Juliusz Chroboczek 
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/b2QBTaTWSMbht_8uXhFPACdBWPQ
Cc: MANET IETF 
Subject: Re: [manet] Reactive protocols in userspace [was: draft-gerla-manetodmrp-02]
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Mar 2014 20:41:24 -0000

On 27 mars 2014, at 21:15, Juliusz Chroboczek  wrote:

>> Implementability should be a key consideration for any protocol
>> designer and specification writer.
>=20
> Nicely put.
>=20

Thank you.

>> I would suggest, though, that we be careful not to mix up reactive
>> routing protocol issues with what concerns ODMRP, as I believe that
>> they are very different in nature (technically, procedurally, and
>> politically).
>=20
> =46rom the technical point of view, I'd really like to see an API emerge
> that solves both problems.  Perhaps that's wishful thinking.

Everything is possible in an API. I would like to see an approach emerge tha=
t does not require me to go lobby Apple and MS to change their systems.....'=
cus they probably won't.=20

>=20
>> ODMRP Is very explicit about being exactly an experiment, by way of
>> aiming for publication as an experimental RFC. [...] The reactive
>> unicast routing protocol, on the other hand, aims for publication on
>> std. track -- for which the bar of "running code" and "known
>> implementability" should be much higher,
>=20
> Fully agree.

Seems that we are in violent agreement here, this will be a really short fig=
ht.....

Thomas

> -- Juliusz
>=20


From nobody Thu Mar 27 23:33:22 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5A91A07EC for ; Thu, 27 Mar 2014 23:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgOT_7KysaZG for ; Thu, 27 Mar 2014 23:33:17 -0700 (PDT)
Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEEB1A0462 for ; Thu, 27 Mar 2014 23:33:17 -0700 (PDT)
Received: by mail-qa0-f45.google.com with SMTP id hw13so4764134qab.4 for ; Thu, 27 Mar 2014 23:33:15 -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=gCLgFKanZaiEpBbG/C4dnGR/Z2EMr25yDQ5oMsb9tvo=; b=K4sWrHZPQDHzIKMWJummqThM01+Qn4g0/73AiWxZqtYMIUcozeJSsSqHnM8zjih3Xt OmE5TmxNrRzi/2tvc1PQw/pagAeZgfJQa26iPpm7efQa2o6GpC/OD7H7GT23TbQInZlj vvmsNe17cgeYYNdXGgK+u3gEXIwc6t/03c09iF4UQBG25kh9DS1MBAiW/psdA7sqBkU4 iOlN+ppDCv8TsQH2PQ2nRNckluVqzyd3Ssi8gemO9oRaNZznndRqZvqvF10I7z30XUS7 rTTFVXjEkMSIyRe5RdOcXpPELp7UGb9JwR1sEr6lgaerFUW1AQyQkE+ICM7TiVW4PFs1 lTEw==
X-Received: by 10.224.165.1 with SMTP id g1mr167851qay.16.1395988395085; Thu, 27 Mar 2014 23:33:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.120.66 with HTTP; Thu, 27 Mar 2014 23:32:55 -0700 (PDT)
In-Reply-To: <87k3bfflek.wl%jch@pps.univ-paris-diderot.fr>
References: <6D8D7CD9-FFAE-4259-B743-076F8D3AD287@thomasclausen.org>  <362ADAB1-2163-4181-B660-31E9C981152F@thomasclausen.org> <51BAC108-8607-49B7-9C1B-241D2F3A74E0@axelcdv.com> <87pplbi9qd.wl%jch@pps.univ-paris-diderot.fr> <66E0ECBA-2CA5-4746-AFC2-1420C657F723@thomasclausen.org> <87k3bfflek.wl%jch@pps.univ-paris-diderot.fr>
From: Henning Rogge 
Date: Fri, 28 Mar 2014 07:32:55 +0100
Message-ID: 
To: Juliusz Chroboczek 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/i5kdnHlT8BLPSKwig2BP7U9Oq1s
Cc: MANET IETF 
Subject: Re: [manet] Reactive protocols in userspace [was: draft-gerla-manetodmrp-02]
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Mar 2014 06:33:19 -0000

On Thu, Mar 27, 2014 at 9:15 PM, Juliusz Chroboczek
 wrote:
>> I would suggest, though, that we be careful not to mix up reactive
>> routing protocol issues with what concerns ODMRP, as I believe that
>> they are very different in nature (technically, procedurally, and
>> politically).
>
> From the technical point of view, I'd really like to see an API emerge
> that solves both problems.  Perhaps that's wishful thinking.

We have yet to see a kernel API for multicast forwarding in MANET...
or maybe it is there, but nearly undocumented.

Henning Rogge


From nobody Fri Mar 28 17:48:08 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D1B1A0715 for ; Fri, 28 Mar 2014 17:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYwuFnGqy3Oj for ; Fri, 28 Mar 2014 17:48:04 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB311A0401 for ; Fri, 28 Mar 2014 17:48:04 -0700 (PDT)
Received: from localhost ([127.0.0.1]:32945 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WThRI-0005t7-BH; Sat, 29 Mar 2014 01:48:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "manet issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: charliep@computer.org
X-Trac-Project: manet
Date: Sat, 29 Mar 2014 00:48:00 -0000
X-URL: http://tools.ietf.org/manet/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/19
Message-ID: <061.041f85b1a5a5f5cb4aab0f33174bca16@trac.tools.ietf.org>
X-Trac-Ticket-ID: 19
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
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9Rmig6CK0Q46r0xcCTQKPNCH-QA
Cc: manet@ietf.org
Subject: [manet]  #19 (aodvv2): Use of square brackets
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 29 Mar 2014 00:48:06 -0000

#19: Use of square brackets

 I am confused by the use of square brackets around stuff: usually, [FOO]
 refers to a reference in the References section, but this is not
 systematically the case in this document (both in the prose and in the
 notation (cf. Table 1).

-- 
-----------------------------------+-----------------------------------
 Reporter:  charliep@computer.org  |      Owner:  charliep@computer.org
     Type:  task                   |     Status:  new
 Priority:  minor                  |  Milestone:
Component:  aodvv2                 |    Version:
 Severity:  Active WG Document     |   Keywords:  notation
-----------------------------------+-----------------------------------

Ticket URL: 
manet 


From nobody Fri Mar 28 17:50:15 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D561A0722 for ; Fri, 28 Mar 2014 17:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZcXgwPhcgOf for ; Fri, 28 Mar 2014 17:50:12 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 24BA11A0721 for ; Fri, 28 Mar 2014 17:50:12 -0700 (PDT)
Received: from localhost ([127.0.0.1]:32991 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WThTN-0003Ar-Bv; Sat, 29 Mar 2014 01:50:09 +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.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: charliep@computer.org
X-Trac-Project: manet
Date: Sat, 29 Mar 2014 00:50:09 -0000
X-URL: http://tools.ietf.org/manet/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/20
Message-ID: <061.38a7788f3dfe934d4b40ca8d7fd57c11@trac.tools.ietf.org>
X-Trac-Ticket-ID: 20
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
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bkoCXv_yWDs61tREoX-G4BRCsOM
Cc: manet@ietf.org
Subject: [manet] #20 (aodvv2): Idle routes must be marked as active after re-use
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 29 Mar 2014 00:50:13 -0000

#20: Idle routes must be marked as active after re-use

 The draft states how Idle routes should be treated and how a route becomes
 Idle and when an Idle route expires. What's confusing to me is that it
 states that an Idle route may still be used for packet forwarding, but it
 doesn't say that a route becomes un-Idle (i.e. Active) when it is used
 (for forwarding)– which would make sense to me.

-- 
-----------------------------------+-----------------------------------
 Reporter:  charliep@computer.org  |      Owner:  charliep@computer.org
     Type:  defect                 |     Status:  new
 Priority:  minor                  |  Milestone:
Component:  aodvv2                 |    Version:
 Severity:  Active WG Document     |   Keywords:  idle route
-----------------------------------+-----------------------------------

Ticket URL: 
manet 


From nobody Fri Mar 28 18:02:21 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA221A073B for ; Fri, 28 Mar 2014 18:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86HnGLtMqr5Z for ; Fri, 28 Mar 2014 18:02: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 098C61A0722 for ; Fri, 28 Mar 2014 18:02:18 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WThf5-0005zY-6z for manet@ietf.org; Fri, 28 Mar 2014 21:02:15 -0400
Message-ID: <53361B95.3030504@computer.org>
Date: Fri, 28 Mar 2014 18:02:13 -0700
From: "Charles E. Perkins" 
Organization: Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: manet@ietf.org
References: <061.041f85b1a5a5f5cb4aab0f33174bca16@trac.tools.ietf.org>
In-Reply-To: <061.041f85b1a5a5f5cb4aab0f33174bca16@trac.tools.ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad869ac0e24ecca101f52b8e1df4772fc677350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0METm8t7BCwOGaVd_e_-FFFO-1M
Subject: Re: [manet] #19 (aodvv2): Use of square brackets
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Mar 2014 01:02:19 -0000

Hello folks,

A number of issues have been raised in recent discussion about the
AODVv2 specification document.  I will be reformulating those for
inclusion on the [manet] issue tracker and then begin discussion
towards resolution of the issues.

On 3/28/2014 5:48 PM, manet issue tracker wrote:
> #19: Use of square brackets
>
>   I am confused by the use of square brackets around stuff: usually, [FOO]
>   refers to a reference in the References section, but this is not
>   systematically the case in this document (both in the prose and in the
>   notation (cf. Table 1).
>

-- 
Regards,
Charlie P.


From nobody Sat Mar 29 05:14:18 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD0D1A04B9 for ; Sat, 29 Mar 2014 05:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOxumThJKLBV for ; Sat, 29 Mar 2014 05:14:14 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 63DB51A04AE for ; Sat, 29 Mar 2014 05:14:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4563224129B; Sat, 29 Mar 2014 05:14:12 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.142] (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 maila2.tigertech.net (Postfix) with ESMTPSA id 76A9E240F13; Sat, 29 Mar 2014 05:14:11 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-5D66FD61-73CD-48AA-9868-3A2A0A3D461E
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (11D167)
In-Reply-To: <680DC4B8-52F7-49B6-BB04-B82F0138CAF0@thomasclausen.org>
Date: Sat, 29 Mar 2014 13:14:09 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <5317012F.60701@computer.org>    <680DC4B8-52F7-49B6-BB04-B82F0138CAF0@thomasclausen.org>
To: Abdussalam Baryun 
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/WFdgEp3l5EgAMe0_4lOqN8aqj74
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Discussion about whether AODVv2 document editor is "interested" in discussing issues
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Mar 2014 12:14:16 -0000

--Apple-Mail-5D66FD61-73CD-48AA-9868-3A2A0A3D461E
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Ok now I just read this email, and it reads really weird. Allow me to correc=
t myself...

> On 5 mars 2014, at 22:21, Thomas Heide Clausen  wr=
ote:
>=20
>=20
>> On 5 mars 2014, at 22:18, Abdussalam Baryun  w=
rote:
>>=20
>> I mean there are implementations and it works, but still under test for n=
ew v2, OLSR and AODV are well known. We don't wait for implementation to fin=
ish then submit for standards as far as I understand standard track ( I reme=
mber once heard that from an AD I think, am I mistaken).=20
>=20
> Actually, having running code (And, preferably, multiple interoperable imp=
lementations) is very very very highly recommended before publishing at std.=
 track.
>=20
> Actually, I'd submit that *not* having multiple interoperable implementati=
ons should be a requirement before std. track publication.
>=20

And that is not what I mean, of course.

I of course wanted to say:

> Actually, I'd submit that  *having* multiple interoperable implementations=
 should be a requirement before std. track publication.


Thomas

> Thomas
>=20
>> AB
>>=20
>>> On Wednesday, March 5, 2014, Henning Rogge wrote:
>>> "Implementation is not a most for a standard track document"... that
>>> is an "interesting" point of view.
>>>=20
>>> Henning Rogge
>>>=20
>>> On Wed, Mar 5, 2014 at 8:23 PM, Abdussalam Baryun
>>>  wrote:
>>> >
>>> > Hi Charles,
>>> >
>>> > As I suggested in meeting IMHO we get a schedule plan for submission a=
s long
>>> > not much clear discussion by the group.
>>> >
>>> > Implementing AODVv2 is not a must (this was discussed before) because m=
ost
>>> > already practiced its techniques but when tested within the coming two=
 years
>>> > it will be better as OLSRv2 taken some years tests after submit.
>>> >
>>> > AB
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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-5D66FD61-73CD-48AA-9868-3A2A0A3D461E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Ok now I just read this email, and it r=
eads really weird. Allow me to correct myself...

On 5 mars 201=
4, at 22:21, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:


On 5 mars 2014, at 22:18, Abdussalam Baryun <<=
a href=3D"mailto:abdussalambaryun@gmail.com">abdussalambaryun@gmail.com&=
gt; wrote:

I mean there are impl=
ementations and it works, but still under test for new v2, OLSR and AOD=
V are well known. We don't wait for implementation to finish then submit for=
 standards as far as I understand standard track ( I remember once heard tha=
t from an AD I think, am I mistaken). 

Actually, having running code (And, preferably, multiple interoperable impl=
ementations) is very very very highly recommended before publishing at std. t=
rack.

Actually, I'd submit that *not* having multiple int=
eroperable implementations should be a requirement before std. track publica=
tion.


And that is not w=
hat I mean, of course.

I of course wanted to say:

Actually, I'd submit that  =
*having* multiple interoperable implementations should be a requirement befo=
re std. track publication.

Thomas

Thomas

AB

On Wednesday, March 5, 2014, Henni=
ng Rogge  wrote:
"Implementation is not a mo=
st for a standard track document"... that


is an "interesting" point of view.



Henning Rogge



On Wed, Mar 5, 2014 at 8:23 PM, Abdussalam Baryun

<abdussalambaryun@gmail.com> wrote:

>

> Hi Charles,

>

> As I suggested in meeting IMHO we get a schedule plan for submission as=
 long

> not much clear discussion by the group.

>

> Implementing AODVv2 is not a must (this was discussed before) because m=
ost

> already practiced its techniques but when tested within the coming two y=
ears

> it will be better as OLSRv2 taken some years tests after submit.

>

> AB

>

>

>

> _______________________________________________

> manet mailing list

> https://www.ietf.org/mailman/listinfo/manet

>




____________________=
___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai=
lman/listinfo/manet
_______________________________=
________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo=
/manet
=

--Apple-Mail-5D66FD61-73CD-48AA-9868-3A2A0A3D461E--


From nobody Mon Mar 31 01:08:39 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D331A0812 for ; Mon, 31 Mar 2014 01:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.6
X-Spam-Level: *
X-Spam-Status: No, score=1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuBM-xJLL4bq for ; Mon, 31 Mar 2014 01:08:36 -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 042471A03A2 for ; Mon, 31 Mar 2014 01:08:35 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WUXGh-0002uC-3B; Mon, 31 Mar 2014 04:08:31 -0400
Message-ID: <5339227D.20100@computer.org>
Date: Mon, 31 Mar 2014 01:08:29 -0700
From: "Charles E. Perkins" 
Organization: Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Stan Ratliff (sratliff)" ,  Christopher Dearlove 
References:  <8A789D78-30FE-4924-AE60-B16D687CAC70@thomasclausen.org>  <5BDEDFE0-D038-4214-8D15-CB4804A1E087@thomasclausen.org>  <48206E14-EAA5-4492-B1B4-AAA49994FA12@mnemosyne.demon.co.uk>  <35472763-FD39-4DC3-BAF4-F9BFAE436491@gmail.com>   <04634E91-C2CC-426E-80DF-4E14E40D34CB@thomasclausen.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86fe89adc23a7d4df46a3975f85798fcf5350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qjspQtS28tukPRCPjDG_948VzZ4
Cc: manet@ietf.org
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 08:08:37 -0000

Hello folks,

I finally got around to reading some of the draft.  I did notice a
couple of typos (can supply on request), but have a couple of
other issues.  Maybe they would be answered if I finished the
draft, but that has to wait at least a few more days...

- I understand the point to be that connectivity and thus
   topology is determined by existence of a link where the
   routers are "willing" and can satisfy the desired metric (say,
   to have sufficient bandwidth).  One could imagine a topology
   where only links of > 10kb/sec were allowed, and another
   topology where only links of > 10Mb/sec were allowed.  Does
   the draft intend to enable this?

- I have always understood a metric to be a function that assigns
   a metric value to a routing path.  Then, a metric type defines
   the way that the function associates a value to a routing path.
   Using typical functional notation, we would have:
     v = f(path), where f is the metric and v is the value that f
            assigns to the path.
   Going a step further, we can consider the space of all routing
   metrics, and have a "big" function F that assigns a metric value
   to a path given two parameters -- namely, metric_type, and path.
   Using typical functional notation, we would have:
   v = F(type, path)

   Using this notation, then, the domain of f is "paths" and the
   range is some set of allowable values.  Let's say that the domain
   of f is D(f) and the range is R(f).  Then, as for any function,
   we have f(D(f)) "is a subset" of R(f).  Here, D(f) is {paths},
   and R(f) depends on the metric type of f (f is a metric).  We
   can also say that D(F) == {metric_types} x {paths}, where 'x'
   is cross product and {metric_types} is the set of all metric
   types.

   The terminology in the draft should not be at odds with these
   conventional mathematical notations.
   map[range -> type]  seems to say that the "range" is the domain.
   It is confusing in multiple ways to say that "metric types" are
   either:
         boolean,
         a willingness (a 4 bit unsigned integer from 0 to 15),
         a number of hops (an 8 bit unsigned integer ..),
         or a metric-value (as defined somewhere else).

   because (a) boolean and #hops are already allowable metric values, and
   (b) these are actually possible ranges for certain metric functions,
       which take as input a path and provide as output a value within
       the range of allowable values for the metric type.  Moreover, if
       it were really intended for the "range" to be the argument of the
       abovementioned map, then the discussion can no longer be
       well-formed without terrible restrictions on the types of metrics
       considered.

- The draft restricts applicability to "managed" MANETs.  That is
    probably appropriate, but could stand to have somewhat better
    definition.  For the purposes of the draft, I imagine that
    "manageability" means "running a specific predetermined set of
    applications".

-- 
Regards,
Charlie P.


From nobody Mon Mar 31 02:07:37 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5468C1A03A2 for ; Mon, 31 Mar 2014 02:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level: 
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, GB_SUMOF=1, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ldv47QW_csrN for ; Mon, 31 Mar 2014 02:07:28 -0700 (PDT)
Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC11A0988 for ; Mon, 31 Mar 2014 02:07:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,763,1389744000"; d="scan'208";a="427438508"
Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 31 Mar 2014 10:07:24 +0100
X-IronPort-AV: E=Sophos;i="4.97,763,1389744000"; d="scan'208";a="46739983"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 31 Mar 2014 10:07:24 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.17]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Mon, 31 Mar 2014 10:07:24 +0100
From: "Dearlove, Christopher (UK)" 
To: "Charles E. Perkins" , "Stan Ratliff (sratliff)" , Christopher Dearlove 
Thread-Topic: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02
Thread-Index: AQHPTLhyfVg/9zBm7E2/8EukTNYtGZr64DuQ
Date: Mon, 31 Mar 2014 09:07:23 +0000
Message-ID: 
References:  <8A789D78-30FE-4924-AE60-B16D687CAC70@thomasclausen.org>  <5BDEDFE0-D038-4214-8D15-CB4804A1E087@thomasclausen.org>  <48206E14-EAA5-4492-B1B4-AAA49994FA12@mnemosyne.demon.co.uk>  <35472763-FD39-4DC3-BAF4-F9BFAE436491@gmail.com>   <04634E91-C2CC-426E-80DF-4E14E40D34CB@thomasclausen.org>  <5339227D.20100@computer.org>
In-Reply-To: <5339227D.20100@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"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ePsyzqyU3IRZrzb-qFYpUFNVXiw
Cc: "manet@ietf.org" 
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 09:07:30 -0000

Some comments below marked CMD.

-- =

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 [mailto:manet-bounces@ietf.org] On Behalf Of Charles E. Perkins
Sent: 31 March 2014 09:08
To: Stan Ratliff (sratliff); Christopher Dearlove
Cc: manet@ietf.org
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-=
02

----------------------! WARNING ! ---------------------- This message origi=
nates from outside our organisation, either from an external partner or fro=
m the internet.
Consider carefully whether you should click on any links, open any attachme=
nts or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions o=
n reporting suspicious email messages.
--------------------------------------------------------

Hello folks,

I finally got around to reading some of the draft.  I did notice a couple o=
f typos (can supply on request), but have a couple of other issues.  Maybe =
they would be answered if I finished the draft, but that has to wait at lea=
st a few more days...

- I understand the point to be that connectivity and thus
   topology is determined by existence of a link where the
   routers are "willing" and can satisfy the desired metric (say,
   to have sufficient bandwidth).  One could imagine a topology
   where only links of > 10kb/sec were allowed, and another
   topology where only links of > 10Mb/sec were allowed.  Does
   the draft intend to enable this?

CMD: Each link may or may not have a specific type of metric assigned, and =
therefor that link may or may not be part of the corresponding topology. It=
 is thus straightforward to implement the example you describe.

- I have always understood a metric to be a function that assigns
   a metric value to a routing path.  Then, a metric type defines
   the way that the function associates a value to a routing path.
   Using typical functional notation, we would have:
     v =3D f(path), where f is the metric and v is the value that f
            assigns to the path.
   Going a step further, we can consider the space of all routing
   metrics, and have a "big" function F that assigns a metric value
   to a path given two parameters -- namely, metric_type, and path.
   Using typical functional notation, we would have:
   v =3D F(type, path)

The metrics are all (as in OLSRv2) assigned to links, path metrics are the =
sum of link metrics.

   Using this notation, then, the domain of f is "paths" and the
   range is some set of allowable values.  Let's say that the domain
   of f is D(f) and the range is R(f).  Then, as for any function,
   we have f(D(f)) "is a subset" of R(f). =


Actually, that's not the mathematical notation I would use. Range is an ove=
rloaded term, some use it for R(f), some use it for f(D(f)). My lecturers a=
voided that problem, R(f) is the codomain, and f(D(f)) is the image, range =
was banished.

   Here, D(f) is {paths},
   and R(f) depends on the metric type of f (f is a metric).  We
   can also say that D(F) =3D=3D {metric_types} x {paths}, where 'x'
   is cross product and {metric_types} is the set of all metric
   types.

   The terminology in the draft should not be at odds with these
   conventional mathematical notations.
   map[range -> type]  seems to say that the "range" is the domain.

Range is an overloaded word, and this isn't using it in that way. Though it=
's not a great usage even if we ignore the functional usage. I take your po=
int, we should reconsider this terminology.

   It is confusing in multiple ways to say that "metric types" are
   either:
         boolean,
         a willingness (a 4 bit unsigned integer from 0 to 15),
         a number of hops (an 8 bit unsigned integer ..),
         or a metric-value (as defined somewhere else).

No, you've inserted the metric in your quote. This is saying that the type =
of the codomain of the map is always one of those three things. Generic typ=
e, not metric type. The domain is an ordered set of metric types. Those thr=
ee things are things assigned to a topology (indexed by metric type).

   because (a) boolean and #hops are already allowable metric values, and
   (b) these are actually possible ranges for certain metric functions,
       which take as input a path and provide as output a value within
       the range of allowable values for the metric type.  Moreover, if
       it were really intended for the "range" to be the argument of the
       abovementioned map, then the discussion can no longer be
       well-formed without terrible restrictions on the types of metrics
       considered.

- The draft restricts applicability to "managed" MANETs. That is
    probably appropriate, but could stand to have somewhat better
    definition.  For the purposes of the draft, I imagine that
    "manageability" means "running a specific predetermined set of
    applications".

CMD: No, I wouldn't make that definition, there's no reason to be that limi=
ted. What's critical is that routers will make a consistent judgement when =
forwarding a packet, which metric type should be used to forward that packe=
t. What's important is that routers have a consistent approach to each metr=
ic type. (Critical means will do unpleasant things, like maybe looping, if =
not so. Important means will behave poorly, and may find bad routes, or no =
routes, if not so.) If it's agreed that (say) metric type X means fast reli=
able delivery, that X corresponds to DHCP type Y, and that packets should n=
ot be labelled Y without a very good reason, then we don't need to specify =
exactly what applications might create packets of that type.

--
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 nobody Mon Mar 31 03:27:14 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656741A067F for ; Mon, 31 Mar 2014 03:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.399
X-Spam-Level: 
X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBS9NtnjmWTL for ; Mon, 31 Mar 2014 03:27:10 -0700 (PDT)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) by ietfa.amsl.com (Postfix) with ESMTP id 896641A066B for ; Mon, 31 Mar 2014 03:27:10 -0700 (PDT)
Received: by mail-yk0-f180.google.com with SMTP id 19so3012590ykq.11 for ; Mon, 31 Mar 2014 03:27: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=6iJxK778EddV0vgpkUyyHweRNrp2HVxecFLMrmDw/sA=; b=s/uu838xerJ/DvghtvZ0PL9j2ijvAVm2UrDH1FuH89baTUQ/HtnCV2nYf3bQh7rLMD dx61FRtkwJnx5zkSt54WbK0jsyp5AJ92K+G2fhauY+dsGhaAAYQt5YVeROR/NKA7EtYg 8wx2xqB81sTGP0XVoKh2UkTz849ggYLsSxb0FIWuplOBO8Q91Vq5EnggU8mc1MnFyP+K VJ9xGcJ+LZTFiTvFPjoFnMkTJ5GceZsL79T9Q4wkEQariW0Dy2yP3nuaxFp0gZMcTCH2 ysG2Ton8gJbw8M87J4btQ7i/Ozc6JiijyLpWbgm580/xa4IirxHOOqrxgONHqt/CGQR+ 8qkA==
MIME-Version: 1.0
X-Received: by 10.236.101.198 with SMTP id b46mr9373268yhg.68.1396261627402; Mon, 31 Mar 2014 03:27:07 -0700 (PDT)
Received: by 10.170.87.135 with HTTP; Mon, 31 Mar 2014 03:27:07 -0700 (PDT)
In-Reply-To: 
References:  <8A789D78-30FE-4924-AE60-B16D687CAC70@thomasclausen.org>  <5BDEDFE0-D038-4214-8D15-CB4804A1E087@thomasclausen.org>  <48206E14-EAA5-4492-B1B4-AAA49994FA12@mnemosyne.demon.co.uk>  <35472763-FD39-4DC3-BAF4-F9BFAE436491@gmail.com>   <04634E91-C2CC-426E-80DF-4E14E40D34CB@thomasclausen.org>  <5339227D.20100@computer.org> 
Date: Mon, 31 Mar 2014 11:27:07 +0100
Message-ID: 
From: Abdussalam Baryun 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=20cf30050b22509f0604f5e47e93
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YsEgBYJy8t6fhki5hmHVrtYeu6A
Cc: Christopher Dearlove , "manet@ietf.org" , "Stan Ratliff \(sratliff\)" 
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 10:27:12 -0000

--20cf30050b22509f0604f5e47e93
Content-Type: text/plain; charset=ISO-8859-1

Hi Chris,

I need to understand more that why I request more explain. Thanks,

On Mon, Mar 31, 2014 at 10:07 AM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> Some comments below marked CMD.
>
> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Charles E.
> Perkins
> Sent: 31 March 2014 09:08
> To: Stan Ratliff (sratliff); Christopher Dearlove
> Cc: manet@ietf.org
> Subject: Re: [manet] comments on
> draft-dearlove-manet-olsrv2-multitopology-02
>


> Hello folks,
>
> I finally got around to reading some of the draft.  I did notice a couple
> of typos (can supply on request), but have a couple of other issues.  Maybe
> they would be answered if I finished the draft, but that has to wait at
> least a few more days...
>
> - I understand the point to be that connectivity and thus
>    topology is determined by existence of a link where the
>    routers are "willing" and can satisfy the desired metric (say,
>    to have sufficient bandwidth).  One could imagine a topology
>    where only links of > 10kb/sec were allowed, and another
>    topology where only links of > 10Mb/sec were allowed.  Does
>    the draft intend to enable this?
>
> CMD: Each link may or may not have a specific type of metric assigned, and
> therefor that link may or may not be part of the corresponding topology. It
> is thus straightforward to implement the example you describe.
>
You said before that each packet has the same topology within the MANET,
but now you mention in the OLSRv2 MANET a router MAY assign metric-types
to its links. IMO, that means the topology is dynamic with metric per
router, and that may not insure each packet has one topology.


>
> - I have always understood a metric to be a function that assigns
>    a metric value to a routing path.  Then, a metric type defines
>    the way that the function associates a value to a routing path.
>    Using typical functional notation, we would have:
>      v = f(path), where f is the metric and v is the value that f
>             assigns to the path.
>    Going a step further, we can consider the space of all routing
>    metrics, and have a "big" function F that assigns a metric value
>    to a path given two parameters -- namely, metric_type, and path.
>    Using typical functional notation, we would have:
>    v = F(type, path)
>
> The metrics are all (as in OLSRv2) assigned to links, path metrics are the
> sum of link metrics.
>
>

Do you mean OLSRv2 path metric is the sum of links' metrics? I think you
mean some types of path costs, not all path costs.

IMHO, in the multi-toplogy situation we have one routing metric for each
topology, your text seem to say the OLSRv2 metrics are assigned only to
links (not to paths within the topology).

Best Regards

AB

--20cf30050b22509f0604f5e47e93
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Chris,


=A0


I need to understand more that why I request more explain. Thanks,
=



On Mon, Mar 31, 2014 at 10:07 AM, Dearlove, Chri=
stopher (UK) <chris.dearlove@baesystems.com> wro=
te:



Some comments below marked CMD.



-----Original Message-----
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Charles =
E. Perkins
Sent: 31 March 2014 09:08
To: Stan Ratliff (sratliff); Chr=
istopher Dearlove

Cc: manet@ietf.org
Subject: Re: [m=
anet] comments on draft-dearlove-manet-olsrv2-multitopology-02


=A0




Hello folks,

I finally got around to reading some of the draft.=
 =A0I did notice a couple of typos (can supply on request), but have a coup=
le of other issues. =A0Maybe they would be answered if I finished the draft=
, but that has to wait at least a few more days...


- I understand the point to be that connectivity and thus
=A0 =A0top=
ology is determined by existence of a link where the
=A0 =A0routers are =
"willing" and can satisfy the desired metric (say,
=A0 =A0to h=
ave sufficient bandwidth). =A0One could imagine a topology

=A0 =A0where only links of > 10kb/sec were allowed, and another
=A0 =
=A0topology where only links of > 10Mb/sec were allowed. =A0Does
=A0 =
=A0the draft intend to enable this?

CMD: Each link may or may =
not have a specific type of metric assigned, and therefor that link may or =
may not be part of the corresponding topology. It is thus straightforward t=
o implement the example you describe.




You said before that each packet has the same topology within the MANE=
T, but now you mention in the OLSRv2 MANET a router=A0MAY assign metric-typ=
es to=A0its links. IMO, that means the topology is dynamic with metric per =
router, and that may=A0not insure each packet has one topology.



=A0





- I have always understood a metric to be a function that assigns<=
br>=A0 =A0a metric value to a routing path. =A0Then, a metric type defines<=
br>=A0 =A0the way that the function associates a value to a routing path.=A0 =A0Using typical functional notation, we would have:

=A0 =A0 =A0v =3D f(path), where f is the metric and v is the value that f=A0 =A0 =A0 =A0 =A0 =A0 assigns to the path.
=A0 =A0Going a step furth=
er, we can consider the space of all routing
=A0 =A0metrics, and have a =
"big" function F that assigns a metric value

=A0 =A0to a path given two parameters -- namely, metric_type, and path.
=
=A0 =A0Using typical functional notation, we would have:
=A0 =A0v =3D F(=
type, path)

The metrics are all (as in OLSRv2) assigned to lin=
ks, path metrics are the sum of link metrics.



=A0


=A0


Do you mean OLSRv2 path metric is the sum of links' metrics? I thi=
nk you mean some types of=A0path costs, not all path costs.


=A0


IMHO, in the multi-toplogy situation we have one routing metric for ea=
ch topology, your text=A0seem to say the OLSRv2 metrics are assigned=A0only=
 to links (not to paths within the topology).


=A0


Best Regards


=A0


AB


=A0


=A0


--20cf30050b22509f0604f5e47e93--


From nobody Mon Mar 31 10:02:39 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A621A6F2C for ; Mon, 31 Mar 2014 10:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.6
X-Spam-Level: **
X-Spam-Status: No, score=2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKFtmF7YO9qA for ; Mon, 31 Mar 2014 10:02:36 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4E32A1A6F27 for ; Mon, 31 Mar 2014 10:02:36 -0700 (PDT)
Received: from [107.1.141.74] (helo=[192.168.253.213]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WUfbT-0001gy-6y; Mon, 31 Mar 2014 13:02:31 -0400
Message-ID: <53399F9E.6010604@computer.org>
Date: Mon, 31 Mar 2014 10:02:22 -0700
From: "Charles E. Perkins" 
Organization: Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Dearlove, Christopher \(UK\)" ,  Christopher Dearlove 
References:  <8A789D78-30FE-4924-AE60-B16D687CAC70@thomasclausen.org>  <5BDEDFE0-D038-4214-8D15-CB4804A1E087@thomasclausen.org>  <48206E14-EAA5-4492-B1B4-AAA49994FA12@mnemosyne.demon.co.uk>  <35472763-FD39-4DC3-BAF4-F9BFAE436491@gmail.com>   <04634E91-C2CC-426E-80DF-4E14E40D34CB@thomasclausen.org>  <5339227D.20100@computer.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86c012f6318efcf64122f717c3a33a6aad350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0b5Z_jEC8P14BVkSF7iaLGlGkhw
Cc: manet@ietf.org
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 17:02:37 -0000

Hello Chris,

On 3/31/2014 2:07 AM, Dearlove, Christopher (UK) wrote:
> - I understand the point to be that connectivity and thus
>     topology is determined by existence of a link where the
>     routers are "willing" and can satisfy the desired metric (say,
>     to have sufficient bandwidth).  One could imagine a topology
>     where only links of > 10kb/sec were allowed, and another
>     topology where only links of > 10Mb/sec were allowed.  Does
>     the draft intend to enable this?
>
> CMD: Each link may or may not have a specific type of metric assigned, and therefor that link may or may not be part of the corresponding topology. It is thus straightforward to implement the example you describe.

How would you describe the metric type for the two examples
as shown above?

>
> - I have always understood a metric to be a function that assigns
>     a metric value to a routing path.  Then, a metric type defines
>     the way that the function associates a value to a routing path.
>     Using typical functional notation, we would have:
>       v = f(path), where f is the metric and v is the value that f
>              assigns to the path.
>     Going a step further, we can consider the space of all routing
>     metrics, and have a "big" function F that assigns a metric value
>     to a path given two parameters -- namely, metric_type, and path.
>     Using typical functional notation, we would have:
>     v = F(type, path)
>
> The metrics are all (as in OLSRv2) assigned to links, path metrics are the sum of link metrics.

This is natural; one can consider a "link" to be a path with only one
path component...

>
>     Using this notation, then, the domain of f is "paths" and the
>     range is some set of allowable values.  Let's say that the domain
>     of f is D(f) and the range is R(f).  Then, as for any function,
>     we have f(D(f)) "is a subset" of R(f).
>
> Actually, that's not the mathematical notation I would use. Range is an overloaded term, some use it for R(f), some use it for f(D(f)). My lecturers avoided that problem, R(f) is the codomain, and f(D(f)) is the image, range was banished.

I reckon the word is not banished worldwide...  and, as you point out,
the word "codomain" is commonly defined differently than "range".

>     The terminology in the draft should not be at odds with these
>     conventional mathematical notations.
>     map[range -> type]  seems to say that the "range" is the domain.
>
> Range is an overloaded word, and this isn't using it in that way. Though it's not a great usage even if we ignore the functional usage. I take your point, we should reconsider this terminology.

Thanks -- I think that would be very helpful to avoid confusion. Usually,
even for words with overloaded meaning, either the meanings are not
contradictory, or the context can help disambiguate.  Usually, but not
always in colloquial English.  I think it's rare or even nonexistent when
using mathematical notation to have contradictory meanings for the same
word...

>     It is confusing in multiple ways to say that "metric types" are
>     either:
>           boolean,
>           a willingness (a 4 bit unsigned integer from 0 to 15),
>           a number of hops (an 8 bit unsigned integer ..),
>           or a metric-value (as defined somewhere else).
>
> No, you've inserted the metric in your quote. This is saying that the type of the codomain of the map is always one of those three things. Generic type, not metric type.

I guess "generic type" means "data type".  "boolean" and the others can
indeed be considered data types.  Since this effort is going to be closely
associated with managing metric types, maybe the draft has to be careful
about always using either "data type" or "metric type".  By the way, why
did you say "three things" instead of "four things"?


>   The domain is an ordered set of metric types.

Is it *really* an ordered set??  What is the ordering?  I would have
thought the only important thing here is that the correspondence
is a function.

>   Those three things are things assigned to a topology (indexed by metric type).

I think you mean something different, because the same topology
can very definitely be delineated by two different metrics.  Thus, you
would have to define some sort of multi-valued correspondence.
Yes, this can be done, but it is considerably more complicated.

>
> - The draft restricts applicability to "managed" MANETs. That is
>      probably appropriate, but could stand to have somewhat better
>      definition.  For the purposes of the draft, I imagine that
>      "manageability" means "running a specific predetermined set of
>      applications".
>
> CMD: No, I wouldn't make that definition, there's no reason to be that limited. What's critical is that routers will make a consistent judgement when forwarding a packet, which metric type should be used to forward that packet. What's important is that routers have a consistent approach to each metric type. (Critical means will do unpleasant things, like maybe looping, if not so. Important means will behave poorly, and may find bad routes, or no routes, if not so.) If it's agreed that (say) metric type X means fast reliable delivery, that X corresponds to DHCP type Y, and that packets should not be labelled Y without a very good reason, then we don't need to specify exactly what applications might create packets of that type.

Sure.  It's almost tautological to limit the definition by your condition.
However, one has to wonder why the condition would be imposed.
When I start wondering that, the answer I get is that one wants to do
this because some application needs to be presented with a strictly
delimited set of routing choices, as defined by the metric (for example,
the "Cap-GT-10Mbps" metric).

-- 
Regards,
Charlie P.


From nobody Mon Mar 31 10:06:03 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB11D1A6F2E for ; Mon, 31 Mar 2014 10:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pax4OQpwrwMs for ; Mon, 31 Mar 2014 10:06:00 -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 A536A1A6F2D for ; Mon, 31 Mar 2014 10:06:00 -0700 (PDT)
Received: from [107.1.141.74] (helo=[192.168.253.213]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WUfek-0008B3-AA; Mon, 31 Mar 2014 13:05:54 -0400
Message-ID: <5339A04B.4040607@computer.org>
Date: Mon, 31 Mar 2014 10:05:15 -0700
From: "Charles E. Perkins" 
Organization: Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Dearlove, Christopher \(UK\)" ,  Christopher Dearlove 
References:  <8A789D78-30FE-4924-AE60-B16D687CAC70@thomasclausen.org>  <5BDEDFE0-D038-4214-8D15-CB4804A1E087@thomasclausen.org>  <48206E14-EAA5-4492-B1B4-AAA49994FA12@mnemosyne.demon.co.uk>  <35472763-FD39-4DC3-BAF4-F9BFAE436491@gmail.com>   <04634E91-C2CC-426E-80DF-4E14E40D34CB@thomasclausen.org>  <5339227D.20100@computer.org>  <53399F9E.6010604@computer.org>
In-Reply-To: <53399F9E.6010604@computer.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86fcddea0c8470eae073ada3806722cd88350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MzZGKwp7regKRCvmDtuS5Bxhuow
Cc: manet@ietf.org
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 17:06:02 -0000

Hello again Chris,

Correcting my mistake below...

On 3/31/2014 10:02 AM, Charles E. Perkins wrote:
>
>>
>> Actually, that's not the mathematical notation I would use. Range is 
>> an overloaded term, some use it for R(f), some use it for f(D(f)). My 
>> lecturers avoided that problem, R(f) is the codomain, and f(D(f)) is 
>> the image, range was banished.
>
> I reckon the word is not banished worldwide...  and, as you point out,
> the word "codomain" is commonly defined differently than "range".

I should have said "image" is commonly defined differently than "range".

-- 
Regards,
Charlie P.


From nobody Mon Mar 31 10:49:01 2014
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE3A1A6F0C for ; Mon, 31 Mar 2014 10:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.5
X-Spam-Level: **
X-Spam-Status: No, score=2.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6, MANGLED_OFF=2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2da56_ZpOwhX for ; Mon, 31 Mar 2014 10:48:57 -0700 (PDT)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 61E601A071B for ; Mon, 31 Mar 2014 10:48:57 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id b13so6335951wgh.29 for ; Mon, 31 Mar 2014 10:48:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t7ZZTbV4YlmKXY7zA22M+P9YJq022PFJ+cH2Fs3JQAM=; b=HGSRSNsA1xxYwbNQXCJTIdw7HLWa89fXId1rR5OdmiPGdHGf5JD9BetXHUK7DnAAKH Pc6XkbiuKELWw+iQaSVlg2I/Z5PgRd++/Pl9nXBA/79/Z4xHi0Hgr2Gm1VqjIUfatTMy pxvZZBYMWaObMmJIlnl24mIbERo7uXp1GvKyY/bQtz2EF0wjCOzQu9ngIDdExSR2Ij5y w9lp0opMs+fjc8yA3PJ8wlhREVlDSNHEuBXOGfChTONu4eB/fWwAQz2aAd5HpB4hCh+O WlDea9+byAKJr8qsguRf0msAhFu+u1TnyUpUJA9XhlRDmn94kLwC5WjOBZfZjbGbtA/5 R6MA==
X-Received: by 10.194.110.100 with SMTP id hz4mr7665203wjb.50.1396288133676; Mon, 31 Mar 2014 10:48:53 -0700 (PDT)
Received: from [192.168.254.2] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id gz1sm27948105wib.14.2014.03.31.10.48.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 10:48:52 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Christopher Dearlove 
In-Reply-To: <53399F9E.6010604@computer.org>
Date: Mon, 31 Mar 2014 18:48:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <8A789D78-30FE-4924-AE60-B16D687CAC70@thomasclausen.org>  <5BDEDFE0-D038-4214-8D15-CB4804A1E087@thomasclausen.org>  <48206E14-EAA5-4492-B1B4-AAA49994FA12@mnemosyne.demon.co.uk>  <35472763-FD39-4DC3-BAF4-F9BFAE436491@gmail.com>   <04634E91-C2CC-426E-80DF-4E14E40D34CB@thomasclausen.org>  <5339227D.20100@computer.org>  <53399F9E.6010604@computer.org>
To: "Charles E. Perkins" 
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kA9e0hiaVoiZgY_5F5fgY7pdc0k
Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 17:48:59 -0000

On 31 Mar 2014, at 18:02, Charles E. Perkins wrote:

> Hello Chris,
>=20
> On 3/31/2014 2:07 AM, Dearlove, Christopher (UK) wrote:
>> - I understand the point to be that connectivity and thus
>>    topology is determined by existence of a link where the
>>    routers are "willing" and can satisfy the desired metric (say,
>>    to have sufficient bandwidth).  One could imagine a topology
>>    where only links of > 10kb/sec were allowed, and another
>>    topology where only links of > 10Mb/sec were allowed.  Does
>>    the draft intend to enable this?
>>=20
>> CMD: Each link may or may not have a specific type of metric =
assigned, and therefor that link may or may not be part of the =
corresponding topology. It is thus straightforward to implement the =
example you describe.
>=20
> How would you describe the metric type for the two examples
> as shown above?

I'd pick two metric types from those available to be allocated =
administratively (which is missing from the IANA considerations section, =
but mentioned somewhere else) and define them that way in that network. =
(As something that specialised, it's not going to have a universal =
definition.)

>> - I have always understood a metric to be a function that assigns
>>    a metric value to a routing path.  Then, a metric type defines
>>    the way that the function associates a value to a routing path.
>>    Using typical functional notation, we would have:
>>      v =3D f(path), where f is the metric and v is the value that f
>>             assigns to the path.
>>    Going a step further, we can consider the space of all routing
>>    metrics, and have a "big" function F that assigns a metric value
>>    to a path given two parameters -- namely, metric_type, and path.
>>    Using typical functional notation, we would have:
>>    v =3D F(type, path)
>>=20
>> The metrics are all (as in OLSRv2) assigned to links, path metrics =
are the sum of link metrics.
>=20
> This is natural; one can consider a "link" to be a path with only one
> path component...

That's putting the cart and the horse the wrong way round. This is a =
link state protocol. Metric are defined for links. Metrics for routes =
are defined as the sum of the link metrics, they have no separate =
existence from that. See RFC 7181 (as it will be in a few days).

>>    Using this notation, then, the domain of f is "paths" and the
>>    range is some set of allowable values.  Let's say that the domain
>>    of f is D(f) and the range is R(f).  Then, as for any function,
>>    we have f(D(f)) "is a subset" of R(f).
>>=20
>> Actually, that's not the mathematical notation I would use. Range is =
an overloaded term, some use it for R(f), some use it for f(D(f)). My =
lecturers avoided that problem, R(f) is the codomain, and f(D(f)) is the =
image, range was banished.
>=20
> I reckon the word is not banished worldwide...  and, as you point out,
> the word "codomain" is commonly defined differently than "range".

Of course it's not banished worldwide. But I wouldn't use it anything =
precise, because of the ambiguity., and the availability of image and =
codomain to be precise. (And actually, there's a third option I could =
point to, where image and codomain are, of necessity, the same.) But =
it's all irrelevant. I agree the usage of range as it current is, is =
confusing because range is often used as a "right hand" thing, whether =
image or codomain is irrelevant.

>>    The terminology in the draft should not be at odds with these
>>    conventional mathematical notations.
>>    map[range -> type]  seems to say that the "range" is the domain.
>>=20
>> Range is an overloaded word, and this isn't using it in that way. =
Though it's not a great usage even if we ignore the functional usage. I =
take your point, we should reconsider this terminology.
>=20
> Thanks -- I think that would be very helpful to avoid confusion. =
Usually,
> even for words with overloaded meaning, either the meanings are not
> contradictory, or the context can help disambiguate.  Usually, but not
> always in colloquial English.  I think it's rare or even nonexistent =
when
> using mathematical notation to have contradictory meanings for the =
same
> word...

Definitely not nonexistent.

Range is one. If you want another, trapezium and trapezoid switch =
meanings when you cross the Atlantic.

But I'm not going to get further stuck into that discussion. It's =
irrelevant to this draft - and this list.

>>    It is confusing in multiple ways to say that "metric types" are
>>    either:
>>          boolean,
>>          a willingness (a 4 bit unsigned integer from 0 to 15),
>>          a number of hops (an 8 bit unsigned integer ..),
>>          or a metric-value (as defined somewhere else).
>>=20
>> No, you've inserted the metric in your quote. This is saying that the =
type of the codomain of the map is always one of those three things. =
Generic type, not metric type.
>=20
> I guess "generic type" means "data type".  "boolean" and the others =
can
> indeed be considered data types.  Since this effort is going to be =
closely
> associated with managing metric types, maybe the draft has to be =
careful
> about always using either "data type" or "metric type".  By the way, =
why
> did you say "three things" instead of "four things"?

Simple error (to the three/four). Consistently using the qualification =
you suggest for type is, I think (but co-authors can have opinions) a =
useful one. (And there are other types too, related to 5444, but I think =
those are already all qualified.)

>>  The domain is an ordered set of metric types.
>=20
> Is it *really* an ordered set??  What is the ordering?  I would have
> thought the only important thing here is that the correspondence
> is a function.

Is it ordered? Actually in this context, or a map, it doesn't need an =
order. But it does need an order when included in a message in TLVs. =
Personally I'd therefore implement it ordered so as to not have to sort =
those that needed to be ordered to include in TLVs. And then might as =
well do the same for all. But in an abstract model, it doesn't always =
(possibly never) need ordering. But I would need to read with care =
relating to parameter usage.

>>  Those three things are things assigned to a topology (indexed by =
metric type).
>=20
> I think you mean something different, because the same topology
> can very definitely be delineated by two different metrics.  Thus, you
> would have to define some sort of multi-valued correspondence.
> Yes, this can be done, but it is considerably more complicated.

No, I mean what I said. This model of multi-topology has a one to one =
correspondence between metric type and topology. So the topologies are =
conveniently indexed by metric type. (Yes, many to one is considerably =
more complicated, especially with backward compatibility.)

>> - The draft restricts applicability to "managed" MANETs. That is
>>     probably appropriate, but could stand to have somewhat better
>>     definition.  For the purposes of the draft, I imagine that
>>     "manageability" means "running a specific predetermined set of
>>     applications".
>>=20
>> CMD: No, I wouldn't make that definition, there's no reason to be =
that limited. What's critical is that routers will make a consistent =
judgement when forwarding a packet, which metric type should be used to =
forward that packet. What's important is that routers have a consistent =
approach to each metric type. (Critical means will do unpleasant things, =
like maybe looping, if not so. Important means will behave poorly, and =
may find bad routes, or no routes, if not so.) If it's agreed that (say) =
metric type X means fast reliable delivery, that X corresponds to DHCP =
type Y, and that packets should not be labelled Y without a very good =
reason, then we don't need to specify exactly what applications might =
create packets of that type.
>=20
> Sure.  It's almost tautological to limit the definition by your =
condition.
> However, one has to wonder why the condition would be imposed.
> When I start wondering that, the answer I get is that one wants to do
> this because some application needs to be presented with a strictly
> delimited set of routing choices, as defined by the metric (for =
example,
> the "Cap-GT-10Mbps" metric).

We need this to avoid any possibility of looping. That really is the =
reason. We had this discussion a while back on the list. And I wouldn't =
want to couple the network layer to applications.

> --=20
> Regards,
> Charlie P.