From nobody Fri Aug 1 02:09: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 6C4251A0408 for ; Fri, 1 Aug 2014 02:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.518 X-Spam-Level: * X-Spam-Status: No, score=1.518 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RELAY_IS_220=2.118, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 RSUwb3IoUpjv for ; Fri, 1 Aug 2014 02:09:42 -0700 (PDT) Received: from m15-32.126.com (m15-32.126.com [220.181.15.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB021A04CA for ; Fri, 1 Aug 2014 02:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=AwItZ BYg6tghfZlg3gngN2U5Gisi+0J3TS7hd2nYOjc=; b=e6fzEVU//HBHHXvR3RUrI B0zZFkhLGTgrtfeSXqNlHO0u87r6YZ+1N788ll28A/uQm74H9Cjvjub/fxi59UW7 7yARLnOcxFxnLV+MHhBd3VUU1YDIi4H9ss/KDjSUblQxVfHvs8ZvBa5qwavQdMDq X5NJfc/gGUJ8utfm+h/nCM= Received: from huixiangren$126.com ( [72.52.91.19, 54.217.235.157, 119.9.64.5] ) by ajax-webmail-wmsvr32 (Coremail) ; Fri, 1 Aug 2014 17:09:32 +0800 (CST) X-Originating-IP: [72.52.91.19, 54.217.235.157, 119.9.64.5] Date: Fri, 1 Aug 2014 17:09:32 +0800 (CST) From: "Xiangren Hui" To: "Stan Ratliff (sratliff)" X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20140422(26738.6344) Copyright (c) 2002-2014 www.mailtech.cn 126com In-Reply-To: References: X-CM-CTRLDATA: JBYf/WZvb3Rlcl9odG09NDAwOTo4MQ== Content-Type: multipart/alternative; boundary="----=_Part_125265_1083507794.1406884172538" MIME-Version: 1.0 Message-ID: <544e5c9c.7d38.14790d4d2fa.Coremail.huixiangren@126.com> X-CM-TRANSID: IMqowGCJekFNWdtTwkIGAA--.27168W X-CM-SenderInfo: xkxl5xxdqj2vbq6rjloofrz/1tbi1A7agksK7BezcQACs4 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: http://mailarchive.ietf.org/arch/msg/manet/cbftaQlDW7Ak4QhdLnQmR-KYemE Cc: manet IETF Subject: Re: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document 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, 01 Aug 2014 09:09:44 -0000 ------=_Part_125265_1083507794.1406884172538 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGVsbG8sCgpJIGFtIGluIGZhdm91ciBvZiBhZG9wdGlvbi4KVGhlIHdvcmsgcmVsYXRlZCB0byBt dWx0aXBhdGggcm91dGluZyBmb3IgYWQgaG9jIG5ldHdvcmtzIGhhcyBiZWVuIHJlc2VhcmNoZWQg Zm9yIG1hbnkgeWVhcnMsIGJ1dCBvcGVuIHRlY2huaWNhbCBzcGVjaWZpY2F0aW9ucyBhcmUgcmVs YXRpdmVseSBtaXNzaW5nLgpUaGlzIGRvY3VtZW50IHdvdWxkIGJlIGhlbHBmdWwgdG8gYnJpbmcg dGhlIHdvcmsgdG8gbGFyZ2VyIGFuZCBpbnRlcm9wZXJhYmxlIGRlcGxveW1lbnQsIHNvIHRoYXQg bW9yZSBleHBlcmllbmNlcyBjYW4gYmUgYWNxdWlyZWQuIEFuZCBJIGJlbGlldmUgdGhlIGV4cGVy aW1lbnRhbCBkb2N1bWVudCBpcyBhIHJlYXNvbmFibGUgYXBwcm9hY2guCgpjaGVlcnMKWGlhbmdy ZW4KCgpPbiAyMDE0LTA3LTMxIDA5OjM4OjAyo6wiU3RhbiBSYXRsaWZmIChzcmF0bGlmZikiIDxz cmF0bGlmZkBjaXNjby5jb20+IHdyb3Rlo7oKV29ya2luZyBHcm91cCBQYXJ0aWNpcGFudHMgLSAK CgpUaGlzIGlzIGEgY2FsbCB0byBhZG9wdCBkcmFmdC15aS1tYW5ldC1vbHNydjItbXVsdGlwYXRo IGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4gSWYgeW91IGhhdmUgaXNzdWVzIHdpdGggdGhl IFdHIGFjY2VwdGluZyB0aGlzIGRvY3VtZW50LCBwbGVhc2Ugbm90ZSB0aGVtIG9uIHRoZSBsaXN0 IGJlZm9yZSBjbG9zZSBvZiBidXNpbmVzcyBvbiBBdWcgMTQsIDIwMTQuIFRvIHByb3Blcmx5IGdh dWdlIHRoZSBvdmVyYWxsIFdHIGludGVyZXN0IGluIHRoaXMgZHJhZnQsIEkgYXNrIHRoYXQgV0cg cGFydGljaXBhbnRzIGluIGZhdm9yIG9mIGFkb3B0aW9uIHBsZWFzZSBzdGF0ZSBzbywgb24gdGhl IGxpc3QsIHByaW9yIHRvIHRoZSBBdWcgMTQgZGVhZGxpbmUuIAoKClJlZ2FyZHMsClN0YW4KCgoK Ck9uIEp1bCAyOSwgMjAxNCwgYXQgMzoyOSBQTSwgSmlhemkgWUkgPGlldGZAamlheml5aS5jb20+ IHdyb3RlOgoKCkRlYXIgY2hhaXJzLCAKCgpUaGUgZHJhZnQgZHJhZnQteWktbWFuZXQtb2xzcnYy LW11bHRpcGF0aCBoYXMgYmVlbiBwcmVzZW50ZWQgaW4gSUVURiBtZWV0aW5nIGluIFRvcm9udG8u IApUaGVyZSBhcmUgYSBsb3Qgb2YgY29uc3RydWN0aXZlIGNvbW1lbnRzIGZyb20gdGhlIFdHIGR1 cmluZyAmIGFmdGVyIHRoZSBtZWV0aW5nLCBkZXRhaWxlZCBpbiAKCgpodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxNjYxMy5odG1sCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE2NzQwLmh0bWwK CgpUaGUgZmVlZGJhY2sgaXMgdmVyeSBoZWxwZnVsIGFuZCBleGNpdGluZy4gV2UgdGh1cyBmb2xk ZWQgdGhlbSBpbiB0aGUgbmV3IHJldmlzaW9uIG9mIHRoZSBkcmFmdCBhcyBzb29uIGFzIHBvc3Np YmxlLCB3aGljaCBpcyBub3cgYXZhaWxhYmxlIHRvZGF5IGF0IAoKCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXlpLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDIKCgpUaGlzIGRyYWZ0 IGFpbXMgZm9yIHB1YmxpY2F0aW9uIGFzIGFuICpFeHBlcmltZW50YWwqIFRyYWNrIFJGQy4gVGhl IG1vdGl2YXRpb24gb2YgYmVpbmcgYW4gZXhwZXJpbWVudGFsIFJGQyBhbmQgZXhwZXJpbWVudHMg cG9pbnRzIGhhdmUgYmVlbiBpbGx1c3RyYXRlZCBpbiAKCgpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC15aS1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTAyI3NlY3Rpb24tMS4xCgoKQXMg YSByZW1pbmRlciwgdGhlcmUgYXJlIG11bHRpcGxlIG9wZW4tc291cmNlIGltcGxlbWVudGF0aW9u cyBhdmFpbGFibGUgZm9yIHRoaXMgcHJvdG9jb2wgYW5kIHRoZXkgYXJlIG5vdyBydW5uaW5nIGFu ZCBiZWluZyB0ZXN0ZWQgaW4gZGlmZmVyZW50IG5ldHdvcmtzLiBUaGUgbXVsdGktcGF0aCByb3V0 aW5nIGhhcyBhdHRyYWN0ZWQgZ3JlYXQgaW50ZXJlc3QgZnJvbSBib3RoIGluZHVzdHJ5IGFuZCBh Y2FkZW1pYS4gCgoKV2UgYmVsaWV2ZSBpdCdzIHRpbWUgdG8gcHVibGlzaCB0aGUgcHJvdG9jb2wg YXMgYW4gZXhwZXJpbWVudGFsIFJGQywgYmFzZWQgb24gdGhlIGV4cGVyaWVuY2VzIHdlIG9idGFp bmVkIGluIHRoZSBsYXN0IGRlY2FkZS4gSXQgd291bGQgYmUgZ3JlYXQgaGVscCBmb3IgdGhlIGVu Z2luZWVycyBhbmQgcmVzZWFyY2hlcnMgaW50ZXJlc3RlZCBpbiB0aGUgbXVsdGktcGF0aCBhcHBy b2FjaCBmb3IgTUFORVQsIGFuZCBwdXNoIGl0IHRvIGEgc3RhbmRhcmQgdHJhY2sgcHJvdG9jb2wg ZXZlbnR1YWxseS4gCgoKVGhlcmVmb3JlLCB3ZSB3b3VsZCBsaWtlIHRvIGtub3cgeW91ciBvcGlu aW9uIG9uIHRoZSBkcmFmdCwgYW5kIGtpbmRseSByZXF1ZXN0IGEgY2FsbCBmb3IgV0cgYWRvcHRp b24uIAoKCkFzIGFsd2F5cywgd2UgYXJlIGxvb2tpbmcgZm9yd2FyZCB0byBmdXJ0aGVyIGNvbW1l bnRzIG9uIHRoZSBkcmFmdCBmcm9tIGFsbCB0aGUgV0cgcGFydGljaXBhbnRzLiAKCgpyZWdhcmRz CgoKSmlhemkKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K bWFuZXQgbWFpbGluZyBsaXN0Cm1hbmV0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWFuZXQKCgo= ------=_Part_125265_1083507794.1406884172538 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+SGVsbG8sPGJyPjxicj5JIGFtIGluIGZhdm91ciBvZiBh ZG9wdGlvbi4gPGJyPlRoZSB3b3JrIHJlbGF0ZWQgdG8gbXVsdGlwYXRoIHJvdXRpbmcgZm9yIGFk IGhvYyBuZXR3b3JrcyBoYXMgYmVlbiByZXNlYXJjaGVkIGZvciBtYW55IHllYXJzLCBidXQgb3Bl biB0ZWNobmljYWwgc3BlY2lmaWNhdGlvbnMgYXJlIHJlbGF0aXZlbHkgbWlzc2luZy4gPGJyPlRo aXMgZG9jdW1lbnQgd291bGQgYmUgaGVscGZ1bCB0byBicmluZyB0aGUgd29yayB0byBsYXJnZXIg YW5kIGludGVyb3BlcmFibGUgZGVwbG95bWVudCwgc28gdGhhdCBtb3JlIGV4cGVyaWVuY2VzIGNh biBiZSBhY3F1aXJlZC4gQW5kIEkgYmVsaWV2ZSB0aGUgZXhwZXJpbWVudGFsIGRvY3VtZW50IGlz IGEgcmVhc29uYWJsZSBhcHByb2FjaC4gPGJyPjxicj5jaGVlcnM8YnI+WGlhbmdyZW4gPGJyPjwv ZGl2PjxkaXY+PC9kaXY+PGRpdiBpZD0iZGl2TmV0ZWFzZU1haWxDYXJkIj48L2Rpdj48YnI+T24g MjAxNC0wNy0zMSAwOTozODowMqOsIlN0YW4gUmF0bGlmZiAoc3JhdGxpZmYpIiAmbHQ7c3JhdGxp ZmZAY2lzY28uY29tJmd0OyB3cm90ZaO6PGJyPiA8YmxvY2txdW90ZSBpZD0iaXNSZXBseUNvbnRl bnQiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsg Qk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4KCgoKCldvcmtpbmcgR3JvdXAgUGFydGljaXBh bnRzIC0mbmJzcDsKPGRpdj48YnI+CjwvZGl2Pgo8ZGl2PlRoaXMgaXMgYSBjYWxsIHRvIGFkb3B0 IGRyYWZ0LXlpLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGggYXMgYSB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50LiZuYnNwO0lmIHlvdSBoYXZlIGlzc3VlcyB3aXRoIHRoZSBXRyBhY2NlcHRpbmcgdGhpcyBk b2N1bWVudCwgcGxlYXNlIG5vdGUgdGhlbSBvbiB0aGUgbGlzdCBiZWZvcmUgY2xvc2Ugb2YgYnVz aW5lc3Mgb24gQXVnJm5ic3A7MTQsIDIwMTQuIFRvIHByb3Blcmx5IGdhdWdlIHRoZSBvdmVyYWxs IFdHIGludGVyZXN0CiBpbiB0aGlzIGRyYWZ0LCBJIGFzayB0aGF0IFdHIHBhcnRpY2lwYW50cyBp biBmYXZvciBvZiBhZG9wdGlvbiBwbGVhc2Ugc3RhdGUgc28sIG9uIHRoZSBsaXN0LCBwcmlvciB0 byB0aGUgQXVnIDE0IGRlYWRsaW5lLiZuYnNwOzwvZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+ UmVnYXJkcyw8L2Rpdj4KPGRpdj5TdGFuPC9kaXY+CjxkaXY+PGJyPgo8L2Rpdj4KPGRpdj48YnI+ CjxkaXY+CjxkaXY+T24gSnVsIDI5LCAyMDE0LCBhdCAzOjI5IFBNLCBKaWF6aSBZSSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlldGZAamlheml5aS5jb20iPmlldGZAamlheml5aS5jb208L2E+Jmd0OyB3 cm90ZTo8L2Rpdj4KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+CjxkaXYgZGlyPSJsdHIiPgo8ZGl2PkRlYXIgY2hhaXJzLCZuYnNw OzwvZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+VGhlIGRyYWZ0IGRyYWZ0LXlpLW1hbmV0LW9s c3J2Mi1tdWx0aXBhdGggaGFzIGJlZW4gcHJlc2VudGVkIGluIElFVEYgbWVldGluZyBpbiBUb3Jv bnRvLiZuYnNwOzwvZGl2Pgo8ZGl2PlRoZXJlIGFyZSBhIGxvdCBvZiBjb25zdHJ1Y3RpdmUgY29t bWVudHMgZnJvbSB0aGUgV0cgZHVyaW5nICZhbXA7IGFmdGVyIHRoZSBtZWV0aW5nLCBkZXRhaWxl ZCBpbiZuYnNwOzwvZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+PGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTY2MTMuaHRtbCI+ aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTY2 MTMuaHRtbDwvYT48L2Rpdj4KPGRpdj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxNjc0MC5odG1sIj5odHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxNjc0MC5odG1sPC9hPjwvZGl2 Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+VGhlIGZlZWRiYWNrIGlzIHZlcnkgaGVscGZ1bCBhbmQg ZXhjaXRpbmcuIFdlIHRodXMgZm9sZGVkIHRoZW0gaW4gdGhlIG5ldyByZXZpc2lvbiBvZiB0aGUg ZHJhZnQgYXMgc29vbiBhcyBwb3NzaWJsZSwgd2hpY2ggaXMgbm93IGF2YWlsYWJsZSB0b2RheSBh dCZuYnNwOzwvZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQteWktbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0wMiI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWktbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0wMjwv YT48L2Rpdj4KPGRpdj48YnI+CjwvZGl2Pgo8ZGl2PlRoaXMgZHJhZnQgYWltcyBmb3IgcHVibGlj YXRpb24gYXMgYW4gKkV4cGVyaW1lbnRhbCogVHJhY2sgUkZDLiBUaGUgbW90aXZhdGlvbiBvZiBi ZWluZyBhbiBleHBlcmltZW50YWwgUkZDIGFuZCBleHBlcmltZW50cyBwb2ludHMgaGF2ZSBiZWVu IGlsbHVzdHJhdGVkIGluJm5ic3A7PC9kaXY+CjxkaXY+PGJyPgo8L2Rpdj4KPGRpdj48YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15aS1tYW5ldC1vbHNydjItbXVsdGlw YXRoLTAyI3NlY3Rpb24tMS4xIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15aS1t YW5ldC1vbHNydjItbXVsdGlwYXRoLTAyI3NlY3Rpb24tMS4xPC9hPjwvZGl2Pgo8ZGl2Pjxicj4K PC9kaXY+CjxkaXY+QXMgYSByZW1pbmRlciwgdGhlcmUgYXJlIG11bHRpcGxlIG9wZW4tc291cmNl IGltcGxlbWVudGF0aW9ucyBhdmFpbGFibGUgZm9yIHRoaXMgcHJvdG9jb2wgYW5kIHRoZXkgYXJl IG5vdyBydW5uaW5nIGFuZCBiZWluZyB0ZXN0ZWQgaW4gZGlmZmVyZW50IG5ldHdvcmtzLiBUaGUg bXVsdGktcGF0aCByb3V0aW5nIGhhcyBhdHRyYWN0ZWQgZ3JlYXQgaW50ZXJlc3QgZnJvbSBib3Ro IGluZHVzdHJ5IGFuZCBhY2FkZW1pYS4mbmJzcDs8L2Rpdj4KPGRpdj48YnI+CjwvZGl2Pgo8ZGl2 PldlIGJlbGlldmUgaXQncyB0aW1lIHRvIHB1Ymxpc2ggdGhlIHByb3RvY29sIGFzIGFuIGV4cGVy aW1lbnRhbCBSRkMsIGJhc2VkIG9uIHRoZSBleHBlcmllbmNlcyB3ZSBvYnRhaW5lZCBpbiB0aGUg bGFzdCBkZWNhZGUuIEl0IHdvdWxkIGJlIGdyZWF0IGhlbHAgZm9yIHRoZSBlbmdpbmVlcnMgYW5k IHJlc2VhcmNoZXJzIGludGVyZXN0ZWQgaW4gdGhlIG11bHRpLXBhdGggYXBwcm9hY2ggZm9yIE1B TkVULCBhbmQgcHVzaCBpdCB0byBhIHN0YW5kYXJkCiB0cmFjayBwcm90b2NvbCBldmVudHVhbGx5 LiZuYnNwOzwvZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+VGhlcmVmb3JlLCB3ZSB3b3VsZCBs aWtlIHRvIGtub3cgeW91ciBvcGluaW9uIG9uIHRoZSBkcmFmdCwgYW5kIGtpbmRseSByZXF1ZXN0 IGEgY2FsbCBmb3IgV0cgYWRvcHRpb24uJm5ic3A7PC9kaXY+CjxkaXY+PGJyPgo8L2Rpdj4KPGRp dj5BcyBhbHdheXMsIHdlIGFyZSBsb29raW5nIGZvcndhcmQgdG8gZnVydGhlciBjb21tZW50cyBv biB0aGUgZHJhZnQgZnJvbSBhbGwgdGhlIFdHIHBhcnRpY2lwYW50cy4mbmJzcDs8L2Rpdj4KPGRp dj48YnI+CjwvZGl2Pgo8ZGl2PnJlZ2FyZHM8L2Rpdj4KPGRpdj48YnI+CjwvZGl2Pgo8ZGl2Pkpp YXppPC9kaXY+CjwvZGl2PgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4KbWFuZXQgbWFpbGluZyBsaXN0PGJyPgo8YSBocmVmPSJtYWlsdG86bWFuZXRA aWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tYW5ldDxicj4KPC9ibG9ja3F1b3RlPgo8L2Rpdj4KPGJyPgo8L2Rpdj4K Cgo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxicj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+ PHNwYW4gaWQ9Im5ldGVhc2VfbWFpbF9mb290ZXIiPjwvc3Bhbj48L3NwYW4+ ------=_Part_125265_1083507794.1406884172538-- From nobody Mon Aug 4 05:34: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 19D0F1B2AAC for ; Mon, 4 Aug 2014 05:34:01 -0700 (PDT) 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_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 8ZA-EoelJ4gi for ; Mon, 4 Aug 2014 05:33:58 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B101B2A99 for ; Mon, 4 Aug 2014 05:33:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,798,1400022000"; d="scan'208,217";a="392130444" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 04 Aug 2014 13:33:57 +0100 X-IronPort-AV: E=Sophos; i="5.01,798,1400022000"; d="scan'208,217"; a="67548535" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 04 Aug 2014 13:34:08 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Mon, 4 Aug 2014 13:34:08 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" , "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" Thread-Topic: Request WGLC for draft-ietf-manet-ibs-02 Thread-Index: Ac+v4ECM+8CUAYujTiu/Ld3gnz2t5A== Date: Mon, 4 Aug 2014 12:34:09 +0000 Message-ID: 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1F45EGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rkkIvZtNGzlcCykXBf1sYXl87p8 Subject: [manet] Request WGLC for draft-ietf-manet-ibs-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, 04 Aug 2014 12:34:01 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1F45EGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable (Trying again with a better distribution list. Apologies to those who will = now have seen it twice.) As the subject line says, I'd like to request WGLC for draft-ietf-manet-ibs= -02. I think this document has had positive support from several people, no= ne against, and the latest version has taken on board comments from then on= e detailed review. The only outstanding question, which I think falls to Adrian to play Solomo= n, is whether the document should be marked as updating RFC 7182 or not. I = took the value yes as I thought it stretched ever so slightly more than jus= t an allocation, but I really don't care one way or the other. We only need= an answer by end of WGLC, not before starting it. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1F45EGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

(Trying again with a b= etter distribution list. Apologies to those who will now have seen it twice= .)

 

As the subject line says, I’d like to request = WGLC for draft-ietf-manet-ibs-02. I think this document has had positive su= pport from several people, none against, and the latest version has taken o= n board comments from then one detailed review.

 

The only outstanding question, which I think falls t= o Adrian to play Solomon, is whether the document should be marked as updat= ing RFC 7182 or not. I took the value yes as I thought it stretched ever so= slightly more than just an allocation, but I really don’t care one way or the other. We only need an answer= by end of WGLC, not before starting it.

 

-- <= /p>

Christopher Dearlove

Senior Principal Engin= eer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

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

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D1F45EGLKXM0002VGREEN_-- From nobody Mon Aug 4 05:38: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 D7F6A1B2AB2 for ; Mon, 4 Aug 2014 05:38:58 -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 UKxSYxrMFu6T for ; Mon, 4 Aug 2014 05:38:56 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BCA1B2AAD for ; Mon, 4 Aug 2014 05:38:56 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id q9so4003772ykb.41 for ; Mon, 04 Aug 2014 05:38:56 -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=UrrHL6ir1dn21Y3pCX+mHi7bbpx3VaNzrLGK9KPeghY=; b=QzW20gKYgiFZX0aZsflNFZsr3Ln5eLy7Ds7kAYAfNpQPS8SG99m5aXYR+eI8bvgpc2 2EWgOk5K1pC8LeuYmG7PhlxVb/toSTRSTxkrfUWgZdCOkPFGw3OTaH3kjxawKAXViQOD PeoqVvAh5BEA6peFiF2SmtT5G3DA2z4ycmXKRFG+JCmq4zDDPGAdzYp7bINy6jNO6bJP NHsFUhhMLXeolyL7HuDXwwTKDCpjpkoRQlNZA4HSb3QNq3a9NnyVc1hcxXX5rd5a3GNw b4G+BE7g969/fx/TTMFLCtUFppeihaf7vtb5D9baRFxqcuWh++RiyI1k8oag+8IIULEU qabA== MIME-Version: 1.0 X-Received: by 10.236.116.202 with SMTP id g50mr4232340yhh.147.1407155935715; Mon, 04 Aug 2014 05:38:55 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Mon, 4 Aug 2014 05:38:55 -0700 (PDT) In-Reply-To: <02e501cfabfa$7439c330$5cad4990$@olddog.co.uk> References: <02e501cfabfa$7439c330$5cad4990$@olddog.co.uk> Date: Mon, 4 Aug 2014 14:38:55 +0200 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=20cf3036388db1296d04ffcd058b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Xh5t6liymS3F1uUuGv-JInfPjaU Cc: manet-chairs@tools.ietf.org, manet-ads , manet Subject: Re: [manet] Duh-oh [Was: request for WG adoption: draft-yi-manet-olsrv2-multipath] 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, 04 Aug 2014 12:38:59 -0000 --20cf3036388db1296d04ffcd058b Content-Type: text/plain; charset=UTF-8 There was a draft for multicast presented in MANET WG meeting asking for adoption. Does your message below mean that any multicast draft prefered to be reviewed by PIM WG. AB On Wed, Jul 30, 2014 at 3:30 PM, Adrian Farrel wrote: > In an attempt to prove that I am human I have just screwed up :-) > > > > Thanks to the anonymous benefactor who pointed out that "multi-path" is > not "multi-cast". > > > > Feeling a bit stupid. > > > > Please ignore that part of my previous email that requested PIM WG review. > > > > > > > > Adrian > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Adrian Farrel > *Sent:* 30 July 2014 00:01 > *To:* 'Jiazi YI'; 'manet'; manet-chairs@tools.ietf.org; 'manet-ads' > *Subject:* Re: [manet] request for WG adoption: > draft-yi-manet-olsrv2-multipath > > > > Jiazi, > > > > I want to thank you for the responsible approach of labelling this > Experimental. > > > > Authors, I would welcome it if you formally asked the PIM working group to > provide multicast review of this work. > > > > Chairs as/when you poll for adoption, please make sure that that cross-WG > review has taken place and that any feedback is considered. > > > > Thanks! > > Adrian > > > > *From:* yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] *On Behalf Of *Jiazi > YI > *Sent:* 29 July 2014 20:30 > *To:* manet; ; manet-ads > *Subject:* request for WG adoption: draft-yi-manet-olsrv2-multipath > > > > Dear chairs, > > > > The draft draft-yi-manet-olsrv2-multipath has been presented in IETF > meeting in Toronto. > > There are a lot of constructive comments from the WG during & after the > meeting, detailed in > > > > http://www.ietf.org/mail-archive/web/manet/current/msg16613.html > > http://www.ietf.org/mail-archive/web/manet/current/msg16740.html > > > > The feedback is very helpful and exciting. We thus folded them in the new > revision of the draft as soon as possible, which is now available today at > > > > http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02 > > > > This draft aims for publication as an *Experimental* Track RFC. The > motivation of being an experimental RFC and experiments points have been > illustrated in > > > > http://tools.ietf.org/html/draft-yi-manet-olsrv2-multipath-02#section-1.1 > > > > As a reminder, there are multiple open-source implementations available > for this protocol and they are now running and being tested in different > networks. The multi-path routing has attracted great interest from both > industry and academia. > > > > We believe it's time to publish the protocol as an experimental RFC, based > on the experiences we obtained in the last decade. It would be great help > for the engineers and researchers interested in the multi-path approach for > MANET, and push it to a standard track protocol eventually. > > > > Therefore, we would like to know your opinion on the draft, and kindly > request a call for WG adoption. > > > > As always, we are looking forward to further comments on the draft from > all the WG participants. > > > > regards > > > > Jiazi > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf3036388db1296d04ffcd058b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There was a draft for multicast presented in MANET WG= meeting asking for adoption. Does your message below mean that any multica= st draft=C2=A0prefered to=C2=A0be reviewed by PIM WG.
=C2=A0
AB

On Wed, Jul 30, 2014 at 3:30 PM, Adrian Farrel <= span dir=3D"ltr"><adrian@olddog.co.uk> wrote:

In an attempt to prove that I a= m human I have just screwed up :-)

=C2=A0

Thanks to the anonymous benefac= tor who pointed out that "multi-path" is not "multi-cast&quo= t;.

=C2=A0

Feeling a bit stupid.=

=C2=A0

Please ignore that part of my p= revious email that requested PIM WG review.

=C2=A0

<sigh>

=C2=A0

Adrian

=C2=A0

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: 30 July 2014 00:01
To: 'Jiazi YI'; 'mane= t'; ma= net-chairs@tools.ietf.org; 'manet-ads'
Subject: Re: [= manet] request for WG adoption: draft-yi-manet-olsrv2-multipath

=C2=A0

Jiazi,

=C2=A0

I want to thank you for the res= ponsible approach of labelling this Experimental.

=C2=A0

Authors, I would welcome it if = you formally asked the PIM working group to provide multicast review of thi= s work.

=C2=A0

Chairs as/when you poll for ado= ption, please make sure that that cross-WG review has taken place and that = any feedback is considered.

=C2=A0

Thanks!

Adrian

=C2=A0

=C2=A0

Dear chairs,=C2=A0

=C2=A0

The draft draft-yi-manet-olsrv2-multipath has been p= resented in IETF meeting in Toronto.=C2=A0

There are a lot of constructive comments from the WG= during & after the meeting, detailed in=C2=A0

=C2=A0

=C2=A0

The feedback is very helpful and exciting. We thus f= olded them in the new revision of the draft as soon as possible, which is n= ow available today at=C2=A0

=C2=A0

=C2=A0

This draft aims for publication as an *Experimental*= Track RFC. The motivation of being an experimental RFC and experiments poi= nts have been illustrated in=C2=A0

=C2=A0

http://tools.ietf.org/h= tml/draft-yi-manet-olsrv2-multipath-02#section-1.1

=C2=A0

As a reminder, there are multiple open-source implem= entations available for this protocol and they are now running and being te= sted in different networks. The multi-path routing has attracted great inte= rest from both industry and academia.=C2=A0

=C2=A0

We believe it's time to publish the protocol as = an experimental RFC, based on the experiences we obtained in the last decad= e. It would be great help for the engineers and researchers interested in t= he multi-path approach for MANET, and push it to a standard track protocol = eventually.=C2=A0

=C2=A0

Therefore, we would like to know your opinion on the= draft, and kindly request a call for WG adoption.=C2=A0

<= /div>

=C2=A0

As always, we are looking forward to further comment= s on the draft from all the WG participants.=C2=A0

=C2=A0

regards

=C2=A0

Jiazi


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


--20cf3036388db1296d04ffcd058b-- From nobody Wed Aug 6 10:07: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 580651A0B04; Wed, 6 Aug 2014 10:07: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 hOD-qMIN7VvL; Wed, 6 Aug 2014 10:07:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8D01A039D; Wed, 6 Aug 2014 10:07:31 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140806170731.5242.91793.idtracker@ietfa.amsl.com> Date: Wed, 06 Aug 2014 10:07:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/aLvtE7gXpU70a3EoBRRS0dLIzPs Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc6779bis-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, 06 Aug 2014 17:07: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 : Definition of Managed Objects for the Neighborhood Discovery Protocol Authors : Ulrich Herberg Robert G. Cole Ian D Chakeres Thomas Heide Clausen Filename : draft-ietf-manet-rfc6779bis-00.txt Pages : 70 Date : 2014-08-06 Abstract: This document revises, extends, and replaces RFC 6779. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6779bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-rfc6779bis-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 Aug 6 10:12: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 79A0A1A0AFA for ; Wed, 6 Aug 2014 10:12:19 -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 Zw8zYOAzbSiw for ; Wed, 6 Aug 2014 10:12:17 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1CE1A037B for ; Wed, 6 Aug 2014 10:12:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EAF332403B9 for ; Wed, 6 Aug 2014 10:12:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id 09A7F24024A for ; Wed, 6 Aug 2014 10:12:15 -0700 (PDT) From: Thomas Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_B00353A7-F77E-43BD-A878-CA80E16F0139" Date: Wed, 6 Aug 2014 19:12:13 +0200 References: <20140806170731.5242.75177.idtracker@ietfa.amsl.com> To: manet IETF Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zZ-QLIXu7t2hID8mpEIbcBqOa4k Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-rfc6779bis-00.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, 06 Aug 2014 17:12:19 -0000 --Apple-Mail=_B00353A7-F77E-43BD-A878-CA80E16F0139 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear All, This revision is exactly identical to the = draft-clausen-manet-rfc6779bis-00, for which WG adoption was called. As = a reminder, this serves to update the NHDP-MIB module as necessitated by = by draft-ietf-manet-nhdp-optimization. A revision of draft-ietf-manet-nhdp-optimization, to remove the =93MIB = considerations=94 section and instead reference = draft-ietf-manet-rfc6779bis-00, will be submitted shortly =97 after = which, as I believe we discussed on the list quite recently, the plan is = to WGLC both documents, and send them onwards in the process. Respectfully, Thomas Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-manet-rfc6779bis-00.txt > Date: August 6, 2014 at 19:07:31 GMT+2 > To: Ian D Chakeres , "Robert Cole" = , Ulrich Herberg , "Ian = Chakeres" , "Thomas H. Clausen" = , "Robert G. Cole" , = "Ulrich Herberg" , Thomas Heide Clausen = >=20 >=20 > A new version of I-D, draft-ietf-manet-rfc6779bis-00.txt > has been successfully submitted by Thomas Heide Clausen and posted to = the > IETF repository. >=20 > Name: draft-ietf-manet-rfc6779bis > Revision: 00 > Title: Definition of Managed Objects for the = Neighborhood Discovery Protocol > Document date: 2014-08-06 > Group: manet > Pages: 70 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-manet-rfc6779bis-00.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6779bis/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-manet-rfc6779bis-00 >=20 >=20 > Abstract: > This document revises, extends, and replaces RFC 6779. It defines a > portion of the Management Information Base (MIB) for use with = network > management protocols in the Internet community. In particular, it > describes objects for configuring parameters of the Neighborhood > Discovery Protocol (NHDP) process on a router. The MIB module > defined in this document, denoted NHDP-MIB, also reports state, > performance information, and notifications about NHDP. This > additional state and performance information is useful to > troubleshoot problems and performance issues during neighbor > discovery. >=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=_B00353A7-F77E-43BD-A878-CA80E16F0139 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = All,

This revision is exactly identical to the = draft-clausen-manet-rfc6779bis-00, for which WG adoption was called. As = a reminder, this serves to update the NHDP-MIB module as necessitated by = by draft-ietf-manet-nhdp-optimization.

A = revision of draft-ietf-manet-nhdp-optimization, to remove the =93MIB = considerations=94 section and instead = reference draft-ietf-manet-rfc6779bis-00, will be submitted shortly = =97 after which, as I believe we discussed on the list quite recently, = the plan is to WGLC both documents, and send them onwards in the = process.

Respectfully,

T= homas

Begin forwarded message:

Subject: = New Version = Notification for = draft-ietf-manet-rfc6779bis-00.txt
Date: August 6, 2014 at 19:07:31 = GMT+2
To: = Ian D Chakeres = <ian.chakeres@gmail.com>, = "Robert Cole" <robert.g.cole@us.army.mil>= ;, Ulrich Herberg <ulrich@herberg.name>, "Ian = Chakeres" <ian.chakeres@gmail.com>, = "Thomas H. Clausen" <T.Clausen@computer.org>, = "Robert G. Cole" <robert.g.cole@us.army.mil>= ;, "Ulrich Herberg" <ulrich@herberg.name>, Thomas = Heide Clausen <t.clausen@computer.org>
<= /span>


A new version of I-D, = draft-ietf-manet-rfc6779bis-00.txt
has been successfully submitted by = Thomas Heide Clausen and posted to the
IETF = repository.

Name: = draft-ietf-manet-rfc6779bis
Revision: = 00
Title: Definition of Managed Objects for = the Neighborhood Discovery Protocol
Document date: = 2014-08-06
Group: manet
Pages: = 70
URL: =            http://www.ietf.org/internet-drafts/draft-ietf-manet-rfc6779bis-00.t= xt
Status:         htt= ps://datatracker.ietf.org/doc/draft-ietf-manet-rfc6779bis/
Htmlized= :       http://= tools.ietf.org/html/draft-ietf-manet-rfc6779bis-00


Abstract= :
  This document revises, extends, and replaces RFC 6779. =  It defines a
  portion of the Management Information = Base (MIB) for use with network
  management protocols in = the Internet community.  In particular, it
=   describes objects for configuring parameters of the = Neighborhood
  Discovery Protocol (NHDP) process on a = router.  The MIB module
  defined in this document, = denoted NHDP-MIB, also reports state,
  performance = information, and notifications about NHDP.  This
=   additional state and performance information is useful = to
  troubleshoot problems and performance issues during = neighbor
  discovery.




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=_B00353A7-F77E-43BD-A878-CA80E16F0139-- From nobody Wed Aug 6 11:28: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 E0FD61A0390 for ; Wed, 6 Aug 2014 11:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 F27CfVIJbhxD for ; Wed, 6 Aug 2014 11:28:45 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6AC01A001D for ; Wed, 6 Aug 2014 11:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=179; q=dns/txt; s=iport; t=1407349725; x=1408559325; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=YBzAwp1yHNtE3EZ1U0e6wKs+G/RNt6WFd3kQEr5JKZo=; b=MjBtGaz6jG2ZLoBdQBKChpi1Ms3pd6o/uO3Pj/L5xAjmD9D6a8I23IzT 2WeI0j7z9jWGFdLclATGNc5yNTJ1B3yiIlphp8N4C/ZsW9BRON6W0vRoH PbowpTjQxL+q0v0M6FwE1GxF4Mn92OppjTtnE0vbpRLaFzLS+a7pW9dHc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncGAIBz4lOtJA2N/2dsb2JhbABagw2BLY0qx1wWd4QKHR1RAT5CJwSIVZ1tpWsXkwKBHAWcEpRlg1SCMg X-IronPort-AV: E=Sophos;i="5.01,813,1400025600"; d="scan'208";a="345365818" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP; 06 Aug 2014 18:28:45 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s76ISimw023426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Aug 2014 18:28:45 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.126]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 13:28:44 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: Working Group Last Call for draft-ietf-manet-ibs Thread-Index: AQHPsaRBnD1To7UD6kW27BaP/PYZsQ== Date: Wed, 6 Aug 2014 18:28:44 +0000 Message-ID: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] 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/X-qOuO_YX0AE7NxxUNkLYwaxQeQ Subject: [manet] Working Group Last Call for draft-ietf-manet-ibs 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, 06 Aug 2014 18:28:47 -0000 Working group participants,=20 This is a Last Call on the above document. Please review and note any issue= s on the list on or before August 20, 2014.=20 Regards, Stan= From nobody Wed Aug 6 12:44:19 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 8466C1A0115 for ; Wed, 6 Aug 2014 12:44:14 -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 JoQKTw9B8bu9 for ; Wed, 6 Aug 2014 12:44:10 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531A91A0101 for ; Wed, 6 Aug 2014 12:44:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 320DC240458; Wed, 6 Aug 2014 12:44:10 -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 7C77C24023D; Wed, 6 Aug 2014 12:44:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> Date: Wed, 6 Aug 2014 21:44:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <13FC52BB-C8FD-47AF-95B2-474D1A091903@thomasclausen.org> References: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> To: "Stan Ratliff (sratliff)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/uLMEjm4U_KFvzkGJtMw_S6PeIDM Cc: manet IETF Subject: Re: [manet] Working Group Last Call for draft-ietf-manet-ibs 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, 06 Aug 2014 19:44:14 -0000 Stan, All, I've previously given my feedback to this document on the list, which the au= thor took into account in producing the current revision.=20 I am fully satisfied with this version, and support its publication as std. t= rack RFC wholeheartedly. Best, Thomas Sent from my iPad > On 06 Aug 2014, at 20:28, "Stan Ratliff (sratliff)" w= rote: >=20 > Working group participants,=20 >=20 > This is a Last Call on the above document. Please review and note any issu= es on the list on or before August 20, 2014.=20 >=20 > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Aug 6 13:03: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 C309F1B283D for ; Wed, 6 Aug 2014 13:03:46 -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 8AHM8aelf8sO for ; Wed, 6 Aug 2014 13:03:45 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F5F1B282B for ; Wed, 6 Aug 2014 13:03:44 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so3152272wgg.12 for ; Wed, 06 Aug 2014 13:03:43 -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=1a54g8Wkpu4hF8Bm29Qz0zeFWbvZZk1Y3djE6XNxCBg=; b=Jnz0iY/Ms4ZZran21qiRx74t4Wwe5DFUP0rWt2acgAv8v5e46SeKTpR+JX2W9djwuY fQozqiEIs90Uy9OKGM6d7TiDwBPl/ECu+vdrGvAofrcJozAiLbQEfodzWqh+JzIf1ZT6 2ECttjCaKSFD/Nmsk+HlVh0pp3GeqGmKYU9ct707aeI/cXi6bmZPipNrH3Kold2ORzpy MPKTDGAFphiElMhYV0ZsNP49ZCTHlZfFp/Gy6dpyabxR+Pum24RwrZacRuAch3iqGpxv jrLBk8YMkftc0oZ8aAu+6Q8lO4w9QnccEiSUqZbYigERRiPjFFufa+47MB3lcq542Tou rH+g== MIME-Version: 1.0 X-Received: by 10.194.95.166 with SMTP id dl6mr18849486wjb.115.1407355423517; Wed, 06 Aug 2014 13:03:43 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Wed, 6 Aug 2014 13:03:43 -0700 (PDT) In-Reply-To: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> References: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> Date: Wed, 6 Aug 2014 22:03:43 +0200 X-Google-Sender-Auth: _wBG9xDSPHZOGLE8Chtnp6uIf1Q Message-ID: From: Jiazi YI To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=047d7bb0398217712404fffb7837 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GmXgmzfBBNQojrB6LdA_0gmQH0E Cc: manet IETF Subject: Re: [manet] Working Group Last Call for draft-ietf-manet-ibs 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, 06 Aug 2014 20:03:47 -0000 --047d7bb0398217712404fffb7837 Content-Type: text/plain; charset=UTF-8 Hi, There is an Appendix A: example TBD I don't know it's "to be done", or "to be dropped"? :-P best Jiazi On Wed, Aug 6, 2014 at 8:28 PM, Stan Ratliff (sratliff) wrote: > Working group participants, > > This is a Last Call on the above document. Please review and note any > issues on the list on or before August 20, 2014. > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7bb0398217712404fffb7837 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

There is an=C2=A0
<= br>
Appendix A: example=C2=A0
TBD

<= div>I don't know it's "to be done", or "to be droppe= d"? :-P

best

Jiazi


On Wed, Aug 6, 2014 a= t 8:28 PM, Stan Ratliff (sratliff) <sratliff@cisco.com> wro= te:
Working group participants,

This is a Last Call on the above document. Please review and note any issue= s on the list on or before August 20, 2014.

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

--047d7bb0398217712404fffb7837-- From nobody Wed Aug 6 13:50: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 CC95B1A01DD for ; Wed, 6 Aug 2014 13:50:29 -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 jsiPcWPT5r2F for ; Wed, 6 Aug 2014 13:50:24 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04781A01EB for ; Wed, 6 Aug 2014 13:50:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9183D24024A; Wed, 6 Aug 2014 13:50:24 -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 1329C24023D; Wed, 6 Aug 2014 13:50:24 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-40D3661A-2C38-491C-98D5-F3E5E8CF9985 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Wed, 6 Aug 2014 22:50:21 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> To: Jiazi YI Archived-At: http://mailarchive.ietf.org/arch/msg/manet/W62kzT7cZn69KvoyabsPnI25FEU Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Working Group Last Call for draft-ietf-manet-ibs 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, 06 Aug 2014 20:50:30 -0000 --Apple-Mail-40D3661A-2C38-491C-98D5-F3E5E8CF9985 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Jiazi, Try to look at the latest version: http://tools.ietf.org/html/draft-ietf-manet-ibs-02 ;) Thomas Sent from my iPad > On 06 Aug 2014, at 22:03, Jiazi YI wrote: >=20 > Hi,=20 >=20 > There is an=20 >=20 > Appendix A: example=20 > TBD >=20 > I don't know it's "to be done", or "to be dropped"? :-P >=20 > best >=20 > Jiazi >=20 >=20 >> On Wed, Aug 6, 2014 at 8:28 PM, Stan Ratliff (sratliff) wrote: >> Working group participants, >>=20 >> This is a Last Call on the above document. Please review and note any iss= ues on the list on or before August 20, 2014. >>=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 --Apple-Mail-40D3661A-2C38-491C-98D5-F3E5E8CF9985 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Jiazi,

Try to look at the latest versio= n:


;)

Thomas
Sent from m= y iPad

On 06 A= ug 2014, at 22:03, Jiazi YI <ietf@jia= ziyi.com> wrote:

Hi, 

<= div>There is an 

Appendix A: example 
TBD

I don't know it's "to be done", or "to b= e dropped"? :-P

best

Jiazi


On Wed, Aug 6, 2014 at 8= :28 PM, Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:
Working group participants,

This is a Last Call on the above document. Please review and note any issues= on the list on or before August 20, 2014.

Regards,
Stan
_______________________________________________
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-40D3661A-2C38-491C-98D5-F3E5E8CF9985-- From nobody Wed Aug 6 14:02: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 7E3291A016C for ; Wed, 6 Aug 2014 14:01:56 -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 anPjcnxT7yNe for ; Wed, 6 Aug 2014 14:01:54 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55971A013B for ; Wed, 6 Aug 2014 14:01:53 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so3954359wib.14 for ; Wed, 06 Aug 2014 14:01:52 -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=xJHhXC2ZGfrzQ9xnaLgWnAdTNkWm2EOwrWJ/hIxase4=; b=U9YqJlybCk72C7gzwmWFA2kO/X/kHazsv3jI1U7+aK0llRFPesz3OZQDJoEPPwMdAK Rutz4s+qJGf8U104nU1LhBbvK5T+VWFN4CPLZ4BYGUbunuRBECwaZ9q5Ndn8+NlE+D1n celQA9NKoUCwcVoLeWQWlbpdRf7PY+0OLwFo3Nc8XFruERuqsOFwmpoKtS+MpzTkz9Z0 QnAwOIm+wUdBSrR73TFP8dFKkqbiv5gOajsvntq0EQ39/+RSL2NvZS+hCKb/v90wuKoi Iy9yogmmG2z1nudk8oysIhQziWMhp5umKz1qUJS5w3B2pXcaGRMuPAEoJ8jiQ0GS7uEz h74w== X-Received: by 10.180.11.72 with SMTP id o8mr27742721wib.71.1407358912528; Wed, 06 Aug 2014 14:01:52 -0700 (PDT) Received: from [192.168.254.5] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id 19sm5001799wjz.3.2014.08.06.14.01.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 14:01:50 -0700 (PDT) References: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2630F608-6A91-4AC2-AEAD-574C54EAF6F8 Content-Transfer-Encoding: 7bit Message-Id: <89D7005E-E8B5-44A1-B97C-C1B52EE81FB3@gmail.com> X-Mailer: iPhone Mail (11D257) From: Christopher Dearlove Date: Wed, 6 Aug 2014 22:01:48 +0100 To: Jiazi YI Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hyK2P-0USZziTXiSvasQn3R3M3Y Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Working Group Last Call for draft-ietf-manet-ibs 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, 06 Aug 2014 21:01:56 -0000 --Apple-Mail-2630F608-6A91-4AC2-AEAD-574C54EAF6F8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I don't think you are looking at the latest version. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 6 Aug 2014, at 21:03, Jiazi YI wrote: >=20 > Hi,=20 >=20 > There is an=20 >=20 > Appendix A: example=20 > TBD >=20 > I don't know it's "to be done", or "to be dropped"? :-P >=20 > best >=20 > Jiazi >=20 >=20 >> On Wed, Aug 6, 2014 at 8:28 PM, Stan Ratliff (sratliff) wrote: >> Working group participants, >>=20 >> This is a Last Call on the above document. Please review and note any iss= ues on the list on or before August 20, 2014. >>=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 --Apple-Mail-2630F608-6A91-4AC2-AEAD-574C54EAF6F8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I don't think you are looking at the latest version.

-- 
Christopher Dearlove

On 6 Aug 2014, at 21:03, Jiazi YI <ietf@jiaziyi.com> wrote:

Hi, 

There is an 

Appendix A: example 
TBD

I don't know it's "to be done", or "to be dropped"? :-P

best

Jiazi


On Wed, Aug 6, 2014 at 8:28 PM, Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:
Working group participants,

This is a Last Call on the above document. Please review and note any issues on the list on or before August 20, 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
--Apple-Mail-2630F608-6A91-4AC2-AEAD-574C54EAF6F8-- From nobody Wed Aug 6 14:07: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 8F0571A02BE for ; Wed, 6 Aug 2014 14:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 Q2Cnh2ySxhgE for ; Wed, 6 Aug 2014 14:07:41 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42211A0263 for ; Wed, 6 Aug 2014 14:07:40 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so5030041vcb.33 for ; Wed, 06 Aug 2014 14:07:39 -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=KyMKQH51HVuQCAa++Nzs94+jESjyBIlkDy+gpojRwxA=; b=OPQcHBf/xeP5vSMLLP6XigWnOmccH0zMNlUqfEbS0GsRqoQxxaHNmqX2/w2PO1+MN7 afs8Dp8LwUP7yhw+MV05i1HFvTWX0ktqfuGC0pFtIMDuYlQ6zJ1j6AkaE3vfp0Ik8kAl qlVRQ9TMqtiPOc1xE+z04Wio/1TRGp/SlzjEk= 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=KyMKQH51HVuQCAa++Nzs94+jESjyBIlkDy+gpojRwxA=; b=IMkvZWsjybNlVJyOyL5JpPG0prlHhVMnqF1+v47Ke7p4didD+VYn1ZQ0TjI5tTb1eb he4+V1c9rKeXzohM5ZDR+s0Rj62pHtPePnZPLqz9JNZ7a3bJZcsODEkU4z6oEawhzltL VdKr8bZTPd+ixr/rc/KVvBwCKgrBwJWsj1dqbSis5O8EjNNn3EB7dsEbc1Xq0glDxBGI 4nsGNhacQpExAyCe/sE0fkA4p75rsAfxGCUVpaxUmpWzb38SgF4BvAsSUOiEX5lsevq7 S7Q+n16nqLE0u45g9fwU2i9xv5C4+MAUbVP9GT09g78sV7PdGASK2VBJKXa78xbYz+Vx 9M8g== X-Gm-Message-State: ALoCoQkhXidJT5YyvmwisPLfkSoceIkI3geKNhcB2mdJlSPUiE3mXHsFWoHWnOFI2qx9+GL3CEq4 MIME-Version: 1.0 X-Received: by 10.52.28.231 with SMTP id e7mr10864144vdh.55.1407359259711; Wed, 06 Aug 2014 14:07:39 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Wed, 6 Aug 2014 14:07:39 -0700 (PDT) In-Reply-To: <13FC52BB-C8FD-47AF-95B2-474D1A091903@thomasclausen.org> References: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> <13FC52BB-C8FD-47AF-95B2-474D1A091903@thomasclausen.org> Date: Wed, 6 Aug 2014 14:07:39 -0700 Message-ID: From: Ulrich Herberg To: Thomas Clausen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/TMIQjckDhKXFJr57JV6Zpuw_B1U Cc: manet IETF Subject: Re: [manet] Working Group Last Call for draft-ietf-manet-ibs 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, 06 Aug 2014 21:07:45 -0000 I am in favor of publication of this document. Minor comments: - s/additinal/additional/ - add comma after e.g.: "(e.g. 0 for HELLO)" - in the example, isn't an IP source address of 192.0.2.0 unusual? Regards Ulrich On Wed, Aug 6, 2014 at 12:44 PM, Thomas Clausen wrote: > Stan, All, > > I've previously given my feedback to this document on the list, which the author took into account in producing the current revision. > > I am fully satisfied with this version, and support its publication as std. track RFC wholeheartedly. > > Best, > > Thomas > > Sent from my iPad > >> On 06 Aug 2014, at 20:28, "Stan Ratliff (sratliff)" wrote: >> >> Working group participants, >> >> This is a Last Call on the above document. Please review and note any issues on the list on or before August 20, 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 From nobody Wed Aug 6 14:31: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 2DEAC1A0280 for ; Wed, 6 Aug 2014 14:31:13 -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 tmhfYpBL0Pc6 for ; Wed, 6 Aug 2014 14:31:11 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BFE1A01C6 for ; Wed, 6 Aug 2014 14:31:10 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so3227036wgh.34 for ; Wed, 06 Aug 2014 14:31:09 -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=vx2y8Ams+RceT1lGdxdnQxWDqgMW+zZQbH8PwJJHcc0=; b=YLfxh6n8dIpo8DSGlouXBnGu100k8lPO7YD6Nt+aXixHb0vraL0TUCYFSAmpgr/9r1 TCAmn9MQ3ZVhWVDQ2dnEd9NuEwUyHrWhcOwMwyRJuBEudKMOyv3jaWAxO7k94jVZsKZw J6uwwXFPuoUkkl2nL2z2Q817Ov4lIT+tgbzei/ApaCwJU2ZzQy/h/XwSH34spPEV6eEH lIQVPnH8OTF39OdHRCwwXoUHHks6Rr3UIEeoXZL3I5VAvI3gVFmPIGzNQvgRCvB6B5VC Z2NxSH4OVvwZpyuAZu3wASftSDh9Q02dSIm8E2SXdh18vwWf9SAlZIoi8rmjXE1t1IId dBww== MIME-Version: 1.0 X-Received: by 10.180.19.200 with SMTP id h8mr53905914wie.32.1407360669625; Wed, 06 Aug 2014 14:31:09 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Wed, 6 Aug 2014 14:31:09 -0700 (PDT) In-Reply-To: References: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> Date: Wed, 6 Aug 2014 23:31:09 +0200 X-Google-Sender-Auth: kOhZlgdIYC0LIU3tEtQ9GEn0YGg Message-ID: From: Jiazi YI To: Thomas Clausen Content-Type: multipart/alternative; boundary=bcaec53d5eb7c8b62204fffcb0da Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qTdij7cIfUhESmFIp3UvSEoLr98 Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Working Group Last Call for draft-ietf-manet-ibs 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, 06 Aug 2014 21:31:13 -0000 --bcaec53d5eb7c8b62204fffcb0da Content-Type: text/plain; charset=UTF-8 Oops... my bad. I simply took the first item from google. I think the draft is in good shape, and in favour of its publication. Just a few minor comments (mainly editorial): o As the draft is specific for ECCSI (RFC6507), I think it would be helpful to mention it in the applicability statement. I'm even wondering if it would be more precise to name the draft "ECCSI based Signatures for for MANET Routing Protocols", because there are other Identity-based signatures which can't be implemented using this draft directly. Of course, it's up to the author to decide which is the more appropriate title. o It would be helpful to expand the abbreviations on their first use, such as AES. I don't know if it's necessary to precise what's OLSRv2 or NHDP -- the RFC editor would fix it if there is anything wrong :) o In For the cryptographic function ECCSI ID is the element defined in Section 12.1 of [RFC7182] . This MUST NOT be empty. A comma between ECCSI and ID would make it clearer. o In The advantage referred to is that each router can be configured once (for its key lifetime) by a trusted authority, independently of all other routers. Thus *router A* can connect to the authority (typically in a secure environment) to receive a private key, or can have a Normally when we use the notation like router/node A,B,C..., it's for an example or a figure -- at least, my first reaction is looking for the examples. As it's a general case here, I think "a router" should be good. best Jiazi On Wed, Aug 6, 2014 at 10:50 PM, Thomas Clausen wrote: > Jiazi, > > Try to look at the latest version: > > http://tools.ietf.org/html/draft-ietf-manet-ibs-02 > > ;) > > Thomas > > > Sent from my iPad > > On 06 Aug 2014, at 22:03, Jiazi YI wrote: > > Hi, > > There is an > > Appendix A: example > TBD > > I don't know it's "to be done", or "to be dropped"? :-P > > best > > Jiazi > > > On Wed, Aug 6, 2014 at 8:28 PM, Stan Ratliff (sratliff) < > sratliff@cisco.com> wrote: > >> Working group participants, >> >> This is a Last Call on the above document. Please review and note any >> issues on the list on or before August 20, 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 > > --bcaec53d5eb7c8b62204fffcb0da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oops... my bad. I simply took the first item from google.= =C2=A0

I think the draft is in good shape, and in favour= of its publication.=C2=A0

Just a few minor commen= ts (mainly editorial):

=C2=A0o As the draft is specific for=C2=A0ECCSI (RFC6507), I think it would be helpful to me= ntion it in the applicability statement.=C2=A0
=C2=A0 =C2=A0 I'm even wondering if= it would be more precise to name the draft "ECCSI based Signatures for=C2=A0for MANET Routing Protocols", because there are other= Identity-based signatures which can't be implemented using this draft = directly. Of course, it's up to the author to decide which is the more = appropriate title.=C2=A0

= =C2=A0 o It would be helpful to expand the abbreviations on their first use= , such as AES. I don't know if it's necessary to precise what's= OLSRv2 or NHDP -- the RFC editor would fix it if there is anything wrong := )

= =C2=A0 o =C2=A0In

For the cryptographic function ECCSI ID is the element <key-id>
      defined in Section=C2=A012.1 of [RFC7182].  This MUST NOT be empty.
<= div>
= =C2=A0 =C2=A0 =C2=A0 A comma between ECCSI and ID would make it clearer.=C2= =A0

= =C2=A0 o In

= 
The advantage referred to is that each router can be configured once
   (for its key lifetime) by a trusted authority, independently of all
   other routers.  Thus router A can connect to the authority (typic=
ally
   in a secure environment) to receive a private key, or can have a

=C2=A0 =C2=A0 =C2=A0Normally when we use the notation like router/node = A,B,C..., it's for an example or a figure -- at least, my first reactio= n is looking for the examples. As it's a general case here, I think &qu= ot;a router" should be good.=C2=A0

= best

Jiazi


On Wed,= Aug 6, 2014 at 10:50 PM, Thomas Clausen <thomas@thomasclausen.org<= /a>> wrote:
Jiazi,

=
Try to look at the latest version:

;)
=
Thomas

=
Sent from my iPad
<= br> On 06 Aug 2014, at 22:03, Jiazi YI <ietf@jiaziyi.com> wrote:

Hi,=C2=A0

There is a= n=C2=A0

Appendix A: example=C2=A0
TBD

=
I don't know it's "to be done", or "to be dropp= ed"? :-P

best

Jiazi


On Wed, Aug 6, 2014 a= t 8:28 PM, Stan Ratliff (sratliff) <sratliff@cisco.com> wro= te:
Working group participants,

This is a Last Call on the above document. Please review and note any issue= s on the list on or before August 20, 2014.

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

___________________= ____________________________
manet mailing list
<= span>manet@ietf.org=
https://www.ietf.org/mailman/listinfo/manet

--bcaec53d5eb7c8b62204fffcb0da-- From nobody Wed Aug 6 14:43: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 52C881A0318 for ; Wed, 6 Aug 2014 14:43:32 -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 MM4kMBmkQvPw for ; Wed, 6 Aug 2014 14:43:30 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5519B1A02F5 for ; Wed, 6 Aug 2014 14:43:30 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so3285271wev.41 for ; Wed, 06 Aug 2014 14:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:mime-version:content-type:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/apNwDX3JKIXnmFhKBOfqAvA45RW70lNDoVj9eG38sE=; b=ym5kQYvOgttWubm66/ic3fjWfRocnuz9nE0EZDmaNHRul98nYdigUOX0VjuEXuWzC5 mYFU0Jsjc0mwrF2VQKDuwKOqT80/2F3RB21vDDVewdcLjekXxZ7Da3wMPUY6F1YsUkWG FhSvU/6+/b1AW2YhvfTEYiueLJdxGQ+CbH8zMsHChsIyO5pvsSC3mzSTapUDJkqiX0Xq zFLFGRSmn9/a9SYATTC85P1XhiCcRt8QuUbkzUHFUYpdkhG46mCqglYpQ1wuWuDtOcE9 itjxViIzLEooBR6wIMR6gEryaRDO2I5NZv9wRWq79TMBJ+jitKdb+F/B71OYdgotsZhp ljZw== X-Received: by 10.180.98.196 with SMTP id ek4mr19556825wib.13.1407361408860; Wed, 06 Aug 2014 14:43:28 -0700 (PDT) Received: from [192.168.254.6] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id 10sm5182620wjx.26.2014.08.06.14.43.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 14:43:28 -0700 (PDT) From: Christopher Dearlove X-Google-Original-From: Christopher Dearlove Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii In-Reply-To: Date: Wed, 6 Aug 2014 22:43:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> <13FC52BB-C8FD-47AF-95B2-474D1A091903@thomasclausen.org> To: Ulrich Herberg X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/m2CddJdBxeRsMOvgo0QW3xN_oV0 Cc: manet IETF , Thomas Clausen Subject: Re: [manet] Working Group Last Call for draft-ietf-manet-ibs 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, 06 Aug 2014 21:43:32 -0000 I replied to just Ulrich, which was meant to go to list. He then = replied, probably not noticing I'd just sent to him. So to catch up, I said RFC 5737, he said he was referring to the .0. I'm = now saying that that's not unheard of, and as the actual numbers here = are really unimportant - except changing them requires recalculation and = reconfirmation (and a bunch of reformatting work) - I think changing is = not a good idea. I didn't comment on the other two points. Obviously the first one shows = I omitted my usual spellcheck step. I'll put in when next reissuing. On 6 Aug 2014, at 22:07, Ulrich Herberg wrote: > I am in favor of publication of this document. >=20 > Minor comments: > - s/additinal/additional/ > - add comma after e.g.: "(e.g. 0 for HELLO)" > - in the example, isn't an IP source address of 192.0.2.0 unusual? >=20 > Regards > Ulrich >=20 > On Wed, Aug 6, 2014 at 12:44 PM, Thomas Clausen > wrote: >> Stan, All, >>=20 >> I've previously given my feedback to this document on the list, which = the author took into account in producing the current revision. >>=20 >> I am fully satisfied with this version, and support its publication = as std. track RFC wholeheartedly. >>=20 >> Best, >>=20 >> Thomas >>=20 >> Sent from my iPad >>=20 >>> On 06 Aug 2014, at 20:28, "Stan Ratliff (sratliff)" = wrote: >>>=20 >>> Working group participants, >>>=20 >>> This is a Last Call on the above document. Please review and note = any issues on the list on or before August 20, 2014. >>>=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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Aug 6 14:48: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 C625C1A02DD for ; Wed, 6 Aug 2014 14:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 QpckMFdTXtuy for ; Wed, 6 Aug 2014 14:48:12 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBE51A02DC for ; Wed, 6 Aug 2014 14:48:12 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hy4so5111097vcb.27 for ; Wed, 06 Aug 2014 14:48:11 -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:content-transfer-encoding; bh=oo0E5pNRCNKwzVxoVdPgFQpj81Vmr3iREvneF40WdRw=; b=Lh8UVuV3fdgsBnuedzfoxBbOEVmA/3re05rEgHskU3VI4H792nMaI50pZCKUhTRPRX JhYiziRMPV+qxSPi7573ci/ss/LqRRnlDIruej3lunSyB0wNq9KYS0J8ynLFjcfnP6sz wWxSCmk9oe2doHdrNnJ/S84htUUH6rFFF927I= 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 :content-transfer-encoding; bh=oo0E5pNRCNKwzVxoVdPgFQpj81Vmr3iREvneF40WdRw=; b=WZgJ8kaKsKzmjpjQ5mDtQ7qyg6RWu6Sf/CskbGsP+tlgdI5vQghyovWHwoMSpNpIpm 8GjnC3eRlXCJLI2d0IeSmot0W3Iy0pVGO0uVAampi4mKmjbEO99bMuW0DZuNfItsl0u6 JwYS8phDJRbwU7ojJQPpHvAGc/sT0J3mViBgFD2EyP/eZKiraStXkE2aoG7Dgwy6y9im /7MTXqFeFp/IK/38z+Jw8PHvOQ9tsK3Fol5wTGLuQ+6cYsPGTZ/piz1FCnNZEd15I5cM Vhm1OC+mxCv3a4cAa/owBDh8tTfw/HwtCml9PnY3PVKDKW+6gNF4r4sQkrpNs+q5JiAU fdhQ== X-Gm-Message-State: ALoCoQlpMWsXwY9+5ZiCGOFRsjlpH1RpwWn6yTS2SKypPmKJD9ephZ+od/Qpt2T8KEBYDHba3v/e MIME-Version: 1.0 X-Received: by 10.220.144.147 with SMTP id z19mr12994492vcu.26.1407361691538; Wed, 06 Aug 2014 14:48:11 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Wed, 6 Aug 2014 14:48:11 -0700 (PDT) In-Reply-To: References: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> <13FC52BB-C8FD-47AF-95B2-474D1A091903@thomasclausen.org> Date: Wed, 6 Aug 2014 14:48:11 -0700 Message-ID: From: Ulrich Herberg To: Christopher Dearlove Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vaKxwWU4VaJLrU7RRym-QUhDUnQ Cc: manet IETF , Thomas Clausen Subject: Re: [manet] Working Group Last Call for draft-ietf-manet-ibs 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, 06 Aug 2014 21:48:14 -0000 Thanks, Chris. The choice of the IP address may not be ideal IMO, but I understand it would be more painful to recalculate the examples (and to verify them by an external party). So I am fine with leaving as is. On Wed, Aug 6, 2014 at 2:43 PM, Christopher Dearlove wrote: > I replied to just Ulrich, which was meant to go to list. He then replied,= probably not noticing I'd just sent to him. > > So to catch up, I said RFC 5737, he said he was referring to the .0. I'm = now saying that that's not unheard of, and as the actual numbers here are r= eally unimportant - except changing them requires recalculation and reconfi= rmation (and a bunch of reformatting work) - I think changing is not a good= idea. > > I didn't comment on the other two points. Obviously the first one shows I= omitted my usual spellcheck step. I'll put in when next reissuing. > > > On 6 Aug 2014, at 22:07, Ulrich Herberg wrote: > >> I am in favor of publication of this document. >> >> Minor comments: >> - s/additinal/additional/ >> - add comma after e.g.: "(e.g. 0 for HELLO)" >> - in the example, isn't an IP source address of 192.0.2.0 unusual? >> >> Regards >> Ulrich >> >> On Wed, Aug 6, 2014 at 12:44 PM, Thomas Clausen >> wrote: >>> Stan, All, >>> >>> I've previously given my feedback to this document on the list, which t= he author took into account in producing the current revision. >>> >>> I am fully satisfied with this version, and support its publication as = std. track RFC wholeheartedly. >>> >>> Best, >>> >>> Thomas >>> >>> Sent from my iPad >>> >>>> On 06 Aug 2014, at 20:28, "Stan Ratliff (sratliff)" wrote: >>>> >>>> Working group participants, >>>> >>>> This is a Last Call on the above document. Please review and note any = issues on the list on or before August 20, 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 Aug 6 15:01: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 B513D1B28B7 for ; Wed, 6 Aug 2014 15:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 VxDPCXxflyPu for ; Wed, 6 Aug 2014 15:01:49 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9219E1A0305 for ; Wed, 6 Aug 2014 15:01:48 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so3189986wgh.26 for ; Wed, 06 Aug 2014 15:01:47 -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 :message-id:references:to; bh=oNf4uIQyYCfumbcLt0on4E28ftEpMWfkuWzOJXcn6aw=; b=r+NkoMCsk5JJA6Nc4tWY6LplwBIOYFeubofxy96jkja4lmMvbBIou/JYSTwOzip83u Kco2QMWXYLmvTgAwfiAqR7LtgoeQGKeRvUSirBul2V50GlILBrv9G5E/vIs9LYvhFk66 UxwbuvgV5nj4PJJkdISZkGE7812/ZL8MuejHHRqr+9vm07H/ulbA9agjjW8bJKzwISMG YjYnGpY5cb8jmiHee976tlYo5U8nbdIQsmjubEDrCishhYGtY3GiVpdPxlByYLKDCCTH U7OTKwGE6FTRsCx3CA/rNzkdA2XgUeZH2A9jzohtvWIDB58/InvTZFv6e1fw6UIA8UY9 /j6Q== X-Received: by 10.195.18.8 with SMTP id gi8mr18721841wjd.75.1407362507196; Wed, 06 Aug 2014 15:01:47 -0700 (PDT) Received: from [192.168.254.6] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id bv16sm10112746wib.2.2014.08.06.15.01.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 15:01:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_7F37D405-1F25-4512-8764-E2AEDBD12FFC" From: Christopher Dearlove In-Reply-To: Date: Wed, 6 Aug 2014 23:01:43 +0100 Message-Id: References: <01E06EC1-6990-47F1-8691-B8AA1D370ECB@cisco.com> To: Jiazi YI X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hnhSPiEVGw4kJyKkSGl5riYMbU4 Cc: manet IETF , Thomas Clausen , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Working Group Last Call for draft-ietf-manet-ibs 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, 06 Aug 2014 22:01:52 -0000 --Apple-Mail=_7F37D405-1F25-4512-8764-E2AEDBD12FFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Comments inline. On 6 Aug 2014, at 22:31, Jiazi YI wrote: > Oops... my bad. I simply took the first item from google.=20 >=20 > I think the draft is in good shape, and in favour of its publication.=20= >=20 > Just a few minor comments (mainly editorial): >=20 > o As the draft is specific for ECCSI (RFC6507), I think it would be = helpful to mention it in the applicability statement.=20 It uses ECCSI rather than is for ECCSI, so I don't think that belongs in = the applicability section. I think it;s well-covered elsewhere. > I'm even wondering if it would be more precise to name the draft = "ECCSI based Signatures for for MANET Routing Protocols", because there = are other Identity-based signatures which can't be implemented using = this draft directly. Of course, it's up to the author to decide which is = the more appropriate title.=20 I think that a draft "identity based signatures" will have people = understanding what it's about, but ECCSI will hit a "what's that?" = Spelled out in full - just look at the title of RFC 6507 which is just = ECCSI spelled out. So while I take the point, I prefer to stick with = what's there. > o It would be helpful to expand the abbreviations on their first = use, such as AES. I don't know if it's necessary to precise what's = OLSRv2 or NHDP -- the RFC editor would fix it if there is anything wrong = :) I tend to assume (rightly or wrongly) anyone reading this will know what = AES is, and it's just a throwaway reference to RFC 7182, which to expand = would mean double parentheses IIRC. But I'm pretty sure the RFC Editor = will impose whatever the preferred style is. > o In >=20 > For the cryptographic function ECCSI ID is the element > defined in Section 12.1 of [RFC7182]. This MUST NOT be empty. >=20 > A comma between ECCSI and ID would make it clearer.=20 It would. Thanks. > o In >=20 > The advantage referred to is that each router can be configured once > (for its key lifetime) by a trusted authority, independently of all > other routers. Thus router A can connect to the authority = (typically > in a secure environment) to receive a private key, or can have a >=20 > Normally when we use the notation like router/node A,B,C..., it's = for an example or a figure -- at least, my first reaction is looking for = the examples. As it's a general case here, I think "a router" should be = good.=20 I needed the rest of the paragraph, as I was expecting a later reference = in it to router B, which I think is reasonable usage even without a = figure. But there is no router B, so I agree with you, that's poor = usage. Thanks. >=20 > best >=20 > Jiazi >=20 >=20 > On Wed, Aug 6, 2014 at 10:50 PM, Thomas Clausen = wrote: > Jiazi, >=20 > Try to look at the latest version: >=20 > http://tools.ietf.org/html/draft-ietf-manet-ibs-02 >=20 > ;) >=20 > Thomas >=20 >=20 > Sent from my iPad >=20 > On 06 Aug 2014, at 22:03, Jiazi YI wrote: >=20 >> Hi,=20 >>=20 >> There is an=20 >>=20 >> Appendix A: example=20 >> TBD >>=20 >> I don't know it's "to be done", or "to be dropped"? :-P >>=20 >> best >>=20 >> Jiazi >>=20 >>=20 >> On Wed, Aug 6, 2014 at 8:28 PM, Stan Ratliff (sratliff) = wrote: >> Working group participants, >>=20 >> This is a Last Call on the above document. Please review and note any = issues on the list on or before August 20, 2014. >>=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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_7F37D405-1F25-4512-8764-E2AEDBD12FFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Oops... my bad. I simply took the first item from = google. 

I think the draft is in good shape, and = in favour of its publication. 

Just a few = minor comments (mainly editorial):

 o As the draft is specific for ECCSI (RFC6507), I think it = would be helpful to mention it in the applicability = statement. 

It = uses ECCSI rather than is for ECCSI, so I don't think that belongs in = the applicability section. I think it;s well-covered = elsewhere.

    I'm even = wondering if it would be more precise to name the draft "ECCSI based Signatures = for for MANET Routing Protocols", = because there are other Identity-based signatures which can't be = implemented using this draft directly. Of course, it's up to the author = to decide which is the more appropriate = title. 

I think = that a draft "identity based signatures" will have people understanding = what it's about, but ECCSI will hit a "what's that?" Spelled out in full = - just look at the title of RFC 6507 which is just ECCSI spelled out. So = while I take the point, I prefer to stick with what's = there.

  o It would be helpful to = expand the abbreviations on their first use, such as AES. I don't know = if it's necessary to precise what's OLSRv2 or NHDP -- the RFC editor = would fix it if there is anything wrong = :)

I tend to assume = (rightly or wrongly) anyone reading this will know what AES is, and it's = just a throwaway reference to RFC 7182, which to expand would mean = double parentheses IIRC. But I'm pretty sure the RFC Editor will impose = whatever the preferred style is.

  o  In

=
For the cryptographic function ECCSI ID is the element <key-id>
      defined in Section 12.1=
 of [RFC7182].  This MUST NOT be empty.

  =     A comma between ECCSI and ID would make it = clearer. 

It = would. Thanks.

  o In

=
The advantage referred to is that each router can be configured once
   (for its key lifetime) by a trusted authority, independently of all
   other routers.  Thus router A can connect to the authority =
(typically
   in a secure environment) to receive a private key, or can have =
a

     Normally when we use the notation = like router/node A,B,C..., it's for an example or a figure -- at least, = my first reaction is looking for the examples. As it's a general case = here, I think "a router" should be = good. 

I needed = the rest of the paragraph, as I was expecting a later reference in it to = router B, which I think is reasonable usage even without a figure. But = there is no router B, so I agree with you, that's poor usage. = Thanks.


best

Jiazi


On = Wed, Aug 6, 2014 at 10:50 PM, Thomas Clausen <thomas@thomasclausen.org> wrote:
Jiazi,

Try to look at the = latest version:


;)

Thomas
=

Sent from my iPad

On 06 Aug 2014, at 22:03, Jiazi YI <ietf@jiaziyi.com> = wrote:

Hi, 

There is an 

Appendix A: = example 
TBD

I don't know it's = "to be done", or "to be dropped"? :-P

best

Jiazi


On Wed, Aug 6, = 2014 at 8:28 PM, Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:
Working group = participants,

This is a Last Call on the above document. Please review and note any = issues on the list on or before August 20, 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=_7F37D405-1F25-4512-8764-E2AEDBD12FFC-- From nobody Thu Aug 7 02:18: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 5DACE1B2A1E; Thu, 7 Aug 2014 02:18:52 -0700 (PDT) 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 FSINBby3URKa; Thu, 7 Aug 2014 02:18:50 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87DC1B2966; Thu, 7 Aug 2014 02:18:49 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s779Ik24022668; Thu, 7 Aug 2014 10:18:47 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s779Ie7b022554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 10:18:40 +0100 From: "Adrian Farrel" To: , , Date: Thu, 7 Aug 2014 10:18:44 +0100 Message-ID: <00e501cfb220$96ec9b60$c4c5d220$@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: Ac+yIJXnSb9CvN3lQke+XTLssv1IYg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20864.006 X-TM-AS-Result: No--40.121-10.0-31-10 X-imss-scan-details: No--40.121-10.0-31-10 X-TMASE-MatchedRID: D2G27ZgZra/YMEqhScrQBUhEDfw/93BuH181YDtIVapF+YXPIqAdvrMj 3GAElQGEHWONFZT/prr3YiuFkZiOxGResrHRY7dK8eSmTJSmEv2S3G9UxpYxsMoNup+2nV/XmkL u0+871bV2HZRu5knIkaCQCfo/jPYbVd/GARVyJ51GypC5CVFOH978NWlYojkr2viB/Jr4D1TNCc A6Zdzj70jpvQu/TgjHcP8NoorbT3V1KobyH4zskSe1T5r1VA3IyeUl7aCTy8jczkKO5k4APhZZd YKgpK9DdxS9fNW9kSZLqpudr4MRIM/BlZO+W2WhtNMyJ72jQd22awxxVfk3ByWy0DEOFuGQ3ogi kAEqSiqRLq2ylp66OeDz4wU7tmbcvXtlm87JVdowiJTf3kjwfaGuPOIOnqBBS5TspQkQ8sGOytA lmFixKqYoxrZu+cZeaw6jvnhkER4dSjum6JPhtyZm6wdY+F8KguwtqyXlE6EhvFjBsLEZNEJb3b 5D8E1yCs950MJfLPLBdLgSSOxM9wnW8iiCcRSGiFoorQjboWkZYA38gj3BxOVs8DNq02hCeIJ7x 1WhBehKW3Ex8kbLqbLDlVGk98URY+SEAY1Jo3eJQ9k+Ypk5CcLiFiL0BG1uEd+K6O5Nt53zb5km gp405bfqHaErmu92kZOl7WKIImq0P2qkGU0XylZ0V5tYhzdWxEHRux+uk8jpP8tMOyYmaA== Archived-At: http://mailarchive.ietf.org/arch/msg/manet/X9X5L91uRlzE0WhkboG3NQ85RV0 Subject: [manet] FW: [Anima] ANIMA draft charter 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: Thu, 07 Aug 2014 09:18:52 -0000 Please excuse the spam. There is a discussion about forming a working group for autonomic networking that may be of interest to a number of you. Please continue the discussion on the ANIMA mailing list (i.e., not here!) Thanks, Adrian > -------- Original Message -------- > Subject: [Anima] ANIMA draft charter > Date: Tue, 5 Aug 2014 08:19:15 +0000 > From: Michael Behringer (mbehring) > To: anima@ietf.org > > At the BoF in Toronto there was rough consensus to continue the work on an > autonomic infrastructure. Brian, Sheng, Toerless, > Laurent and I have now drafted a potential WG charter with the input of our ADs. > Note that this is not yet a formal charter > proposal, it's for discussion only so far. > > The assumption is that more general aspects of autonomics will continue to be > discussed in the NMRG group. > > If we were to go ahead with a WG, the goal would be to focus on realistic > deliverables. So the plan is to start with a small, > achievable set of deliverables, and, if successful and useful, expand after re- > chartering. > > Please comment here on this draft charter proposal. > > Thanks, > Michael > > > Autonomic Networking Integrated Model and Approach (ANIMA) WG > > Description of Working Group > > Autonomic Networking focuses on self-management of network elements. An > autonomic function works in a distributed way across > various network elements, allowing however central guidance and reporting. > Autonomic functions already exist today, for example > IGP routing protocols such as OSPF. However, all such functions have their own > discovery, transport, messaging and security > mechanisms. > > To transform the somewhat abstract Autonomic Networking concept into > concrete, realisable requirements, the first stage, > undertaken in the Network Management Research Group (NMRG) of the IRTF, > was to define terminology and design goals, and to > derive a high-level gap analysis. The definitions and design goals, as well as a > simple architecture model are defined in > draft-irtf-nmrg-autonomic-network-definitions; the gap analysis for AN is > described in draft-irtf-nmrg-an-gap-analysis. The UCAN > BoF at IETF 90 discussed use cases and some existing solutions. All the above > work serves as a baseline for this working group. > > This working group defines solutions for an initial set of components of an > autonomic networking infrastructure, based on the > simple architecture and design goals defined in draft-irtf-nmrg-autonomic- > network-definitions. Future work may include a more > detailed systems architecture to support the development of autonomic service > agents. The Anima working group will initially > focus on enterprise, ISP networks and IoT. > > The solutions target to cover the following areas: > o identity of nodes > o common security model > o discovery model > o negotiation model > o a secure and logically separated communications channel > o an example for an autonomic management model > > The goals of this working group are: > > o Definition of a generic discovery and negotiation protocol for autonomic > functions > Starting point: draft-jiang-config-negotiation-protocol > o Definition of a mechanism to bootstrap a trust infrastructure > Starting point: draft-pritikin-bootstrapping-keyinfrastructures > o Definition of an logically separated Autonomic Control Plane > Starting point: draft-behringer-autonomic-control-plane > > In addition, autonomic service agents will need to be defined for specific use > cases. The working group will initially consider > one simple example as a test case for further work. > > o Definition of > Starting point: draft-use-case-tbd > > The initial set of work items is limited to the above list to stay focused and avoid > "boiling the ocean". Additional documents > concerning policy intent, other autonomic infrastructure components, use cases > or autonomic service agents are strongly > encouraged, as individual submissions, but are not planned as working group > deliverables for now. No additional work items will > be accepted in the working group without re-chartering. > > Milestones > > Nov 2014 - WG formation and adoption of drafts > - Mar IETF - > Jun 2015 - WGLC for draft-generic-discovery-negotiation-protocol > - Jul IETF - > Aug 2015 - submit draft-generic-discovery-negotiation-protocol to IESG > (standards track) > Oct 2015 - WGLC draft-keyinfrastructure-bootstrap > Oct 2015 - WGLC draft-use-case-tbd > - Nov IETF - > Dec 2015 - submit draft-keyinfrastructure-bootstrap to IESG (standards track) > Dec 2015 - submit draft-use-case-tbd to IESG (standards track) > Jan 2016 - WGLC draft-autonomic-common-control-plane > - Mar IETF - > Apr 2016 - submit draft-autonomic-common-control-plane to IESG (standards > track) > Jul 2016 - recharter if needed, or close > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Aug 7 06:37: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 5FD4A1B2AFE for ; Thu, 7 Aug 2014 06:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 HWXPh7JR6-Tx for ; Thu, 7 Aug 2014 06:36:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1EC81B29EA for ; Thu, 7 Aug 2014 06:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7524; q=dns/txt; s=iport; t=1407418620; x=1408628220; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KjyiTrr1CIuRzXtn5W54zqXDM3hILdNGijBr35AYYf8=; b=BpJMCSWFUo/kzUo0E5XZz5vrOZlYn7v5gOkKxOKmyZvzLoIU7LohaDaQ U0Px0d8B/MxEIBLXK8f5p+ThvnEhwoFI8fTO2ZZpAEHidd+NVG5n4Fw2K +8M1elwloHi5RuGSoeM7MAbNWmFfP3YL3DoG1F0PdYFLLcFRBJp9+9kli E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAFeA41OtJV2U/2dsb2JhbABRCYMNUlcEzEgKhnVTAYEQFneEAwEBAQMBAQEBNzQGBQUHBAIBCBEBAgEBAR8JBycLFAMGCAIEDgUbiB8IDcN/EwSOcQMlMwcGgymBHAWcG5Rwg1dsgQRC X-IronPort-AV: E=Sophos;i="5.01,818,1400025600"; d="scan'208";a="345741722" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 07 Aug 2014 13:36:59 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s77DawmR030006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 13:36:58 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.126]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 08:36:58 -0500 From: "Stan Ratliff (sratliff)" To: "Papadimitriou, Dimitri (Dimitri)" Thread-Topic: [Anima] ANIMA draft charter Thread-Index: AQHPsitDwfrUs7bNU0mUnaMaaUyJFpvFeM0A Date: Thu, 7 Aug 2014 13:36:57 +0000 Message-ID: <7CFFB29E-17DE-4C5E-8EA1-E304E6FAACBB@cisco.com> References: <00e501cfb220$96ec9b60$c4c5d220$@olddog.co.uk> <84675BAA8C49154AB81E2587BE8BDF83234331DF@FR711WXCHMBA07.zeu.alcatel-lucent.com> In-Reply-To: <84675BAA8C49154AB81E2587BE8BDF83234331DF@FR711WXCHMBA07.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] 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/WwG8lP6kDwBQolaO2UwFohTWgfk Cc: "manet@ietf.org" Subject: Re: [manet] [Anima] ANIMA draft charter 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, 07 Aug 2014 13:37:02 -0000 Dimitri, =20 >>=20 >> Please continue the discussion on the ANIMA mailing list (i.e., not here= !) Regards, Stan On Aug 7, 2014, at 6:34 AM, "Papadimitriou, Dimitri (Dimitri)" wrote: > Hi Adrian, all >=20 > Thanks for sharing. Reading this charter, the following statement escapes= me >=20 > "Autonomic functions already exist today, for example IGP routing protoco= ls such as OSPF." >=20 > I would have said OSPF like any other IGP is adaptive (and from the curre= nt state only -not previous states-) but it is not autonomous: the same inp= ut leads to the same output (decision), i.e., there is no improvement of qu= ality of the decision process over time and on the other hand there is no m= ean by which OSPF can by itself overcome degradation of performance (at bes= t mitigate if pre-configured to execute fixed sequences for a sub-set of pr= e-determined conditions, cf.RFC 4222, so again driven by open control loops= ). >=20 > Setting of configurable constants is mainly driven by open control loops.= Moreover individual routers can't make autonomous decisions in terms of ar= ea parameters configuration as all routers belonging to an area must agree = on that area's configuration). >=20 > Thanks, > -dimitri. >> -----Original Message----- >> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On >> Behalf Of Adrian Farrel >> Sent: Thursday, August 07, 2014 11:19 AM >> To: routing-discussion@ietf.org; manet@ietf.org; roll@ietf.org >> Subject: FW: [Anima] ANIMA draft charter >>=20 >> Please excuse the spam. >>=20 >> There is a discussion about forming a working group for autonomic >> networking that may be of interest to a number of you. >>=20 >> Please continue the discussion on the ANIMA mailing list (i.e., not here= !) >>=20 >> Thanks, >> Adrian >>=20 >>> -------- Original Message -------- >>> Subject: [Anima] ANIMA draft charter >>> Date: Tue, 5 Aug 2014 08:19:15 +0000 >>> From: Michael Behringer (mbehring) >>> To: anima@ietf.org >>>=20 >>> At the BoF in Toronto there was rough consensus to continue the work >>> on an autonomic infrastructure. Brian, Sheng, Toerless, Laurent and I >>> have now drafted a potential WG charter with the input of our >> ADs. >>> Note that this is not yet a formal charter proposal, it's for >>> discussion only so far. >>>=20 >>> The assumption is that more general aspects of autonomics will >>> continue to be discussed in the NMRG group. >>>=20 >>> If we were to go ahead with a WG, the goal would be to focus on >>> realistic deliverables. So the plan is to start with a small, >>> achievable set of deliverables, and, if successful and useful, expand >>> after >> re- >>> chartering. >>>=20 >>> Please comment here on this draft charter proposal. >>>=20 >>> Thanks, >>> Michael >>>=20 >>>=20 >>> Autonomic Networking Integrated Model and Approach (ANIMA) WG >>>=20 >>> Description of Working Group >>>=20 >>> Autonomic Networking focuses on self-management of network elements. >>> An autonomic function works in a distributed way across various >>> network elements, allowing however central guidance and reporting. >>> Autonomic functions already exist today, for example IGP routing >>> protocols such as OSPF. However, all such functions have their own >>> discovery, transport, messaging and security mechanisms. >>>=20 >>> To transform the somewhat abstract Autonomic Networking concept into >>> concrete, realisable requirements, the first stage, undertaken in the >>> Network Management Research Group (NMRG) of the IRTF, was to define >>> terminology and design goals, and to derive a high-level gap analysis. >>> The definitions and design goals, as well as >> a >>> simple architecture model are defined in >>> draft-irtf-nmrg-autonomic-network-definitions; the gap analysis for AN >>> is described in draft-irtf-nmrg-an-gap-analysis. The UCAN BoF at IETF >>> 90 discussed use cases and some existing solutions. All the above work >>> serves as a baseline for this working group. >>>=20 >>> This working group defines solutions for an initial set of components >>> of an autonomic networking infrastructure, based on the simple >>> architecture and design goals defined in draft-irtf-nmrg-autonomic- >>> network-definitions. Future work may include a more detailed systems >>> architecture to support the development of autonomic service agents. >>> The Anima working group will initially focus on enterprise, ISP >>> networks and IoT. >>>=20 >>> The solutions target to cover the following areas: >>> o identity of nodes >>> o common security model >>> o discovery model >>> o negotiation model >>> o a secure and logically separated communications channel o an example >>> for an autonomic management model >>>=20 >>> The goals of this working group are: >>>=20 >>> o Definition of a generic discovery and negotiation protocol for >>> autonomic functions >>> Starting point: draft-jiang-config-negotiation-protocol >>> o Definition of a mechanism to bootstrap a trust infrastructure >>> Starting point: draft-pritikin-bootstrapping-keyinfrastructures >>> o Definition of an logically separated Autonomic Control Plane >>> Starting point: draft-behringer-autonomic-control-plane >>>=20 >>> In addition, autonomic service agents will need to be defined for >>> specific use cases. The working group will initially consider one >>> simple example as a test case for further work. >>>=20 >>> o Definition of >>> Starting point: draft-use-case-tbd >>>=20 >>> The initial set of work items is limited to the above list to stay >>> focused and >> avoid >>> "boiling the ocean". Additional documents concerning policy intent, >>> other autonomic infrastructure components, use cases or autonomic >>> service agents are strongly encouraged, as individual submissions, but >>> are not planned as working group deliverables for now. No additional >>> work items will be accepted in the working group without >>> re-chartering. >>>=20 >>> Milestones >>>=20 >>> Nov 2014 - WG formation and adoption of drafts >>> - Mar IETF - >>> Jun 2015 - WGLC for draft-generic-discovery-negotiation-protocol >>> - Jul IETF - >>> Aug 2015 - submit draft-generic-discovery-negotiation-protocol to IESG >>> (standards track) Oct 2015 - WGLC draft-keyinfrastructure-bootstrap >>> Oct 2015 - WGLC draft-use-case-tbd >>> - Nov IETF - >>> Dec 2015 - submit draft-keyinfrastructure-bootstrap to IESG >>> (standards track) Dec 2015 - submit draft-use-case-tbd to IESG >>> (standards track) Jan 2016 - WGLC draft-autonomic-common-control-plane >>> - Mar IETF - >>> Apr 2016 - submit draft-autonomic-common-control-plane to IESG >>> (standards >>> track) >>> Jul 2016 - recharter if needed, or close >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>=20 >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Aug 7 08:16:52 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 C43311B2BB1; Thu, 7 Aug 2014 08:16:50 -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 RfCnpV_g6ijf; Thu, 7 Aug 2014 08:16:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D61591B2CE0; Thu, 7 Aug 2014 08:16:46 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807151646.20977.22948.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 08:16:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zB7VdLc4HOqWMBfT9BUKljSOnWo Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-optimization-01.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: Thu, 07 Aug 2014 15:16:50 -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 : An Optimization for the MANET Neighborhood Discovery Protocol (NHDP) Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-optimization-01.txt Pages : 10 Date : 2014-08-07 Abstract: The link quality mechanism of the MANET Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold, while still retaining the corresponding link information as acquired from HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently. NHDP also collects information about symmetric 2-hop neighbors. However it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" as described above, then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment. This specification updates RFC6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", and RFC7181 "The Optimized Link State Routing Protocol version 2 (OLSRv2)" to permit retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-optimization/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-optimization-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-optimization-01 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 Thu Aug 7 08:27: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 3A0881B2D70; Thu, 7 Aug 2014 08:27:03 -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 Ce_pfrElvzbC; Thu, 7 Aug 2014 08:26:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0381B2CF8; Thu, 7 Aug 2014 08:26:47 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807152647.19846.73490.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 08:26:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zMPpby7_ic_xpo-Knhn5XqWB1mM Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-optimization-02.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: Thu, 07 Aug 2014 15:27: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 : An Optimization for the MANET Neighborhood Discovery Protocol (NHDP) Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-optimization-02.txt Pages : 10 Date : 2014-08-07 Abstract: The link quality mechanism of the MANET Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold, while still retaining the corresponding link information as acquired from HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently. NHDP also collects information about symmetric 2-hop neighbors. However it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" as described above, then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment. This specification updates RFC6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", and RFC7181 "The Optimized Link State Routing Protocol version 2 (OLSRv2)" to permit retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-optimization/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-optimization-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-optimization-02 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 Thu Aug 7 08:34: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 8BF461B2C94 for ; Thu, 7 Aug 2014 08:34:41 -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 XPj-6pKh6aBI for ; Thu, 7 Aug 2014 08:34:39 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3036F1B2D16 for ; Thu, 7 Aug 2014 08:34:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CD92F1C0C5D; Thu, 7 Aug 2014 08:34:38 -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 B10D71C0B75; Thu, 7 Aug 2014 08:34:36 -0700 (PDT) From: Thomas Clausen Content-Type: multipart/alternative; boundary="Apple-Mail=_5D8EE3B5-A0A6-4192-9910-74D0F010852F" Date: Thu, 7 Aug 2014 17:34:33 +0200 References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> To: "" , manet-ads , manet IETF Message-Id: <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3QjdOmdTQeK4btkilYcqC9CsSrc Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-nhdp-optimization-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: Thu, 07 Aug 2014 15:34:41 -0000 --Apple-Mail=_5D8EE3B5-A0A6-4192-9910-74D0F010852F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All, We=92ve updated draft-ietf-manet-nhdp-optimization, to reference the = recently published draft-ietf-manet-rfc6779bis (which allowed removing = the MIB considerations section from this I-D) added by way of a = paragraph to the introduction. Of course, in an attempt to prove that I=92m almost as human as our AD, = I ended up submitting a -01 which contained a wrong (& convoluted) = version of that paragraph=85.hence, this recent submission of -02. In both -01, we also cleaned up a couple of warnings that IDnits threw = at us. In accordance with what Stan proposed a short while back, we=92d like to = ask that the WG chairs issue a WGLC for: o draft-ietf-manet-nhdp-optimization o draft-ietf-manet-rfc6779bis Given that this is a question that is bound to come up, might as well = take it now: =93This co-author of these two I-Ds confirm, that he=92s not = aware of any IPR related to these documents" Ball over to Stan now ;) Best, Thomas Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-manet-nhdp-optimization-02.txt > Date: August 7, 2014 at 17:26:47 GMT+2 > To: Thomas Heide Clausen , "Christopher = Dearlove" , "Thomas H. Clausen" = , Christopher Dearlove = >=20 >=20 > A new version of I-D, draft-ietf-manet-nhdp-optimization-02.txt > has been successfully submitted by Thomas Heide Clausen and posted to = the > IETF repository. >=20 > Name: draft-ietf-manet-nhdp-optimization > Revision: 02 > Title: An Optimization for the MANET Neighborhood = Discovery Protocol (NHDP) > Document date: 2014-08-07 > Group: manet > Pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-optimization-02.= txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-optimization/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-manet-nhdp-optimization-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-optimization-02 >=20 > Abstract: > The link quality mechanism of the MANET Neighborhood Discovery > Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the > measured link quality from that 1-hop neighbor is below an = acceptable > threshold, while still retaining the corresponding link information > as acquired from HELLO message exchange. This allows immediate > reinstatement of the 1-hop neighbor if the link quality later > improves sufficiently. >=20 > NHDP also collects information about symmetric 2-hop neighbors. > However it specifies that if a link from a symmetric 1-hop neighbor > ceases being symmetric, including while "ignored" as described = above, > then corresponding symmetric 2-hop neighbors are removed. This may > lead to symmetric 2-hop neighborhood information being permanently > removed (until further HELLO messages are received) if the link > quality of a symmetric 1-hop neighbor drops below the acceptable > threshold, even if only for a moment. >=20 > This specification updates RFC6130 "Mobile Ad Hoc Network (MANET) > Neighborhood Discovery Protocol (NHDP)", and RFC7181 "The Optimized > Link State Routing Protocol version 2 (OLSRv2)" to permit retaining, > but ignoring, symmetric 2-hop information when the link quality from > the corresponding 1-hop neighbor drops below the acceptable > threshold. This allows immediate reinstatement of the symmetric > 2-hop neighbor if the link quality later improves sufficiently, thus > making the symmetric 2-hop neighborhood more "robust". >=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=_5D8EE3B5-A0A6-4192-9910-74D0F010852F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 All,

We=92ve updated = draft-ietf-manet-nhdp-optimization, to reference the recently published = draft-ietf-manet-rfc6779bis (which allowed removing the MIB = considerations section from this I-D) added by way of a paragraph to the = introduction.

Of course, in an attempt to prove = that I=92m almost as human as our AD, I ended up submitting a -01 which = contained a wrong (& convoluted) version of that paragraph=85.hence, = this recent submission of -02.

In both -01, we = also cleaned up a couple of warnings that IDnits threw at = us.

In accordance with what Stan proposed a = short while back, we=92d like to ask that the WG chairs issue a WGLC = for:

o = draft-ietf-manet-nhdp-optimization
o = draft-ietf-manet-rfc6779bis

Given that = this is a question that is bound to come up, might as well take it = now:

=93This co-author of these two = I-Ds confirm, that he=92s not aware of any IPR related = to
=   these documents"

Ball over to = Stan now = ;)

Best,

Thomas



Begin forwarded = message:

Subject: = New Version = Notification for = draft-ietf-manet-nhdp-optimization-02.txt
Date: August 7, 2014 at 17:26:47 = GMT+2
To: = Thomas Heide Clausen = <t.clausen@computer.org>, = "Christopher Dearlove" <chris.dearlove@baesystems.co= m>, "Thomas H. Clausen" <T.Clausen@computer.org>, = Christopher Dearlove <chris.dearlove@baesystems.co= m>


A new version of I-D, = draft-ietf-manet-nhdp-optimization-02.txt
has been successfully = submitted by Thomas Heide Clausen and posted to the
IETF = repository.

Name: = draft-ietf-manet-nhdp-optimization
Revision: = 02
Title: An Optimization for the MANET = Neighborhood Discovery Protocol (NHDP)
Document date: = 2014-08-07
Group: manet
Pages: = 10
URL: =            http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-opt= imization-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-optimization/
Htmlized:       = http://tools.ietf.org/html/draft-ietf-manet-nhdp-optimization-02
Di= ff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-optimizat= ion-02

Abstract:
  The link quality mechanism = of the MANET Neighborhood Discovery
  Protocol (NHDP) = enables "ignoring" some 1-hop neighbors if the
  measured = link quality from that 1-hop neighbor is below an acceptable
=   threshold, while still retaining the corresponding link = information
  as acquired from HELLO message exchange. =  This allows immediate
  reinstatement of the 1-hop = neighbor if the link quality later
  improves = sufficiently.

  NHDP also collects information about = symmetric 2-hop neighbors.
  However it specifies that if = a link from a symmetric 1-hop neighbor
  ceases being = symmetric, including while "ignored" as described above,
=   then corresponding symmetric 2-hop neighbors are removed. =  This may
  lead to symmetric 2-hop neighborhood = information being permanently
  removed (until further = HELLO messages are received) if the link
  quality of a = symmetric 1-hop neighbor drops below the acceptable
=   threshold, even if only for a moment.

=   This specification updates RFC6130 "Mobile Ad Hoc Network = (MANET)
  Neighborhood Discovery Protocol (NHDP)", and = RFC7181 "The Optimized
  Link State Routing Protocol = version 2 (OLSRv2)" to permit retaining,
  but ignoring, = symmetric 2-hop information when the link quality from
=   the corresponding 1-hop neighbor drops below the = acceptable
  threshold.  This allows immediate = reinstatement of the symmetric
  2-hop neighbor if the = link quality later improves sufficiently, thus
  making = the symmetric 2-hop neighborhood more = "robust".




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=_5D8EE3B5-A0A6-4192-9910-74D0F010852F-- From nobody Thu Aug 7 10:26: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 A3D351B2EBF; Thu, 7 Aug 2014 10:26:35 -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 ESEtpEjI1wu2; Thu, 7 Aug 2014 10:26:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EEB1B2EC0; Thu, 7 Aug 2014 10:26:19 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807172619.13877.11363.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 10:26:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CaM-s1DdPww_af-9CQPV80XQi-4 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-management-snapshot-02.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: Thu, 07 Aug 2014 17:26: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 : Snapshot of OLSRv2-Routed MANET Management Authors : Thomas Clausen Ulrich Herberg Filename : draft-ietf-manet-olsrv2-management-snapshot-02.txt Pages : 13 Date : 2014-08-07 Abstract: This document describes how Mobile Ad Hoc Networks (MANETs) are typically managed, in terms of pre-deployment management, as well as rationale and means of monitoring and management of MANET routers running the Optimized Link State Routing protocol version 2 (OLSRv2) and its constituent MANET NehgiborHood Discovery Protocol (NHDP). Apart from pre-deployment management for setting up IP addresses and security related credentials, OLSRv2 only needs routers to agree one single parameter (called "C"). Other parameters for tweaking network performance may be determined during operation of the network, and need not be the same in all routers. This, using MIB modules and related management protocols such as SNMP (or possibly other, less "chatty", protocols). In addition, for debugging purposes, monitoring data and performance related counters, as well as notifications ("traps") can be sent to the Network Management System (NMS) via standardized management protocols. This document The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-management-snapshot/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-management-snapshot-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-management-snapshot-02 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 Thu Aug 7 10:31: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 00BA71A007A for ; Thu, 7 Aug 2014 10:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 pYwLcX-BodSH for ; Thu, 7 Aug 2014 10:30:57 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795011A0045 for ; Thu, 7 Aug 2014 10:30:28 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so6807618vcb.14 for ; Thu, 07 Aug 2014 10:30:27 -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=+hPSdBauf+BrgORcGqfLk3V0E9RvVGPVv1r2PWAGyVw=; b=XHEKSJh9RzfhKaVn+4F6KDY0i9yo+KIHzfhrRjX2FlLHmKEul9+VD3UdwXFCj4rGyv B1O5FjV5HK3zDoouE8lK0HUu1D6yurf/DwokFclPk/+hOryA9IruTO7BMhMCnmHSs1M4 3uNiiZudXx4VWNbSIp1KXTAyphrQrr4tEQxRI= 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=+hPSdBauf+BrgORcGqfLk3V0E9RvVGPVv1r2PWAGyVw=; b=XI/6XX9X/awnF8JrYbvxkfEQoxDSeuKBS1HavFK5X+zmO2ZTjOz0YOrHcKgxxKRFPH F0BlCmTdRDolqsD4+VmzzWOsL87FklPnP2GyztGYSZ2B2MIDKxVWaLfHw/Ooj7/FOJkF gq9V0n4BVX0LzxvdqmYR6APVBDazINo8tfu71XmcIw9rNmfcPxOJxdjZMxfzVDWxa1UT 9ngERM5OZjVS98EmgZV9IG5t2Hcp/nqDxXuhegMPTgNuqPxaaf3tcLNL/M7vnss5Rp9U 1gvPAKL+xwaqG7KeodvyA7LzumoIZcmDBXPVcIRFGAMSFLzLVfhRtQVgO2KNHN0AbaJw qEzg== X-Gm-Message-State: ALoCoQn8fP/xAzhrR2DRc4eomBSiQH6C0yOjzrTKEJrHUxFmYazYs9TO8wUmtIkhKB0n0rL0LYNs MIME-Version: 1.0 X-Received: by 10.220.17.145 with SMTP id s17mr124991vca.77.1407432627612; Thu, 07 Aug 2014 10:30:27 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Thu, 7 Aug 2014 10:30:27 -0700 (PDT) In-Reply-To: <20140807172619.13877.21972.idtracker@ietfa.amsl.com> References: <20140807172619.13877.21972.idtracker@ietfa.amsl.com> Date: Thu, 7 Aug 2014 10:30:27 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/AZnTpUmIOEMx0i_k7gPETAThoG4 Cc: Thomas Clausen Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-olsrv2-management-snapshot-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: Thu, 07 Aug 2014 17:30:59 -0000 Hi, we have submitted a new revision of the draft in the subject. As part of our own review, we verified IDnits, which was gently reminding us to include an IANA section (although to be removed later by the RFC editor) and a security considerations section into the draft (as required for every RFC). Therefore, we added some text; please have a look. Do remember, though, that this document is not a prescriptive document for how to do management, nor even a recommendation, so it is not the place of this document to suggest how to secure a management framework for OLSRv2. Best regards Ulrich ---------- Forwarded message ---------- From: Date: Thu, Aug 7, 2014 at 10:26 AM Subject: New Version Notification for draft-ietf-manet-olsrv2-management-snapshot-02.txt To: Thomas Clausen , "Thomas H. Clausen" , Ulrich Herberg A new version of I-D, draft-ietf-manet-olsrv2-management-snapshot-02.txt has been successfully submitted by Ulrich Herberg and posted to the IETF repository. Name: draft-ietf-manet-olsrv2-management-snapshot Revision: 02 Title: Snapshot of OLSRv2-Routed MANET Management Document date: 2014-08-07 Group: manet Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-management-snapshot-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-management-snapshot/ Htmlized: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-management-snapshot-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-management-snapshot-02 Abstract: This document describes how Mobile Ad Hoc Networks (MANETs) are typically managed, in terms of pre-deployment management, as well as rationale and means of monitoring and management of MANET routers running the Optimized Link State Routing protocol version 2 (OLSRv2) and its constituent MANET NehgiborHood Discovery Protocol (NHDP). Apart from pre-deployment management for setting up IP addresses and security related credentials, OLSRv2 only needs routers to agree one single parameter (called "C"). Other parameters for tweaking network performance may be determined during operation of the network, and need not be the same in all routers. This, using MIB modules and related management protocols such as SNMP (or possibly other, less "chatty", protocols). In addition, for debugging purposes, monitoring data and performance related counters, as well as notifications ("traps") can be sent to the Network Management System (NMS) via standardized management protocols. This document 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 From nobody Thu Aug 7 10:47: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 41EA21A005F for ; Thu, 7 Aug 2014 10:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 QlGCQjMjPf5E for ; Thu, 7 Aug 2014 10:47:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000C31A0046 for ; Thu, 7 Aug 2014 10:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=215; q=dns/txt; s=iport; t=1407433660; x=1408643260; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bKG/J0fRQ1rm4JneguWI23DbnulfL/h9dHHHW1zQH7c=; b=FpisVemWLEuiEdvHiS2U6rTVI2RJw6MU17HqlKAE8G0SXiFGVeDZmBqn O6X0YJ4urjZ3cEBJY2/UJYxaE/pbibznCk8zutjk2zaD52ZycU/Pw/887 8KPwGUiboGTkUpKRfYBzzK7ibAbkxMpgAEOItBYXR1N1cTNVdKxlB+EGz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAC+741OtJA2H/2dsb2JhbABagw2BLdQaAYEWFneEBAEBBB1cEAIBTjIlAgQOiEfEHRePTAeDL4EcAQScG5RwghGBRoIy X-IronPort-AV: E=Sophos;i="5.01,819,1400025600"; d="scan'208";a="345854959" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 07 Aug 2014 17:47:39 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s77HldSO021984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 17:47:39 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.126]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 12:47:39 -0500 From: "Stan Ratliff (sratliff)" To: Thomas Clausen Thread-Topic: Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization Thread-Index: AQHPsmetgFGqmSrFFkajPEnl2Q8IDw== Date: Thu, 7 Aug 2014 17:47:38 +0000 Message-ID: References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> In-Reply-To: <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] 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/bEtHNblZsQpL8g42oR8A6T92Mfs Cc: "" , manet IETF , manet-ads Subject: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 07 Aug 2014 17:47:41 -0000 Working group participants,=20 This is a working group last call on the two documents mentioned above. Ple= ase submit any issues or concerns via the list on or before August 21, 2014= .=20 Regards, Stan= From nobody Thu Aug 7 14:36: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 54A6F1A0275 for ; Thu, 7 Aug 2014 14:36:10 -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 TEIPuZr9CJkg for ; Thu, 7 Aug 2014 14:36:08 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818A91A0104 for ; Thu, 7 Aug 2014 14:36:08 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id 29so3417808yhl.18 for ; Thu, 07 Aug 2014 14:36: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=nE6U6ukE17o0qKTAb5vP5FOhzS4kGExrOQPL2ZhiJb4=; b=NTwLvxz1jSNmyWZY4Eye74C6TLJW8eoraGzC4H+dOyXK8JpdCV/Tv8TgSzhLc5jtXV S4bg/6jmEohoU7h8+zvVffE7+yTEkATVY9egGcAyr3jHfnRsg1vT2ueiOPiYPstDvU8c +sA2x2DXIkwuSu7s3CcuahjU8TCW7kgd4/u2+90zxnP92XX6/QtedyoFZCS7Y0FOsUEA q5e4Nfb6e0BPnUkAO/wBSW9NBMzRws3ACIroC5W14KMojt0moAv5CEnmB1S685r6mUOg nVH42U0BuiTrBMEiqvtZfBfbXmZGP9Ldy32PsS7GCmwItUJKtBgLOXnp0UvqRigiYvxT N/Ww== MIME-Version: 1.0 X-Received: by 10.236.140.231 with SMTP id e67mr8151630yhj.69.1407447367810; Thu, 07 Aug 2014 14:36:07 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Thu, 7 Aug 2014 14:36:07 -0700 (PDT) In-Reply-To: References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> Date: Thu, 7 Aug 2014 23:36:07 +0200 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=001a11c203ae66032a050010e016 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Jlp76k1QjG4WRe_vmAk8kBTkFJM Cc: "" , manet-ads , manet IETF , Thomas Clausen Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 07 Aug 2014 21:36:10 -0000 --001a11c203ae66032a050010e016 Content-Type: text/plain; charset=UTF-8 My comment: there was an object the optimization draft to be a standard track with an open questioning/discussion, however, no sign for reply from editors, so I don't see reason/interest for my review for the new update versions. AB On Thursday, August 7, 2014, Stan Ratliff (sratliff) wrote: > Working group participants, > > This is a working group last call on the two documents mentioned above. > Please submit any issues or concerns via the list on or before August 21, > 2014. > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c203ae66032a050010e016 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My comment: there was an=C2=A0object the optimization draft to be a=C2=A0st= andard track=C2=A0with an open=C2=A0questioning/discussion, however, no sig= n for reply from editors,=C2=A0so I don't see reason/interest=C2=A0for = my review for the new update versions.=C2=A0

AB

On Thursday, August 7, 2014, Stan Ratliff (sratlif= f) wrote:
Working group participants,
This is a working group last call on the two documents mentioned above. Ple= ase submit any issues or concerns via the list on or before August 21, 2014= .

Regards,
Stan
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--001a11c203ae66032a050010e016-- From nobody Thu Aug 7 14:48: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 E60171A0113 for ; Thu, 7 Aug 2014 14:48:43 -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 6YbVVotfRr7D for ; Thu, 7 Aug 2014 14:48:42 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54361A010C for ; Thu, 7 Aug 2014 14:48:41 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so76617wib.3 for ; Thu, 07 Aug 2014 14:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:mime-version:content-type:in-reply-to:date:cc :message-id:references:to; bh=aql3Z3FA/uUrADVQlm/ToHpUvm/qWyXczRkC+FZ/kZ4=; b=NnCooV5VBcmZdDoeM+4lDcqqrkBHXxFQ4zHzh1dz52UcYXnVIjPHv/SQYOldnFRXIu DEAnmw0oc5l8J+3b5peNHxgKeT4Y6m4YjdsITYKFFig0Plk53dc/DOchQ5uehypzl0H5 hbRDyq7ng+8usjXQx31zbId7hVrOg2mekGuiZT2Fcn+XzI1iw1RjVsQtCU9GDdcnJzDi ejOcXKahHdweqmMaZL7O/D3z2shGG30VbO92+/ypf4zqXSl0KM/PhKqO6qSm8lCA5v7F xjFb3JG/U+LCLKIeY++vz0KEB1RCSTgz9qbC+OnL4MYFwz+MEPyEFyZGt6m5/TEnfdPm qk3Q== X-Received: by 10.180.206.84 with SMTP id lm20mr242544wic.9.1407448120231; Thu, 07 Aug 2014 14:48:40 -0700 (PDT) Received: from [192.168.254.6] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id ex4sm489819wic.2.2014.08.07.14.48.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 14:48:39 -0700 (PDT) From: Christopher Dearlove X-Google-Original-From: Christopher Dearlove Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_9EF26824-6FB0-4F93-80D4-664EA876694A" In-Reply-To: Date: Thu, 7 Aug 2014 22:48:36 +0100 Message-Id: References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9pP6lSNKlG0tVv-RVQVV41gqqtA Cc: "" , manet IETF , manet-ads , Thomas Clausen , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 07 Aug 2014 21:48:44 -0000 --Apple-Mail=_9EF26824-6FB0-4F93-80D4-664EA876694A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii WGLC is when discussion is held (and before it of course). I do not = recall any objection, nor open question. On 7 Aug 2014, at 22:36, Abdussalam Baryun wrote: > My comment: there was an object the optimization draft to be a = standard track with an open questioning/discussion, however, no sign for = reply from editors, so I don't see reason/interest for my review for the = new update versions.=20 >=20 > AB >=20 > On Thursday, August 7, 2014, Stan Ratliff (sratliff) wrote: > Working group participants, >=20 > This is a working group last call on the two documents mentioned = above. Please submit any issues or concerns via the list on or before = August 21, 2014. >=20 > 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 --Apple-Mail=_9EF26824-6FB0-4F93-80D4-664EA876694A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
WGLC is when discussion is held (and before it of course). I do not recall any objection, nor open question.


On 7 Aug 2014, at 22:36, Abdussalam Baryun wrote:

My comment: there was an object the optimization draft to be a standard track with an open questioning/discussion, however, no sign for reply from editors, so I don't see reason/interest for my review for the new update versions. 

AB

On Thursday, August 7, 2014, Stan Ratliff (sratliff) wrote:
Working group participants,

This is a working group last call on the two documents mentioned above. Please submit any issues or concerns via the list on or before August 21, 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

--Apple-Mail=_9EF26824-6FB0-4F93-80D4-664EA876694A-- From nobody Thu Aug 7 14:55:02 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 55F621A01AF for ; Thu, 7 Aug 2014 14:55:00 -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 xQF6rhvKDybX for ; Thu, 7 Aug 2014 14:54:58 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31E51A014F for ; Thu, 7 Aug 2014 14:54:58 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id b6so3465906yha.28 for ; Thu, 07 Aug 2014 14:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MtxgC6g6fxdmTeCb6rEi/6camYX7dTDNhU6vdmvO9XU=; b=QQb+I2x6TWUHCIK+OI1cUr+yAtF5oDMhcD3IEdpqoWc2Xqk++MoO2b9cVZvu+XXvpc FqccyGUkW9Df12e+g4RuyKsfkJRxeIOpvc8kZtLglkHElsuJTdc0SZFibkySPDgqb+F3 u8nh0Bq6bXJeEOsYPcfEA3fDHINNamhE/zoIFfni1z9svJlVK9FK0rAt50fWmyQHxnH6 cuvhE5QVlsIfyuYo3jYbtiLVLOU6grYq1cGxCFEjnEnd9zmOz6J1pHJc0ojcbz6kmuBs 4HLFd8SgsODJgpxVFgljBuGY8ZI0Oupudn6+BBzm2kpgbwuveWPdN2qum5NFDWVPkdX3 7QOQ== MIME-Version: 1.0 X-Received: by 10.236.23.163 with SMTP id v23mr8688265yhv.58.1407448497966; Thu, 07 Aug 2014 14:54:57 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Thu, 7 Aug 2014 14:54:57 -0700 (PDT) In-Reply-To: <4857CBDE-DA81-4A80-9840-B3E6F43D7081@thomasclausen.org> References: <4857CBDE-DA81-4A80-9840-B3E6F43D7081@thomasclausen.org> Date: Thu, 7 Aug 2014 23:54:57 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Clausen Content-Type: multipart/alternative; boundary=089e013d0700c2d4d0050011230f Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Ysalz_0ssA5_tseeB2gMD_c8SLE Cc: "" , manet-ads , manet Subject: Re: [manet] Summary of Collective Next Steps - with some errors fixed (with respect to presentation in Toronto) 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, 07 Aug 2014 21:55:00 -0000 --089e013d0700c2d4d0050011230f Content-Type: text/plain; charset=UTF-8 The plan suggested needs some times for my responds, however, I only speak for myself so just wanted to suggest reasonable time plan to ensure quality of such drafts processes. AB On Monday, July 28, 2014, Thomas Clausen wrote: > > All, > > In Toronto, I showed this slide -- which reflected the collective status > of the documents for which an "immanent action has been requested or > suggested". It's auto-generated from a(n ever evolving) spreadsheet I use > for IETF document tracking. > > As it was suggested to me that this was actually useful, I'm shooting out > an updated version, and will probably do that at "irregular intervals" in > the future. > > Best, > > Thomas > --089e013d0700c2d4d0050011230f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The plan suggested needs some times for my responds, however, I only speak = for myself so just wanted to suggest reasonable time plan to ensure quality= of such drafts processes.=C2=A0

AB

On Monday, Ju= ly 28, 2014, Thomas Clausen wrote:

All,

In Toronto, I showed this slide -- which reflected the collective status of= the documents for which an "immanent action has been requested or sug= gested". It's auto-generated from a(n ever evolving) spreadsheet I= use for IETF document tracking.

As it was suggested to me that this was actually useful, I'm shooting o= ut an updated version, and will probably do that at "irregular interva= ls" in the future.

Best,

Thomas
--089e013d0700c2d4d0050011230f-- From nobody Thu Aug 7 15:16: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 15B421A02DB for ; Thu, 7 Aug 2014 15:16:02 -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 1AhQnIjZw4rn for ; Thu, 7 Aug 2014 15:16:00 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394981B284B for ; Thu, 7 Aug 2014 15:16:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 064753218E5; Thu, 7 Aug 2014 15:16:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.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 mailc2.tigertech.net (Postfix) with ESMTPSA id 366EC321807; Thu, 7 Aug 2014 15:15:59 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C756AE97-21E0-463B-9EDB-76B38681360E Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Fri, 8 Aug 2014 00:15:55 +0200 Content-Transfer-Encoding: 7bit Message-Id: <22176420-ED4C-497D-ACE9-15AFF0084E8A@thomasclausen.org> References: <4857CBDE-DA81-4A80-9840-B3E6F43D7081@thomasclausen.org> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Pcazc0M_UKP25lQWkOxAtqkQn60 Cc: "" , manet , manet-ads Subject: Re: [manet] Summary of Collective Next Steps - with some errors fixed (with respect to presentation in Toronto) 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, 07 Aug 2014 22:16:02 -0000 --Apple-Mail-C756AE97-21E0-463B-9EDB-76B38681360E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear Abdussalam, This slide simply reflects what document authors had requested, without maki= ng any judgments vs the request.=20 This slide is not a plan. As you no doubt have noticed, I am not MANET WG ch= air, nor do I have any other leadership positions in the IETF, so it's not f= or me to make plans. I'm just a random WG participant, who likes making and updating spreadsheets= for his own utility, and who occasionally shares it as a public service to o= ther WG participants. Thomas Sent from my iPad > On 07 Aug 2014, at 23:54, Abdussalam Baryun w= rote: >=20 > The plan suggested needs some times for my responds, however, I only speak= for myself so just wanted to suggest reasonable time plan to ensure quality= of such drafts processes.=20 >=20 > AB >=20 >> On Monday, July 28, 2014, Thomas Clausen wrote: >>=20 >> All, >>=20 >> In Toronto, I showed this slide -- which reflected the collective status o= f the documents for which an "immanent action has been requested or suggeste= d". It's auto-generated from a(n ever evolving) spreadsheet I use for IETF d= ocument tracking. >>=20 >> As it was suggested to me that this was actually useful, I'm shooting out= an updated version, and will probably do that at "irregular intervals" in t= he future. >>=20 >> Best, >>=20 >> Thomas > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-C756AE97-21E0-463B-9EDB-76B38681360E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Abdussalam,

This slide s= imply reflects what document authors had requested, without making any judgm= ents vs the request. 

<= div>This slide is not a plan. As you no doubt have noticed, I a= m not MANET WG chair, nor do I have any other leadership positions in the IE= TF, so it's not for me to make plans.

I'm just a random WG participant, who likes mak= ing and updating spreadsheets for his own utility, and who occasionally shar= es it as a public service to other WG participants.

Thomas

Sent from my iPad

On 07 Aug 2014, at 23:54, Abdussalam Baryun <abdussalambaryun@gmail.com> w= rote:

The plan suggested needs some times for my responds, however= , I only speak for myself so just wanted to suggest reasonable time plan to e= nsure quality of such drafts processes. 

AB

O= n Monday, July 28, 2014, Thomas Clausen wrote:

All,

In Toronto, I showed this slide -- which reflected the collective status of t= he documents for which an "immanent action has been requested or suggested".= It's auto-generated from a(n ever evolving) spreadsheet I use for IETF docu= ment tracking.

As it was suggested to me that this was actually useful, I'm shooting out an= updated version, and will probably do that at "irregular intervals" in the f= uture.

Best,

Thomas
_______________________________________________=
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
=
= --Apple-Mail-C756AE97-21E0-463B-9EDB-76B38681360E-- From nobody Fri Aug 8 01:19: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 B80AC1ABB2D for ; Fri, 8 Aug 2014 01:19:51 -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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, J_CHICKENPOX_26=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 lo1E_f25Y5gT for ; Fri, 8 Aug 2014 01:19:50 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF821ABB32 for ; Fri, 8 Aug 2014 01:19:50 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 131so3626574ykp.0 for ; Fri, 08 Aug 2014 01:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z7B/LImQ06CztiyOnB3vHwnAInX/mmrmWxyzXCiK6D8=; b=yM7/f5yi776KsuU88ftgArvYBnKwZg9wsFKVyxdCKYl6Tdg26gQ32e2CObI8R1w7WN SSHSq8PABfXTpt2TRolt2qZ2yUi/Ao9XRNqUr6sViIIeEq5b4IyLczJRyH8mZ4h4MGgD m+SpvEu7KMVQUPdYgN/o+ZN2vYUSlGJrc1VFOaVcuGha+Did6+B5BuDFjGek7R1QvC7i 5p4T8GMoMHWqhagqg+lkFAv6Au62TIYpM+wLJ/4dyIIu9Y3NR7+aONKBx2TiNoD4I9+w ClhWuSKgHb01R674trOcOK0LQsODVenYXejgkJFr0OmqTkUgm9ckeGWCxqpXSMInyT8C T+iA== MIME-Version: 1.0 X-Received: by 10.236.116.202 with SMTP id g50mr1963149yhh.147.1407485989520; Fri, 08 Aug 2014 01:19:49 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Fri, 8 Aug 2014 01:19:49 -0700 (PDT) In-Reply-To: <6734E4B2-C99B-40F8-B328-1AA342AADDEE@thomasclausen.org> References: <4857CBDE-DA81-4A80-9840-B3E6F43D7081@thomasclausen.org> <6734E4B2-C99B-40F8-B328-1AA342AADDEE@thomasclausen.org> Date: Fri, 8 Aug 2014 10:19:49 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Clausen Content-Type: multipart/alternative; boundary=20cf3036388d6e8ee7050019ded9 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/x-S3WFziHYM8qz4BYaVAyCvHzK0 Cc: "" , manet-ads , manet Subject: Re: [manet] Summary of Collective Next Steps - with some errors fixed (with respect to presentation in Toronto) 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, 08 Aug 2014 08:19:52 -0000 --20cf3036388d6e8ee7050019ded9 Content-Type: text/plain; charset=UTF-8 Dear Thomas, CC:chairs and AD Thanks. I suggest we make the summary into the WG milestones with dates, because the WG milestones are the real next steps of the WG. AB On Thursday, August 7, 2014, Thomas Clausen wrote: > Dear Abdussalam, > > This slide simply reflects what document authors had requested, without > making any personal judgment vs the request. > > This slide is not a plan. As you no doubt have noticed, I am not MANET WG > chair, nor do I have any other leadership positions in the IETF, so it's > not for me to make plans. > > I'm just a random WG participant, who likes making and updating > spreadsheets for his own utility, and who occasionally shares it as a > public service. > > Thomas > > Sent from my iPad > > On 07 Aug 2014, at 23:54, Abdussalam Baryun > wrote: > > The plan suggested needs some times for my responds, however, I only speak > for myself so just wanted to suggest reasonable time plan to ensure quality > of such drafts processes. > > AB > > On Monday, July 28, 2014, Thomas Clausen wrote: > >> >> All, >> >> In Toronto, I showed this slide -- which reflected the collective status >> of the documents for which an "immanent action has been requested or >> suggested". It's auto-generated from a(n ever evolving) spreadsheet I use >> for IETF document tracking. >> >> As it was suggested to me that this was actually useful, I'm shooting out >> an updated version, and will probably do that at "irregular intervals" in >> the future. >> >> Best, >> >> Thomas >> > --20cf3036388d6e8ee7050019ded9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Thomas,
CC:chairs and AD

Thanks. I suggest = we make the summary into the WG=C2=A0milestones with dates, because the WG = milestones are the real=C2=A0next steps of the WG.=C2=A0

AB

On Thursday, August 7, 2014, Thomas Clausen wrote:
Dear Abdussalam,

=
This slide simply reflects what document authors had requested, without mak= ing any personal judgment vs the request.=C2=A0

Th= is slide is not a plan. As you no doubt have noticed, I am not MANET WG cha= ir, nor do I have any other leadership positions in the IETF, so it's n= ot for me to make plans.

I'm just a random WG participant, who likes making = and updating spreadsheets for his own utility, and who occasionally shares = it as a public service.

Thomas

Sent from my iPa= d

On 07 Aug 2014, at 23:54, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

The plan suggested needs some times for my responds, however, I only s= peak for myself so just wanted to suggest reasonable time plan to ensure qu= ality of such drafts processes.=C2=A0

AB

On Monda= y, July 28, 2014, Thomas Clausen wrote:

All,

In Toronto, I showed this slide -- which reflected the collective status of= the documents for which an "immanent action has been requested or sug= gested". It's auto-generated from a(n ever evolving) spreadsheet I= use for IETF document tracking.

As it was suggested to me that this was actually useful, I'm shooting o= ut an updated version, and will probably do that at "irregular interva= ls" in the future.

Best,

Thomas
--20cf3036388d6e8ee7050019ded9-- From nobody Fri Aug 8 04:34: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 DF89F1A01AF; Fri, 8 Aug 2014 04:34:17 -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 DPJhWOEhjbpd; Fri, 8 Aug 2014 04:34:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4936F1B2AE4; Fri, 8 Aug 2014 04:34:14 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808113414.26522.38293.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 04:34:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/J9Ri3llbuSKFvtBtlZvUPeIiq9k Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-02.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: Fri, 08 Aug 2014 11:34:18 -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-02.txt Pages : 17 Date : 2014-08-08 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-dat-metric-02 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 Fri Aug 8 04:39: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 664311B2A64 for ; Fri, 8 Aug 2014 04:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 7fpGAZHcmaIt for ; Fri, 8 Aug 2014 04:39:19 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3571A01AF for ; Fri, 8 Aug 2014 04:39:18 -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 1XFiVx-0003AX-9b for manet@ietf.org; Fri, 08 Aug 2014 13:39:17 +0200 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 1XFiVx-0003Fo-5v for manet@ietf.org; Fri, 08 Aug 2014 13:39:17 +0200 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; Fri, 8 Aug 2014 13:39:17 +0200 Message-ID: <53E4B6DB.80408@fkie.fraunhofer.de> Date: Fri, 8 Aug 2014 13:39:07 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <20140808113414.26522.38293.idtracker@ietfa.amsl.com> In-Reply-To: <20140808113414.26522.38293.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050204080208080308040303" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19268/Thu Aug 7 20:23:44 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c51b770f3e2e0970392bce6b101b1534 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/jrZKcBr53gQkCRT0jWUQM2P6Lqo Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-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: Fri, 08 Aug 2014 11:39:21 -0000 --------------ms050204080208080308040303 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I have just finished working through the review of Thomas Clausen of my draft and pushed a new revision. A major point where I disagree with Thomas is the IANA registration. I think there is no real benefit to register a metric codepoint for a metric that is completely asymmetric and does not need to know what metric the other side of the link is using. In a normal MANET I would just use the "tlv extension" 0... or maybe 0-15 if I run a multi-topology network. What does the working group think, shall we add an IANA registration anyways, making it mandatory for all coming link metrics? Henning Rogge On 08/08/2014 01:34 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. >=20 > Title : Packet Sequence Number based directional airt= ime metric for OLSRv2 > Authors : Henning Rogge > Emmanuel Baccelli > Filename : draft-ietf-manet-olsrv2-dat-metric-02.txt > Pages : 17 > Date : 2014-08-08 >=20 > Abstract: > This document specifies an directional airtime link metric for usage= > in OLSRv2. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-dat-metric/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-dat-metric-0= 2 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 --=20 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 --------------ms050204080208080308040303 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 Fw0xNDA4MDgxMTM5MTVaMCMGCSqGSIb3DQEJBDEWBBTb3UbYMYlkNtXUhLQN4Yi+zvEq3TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAFEjMIweOnR07a0OtNV41a5N6q3mXw/zgIfYCrTP+vK7e MubJreIMLLGCgxCnGOGL/Cj17CyBCShVczjVkWU6ubBHFLzMk870445v/F7YhYqP1J66JVsA aLQDNWljlYOJOAE5C/6VECDMU7OaHNrojYp5sSweStgHdhaCCqWpoAp9/oZX0OMsqZ0WXByE 0PNJNMMBdg4rA/fBaAg7qE7SHwIaPR2RUykp6IJd5ELz6UKCWFmwNTTX5WLlmYyhenDpBLRq oJfnq5/aN/6mLaNszwt9cbevt52gWoChpkyTvCxJ4T4XVlH0DEP9ROWKMBEgQIV6uvQ1wJEf jxqisAt9DQAAAAAAAA== --------------ms050204080208080308040303-- From nobody Fri Aug 8 05:34: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 5B5F81B2B59 for ; Fri, 8 Aug 2014 05:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 PyjhNm9LV6ep for ; Fri, 8 Aug 2014 05:34:51 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E191B2B57 for ; Fri, 8 Aug 2014 05:34:50 -0700 (PDT) Received: by mail-oi0-f50.google.com with SMTP id a141so3585906oig.37 for ; Fri, 08 Aug 2014 05:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=P/m60coaAfEkIDSupFsxrZ28rbj5K0i56PHoYOjBGdY=; b=YywtfL5oG+vn6i3VFgY5cjQqvH6jKI3DfIlf5uBAmd/Ja005piZKJU4DELi4kcZ31K l6P7H6XRDbRyiXljEp3nPTVuVv6wscNXYOo+OQOdfBOZ3wTzYBrR2Db73xtAZ+Qy2BIE cAEdyTg0vJw/n/2rYKK4l0YkYk5Yy+U3XSoJhcf827viHslICrsOvimsa/3qOu3wEt9r Ei3WkQYCSHqPmJdfoBt4GyhJNcLfuNTZzOXk6tDj/zuBHpkrARaWw63x9LatlQhUcxiC nsDd5kVYieBqMizxWymtOWVM2VYHzZz/qmwKGiaA+v0JVn38vmKU4adOmzHHJ63F4TsL obwg== MIME-Version: 1.0 X-Received: by 10.60.164.9 with SMTP id ym9mr30002446oeb.26.1407501290438; Fri, 08 Aug 2014 05:34:50 -0700 (PDT) Received: by 10.76.104.206 with HTTP; Fri, 8 Aug 2014 05:34:50 -0700 (PDT) Date: Fri, 8 Aug 2014 14:34:50 +0200 Message-ID: From: Sylvain David To: manet@ietf.org Content-Type: multipart/alternative; boundary=089e0158bffa7008a005001d6e41 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/uhN6FgKAY0QO-SRhSuKDiDy0oio Subject: Re: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document 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, 08 Aug 2014 12:34:52 -0000 --089e0158bffa7008a005001d6e41 Content-Type: text/plain; charset=UTF-8 I'm in favor of WG adoption. --089e0158bffa7008a005001d6e41 Content-Type: text/html; charset=UTF-8
I'm in favor of WG adoption.
--089e0158bffa7008a005001d6e41-- From nobody Fri Aug 8 05:38: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 4DD641B2B53 for ; Fri, 8 Aug 2014 05:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 zoqSdrTfKa9I for ; Fri, 8 Aug 2014 05:38:43 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152601A0AC7 for ; Fri, 8 Aug 2014 05:38:43 -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 1XFjRR-0001n4-AS for manet@ietf.org; Fri, 08 Aug 2014 14:38:41 +0200 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 1XFjRR-0003YT-6j for manet@ietf.org; Fri, 08 Aug 2014 14:38:41 +0200 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; Fri, 8 Aug 2014 14:38:41 +0200 Message-ID: <53E4C4C7.1050905@fkie.fraunhofer.de> Date: Fri, 8 Aug 2014 14:38:31 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090802010105010908010706" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19268/Thu Aug 7 20:23:44 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: a22a8819f20226a2167e46b22584aa1b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ZsMooodNBphak7NAqYp8GfKvHic Subject: Re: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document 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, 08 Aug 2014 12:38:45 -0000 --------------ms090802010105010908010706 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 08/08/2014 02:34 PM, Sylvain David wrote: > I'm in favor of WG adoption. I am also in favor adopting it as an experimental draft. I think multipath-routing in radio networks is still a quite complicated topic and it will need quite a bit experimentation to find a "one size fits all" variant of the Dijkstra algorithm that maintains enough separation between the different paths. 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 --------------ms090802010105010908010706 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 Fw0xNDA4MDgxMjM4MzlaMCMGCSqGSIb3DQEJBDEWBBTlJYjzlUDx9jPsyLxt3kyfBtzuijBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAL1ylUjyz36ONIcm62VROtkOoACy7zurz36uxa4dY/lg9 kkWEXzhud/VPl1KBBgdakNWDBBiwqcFucO5N2dbtMbKG9YOqIetkv86fNz20Ab/iht8xOC/G tb7DWspcuyEkmnqFw3yeJReNuXlriEXfJQiSpL1YpZKVfZEXwgoqr1fzP7GGNL6WMF3De6aM mRBAwRsuMuvwy3zR787qk/Q4QN3nA+tnJApMK6TxXhIhAlDheNU2wEPq1TkTaXLplDOVjOat 0fojQ6BTvDgdZA5NbNYVbMIjycvB87T2NzttYOC8QKmu0iX/GhZF15iuqkLWxzAigaPRb8ry B9bTEobgqwAAAAAAAA== --------------ms090802010105010908010706-- From nobody Fri Aug 8 06:45: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 045AE1B29A2 for ; Fri, 8 Aug 2014 06:45:10 -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, 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 zLAdoHnMGxEI for ; Fri, 8 Aug 2014 06:45:07 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908421B29A0 for ; Fri, 8 Aug 2014 06:45:06 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so5721780wes.36 for ; Fri, 08 Aug 2014 06:45:05 -0700 (PDT) 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=bASAP/Sy90KTAvlMkqG8fq4emauMEs06LJt+0OWSQQE=; b=YyUkwlGWHtDm0ZipsXIwJJ0LtG/k1SE+JlY1XebRhWRVvc+bLwEjlnuEr0xm8owLed +ZKLEr+fsgfk4MrhOcLAXafT5PXrO72mtbOZ3dxlEbmxGZEafBRfx99UymP49pEAYeG4 jAuLAgQ/v+hSEk13CiDprypV6be4nwxJcdIP+uCFFOxgQdFf6K4HFKabun7TFuqK0WBW +mDAqD65B/sR2UnRIw5T8J5IxGvcVKEEmStyMrwPMpBoTBCVEdma1fBeScjt8xjZvYS8 kTL3LtG5jZS3+NA8AfKhnLnFUYFhCTnQjfdI8V/C2aStrZTrsDDLgNDuDGD5g9W0OYUV Qfyg== X-Gm-Message-State: ALoCoQl33GNWzMwv305qIHYbakBm1bKMcFqa/mNZ8YBefQbBAu0edN380WN0pjvZHzoZSQFaBVDk X-Received: by 10.194.57.132 with SMTP id i4mr31452065wjq.6.1407505505592; Fri, 08 Aug 2014 06:45:05 -0700 (PDT) Received: from [192.168.178.95] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPSA id x11sm17502678wjr.15.2014.08.08.06.45.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 06:45:04 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Teco Boot In-Reply-To: <53E4B6DB.80408@fkie.fraunhofer.de> Date: Fri, 8 Aug 2014 15:45:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140808113414.26522.38293.idtracker@ietfa.amsl.com> <53E4B6DB.80408@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/EfpaHWBYUuCdr8ED2JtTieyU1R0 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-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: Fri, 08 Aug 2014 13:45:10 -0000 You need IANA registration if you want to transfer specific information, = like data rate, signal strength, loss ratio. If you use such info just = to calculate the default dimensionless metric, which I think you propose = in your draft, IANA registration does not make sense to me. My advice is to add some text on using the Directional airtime metric = for calculating the "Link metric meaning assigned by administrative = action". You just automate the administrative action. Teco Op 8 aug. 2014, om 13:39 heeft Henning Rogge = het volgende geschreven: > Hi, >=20 > I have just finished working through the review of Thomas Clausen of = my > draft and pushed a new revision. >=20 > A major point where I disagree with Thomas is the IANA registration. >=20 > I think there is no real benefit to register a metric codepoint for a > metric that is completely asymmetric and does not need to know what > metric the other side of the link is using. >=20 > In a normal MANET I would just use the "tlv extension" 0... or maybe > 0-15 if I run a multi-topology network. >=20 > What does the working group think, shall we add an IANA registration > anyways, making it mandatory for all coming link metrics? >=20 > Henning Rogge >=20 >=20 > On 08/08/2014 01:34 PM, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. >>=20 >> Title : Packet Sequence Number based directional = airtime metric for OLSRv2 >> Authors : Henning Rogge >> Emmanuel Baccelli >> Filename : draft-ietf-manet-olsrv2-dat-metric-02.txt >> Pages : 17 >> Date : 2014-08-08 >>=20 >> Abstract: >> This document specifies an directional airtime link metric for = usage >> in OLSRv2. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-dat-metric/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-02 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-dat-metric-02 >>=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 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Fri Aug 8 07:01: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 857A61B2A22 for ; Fri, 8 Aug 2014 07:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 BrO-iAa1JV-U for ; Fri, 8 Aug 2014 07:01:45 -0700 (PDT) Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359DE1B2A54 for ; Fri, 8 Aug 2014 07:01:42 -0700 (PDT) Received: from [192.168.0.7] (host101-207-dynamic.1-87-r.retail.telecomitalia.it [87.1.207.101]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mxbk.iit.cnr.it (Postfix) with ESMTPSA id 01C73C0419 for ; Fri, 8 Aug 2014 16:01:36 +0200 (CEST) Message-ID: <53E4D842.7070900@iit.cnr.it> Date: Fri, 08 Aug 2014 16:01:38 +0200 From: Elisabetta Biondi User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: manet@ietf.org References: <53e0f351.j7PEQ+hTL1rJSHYa%chants14_publicity@iit.cnr.it> In-Reply-To: <53e0f351.j7PEQ+hTL1rJSHYa%chants14_publicity@iit.cnr.it> X-Forwarded-Message-Id: <53e0f351.j7PEQ+hTL1rJSHYa%chants14_publicity@iit.cnr.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Xy5I99w59cakU6AIIItSRaFPcFg Subject: [manet] ACM CHANTS 2014 (co-located with ACM MobiCom): call for participation 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, 08 Aug 2014 14:01:47 -0000 ------------------------------------------------------------------------ - Our apologies if you receive multiple copies of this CFP - ------------------------------------------------------------------------ CALL FOR PARTICIPATION ACM CHANTS 2014 - 9th Workshop on Challenged Networks co-located with ACM MobiCom 2014 7 September 2014, Maui, Hawaii, USA www.acm-chants.org Supported by the FP7 EU MOTO project http://www.fp7-moto.eu ------------------------------------------------------------------------ ****** Early registration deadline: August 9, 2014 ******* ------------------------------------------------------------------------ Featuring: 1 Keynote talk: Giovanni Pau, LIP6-UPMC, France 10 full papers + 5 concise papers 5 demos Details at http://acm-chants.org/, as well as below. ======================================================================== TECHNICAL PROGRAM ======================================================================== 08:20 - 08:30 Welcome 08:30 - 09:15 Keynote Talk Prof. Giovanni Pau, LIP6-UPMC, France Title: Will ICN ride Challenged Network Environments? 09:15 - 10:00 New scenarios and deployment issues for challenged networks ------------------------------------------------------------------------ Enhancing Opportunistic Networks with Legacy Nodes Marcin Nagy, Teemu Karkkainen, and Jorg Ott Opportunistic Interaction in the Challenged Internet of Things Hanno Wirtz, Jan Ruth, Martin Serror, Jo Agila Bitsch Link and Klaus Wehrle 10:00 - 10:30 Coffee Break 10:30 - 12:00 Challenged networking solutions for heterogeneous networks ------------------------------------------------------------------------ Mind the Gap: Modelling Video Delivery Under Expected Periods of Disconnection Argyrios Tasiopoulos, Ioannis Psaras and George Pavlou Flooding data in a cell: Is cellular multicast better than device-to-device communications? Filippo Rebecchi, Marcelo Dias de Amorim and Vania Conan A message ferrying approach to low-cost backhaul in cellular networks Sayed A. Hoseini, Azade Fotouhi, Mahbub Hassan, Chun T. Chou and Mostafa Ammar Adaptive Data Offloading in Opportunistic Networks through an Actor-Critic Learning Method Lorenzo Valerio, Raffaele Bruno and Andrea Passarella 12:00 - 13:30 Lunch Break 13:30 - 15:00 Mechanisms for challenged networks ------------------------------------------------------------------------ Stalk Me if You Can - The Anatomy of Sybil Attacks in Opportunistic Networks Sacha Trifunovic and Andreea Hossmann-Picu Dynamic framework for building highly-localized Mobile Web DTN applications Kartik Sankaran, Akkihebbal L. Ananda, Mun Choon Chan and Li-Shiuan Peh Bundle Protocol Header Compression Martin Wegner, Wolf-Bastian Pottner and Lars Wolf WD2: An Improved WiFi-Direct Group Formation Protocol Hongxu Zhang, Yufeng Wang and Chiu Tan 15:00 - 15:30 Coffee Break 15:30 - 16:10 Demonstrations ------------------------------------------------------------------------ RasPiNET: Decentralised Communication and Sensing Platform with Satellite Connectivity Eiko Yoneki Opportunistic communications to alleviate cellular infrastructures Farid Benbadis, Filippo Rebecchi, Florian Cosnier, Matteo Sammarco, Marcelo Dias de Amorim and Vania Conan Wireless IP mesh on Android for firemen monitoring Ana Aguiar, Eduardo Soares, Pedro Brandao, Tiago Magalhaes, Jose Maria Fernandes and Ilidio Oliveira Application-Transparent Deployment of DTN via SmartNet Lance Alt, Geoffrey Xie and Justin Rohrer Demo: Enhancing Opportunistic Networks with Legacy Nodes Teemu Karkkainen, Marcin Nagy and Jorg Ott Mobile Opportunistic System for Experience Sharing (MOSES) in Indoor Exhibitions Fehmi Ben Abdesslem and Anders Lindgren 16:10 - 17:50 Concise contributions ------------------------------------------------------------------------ Congestion Control in Disruption-Tolerant Networks: a Comparative Study for Interplanetary Networking Applications Aloizio Silva, Scott Burleigh, Celso Hirata and Katia Obraczka Hot Spot Selection in Rural Access Nanosatellite Networks Marco Cello, Mario Marchese and Fabio Patrone Revisiting Pitfalls of DTN Datasets Statistical Analysis Gwilherm Baudic, Tanguy Perennou and Emmanuel Lochin On Efficient Data Collection with Delay Minimization in Deep Sea Jie Wu and Huanyang Zheng Shared Content Editing in Opportunistic Networks Teemu Karkkainen and Jorg Ott 17:50 - 18:00 Closing remarks ======================================================================== From nobody Fri Aug 8 10:33: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 5A21E1B2BF9 for ; Fri, 8 Aug 2014 10:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 HtXrjNgqPBDj for ; Fri, 8 Aug 2014 10:33:36 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C841B2B97 for ; Fri, 8 Aug 2014 10:33:31 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s78HXND8002303; Fri, 8 Aug 2014 18:33:23 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s78HXIdx002220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2014 18:33:21 +0100 From: "Adrian Farrel" To: "'Christopher Dearlove'" , "'Abdussalam Baryun'" References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> In-Reply-To: Date: Fri, 8 Aug 2014 18:33:17 +0100 Message-ID: <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AF_01CFB337.3B7377F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFlogsEsLq7uNgsMAkmO+h8+jv1BwE4j5cSAqXXMI8ByZ999wGwpzPmnGBPjNA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20868.001 X-TM-AS-Result: No--22.367-10.0-31-10 X-imss-scan-details: No--22.367-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtEzx9GDMr0HvzYTypjB3iDVDYBVKmbeeQNpifu1ea0XM3qW VMkOhHg1zlZqgG1Ac/LvUl9LSkKwTo4a2rhHAtuZIyvp1AQXH8vopnaEFCKOeNJgDNnoqapaq8k 2QEqE4yVQPdeDNvxotYmlzyMidQUrv2sAeJ15zQbiNGQgiadfQwtx7lnIMkAm4myBeYKxy0WrEX ugPHvhRW4zDpvEsAkmUGL5XlDynpOnbwo3utj2R6yBo9Jaui9GgFWL4mAkjkGSNcbecZTzofI8z C9vqWtzWqINS4FZPxhWJjc5hzdkk2ebwiqyDhxxr3X9gdfSLWUZbpN+hw0Ke6NIF3ryQt73MQYW N5nDJFTJZ9QHjpNa9hhiIqC7/ynl8Wds9taEnsyVUcz8XpiS9COSuAnftGqPxSZxKZrfThNqoB4 6H80riXsSMlKblqe9G7JmxvXwtb3+st4JVw/J4DCIlN/eSPB9IfyQNHR2nabhE0WvrIvnq0GzU7 CKX1sd1skCTGBJ9mp77384BTKUT9NJLb05NEhp/Sl5cYQQGW+uiAW0p38/t9KWShEsIp8TnpBWe VcwjKCdfbTr9wk1pfzxIC9LasqudG57tpB6osSzLD5kmcW6ZBOySJ0+MHXaE435Dt6W/lg9JrCI Esrp9x/2e9RyQzWhWnMoQfS9Wq8Sd6sOmnf5YwAYYobwIbwCSHjWEz/Dpkz5N0o2THGRZFJQYfp G4rTPPw1HPwekKZJkRkp1KngjvTkEZfvfb2jJDB+ErBr0bANar2Wff4KSIY9osn8JrdJPaOLTgT M6Njg8NwUqJRyhvtehSCqAkY5VNYG1JZn5sTqeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7E+N7oe5M1Kp/j9dpg7UDFmXkFqozGCmzyDgfP5aEBEa1KZrJfvHyA+IieNLCsOfoQ== Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hkiAHxsZVoVyyVyjFWHQheULg6M Cc: manet-chairs@tools.ietf.org, 'manet IETF' , 'manet-ads' , 'Thomas Clausen' , "'Stan Ratliff \(sratliff\)'" Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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: Fri, 08 Aug 2014 17:33:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03AF_01CFB337.3B7377F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Chris, I believe Abdussalam is referring to an email he sent on 3rd July this year (although it would have been helpful had he made this clear). In http://www.ietf.org/mail-archive/web/manet/current/msg16408.html he raised some questions during the poll for document adoption. A quick, non-scientific, and unthorough scan of the archives does not show an answer. I can't say that I can parse the referenced email with ease, but I think I see a request to substantiate the assertion implicit in the draft that there is some optimization benefit to the work. You might reasonably respond to that "allowing immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently obviously makes the symmetric 2-hop neighborhood more robust, and so the updates to the two RFCs clearly represents an optimization." I must say that I find it hard to correlate that old email with the new comment that "there was an object the optimization draft to be a standard track with an open questioning/discussion." I do not see any objection in the archive to the publication of the draft on the Standards Track. All I see is a "vote" to not adopt the I-D. Abdussalam: You go on to say "I don't see reason/interest for my review for the new update versions." That's OK. There is no requirement for you to review this document nor to send any email commenting on whether or not you have reviewed it. Adrian From: Christopher Dearlove [mailto:christopher.dearlove@gmail.com] Sent: 07 August 2014 22:49 To: Abdussalam Baryun Cc: Stan Ratliff (sratliff); ; manet-ads; manet IETF; Thomas Clausen Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization WGLC is when discussion is held (and before it of course). I do not recall any objection, nor open question. On 7 Aug 2014, at 22:36, Abdussalam Baryun wrote: My comment: there was an object the optimization draft to be a standard track with an open questioning/discussion, however, no sign for reply from editors, so I don't see reason/interest for my review for the new update versions. AB On Thursday, August 7, 2014, Stan Ratliff (sratliff) wrote: Working group participants, This is a working group last call on the two documents mentioned above. Please submit any issues or concerns via the list on or before August 21, 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 ------=_NextPart_000_03AF_01CFB337.3B7377F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chris,

 

I believe Abdussalam is = referring to an email he sent on 3rd July this year (although it would = have been helpful had he made this clear).

 

In = http://www.ietf.org/mail-archive/web/manet/current/msg16408.html he = raised some questions during the poll for document adoption. A quick, = non-scientific, and unthorough  = scan of the archives does not show an = answer.

 

I can't say that I can parse = the referenced email with ease, but I think I see a request to = substantiate the assertion implicit in the draft that there is some = optimization benefit to the work. You might reasonably respond to that = "allowing immediate reinstatement of the symmetric 2-hop neighbor = if the link quality later improves sufficiently obviously makes the = symmetric 2-hop neighborhood more robust, and so the updates to the two = RFCs clearly represents an optimization."

 

I must say that I find it hard = to correlate that old email with the new comment that "there was an = object the optimization draft to be a standard track with an open = questioning/discussion." I do not see any objection in the archive = to the publication of the draft on the Standards Track. All I see is a = "vote" to not adopt the I-D.

 

Abdussalam: You go on to say = "I don't see reason/interest for my review for the new update = versions."  That's OK. = There is no requirement for you to review this document nor to send any = email commenting on whether or not you have reviewed = it.

 

Adrian

 

 

From: Christopher = Dearlove [mailto:christopher.dearlove@gmail.com]
Sent: 07 = August 2014 22:49
To: Abdussalam Baryun
Cc: Stan = Ratliff (sratliff); <manet-chairs@tools.ietf.org>; manet-ads; = manet IETF; Thomas Clausen
Subject: Re: [manet] Working group = last call for draft-ietf-manet-rfc6779bis and = draft-ietf-manet-nhdp-optimization

 

WGLC is when = discussion is held (and before it of course). I do not recall any = objection, nor open question.

 

 

On 7 Aug 2014, at = 22:36, Abdussalam Baryun wrote:



My comment: there was an object the optimization draft to = be a standard track with an open questioning/discussion, = however, no sign for reply from editors, so I don't see = reason/interest for my review for the new update = versions. 

 

AB

On Thursday, August 7, 2014, Stan Ratliff (sratliff) = wrote:

Working group = participants,

This is a working group last call on the two = documents mentioned above. Please submit any issues or concerns via the = list on or before August 21, = 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

 

------=_NextPart_000_03AF_01CFB337.3B7377F0-- From nobody Fri Aug 8 11:04: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 A11E91B2A22 for ; Fri, 8 Aug 2014 11:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 9B3HQfl4Xv_d for ; Fri, 8 Aug 2014 11:04:23 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5A31B2861 for ; Fri, 8 Aug 2014 11:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15736; q=dns/txt; s=iport; t=1407521062; x=1408730662; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J+ShOZ7RhXjU6KNtT8fq210I8+YDmSPveZnRbyZ1MMg=; b=DXLNPuh6R7+H7j3p/fPiYlqV0XS2uCoMkRBC+ziD6v8e5ZIEXe3HCG3y Qr/WaloRVc2on/Q2dg8VBedvTUPPSXiJxHnJvEVP/wXHYZOzvNBJFyzDe McmzefWBbLxDYHWK5OAMMeNbALuC+Adla060e8dG3CtTIt9/CbAKFfwm+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAGcQ5VOtJA2J/2dsb2JhbABagkdGUlcEzGIBCYdIAYEVFneEAwEBAQQBAQEaUQsQAgEIEQQBASQEByEGCxQJCAIEDgUJiCUDEQ2/ag2FYBQDBo0ZgUsQAgFLBAYBCYMmgRwFgViPPoQlhGWCCYFWjHCGMoIRgUZsAYFG X-IronPort-AV: E=Sophos; i="5.01,826,1400025600"; d="scan'208,217"; a="67699403" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 08 Aug 2014 18:04:21 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s78I4LGp014483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 18:04:21 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.126]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 13:04:21 -0500 From: "Stan Ratliff (sratliff)" To: "" Thread-Topic: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization Thread-Index: AQHPsmetgFGqmSrFFkajPEnl2Q8ID5vF/jOAgAADfQCAAUr/gIAACK0A Date: Fri, 8 Aug 2014 18:04:20 +0000 Message-ID: References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> In-Reply-To: <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: multipart/alternative; boundary="_000_EA96BB97E37C4AE9B9253CE1EAA85B49ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gV8QjnvJE-zKydaZ4ORjuinXmus Cc: Christopher Dearlove , manet IETF , manet-ads , Thomas Clausen , "" Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 08 Aug 2014 18:04:27 -0000 --_000_EA96BB97E37C4AE9B9253CE1EAA85B49ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I'll also add that Abdussalam states in that email (in part): "I vote don't adopt until seeing a presented results of optimisation perfor= mance in terms of net data rate and delay with MANET size scenarios and wit= h determined thresholds (experiments or simulations)." That being the only opinion expressed in the negative, I determined that Ab= dussalam was "in the rough". Thus, we proceeded. I'll also say that in gene= ral, I'm adamantly opposed to *requiring* simulation runs/output for anythi= ng occurring in the MANET WG. Regards, Stan On Aug 8, 2014, at 1:33 PM, Adrian Farrel > wrote: Chris, I believe Abdussalam is referring to an email he sent on 3rd July this year= (although it would have been helpful had he made this clear). In http://www.ietf.org/mail-archive/web/manet/current/msg16408.html he rais= ed some questions during the poll for document adoption. A quick, non-scien= tific, and unthorough scan of the archives does not show an answer. I can't say that I can parse the referenced email with ease, but I think I = see a request to substantiate the assertion implicit in the draft that ther= e is some optimization benefit to the work. You might reasonably respond to= that "allowing immediate reinstatement of the symmetric 2-hop neighbor if = the link quality later improves sufficiently obviously makes the symmetric = 2-hop neighborhood more robust, and so the updates to the two RFCs clearly = represents an optimization." I must say that I find it hard to correlate that old email with the new com= ment that "there was an object the optimization draft to be a standard trac= k with an open questioning/discussion." I do not see any objection in the a= rchive to the publication of the draft on the Standards Track. All I see is= a "vote" to not adopt the I-D. Abdussalam: You go on to say "I don't see reason/interest for my review for= the new update versions." That's OK. There is no requirement for you to r= eview this document nor to send any email commenting on whether or not you = have reviewed it. Adrian From: Christopher Dearlove [mailto:christopher.dearlove@gmail.com] Sent: 07 August 2014 22:49 To: Abdussalam Baryun Cc: Stan Ratliff (sratliff); >; manet-ads; manet IETF; Thomas Clausen Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bi= s and draft-ietf-manet-nhdp-optimization WGLC is when discussion is held (and before it of course). I do not recall = any objection, nor open question. On 7 Aug 2014, at 22:36, Abdussalam Baryun wrote: My comment: there was an object the optimization draft to be a standard tra= ck with an open questioning/discussion, however, no sign for reply from edi= tors, so I don't see reason/interest for my review for the new update versi= ons. AB On Thursday, August 7, 2014, Stan Ratliff (sratliff) wrote: Working group participants, This is a working group last call on the two documents mentioned above. Ple= ase submit any issues or concerns via the list on or before August 21, 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_EA96BB97E37C4AE9B9253CE1EAA85B49ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable All, 

I'll also add that Abdussalam states in that email (in part): 

"I vote don't adopt until seeing a presented results of optimisat= ion performance in terms of net data rate and delay with MANET size scenari= os and with determined thresholds (experiments or simulations)."

That being the only opinion expressed in the negative, I determined th= at Abdussalam was "in the rough". Thus, we proceeded. I'll also s= ay that in general, I'm adamantly opposed to *requiring* simulation runs/ou= tput for anything occurring in the MANET WG. 

Regards,
Stan 


On Aug 8, 2014, at 1:33 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Chris,
 
I believe Abdussalam is referring to an email he sent on = 3rd July this year (although it would have been helpful had he made this cl= ear).
 
In http://www.ietf.org/mai= l-archive/web/manet/current/msg16408.html he raised some questions during the poll for document adoption. A quick, non-= scientific, and unthorough  scan of the archives does not show an answer.
 
I can't say that I can parse the referenced email with ea= se, but I think I see a request to substantiate the assertion implicit in t= he draft that there is some optimization benefit to the work. You might reasonably respond to that "allowing i= mmediate reinstatement of the symmetric 2-hop neighbor if the link quality = later improves sufficiently obviously makes the symmetric 2-hop neighborhoo= d more robust, and so the updates to the two RFCs clearly represents an optimization."
 
I must say that I find it hard to correlate that old emai= l with the new comment that "there was an object the optimization draf= t to be a standard track with an open questioning/discussion." I do not see any objection in the archive to the publication of the draft = on the Standards Track. All I see is a "vote" to not adopt the I-= D.
 
Abdussalam: You go on to say "I don't see reason/int= erest for my review for the new update versions."  That's OK. There is no requirement for you to review this document nor to send an= y email commenting on whether or not you have reviewed it.
 
Adrian
 
 
From:&nbs= p;Christopher Dearlove [mailto:christopher.dearlove@gmail.c= om] 
Sent: 07 August 20= 14 22:49
To: Abdussalam Bar= yun
Cc: Stan Ratliff (= sratliff); <manet-chairs@tools.ietf.org>= ;; manet-ads; manet IETF; Thomas Clausen
Subject: Re: [mane= t] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-m= anet-nhdp-optimization
 
WGLC is when discussion is held (and before it of course). I do not r= ecall any objection, nor open question.
 
 
On 7 Aug 2014, at 22:36, Abdussalam Baryun wrote:


My comment: there was an object the optimization draft to be a&n= bsp;standard track with an open questioning/discussion, however, = no sign for reply from editors, so I don't see reason/interest fo= r my review for the new update versions. 
 
AB

On Thursday, August 7, 2014, Stan Ratliff (sratliff) wrote:
Working group participants,

This is a working group last call on the two documents mentioned above. Ple= ase submit any issues or concerns via the list on or before August 21, 2014= .

Regards,
Stan
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/m= ailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/ma= net
 

--_000_EA96BB97E37C4AE9B9253CE1EAA85B49ciscocom_-- From nobody Fri Aug 8 13:56: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 239961A064C for ; Fri, 8 Aug 2014 13:56:37 -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 bzIEsIQbCNSc for ; Fri, 8 Aug 2014 13:56:34 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0501A0158 for ; Fri, 8 Aug 2014 13:56:33 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so5999893wgh.11 for ; Fri, 08 Aug 2014 13:56:32 -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=/a5wTsXesoTMpMjUuG7X3VPSys0UbGxMV1dQ6Ej1Glw=; b=ybsbXMK7h92vV9nUEa3DHwXMIW7LAlaVPPA8wrcUr6DZM0bI0QZzBBWRqFrZjWVqTF zvX8B0v092ZUOxJWs/Ur3XMPk4hV2wAuwD5YTEELKK2M7z9Pk2yDLddeyfflNON9328x Sc+ZunhZaVrBj+OOAQ3StMrhqgkrdOzXGLY8ErYKcBAORRJusXN/gpxslu8AEGvmVl41 CG89FY15yxs6BM6G/dotkJVe6xtGUusMYslLNCjPXd1If2bGb5EnpiZnEZ/8++A/VARO KdD+Gi04NVJ6n5pkwaktUF/fCPlG0Q7wuK+h9gEF2VnvuoZLAM8NBcms5Ceh6ujXliYE uHww== X-Received: by 10.180.210.163 with SMTP id mv3mr6798699wic.15.1407531392788; Fri, 08 Aug 2014 13:56:32 -0700 (PDT) Received: from [192.168.1.117] (host109-150-153-180.range109-150.btcentralplus.com. [109.150.153.180]) by mx.google.com with ESMTPSA id fb12sm19804310wjc.43.2014.08.08.13.56.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 13:56:31 -0700 (PDT) References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-470C6CA8-60FA-4CEA-BE02-FDC5DEBD51D4 Content-Transfer-Encoding: 7bit Message-Id: <8802CEE7-D6BD-4950-B02F-FB9D195B0066@gmail.com> X-Mailer: iPhone Mail (11D257) From: Christopher Dearlove Date: Fri, 8 Aug 2014 21:56:29 +0100 To: "Stan Ratliff (sratliff)" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/N3knW4T7QTgFRxdh13T6iU-ku4k Cc: manet IETF , manet-ads , Thomas Clausen , "" Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 08 Aug 2014 20:56:37 -0000 --Apple-Mail-470C6CA8-60FA-4CEA-BE02-FDC5DEBD51D4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Adrian Thanks for the effort in unearthing this. I take the same view as Stan. I wi= ll note that I have implemented this, but don't have any publishable perform= ance results. But as I said, I agree with Stan on the lack of necessity of t= his. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 8 Aug 2014, at 19:04, "Stan Ratliff (sratliff)" wr= ote: >=20 > All,=20 >=20 > I'll also add that Abdussalam states in that email (in part):=20 >=20 > "I vote don't adopt until seeing a presented results of optimisation perfo= rmance in terms of net data rate and delay with MANET size scenarios and wit= h determined thresholds (experiments or simulations)." >=20 > That being the only opinion expressed in the negative, I determined that A= bdussalam was "in the rough". Thus, we proceeded. I'll also say that in gene= ral, I'm adamantly opposed to *requiring* simulation runs/output for anythin= g occurring in the MANET WG.=20 >=20 > Regards, > Stan=20 >=20 >=20 >> On Aug 8, 2014, at 1:33 PM, Adrian Farrel wrote: >>=20 >> Chris, >> =20 >> I believe Abdussalam is referring to an email he sent on 3rd July this ye= ar (although it would have been helpful had he made this clear). >> =20 >> In http://www.ietf.org/mail-archive/web/manet/current/msg16408.html he ra= ised some questions during the poll for document adoption. A quick, non-scie= ntific, and unthorough scan of the archives does not show an answer. >> =20 >> I can't say that I can parse the referenced email with ease, but I think I= see a request to substantiate the assertion implicit in the draft that ther= e is some optimization benefit to the work. You might reasonably respond to t= hat "allowing immediate reinstatement of the symmetric 2-hop neighbor if the= link quality later improves sufficiently obviously makes the symmetric 2-ho= p neighborhood more robust, and so the updates to the two RFCs clearly repre= sents an optimization." >> =20 >> I must say that I find it hard to correlate that old email with the new c= omment that "there was an object the optimization draft to be a standard tra= ck with an open questioning/discussion." I do not see any objection in the a= rchive to the publication of the draft on the Standards Track. All I see is a= "vote" to not adopt the I-D. >> =20 >> Abdussalam: You go on to say "I don't see reason/interest for my review f= or the new update versions." That's OK. There is no requirement for you to r= eview this document nor to send any email commenting on whether or not you h= ave reviewed it. >> =20 >> Adrian >> =20 >> =20 >> From: Christopher Dearlove [mailto:christopher.dearlove@gmail.com]=20 >> Sent: 07 August 2014 22:49 >> To: Abdussalam Baryun >> Cc: Stan Ratliff (sratliff); ; manet-ads; ma= net IETF; Thomas Clausen >> Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779= bis and draft-ietf-manet-nhdp-optimization >> =20 >> WGLC is when discussion is held (and before it of course). I do not recal= l any objection, nor open question. >> =20 >> =20 >> On 7 Aug 2014, at 22:36, Abdussalam Baryun wrote: >>=20 >>=20 >> My comment: there was an object the optimization draft to be a standard t= rack with an open questioning/discussion, however, no sign for reply from ed= itors, so I don't see reason/interest for my review for the new update versi= ons.=20 >> =20 >> AB >>=20 >> On Thursday, August 7, 2014, Stan Ratliff (sratliff) wrote: >> Working group participants, >>=20 >> This is a working group last call on the two documents mentioned above. P= lease submit any issues or concerns via the list on or before August 21, 201= 4. >>=20 >> 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 >=20 --Apple-Mail-470C6CA8-60FA-4CEA-BE02-FDC5DEBD51D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Adrian

Thanks for the effort in unearthing this. I take the same view as Stan. I will note that I have implemented this, but don't have any publishable performance results. But as I said, I agree with Stan on the lack of necessity of this.

-- 
Christopher Dearlove

On 8 Aug 2014, at 19:04, "Stan Ratliff (sratliff)" <sratliff@cisco.com> wrote:

All, 

I'll also add that Abdussalam states in that email (in part): 

"I vote don't adopt until seeing a presented results of optimisation performance in terms of net data rate and delay with MANET size scenarios and with determined thresholds (experiments or simulations)."

That being the only opinion expressed in the negative, I determined that Abdussalam was "in the rough". Thus, we proceeded. I'll also say that in general, I'm adamantly opposed to *requiring* simulation runs/output for anything occurring in the MANET WG. 

Regards,
Stan 


On Aug 8, 2014, at 1:33 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Chris,
 
I believe Abdussalam is referring to an email he sent on 3rd July this year (although it would have been helpful had he made this clear).
 
In http://www.ietf.org/mail-archive/web/manet/current/msg16408.html he raised some questions during the poll for document adoption. A quick, non-scientific, and unthorough  scan of the archives does not show an answer.
 
I can't say that I can parse the referenced email with ease, but I think I see a request to substantiate the assertion implicit in the draft that there is some optimization benefit to the work. You might reasonably respond to that "allowing immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently obviously makes the symmetric 2-hop neighborhood more robust, and so the updates to the two RFCs clearly represents an optimization."
 
I must say that I find it hard to correlate that old email with the new comment that "there was an object the optimization draft to be a standard track with an open questioning/discussion." I do not see any objection in the archive to the publication of the draft on the Standards Track. All I see is a "vote" to not adopt the I-D.
 
Abdussalam: You go on to say "I don't see reason/interest for my review for the new update versions."  That's OK. There is no requirement for you to review this document nor to send any email commenting on whether or not you have reviewed it.
 
Adrian
 
 
From: Christopher Dearlove [mailto:christopher.dearlove@gmail.com] 
Sent: 07 August 2014 22:49
To: Abdussalam Baryun
Cc: Stan Ratliff (sratliff); <manet-chairs@tools.ietf.org>; manet-ads; manet IETF; Thomas Clausen
Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization
 
WGLC is when discussion is held (and before it of course). I do not recall any objection, nor open question.
 
 
On 7 Aug 2014, at 22:36, Abdussalam Baryun wrote:


My comment: there was an object the optimization draft to be a standard track with an open questioning/discussion, however, no sign for reply from editors, so I don't see reason/interest for my review for the new update versions. 
 
AB

On Thursday, August 7, 2014, Stan Ratliff (sratliff) wrote:
Working group participants,

This is a working group last call on the two documents mentioned above. Please submit any issues or concerns via the list on or before August 21, 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
 

--Apple-Mail-470C6CA8-60FA-4CEA-BE02-FDC5DEBD51D4-- From nobody Sat Aug 9 04:25: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 215691B27B7 for ; Sat, 9 Aug 2014 04:25:39 -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 2CNI3F2YZwzX for ; Sat, 9 Aug 2014 04:25:37 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27231B27B6 for ; Sat, 9 Aug 2014 04:25:36 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id f10so4963338yha.20 for ; Sat, 09 Aug 2014 04:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Pg4iDSItaho25KSDYAyllfXj9eQHniIaQzOg3bwyfI=; b=LhRqI/wzikvKVgdKxfqZK4wsuknyWNpn4JRxoPhXXvjnZzLIG5CxpnbY8p2PGdZD7z 5JRlqtHyd3MqBL8rjKC48e6fHUb2gTURdiL3Di6gQd0Pxm4b8cj3InLhfd6XP/9BkLcH itSFNoS3WmINyKx91I88oiTzSJMXOJ8Ipjk8o248rtAyX9feiI0PjUD+m1HLiB5omJlB KkVkmylWIEkLbuOBNV7979OK49/k20nyRFJQKbx+yvMJzPzGAG/YtQOyVwiwwqC17/zS vMYpbfKwCaVS939uGcbBGbKTlRlbweyCaFBkHA0r4k9oL5ekgNRe7RujPY/PdMyG3xJn F+4g== MIME-Version: 1.0 X-Received: by 10.236.10.66 with SMTP id 42mr23393247yhu.68.1407583535973; Sat, 09 Aug 2014 04:25:35 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Sat, 9 Aug 2014 04:25:35 -0700 (PDT) In-Reply-To: <8802CEE7-D6BD-4950-B02F-FB9D195B0066@gmail.com> References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> <8802CEE7-D6BD-4950-B02F-FB9D195B0066@gmail.com> Date: Sat, 9 Aug 2014 13:25:35 +0200 Message-ID: From: Abdussalam Baryun To: Christopher Dearlove Content-Type: multipart/alternative; boundary=001a1136b28ca7506e05003094fd Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NtlCA8ZvsYZuhaArYFWDfp_V5J0 Cc: manet IETF , manet-ads , Thomas Clausen , "Stan Ratliff \(sratliff\)" , "" Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 09 Aug 2014 11:25:39 -0000 --001a1136b28ca7506e05003094fd Content-Type: text/plain; charset=UTF-8 On Friday, August 8, 2014, Christopher Dearlove wrote: > Adrian > > Thanks for the effort in unearthing this. I take the same view as Stan. I > will note that I have implemented this, but don't have any publishable > performance results. But as I said, I agree with Stan on the lack of > necessity of this. > The draft is updating two standards, and promoting better performance. I remember when the first present of the draft at IETF 89, I asked you of its difference, and the answer was no much code difference just performance. When we promote optimum that means best performance? So how can this WG get sure of that optimum behavior, do we just follow the author/implementor, is that IETF practice. The results can be necessary to prove it's a suitable standard update. If you want it to be not necessary to give results then no need to update our standards, just a new standard extension. AB > --001a1136b28ca7506e05003094fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Friday, August 8, 2014, Christopher Dearlove wrote:
Adrian

Thanks for the effort in unearthing this. I take the same view as Stan. I w= ill note that I have implemented this, but don't have any publishable p= erformance results. But as I said, I agree with Stan on the lack of necessi= ty of this.

=C2=A0The draft is updating two stan= dards, and promoting better performance. I remember when the first present = of the draft at IETF 89, I=C2=A0asked=C2=A0you of its difference,=C2=A0and = the answer was no much=C2=A0code difference just performance.

=C2=A0When we promote=C2=A0optimum that means best perf= ormance? So how can this WG get sure of that=C2=A0optimum behavior, do we j= ust follow the=C2=A0author/implementor, is that IETF practice.=C2=A0=C2=A0T= he results can be necessary to prove it's a=C2=A0suitable standard=C2= =A0update. If you want it to be not necessary to give results then no=C2=A0= need to update our standards, just a new standard extension.=C2=A0

AB

<= div dir=3D"auto">

--001a1136b28ca7506e05003094fd-- From nobody Sat Aug 9 04:52: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 0D2311B27CB for ; Sat, 9 Aug 2014 04:52:19 -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 3hDPn5p8kh9R for ; Sat, 9 Aug 2014 04:52:17 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92F61B27CA for ; Sat, 9 Aug 2014 04:52:16 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so6529149wes.6 for ; Sat, 09 Aug 2014 04:52:15 -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=SFxZ5DX6Hazl01I5LhUVgNIXm+TZPdxdm4xL40FQH9s=; b=klUW2MI7+7UWH0cLILD7OffrvXlA9PsMFZ0OZZ68OIaIFAS3lBSO35fuc5ekudUpuZ Lr7rA6cXwu7CIBO9h0CIoH7sUlEZ0fYswIldd0LYLOJvEtzcPIhX5HTvUuJo0QY5c9uc niPPa5hpUi5AECJKbaDiNJJxpMkeBBW6qknwm8uzV9HPrgr2MdbJTdVGFYPX3uH4vqQq ZzfyypYjUYgg3DUZR397sekYNBdjKVoyzLOhO2mN+2Ig9Q/usIi2nemz7bwqYQ9IuHMJ uRNz38vjQ21gPwrp5xxx7lsy2GEsOeslmddMoa/xIKSuumd9EJpEA567mRnOiQzyiqUi KXGg== X-Received: by 10.194.191.131 with SMTP id gy3mr2571471wjc.108.1407585135615; Sat, 09 Aug 2014 04:52:15 -0700 (PDT) Received: from [192.168.1.117] (host109-150-153-180.range109-150.btcentralplus.com. [109.150.153.180]) by mx.google.com with ESMTPSA id w6sm24131078wjq.39.2014.08.09.04.52.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Aug 2014 04:52:14 -0700 (PDT) References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> <8802CEE7-D6BD-4950-B02F-FB9D195B0066@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-9B2CA46F-B6A8-4D34-BAEF-3D03D654AF60 Content-Transfer-Encoding: 7bit Message-Id: <61C2475A-185C-48D3-B317-838BD3F6924B@gmail.com> X-Mailer: iPhone Mail (11D257) From: Christopher Dearlove Date: Sat, 9 Aug 2014 12:52:11 +0100 To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CkDDGcm3aanAnJgnmP5E95XZ4Z0 Cc: manet IETF , manet-ads , Thomas Clausen , "Stan Ratliff \(sratliff\)" , "" Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 09 Aug 2014 11:52:19 -0000 --Apple-Mail-9B2CA46F-B6A8-4D34-BAEF-3D03D654AF60 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I didn't understand all of that. But just understand what the extension does. It retains unused certain infor= mation that was thrown away. It makes it available immediately it becomes "g= ood" again without waiting for it to be reconfirmed by signalling. It was ev= en an arbitrary decision by the router that caused it to be thrown away. Fin= ally it's an entirely optional decision to use it. Given all that, the objection is essentially one that says it might be harmf= ul not to have to wait for valid information that you used to have, and that= is optional to use. That makes no sense at all. (The update of the MIB is just a consequence, it's nothing fundamental.) -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 9 Aug 2014, at 12:25, Abdussalam Baryun wr= ote: >=20 >=20 >=20 >> On Friday, August 8, 2014, Christopher Dearlove wrote: >> Adrian >>=20 >> Thanks for the effort in unearthing this. I take the same view as Stan. I= will note that I have implemented this, but don't have any publishable perf= ormance results. But as I said, I agree with Stan on the lack of necessity o= f this. >=20 > The draft is updating two standards, and promoting better performance. I r= emember when the first present of the draft at IETF 89, I asked you of its d= ifference, and the answer was no much code difference just performance. >=20 > When we promote optimum that means best performance? So how can this WG g= et sure of that optimum behavior, do we just follow the author/implementor, i= s that IETF practice. The results can be necessary to prove it's a suitable= standard update. If you want it to be not necessary to give results then no= need to update our standards, just a new standard extension.=20 >=20 > AB >=20 --Apple-Mail-9B2CA46F-B6A8-4D34-BAEF-3D03D654AF60 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I didn't understand all of that.
=

But just understand what the extension does. It retains u= nused certain information that was thrown away. It makes it available immedi= ately it becomes "good" again without waiting for it to be reconfirmed by si= gnalling. It was even an arbitrary decision by the router that caused it to b= e thrown away. Finally it's an entirely optional decision to use it.

Given all that, the objection is essentially one that says= it might be harmful not to have to wait for valid information that you used= to have, and that is optional to use. That makes no sense at all.

(The update of the MIB is just a consequence, it's nothing f= undamental.)

On 9 Aug 2014, at 12:2= 5, Abdussalam Baryun <abdus= salambaryun@gmail.com> wrote:

=


On Friday, August 8, 2014, Christopher Dearlove wrote:
Adrian

=
Thanks for the effort in unearthing this. I take the same view as Stan. I wi= ll note that I have implemented this, but don't have any publishable perform= ance results. But as I said, I agree with Stan on the lack of necessity of t= his.

 The draft is updating two stand= ards, and promoting better performance. I remember when the first present of= the draft at IETF 89, I asked you of its difference, and the= answer was no much code difference just performance.

 When we promote optimum that means best perfo= rmance? So how can this WG get sure of that optimum behavior, do we jus= t follow the author/implementor, is that IETF practice.  The r= esults can be necessary to prove it's a suitable standard update. I= f you want it to be not necessary to give results then no need to updat= e our standards, just a new standard extension. 

AB


= --Apple-Mail-9B2CA46F-B6A8-4D34-BAEF-3D03D654AF60-- From nobody Sat Aug 9 05:05: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 1F9B41A02D1 for ; Sat, 9 Aug 2014 05:05:40 -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 IVsa67M0_-7x for ; Sat, 9 Aug 2014 05:05:38 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141B91A0147 for ; Sat, 9 Aug 2014 05:05:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CBA611BCC353; Sat, 9 Aug 2014 05:05:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.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 mailc2.tigertech.net (Postfix) with ESMTPSA id 02B691BCC314; Sat, 9 Aug 2014 05:05:37 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B4D5C9F6-EF47-496A-ABCB-171E8E79760D Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Sat, 9 Aug 2014 14:05:32 +0200 Content-Transfer-Encoding: 7bit Message-Id: <83D5689A-3070-4DAD-89B8-A196930DDF1B@thomasclausen.org> References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> <8802CEE7-D6BD-4950-B02F-FB9D195B0066@gmail.com> To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bB4EudxpjjPVvKIJrOPNDXn-bg4 Cc: Christopher Dearlove , manet IETF , manet-ads , "Stan Ratliff \(sratliff\)" , "" Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 09 Aug 2014 12:05:40 -0000 --Apple-Mail-B4D5C9F6-EF47-496A-ABCB-171E8E79760D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Abdussalam, If you, in your implementation of NHDP/OLSRv2, do not want to include this o= ptimization, then you can simply decide to not implement it. Your implementa= tion will, then, still be fully interoperable with an implementation that do= es include this optimization -- this is described in, for example, the appli= cability statement of the document. However, in the situations clearly described in the document (for example, i= n paragraph 4 of the introduction), your implementation will then take longe= r time to recover from certain types of link failure. The exact benefit from including this optimization in your deployments of NH= DP/OLSRv2 are for you to evaluate -- nobody can do that in your place: we do= not know the frequency of the type of link failures where this optimization= is effective in your deployment specifics. There are, however, no "downsides" to implementing this optimization, no sit= uations in which it degrades performance, and -- as we indicated -- it's ver= y light to implement. So even if you do not expect to benefit from the optim= ization, then it'd probably be silly to not do so.=20 Now, I am not sure why you talk about "optimum", or "best performance", I do= not believe that anybody has claimed such absolutes. Thomas > On 09 Aug 2014, at 13:25, Abdussalam Baryun w= rote: >=20 >=20 >=20 >> On Friday, August 8, 2014, Christopher Dearlove wrote: >> Adrian >>=20 >> Thanks for the effort in unearthing this. I take the same view as Stan. I= will note that I have implemented this, but don't have any publishable perf= ormance results. But as I said, I agree with Stan on the lack of necessity o= f this. >=20 > The draft is updating two standards, and promoting better performance. I r= emember when the first present of the draft at IETF 89, I asked you of its d= ifference, and the answer was no much code difference just performance. >=20 > When we promote optimum that means best performance? So how can this WG g= et sure of that optimum behavior, do we just follow the author/implementor, i= s that IETF practice. The results can be necessary to prove it's a suitable= standard update. If you want it to be not necessary to give results then no= need to update our standards, just a new standard extension.=20 >=20 > AB >=20 --Apple-Mail-B4D5C9F6-EF47-496A-ABCB-171E8E79760D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Abdussalam,<= /div>

If you, in your implementation of NHDP/OLSRv2, do n= ot want to include this optimization, then you can simply decide to not impl= ement it. Your implementation will, then, still be fully interoperable with a= n implementation that does include this optimization -- this is described in= , for example, the applicability statement of the document.

However, in the situations clearly described in the document (for e= xample, in paragraph 4 of the introduction), your implementation will then t= ake longer time to recover from certain types of link failure.
The exact benefit from including this optimization in your deplo= yments of NHDP/OLSRv2 are for you to evaluate -- nobody can do that in your p= lace: we do not know the frequency of the type of link failures where this o= ptimization is effective in your deployment specifics.

<= div>There are, however, no "downsides" to implementing this optimization, no= situations in which it degrades performance, and -- as we indicated -- it's= very light to implement. So even if you do not expect to benefit from the o= ptimization, then it'd probably be silly to not do so. 

<= /div>
Now, I am not sure why you talk about "optimum", or "best performa= nce", I do not believe that anybody has claimed such absolutes.
Thomas

On 09 Aug 2014, at 13:25, Abdus= salam Baryun <abdussalambar= yun@gmail.com> wrote:


On Friday, August 8, 2014, Christopher Dearlove wrote:
Adrian

Thanks for the effort in unearthing this. I take the same view as Stan. I wi= ll note that I have implemented this, but don't have any publishable perform= ance results. But as I said, I agree with Stan on the lack of necessity of t= his.

 The draft is updating two stand= ards, and promoting better performance. I remember when the first present of= the draft at IETF 89, I asked you of its difference, and the= answer was no much code difference just performance.

 When we promote optimum that means best perfo= rmance? So how can this WG get sure of that optimum behavior, do we jus= t follow the author/implementor, is that IETF practice.  The r= esults can be necessary to prove it's a suitable standard update. I= f you want it to be not necessary to give results then no need to updat= e our standards, just a new standard extension. 

AB


= --Apple-Mail-B4D5C9F6-EF47-496A-ABCB-171E8E79760D-- From nobody Sat Aug 9 15:55: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 CB4311A0368 for ; Sat, 9 Aug 2014 15:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 Ku0xms-OLGTY for ; Sat, 9 Aug 2014 15:55:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397041A0364 for ; Sat, 9 Aug 2014 15:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6261; q=dns/txt; s=iport; t=1407624953; x=1408834553; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XvBGeUkP9eLJm4Kl/JflH+NDOrPEh254gLYpGnHVRXs=; b=RMMeZKuwpkSE01A5LrCmoGv6cyPLratrCyV9xcJuiYB4alq4fdXn7xHO 86TbIFC0ZmISwdohjdPY26pgJU04kWRnV13ovoKcw9JWzvQzX5SWZWSKX 6MEK4fOx3cREGlDdgPwO2oevNsq2geXaZqomHrKm79iaxxBIibnLiEJsk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAKOm5lOtJA2F/2dsb2JhbABYgw2BKQTUXwGBCBZ3hAQBAQQdXBACAQg7BAchERQRAgQOBYguAxG/Gg2FYBeJf4Mggi0Hgy+BHQWRGYkNggmOSYYyghaBRmyBRw X-IronPort-AV: E=Sophos;i="5.01,834,1400025600"; d="scan'208,217";a="346347349" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 09 Aug 2014 22:55:27 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s79MtRTi018884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Aug 2014 22:55:27 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.251]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sat, 9 Aug 2014 17:55:27 -0500 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization Thread-Index: AQHPsmetgFGqmSrFFkajPEnl2Q8ID5vF/jOAgAADfQCAAUr/gIAACK0AgAAwGYCAAPLTgIAAwL4A Date: Sat, 9 Aug 2014 22:55:27 +0000 Message-ID: References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> <8802CEE7-D6BD-4950-B02F-FB9D195B0066@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.116.179.220] Content-Type: multipart/alternative; boundary="_000_DC96782634DD494C852850B3E08B4A5Aciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qNEK4rXVTgehwp0euzWN4mgg1yU Cc: Christopher Dearlove , manet IETF , manet-ads , Thomas Clausen , "" Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 09 Aug 2014 22:55:55 -0000 --_000_DC96782634DD494C852850B3E08B4A5Aciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Abdussalam, On Aug 9, 2014, at 7:25 AM, Abdussalam Baryun > wrote: On Friday, August 8, 2014, Christopher Dearlove wrote: Adrian Thanks for the effort in unearthing this. I take the same view as Stan. I w= ill note that I have implemented this, but don't have any publishable perfo= rmance results. But as I said, I agree with Stan on the lack of necessity o= f this. The draft is updating two standards, and promoting better performance. I r= emember when the first present of the draft at IETF 89, I asked you of its = difference, and the answer was no much code difference just performance. When we promote optimum that means best performance? So how can this WG ge= t sure of that optimum behavior, do we just follow the author/implementor, = is that IETF practice. The results can be necessary to prove it's a suitab= le standard update. If you want it to be not necessary to give results then= no need to update our standards, just a new standard extension. There is a long history in the IETF of promoting standards and extensions u= sing a thorough logical analysis of the protocols. Note that this does *not= * imply an analysis of *a given implementation* of a protocol, via simulati= on or otherwise. The analysis of a given protocol, or extension, is underta= ken by the authors, and by Working Group participants with sufficient inter= est (and time) to undertake the analysis. This is a critical part of the co= nsensus mode of operation within the IETF, and has never required formal pr= oofs, or simulation runs/output, etc. The stated goal of the IETF has alway= s been "rough consensus and working code". So at this point, we *still* have the authors, and others in the WG, in con= sensus that the document represents *exactly* what it says it represents - = an optimization for NHDP. If you have analysis to the contrary, WGLC is *ex= actly* the time to bring that analysis up, and share with the WG situations= where you believe implementing this change will have an adverse effect - e= ither on performance, or on protocol integrity. Otherwise, with my co-chair= hat firmly on, it still looks like we have rough consensus, with you being= "in the rough". Regards, Stan AB --_000_DC96782634DD494C852850B3E08B4A5Aciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Abdussalam,

On Aug 9, 2014, at 7:25 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:



On Friday, August 8, 2014, Christopher Dearlove wrote:
Adrian

Thanks for the effort in unearthing this. I take the same view as Stan= . I will note that I have implemented this, but don't have any publishable = performance results. But as I said, I agree with Stan on the lack of necess= ity of this.

 The draft is updating two standards, and promoting better perfor= mance. I remember when the first present of the draft at IETF 89, I as= ked you of its difference, and the answer was no much code d= ifference just performance.

 When we promote optimum that means best performance? So how= can this WG get sure of that optimum behavior, do we just follow the&= nbsp;author/implementor, is that IETF practice.  The results can = be necessary to prove it's a suitable standard update. If you want it to be not necessary to give results then no need to update ou= r standards, just a new standard extension. 

There is a long history in the IETF of promoting standards and extensi= ons using a thorough logical analysis of the protocols. Note that this does= *not* imply an analysis of *a given implementation* of a protocol, via sim= ulation or otherwise. The analysis of a given protocol, or extension, is undertaken by the authors, and by Wo= rking Group participants with sufficient interest (and time) to undertake t= he analysis. This is a critical part of the consensus mode of operation wit= hin the IETF, and has never required formal proofs, or simulation runs/output, etc. The stated goal of the IETF= has always been "rough consensus and working code".  

So at this point, we *still* have the authors, and others in the WG, i= n consensus that the document represents *exactly* what it says it represen= ts - an optimization for NHDP. If you have analysis to the contrary, WGLC i= s *exactly* the time to bring that analysis up, and share with the WG situations where you believe implementi= ng this change will have an adverse effect - either on performance, or on p= rotocol integrity. Otherwise, with my co-chair hat firmly on, it still look= s like we have rough consensus, with you being "in the rough". 

Regards,
Stan



AB



--_000_DC96782634DD494C852850B3E08B4A5Aciscocom_-- From nobody Sat Aug 9 17:42: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 519081A03AD for ; Sat, 9 Aug 2014 17:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 HEHlyvUSKhZg for ; Sat, 9 Aug 2014 17:42:56 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600AC1A01DC for ; Sat, 9 Aug 2014 17:42:56 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id t59so5277131yho.11 for ; Sat, 09 Aug 2014 17:42:55 -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=9a4Vsrkp7sl30D2VyDdbu8uAAFGLR55xSj+hFpjZaMw=; b=oKtV2DM8Ym6YSLMws8k3XH++hAaYBxNUw5UmtgZoEvSyJrAo7olyHpC2FUNGvkyEn0 1E3gFbbXUbG+xyDDVFTc2W55Q+q2eSjUmnSEjO2r4xyc+F5VP2BaTLAEhmw4P+nLpOKI S9rQ3t2uUGYRzh7r7kzXfYW7tYZ4LOHdHTJM8Pg8++QCqyu3xtFXYKlAcFulwGeMHrEp WyiM6eBxE+PxrMgQ5TNcWEMdh5yyn7sywOMz+ELxiWogINYCSgCZxJQkbA1b7Pv8FFom 3MdBIy8suyVunt15SeTZszTMZhqh59eXYcTTj1ch5P27qQgncVkawmf3C/xKVExw/FD5 TnaQ== MIME-Version: 1.0 X-Received: by 10.236.38.71 with SMTP id z47mr29861800yha.18.1407631375660; Sat, 09 Aug 2014 17:42:55 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Sat, 9 Aug 2014 17:42:55 -0700 (PDT) In-Reply-To: <83D5689A-3070-4DAD-89B8-A196930DDF1B@thomasclausen.org> References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> <8802CEE7-D6BD-4950-B02F-FB9D195B0066@gmail.com> <83D5689A-3070-4DAD-89B8-A196930DDF1B@thomasclausen.org> Date: Sun, 10 Aug 2014 02:42:55 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Clausen Content-Type: multipart/alternative; boundary=047d7bf0d9321efcfd05003bb87b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zhmFVPprZIAePI5LGkkhCyPk9IE Cc: Christopher Dearlove , manet IETF , manet-ads , "Stan Ratliff \(sratliff\)" , "" Subject: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 10 Aug 2014 00:42:58 -0000 --047d7bf0d9321efcfd05003bb87b Content-Type: text/plain; charset=UTF-8 Hi Thomas, I agree that the draft finds ways to reduce overhead but I wanted to make sure of the overall performance. On Saturday, August 9, 2014, Thomas Clausen wrote: > Abdussalam, > > If you, in your implementation of NHDP/OLSRv2, do not want to include this > optimization, then you can simply decide to not implement it. Your > implementation will, then, still be fully interoperable with an > implementation that does include this optimization -- this is described in, > for example, the applicability statement of the document. > IMHO with just seeing draft with no results the Interoperable may be with better performance for optimiz-routers and can give less performance to normal routers within MANET. I think the draft has no recommendations related to that issue. > However, in the situations clearly described in the document (for example, > in paragraph 4 of the introduction), your implementation will then take > longer time to recover from certain types of link failure. > I agree, but what about packet loss, there is a trade off, so quicker recover can have higher possibility of packet loss. > > The exact benefit from including this optimization in your deployments of > NHDP/OLSRv2 are for you to evaluate -- nobody can do that in your place: we > do not know the frequency of the type of link failures where this > optimization is effective in your deployment specifics. > Ok but I was thinking to find a solution for the user of the draft, as the method that determines the optimization related to failure frequency. > There are, however, no "downsides" to implementing this optimization, no > situations in which it degrades performance, and -- as we indicated -- it's > very light to implement. So even if you do not expect to benefit from the > optimization, then it'd probably be silly to not do so. > I cannot be sure of no downside only if I see results, you are sure may be because you have seen some. I think there can be downsides if there are no conditions for this optimisations. > > Now, I am not sure why you talk about "optimum", or "best performance", I > do not believe that anybody has claimed such absolutes. > Ok now I understand that this draft is reducing overhead, quick recover, and not optimising for best performance. AB > > Thomas > > On 09 Aug 2014, at 13:25, Abdussalam Baryun > wrote: > > > > On Friday, August 8, 2014, Christopher Dearlove wrote: > >> Adrian >> >> Thanks for the effort in unearthing this. I take the same view as Stan. I >> will note that I have implemented this, but don't have any publishable >> performance results. But as I said, I agree with Stan on the lack of >> necessity of this. >> > > The draft is updating two standards, and promoting better performance. I > remember when the first present of the draft at IETF 89, I asked you of its > difference, and the answer was no much code difference just performance. > > When we promote optimum that means best performance? So how can this WG > get sure of that optimum behavior, do we just follow > the author/implementor, is that IETF practice. The results can be > necessary to prove it's a suitable standard update. If you want it to be > not necessary to give results then no need to update our standards, just a > new standard extension. > > AB > > >> --047d7bf0d9321efcfd05003bb87b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thomas,

I agree that the draft finds ways to reduce o= verhead but I wanted to make sure of the=C2=A0overall=C2=A0performance.
=
On Saturday, August 9, 2014, Thomas Clausen wrote:
Abdussalam,
<= br>
If you, in your implementation of NHDP/OLSRv2, do not want to= include this optimization, then you can simply decide to not implement it.= Your implementation will, then, still be fully interoperable with an imple= mentation that does include this optimization -- this is described in, for = example, the applicability statement of the document.

IMHO with just seeing draft wi= th no results the=C2=A0Interoperable may be=C2=A0with better performance fo= r optimiz-routers=C2=A0and can give=C2=A0less performance to=C2=A0normal ro= uters within MANET. =C2=A0I think the=C2=A0draft has no recommendations rel= ated to that issue.=C2=A0

<= br>
However, in the situations clearly described in the document = (for example, in paragraph 4 of the introduction), your implementation will= then take longer time to recover from certain types of link failure.

I agree, but what about packet= loss, there is a trade off, so quicker=C2=A0recover can have higher possib= ility of packet loss.=C2=A0
=C2=A0

The exact benefit from including this optimization in your deployments= of NHDP/OLSRv2 are for you to evaluate -- nobody can do that in your place= : we do not know the frequency of the type of link failures where this opti= mization is effective in your deployment specifics.

=C2=A0Ok but I was thinking to= find a solution for the user of the draft, as the=C2=A0method=C2=A0that de= termines the=C2=A0optimization related to failure=C2=A0frequency.=C2=A0


There are, however, no "dow= nsides" to implementing this optimization, no situations in which it d= egrades performance, and -- as we indicated -- it's very light to imple= ment. So even if you do not expect to benefit from the optimization, then i= t'd probably be silly to not do so.=C2=A0

I cannot be sure of no downsid= e only if I see results, you are sure may be=C2=A0because you have seen som= e. I=C2=A0think there can be downsides if there are no conditions for this= =C2=A0optimisations.
=C2=A0

Now, I am not sure why you talk = about "optimum", or "best performance", I do not believ= e that anybody has claimed such absolutes.

Ok now I understand that this draft is=C2=A0reducing ov= erhead, quick recover, and=C2=A0not optimising for best=C2=A0performance. = =C2=A0

AB
=C2=A0

Thomas

= On 09 Aug 2014, at 13:25, Abdussalam Baryun <abdussalambaryun@gmail.c= om> wrote:



On Friday, August 8, 2014,= Christopher Dearlove wrote:
Adrian

Thanks for the effort in unearthing this. I take the same view as Stan. I w= ill note that I have implemented this, but don't have any publishable p= erformance results. But as I said, I agree with Stan on the lack of necessi= ty of this.

=C2=A0The draft is updating two stan= dards, and promoting better performance. I remember when the first present = of the draft at IETF 89, I=C2=A0asked=C2=A0you of its difference,=C2=A0and = the answer was no much=C2=A0code difference just performance.

=C2=A0When we promote=C2=A0optimum that means best perf= ormance? So how can this WG get sure of that=C2=A0optimum behavior, do we j= ust follow the=C2=A0author/implementor, is that IETF practice.=C2=A0=C2=A0T= he results can be necessary to prove it's a=C2=A0suitable standard=C2= =A0update. If you want it to be not necessary to give results then no=C2=A0= need to update our standards, just a new standard extension.=C2=A0

AB

<= div dir=3D"auto">

--047d7bf0d9321efcfd05003bb87b-- From nobody Sun Aug 10 02:51: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 1B7C21A06AD for ; Sun, 10 Aug 2014 02:50:59 -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 kK516eweowsO for ; Sun, 10 Aug 2014 02:50:57 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ACBF1A06AC for ; Sun, 10 Aug 2014 02:50:56 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so2873882wib.4 for ; Sun, 10 Aug 2014 02:50:55 -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 :message-id:references:to; bh=8f6NgBR3GUAZ43TrWc9AgaBr8zo2cKrwBwfcasQQMsc=; b=J3zp9M/U0/XDxVMyThByopZGWNt7x5pWfmuZHr2kTnG6qT3MLHvFJnmJlN2FFAS09V SBUtnijVbYFfl9RC8elhrAaJAO3JTEUSHHyPqu6dG6QMZyLJJWI0SrXyOqaGobgYiTAh pQTYBBH6f8Vt6kZRXaXkQ/ZNeF+M2PYcV4npGR1WcRA593vvbEFs4Jb9bE46C/ODTt5A h9uoDV3kqOYiT+33LoSyMtTVsE56jC0ZmdqfHtgIfjharCWxQdsdOJjXhPYUE0Wt2ZLG hcpZjcgaXa/q6oO4ceThpUWRBXm7FvEq0LmxATc+qnfP9jIHN2isu0JGJqhySo4Y01ZV 5ONg== X-Received: by 10.194.237.5 with SMTP id uy5mr17105525wjc.98.1407664255010; Sun, 10 Aug 2014 02:50:55 -0700 (PDT) Received: from [192.168.254.8] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id gl4sm29205029wib.19.2014.08.10.02.50.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Aug 2014 02:50:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D115D508-A04B-4127-BF6C-91C516F40F4B" From: Christopher Dearlove In-Reply-To: Date: Sun, 10 Aug 2014 10:50:57 +0100 Message-Id: References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> <8802CEE7-D6BD-4950-B02F-FB9D195B0066@gmail.com> <83D5689A-3070-4DAD-89B8-A196930DDF1B@thomasclausen.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/O4ETKLK1PuFq999oxJKwtnxA-hg Cc: manet IETF , manet-ads , Thomas Clausen , "Stan Ratliff \(sratliff\)" , "" Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization 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, 10 Aug 2014 09:50:59 -0000 --Apple-Mail=_D115D508-A04B-4127-BF6C-91C516F40F4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Comments inline On 10 Aug 2014, at 01:42, Abdussalam Baryun wrote: > Hi Thomas, >=20 > I agree that the draft finds ways to reduce overhead but I wanted to = make sure of the overall performance. >=20 > On Saturday, August 9, 2014, Thomas Clausen wrote: > Abdussalam, >=20 > If you, in your implementation of NHDP/OLSRv2, do not want to include = this optimization, then you can simply decide to not implement it. Your = implementation will, then, still be fully interoperable with an = implementation that does include this optimization -- this is described = in, for example, the applicability statement of the document. >=20 > IMHO with just seeing draft with no results the Interoperable may be = with better performance for optimiz-routers and can give less = performance to normal routers within MANET. I think the draft has no = recommendations related to that issue.=20 That's pure speculation, and speculation that doesn't really make sense, = because if it were so then receiving information would be bad in the = same way. Of course that's theoretically possible in some cases, but in = that case you've got a bigger problem than this. >=20 > However, in the situations clearly described in the document (for = example, in paragraph 4 of the introduction), your implementation will = then take longer time to recover from certain types of link failure. >=20 > I agree, but what about packet loss, there is a trade off, so quicker = recover can have higher possibility of packet loss.=20 How? It can certainly have lower possibility of packet loss (it can = reestablish what might be the only link to a two hop neighbour, and = routers beyond that). >=20 > The exact benefit from including this optimization in your deployments = of NHDP/OLSRv2 are for you to evaluate -- nobody can do that in your = place: we do not know the frequency of the type of link failures where = this optimization is effective in your deployment specifics. >=20 > Ok but I was thinking to find a solution for the user of the draft, = as the method that determines the optimization related to failure = frequency.=20 I don't know what that means. >=20 > There are, however, no "downsides" to implementing this optimization, = no situations in which it degrades performance, and -- as we indicated = -- it's very light to implement. So even if you do not expect to benefit = from the optimization, then it'd probably be silly to not do so.=20 >=20 > I cannot be sure of no downside only if I see results, you are sure = may be because you have seen some. I think there can be downsides if = there are no conditions for this optimisations. That's again pure speculation, and same comment applies. >=20 > Now, I am not sure why you talk about "optimum", or "best = performance", I do not believe that anybody has claimed such absolutes. >=20 > Ok now I understand that this draft is reducing overhead, quick = recover, and not optimising for best performance. =20 What do you mean by performance? Recovering the use of links quickly can = improve various things I would consider performance (may include better = routes, and reestablishing necessary routes hence improving delivery). And finally, if you find some exotic circumstance where this makes = things worse, then just don't use it. If you don't trust what you = consider unknown, then just don't use it. Meanwhile the acknowledgements include my colleague Liz Cullen who = observed routing inefficiencies in a simulated scenario and identified = what was happening (glitch in local link quality causing longer term two = hop router loss). The draft is the result I worked out for how to fix = that. So this started from a case that showed where not having this = caused inferior performance. Without any change in signalling, so no = extra overhead or compatibility issues. > AB > =20 >=20 > Thomas >=20 > On 09 Aug 2014, at 13:25, Abdussalam Baryun = wrote: >=20 >>=20 >>=20 >> On Friday, August 8, 2014, Christopher Dearlove wrote: >> Adrian >>=20 >> Thanks for the effort in unearthing this. I take the same view as = Stan. I will note that I have implemented this, but don't have any = publishable performance results. But as I said, I agree with Stan on the = lack of necessity of this. >>=20 >> The draft is updating two standards, and promoting better = performance. I remember when the first present of the draft at IETF 89, = I asked you of its difference, and the answer was no much code = difference just performance. >>=20 >> When we promote optimum that means best performance? So how can this = WG get sure of that optimum behavior, do we just follow the = author/implementor, is that IETF practice. The results can be necessary = to prove it's a suitable standard update. If you want it to be not = necessary to give results then no need to update our standards, just a = new standard extension.=20 >>=20 >> AB >>=20 >>>=20 --Apple-Mail=_D115D508-A04B-4127-BF6C-91C516F40F4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = Thomas,

I agree that the draft finds ways to reduce = overhead but I wanted to make sure of = the overall performance.

On Saturday, August 9, 2014, = Thomas Clausen wrote:
Abdussalam,

<= /div>
If you, in your implementation of NHDP/OLSRv2, do not want to = include this optimization, then you can simply decide to not implement = it. Your implementation will, then, still be fully interoperable with an = implementation that does include this optimization -- this is described = in, for example, the applicability statement of the document.

IMHO with just seeing draft = with no results the Interoperable may be with better = performance for optimiz-routers and can give less performance = to normal routers within MANET.  I think the draft has no = recommendations related to that = issue. 

That's pure = speculation, and speculation that doesn't really make sense, because if = it were so then receiving information would be bad in the same way. Of = course that's theoretically possible in some cases, but in that case = you've got a bigger problem than this.


However, in the = situations clearly described in the document (for example, in paragraph = 4 of the introduction), your implementation will then take longer time = to recover from certain types of link failure.

I agree, but what about = packet loss, there is a trade off, so quicker recover can have = higher possibility of packet = loss. 

How? It can certainly = have lower possibility of packet loss (it can reestablish what might be = the only link to a two hop neighbour, and routers beyond = that).


The exact benefit from including this optimization in your = deployments of NHDP/OLSRv2 are for you to evaluate -- nobody can do that = in your place: we do not know the frequency of the type of link failures = where this optimization is effective in your deployment specifics.

 Ok but I was thinking = to find a solution for the user of the draft, as = the method that determines the optimization related to = failure frequency. 

I = don't know what that means.


There are, however, no = "downsides" to implementing this optimization, no situations in which it = degrades performance, and -- as we indicated -- it's very light to = implement. So even if you do not expect to benefit from the = optimization, then it'd probably be silly to not do so. 

I cannot be sure of no = downside only if I see results, you are sure may be because you = have seen some. I think there can be downsides if there are no = conditions for = this optimisations.

That'= s again pure speculation, and same comment = applies.


Now, I am not sure why you = talk about "optimum", or "best performance", I do not believe that = anybody has claimed such absolutes.

Ok now I understand that this draft is reducing = overhead, quick recover, and not optimising for = best performance. =  

What do you mean by = performance? Recovering the use of links quickly can improve various = things I would consider performance (may include better routes, and = reestablishing necessary routes hence improving = delivery).

And finally, if you find some exotic = circumstance where this makes things worse, then just don't use it. If = you don't trust what you consider unknown, then just don't use = it.

Meanwhile the acknowledgements include my = colleague Liz Cullen who observed routing inefficiencies in a simulated = scenario and identified what was happening (glitch in local link quality = causing longer term two hop router loss). The draft is the result I = worked out for how to fix that. So this started from a case that showed = where not having this caused inferior performance. Without any change in = signalling, so no extra overhead or compatibility = issues.

AB
 

Thomas

On = 09 Aug 2014, at 13:25, Abdussalam Baryun = <abdussalambaryun@gmail.com> wrote:



On Friday, August 8, = 2014, Christopher Dearlove wrote:
Adrian

Thanks for the effort in unearthing this. I take the same view as Stan. = I will note that I have implemented this, but don't have any publishable = performance results. But as I said, I agree with Stan on the lack of = necessity of this.

 The draft is updating two = standards, and promoting better performance. I remember when the first = present of the draft at IETF 89, I asked you of its = difference, and the answer was no much code difference just = performance.

 When we promote optimum that means best = performance? So how can this WG get sure of that optimum behavior, = do we just follow the author/implementor, is that IETF = practice.  The results can be necessary to prove it's = a suitable standard update. If you want it to be not necessary = to give results then no need to update our standards, just a new = standard extension. 

AB



= --Apple-Mail=_D115D508-A04B-4127-BF6C-91C516F40F4B-- From nobody Sun Aug 10 03:23: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 B0F9A1A06C3 for ; Sun, 10 Aug 2014 03:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668] 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 5JQBKH6RHVrf for ; Sun, 10 Aug 2014 03:23:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3B31A06C2 for ; Sun, 10 Aug 2014 03:23:49 -0700 (PDT) Received: from localhost ([::1]:42795 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XGQHt-00012h-RT; Sun, 10 Aug 2014 03:23:41 -0700 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: draft-ietf-manet-nhdp-optimization@tools.ietf.org, abdussalambaryun@gmail.com X-Trac-Project: manet Date: Sun, 10 Aug 2014 10:23:41 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/manet/trac/ticket/51 Message-ID: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> X-Trac-Ticket-ID: 51 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-nhdp-optimization@tools.ietf.org, abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: chris.dearlove@baesystems.com, t.clausen@computer.org Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5NxghrFV28iGwWrYtr0i-bOGPNY Cc: manet@ietf.org Subject: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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: Sun, 10 Aug 2014 10:23:50 -0000 #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change The neighbor nodes reaction to changes in the link quality is not considered by the draft. For example: A ------- B ------- C (node B is N1 and C is N2) When link quality change, A - - - - B - - - - C (node A lost links but still aware) N1 and N2 may optimise as well for their links quality change. B has A as N1 and C as N1, so B lost links. When A has change in link quality then: A ------- B -------- C (at node A recovered links) A - - - - B - - - - C (at node B lost links which is N1 for A) B is not connected to C but A thinks they are. There is high probability that when the quality changes in links between A-B there will be changes in B-C. Furthermore, C may not be optimizing router, so it will loose A as neighbour but A still has C as 2-hop symmetric neighbor. This can increase packet loss in the network. Best, AB -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-manet-nhdp- abdussalambaryun@gmail.com | optimization@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nhdp-optimization | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: manet From nobody Sun Aug 10 04:59: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 E3A6D1A06F1 for ; Sun, 10 Aug 2014 04:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 Lmo5hhdiipXn for ; Sun, 10 Aug 2014 04:59:27 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A952D1A06EB for ; Sun, 10 Aug 2014 04:59:26 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so2992499wiv.5 for ; Sun, 10 Aug 2014 04:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=+OSlR3ZVVpWQntughU6noK3OCosDHB/F6CR0VGZrMbA=; b=LRYa8h8ryTHnfqY/RpS2eOzVWz5HfrGAAmVrC7xd0Y28tIC3MsQL2LmJItX/HQaYm/ FQg9LltdwNefZ9dvsbokyBhKAsQFuPEi1xgjBW97UXv90HKq2/PkgbD0a8N5xfEqOo7E HKKyo+zupodjErv79PYfz+BBqf7Nd1ALlviluvzuMf3QhdnuE+IGjHY1C+EzU5cd7y+j 2LCSsNYGOOXQSbB+xpAhQRVF8dDbcdTM9hR/1AOqgOXMirVsSES4SEdEnuy9dWmw/kFA NzV1xd3ukzSNz3cjeaBLqEa//kzw45mqjdpjOGafJ4xv71Tqgo0el/ut/zD/Q+5QGNUw GaAA== X-Received: by 10.180.210.231 with SMTP id mx7mr11374988wic.42.1407671965080; Sun, 10 Aug 2014 04:59:25 -0700 (PDT) Received: from [192.168.254.8] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id a4sm30345416wie.21.2014.08.10.04.59.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Aug 2014 04:59:24 -0700 (PDT) From: Christopher Dearlove X-Google-Original-From: Christopher Dearlove Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) In-Reply-To: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> Date: Sun, 10 Aug 2014 12:59:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> To: X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9GS_APX8pjPMJJgoKAEvdyEMO14 Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 10 Aug 2014 11:59:29 -0000 On 10 Aug 2014, at 11:23, manet issue tracker wrote: > #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection = with link > quality change I'm not sure what #51 means, but the analysis is flawed. > The neighbor nodes reaction to changes in the link quality is not > considered by the draft. That's because it has no reaction to changes in the link quality as = viewed by A. A's link quality is not communicated to B. If the change = lasts until the next HELLO message, A will report the link lost, and = then B will react. Exactly as it would have done without this = optimisation. If B does its own link quality process, it won't = necessarily (very often won't) have the same transients in it, and then = B's reaction will be governed by it running the protocol, optimised or = not. > For example: >=20 > A ------- B ------- C (node B is N1 and C is N2) >=20 > When link quality change, >=20 > A - - - - B - - - - C (node A lost links but still aware) >=20 > N1 and N2 may optimise as well for their links quality change. Your notation is messed up here. Your nodes are A, B, and C. I think you = are trying to use N1 and N2 for relationship, but then N1 and N2 can't = do anything. What's done is done by A and B. This does not help. > B has A as N1 and C as N1, so B lost links. I don't know what you are trying to say here exactly, but B has not lost = anything due to A's link quality decisions, until A sends a HELLO = message. If A does send a HELLO message then the optimisation is = irrelevant. The only way B is affected is if it also has a link quality change. = Which is possible, but by no means certain. And not a problem if it = does. > When A has change in link quality then: >=20 > A ------- B -------- C (at node A recovered links) >=20 > A - - - - B - - - - C (at node B lost links which is N1 for A) > B is not connected to C Why? There absolutely no reason why the B-C link has changed, when we = are talking about a change in quality in the B to A link. If it does = this is now compounding even more effects. > but A thinks they are. There is high probability > that when the quality changes in links between A-B there will be = changes > in B-C. Why? Completely depends on why the link is poor. To say "there is high = probability there will be changes" is simple assertion without evidence. > Furthermore, C may not be optimizing router, so it will loose A as lose > neighbour but A still has C as 2-hop symmetric neighbor. This can > increase packet loss in the network. The optimisation is really irrelevant here. If the B-C link changes then = A won't know about it until B signals that. That's completely irrelevant = to this optimisation. If the link to B has more than a transient failure, B will be lost as a = neighbour. B's links are then irrelevant, so whop cares if a link B-C is = kept or not? If the link to B has a transient failure, you are suggesting that B to C = will fail (not justified) and that therefore you should discard C, = because the B-C link is bad. But now you have chosen to discard the = assumption of correlation that you used when it suited you, because now = A to B transient fails (the case of interest, as longer term failure = will have its usual non-optimised effect) but B to C is assumed = permanently (not transiently) failed. That's just unrealistic special case pleading (you've assumed in = particular that B-C fails at the same time, that this is detected by B, = but it is longer term, not transient - that only transient matters is = because if nontransient then the main protocol will define what happens = when a HELLO message is next sent). Of course we can devise cases where = any change happens not to work well here. But the best you've found = makes unjustified assumptions, to make things no worse than they would = have been had, for example, A used a more smoothed link quality. = Meanwhile actually realistic cases where things are improved are ignored = by you. And, should you run in a network with unusual properties, you still = always have the option don't use the optimisation. You're whole argument boils down to "I'm trying hard, making unrealistic = assumptions, to find a special case where there's a problem". And on = that basis you suggest that the optional optimisation that will = demonstrably help in realistic cases shouldn't be defined. That's not a good argument.= From nobody Sun Aug 10 05: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 6A4F31A06FA for ; Sun, 10 Aug 2014 05:31:40 -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 qugiRAkQ3jQ5 for ; Sun, 10 Aug 2014 05:31:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B651A06F8 for ; Sun, 10 Aug 2014 05:31:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 352EC1C0358; Sun, 10 Aug 2014 05:31:38 -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 97FFC1C01C7; Sun, 10 Aug 2014 05:31:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (11D257) In-Reply-To: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> Date: Sun, 10 Aug 2014 14:31:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <893B6363-D5ED-47E1-922C-AAAD9F7DD9A2@thomasclausen.org> References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> To: "manet@ietf.org" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NOlUGzLKO4rFYmclcvOc19WJKmA Cc: "draft-ietf-manet-nhdp-optimization@tools.ietf.org" Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 10 Aug 2014 12:31:40 -0000 > On 10 Aug 2014, at 12:23, "manet issue tracker" wrote: >=20 > #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with l= ink > quality change >=20 > The neighbor nodes reaction to changes in the link quality is not > considered by the draft. Did you actually read RFC6130/7182? The Link Quality is only ever recorded and used inside a router, and is neve= r communicated to neighbors.=20 This draft does not change that. > For example: >=20 > A ------- B ------- C (node B is N1 and C is N2) >=20 > When link quality change, >=20 > A - - - - B - - - - C (node A lost links but still aware) >=20 > N1 and N2 may optimise as well for their links quality change. I do not understand what the above sentence means. > B has A as N1 and C as N1, so B lost links. If Router A's link quality decisions means that it considers the link to B a= s "lost", then that doesn't cause B to lose anything. That can only due to a= local decision by B as to link quality - or, when B receives a HELLO messag= e from A....which renders this discussion moot. > When A has change in link quality then: >=20 > A ------- B -------- C (at node A recovered links) >=20 > A - - - - B - - - - C (at node B lost links which is N1 for A) >=20 > B is not connected to C but A thinks they are. Now I am convinced that you need to go back and re-read RFC6130. Why would a= local decision in A based on its perceived link-quality of the link A-B hav= e the faintest impact on the link B-C? > There is high probability > that when the quality changes in links between A-B there will be changes > in B-C. No, that's decidedly not a true statement. There is absolutely no reason to a= ssume that a change in the link-quality of the link between A and B will als= o change the link quality of the link between B and C. For example, if the l= ink quality changes due to "noise" being generated "to the left of A", it ma= y not reach the link B-C. Or A-B and B-C may be links over different channel= s, medias, ... > Furthermore, C may not be optimizing router, I do not know what that is. > so it will loose A as > neighbour but A still has C as 2-hop symmetric neighbor. This can > increase packet loss in the network. Incorrect. A's operation does not depend on if "B" or "C" implement (or not) the optimi= zation in this draft. Now, if A has C as a 2-hop symmetric neighbor when B has lost the link, then= (i) that's a transient effect, and (ii) A will know about it (in either cas= e) when B sends a HELLO message, and (iii) if the link A-B is more than just= transiently broken, then A won't use it (and, won't use the link B-C either= ). May I also point out that you are actually first making an (incorrect) asser= tion in your argument (that if the link quality for A-B as seen by A, degrad= es, then so does the link quality for B-C, as seen by B, both transiently), t= hen disregarding the very same assertion in your argument by assuming that t= he incurred failure affects B-C permanently.=20 Self-contradicting arguments like that make for a very, very unconvincing ca= se. Thomas >=20 > Best, >=20 > AB >=20 > --=20 > -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-manet-nhdp- > abdussalambaryun@gmail.com | optimization@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: nhdp-optimization | Version: > Severity: In WG Last Call | Keywords: > -------------------------------------+------------------------------------= - >=20 > Ticket URL: > manet >=20 From nobody Sun Aug 10 07:52: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 4CAFA1A0740 for ; Sun, 10 Aug 2014 07:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, 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 WcI6lvB7AAfs for ; Sun, 10 Aug 2014 07:52:26 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064211A073D for ; Sun, 10 Aug 2014 07:52:25 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z60so7677140qgd.41 for ; Sun, 10 Aug 2014 07:52: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=RlYrMwz0gveMIpyae7mO9ftxDWSNJJ+/ZF2a4TNwMmc=; b=GdM8nS3K+OO0ZyFsR0qtUP6SPyXaIHoSipwp59wb+FSvRU8yRddfpKDa5fvgIx3PnD MIJ66kj0gsJNKYdgh9UXr1C4rCAnwpxIUQTqVlnWvEelOQd0E/3IEwcNhLKdryomvOr7 1q487BMllsZcD3j2n+x3DZvtL9jKjhUgo8ZVn3Y3Aq8AnD1M7ta9I0W+flQezk+xvTM+ ExLgHN1TIxpPJci7Y8Pvi/Ika7m04m1rx8Ve5jHcs/N/7z/sOZcodBnvcjmYEPXQx2TL v/+31BeBqUlA/1yJG3iuamKNPNVzItgBMUYbjc5oMoDFDXMwxDDCnFl+79syyVMt5p4b HGTQ== X-Received: by 10.140.104.162 with SMTP id a31mr4388982qgf.104.1407682345220; Sun, 10 Aug 2014 07:52:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Sun, 10 Aug 2014 07:52:05 -0700 (PDT) In-Reply-To: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> From: Henning Rogge Date: Sun, 10 Aug 2014 16:52:05 +0200 Message-ID: To: MANET IETF Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UhnnC2ufcJ1w79778zp39uFkZ5Y Cc: draft-ietf-manet-nhdp-optimization@tools.ietf.org Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 10 Aug 2014 14:52:27 -0000 Abdussalam, are you maybe mixing up "link quality" and "link metric" ? One is a local value (often with hysteresis) to turn links on and of. The other one is communicated between nodes and used by the dijkstra algorithm. Henning Rogge On Sun, Aug 10, 2014 at 12:23 PM, manet issue tracker wrote: > #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link > quality change > > The neighbor nodes reaction to changes in the link quality is not > considered by the draft. > For example: > > A ------- B ------- C (node B is N1 and C is N2) > > When link quality change, > > A - - - - B - - - - C (node A lost links but still aware) > > N1 and N2 may optimise as well for their links quality change. > B has A as N1 and C as N1, so B lost links. > > When A has change in link quality then: > > A ------- B -------- C (at node A recovered links) > > A - - - - B - - - - C (at node B lost links which is N1 for A) > > B is not connected to C but A thinks they are. There is high probability > that when the quality changes in links between A-B there will be changes > in B-C. Furthermore, C may not be optimizing router, so it will loose A as > neighbour but A still has C as 2-hop symmetric neighbor. This can > increase packet loss in the network. > > Best, > > AB > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-manet-nhdp- > abdussalambaryun@gmail.com | optimization@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: nhdp-optimization | Version: > Severity: In WG Last Call | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Sun Aug 10 08:21: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 5DDB21A0759 for ; Sun, 10 Aug 2014 08:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ZIkaralsTohe for ; Sun, 10 Aug 2014 08:21:30 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF7C1A0757 for ; Sun, 10 Aug 2014 08:21:30 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id t59so5513034yho.25 for ; Sun, 10 Aug 2014 08:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hTsg2S8MTJfN2cHYqSXblXyjbDkZNSSHsAs0beKmVpQ=; b=eRCeXSxOTLoGPhPd6m1rr29jZPMo3wCaBIjX6FxELknGa1WXX8wPkINDzNH9zyXx99 HwQw10r1h2sVF/37azvWYqk3qTRBa5tfs9mIYLvMqGjmf7UeS9suOd/Vg1An+gUgcdAi bMMQdffZKxyxnRyZtrlul6fOdpY0EWFshfdcqxVXmwf8gALnkyQFcDMa0tZOcxuw7C6s y8U4ui8AdNsEFs3l4P5sDj3sYVWfL66T07Jau7F9hdQyfqvrWyyM0oM5Xtjo/9NtyH0d D2cUagfy94yFFPmSvZ+3DDsbpH0NusKkIcCDG1QKlRMRvTbUXoK0eE3vwSRycuAdIrll ZmGw== MIME-Version: 1.0 X-Received: by 10.236.112.3 with SMTP id x3mr33989528yhg.17.1407684089857; Sun, 10 Aug 2014 08:21:29 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Sun, 10 Aug 2014 08:21:29 -0700 (PDT) In-Reply-To: <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> Date: Sun, 10 Aug 2014 17:21:29 +0200 Message-ID: From: Abdussalam Baryun To: Christopher Dearlove Content-Type: multipart/alternative; boundary=20cf301af24721cb0a050047fef8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/eJ-RJU0DlevVi2JJ3dDsGkNLxM0 Cc: "manet@ietf.org" Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 10 Aug 2014 15:21:33 -0000 --20cf301af24721cb0a050047fef8 Content-Type: text/plain; charset=UTF-8 I considered to follow the method of your initial analysis within the presentation of IETF 89 meeting. Please see slides 21-24 related to the draft before adoption. On Sunday, August 10, 2014, Christopher Dearlove wrote: > > On 10 Aug 2014, at 11:23, manet issue tracker wrote: > > > #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with > link > > quality change > > I'm not sure what #51 means, but the analysis is flawed. > > Means analysing the router decisions/performances if it considers connected with neighbors or not while it has link quality change. > > The neighbor nodes reaction to changes in the link quality is not > > considered by the draft. > > That's because it has no reaction to changes in the link quality as viewed > by A. The reaction is link lost within router A and other reaction specified within A. > A's link quality is not communicated to B. Yes I agree. > If the change lasts until the next HELLO message, A will report the link > lost, and then B will react. Agree > Exactly as it would have done without this optimisation. If B does its > own link quality process, it won't necessarily (very often won't) have the > same transients in it, and then B's reaction will be governed by it running > the protocol, optimised or not. > > > For example: > > > > A ------- B ------- C (node B is N1 and C is N2) > > > > When link quality change, > > > > A - - - - B - - - - C (node A lost links but still aware) > > > > N1 and N2 may optimise as well for their links quality change. > > Your notation is messed up here. Your nodes are A, B, and C. I think you > are trying to use N1 and N2 for relationship, but then N1 and N2 can't do > anything. What's done is done by A and B. This does not help. Neighbor relationship for hop 1 and hop 2. > > B has A as N1 and C as N1, so B lost links. > > I don't know what you are trying to say here exactly, but B has not lost > anything due to A's link quality decisions, until A sends a HELLO message. > If A does send a HELLO message then the optimisation is irrelevant. B lost not because of A, I mentioned that N1 and N2 may optimize as well so if there is a change in B links then it will make them as lost. > > The only way B is affected is if it also has a link quality change. Which > is possible, but by no means certain. And not a problem if it does. That was my point. So why it is no problem. > > > When A has change in link quality then: > > > > A ------- B -------- C (at node A recovered links) > > > > A - - - - B - - - - C (at node B lost links which is N1 for A) > > > B is not connected to C > > Why? There absolutely no reason why the B-C link has changed, when we are > talking about a change in quality in the B to A link. If it does this is > now compounding even more effects. Because C is optimizing also in this example, so the three nodes optimize after change in the two links, but link AB changes before BC. > > > but A thinks they are. There is high probability > > that when the quality changes in links between A-B there will be changes > > in B-C. > > Why? Completely depends on why the link is poor. To say "there is high > probability there will be changes" is simple assertion without evidence. Happens Within the mobile channel characteristics as MANET, the movement and the node environment are usually the largest reason of link quality change. > > Furthermore, C may not be optimizing router, so it will loose A as > > lose > > > neighbour but A still has C as 2-hop symmetric neighbor. This can > > increase packet loss in the network. > > The optimisation is really irrelevant here. If the B-C link changes then A > won't know about it until B signals that. Yes A will not know but while it recover as connected but B is having that link lost. > That's completely irrelevant to this optimisation. > > If the link to B has more than a transient failure, B will be lost as a > neighbour. B's links are then irrelevant, so whop cares if a link B-C is > kept or not? The example is showing after recovering for A. As you showed in your presentation that there is difference in reaction between A if it optimise or not. If A optimises then at recovery it will not loose 2 hop link but in normal it does loose. > > If the link to B has a transient failure, you are suggesting that B to C > will fail (not justified) and that therefore you should discard C, because > the B-C link is bad. But now you have chosen to discard the assumption of > correlation that you used when it suited you, because now A to B transient > fails (the case of interest, as longer term failure will have its usual > non-optimised effect) but B to C is assumed permanently (not transiently) > failed. > > That's just unrealistic special case pleading (you've assumed in > particular that B-C fails at the same time, that this is detected by B, but > it is longer term, not transient - that only transient matters is because > if nontransient then the main protocol will define what happens when a > HELLO message is next sent). It can happen as routers have different quality threshold and neighbor links may have similar failur reasons. Of course we can devise cases where any change happens not to work well > here. But the best you've found makes unjustified assumptions, to make > things no worse than they would have been had, for example, A used a more > smoothed link quality. Meanwhile actually realistic cases where things are > improved are ignored by you. > > And, should you run in a network with unusual properties, you still always > have the option don't use the optimisation. > > You're whole argument boils down to "I'm trying hard, making unrealistic > assumptions, to find a special case where there's a problem". And on that > basis you suggest that the optional optimisation that will demonstrably > help in realistic cases shouldn't be defined. I disagree, I think it is very simple with three nodes as neighbors. Usually MANET working group look into large networks with very high probability of link changes. Overall, we can assume worst case and good case for this three node example, so the probability is about 0.25 when all nodes optimise. We can go into analysing all cases and then find the absolute probability which includes if nodes are optimising or not or with larger sizes. > > That's not a good argument. It is good as long there are no test results with different MANET sizes proving optimization as with good performance. We need to look into the worst cases while analysing. Do you think my example was the worst case? AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf301af24721cb0a050047fef8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I considered to follow the method of=C2=A0your initial=C2=A0analysis within= the presentation of IETF 89 meeting. Please see slides 21-24 related to th= e draft before adoption.=C2=A0

On Sunday, August 10, 2014, Christoph= er Dearlove wrote:

On 10 Aug 2014, at 11:23, manet issue tracker wrote:

> #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection wi= th link
> quality change

I'm not sure what #51 means, but the analysis is flawed.


Means analysing=C2=A0the router decisi= ons/performances=C2=A0if it considers=C2=A0connected with neighbors=C2=A0or= not while it has link=C2=A0quality change.=C2=A0

= =C2=A0
> The neighbor nodes reaction to changes in the link quality is not
> considered by the draft.

That's because it has no reaction to changes in the link quality as vie= wed by A.=C2=A0

The reaction is link lost within router A and other reaction spe= cified within A.=C2=A0
=C2=A0
A's link quality is not communicated to B.=C2=A0

Yes I agree= .=C2=A0
=C2=A0
If the change lasts until the next HELLO message, A will report the link lo= st, and then B will react.

Agree=C2=A0
=C2=A0
=C2=A0Exactly as it would have done without this optimisation. If= B does its own link quality process, it won't necessarily (very often = won't) have the same transients in it, and then B's reaction will b= e governed by it running the protocol, optimised or not.

> For example:
>
> A ------- B ------- C =C2=A0 =C2=A0 (node B is N1 and C is N2)
>
> When link quality change,
>
> A - - - - B - - - - C =C2=A0 =C2=A0 =C2=A0(node A lost links but still= aware)
>
> N1 and N2 may optimise as well for their links quality change.

Your notation is messed up here. Your nodes are A, B, and C. I think you ar= e trying to use N1 and N2 for relationship, but then N1 and N2 can't do= anything. What's done is done by A and B. This does not help.

Neighbor relationship for hop 1 and hop 2.=C2=A0
<= div>

> B has A as N1 and C as N1, so B lost links.

I don't know what you are trying to say here exactly, but B has not los= t anything due to A's link quality decisions, until A sends a HELLO mes= sage. If A does send a HELLO message then the optimisation is irrelevant.

B lost not because of A, I mentioned that N1 and N2 may= optimize as well so if there is a change in B links then it will make them= as lost.=C2=A0
=C2=A0

The only way B is affected is if it also has a link quality change. Which i= s possible, but by no means certain. And not a problem if it does.

That was my point. So why it is no problem.=C2=A0
=C2=A0

> When A has change in link quality then:
>
> A ------- B -------- C =C2=A0 =C2=A0(at node A recovered links)
>
> A - - - - =C2=A0B =C2=A0- - - - =C2=A0C =C2=A0 =C2=A0 (at node B lost = links which is N1 for A)

> B is not connected to C

Why? There absolutely no reason why the B-C link has changed, when we are t= alking about a change in quality in the B to A link. If it does this is now= compounding even more effects.

Because C i= s optimizing also in this example, so the three nodes optimize after change= in the two links, but link AB changes before BC.=C2=A0
=C2=A0

> but A thinks they are. There is high probability
> that when the quality changes in links between A-B there will be chang= es
> in B-C.

Why? Completely depends on why the link is poor. To say "there is high= probability there will be changes" is simple assertion without eviden= ce.

Happens=C2=A0Within the=C2=A0mobile cha= nnel=C2=A0characteristics=C2=A0=C2=A0as MANET, the movement and the node en= vironment=C2=A0=C2=A0are usually the largest reason of link quality change.= =C2=A0


> Furthermore, C may not be optimizing router, so it will loose A as

lose

> neighbour but A still has C as 2-hop symmetric =C2=A0neighbor. This ca= n
> increase packet loss in the network.

The optimisation is really irrelevant here. If the B-C link changes then A = won't know about it until B signals that.=C2=A0

Yes A will not know but while it=C2=A0reco= ver as connected but=C2=A0B is having that link lost.=C2=A0
=C2= =A0
That's completely irrelevant to this optimisation.

If the link to B has more than a transient failure, B will be lost as a nei= ghbour. B's links are then irrelevant, so whop cares if a link B-C is k= ept or not?

The example is showing after re= covering for A. As you showed in your presentation that there is difference= in reaction between A if it optimise or not. If A optimises then at recove= ry it will not loose 2 hop link but in normal it does loose.=C2=A0
=C2=A0

If the link to B has a transient failure, you are suggesting that B to C wi= ll fail (not justified) and that therefore you should discard C, because th= e B-C link is bad. But now you have chosen to discard the assumption of cor= relation that you used when it suited you, because now A to B transient fai= ls (the case of interest, as longer term failure will have its usual non-op= timised effect) but B to C is assumed permanently (not transiently) failed.=

That's just unrealistic special case pleading (you've assumed in pa= rticular that B-C fails at the same time, that this is detected by B, but i= t is longer term, not transient =C2=A0- that only transient matters is beca= use if nontransient =C2=A0then the main protocol will define what happens w= hen a HELLO message is next sent).=C2=A0

It can happ= en as routers have different quality threshold and neighbor=C2=A0links may= =C2=A0have similar failur reasons.=C2=A0

Of course we can devise cases= where any change happens not to work well here. But the best you've fo= und makes unjustified assumptions, to make things no worse than they would = have been had, for example, A used a more smoothed link quality. Meanwhile = actually realistic cases where things are improved are ignored by you.

And, should you run in a network with unusual properties, you still always = have the option don't use the optimisation.

You're whole argument boils down to "I'm trying hard, making u= nrealistic assumptions, to find a special case where there's a problem&= quot;. And on that basis you suggest that the optional optimisation that wi= ll demonstrably help in realistic cases shouldn't be defined.

I disagree,=C2=A0I think it is very simple with three n= odes as neighbors. Usually MANET working group look into large networks wit= h very high probability of link changes. Overall, we can assume worst case = and good case for this three node example, so the probability is about 0.25= when all nodes optimise. We=C2=A0can go into analysing all cases and then = find the absolute=C2=A0probability which includes if nodes are optimising o= r not or with larger sizes.=C2=A0
=C2=A0

That's not a good argument.

It is good = as long there are no test results with different MANET sizes proving optimi= zation as with=C2=A0good performance. We need to look into the worst cases = while analysing. Do you think my example was the worst case?

AB
=C2=A0
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--20cf301af24721cb0a050047fef8-- From nobody Sun Aug 10 08:34: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 2BD801A0775 for ; Sun, 10 Aug 2014 08:34:56 -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 QKkv0cGYDs31 for ; Sun, 10 Aug 2014 08:34:54 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8191E1A0774 for ; Sun, 10 Aug 2014 08:34:53 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so3122735wib.4 for ; Sun, 10 Aug 2014 08:34:51 -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 :message-id:references:to; bh=YdHktjiBRPk5kO9ry7gkRv3co43IS3FzRp1Jn+ehEsY=; b=RmIS0hWO3f0F+pjZc97NziWaS7hzLckSwFLQNXG5iaM0UK9dS/5ZS3aP0PY/HkhHXP zYhj/pByoJsw/hRXFZ9Zm/XulYwFcN9MbyDroFkXaQ210KxMpNWhwRWb01pnZt1b0w1J lc7XahLibXEcrNFgxCUTj9+wDITvQ9b9D03PGsrxmZ1CNvzd9pSDivWPBQVuTjSCmJiM mS9hBl6tLA/1CGEDYeoYhjhfJVirWYvmDkHQGbt1LWzC/dNiiVuhbiQeEZAJh7Mpnc+u 7I3GVcTopwLQM4mOXVIb+XufO86LegHxA05JxNsOSW+v+Tpa22KhPWuNety+u0JKN/Xl 4oLg== X-Received: by 10.180.12.76 with SMTP id w12mr18134400wib.4.1407684891128; Sun, 10 Aug 2014 08:34:51 -0700 (PDT) Received: from [192.168.254.8] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id u5sm32275251wia.17.2014.08.10.08.34.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Aug 2014 08:34:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C7D0F015-55DC-49DD-A395-736CD20316A4" From: Christopher Dearlove In-Reply-To: Date: Sun, 10 Aug 2014 16:34:47 +0100 Message-Id: References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/HwazGwgKxR0XAyDIZnYew-WXtIw Cc: "manet@ietf.org" Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 10 Aug 2014 15:34:56 -0000 --Apple-Mail=_C7D0F015-55DC-49DD-A395-736CD20316A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm just not going to do this (going through posting point by point) = again. I'm just going to reply to your last point. No, I don't think = this is a useful, consistent, well thought through or relevant case or = objection. I've explained why. (I'll just comment that an illustration of that is the simple invention = of a 0.25 figure, which has no foundation whatsoever.) On 10 Aug 2014, at 16:21, Abdussalam Baryun wrote: > I considered to follow the method of your initial analysis within the = presentation of IETF 89 meeting. Please see slides 21-24 related to the = draft before adoption.=20 >=20 > On Sunday, August 10, 2014, Christopher Dearlove wrote: >=20 > On 10 Aug 2014, at 11:23, manet issue tracker wrote: >=20 > > #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection = with link > > quality change >=20 > I'm not sure what #51 means, but the analysis is flawed. >=20 >=20 > Means analysing the router decisions/performances if it considers = connected with neighbors or not while it has link quality change.=20 >=20 > =20 > > The neighbor nodes reaction to changes in the link quality is not > > considered by the draft. >=20 > That's because it has no reaction to changes in the link quality as = viewed by A.=20 >=20 > The reaction is link lost within router A and other reaction specified = within A.=20 > =20 > A's link quality is not communicated to B.=20 >=20 > Yes I agree.=20 > =20 > If the change lasts until the next HELLO message, A will report the = link lost, and then B will react. >=20 > Agree=20 > =20 > Exactly as it would have done without this optimisation. If B does = its own link quality process, it won't necessarily (very often won't) = have the same transients in it, and then B's reaction will be governed = by it running the protocol, optimised or not. >=20 > > For example: > > > > A ------- B ------- C (node B is N1 and C is N2) > > > > When link quality change, > > > > A - - - - B - - - - C (node A lost links but still aware) > > > > N1 and N2 may optimise as well for their links quality change. >=20 > Your notation is messed up here. Your nodes are A, B, and C. I think = you are trying to use N1 and N2 for relationship, but then N1 and N2 = can't do anything. What's done is done by A and B. This does not help. >=20 > Neighbor relationship for hop 1 and hop 2.=20 >=20 >=20 > > B has A as N1 and C as N1, so B lost links. >=20 > I don't know what you are trying to say here exactly, but B has not = lost anything due to A's link quality decisions, until A sends a HELLO = message. If A does send a HELLO message then the optimisation is = irrelevant. >=20 > B lost not because of A, I mentioned that N1 and N2 may optimize as = well so if there is a change in B links then it will make them as lost.=20= > =20 >=20 > The only way B is affected is if it also has a link quality change. = Which is possible, but by no means certain. And not a problem if it = does. >=20 > That was my point. So why it is no problem.=20 > =20 >=20 > > When A has change in link quality then: > > > > A ------- B -------- C (at node A recovered links) > > > > A - - - - B - - - - C (at node B lost links which is N1 for = A) >=20 > > B is not connected to C >=20 > Why? There absolutely no reason why the B-C link has changed, when we = are talking about a change in quality in the B to A link. If it does = this is now compounding even more effects. >=20 > Because C is optimizing also in this example, so the three nodes = optimize after change in the two links, but link AB changes before BC.=20= > =20 >=20 > > but A thinks they are. There is high probability > > that when the quality changes in links between A-B there will be = changes > > in B-C. >=20 > Why? Completely depends on why the link is poor. To say "there is high = probability there will be changes" is simple assertion without evidence. >=20 > Happens Within the mobile channel characteristics as MANET, the = movement and the node environment are usually the largest reason of = link quality change.=20 >=20 >=20 > > Furthermore, C may not be optimizing router, so it will loose A as >=20 > lose >=20 > > neighbour but A still has C as 2-hop symmetric neighbor. This can > > increase packet loss in the network. >=20 > The optimisation is really irrelevant here. If the B-C link changes = then A won't know about it until B signals that.=20 >=20 > Yes A will not know but while it recover as connected but B is having = that link lost.=20 > =20 > That's completely irrelevant to this optimisation. >=20 > If the link to B has more than a transient failure, B will be lost as = a neighbour. B's links are then irrelevant, so whop cares if a link B-C = is kept or not? >=20 > The example is showing after recovering for A. As you showed in your = presentation that there is difference in reaction between A if it = optimise or not. If A optimises then at recovery it will not loose 2 hop = link but in normal it does loose.=20 > =20 >=20 > If the link to B has a transient failure, you are suggesting that B to = C will fail (not justified) and that therefore you should discard C, = because the B-C link is bad. But now you have chosen to discard the = assumption of correlation that you used when it suited you, because now = A to B transient fails (the case of interest, as longer term failure = will have its usual non-optimised effect) but B to C is assumed = permanently (not transiently) failed. >=20 > That's just unrealistic special case pleading (you've assumed in = particular that B-C fails at the same time, that this is detected by B, = but it is longer term, not transient - that only transient matters is = because if nontransient then the main protocol will define what happens = when a HELLO message is next sent).=20 >=20 > It can happen as routers have different quality threshold and neighbor = links may have similar failur reasons.=20 >=20 > Of course we can devise cases where any change happens not to work = well here. But the best you've found makes unjustified assumptions, to = make things no worse than they would have been had, for example, A used = a more smoothed link quality. Meanwhile actually realistic cases where = things are improved are ignored by you. >=20 > And, should you run in a network with unusual properties, you still = always have the option don't use the optimisation. >=20 > You're whole argument boils down to "I'm trying hard, making = unrealistic assumptions, to find a special case where there's a = problem". And on that basis you suggest that the optional optimisation = that will demonstrably help in realistic cases shouldn't be defined. >=20 > I disagree, I think it is very simple with three nodes as neighbors. = Usually MANET working group look into large networks with very high = probability of link changes. Overall, we can assume worst case and good = case for this three node example, so the probability is about 0.25 when = all nodes optimise. We can go into analysing all cases and then find the = absolute probability which includes if nodes are optimising or not or = with larger sizes.=20 > =20 >=20 > That's not a good argument. >=20 > It is good as long there are no test results with different MANET = sizes proving optimization as with good performance. We need to look = into the worst cases while analysing. Do you think my example was the = worst case? >=20 > AB > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_C7D0F015-55DC-49DD-A395-736CD20316A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = considered to follow the method of your initial analysis = within the presentation of IETF 89 meeting. Please see slides 21-24 = related to the draft before adoption. 

On Sunday, August 10, = 2014, Christopher Dearlove wrote:

On 10 Aug 2014, at 11:23, manet issue tracker wrote:

> #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection = with link
> quality change

I'm not sure what #51 means, but the analysis is flawed.


Means analysing the router = decisions/performances if it considers connected with = neighbors or not while it has link quality = change. 

 
> The neighbor nodes reaction to changes in the link quality is = not
> considered by the draft.

That's because it has no reaction to changes in the link quality as = viewed by A. 

The reaction is link lost within router A and other reaction = specified within A. 
 
A's link quality is not communicated to = B. 

Yes I = agree. 
 
If the change lasts until the next HELLO message, A will report the link = lost, and then B will react.

Agree 
 
 Exactly as it would have done without this = optimisation. If B does its own link quality process, it won't = necessarily (very often won't) have the same transients in it, and then = B's reaction will be governed by it running the protocol, optimised or = not.

> For example:
>
> A ------- B ------- C     (node B is N1 and C is N2)
>
> When link quality change,
>
> A - - - - B - - - - C      (node A lost links but = still aware)
>
> N1 and N2 may optimise as well for their links quality change.

Your notation is messed up here. Your nodes are A, B, and C. I think you = are trying to use N1 and N2 for relationship, but then N1 and N2 can't = do anything. What's done is done by A and B. This does not = help.

Neighbor relationship for hop 1 and hop = 2. 


> B has A as N1 and C as N1, so B lost links.

I don't know what you are trying to say here exactly, but B has not lost = anything due to A's link quality decisions, until A sends a HELLO = message. If A does send a HELLO message then the optimisation is = irrelevant.

B lost not because of A, I mentioned that N1 and N2 = may optimize as well so if there is a change in B links then it will = make them as lost. 
 

The only way B is affected is if it also has a link quality change. = Which is possible, but by no means certain. And not a problem if it = does.

That was my point. So why it is no = problem. 
 

> When A has change in link quality then:
>
> A ------- B -------- C    (at node A recovered links)
>
> A - - - -  B  - - - -  C     (at node B = lost links which is N1 for A)

> B is not connected to C

Why? There absolutely no reason why the B-C link has changed, when we = are talking about a change in quality in the B to A link. If it does = this is now compounding even more = effects.

Because C is optimizing also in = this example, so the three nodes optimize after change in the two links, = but link AB changes before BC. 
 

> but A thinks they are. There is high probability
> that when the quality changes in links between A-B there will be = changes
> in B-C.

Why? Completely depends on why the link is poor. To say "there is high = probability there will be changes" is simple assertion without = evidence.

Happens Within = the mobile channel characteristics  as MANET, the = movement and the node environment  are usually the largest = reason of link quality change. 


> Furthermore, C may not be optimizing router, so it will loose A = as

lose

> neighbour but A still has C as 2-hop symmetric  neighbor. This = can
> increase packet loss in the network.

The optimisation is really irrelevant here. If the B-C link changes then = A won't know about it until B signals = that. 

Yes A will not know but while = it recover as connected but B is having that link = lost. 
 
That's completely irrelevant to this optimisation.

If the link to B has more than a transient failure, B will be lost as a = neighbour. B's links are then irrelevant, so whop cares if a link B-C is = kept or not?

The example is showing = after recovering for A. As you showed in your presentation that there is = difference in reaction between A if it optimise or not. If A optimises = then at recovery it will not loose 2 hop link but in normal it does = loose. 
 

If the link to B has a transient failure, you are suggesting that B to C = will fail (not justified) and that therefore you should discard C, = because the B-C link is bad. But now you have chosen to discard the = assumption of correlation that you used when it suited you, because now = A to B transient fails (the case of interest, as longer term failure = will have its usual non-optimised effect) but B to C is assumed = permanently (not transiently) failed.

That's just unrealistic special case pleading (you've assumed in = particular that B-C fails at the same time, that this is detected by B, = but it is longer term, not transient  - that only transient matters = is because if nontransient  then the main protocol will define what = happens when a HELLO message is next sent). 

It can happen = as routers have different quality threshold and neighbor links = may have similar failur reasons. 

Of course we can = devise cases where any change happens not to work well here. But the = best you've found makes unjustified assumptions, to make things no worse = than they would have been had, for example, A used a more smoothed link = quality. Meanwhile actually realistic cases where things are improved = are ignored by you.

And, should you run in a network with unusual properties, you still = always have the option don't use the optimisation.

You're whole argument boils down to "I'm trying hard, making unrealistic = assumptions, to find a special case where there's a problem". And on = that basis you suggest that the optional optimisation that will = demonstrably help in realistic cases shouldn't be defined.

I disagree, I think it is very simple with = three nodes as neighbors. Usually MANET working group look into large = networks with very high probability of link changes. Overall, we can = assume worst case and good case for this three node example, so the = probability is about 0.25 when all nodes optimise. We can go into = analysing all cases and then find the absolute probability which = includes if nodes are optimising or not or with larger = sizes. 
 

That's not a good argument.

It is good = as long there are no test results with different MANET sizes proving = optimization as with good performance. We need to look into the = worst cases while analysing. Do you think my example was the worst = case?

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

= --Apple-Mail=_C7D0F015-55DC-49DD-A395-736CD20316A4-- From nobody Sun Aug 10 08:42: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 5CCF91A0430 for ; Sun, 10 Aug 2014 08:42:41 -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 OSQtC0ZcPid8 for ; Sun, 10 Aug 2014 08:42:40 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C801A0363 for ; Sun, 10 Aug 2014 08:42:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id EB3F916113D; Sun, 10 Aug 2014 08:42:39 -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 16C2C1610FA; Sun, 10 Aug 2014 08:42:37 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_81487E41-9091-458F-95A8-8821FA733516" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Clausen In-Reply-To: Date: Sun, 10 Aug 2014 17:42:34 +0200 Message-Id: <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7NTfUlxn-yhV_z_k_ziEQ7zh1UQ Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 10 Aug 2014 15:42:41 -0000 --Apple-Mail=_81487E41-9091-458F-95A8-8821FA733516 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 10, 2014, at 17:21, Abdussalam Baryun = wrote: > I considered to follow the method of your initial analysis within the = presentation of IETF 89 meeting. Please see slides 21-24 related to the = draft before adoption.=20 >=20 > On Sunday, August 10, 2014, Christopher Dearlove wrote: >=20 > The only way B is affected is if it also has a link quality change. = Which is possible, but by no means certain. And not a problem if it = does. >=20 > That was my point. So why it is no problem. =20 It doesn=92t work that way - you do not get to ask someone to =93prove a = negative=94. The onus is on you to prove that there is a problem, Abdussalam. > > but A thinks they are. There is high probability > > that when the quality changes in links between A-B there will be = changes > > in B-C. >=20 > Why? Completely depends on why the link is poor. To say "there is high = probability there will be changes" is simple assertion without evidence. >=20 > Happens Within the mobile channel characteristics=20 I do not know what =93mobile channel characteristics=94 are. > as MANET, the movement and the node environment are usually the = largest reason of link quality change.=20 Anybody who has run a multi-hop wireless network with static routers can = testify to the fact that link quality change happens for a great many = factors other than =93movement=94.=20 >=20 > Of course we can devise cases where any change happens not to work = well here. But the best you've found makes unjustified assumptions, to = make things no worse than they would have been had, for example, A used = a more smoothed link quality. Meanwhile actually realistic cases where = things are improved are ignored by you. >=20 > And, should you run in a network with unusual properties, you still = always have the option don't use the optimisation. >=20 > You're whole argument boils down to "I'm trying hard, making = unrealistic assumptions, to find a special case where there's a = problem". And on that basis you suggest that the optional optimisation = that will demonstrably help in realistic cases shouldn't be defined. >=20 > I disagree, I think it is very simple with three nodes as neighbors. = Usually MANET working group look into large networks with very high = probability of link changes. Overall, we can assume worst case and good = case for this three node example, so the probability is about 0.25 when = all nodes optimise. We can go into analysing all cases and then find the = absolute probability which includes if nodes are optimising or not or = with larger sizes.=20 I am sorry, I am not sure that I understand the above, nor the relevance = of the above. > =20 >=20 > That's not a good argument. >=20 > It is good as long there are no test results with different MANET = sizes proving optimization as with good performance. We need to look = into the worst cases while analysing. Do you think my example was the = worst case? No, your example was invalid because you changed your assumptions as you = worked through it. Thomas= --Apple-Mail=_81487E41-9091-458F-95A8-8821FA733516 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 10, 2014, at 17:21, Abdussalam = Baryun <abdussalambaryun@gmail.com&= gt; wrote:

I = considered to follow the method of your initial analysis = within the presentation of IETF 89 meeting. Please see slides 21-24 = related to the draft before adoption. 

On Sunday, August 10, = 2014, Christopher Dearlove wrote:

<SNIP>


The only way B is affected is if it also has a link quality = change. Which is possible, but by no means certain. And not a problem if = it does.

That was my point. So why it is = no problem.  

It = doesn=92t work that way - you do not get to ask someone to =93prove a = negative=94.

The onus is on you to prove that = there is a problem, = Abdussalam.

<SNIP>

> but A thinks they are. There is high probability
> = that when the quality changes in links between A-B there will be = changes
> in B-C.

Why? Completely depends on why the link = is poor. To say "there is high probability there will be changes" is = simple assertion without = evidence.

Happens Within = the mobile = channel characteristics 

=
I do not know what =93mobile channel characteristics=94 = are.

 as MANET, the movement = and the node environment  are usually the largest reason of = link quality = change. 

Anybody who = has run a multi-hop wireless network with static routers can testify to = the fact that link quality change happens for a great many factors other = than = =93movement=94. 

<SNIP>

=

Of course we can devise cases where any change happens not to = work well here. But the best you've found makes unjustified assumptions, = to make things no worse than they would have been had, for example, A = used a more smoothed link quality. Meanwhile actually realistic cases = where things are improved are ignored by you.

And, should you run = in a network with unusual properties, you still always have the option = don't use the optimisation.

You're whole argument boils down to = "I'm trying hard, making unrealistic assumptions, to find a special case = where there's a problem". And on that basis you suggest that the = optional optimisation that will demonstrably help in realistic cases = shouldn't be defined.

I disagree, I = think it is very simple with three nodes as neighbors. Usually MANET = working group look into large networks with very high probability of = link changes. Overall, we can assume worst case and good case for this = three node example, so the probability is about 0.25 when all nodes = optimise. We can go into analysing all cases and then find the = absolute probability which includes if nodes are optimising or not = or with larger sizes. 

I am = sorry, I am not sure that I understand the above, nor the relevance of = the above.

 

That's not a good = argument.

It is good as long there are = no test results with different MANET sizes proving optimization as = with good performance. We need to look into the worst cases while = analysing. Do you think my example was the worst = case?

No, your example was = invalid because you changed your assumptions as you worked through = it.

Thomas
= --Apple-Mail=_81487E41-9091-458F-95A8-8821FA733516-- From nobody Sun Aug 10 08:48: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 205281A0430 for ; Sun, 10 Aug 2014 08:48:49 -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 LqPk1xyYBSkU for ; Sun, 10 Aug 2014 08:48:48 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F56E1A0412 for ; Sun, 10 Aug 2014 08:48:47 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id q107so7710699qgd.0 for ; Sun, 10 Aug 2014 08:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=7M41liitGqj+6t05s1hAyk/fbDLplIBPNohop5DUeVI=; b=ZEbbkfV0KB1slVxP8JMFUspUDAK9JPK0xaF75iM3w5uGsWU9bYJZgMlrm38VkqIFAS bCPE4GF8Efit7b2Yj56Kj9ozijfj+AZriggvHamCuyh6rXjqL+Lw8/Ynj8Io8kJko5Be Odk60wvCAfQPD4F0DnMPgnv0jW684bBkchTPvGapcrwa3Q0h9DJ9euuah4FJxBiIzqso KR8pqhTw7xw8xQDozUfZkB5DjTmJEc1QXiNV8/KQR4E/FZqLPcAbdza2vS/QrftATaWO MNiM8yUf0e88QjPsf08Ki+VsHnMVwpxyZewWtHBmOPq0Y4X90dDHW9zlbMxHK4C5E3nf FjYg== X-Received: by 10.224.80.10 with SMTP id r10mr57433356qak.24.1407685727219; Sun, 10 Aug 2014 08:48:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.18 with HTTP; Sun, 10 Aug 2014 08:48:27 -0700 (PDT) In-Reply-To: <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> From: Henning Rogge Date: Sun, 10 Aug 2014 17:48:27 +0200 Message-ID: To: Thomas Clausen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CmYDcTehJsCbIPLYQO_5Txdw-H0 Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 10 Aug 2014 15:48:49 -0000 On Sun, Aug 10, 2014 at 5:42 PM, Thomas Clausen wrote: > Anybody who has run a multi-hop wireless network with static routers can > testify to the fact that link quality change happens for a great many > factors other than =E2=80=9Cmovement=E2=80=9D. Exactly... especially with metrics based on packet loss. Hell, even on a simulated link with a perfect random generator you get fluctuations of ETX or ETT metrics because of the effects of the statistical distribution of packet loss events (e.g. Binomial distribution). Henning Rogge From nobody Sun Aug 10 09:46: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 D7C7E1A079E for ; Sun, 10 Aug 2014 09:46:34 -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 AYwKJh7lnPvm for ; Sun, 10 Aug 2014 09:46:32 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEACE1A0470 for ; Sun, 10 Aug 2014 09:46:31 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id b13so7528454wgh.18 for ; Sun, 10 Aug 2014 09:46:30 -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 :message-id:references:to; bh=WDoVP/SgF/DWZSxAWQ9wwBnEvWWNw2/oaYZuJ1KIpA8=; b=QH2qAkfX5UHWm5wLqPrn1Qw66NSTP+f7Pb3f4qpBee+GzGxpIhSFGLN5hxiojDaaZI wXM6xYyBHEBBQhoQBPKvwqeEwlYqBfJiAL4QknHiqqKZD5nOLbJzvvaEmidxoqmfhPDV qDQOy7sZXl6ikW0CIjtKmsbX2It/Zfp8FpOIpIlQkxT0evz1DeEa9e4BbTuwVLvBjwxj PXffbTko2byTx8I+8JrQ6JccfL1hNzemiOMTHjJkabnBBBWW7k1SWeasEFl+iQApRTIF O/pkc3n3LwU2eTq/4PXNOskB3AYOPKKSq7KliPaw97owuFHHZFPmLPqU3b31AUpLQfGP DISw== X-Received: by 10.180.92.38 with SMTP id cj6mr19015276wib.64.1407689190239; Sun, 10 Aug 2014 09:46:30 -0700 (PDT) Received: from [192.168.254.8] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id hp6sm32910891wib.23.2014.08.10.09.46.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Aug 2014 09:46:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_102DE6EC-27BA-4638-9EB7-CF6E3C98176C" From: Christopher Dearlove In-Reply-To: Date: Sun, 10 Aug 2014 17:46:25 +0100 Message-Id: <22F5BBC6-57CA-477C-A64F-AF504F557F60@gmail.com> References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> To: Christopher Dearlove X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RP3lH2x2CJEKYmY8_REQlIre38I Cc: "manet@ietf.org" Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 10 Aug 2014 16:46:35 -0000 --Apple-Mail=_102DE6EC-27BA-4638-9EB7-CF6E3C98176C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Actually, I'm going to add one more comment. No, the worst case is not = what matters. I can devise a worst case. In it the whole protocol = doesn't work. For example that could be down to a mismatch in mobility = and interval parameters. Or an ever-thrashing link quality. Or other = possibilities. This optimisation is irrelevant to actual worst cases. What matters is does it improve the case it is designed for? (yes). Does = it behave well in other normal cases, such as link quality going bad and = staying there? (yes). Can it behave catastrophically? (no, because if = left everything will time out). Is there a common case it seriously = makes worse? (none has been presented - no, this is not one). Is there a = mitigation in unusual circumstances where there is a problem? (yes, = don't use it, it's optional). On 10 Aug 2014, at 16:34, Christopher Dearlove wrote: > I'm just not going to do this (going through posting point by point) = again. I'm just going to reply to your last point. No, I don't think = this is a useful, consistent, well thought through or relevant case or = objection. I've explained why. >=20 > (I'll just comment that an illustration of that is the simple = invention of a 0.25 figure, which has no foundation whatsoever.) >=20 >=20 > On 10 Aug 2014, at 16:21, Abdussalam Baryun wrote: >=20 >> I considered to follow the method of your initial analysis within the = presentation of IETF 89 meeting. Please see slides 21-24 related to the = draft before adoption.=20 >>=20 >> On Sunday, August 10, 2014, Christopher Dearlove wrote: >>=20 >> On 10 Aug 2014, at 11:23, manet issue tracker wrote: >>=20 >> > #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection = with link >> > quality change >>=20 >> I'm not sure what #51 means, but the analysis is flawed. >>=20 >>=20 >> Means analysing the router decisions/performances if it considers = connected with neighbors or not while it has link quality change.=20 >>=20 >> =20 >> > The neighbor nodes reaction to changes in the link quality is not >> > considered by the draft. >>=20 >> That's because it has no reaction to changes in the link quality as = viewed by A.=20 >>=20 >> The reaction is link lost within router A and other reaction = specified within A.=20 >> =20 >> A's link quality is not communicated to B.=20 >>=20 >> Yes I agree.=20 >> =20 >> If the change lasts until the next HELLO message, A will report the = link lost, and then B will react. >>=20 >> Agree=20 >> =20 >> Exactly as it would have done without this optimisation. If B does = its own link quality process, it won't necessarily (very often won't) = have the same transients in it, and then B's reaction will be governed = by it running the protocol, optimised or not. >>=20 >> > For example: >> > >> > A ------- B ------- C (node B is N1 and C is N2) >> > >> > When link quality change, >> > >> > A - - - - B - - - - C (node A lost links but still aware) >> > >> > N1 and N2 may optimise as well for their links quality change. >>=20 >> Your notation is messed up here. Your nodes are A, B, and C. I think = you are trying to use N1 and N2 for relationship, but then N1 and N2 = can't do anything. What's done is done by A and B. This does not help. >>=20 >> Neighbor relationship for hop 1 and hop 2.=20 >>=20 >>=20 >> > B has A as N1 and C as N1, so B lost links. >>=20 >> I don't know what you are trying to say here exactly, but B has not = lost anything due to A's link quality decisions, until A sends a HELLO = message. If A does send a HELLO message then the optimisation is = irrelevant. >>=20 >> B lost not because of A, I mentioned that N1 and N2 may optimize as = well so if there is a change in B links then it will make them as lost.=20= >> =20 >>=20 >> The only way B is affected is if it also has a link quality change. = Which is possible, but by no means certain. And not a problem if it = does. >>=20 >> That was my point. So why it is no problem.=20 >> =20 >>=20 >> > When A has change in link quality then: >> > >> > A ------- B -------- C (at node A recovered links) >> > >> > A - - - - B - - - - C (at node B lost links which is N1 for = A) >>=20 >> > B is not connected to C >>=20 >> Why? There absolutely no reason why the B-C link has changed, when we = are talking about a change in quality in the B to A link. If it does = this is now compounding even more effects. >>=20 >> Because C is optimizing also in this example, so the three nodes = optimize after change in the two links, but link AB changes before BC.=20= >> =20 >>=20 >> > but A thinks they are. There is high probability >> > that when the quality changes in links between A-B there will be = changes >> > in B-C. >>=20 >> Why? Completely depends on why the link is poor. To say "there is = high probability there will be changes" is simple assertion without = evidence. >>=20 >> Happens Within the mobile channel characteristics as MANET, the = movement and the node environment are usually the largest reason of = link quality change.=20 >>=20 >>=20 >> > Furthermore, C may not be optimizing router, so it will loose A as >>=20 >> lose >>=20 >> > neighbour but A still has C as 2-hop symmetric neighbor. This can >> > increase packet loss in the network. >>=20 >> The optimisation is really irrelevant here. If the B-C link changes = then A won't know about it until B signals that.=20 >>=20 >> Yes A will not know but while it recover as connected but B is having = that link lost.=20 >> =20 >> That's completely irrelevant to this optimisation. >>=20 >> If the link to B has more than a transient failure, B will be lost as = a neighbour. B's links are then irrelevant, so whop cares if a link B-C = is kept or not? >>=20 >> The example is showing after recovering for A. As you showed in your = presentation that there is difference in reaction between A if it = optimise or not. If A optimises then at recovery it will not loose 2 hop = link but in normal it does loose.=20 >> =20 >>=20 >> If the link to B has a transient failure, you are suggesting that B = to C will fail (not justified) and that therefore you should discard C, = because the B-C link is bad. But now you have chosen to discard the = assumption of correlation that you used when it suited you, because now = A to B transient fails (the case of interest, as longer term failure = will have its usual non-optimised effect) but B to C is assumed = permanently (not transiently) failed. >>=20 >> That's just unrealistic special case pleading (you've assumed in = particular that B-C fails at the same time, that this is detected by B, = but it is longer term, not transient - that only transient matters is = because if nontransient then the main protocol will define what happens = when a HELLO message is next sent).=20 >>=20 >> It can happen as routers have different quality threshold and = neighbor links may have similar failur reasons.=20 >>=20 >> Of course we can devise cases where any change happens not to work = well here. But the best you've found makes unjustified assumptions, to = make things no worse than they would have been had, for example, A used = a more smoothed link quality. Meanwhile actually realistic cases where = things are improved are ignored by you. >>=20 >> And, should you run in a network with unusual properties, you still = always have the option don't use the optimisation. >>=20 >> You're whole argument boils down to "I'm trying hard, making = unrealistic assumptions, to find a special case where there's a = problem". And on that basis you suggest that the optional optimisation = that will demonstrably help in realistic cases shouldn't be defined. >>=20 >> I disagree, I think it is very simple with three nodes as neighbors. = Usually MANET working group look into large networks with very high = probability of link changes. Overall, we can assume worst case and good = case for this three node example, so the probability is about 0.25 when = all nodes optimise. We can go into analysing all cases and then find the = absolute probability which includes if nodes are optimising or not or = with larger sizes.=20 >> =20 >>=20 >> That's not a good argument. >>=20 >> It is good as long there are no test results with different MANET = sizes proving optimization as with good performance. We need to look = into the worst cases while analysing. Do you think my example was the = worst case? >>=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 --Apple-Mail=_102DE6EC-27BA-4638-9EB7-CF6E3C98176C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = considered to follow the method of your initial analysis = within the presentation of IETF 89 meeting. Please see slides 21-24 = related to the draft before adoption. 

On Sunday, August 10, = 2014, Christopher Dearlove wrote:

On 10 Aug 2014, at 11:23, manet issue tracker wrote:

> #51: Analysis of OLSRv2/NHDP-optimized Handling neighbor connection = with link
> quality change

I'm not sure what #51 means, but the analysis is flawed.


Means analysing the router = decisions/performances if it considers connected with = neighbors or not while it has link quality = change. 

 
> The neighbor nodes reaction to changes in the link quality is = not
> considered by the draft.

That's because it has no reaction to changes in the link quality as = viewed by A. 

The reaction is link lost within router A and other reaction = specified within A. 
 
A's link quality is not communicated to = B. 

Yes I = agree. 
 
If the change lasts until the next HELLO message, A will report the link = lost, and then B will react.

Agree 
 
 Exactly as it would have done without this = optimisation. If B does its own link quality process, it won't = necessarily (very often won't) have the same transients in it, and then = B's reaction will be governed by it running the protocol, optimised or = not.

> For example:
>
> A ------- B ------- C     (node B is N1 and C is N2)
>
> When link quality change,
>
> A - - - - B - - - - C      (node A lost links but = still aware)
>
> N1 and N2 may optimise as well for their links quality change.

Your notation is messed up here. Your nodes are A, B, and C. I think you = are trying to use N1 and N2 for relationship, but then N1 and N2 can't = do anything. What's done is done by A and B. This does not = help.

Neighbor relationship for hop 1 and hop = 2. 


> B has A as N1 and C as N1, so B lost links.

I don't know what you are trying to say here exactly, but B has not lost = anything due to A's link quality decisions, until A sends a HELLO = message. If A does send a HELLO message then the optimisation is = irrelevant.

B lost not because of A, I mentioned that N1 and N2 = may optimize as well so if there is a change in B links then it will = make them as lost. 
 

The only way B is affected is if it also has a link quality change. = Which is possible, but by no means certain. And not a problem if it = does.

That was my point. So why it is no = problem. 
 

> When A has change in link quality then:
>
> A ------- B -------- C    (at node A recovered links)
>
> A - - - -  B  - - - -  C     (at node B = lost links which is N1 for A)

> B is not connected to C

Why? There absolutely no reason why the B-C link has changed, when we = are talking about a change in quality in the B to A link. If it does = this is now compounding even more = effects.

Because C is optimizing also in = this example, so the three nodes optimize after change in the two links, = but link AB changes before BC. 
 

> but A thinks they are. There is high probability
> that when the quality changes in links between A-B there will be = changes
> in B-C.

Why? Completely depends on why the link is poor. To say "there is high = probability there will be changes" is simple assertion without = evidence.

Happens Within = the mobile channel characteristics  as MANET, the = movement and the node environment  are usually the largest = reason of link quality change. 


> Furthermore, C may not be optimizing router, so it will loose A = as

lose

> neighbour but A still has C as 2-hop symmetric  neighbor. This = can
> increase packet loss in the network.

The optimisation is really irrelevant here. If the B-C link changes then = A won't know about it until B signals = that. 

Yes A will not know but while = it recover as connected but B is having that link = lost. 
 
That's completely irrelevant to this optimisation.

If the link to B has more than a transient failure, B will be lost as a = neighbour. B's links are then irrelevant, so whop cares if a link B-C is = kept or not?

The example is showing = after recovering for A. As you showed in your presentation that there is = difference in reaction between A if it optimise or not. If A optimises = then at recovery it will not loose 2 hop link but in normal it does = loose. 
 

If the link to B has a transient failure, you are suggesting that B to C = will fail (not justified) and that therefore you should discard C, = because the B-C link is bad. But now you have chosen to discard the = assumption of correlation that you used when it suited you, because now = A to B transient fails (the case of interest, as longer term failure = will have its usual non-optimised effect) but B to C is assumed = permanently (not transiently) failed.

That's just unrealistic special case pleading (you've assumed in = particular that B-C fails at the same time, that this is detected by B, = but it is longer term, not transient  - that only transient matters = is because if nontransient  then the main protocol will define what = happens when a HELLO message is next sent). 

It can happen = as routers have different quality threshold and neighbor links = may have similar failur reasons. 

Of course we can = devise cases where any change happens not to work well here. But the = best you've found makes unjustified assumptions, to make things no worse = than they would have been had, for example, A used a more smoothed link = quality. Meanwhile actually realistic cases where things are improved = are ignored by you.

And, should you run in a network with unusual properties, you still = always have the option don't use the optimisation.

You're whole argument boils down to "I'm trying hard, making unrealistic = assumptions, to find a special case where there's a problem". And on = that basis you suggest that the optional optimisation that will = demonstrably help in realistic cases shouldn't be defined.

I disagree, I think it is very simple with = three nodes as neighbors. Usually MANET working group look into large = networks with very high probability of link changes. Overall, we can = assume worst case and good case for this three node example, so the = probability is about 0.25 when all nodes optimise. We can go into = analysing all cases and then find the absolute probability which = includes if nodes are optimising or not or with larger = sizes. 
 

That's not a good argument.

It is good = as long there are no test results with different MANET sizes proving = optimization as with good performance. We need to look into the = worst cases while analysing. Do you think my example was the worst = case?

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=_102DE6EC-27BA-4638-9EB7-CF6E3C98176C-- From nobody Mon Aug 11 01:56: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 E8A561A0382 for ; Mon, 11 Aug 2014 01:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 qTAxBBSS1NrM for ; Mon, 11 Aug 2014 01:56:01 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D091A0380 for ; Mon, 11 Aug 2014 01:56:01 -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 1XGlOZ-0002AF-J6 for manet@ietf.org; Mon, 11 Aug 2014 10:55:59 +0200 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 1XGlOZ-00020z-FA for manet@ietf.org; Mon, 11 Aug 2014 10:55:59 +0200 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; Mon, 11 Aug 2014 10:55:59 +0200 Message-ID: <53E88519.9070606@fkie.fraunhofer.de> Date: Mon, 11 Aug 2014 10:55:53 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "manet@ietf.org" References: <20140811085415.15019.55631.idtracker@ietfa.amsl.com> In-Reply-To: <20140811085415.15019.55631.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20140811085415.15019.55631.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020500000505050208000108" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19276/Mon Aug 11 06:30:28 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8f0825cc5ea57eed1c396caca87449a6 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_UT8S68oNrDgmdDlKh_5h1XXfIo Subject: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-01.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: Mon, 11 Aug 2014 08:56:04 -0000 --------------ms020500000505050208000108 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I have uploaded a new revision of my "dualstack optimization" draft. I hope the new revision addresses a few of the unclear parts of the first one. Henning Rogge -------- Forwarded Message -------- Subject: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-01.txt Date: Mon, 11 Aug 2014 01:54:15 -0700 From: internet-drafts@ietf.org To: Henning Rogge , Henning Rogge A new version of I-D, draft-rogge-manet-nhdp-dualstack-optimization-01.tx= t has been successfully submitted by Henning Rogge and posted to the IETF repository. Name: draft-rogge-manet-nhdp-dualstack-optimization Revision: 01 Title: Optimized flooding for NHDP Dual Stack routers Document date: 2014-08-11 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-rogge-manet-nhdp-dualstack-opti= mization-01.txt Status: https://datatracker.ietf.org/doc/draft-rogge-manet-nhdp-dualstack-optimiz= ation/ Htmlized: http://tools.ietf.org/html/draft-rogge-manet-nhdp-dualstack-optimization-= 01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-rogge-manet-nhdp-dualstack-optim= ization-01 Abstract: This document specifies an optimization for the flooding of RFC5444 control traffic with NHDP in dualstack deployments. 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. The IETF Secretariat --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020500000505050208000108 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 Fw0xNDA4MTEwODU1NThaMCMGCSqGSIb3DQEJBDEWBBRzNeU39+Zka5d8BAUiR/dgcf7RPjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAd9oQgxyGIJJu0ktpx1DQWhwpJNGoweWZL5b2nPf17DuY 0Mojo274pxvOGOOHPc9uy+5nt0LFgdk733i1wTBGkgR1aHwLJp5vjKGuSUAu6ZUVC1VHgEXF k5L9Vby8F/tUiSHT8OhSqetcStAqeBVWhbqHqa28gPfA+t+NqyVIViONvQAFabb8QQYvATZc qDpREK5J6CNTRMDZ+p1nlsSzjEVvD7dwMGjeGEmbEd4N9qoMTMDF8EJx6ME0rfT+Gl42V3jx FbIvMmtvX5EsqJL4AzCl9siNvkiPI4xXYa9pi94T2lueSOYD7RnQxHQm648+lSomt4+zw8l8 l1WgdZae+wAAAAAAAA== --------------ms020500000505050208000108-- From nobody Mon Aug 11 03:03: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 724D71A03B7 for ; Mon, 11 Aug 2014 03:03:13 -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 xrNqVVIB1Duq for ; Mon, 11 Aug 2014 03:03:12 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5261A03AC for ; Mon, 11 Aug 2014 03:03:11 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so3895529wiw.12 for ; Mon, 11 Aug 2014 03:03:10 -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=eEiNCq5YzNbpOV5yLTuu+E+NnVXoGQz4Vy8aRH7u8qU=; b=eChTH3UnDBXstqZ5VuuNEO5QuQ6DxyhjmGZ7Vv+f/pKL+GqxuNfpjvjw/X89R30lvW 8m+5uF/H5P5frwqVxMPCoZzXLYWVCFOt9nQWyofuFyO8V+4jSFw0XTJfqcJ/+m2qWMTG DHAyEtpRKJnUyuh1vniMFq/QvrWjLN1GAgV5K5x5PiPNeGa+LswOxO3XILspeSiuxtpK izzsiyiawOI7fdTufuLSEqz+SMsYsX/CbTrEbJqBhN/Y8gou9/4034IO3AiI/ZJIcafm soW95vSS8YkI7XRnGoHIHbhN7Ftgmcm4ENWex4M7bW8q64o3qRqF5lfwvUcNRYBXjwpA yADQ== MIME-Version: 1.0 X-Received: by 10.194.95.166 with SMTP id dl6mr10631322wjb.115.1407751389908; Mon, 11 Aug 2014 03:03:09 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Mon, 11 Aug 2014 03:03:09 -0700 (PDT) In-Reply-To: <53E88519.9070606@fkie.fraunhofer.de> References: <20140811085415.15019.55631.idtracker@ietfa.amsl.com> <53E88519.9070606@fkie.fraunhofer.de> Date: Mon, 11 Aug 2014 12:03:09 +0200 X-Google-Sender-Auth: JfaOOWGZlwsQdxQJyIN1zGACt7w Message-ID: From: Jiazi YI To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7bb03982871470050057a915 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yJd6RINqJop23RHFFg9Wv3jvCVc Cc: "manet@ietf.org" Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-01.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: Mon, 11 Aug 2014 10:03:13 -0000 --047d7bb03982871470050057a915 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Henning, I took a quick look at the draft. The first question I would like to ask is: what's the assumption of the "dual track" model you use here? You assume two independent IPv4/IPv6 implementations are running on each router? Or "a single combined implementation for both IP address types"? -- I actually don't know what how the latter works. If I remember correctly, a NHDP router will regard message with different address length as "invalid". best Jiazi On Mon, Aug 11, 2014 at 10:55 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > Hi, > > I have uploaded a new revision of my "dualstack optimization" draft. > > I hope the new revision addresses a few of the unclear parts of the > first one. > > Henning Rogge > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-rogge-manet-nhdp-dualstack-optimization-01.txt > Date: Mon, 11 Aug 2014 01:54:15 -0700 > From: internet-drafts@ietf.org > To: Henning Rogge , Henning Rogge > > > > A new version of I-D, draft-rogge-manet-nhdp-dualstack-optimization-01.tx= t > has been successfully submitted by Henning Rogge and posted to the > IETF repository. > > Name: draft-rogge-manet-nhdp-dualstack-optimization > Revision: 01 > Title: Optimized flooding for NHDP Dual Stack routers > Document date: 2014-08-11 > Group: Individual Submission > Pages: 9 > URL: > > http://www.ietf.org/internet-drafts/draft-rogge-manet-nhdp-dualstack-opti= mization-01.txt > Status: > > https://datatracker.ietf.org/doc/draft-rogge-manet-nhdp-dualstack-optimiz= ation/ > Htmlized: > http://tools.ietf.org/html/draft-rogge-manet-nhdp-dualstack-optimization-= 01 > Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-rogge-manet-nhdp-dualstack-optim= ization-01 > > Abstract: > This document specifies an optimization for the flooding of RFC5444 > control traffic with NHDP in dualstack deployments. > > > > > > 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 > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7bb03982871470050057a915 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Henning,=C2=A0

I took a quick look a= t the draft. The first question I would like to ask is: what's the assu= mption of the "dual track" model you use here?
You assu= me two independent IPv4/IPv6 implementations are running on each router? Or= "a single combined implementation for both IP address types"? --= I actually don't know what how the latter works. If I remember correct= ly, a NHDP router will regard message with different address length as &quo= t;invalid".=C2=A0

best

Jiazi


On Mon, Aug 11, 2014 = at 10:55 AM, Henning Rogge <henning.rogge@fkie.fraunhofer.d= e> wrote:
Hi,

I have uploaded a new revision of my "dualstack optimization" dra= ft.

I hope the new revision addresses a few of the unclear parts of the
first one.

Henning Rogge


-------- Forwarded Message --------
Subject: New Version Notification for
draft-rogge-manet-nhdp-dualstack-optimization-01.txt
Date: Mon, 11 Aug 2014 01:54:15 -0700
From: internet-drafts@ietf.org<= /a>
To: Henning Rogge <h= enning.rogge@fkie.fraunhofer.de>, Henning Rogge
<henning.rogge@fkie.= fraunhofer.de>


A new version of I-D, draft-rogge-manet-nhdp-dualstack-optimization-01.txt<= br> has been successfully submitted by Henning Rogge and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-rogge-manet-nhdp-dualstack-o= ptimization
Revision: =C2=A0 =C2=A0 =C2=A0 01
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optimized flooding for NHDP Dual S= tack routers
Document date: =C2=A02014-08-11
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
URL:
http://www.ietf.org/internet-dr= afts/draft-rogge-manet-nhdp-dualstack-optimization-01.txt
Status:
https://datatracker.ietf.org/doc/draft-r= ogge-manet-nhdp-dualstack-optimization/
Htmlized:
http://tools.ietf.org/html/draft-rogge-manet= -nhdp-dualstack-optimization-01
Diff:
http://www.ietf.org/rfcdiff?url2=3Dd= raft-rogge-manet-nhdp-dualstack-optimization-01

Abstract:
=C2=A0 =C2=A0This document specifies an optimization for the flooding of RF= C5444
=C2=A0 =C2=A0control traffic with NHDP in dualstack deployments.





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.

The IETF Secretariat


--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany
Telefon +49 = 228 9435-961, =C2=A0 Fax +49 228 9435 685
mailto:henning.rogge@fk= ie.fraunhofer.de http://www.fkie.fraunhofer.de




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


--047d7bb03982871470050057a915-- From nobody Mon Aug 11 03:08: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 A54801A03BF for ; Mon, 11 Aug 2014 03:08:22 -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 kJ7gjTxETPyV for ; Mon, 11 Aug 2014 03:08:20 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E605E1A03BB for ; Mon, 11 Aug 2014 03:08:19 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 10so5801024ykt.31 for ; Mon, 11 Aug 2014 03:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SgrghE3dPT9NFJZiX7QsiVUorthcOPg0pScKTPMDKgw=; b=jntoc+W7n7wLFZ0Oia9g0IVkbEsSLigIESfDPVjRVwJCEijcnq9ppRDg3CEM1zEtba ZqhO1NgxXZeDkPSIg3eCaK+dz85ynMaCJLof7pzrH9CNOpq+KAOKSBQnyUxD8MItEXUa 7pxiEVdzJ2osjc8o45tfIZjJK4CHl91w4ker0heDuzYLRFYvZBQUgYxNoaq0kFwTbkbL hHjBduSw6KYAImN0ZIJREhuOoZouvpJrtMZ8jKCcF6LB0M2QNNAm+r1R/mh1gWAzHKmV Fbu4XEeB0t9M1j3rhxrKeJ8ReOSdNBEJG7AuKLcQJgdt5rnDTVP/X0ezvhuPt+qRovj9 Nwvw== MIME-Version: 1.0 X-Received: by 10.236.35.103 with SMTP id t67mr41371548yha.7.1407751699058; Mon, 11 Aug 2014 03:08:19 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Mon, 11 Aug 2014 03:08:18 -0700 (PDT) In-Reply-To: <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> Date: Mon, 11 Aug 2014 12:08:18 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Clausen Content-Type: multipart/alternative; boundary=20cf3011e243f456be050057bbf8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/sc14aOV6ndl2UqUQYkUOVLev1kQ Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 11 Aug 2014 10:08:22 -0000 --20cf3011e243f456be050057bbf8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, August 10, 2014, Thomas Clausen wrote: > > > > but A thinks they are. There is high probability >> > that when the quality changes in links between A-B there will be chang= es >> > in B-C. >> >> Why? Completely depends on why the link is poor. To say "there is high >> probability there will be changes" is simple assertion without evidence. > > > Happens Within the mobile channel characteristics > > > I do not know what =E2=80=9Cmobile channel characteristics=E2=80=9D are. > > as MANET, the movement and the node environment are usually the largest > reason of link quality change. > > > Anybody who has run a multi-hop wireless network with static routers can > testify to the fact that link quality change happens for a great many > factors other than =E2=80=9Cmovement=E2=80=9D. > > That change with static depend on the channel as you mentioned above that you did not know (defined by many if googled), but I included it as a factor with mobility. The network/node movement affects the channel characteristic as well. Usually as the draft applicability statement has accepted the general purpose scenario, so the A-B link frequency channel mostly similar to the B-C frequency channel so both links can have high correlation of link quality change. AB --20cf3011e243f456be050057bbf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, August 10, 2014, Thomas Clausen wrote:


> but A thinks they are. There is high probability
&= gt; that when the quality changes in links between A-B there will be change= s
> in B-C.

Why? Completely depends on why the link is poor. To say= "there is high probability there will be changes" is simple asse= rtion without evidence.

Happens=C2=A0Within= the=C2=A0mobile channel=C2=A0characteristics=C2=A0

I do not know what =E2=80=9Cmobile c= hannel characteristics=E2=80=9D are.

=C2=A0as MANET, the movement and the node environment=C2=A0=C2=A0are u= sually the largest reason of link quality change.=C2=A0

Anybody who has run a multi-hop wireless network w= ith static routers can testify to the fact that link quality change happens= for a great many factors other than =E2=80=9Cmovement=E2=80=9D.=C2=A0


That=C2=A0chang= e with static=C2=A0depend on the channel as you mentioned above that=C2=A0y= ou did not know (defined by many if googled),=C2=A0but I included it as a f= actor with mobility.=C2=A0The network/node=C2=A0movement affects=C2=A0the c= hannel characteristic=C2=A0as well.

=C2=A0Usually as the draft applicability statement=C2= =A0has accepted the=C2=A0general purpose scenario, so=C2=A0the=C2=A0A-B lin= k=C2=A0frequency=C2=A0channel mostly=C2=A0similar to the B-C frequency=C2= =A0channel so both links=C2=A0can have high correlation of link=C2=A0qualit= y change.=C2=A0

AB

--20cf3011e243f456be050057bbf8-- From nobody Mon Aug 11 03:20: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 BC8221A03BE for ; Mon, 11 Aug 2014 03:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 1TySCOOGvhhR for ; Mon, 11 Aug 2014 03:19:59 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611811A03B9 for ; Mon, 11 Aug 2014 03:19:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,840,1400022000"; d="scan'208,217";a="394860409" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Aug 2014 11:19:55 +0100 X-IronPort-AV: E=Sophos; i="5.01,840,1400022000"; d="scan'208,217"; a="69044146" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 11 Aug 2014 11:20:10 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Mon, 11 Aug 2014 11:20:10 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , Thomas Clausen Thread-Topic: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change Thread-Index: AQHPtIU24If+JKsjMkmNfqDgEX2L75vJqzsAgAA4e4CAAAXkAIABNPAAgAASK5A= Date: Mon, 11 Aug 2014 10:20:10 +0000 Message-ID: References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D20348GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2e7R0RC_7J6OBLMUkmlrmxjT1lQ Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 11 Aug 2014 10:20:04 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D20348GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGhlIGtleSB3b3JkcyB0aGVyZSBhcmUg4oCcY2FuIGhhdmXigJ0uIE5vdCDigJx3aWxsIGhhdmXi gJ0uDQoNCkFuZCBldmVuIHRoZW4geW91IHdlcmVu4oCZdCBjb25zaXN0ZW50LCB5b3UgYXNzdW1l IEItQyB3ZW50IGRvd24gd2hlbiBBLUIgZGlkLCBidXQgbm90IHRoYXQgQi1DIHdlbnQgdXAgd2hl biBBLUIgZGlkLiBUaGlzIG1heSBiZSBjb25zaWRlcmVkIGF0dGVtcHRpbmcgdG8gaGF2ZSB5b3Vy IGNha2UgYW5kIGVhdCBpdCwgaWYgdGhlIGNha2UgaXMgZmluZGluZyBhIHByb2JsZW0uIChJ4oCZ bSBub3Qgc3VyZSB3aHkgeW91IGFyZSB0cnlpbmcgaGFyZCB0byBmaW5kIGEgcHJvYmxlbSBubyBv bmUgZWxzZSBoYXMsIGJ1dCB0aGF0IHNlZW1zIHRvIGJlIHRoZSBjYXNlLikNCg0KQW5kLCBhcyBo YXMgYmVlbiBzYWlkIHNldmVyYWwgdGltZXMsIGlmIHlvdSBoYXZlIGEgc2NlbmFyaW8gd2l0aCBh IHByb2JsZW0sIGp1c3QgZG9u4oCZdCB1c2UgaXQuDQoNCihTaW1pbGFybHkgaWYgeW91IGhhdmUg YSBzY2VuYXJpbyB3aGVyZSBpdCBpcyBwb2ludGxlc3MsIHlvdSBjYW4gZGVjaWRlIG5vdCB0byB1 c2UgaXQuIEFuIGV4YW1wbGUgdGhlcmUgY291bGQgYmUgYSBoZWF2aWx5IGRhbXBlZCBsaW5rIHF1 YWxpdHkgdGhhdCBpZiBpdCBnb2VzIGRvd24gY2Fu4oCZdCBjb21lIGJhY2sgdXAgaW4gbGVzcyB0 aGFuIFJFRlJFU0hfSU5URVJWQUwgdGltZS4gSXQgd29u4oCZdCBkbyBhbnkgaGFybSDigJMgZXhj ZXB0IGEgdHJpdmlhbCBhbW91bnQgb2Ygc3RvcmFnZSBhbmQgcHJvY2Vzc2luZyDigJMgYnV0IGl0 IHdvbuKAmXQgZG8gbXVjaCBnb29kIGVpdGhlci4pDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92 ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3Vw DQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkN CkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5pbmdmaWVs ZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6ICs0NCAx MjQ1IDI0MjE5NCB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB8IGh0dHA6Ly93 d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQNClJl Z2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFl cm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLDQpSZWdpc3Rl cmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KDQpGcm9tOiBtYW5ldCBbbWFpbHRv Om1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBYmR1c3NhbGFtIEJhcnl1bg0K U2VudDogMTEgQXVndXN0IDIwMTQgMTE6MDgNClRvOiBUaG9tYXMgQ2xhdXNlbg0KQ2M6IENocmlz dG9waGVyIERlYXJsb3ZlOyBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0gIzUx IChuaGRwLW9wdGltaXphdGlvbik6IEFuYWx5c2lzIG9mIE9MU1J2Mi9OSERQLW9wdGltaXplZCBI YW5kbGluZyBuZWlnaGJvciBjb25uZWN0aW9uIHdpdGggbGluayBxdWFsaXR5IGNoYW5nZQ0KDQpP biBTdW5kYXksIEF1Z3VzdCAxMCwgMjAxNCwgVGhvbWFzIENsYXVzZW4gd3JvdGU6DQoNCg0KPiBi dXQgQSB0aGlua3MgdGhleSBhcmUuIFRoZXJlIGlzIGhpZ2ggcHJvYmFiaWxpdHkNCj4gdGhhdCB3 aGVuIHRoZSBxdWFsaXR5IGNoYW5nZXMgaW4gbGlua3MgYmV0d2VlbiBBLUIgdGhlcmUgd2lsbCBi ZSBjaGFuZ2VzDQo+IGluIEItQy4NCg0KV2h5PyBDb21wbGV0ZWx5IGRlcGVuZHMgb24gd2h5IHRo ZSBsaW5rIGlzIHBvb3IuIFRvIHNheSAidGhlcmUgaXMgaGlnaCBwcm9iYWJpbGl0eSB0aGVyZSB3 aWxsIGJlIGNoYW5nZXMiIGlzIHNpbXBsZSBhc3NlcnRpb24gd2l0aG91dCBldmlkZW5jZS4NCg0K SGFwcGVucyBXaXRoaW4gdGhlIG1vYmlsZSBjaGFubmVsIGNoYXJhY3RlcmlzdGljcw0KDQpJIGRv IG5vdCBrbm93IHdoYXQg4oCcbW9iaWxlIGNoYW5uZWwgY2hhcmFjdGVyaXN0aWNz4oCdIGFyZS4N Cg0KIGFzIE1BTkVULCB0aGUgbW92ZW1lbnQgYW5kIHRoZSBub2RlIGVudmlyb25tZW50ICBhcmUg dXN1YWxseSB0aGUgbGFyZ2VzdCByZWFzb24gb2YgbGluayBxdWFsaXR5IGNoYW5nZS4NCg0KQW55 Ym9keSB3aG8gaGFzIHJ1biBhIG11bHRpLWhvcCB3aXJlbGVzcyBuZXR3b3JrIHdpdGggc3RhdGlj IHJvdXRlcnMgY2FuIHRlc3RpZnkgdG8gdGhlIGZhY3QgdGhhdCBsaW5rIHF1YWxpdHkgY2hhbmdl IGhhcHBlbnMgZm9yIGEgZ3JlYXQgbWFueSBmYWN0b3JzIG90aGVyIHRoYW4g4oCcbW92ZW1lbnTi gJ0uDQoNCg0KVGhhdCBjaGFuZ2Ugd2l0aCBzdGF0aWMgZGVwZW5kIG9uIHRoZSBjaGFubmVsIGFz IHlvdSBtZW50aW9uZWQgYWJvdmUgdGhhdCB5b3UgZGlkIG5vdCBrbm93IChkZWZpbmVkIGJ5IG1h bnkgaWYgZ29vZ2xlZCksIGJ1dCBJIGluY2x1ZGVkIGl0IGFzIGEgZmFjdG9yIHdpdGggbW9iaWxp dHkuIFRoZSBuZXR3b3JrL25vZGUgbW92ZW1lbnQgYWZmZWN0cyB0aGUgY2hhbm5lbCBjaGFyYWN0 ZXJpc3RpYyBhcyB3ZWxsLg0KDQogVXN1YWxseSBhcyB0aGUgZHJhZnQgYXBwbGljYWJpbGl0eSBz dGF0ZW1lbnQgaGFzIGFjY2VwdGVkIHRoZSBnZW5lcmFsIHB1cnBvc2Ugc2NlbmFyaW8sIHNvIHRo ZSBBLUIgbGluayBmcmVxdWVuY3kgY2hhbm5lbCBtb3N0bHkgc2ltaWxhciB0byB0aGUgQi1DIGZy ZXF1ZW5jeSBjaGFubmVsIHNvIGJvdGggbGlua3MgY2FuIGhhdmUgaGlnaCBjb3JyZWxhdGlvbiBv ZiBsaW5rIHF1YWxpdHkgY2hhbmdlLg0KDQpBQg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBp ZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5 IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioK --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D20348GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBr ZXkgd29yZHMgdGhlcmUgYXJlIOKAnGNhbiBoYXZl4oCdLiBOb3Qg4oCcd2lsbCBoYXZl4oCdLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QW5kIGV2ZW4gdGhlbiB5b3Ugd2VyZW7igJl0IGNvbnNpc3RlbnQsIHlvdSBhc3N1 bWUgQi1DIHdlbnQgZG93biB3aGVuIEEtQiBkaWQsIGJ1dCBub3QgdGhhdCBCLUMgd2VudCB1cCB3 aGVuIEEtQiBkaWQuIFRoaXMgbWF5IGJlIGNvbnNpZGVyZWQgYXR0ZW1wdGluZyB0byBoYXZlDQog eW91ciBjYWtlIGFuZCBlYXQgaXQsIGlmIHRoZSBjYWtlIGlzIGZpbmRpbmcgYSBwcm9ibGVtLiAo SeKAmW0gbm90IHN1cmUgd2h5IHlvdSBhcmUgdHJ5aW5nIGhhcmQgdG8gZmluZCBhIHByb2JsZW0g bm8gb25lIGVsc2UgaGFzLCBidXQgdGhhdCBzZWVtcyB0byBiZSB0aGUgY2FzZS4pPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5BbmQsIGFzIGhhcyBiZWVuIHNhaWQgc2V2ZXJhbCB0aW1lcywgaWYgeW91IGhhdmUgYSBzY2Vu YXJpbyB3aXRoIGEgcHJvYmxlbSwganVzdCBkb27igJl0IHVzZSBpdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihTaW1p bGFybHkgaWYgeW91IGhhdmUgYSBzY2VuYXJpbyB3aGVyZSBpdCBpcyBwb2ludGxlc3MsIHlvdSBj YW4gZGVjaWRlIG5vdCB0byB1c2UgaXQuIEFuIGV4YW1wbGUgdGhlcmUgY291bGQgYmUgYSBoZWF2 aWx5IGRhbXBlZCBsaW5rIHF1YWxpdHkgdGhhdCBpZiBpdCBnb2VzDQogZG93biBjYW7igJl0IGNv bWUgYmFjayB1cCBpbiBsZXNzIHRoYW4gUkVGUkVTSF9JTlRFUlZBTCB0aW1lLiBJdCB3b27igJl0 IGRvIGFueSBoYXJtIOKAkyBleGNlcHQgYSB0cml2aWFsIGFtb3VudCBvZiBzdG9yYWdlIGFuZCBw cm9jZXNzaW5nIOKAkyBidXQgaXQgd29u4oCZdCBkbyBtdWNoIGdvb2QgZWl0aGVyLik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwPGJy Pg0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5 PGJyPg0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+DQpXZXN0IEhh bm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLPGJy Pg0KVGVsOiAmIzQzOzQ0IDEyNDUgMjQyMTk0Jm5ic3A7fCZuYnNwOyBGYXg6ICYjNDM7NDQgMTI0 NSAyNDIxMjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Y2hyaXMuZGVh cmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPg0KIHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1z LmNvbTxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QkFFIFN5c3RlbXMgKE9wZXJhdGlv bnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94 IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdV MTQgNllVLCBVSzxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMTk5 NjY4NzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkFiZHVzc2FsYW0gQmFyeXVuPGJyPg0KPGI+U2VudDo8L2I+IDEx IEF1Z3VzdCAyMDE0IDExOjA4PGJyPg0KPGI+VG86PC9iPiBUaG9tYXMgQ2xhdXNlbjxicj4NCjxi PkNjOjwvYj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmU7IG1hbmV0QGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbbWFuZXRdICM1MSAobmhkcC1vcHRpbWl6YXRpb24pOiBBbmFseXNpcyBv ZiBPTFNSdjIvTkhEUC1vcHRpbWl6ZWQgSGFuZGxpbmcgbmVpZ2hib3IgY29ubmVjdGlvbiB3aXRo IGxpbmsgcXVhbGl0eSBjaGFuZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpPbiBTdW5kYXksIEF1Z3VzdCAxMCwgMjAxNCwgVGhvbWFzIENsYXVzZW4g d3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0 OyBidXQgQSB0aGlua3MgdGhleSBhcmUuIFRoZXJlIGlzIGhpZ2ggcHJvYmFiaWxpdHk8YnI+DQom Z3Q7IHRoYXQgd2hlbiB0aGUgcXVhbGl0eSBjaGFuZ2VzIGluIGxpbmtzIGJldHdlZW4gQS1CIHRo ZXJlIHdpbGwgYmUgY2hhbmdlczxicj4NCiZndDsgaW4gQi1DLjxicj4NCjxicj4NCldoeT8gQ29t cGxldGVseSBkZXBlbmRzIG9uIHdoeSB0aGUgbGluayBpcyBwb29yLiBUbyBzYXkgJnF1b3Q7dGhl cmUgaXMgaGlnaCBwcm9iYWJpbGl0eSB0aGVyZSB3aWxsIGJlIGNoYW5nZXMmcXVvdDsgaXMgc2lt cGxlIGFzc2VydGlvbiB3aXRob3V0IGV2aWRlbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IYXBw ZW5zJm5ic3A7V2l0aGluIHRoZSZuYnNwO21vYmlsZSBjaGFubmVsJm5ic3A7Y2hhcmFjdGVyaXN0 aWNzJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IGtub3cgd2hhdCDi gJxtb2JpbGUgY2hhbm5lbCBjaGFyYWN0ZXJpc3RpY3PigJ0gYXJlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDthcyBNQU5FVCwgdGhlIG1vdmVtZW50IGFuZCB0aGUg bm9kZSBlbnZpcm9ubWVudCZuYnNwOyZuYnNwO2FyZSB1c3VhbGx5IHRoZSBsYXJnZXN0IHJlYXNv biBvZiBsaW5rIHF1YWxpdHkgY2hhbmdlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Bbnlib2R5IHdobyBoYXMgcnVuIGEgbXVsdGktaG9wIHdpcmVsZXNzIG5ldHdvcmsgd2l0aCBz dGF0aWMgcm91dGVycyBjYW4gdGVzdGlmeSB0byB0aGUgZmFjdCB0aGF0IGxpbmsgcXVhbGl0eSBj aGFuZ2UgaGFwcGVucyBmb3IgYSBncmVhdCBtYW55IGZhY3RvcnMgb3RoZXIgdGhhbiDigJxtb3Zl bWVudOKAnS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCZuYnNwO2NoYW5nZSB3aXRoIHN0YXRp YyZuYnNwO2RlcGVuZCBvbiB0aGUgY2hhbm5lbCBhcyB5b3UgbWVudGlvbmVkIGFib3ZlIHRoYXQm bmJzcDt5b3UgZGlkIG5vdCBrbm93IChkZWZpbmVkIGJ5IG1hbnkgaWYgZ29vZ2xlZCksJm5ic3A7 YnV0IEkgaW5jbHVkZWQgaXQgYXMgYSBmYWN0b3Igd2l0aCBtb2JpbGl0eS4mbmJzcDtUaGUgbmV0 d29yay9ub2RlJm5ic3A7bW92ZW1lbnQgYWZmZWN0cyZuYnNwO3RoZSBjaGFubmVsIGNoYXJhY3Rl cmlzdGljJm5ic3A7YXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7VXN1YWxseSBhcyB0aGUgZHJhZnQgYXBwbGljYWJpbGl0 eSBzdGF0ZW1lbnQmbmJzcDtoYXMgYWNjZXB0ZWQgdGhlJm5ic3A7Z2VuZXJhbCBwdXJwb3NlIHNj ZW5hcmlvLCBzbyZuYnNwO3RoZSZuYnNwO0EtQiBsaW5rJm5ic3A7ZnJlcXVlbmN5Jm5ic3A7Y2hh bm5lbCBtb3N0bHkmbmJzcDtzaW1pbGFyIHRvIHRoZSBCLUMgZnJlcXVlbmN5Jm5ic3A7Y2hhbm5l bCBzbyBib3RoIGxpbmtzJm5ic3A7Y2FuIGhhdmUgaGlnaCBjb3JyZWxhdGlvbiBvZiBsaW5rJm5i c3A7cXVhbGl0eSBjaGFuZ2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFCPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKjxicj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBs ZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJy PgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRp c2Nsb3NlIG9yPGJyPgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u Ljxicj4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKio8L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D20348GLKXM0002VGREEN_-- From nobody Mon Aug 11 03: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 B35901A03E8 for ; Mon, 11 Aug 2014 03:21:40 -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 goIyfQ6GbUEp for ; Mon, 11 Aug 2014 03:21:39 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AD11A03D7 for ; Mon, 11 Aug 2014 03:21:39 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x3so1367844qcv.37 for ; Mon, 11 Aug 2014 03:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0fg8ohY2FhT5BhtJVBay4boTIpSwMuTUSLWY4rIm33g=; b=j2f8F5aO7cL1yjDhz0z6xhbZ8SmFI+eSZC4DxP6mWQaKPiA8siZdtH0W4guDDUL6Gk rIZOvEAvAKsBQa4QC8cup8coPxPxJj+VdcmCeZ1uOX1CQ3p/KKi8b1TcDDtwj0V3QdBH qHJnNMKfDhqpyrGpTTTb0MwIDwd+V7L8Pm2sPHU2aSqxwPAYuuYl1FuAHp35H9gWNniu Q1Kq1sOvG9bf9POarI5Wllf23t2fGNHvNYl6Bg/B9BVT95Ki/M1CbkKKEvedPaQj0EUb nHDLkDaAh/hlWjYGWbVFJpRweCQYR9ls3CkrdF3iaqvzzejdVJiVohbfWJpljo02F1rn hOHQ== X-Received: by 10.229.178.202 with SMTP id bn10mr61054935qcb.6.1407752498470; Mon, 11 Aug 2014 03:21:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.149.66 with HTTP; Mon, 11 Aug 2014 03:21:18 -0700 (PDT) In-Reply-To: References: <20140811085415.15019.55631.idtracker@ietfa.amsl.com> <53E88519.9070606@fkie.fraunhofer.de> From: Henning Rogge Date: Mon, 11 Aug 2014 12:21:18 +0200 Message-ID: To: Jiazi YI Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Lj1KQiLIHL3ALYz49n1iiacAktc Cc: "manet@ietf.org" Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-01.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: Mon, 11 Aug 2014 10:21:41 -0000 On Mon, Aug 11, 2014 at 12:03 PM, Jiazi YI wrote: > Hi Henning, > > I took a quick look at the draft. Thank you. > The first question I would like to ask is: > what's the assumption of the "dual track" model you use here? > You assume two independent IPv4/IPv6 implementations are running on each > router? Or "a single combined implementation for both IP address types"? -- See Section 3 and Section 7.2 You could actually implement this draft for both, but its easier if you have a single implementation because both have to talk to each other. > I actually don't know what how the latter works. My own implementation does exactly do this... single implementation for both IPv4 and IPv6. > If I remember correctly, a > NHDP router will regard message with different address length as "invalid". Because NHDP Hello messages have no hoplimit/hoplimit=1 they will not be aggregated into the "wrong" RFC5444/UDP packet anyways. For something running "on top of" NHDP (e.g. OLSRv2), you need to channel incoming 4-byte address length message to the right processing chain, even if they come in a IPv6 UDP packet. Henning Rogge From nobody Mon Aug 11 03:37: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 911821A0456 for ; Mon, 11 Aug 2014 03:37:35 -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 mWC3DEA_8Il4 for ; Mon, 11 Aug 2014 03:37:34 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B091A0453 for ; Mon, 11 Aug 2014 03:37:34 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so8406468wes.34 for ; Mon, 11 Aug 2014 03:37:32 -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=kioWC4JXXLfW+QzpGdyNfgLW/sQ/lQJW8DYOJ8wg8Ko=; b=yb3cnmozKeRliNeH8opsS+v9eyzgCTq/Wch5LVx6of9+sWtkUQ6ag2tNXTsy60fyAV IRSEijSr2IvhLdiKnteMquU6w9Rnb67MGAQ56PhEQc9akaVhmWmCad+WnHDWy08zACr0 pE8hgmv2+aG+nK4ni91T4h3vYIK7z7CjAjwl04Q0sFclITSYN6GyfrasrPsXB4dzbpS2 H3qxxZ/JdPCgSsUwTxbvnzpj04m4FU6qM6zzeclsrhHKLWHXduVvP83sj7HWHI2X+YGg ZsqySkOQns0OBxWHQ7ZbtTexDKZXWYFvVUQI8Kz9M8erNgZ2iQhxvivVZrjS3VUuabgF rVIA== MIME-Version: 1.0 X-Received: by 10.180.149.161 with SMTP id ub1mr24792099wib.32.1407753452708; Mon, 11 Aug 2014 03:37:32 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Mon, 11 Aug 2014 03:37:32 -0700 (PDT) In-Reply-To: References: <20140811085415.15019.55631.idtracker@ietfa.amsl.com> <53E88519.9070606@fkie.fraunhofer.de> Date: Mon, 11 Aug 2014 12:37:32 +0200 X-Google-Sender-Auth: EcG_h7mzcdilCmufG3E4SxvS4Ko Message-ID: From: Jiazi YI To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c37e567ae9aa050058248b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UmVwReo-59Is96AtaQd7E-fFuFs Cc: "manet@ietf.org" Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-01.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: Mon, 11 Aug 2014 10:37:35 -0000 --001a11c37e567ae9aa050058248b Content-Type: text/plain; charset=UTF-8 Hi, I noticed that you mentioned both (independent/combined) in the applicability statement. But as the IPv4/IPv6 combined implementation is not standard, and "communications" are required for independent implementations, I suppose more details need to be elaborated for each of them? For example, what kind of communications are required? Do they need to share some configurations? I think it's important to have interoperable implementations. best Jiazi On Mon, Aug 11, 2014 at 12:21 PM, Henning Rogge wrote: > On Mon, Aug 11, 2014 at 12:03 PM, Jiazi YI wrote: > > Hi Henning, > > > > I took a quick look at the draft. > Thank you. > > > The first question I would like to ask is: > > what's the assumption of the "dual track" model you use here? > > You assume two independent IPv4/IPv6 implementations are running on each > > router? Or "a single combined implementation for both IP address types"? > -- > > See Section 3 and Section 7.2 > > You could actually implement this draft for both, but its easier if > you have a single implementation because both have to talk to each > other. > > > I actually don't know what how the latter works. > > My own implementation does exactly do this... single implementation > for both IPv4 and IPv6. > > > If I remember correctly, a > > NHDP router will regard message with different address length as > "invalid". > > Because NHDP Hello messages have no hoplimit/hoplimit=1 they will not > be aggregated into the "wrong" RFC5444/UDP packet anyways. > > For something running "on top of" NHDP (e.g. OLSRv2), you need to > channel incoming 4-byte address length message to the right processing > chain, even if they come in a IPv6 UDP packet. > > Henning Rogge > --001a11c37e567ae9aa050058248b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I noticed that you mentioned = both (independent/combined) in the applicability statement.=C2=A0
But as the IPv4/IPv6 combined implementation is not standard, and "co= mmunications" are required for independent implementations, I suppose = more details need to be elaborated for each of them? For example, what kind= of communications are required? Do they need to share some configurations?= =C2=A0
I think it's important to have interoperable implementations.=C2= =A0

best

Jiazi


On Mon, Aug = 11, 2014 at 12:21 PM, Henning Rogge <hrogge@gmail.com> wrote:=
On Mon, Aug 11, 2014 at 12:0= 3 PM, Jiazi YI <ietf@jiaziyi.com= > wrote:
> Hi Henning,
>
> I took a quick look at the draft.
Thank you.

> The first question I would like to ask is:
> what's the assumption of the "dual track" model you use = here?
> You assume two independent IPv4/IPv6 implementations are running on ea= ch
> router? Or "a single combined implementation for both IP address = types"? --

See Section 3 and Section 7.2

You could actually implement this draft for both, but its easier if
you have a single implementation because both have to talk to each
other.

> I actually don't know what how the latter works.

My own implementation does exactly do this... single implementation for both IPv4 and IPv6.

> If I remember correctly, a
> NHDP router will regard message with different address length as "= ;invalid".

Because NHDP Hello messages have no hoplimit/hoplimit=3D1 they will n= ot
be aggregated into the "wrong" RFC5444/UDP packet anyways.

For something running "on top of" NHDP (e.g. OLSRv2), you need to=
channel incoming 4-byte address length message to the right processing
chain, even if they come in a IPv6 UDP packet.

Henning Rogge

--001a11c37e567ae9aa050058248b-- From nobody Mon Aug 11 03:47: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 6ECD21A044F for ; Mon, 11 Aug 2014 03:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 dmKvrXzOUrt3 for ; Mon, 11 Aug 2014 03:47:38 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A8E1A0418 for ; Mon, 11 Aug 2014 03:47:38 -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 1XGn8a-0004TM-NZ; Mon, 11 Aug 2014 12:47:36 +0200 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 1XGn8a-0002aT-Js; Mon, 11 Aug 2014 12:47:36 +0200 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; Mon, 11 Aug 2014 12:47:36 +0200 Message-ID: <53E89F44.1010700@fkie.fraunhofer.de> Date: Mon, 11 Aug 2014 12:47:32 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Jiazi YI , Henning Rogge References: <20140811085415.15019.55631.idtracker@ietfa.amsl.com> <53E88519.9070606@fkie.fraunhofer.de> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010103040400070202050200" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19276/Mon Aug 11 06:30:28 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: a8bb361c08068357dcb389a69381f4e8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5gtB58yuCijamR_t6pbZyVW8RBo Cc: "manet@ietf.org" Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-01.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: Mon, 11 Aug 2014 10:47:40 -0000 --------------ms010103040400070202050200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/11/2014 12:37 PM, Jiazi YI wrote: > Hi,=20 >=20 > I noticed that you mentioned both (independent/combined) in the > applicability statement.=20 > But as the IPv4/IPv6 combined implementation is not standard, I do not agree completely... I have written such a combined implementation and a different "ipv4 only" or "ipv6 only" implementation would not even notice the difference. In fact, the only thing that would be different is the presence of the Message TLV inside the IPv6 Hello messages. > and > "communications" are required for independent implementations, I suppos= e > more details need to be elaborated for each of them? For example, what > kind of communications are required? Do they need to share some > configurations?=20 I do NOT plan to describe this communication, because I consider this as an implementation detail. I don't think you should ever try to combine two different implementations (one IPv4, the other IPv6) on a local node AND try to get this optimization running. So "NRL OLSRv2 IPv4" and "NRL OLSRv2 IPv6" could be upgraded to "pair of NRL OLSRv2 with internal communication for dualstack optimization". But not "NRL OLSRv2 IPv4" and "XYZ OLSRv2 IPv6". > I think it's important to have interoperable implementations. Interoperability is only between routers... As long as the single combined implementation (or the communicating pair of implementations) behave like the draft suggests, they should be interoperable to all existing implementations running on different routers, might they be IPv4 only, IPv6 only or both (without dualstack optimization). Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010103040400070202050200 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 Fw0xNDA4MTExMDQ3MzVaMCMGCSqGSIb3DQEJBDEWBBRhJtQPziel3zsiEEa6IDn6y60AbzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAivucKPsM59Weuacr++ULAi0oEx7rnMWObGcRWIv5R2xb ciK5Q0Gh6+MM+Acy+m4hbo4IrBgzxbCOxEveeDLvrO0Vyl8BJGNIZQ0RKutB+L5txn17fGAa wIzT1wIDm7efpy9rDeCx5uVM51gI2dsD92rqgYuV+8ImefDIo6iHCk/D2tAU9pN6n3fOLVXC TSz7hEDbWagpSr9iIu5PtA7f0un/iBHRnssUXfYd3CQ61bBflCysOQZtaVTeBVoHASav3Yy+ 9f7dRoCGdJFi9myH4ABXSWTwmwyxVl8bU9+p9kFMSWiCDW1I+Px1AbnHNY4aGobZH0/G0PLx YXk/90SIRQAAAAAAAA== --------------ms010103040400070202050200-- From nobody Mon Aug 11 04:18: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 CEBB51A0407 for ; Mon, 11 Aug 2014 04:18:03 -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 1jH801qlsh59 for ; Mon, 11 Aug 2014 04:18:02 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96731A03F9 for ; Mon, 11 Aug 2014 04:18:01 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so8271207wgg.28 for ; Mon, 11 Aug 2014 04:18:00 -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=TjRnOBEoB75vIxtSbnL6f+93BFLse1bArKgfRnopcts=; b=B+4IwkVOmKinZMUZb23wNiM+PMmDaX4dYYir3gQd+av1Kzi4du+P71c4na/bqPCSSe 3ntgLXHEkZilAOC2NRrdmHdkGuXvBtNhOR/05V1CBl7Na+DSrjei0UCxir63nmVZUfXW lgDQ0PqJjTcB7hTUPKxhAZuBa/ZS+yVCikSGil/EnLf4QPVeWHML2zNJ5wgCFMdoeAi+ iqPxdjQwiA8XcZ8lm16glwy64BGSTKuEPn3o5rW1nViGC41mteYhXzLbqN+AoYEjt4Ak mekQgrPL+K9/FKwq1oATDTYYwPv5F1M/LrQATExw57ATK5r8G8Q0mcheZa8q6NolbWG8 nx1Q== MIME-Version: 1.0 X-Received: by 10.194.237.5 with SMTP id uy5mr26113827wjc.98.1407755880457; Mon, 11 Aug 2014 04:18:00 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Mon, 11 Aug 2014 04:18:00 -0700 (PDT) In-Reply-To: <53E89F44.1010700@fkie.fraunhofer.de> References: <20140811085415.15019.55631.idtracker@ietfa.amsl.com> <53E88519.9070606@fkie.fraunhofer.de> <53E89F44.1010700@fkie.fraunhofer.de> Date: Mon, 11 Aug 2014 13:18:00 +0200 X-Google-Sender-Auth: _FddcpNfYjU0aUiRbFEjl4dIJ-Q Message-ID: From: Jiazi YI To: Henning Rogge Content-Type: multipart/alternative; boundary=089e013d1fb42f6af5050058b58e Archived-At: http://mailarchive.ietf.org/arch/msg/manet/av3QAdWe0T6cWaEjO8jUWVpuHgc Cc: "manet@ietf.org" Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-01.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: Mon, 11 Aug 2014 11:18:04 -0000 --089e013d1fb42f6af5050058b58e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi, On Mon, Aug 11, 2014 at 12:47 PM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > On 08/11/2014 12:37 PM, Jiazi YI wrote: > > Hi, > > > > I noticed that you mentioned both (independent/combined) in the > > applicability statement. > > But as the IPv4/IPv6 combined implementation is not standard, > > I do not agree completely... I have written such a combined > implementation and a different "ipv4 only" or "ipv6 only" implementation > would not even notice the difference. In fact, the only thing that would > be different is the presence of the Message TLV inside the IPv6 Hello > messages. > The "combined" implementation you meant here, is that it can run IPv6/IPv4 simultaneously, or it can be configured to run either IPv4, or IPv6? My first understanding was the former one, but I think you actually mean the latter? Jiazi > > > and > > "communications" are required for independent implementations, I suppos= e > > more details need to be elaborated for each of them? For example, what > > kind of communications are required? Do they need to share some > > configurations? > > I do NOT plan to describe this communication, because I consider this as > an implementation detail. I don't think you should ever try to combine > two different implementations (one IPv4, the other IPv6) on a local node > AND try to get this optimization running. > > So "NRL OLSRv2 IPv4" and "NRL OLSRv2 IPv6" could be upgraded to "pair of > NRL OLSRv2 with internal communication for dualstack optimization". > > But not "NRL OLSRv2 IPv4" and "XYZ OLSRv2 IPv6". > > > I think it's important to have interoperable implementations. > > Interoperability is only between routers... As long as the single > combined implementation (or the communicating pair of implementations) > behave like the draft suggests, they should be interoperable to all > existing implementations running on different routers, might they be > IPv4 only, IPv6 only or both (without dualstack optimization). > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > --089e013d1fb42f6af5050058b58e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
hi,


On Mon, Aug 11, 2014 at 12:47 PM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
On 08/11/2014 12:37 PM, Jiaz= i YI wrote:
> Hi,
>
> I noticed that you mentioned both (independent/combined) in the
> applicability statement.
> But as the IPv4/IPv6 combined implementation is not standard,

I do not agree completely... I have written such a combined
implementation and a different "ipv4 only" or "ipv6 only&quo= t; implementation
would not even notice the difference. In fact, the only thing that would be different is the presence of the Message TLV inside the IPv6 Hello
messages.

The "combined" impl= ementation you meant here, is that it can run IPv6/IPv4 simultaneously, or = it can be configured to run either IPv4, or IPv6? My first understanding wa= s the former one, but I think you actually mean the latter?

Jiazi
=C2=A0

> and
> "communications" are required for independent implementation= s, I suppose
> more details need to be elaborated for each of them? For example, what=
> kind of communications are required? Do they need to share some
> configurations?

I do NOT plan to describe this communication, because I consider this= as
an implementation detail. I don't think you should ever try to combine<= br> two different implementations (one IPv4, the other IPv6) on a local node AND try to get this optimization running.

So "NRL OLSRv2 IPv4" and "NRL OLSRv2 IPv6" could be upg= raded to "pair of
NRL OLSRv2 with internal communication for dualstack optimization".
But not "NRL OLSRv2 IPv4" and "XYZ OLSRv2 IPv6".

> I think it's important to have interoperable implementations.

Interoperability is only between routers... As long as the single
combined implementation (or the communicating pair of implementations)
behave like the draft suggests, they should be interoperable to all
existing implementations running on different routers, might they be
IPv4 only, IPv6 only or both (without dualstack optimization).

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany
Telefon +49 = 228 9435-961, =C2=A0 Fax +49 228 9435 685
mailto:henning.rogge@fk= ie.fraunhofer.de http://www.fkie.fraunhofer.de


--089e013d1fb42f6af5050058b58e-- From nobody Mon Aug 11 04:23: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 A3E871A041F for ; Mon, 11 Aug 2014 04:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 uVPpnQYGYxlC for ; Mon, 11 Aug 2014 04:23:14 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1021A0407 for ; Mon, 11 Aug 2014 04:23:14 -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 1XGnh3-0001eM-1e; Mon, 11 Aug 2014 13:23:13 +0200 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 1XGnh2-0002jg-UD; Mon, 11 Aug 2014 13:23:12 +0200 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; Mon, 11 Aug 2014 13:23:12 +0200 Message-ID: <53E8A79A.9080303@fkie.fraunhofer.de> Date: Mon, 11 Aug 2014 13:23:06 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Jiazi YI References: <20140811085415.15019.55631.idtracker@ietfa.amsl.com> <53E88519.9070606@fkie.fraunhofer.de> <53E89F44.1010700@fkie.fraunhofer.de> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030805010306000709020705" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19276/Mon Aug 11 06:30:28 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 71f20a6753145be45d3fd9933e2b2e69 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qJaqc53xSvXcKI-wTRxR2CAZAxI Cc: "manet@ietf.org" Subject: Re: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-01.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: Mon, 11 Aug 2014 11:23:16 -0000 --------------ms030805010306000709020705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/11/2014 01:18 PM, Jiazi YI wrote: > hi, >=20 > On Mon, Aug 11, 2014 at 12:47 PM, Henning Rogge > > wrote: > I do not agree completely... I have written such a combined > implementation and a different "ipv4 only" or "ipv6 only" implement= ation > would not even notice the difference. In fact, the only thing that = would > be different is the presence of the Message TLV inside the IPv6 Hel= lo > messages. >=20 >=20 > The "combined" implementation you meant here, is that it can run > IPv6/IPv4 simultaneously, or it can be configured to run either IPv4, o= r > IPv6? My first understanding was the former one, but I think you > actually mean the latter? All of them. I can run my implementation in "IPv4 only" mode... I can run it as "IPv6 only"... and I can run it so it opens sockets for both IPv4 and IPv6 and does the job for both. In the third mode it also handles the dualstack optimization. In all three cases its just a single program running. I have also tested it to run TWO versions of my program, one configured for "IPv4 only" and one for "IPv6 only". The difference is just the configuration. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030805010306000709020705 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 Fw0xNDA4MTExMTIzMTFaMCMGCSqGSIb3DQEJBDEWBBR+DiNggGr4J2sgn6vGPnyuLkmPiDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEArhTuUDZUW49QI+m1eKHm5KKI1R6lq6QcdSZ9VIyu+ovd oXN8PfmQWT1eLDahEMwUkZhban5PmZJ5HC01rS/5ofZFsPyMJsq4/mjMV0LcDsUvSwM5OXBT nGBNhh4RMlnKbTnS8xtl2dlsXUqvlSRHavZm3aJRxB3eK7dUma06heP8YXv8bgm86ZlnvAw1 X+3CODCC4EzQaw04GkaPeEWbtSBebQuoxnuAiK3D0U2bzZxUymw21cqh6hlirJujR9KkWCYg C0ASU7gtob0IHF6uKSNotN4zWu9k7e4cflNPx3bp6DIeC9iJhV/dwhwoeEupAV9XhxJkzGdP vQvI7X+W5gAAAAAAAA== --------------ms030805010306000709020705-- From nobody Mon Aug 11 04:27: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 CBDDB1A0458 for ; Mon, 11 Aug 2014 04:27:45 -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 cl1nIHfNO5lH for ; Mon, 11 Aug 2014 04:27:44 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5D61A0407 for ; Mon, 11 Aug 2014 04:27:44 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id b6so6149003yha.14 for ; Mon, 11 Aug 2014 04:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lBsyvZDg2xO+YhQrTgvMD74aQO/MHtRBG376qM7kFfI=; b=ZCwWQgwyYKNcZ7aITxbI+Y+IWokVR7tyzWUQt7QCMKZEGIA4AMTwZkYazwOG8hc0SK /cD56NAZ7wE10WOxj5BnLVBR7E6HST9iBT4k21j0Bq+QGneQZCQl8kjBcZGHRGslliLR kjKYti65ZQ+ZTLQMRZA+9SzweWSgDp3gwcbR0jY1ANK0JY6kVqVyjRHE38ql3WXTwNYA 2WkbbGsuqqFQFzJRebdAzcb/ddXrZCjG5+NvWWmke3IAKf4C+no2ZYHNhwpgQFLlTOVT LYj8ygUvEFO92NjwVhwrtOJPDPKvK/aBeDfOhK2LeUnl2XGsWL8WZ+TxZA1RXRfrpXHS ZLvQ== MIME-Version: 1.0 X-Received: by 10.236.32.227 with SMTP id o63mr40089312yha.31.1407756463595; Mon, 11 Aug 2014 04:27:43 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Mon, 11 Aug 2014 04:27:43 -0700 (PDT) In-Reply-To: References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> Date: Mon, 11 Aug 2014 13:27:43 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=089e0160b3b8f166ce050058d75d Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JorMl0HxNk1e5Krm79Dd2NA8Ld4 Cc: "manet@ietf.org" , Christopher Dearlove , Thomas Clausen Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 11 Aug 2014 11:27:45 -0000 --089e0160b3b8f166ce050058d75d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, August 11, 2014, Dearlove, Christopher (UK) wrote: > The key words there are =E2=80=9Ccan have=E2=80=9D. Not =E2=80=9Cwill ha= ve=E2=80=9D. > > Yes I used that "can have" because I want to consider the real full possibilities, so we not trying to make the problem but we consider it in our draft. so I think you agree with the word I used. > > > And even then you weren=E2=80=99t consistent, you assume B-C went down wh= en A-B > did, but not that B-C went up when A-B did. This may be considered > attempting to have your cake and eat it, if the cake is finding a problem= . > (I=E2=80=99m not sure why you are trying hard to find a problem no one el= se has, > but that seems to be the case.) > > I think this is the analysis of one possible issue. I did consider that they become up together as well and they may not be together. The key problem that you may missed is that each neighbour node don't need to have same quality level threshold so the becoming up together may not happen with time difference period of when they went down. The examples considers optimization as if each node can have different quality level (I think this is allowed that optimized routers can have different measures). So three factors to consider within the example: the routers (optimizing/normal), the optimized-routers' measures of quality same/different, and the links' frequency of change below threshold. > > > And, as has been said several times, if you have a scenario with a > problem, just don=E2=80=99t use it. > > Or we can find a way to amend the draft to consider such situation/condition and solve it. > > > (Similarly if you have a scenario where it is pointless, you can decide > not to use it. An example there could be a heavily damped link quality th= at > if it goes down can=E2=80=99t come back up in less than REFRESH_INTERVAL = time. It > won=E2=80=99t do any harm =E2=80=93 except a trivial amount of storage an= d processing =E2=80=93 but > it won=E2=80=99t do much good either.) > > The optimization is working to improve for the time below the refresh interval. So my example is about times below that time. The draft mentions that the optimization is used to improve when there are temporary short quality changes. IMHO it only considers one link failure, which is A-B the first hop (I suggest to mention that in the applicability statement). what about if both neighbor hops get considered changed by optimize-routers of the routing path. AB > > > -- > > > --089e0160b3b8f166ce050058d75d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, August 11, 2014, Dearlove, Christopher (UK) wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

The key words there are = =E2=80=9Ccan have=E2=80=9D. Not =E2=80=9Cwill have=E2=80=9D.<= /span>

Yes I used=C2=A0that "can have" bec= ause I want to consider the real full possibilities, so we=C2=A0not trying = to make the problem but we=C2=A0consider it in our draft.=C2=A0so I think= =C2=A0you agree with the word I=C2=A0used.=C2=A0=C2=A0

=C2=A0

And even then you weren= =E2=80=99t consistent, you assume B-C went down when A-B did, but not that = B-C went up when A-B did. This may be considered attempting to have your cake and eat it, if the cake is finding a problem. (I=E2=80=99m not s= ure why you are trying hard to find a problem no one else has, but that see= ms to be the case.)

I think this is the analysis of one possible issue. I did= consider that they become up together as well and they may not be together= . The key problem that you may missed is that each neighbour node don't= need to have same quality level=C2=A0threshold=C2=A0so the becoming up tog= ether may not happen with=C2=A0time difference=C2=A0period of when they wen= t down. The examples considers optimization as if each node can have differ= ent quality level (I think this is allowed that optimized routers can have = different measures). So three=C2=A0factors to consider within the example:= =C2=A0the routers (optimizing/normal), the optimized-routers'=C2=A0meas= ures of quality same/different, and the links' frequency of change belo= w threshold.=C2=A0

=C2=A0

And, as has been said sev= eral times, if you have a scenario with a problem, just don=E2=80=99t use i= t.

Or we can find a w= ay to amend the draft to consider such situation/condition and solve it.=C2= =A0=C2=A0

=C2=A0

(Similarly if you have a = scenario where it is pointless, you can decide not to use it. An example th= ere could be a heavily damped link quality that if it goes down can=E2=80=99t come back up in less than REFRESH_INTERVAL time. It won= =E2=80=99t do any harm =E2=80=93 except a trivial amount of storage and pro= cessing =E2=80=93 but it won=E2=80=99t do much good either.)<= /span>


The optimization is working to= improve=C2=A0for the time below the=C2=A0refresh interval. So my example i= s about times=C2=A0below that time. The=C2=A0draft mentions=C2=A0that the o= ptimization is used to improve when there are temporary short quality chang= es. IMHO it=C2=A0only considers one link failure,=C2=A0which is A-B the fir= st hop (I suggest to mention that in the applicability statement).=C2=A0wha= t about if both neighbor=C2=A0hops get considered changed by optimize-route= rs of the routing=C2=A0path.=C2=A0

AB

=C2=A0

--


--089e0160b3b8f166ce050058d75d-- From nobody Mon Aug 11 05:10: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 95A081A066D for ; Mon, 11 Aug 2014 05:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 NpZAofGlQXna for ; Mon, 11 Aug 2014 05:10:38 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B471A067D for ; Mon, 11 Aug 2014 05:10:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,841,1400022000"; d="scan'208,217";a="467197120" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 11 Aug 2014 13:10:30 +0100 X-IronPort-AV: E=Sophos; i="5.01,841,1400022000"; d="scan'208,217"; a="61527933" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 11 Aug 2014 13:10:46 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Mon, 11 Aug 2014 13:10:46 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change Thread-Index: AQHPtIU24If+JKsjMkmNfqDgEX2L75vJqzsAgAA4e4CAAAXkAIABNPAAgAASK5CAAAQFgIAAGxkQ Date: Mon, 11 Aug 2014 12:10:45 +0000 Message-ID: References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D203F5GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Eo3O-WcSQPbhztwuFP27usy0tro Cc: "manet@ietf.org" , Christopher Dearlove , Thomas Clausen Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 11 Aug 2014 12:10:45 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D203F5GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGhlcmUgaXMgbm8gbmVlZCAob3IgZXZlbiBhZHZhbnRhZ2UpIHRvIGNoYW5nZSAoYW1lbmRpbmcg c3VnZ2VzdHMgYSBwcm9ibGVtLCB3aGljaCB0aGVyZSBpc27igJl0KSB0aGUgZHJhZnQgYmFzZWQg b24gYW55dGhpbmcgeW91IGhhdmUgcG9zdGVkLg0KDQpUaGVyZSBpc27igJl0IGV2ZW4gYW55dGhp bmcgdGhhdCBjb3VsZCBiZSBjaGFuZ2VkIGJlY2F1c2UsIGFuZCBsZXTigJlzIHNheSBpdCBhZ2Fp biwgbGluayBxdWFsaXR5IGluZm9ybWF0aW9uIGlzIG5vdCBjb21tdW5pY2F0ZWQuIEluIGFkZGl0 aW9uIHR3byBob3AgaW5mb3JtYXRpb24gaXMgbm90IGNvbW11bmljYXRlZCAob25seSBvbmUgaG9w IGluZm9ybWF0aW9uIHRoYXQgYmVjb21lcyB0d28gaG9wIGluZm9ybWF0aW9uLCBidXQgaXTigJlz IGFib3V0IGl0IGFzIHR3byBob3AgaW5mb3JtYXRpb24gdGhhdCB0aGlzIGFwcGxpZXMpLg0KDQot LQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9y bWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFn ZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENl bnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBD TTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTQgfCAgRmF4OiArNDQgMTI0NSAyNDIxMjQN CmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbT4gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIChP cGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8g Qm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMs IEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5OTY2ODcN Cg0KRnJvbTogQWJkdXNzYWxhbSBCYXJ5dW4gW21haWx0bzphYmR1c3NhbGFtYmFyeXVuQGdtYWls LmNvbV0NClNlbnQ6IDExIEF1Z3VzdCAyMDE0IDEyOjI4DQpUbzogRGVhcmxvdmUsIENocmlzdG9w aGVyIChVSykNCkNjOiBUaG9tYXMgQ2xhdXNlbjsgQ2hyaXN0b3BoZXIgRGVhcmxvdmU7IG1hbmV0 QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSAjNTEgKG5oZHAtb3B0aW1pemF0aW9uKTog QW5hbHlzaXMgb2YgT0xTUnYyL05IRFAtb3B0aW1pemVkIEhhbmRsaW5nIG5laWdoYm9yIGNvbm5l Y3Rpb24gd2l0aCBsaW5rIHF1YWxpdHkgY2hhbmdlDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlz IG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVy IGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJl ZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0 YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0 aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVy ZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVt YWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRy YW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9j dW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KDQoNCk9u IE1vbmRheSwgQXVndXN0IDExLCAyMDE0LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90 ZToNClRoZSBrZXkgd29yZHMgdGhlcmUgYXJlIOKAnGNhbiBoYXZl4oCdLiBOb3Qg4oCcd2lsbCBo YXZl4oCdLg0KWWVzIEkgdXNlZCB0aGF0ICJjYW4gaGF2ZSIgYmVjYXVzZSBJIHdhbnQgdG8gY29u c2lkZXIgdGhlIHJlYWwgZnVsbCBwb3NzaWJpbGl0aWVzLCBzbyB3ZSBub3QgdHJ5aW5nIHRvIG1h a2UgdGhlIHByb2JsZW0gYnV0IHdlIGNvbnNpZGVyIGl0IGluIG91ciBkcmFmdC4gc28gSSB0aGlu ayB5b3UgYWdyZWUgd2l0aCB0aGUgd29yZCBJIHVzZWQuDQoNCkFuZCBldmVuIHRoZW4geW91IHdl cmVu4oCZdCBjb25zaXN0ZW50LCB5b3UgYXNzdW1lIEItQyB3ZW50IGRvd24gd2hlbiBBLUIgZGlk LCBidXQgbm90IHRoYXQgQi1DIHdlbnQgdXAgd2hlbiBBLUIgZGlkLiBUaGlzIG1heSBiZSBjb25z aWRlcmVkIGF0dGVtcHRpbmcgdG8gaGF2ZSB5b3VyIGNha2UgYW5kIGVhdCBpdCwgaWYgdGhlIGNh a2UgaXMgZmluZGluZyBhIHByb2JsZW0uIChJ4oCZbSBub3Qgc3VyZSB3aHkgeW91IGFyZSB0cnlp bmcgaGFyZCB0byBmaW5kIGEgcHJvYmxlbSBubyBvbmUgZWxzZSBoYXMsIGJ1dCB0aGF0IHNlZW1z IHRvIGJlIHRoZSBjYXNlLikNCkkgdGhpbmsgdGhpcyBpcyB0aGUgYW5hbHlzaXMgb2Ygb25lIHBv c3NpYmxlIGlzc3VlLiBJIGRpZCBjb25zaWRlciB0aGF0IHRoZXkgYmVjb21lIHVwIHRvZ2V0aGVy IGFzIHdlbGwgYW5kIHRoZXkgbWF5IG5vdCBiZSB0b2dldGhlci4gVGhlIGtleSBwcm9ibGVtIHRo YXQgeW91IG1heSBtaXNzZWQgaXMgdGhhdCBlYWNoIG5laWdoYm91ciBub2RlIGRvbid0IG5lZWQg dG8gaGF2ZSBzYW1lIHF1YWxpdHkgbGV2ZWwgdGhyZXNob2xkIHNvIHRoZSBiZWNvbWluZyB1cCB0 b2dldGhlciBtYXkgbm90IGhhcHBlbiB3aXRoIHRpbWUgZGlmZmVyZW5jZSBwZXJpb2Qgb2Ygd2hl biB0aGV5IHdlbnQgZG93bi4gVGhlIGV4YW1wbGVzIGNvbnNpZGVycyBvcHRpbWl6YXRpb24gYXMg aWYgZWFjaCBub2RlIGNhbiBoYXZlIGRpZmZlcmVudCBxdWFsaXR5IGxldmVsIChJIHRoaW5rIHRo aXMgaXMgYWxsb3dlZCB0aGF0IG9wdGltaXplZCByb3V0ZXJzIGNhbiBoYXZlIGRpZmZlcmVudCBt ZWFzdXJlcykuIFNvIHRocmVlIGZhY3RvcnMgdG8gY29uc2lkZXIgd2l0aGluIHRoZSBleGFtcGxl OiB0aGUgcm91dGVycyAob3B0aW1pemluZy9ub3JtYWwpLCB0aGUgb3B0aW1pemVkLXJvdXRlcnMn IG1lYXN1cmVzIG9mIHF1YWxpdHkgc2FtZS9kaWZmZXJlbnQsIGFuZCB0aGUgbGlua3MnIGZyZXF1 ZW5jeSBvZiBjaGFuZ2UgYmVsb3cgdGhyZXNob2xkLg0KDQpBbmQsIGFzIGhhcyBiZWVuIHNhaWQg c2V2ZXJhbCB0aW1lcywgaWYgeW91IGhhdmUgYSBzY2VuYXJpbyB3aXRoIGEgcHJvYmxlbSwganVz dCBkb27igJl0IHVzZSBpdC4NCk9yIHdlIGNhbiBmaW5kIGEgd2F5IHRvIGFtZW5kIHRoZSBkcmFm dCB0byBjb25zaWRlciBzdWNoIHNpdHVhdGlvbi9jb25kaXRpb24gYW5kIHNvbHZlIGl0Lg0KDQoo U2ltaWxhcmx5IGlmIHlvdSBoYXZlIGEgc2NlbmFyaW8gd2hlcmUgaXQgaXMgcG9pbnRsZXNzLCB5 b3UgY2FuIGRlY2lkZSBub3QgdG8gdXNlIGl0LiBBbiBleGFtcGxlIHRoZXJlIGNvdWxkIGJlIGEg aGVhdmlseSBkYW1wZWQgbGluayBxdWFsaXR5IHRoYXQgaWYgaXQgZ29lcyBkb3duIGNhbuKAmXQg Y29tZSBiYWNrIHVwIGluIGxlc3MgdGhhbiBSRUZSRVNIX0lOVEVSVkFMIHRpbWUuIEl0IHdvbuKA mXQgZG8gYW55IGhhcm0g4oCTIGV4Y2VwdCBhIHRyaXZpYWwgYW1vdW50IG9mIHN0b3JhZ2UgYW5k IHByb2Nlc3Npbmcg4oCTIGJ1dCBpdCB3b27igJl0IGRvIG11Y2ggZ29vZCBlaXRoZXIuKQ0KDQpU aGUgb3B0aW1pemF0aW9uIGlzIHdvcmtpbmcgdG8gaW1wcm92ZSBmb3IgdGhlIHRpbWUgYmVsb3cg dGhlIHJlZnJlc2ggaW50ZXJ2YWwuIFNvIG15IGV4YW1wbGUgaXMgYWJvdXQgdGltZXMgYmVsb3cg dGhhdCB0aW1lLiBUaGUgZHJhZnQgbWVudGlvbnMgdGhhdCB0aGUgb3B0aW1pemF0aW9uIGlzIHVz ZWQgdG8gaW1wcm92ZSB3aGVuIHRoZXJlIGFyZSB0ZW1wb3Jhcnkgc2hvcnQgcXVhbGl0eSBjaGFu Z2VzLiBJTUhPIGl0IG9ubHkgY29uc2lkZXJzIG9uZSBsaW5rIGZhaWx1cmUsIHdoaWNoIGlzIEEt QiB0aGUgZmlyc3QgaG9wIChJIHN1Z2dlc3QgdG8gbWVudGlvbiB0aGF0IGluIHRoZSBhcHBsaWNh YmlsaXR5IHN0YXRlbWVudCkuIHdoYXQgYWJvdXQgaWYgYm90aCBuZWlnaGJvciBob3BzIGdldCBj b25zaWRlcmVkIGNoYW5nZWQgYnkgb3B0aW1pemUtcm91dGVycyBvZiB0aGUgcm91dGluZyBwYXRo Lg0KDQpBQg0KDQotLQ0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBs ZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllv dSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xv c2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioK --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D203F5GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIG5vIG5lZWQgKG9yIGV2ZW4gYWR2YW50YWdl KSB0byBjaGFuZ2UgKGFtZW5kaW5nIHN1Z2dlc3RzIGEgcHJvYmxlbSwgd2hpY2ggdGhlcmUgaXNu 4oCZdCkgdGhlIGRyYWZ0IGJhc2VkIG9uIGFueXRoaW5nIHlvdSBoYXZlIHBvc3RlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoZXJlIGlzbuKAmXQgZXZlbiBhbnl0aGluZyB0aGF0IGNvdWxkIGJlIGNoYW5nZWQgYmVj YXVzZSwgYW5kIGxldOKAmXMgc2F5IGl0IGFnYWluLCBsaW5rIHF1YWxpdHkgaW5mb3JtYXRpb24g aXMgbm90IGNvbW11bmljYXRlZC4gSW4gYWRkaXRpb24gdHdvIGhvcCBpbmZvcm1hdGlvbg0KIGlz IG5vdCBjb21tdW5pY2F0ZWQgKG9ubHkgb25lIGhvcCBpbmZvcm1hdGlvbiB0aGF0IGJlY29tZXMg dHdvIGhvcCBpbmZvcm1hdGlvbiwgYnV0IGl04oCZcyBhYm91dCBpdCBhcyB0d28gaG9wIGluZm9y bWF0aW9uIHRoYXQgdGhpcyBhcHBsaWVzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVl ciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwPGJyPg0KQ29tbXVuaWNhdGlvbnMsIE5ldHdv cmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5PGJyPg0KQkFFIFN5c3RlbXMgQWR2YW5j ZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+DQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBC YWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLPGJyPg0KVGVsOiAmIzQzOzQ0IDEyNDUgMjQy MTk0Jm5ic3A7fCZuYnNwOyBGYXg6ICYjNDM7NDQgMTI0NSAyNDIxMjQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0ibWFpbHRv OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3Nw YW4+PC9hPg0KIHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbTxicj4NCjxicj4NCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+QkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQ8YnI+DQpSZWdpc3Rl cmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3Bh Y2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSzxicj4NClJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMTk5NjY4NzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBYmR1c3Nh bGFtIEJhcnl1biBbbWFpbHRvOmFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IDExIEF1Z3VzdCAyMDE0IDEyOjI4PGJyPg0KPGI+VG86PC9iPiBEZWFybG92ZSwg Q2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4gVGhvbWFzIENsYXVzZW47IENocmlzdG9w aGVyIERlYXJsb3ZlOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21h bmV0XSAjNTEgKG5oZHAtb3B0aW1pemF0aW9uKTogQW5hbHlzaXMgb2YgT0xTUnYyL05IRFAtb3B0 aW1pemVkIEhhbmRsaW5nIG5laWdoYm9yIGNvbm5lY3Rpb24gd2l0aCBsaW5rIHF1YWxpdHkgY2hh bmdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGlu ZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7 YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMz OTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdp bmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVy bmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBj YXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkg YXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3Ig aW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9p Pjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0 aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8 YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1 cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9z cGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+ DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVh c2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hv d3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1 c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9z cGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQpPbiBNb25kYXksIEF1Z3VzdCAxMSwgMjAxNCwgRGVhcmxvdmUsIENocmlzdG9waGVy IChVSykgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBr ZXkgd29yZHMgdGhlcmUgYXJlIOKAnGNhbiBoYXZl4oCdLiBOb3Qg4oCcd2lsbCBoYXZl4oCdLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WWVzIEkgdXNlZCZuYnNwO3RoYXQgJnF1b3Q7Y2FuIGhhdmUmcXVvdDsgYmVjYXVz ZSBJIHdhbnQgdG8gY29uc2lkZXIgdGhlIHJlYWwgZnVsbCBwb3NzaWJpbGl0aWVzLCBzbyB3ZSZu YnNwO25vdCB0cnlpbmcgdG8gbWFrZSB0aGUgcHJvYmxlbSBidXQgd2UmbmJzcDtjb25zaWRlciBp dCBpbiBvdXIgZHJhZnQuJm5ic3A7c28gSSB0aGluayZuYnNwO3lvdSBhZ3JlZSB3aXRoIHRoZSB3 b3JkIEkmbmJzcDt1c2VkLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5BbmQgZXZlbiB0aGVuIHlvdSB3ZXJlbuKAmXQgY29uc2lzdGVudCwgeW91 IGFzc3VtZSBCLUMgd2VudCBkb3duIHdoZW4gQS1CIGRpZCwgYnV0IG5vdCB0aGF0IEItQyB3ZW50 DQogdXAgd2hlbiBBLUIgZGlkLiBUaGlzIG1heSBiZSBjb25zaWRlcmVkIGF0dGVtcHRpbmcgdG8g aGF2ZSB5b3VyIGNha2UgYW5kIGVhdCBpdCwgaWYgdGhlIGNha2UgaXMgZmluZGluZyBhIHByb2Js ZW0uIChJ4oCZbSBub3Qgc3VyZSB3aHkgeW91IGFyZSB0cnlpbmcgaGFyZCB0byBmaW5kIGEgcHJv YmxlbSBubyBvbmUgZWxzZSBoYXMsIGJ1dCB0aGF0IHNlZW1zIHRvIGJlIHRoZSBjYXNlLik8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhpcyBpcyB0aGUgYW5hbHlzaXMgb2Ygb25l IHBvc3NpYmxlIGlzc3VlLiBJIGRpZCBjb25zaWRlciB0aGF0IHRoZXkgYmVjb21lIHVwIHRvZ2V0 aGVyIGFzIHdlbGwgYW5kIHRoZXkgbWF5IG5vdCBiZSB0b2dldGhlci4gVGhlIGtleSBwcm9ibGVt IHRoYXQgeW91IG1heSBtaXNzZWQgaXMgdGhhdCBlYWNoIG5laWdoYm91ciBub2RlIGRvbid0IG5l ZWQgdG8gaGF2ZSBzYW1lIHF1YWxpdHkgbGV2ZWwmbmJzcDt0aHJlc2hvbGQmbmJzcDtzbw0KIHRo ZSBiZWNvbWluZyB1cCB0b2dldGhlciBtYXkgbm90IGhhcHBlbiB3aXRoJm5ic3A7dGltZSBkaWZm ZXJlbmNlJm5ic3A7cGVyaW9kIG9mIHdoZW4gdGhleSB3ZW50IGRvd24uIFRoZSBleGFtcGxlcyBj b25zaWRlcnMgb3B0aW1pemF0aW9uIGFzIGlmIGVhY2ggbm9kZSBjYW4gaGF2ZSBkaWZmZXJlbnQg cXVhbGl0eSBsZXZlbCAoSSB0aGluayB0aGlzIGlzIGFsbG93ZWQgdGhhdCBvcHRpbWl6ZWQgcm91 dGVycyBjYW4gaGF2ZSBkaWZmZXJlbnQgbWVhc3VyZXMpLiBTbw0KIHRocmVlJm5ic3A7ZmFjdG9y cyB0byBjb25zaWRlciB3aXRoaW4gdGhlIGV4YW1wbGU6Jm5ic3A7dGhlIHJvdXRlcnMgKG9wdGlt aXppbmcvbm9ybWFsKSwgdGhlIG9wdGltaXplZC1yb3V0ZXJzJyZuYnNwO21lYXN1cmVzIG9mIHF1 YWxpdHkgc2FtZS9kaWZmZXJlbnQsIGFuZCB0aGUgbGlua3MnIGZyZXF1ZW5jeSBvZiBjaGFuZ2Ug YmVsb3cgdGhyZXNob2xkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5BbmQsIGFzIGhhcyBiZWVuIHNhaWQgc2V2ZXJhbCB0aW1lcywgaWYgeW91IGhhdmUg YSBzY2VuYXJpbyB3aXRoIGEgcHJvYmxlbSwganVzdCBkb27igJl0IHVzZSBpdC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9yIHdlIGNhbiBmaW5kIGEgd2F5IHRvIGFtZW5kIHRoZSBkcmFmdCB0 byBjb25zaWRlciBzdWNoIHNpdHVhdGlvbi9jb25kaXRpb24gYW5kIHNvbHZlIGl0LiZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oU2ltaWxhcmx5 IGlmIHlvdSBoYXZlIGEgc2NlbmFyaW8gd2hlcmUgaXQgaXMgcG9pbnRsZXNzLCB5b3UgY2FuIGRl Y2lkZSBub3QgdG8gdXNlIGl0LiBBbiBleGFtcGxlDQogdGhlcmUgY291bGQgYmUgYSBoZWF2aWx5 IGRhbXBlZCBsaW5rIHF1YWxpdHkgdGhhdCBpZiBpdCBnb2VzIGRvd24gY2Fu4oCZdCBjb21lIGJh Y2sgdXAgaW4gbGVzcyB0aGFuIFJFRlJFU0hfSU5URVJWQUwgdGltZS4gSXQgd29u4oCZdCBkbyBh bnkgaGFybSDigJMgZXhjZXB0IGEgdHJpdmlhbCBhbW91bnQgb2Ygc3RvcmFnZSBhbmQgcHJvY2Vz c2luZyDigJMgYnV0IGl0IHdvbuKAmXQgZG8gbXVjaCBnb29kIGVpdGhlci4pPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBvcHRpbWl6YXRpb24gaXMgd29ya2luZyB0byBpbXByb3ZlJm5i c3A7Zm9yIHRoZSB0aW1lIGJlbG93IHRoZSZuYnNwO3JlZnJlc2ggaW50ZXJ2YWwuIFNvIG15IGV4 YW1wbGUgaXMgYWJvdXQgdGltZXMmbmJzcDtiZWxvdyB0aGF0IHRpbWUuIFRoZSZuYnNwO2RyYWZ0 IG1lbnRpb25zJm5ic3A7dGhhdCB0aGUgb3B0aW1pemF0aW9uIGlzIHVzZWQgdG8gaW1wcm92ZSB3 aGVuIHRoZXJlIGFyZSB0ZW1wb3Jhcnkgc2hvcnQgcXVhbGl0eSBjaGFuZ2VzLiBJTUhPDQogaXQm bmJzcDtvbmx5IGNvbnNpZGVycyBvbmUgbGluayBmYWlsdXJlLCZuYnNwO3doaWNoIGlzIEEtQiB0 aGUgZmlyc3QgaG9wIChJIHN1Z2dlc3QgdG8gbWVudGlvbiB0aGF0IGluIHRoZSBhcHBsaWNhYmls aXR5IHN0YXRlbWVudCkuJm5ic3A7d2hhdCBhYm91dCBpZiBib3RoIG5laWdoYm9yJm5ic3A7aG9w cyBnZXQgY29uc2lkZXJlZCBjaGFuZ2VkIGJ5IG9wdGltaXplLXJvdXRlcnMgb2YgdGhlIHJvdXRp bmcmbmJzcDtwYXRoLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BQjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0t DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwPioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqPGJyPgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0 byB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBp dCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQg bm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+ CmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKjwvcD48L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D203F5GLKXM0002VGREEN_-- From nobody Tue Aug 12 02:38: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 AB2C51A07DD for ; Tue, 12 Aug 2014 02:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 2CE_chyxGJmu for ; Tue, 12 Aug 2014 02:38:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299151A07BB for ; Tue, 12 Aug 2014 02:38:40 -0700 (PDT) Received: from localhost ([::1]:41284 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XH8XK-0007R2-Mv; Tue, 12 Aug 2014 02:38:34 -0700 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: draft-ietf-manet-nhdp-optimization@tools.ietf.org, abdussalambaryun@gmail.com X-Trac-Project: manet Date: Tue, 12 Aug 2014 09:38:34 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/52 Message-ID: <066.0bb22f15b7c74448b0bb3821234ffc46@trac.tools.ietf.org> X-Trac-Ticket-ID: 52 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-nhdp-optimization@tools.ietf.org, abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: chris.dearlove@baesystems.com, t.clausen@computer.org Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Ir6JGk0Wlb6Bkrf0Pt1StoVeqEM Cc: manet@ietf.org Subject: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial issues) 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: Tue, 12 Aug 2014 09:38:41 -0000 #52: Confused paragraph #1 (Editorial issues) The draft states in section 3: This specification updates [RFC6130]. The optimization presented in this specification is simply permissive, as it allows retaining information which otherwise would have been removed, but does not use that information except when it could have been used by [RFC6130]. This can, in some cases, ensure that the symmetric 2-hop neighborhood is more robust against temporary link quality changes, and consequently yield a more stable network. The only other consequence of this optimization is that state for some otherwise expired 2-Hop Tuples may be maintained for longer. Abdussalam Baryun Comment (AB)> the paragraph starts that it updates 6130 which is repeated many times before. The above paragraph has no applicability statement. Please refer here to applicability statements of the updated standards 6130 and 7181, and mention first that their applicability applies for this update proposal. This is to avoid confusion. The draft states in section 3: This specification also updates [RFC7181]. This could be avoided by simply noting that this specification describes how the updates to [RFC6130] may be handled so as to be invisible to any other protocol using it. AB> I think that this proposal update is for only OLSRv2 routers, this is clear from the abstract. However, the above confuses that as separating the update of mentioning visibility of any other protocol. I don't think this update can be used for AODVv2 (if I mistaken please amend the text to avoid confusion). The draft states in section 3: However as it is known that some implementations of [RFC7181] are not independent of the implementation of [RFC6130] that they use, it is useful to indicate the direct impact on [RFC7181]. AB> when you say "it is known", you should mean known by IETF so please refer to that known document/reference otherwise it is only known by some people. IMHO I remember discussing this issue with OLSRv2 authors at IESG last call, I understood from them that OLSRv2 is not independent from RFC6130. Now, let me assume I know there are routers independent of their RFC6130 interface, then this optimisation proposal is mostly updating RFC6130, therefore, the changes recommended by the draft to the 7181 is only a must if there is dependancy, otherwise, please mention that the full changes required is a must even if OLSRv2 is not dependent on 6130. Furthermore, if there are possibility of other protocol other than OLSRv2 routers to use this draft, then mention that clearly and mention that the Must is of all changes of section 4. AB> to avoid confusion if this update is only for OLSRv2 routers then mention that in its title. So the title will add words "for OLSRv2 routers. Best. AB -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-manet-nhdp- abdussalambaryun@gmail.com | optimization@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: nhdp-optimization | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: manet From nobody Tue Aug 12 02:51: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 190B41A07C8 for ; Tue, 12 Aug 2014 02:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 rUSH9Ccr7nLh for ; Tue, 12 Aug 2014 02:51:28 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0E71A03A2 for ; Tue, 12 Aug 2014 02:51:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,848,1400022000"; d="scan'208";a="395135588" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 12 Aug 2014 10:51:12 +0100 X-IronPort-AV: E=Sophos;i="5.01,848,1400022000"; d="scan'208";a="69181897" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 12 Aug 2014 10:51:28 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Tue, 12 Aug 2014 10:51:28 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" , "draft-ietf-manet-nhdp-optimization@tools.ietf.org" , "abdussalambaryun@gmail.com" Thread-Topic: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial issues) Thread-Index: AQHPthE/YX2SR9vCC0ebmGQra7VFqJvMttRQ Date: Tue, 12 Aug 2014 09:51:27 +0000 Message-ID: References: <066.0bb22f15b7c74448b0bb3821234ffc46@trac.tools.ietf.org> In-Reply-To: <066.0bb22f15b7c74448b0bb3821234ffc46@trac.tools.ietf.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="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kDZZFCw6tdUpuxy9AHhF9EOM4jA Subject: Re: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial 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: Tue, 12 Aug 2014 09:51:30 -0000 Q29tbWVudHMgYmVsb3cuIENNRC4NCg0KLS0gDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9y IFByaW5jaXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwDQpDb21tdW5p Y2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0 ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBH cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5 NMKgfCAgRmF4OiArNDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t IHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykg TGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFy bmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwg VUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtYW5ldCBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJh YyttYW5ldEB0cmFjLnRvb2xzLmlldGYub3JnXSANClNlbnQ6IDEyIEF1Z3VzdCAyMDE0IDEwOjM5 DQpUbzogZHJhZnQtaWV0Zi1tYW5ldC1uaGRwLW9wdGltaXphdGlvbkB0b29scy5pZXRmLm9yZzsg YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb20NCkNjOiBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDog W21hbmV0XSAjNTIgKG5oZHAtb3B0aW1pemF0aW9uKTogQ29uZnVzZWQgcGFyYWdyYXBoICMxIChF ZGl0b3JpYWwgaXNzdWVzKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUg b3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9t IHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xp Y2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0 aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0 cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQojNTI6 IENvbmZ1c2VkIHBhcmFncmFwaCAjMSAoRWRpdG9yaWFsIGlzc3VlcykNCg0KIFRoZSBkcmFmdCBz dGF0ZXMgaW4gc2VjdGlvbiAzOg0KDQogVGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMgW1JGQzYx MzBdLiAgVGhlIG9wdGltaXphdGlvbiBwcmVzZW50ZWQgaW4NCiAgICB0aGlzIHNwZWNpZmljYXRp b24gaXMgc2ltcGx5IHBlcm1pc3NpdmUsIGFzIGl0IGFsbG93cyByZXRhaW5pbmcNCiAgICBpbmZv cm1hdGlvbiB3aGljaCBvdGhlcndpc2Ugd291bGQgaGF2ZSBiZWVuIHJlbW92ZWQsIGJ1dCBkb2Vz IG5vdCB1c2UNCiAgICB0aGF0IGluZm9ybWF0aW9uIGV4Y2VwdCB3aGVuIGl0IGNvdWxkIGhhdmUg YmVlbiB1c2VkIGJ5IFtSRkM2MTMwXS4NCiAgICBUaGlzIGNhbiwgaW4gc29tZSBjYXNlcywgZW5z dXJlIHRoYXQgdGhlIHN5bW1ldHJpYyAyLWhvcCBuZWlnaGJvcmhvb2QNCiAgICBpcyBtb3JlIHJv YnVzdCBhZ2FpbnN0IHRlbXBvcmFyeSBsaW5rIHF1YWxpdHkgY2hhbmdlcywgYW5kDQogICAgY29u c2VxdWVudGx5IHlpZWxkIGEgbW9yZSBzdGFibGUgbmV0d29yay4gIFRoZSBvbmx5IG90aGVyIGNv bnNlcXVlbmNlDQogICAgb2YgdGhpcyBvcHRpbWl6YXRpb24gaXMgdGhhdCBzdGF0ZSBmb3Igc29t ZSBvdGhlcndpc2UgZXhwaXJlZCAyLUhvcA0KICAgIFR1cGxlcyBtYXkgYmUgbWFpbnRhaW5lZCBm b3IgbG9uZ2VyLg0KDQogQWJkdXNzYWxhbSBCYXJ5dW4gQ29tbWVudCAoQUIpPiB0aGUgcGFyYWdy YXBoIHN0YXJ0cyB0aGF0IGl0IHVwZGF0ZXMgNjEzMCAgd2hpY2ggaXMgcmVwZWF0ZWQgbWFueSB0 aW1lcyBiZWZvcmUuIFRoZSBhYm92ZSBwYXJhZ3JhcGggaGFzIG5vICBhcHBsaWNhYmlsaXR5IHN0 YXRlbWVudC4gUGxlYXNlIHJlZmVyIGhlcmUgdG8gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnRzIG9m ICB0aGUgdXBkYXRlZCBzdGFuZGFyZHMgNjEzMCBhbmQgNzE4MSwgYW5kIG1lbnRpb24gZmlyc3Qg dGhhdCB0aGVpciAgYXBwbGljYWJpbGl0eSBhcHBsaWVzIGZvciB0aGlzIHVwZGF0ZSBwcm9wb3Nh bC4gVGhpcyBpcyB0byBhdm9pZCAgY29uZnVzaW9uLg0KDQpDTUQ6IE5vLiBUaGlzIGRyYWZ0IHVw ZGF0ZXMgUkZDIDYxMzAuIFRoYXQgaXMgdGhlIGtleSBjZW50cmFsIGZhY3QgYWJvdXQgd2hlcmUg aXQgaXMgYXBwbGljYWJsZS4gSXQncyBzYWlkIGVhcmxpZXIgaW4gdGhlIGFic3RyYWN0IGFuZCBp bnRyb2R1Y3Rpb24gYmVjYXVzZSBpdCdzIHRoZSBrZXkgZmFjdCBhYm91dCB0aGUgd2hvbGUgc3Bl Y2lmaWNhdGlvbi4gQnV0IHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBzdGFuZHMgYWxvbmUs IGFuZCB3aWxsIHJlcGVhdCB0aGluZ3Mgc2FpZCBpbiB0aGUgaW50cm9kdWN0aW9uLiBJbiBmYWN0 IHRoYXQncyB0aGUgbmF0dXJlIG9mIGludHJvZHVjdGlvbnMsIG1hbnkgdGhpbmdzIHNhaWQgdGhl cmUgYXJlIHNhaWQgaW4gbW9yZSBkZXRhaWwgbGF0ZXIuIChJbiB0aGUgY2FzZSBvZiBhYnN0cmFj dHMgZXZlcnl0aGluZyBzYWlkIHRoZXJlIGlzIHNhaWQgaW4gbW9yZSBkZXRhaWwgbGF0ZXIuKQ0K DQogVGhlIGRyYWZ0IHN0YXRlcyBpbiBzZWN0aW9uIDM6DQogIFRoaXMgc3BlY2lmaWNhdGlvbiBh bHNvIHVwZGF0ZXMgW1JGQzcxODFdLiAgVGhpcyBjb3VsZCBiZSBhdm9pZGVkIGJ5DQogICAgc2lt cGx5IG5vdGluZyB0aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgaG93IHRoZSB1cGRh dGVzIHRvDQogICAgW1JGQzYxMzBdIG1heSBiZSBoYW5kbGVkIHNvIGFzIHRvIGJlIGludmlzaWJs ZSB0byBhbnkgb3RoZXIgcHJvdG9jb2wNCiAgICB1c2luZyBpdC4NCg0KIEFCPiBJIHRoaW5rIHRo YXQgdGhpcyBwcm9wb3NhbCB1cGRhdGUgaXMgZm9yIG9ubHkgT0xTUnYyIHJvdXRlcnMsIHRoaXMg aXMgIGNsZWFyIGZyb20gdGhlIGFic3RyYWN0LiBIb3dldmVyLCB0aGUgYWJvdmUgY29uZnVzZXMg dGhhdCBhcyBzZXBhcmF0aW5nICB0aGUgdXBkYXRlIG9mIG1lbnRpb25pbmcgdmlzaWJpbGl0eSBv ZiBhbnkgb3RoZXIgcHJvdG9jb2wuIEkgZG9uJ3QgdGhpbmsgIHRoaXMgdXBkYXRlIGNhbiBiZSB1 c2VkIGZvciBBT0RWdjIgKGlmIEkgbWlzdGFrZW4gcGxlYXNlIGFtZW5kIHRoZSB0ZXh0IHRvICBh dm9pZCBjb25mdXNpb24pLg0KDQpDTUQ6IE5vLCBhZ2Fpbi4gU3RhdGluZyB0aGF0IGl0IGFsc28g dXBkYXRlcyBSRkM3MTgxIGxhdGVyIG9uIGlzIGNvcnJlY3QuIFRoZXJlJ3Mgbm8gc3VnZ2VzdGlv biB0aGF0IHRoaXMgaXMgdGhlIG9ubHkgcG9zc2liaWxpdHkuIFVwZGF0ZXMgWCBhbmQgWSBpbiBu byB3YXkgaW1wbGllcyBvbmx5IHVwZGF0ZXMgWCBpbiBZIGNvbnRleHQuIEl0IHdvdWxkIGlmIGl0 IHdlcmUgc28gbGltaXRlZCB0aGF0IHlvdSdkIHNheSBzbyAodW5sZXNzIG9idmlvdXMpLg0KDQog VGhlIGRyYWZ0IHN0YXRlcyBpbiBzZWN0aW9uIDM6DQoNCiAgSG93ZXZlciBhcyBpdCBpcyBrbm93 biB0aGF0IHNvbWUgaW1wbGVtZW50YXRpb25zIG9mDQogICAgW1JGQzcxODFdIGFyZSBub3QgaW5k ZXBlbmRlbnQgb2YgdGhlIGltcGxlbWVudGF0aW9uIG9mIFtSRkM2MTMwXSB0aGF0DQogICAgdGhl eSB1c2UsIGl0IGlzIHVzZWZ1bCB0byBpbmRpY2F0ZSB0aGUgZGlyZWN0IGltcGFjdCBvbiBbUkZD NzE4MV0uDQoNCiBBQj4gd2hlbiB5b3Ugc2F5ICJpdCBpcyBrbm93biIsIHlvdSBzaG91bGQgbWVh biBrbm93biBieSBJRVRGIHNvIHBsZWFzZSAgcmVmZXIgdG8gdGhhdCBrbm93biBkb2N1bWVudC9y ZWZlcmVuY2Ugb3RoZXJ3aXNlIGl0IGlzIG9ubHkga25vd24gYnkgc29tZSAgcGVvcGxlLg0KDQpD TUQ6IEl0J3Mgbm93IGtub3duLCBiZWNhdXNlIHRoaXMgaW5mb3JtcyB5b3Ugb2YgdGhhdC4gRmFj dHMgYWJvdXQgaW1wbGVtZW50YXRpb25zIGFyZSBoYXJkIHRvIHBpbiBkb3duIHRvIHJlZmVyZW5j ZXMuIEhvd2V2ZXIgIml0IGlzIGtub3duIHRoYXQiIGNvdWxkIGJlIHJlbW92ZWQgYXMgdGF1dG9s b2dpY2FsLg0KDQpJTUhPIEkgcmVtZW1iZXIgZGlzY3Vzc2luZyB0aGlzIGlzc3VlIHdpdGggT0xT UnYyIGF1dGhvcnMgYXQgSUVTRyAgbGFzdCBjYWxsLCBJIHVuZGVyc3Rvb2QgZnJvbSB0aGVtIHRo YXQgT0xTUnYyIGlzIG5vdCBpbmRlcGVuZGVudCBmcm9tICBSRkM2MTMwLiBOb3csIGxldCBtZSBh c3N1bWUgSSBrbm93IHRoZXJlIGFyZSByb3V0ZXJzIGluZGVwZW5kZW50IG9mIHRoZWlyDQogUkZD NjEzMCBpbnRlcmZhY2UsIHRoZW4gdGhpcyBvcHRpbWlzYXRpb24gcHJvcG9zYWwgIGlzIG1vc3Rs eSB1cGRhdGluZyAgUkZDNjEzMCwgdGhlcmVmb3JlLCB0aGUgY2hhbmdlcyByZWNvbW1lbmRlZCBi eSB0aGUgZHJhZnQgdG8gdGhlIDcxODEgaXMgIG9ubHkgYSBtdXN0IGlmIHRoZXJlIGlzIGRlcGVu ZGFuY3ksIG90aGVyd2lzZSwgcGxlYXNlIG1lbnRpb24gdGhhdCB0aGUgIGZ1bGwgY2hhbmdlcyBy ZXF1aXJlZCBpcyBhIG11c3QgZXZlbiBpZiBPTFNSdjIgaXMgbm90IGRlcGVuZGVudCBvbiA2MTMw Lg0KIEZ1cnRoZXJtb3JlLCBpZiB0aGVyZSBhcmUgcG9zc2liaWxpdHkgb2Ygb3RoZXIgcHJvdG9j b2wgb3RoZXIgdGhhbiBPTFNSdjIgIHJvdXRlcnMgdG8gdXNlIHRoaXMgZHJhZnQsIHRoZW4gbWVu dGlvbiB0aGF0IGNsZWFybHkgYW5kIG1lbnRpb24gdGhhdCB0aGUgIE11c3QgaXMgb2YgYWxsIGNo YW5nZXMgb2Ygc2VjdGlvbiA0Lg0KDQpDTUQ6IEkganVzdCBjYW4ndCBwYXJzZSB0aGF0LiBCdXQg dGhlIHBhcnQgSSBkaWQgdW5kZXJzdGFuZCBpcyBqdXN0IHJlcGVhdGluZyB0aGUgc2FtZSBtaXNy ZWFkaW5nLg0KDQogQUI+IHRvIGF2b2lkIGNvbmZ1c2lvbiBpZiB0aGlzIHVwZGF0ZSBpcyBvbmx5 IGZvciBPTFNSdjIgcm91dGVycyB0aGVuICBtZW50aW9uIHRoYXQgaW4gaXRzIHRpdGxlLiBTbyB0 aGUgdGl0bGUgd2lsbCBhZGQgd29yZHMgImZvciBPTFNSdjIgIHJvdXRlcnMuDQoNCkNNRDogVGhl IG9ubHkgY29uZnVzaW9uIGlzIHlvdXJzLiBUaGVyZSdzIG5vIHN1Z2dlc3Rpb24gb2YgdGhhdCBh bnl3aGVyZSwgYW5kIGl0J3Mgbm90IHNvLg0KDQogQmVzdC4NCiBBQg0KDQotLSANCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0NCiBSZXBv cnRlcjogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgT3duZXI6ICBkcmFmdC1pZXRm LW1hbmV0LW5oZHAtDQogIGFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tICAgICAgICAgfCAgb3B0 aW1pemF0aW9uQHRvb2xzLmlldGYub3JnDQogICAgIFR5cGU6ICBlbmhhbmNlbWVudCAgICAgICAg ICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAg ICAgICAgfCAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgbmhkcC1vcHRpbWl6YXRpb24gICAgICAg IHwgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIEluIFdHIExhc3QgQ2FsbCAgICAgICAgICB8ICAg S2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93 Zy9tYW5ldC90cmFjL3RpY2tldC81Mj4NCm1hbmV0IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvbWFu ZXQvPg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNv bmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxl dGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQg bm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlz dHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK From nobody Tue Aug 12 08:55: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 330511A040B for ; Tue, 12 Aug 2014 08:55:12 -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 1vKzIyOsTu0F for ; Tue, 12 Aug 2014 08:55:09 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981A51A03F5 for ; Tue, 12 Aug 2014 08:55:00 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id c41so7629333yho.12 for ; Tue, 12 Aug 2014 08:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cggPWekFIYxqayoZSFVeUOc/Ai180mNBT6c9rWShFAc=; b=0Mk5d26An/QDR0/ieaanKbk4DoW2L5F+IdHHqlCUar8H9Kei7JDJkwOgaziTs3H+QU uvafSP5NK0CRGCTPK57vS13GSORXbg90fkw/gjM+l/bjzpG55Da/vV4cbGbOxPW6/SsJ naNpmrHI+gkk0N9+8gzQHDSKP1v4uPpjp/g09hL6bvRDuYND4X1j3ifKynzvB5MuRyJM +YJvk4SyP3y4kEsnXvMQ92/T5trpc1ipP5yHn36vXh/uOIKwLZgG35DiYjUyYuVFR7+I lp15PU2L5tVnbkIrr2wakz8U/g8unfwUT4NWM4dLwsFVaGOpCnVIV6la5U4HJ5PO2NUF kHvg== MIME-Version: 1.0 X-Received: by 10.236.112.3 with SMTP id x3mr53468871yhg.17.1407858899945; Tue, 12 Aug 2014 08:54:59 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Tue, 12 Aug 2014 08:54:59 -0700 (PDT) In-Reply-To: References: <066.0bb22f15b7c74448b0bb3821234ffc46@trac.tools.ietf.org> Date: Tue, 12 Aug 2014 17:54:59 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=20cf301af247a010d9050070b1bf Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2voR90pQm0sXH2F7TkV2RitLLso Cc: "manet@ietf.org" , "draft-ietf-manet-nhdp-optimization@tools.ietf.org" Subject: Re: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial 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: Tue, 12 Aug 2014 15:55:12 -0000 --20cf301af247a010d9050070b1bf Content-Type: text/plain; charset=UTF-8 On Tuesday, August 12, 2014, Dearlove, Christopher (UK) wrote: > > > The draft states in section 3: > > This specification updates [RFC6130]. The optimization presented in > this specification is simply permissive, as it allows retaining > information which otherwise would have been removed, but does not use > that information except when it could have been used by [RFC6130]. > This can, in some cases, ensure that the symmetric 2-hop neighborhood > is more robust against temporary link quality changes, and > consequently yield a more stable network. The only other consequence > of this optimization is that state for some otherwise expired 2-Hop > Tuples may be maintained for longer. > > Abdussalam Baryun Comment (AB)> the paragraph starts that it updates 6130 > which is repeated many times before. The above paragraph has no > applicability statement. Please refer here to applicability statements of > the updated standards 6130 and 7181, and mention first that their > applicability applies for this update proposal. This is to avoid > confusion. > > CMD: No. This draft updates RFC 6130. That is the key central fact about > where it is applicable. It's said earlier in the abstract and introduction > because it's the key fact about the whole specification. But the > applicability statement stands alone, and will repeat things said in the > introduction. In fact that's the nature of introductions, many things said > there are said in more detail later. (In the case of abstracts everything > said there is said in more detail later.) [AB] the main point is the applicability within the MANET so draft should have that clear stated, and if this update accepts the same applicability of 6130 and 7181. > > The draft states in section 3: > This specification also updates [RFC7181]. This could be avoided by > simply noting that this specification describes how the updates to > [RFC6130] may be handled so as to be invisible to any other protocol > using it. > > AB> I think that this proposal update is for only OLSRv2 routers, this is > clear from the abstract. However, the above confuses that as separating > the update of mentioning visibility of any other protocol. I don't think > this update can be used for AODVv2 (if I mistaken please amend the text to > avoid confusion). > > CMD: No, again. Stating that it also updates RFC7181 later on is correct. > There's no suggestion that this is the only possibility. Updates X and Y in > no way implies only updates X in Y context. It would if it were so limited > that you'd say so (unless obvious). AB> When we say MANET we MUST not ignore that there are proactive and reactive routers. So in the draft ignores reactive routing changes. So does the WG still think we should not mention clearly that this update is for both reactive and proactive or clearly that it is for proactive only. AB> I think when draft was adopted many of WG considered it as OLSRv2/NHDP optimization (not sure but the chair and AD can know better). Furthermore, there should be discussions related to AODVv2 to see applicability. > The draft states in section 3: > > However as it is known that some implementations of > [RFC7181] are not independent of the implementation of [RFC6130] that > they use, it is useful to indicate the direct impact on [RFC7181]. > > AB> when you say "it is known", you should mean known by IETF so please > refer to that known document/reference otherwise it is only known by some > people. > > CMD: It's now known, because this informs you of that. Facts about > implementations are hard to pin down to references. However "it is known > that" could be removed as tautological. No. I mean within RFC7181 IMHO it is dependent on 6130, so we don't have independent. > IMHO I remember discussing this issue with OLSRv2 authors at IESG last > call, I understood from them that OLSRv2 is not independent from RFC6130. > Now, let me assume I know there are routers independent of their > RFC6130 interface, then this optimisation proposal is mostly updating > RFC6130, therefore, the changes recommended by the draft to the 7181 is > only a must if there is dependancy, otherwise, please mention that the > full changes required is a must even if OLSRv2 is not dependent on 6130. > Furthermore, if there are possibility of other protocol other than OLSRv2 > routers to use this draft, then mention that clearly and mention that the > Must is of all changes of section 4. > > CMD: I just can't parse that. But the part I did understand is just > repeating the same misreading. The 7181 is dependent on 6130. So no need to update other independent that are not standards on IETF. > > AB> to avoid confusion if this update is only for OLSRv2 routers then > mention that in its title. So the title will add words "for OLSRv2 > routers. > > CMD: The only confusion is yours. There's no suggestion of that anywhere, > and it's not so. Yes. I am a reader of the draft and you are the author. So now the author notice the reader confusion, which can happen again with other readers on future, I hope the WG considers this issue. AB > > > > > --20cf301af247a010d9050070b1bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, August 12, 2014, Dearlove, Christopher (UK) wrote:
=


=C2=A0The draft states in section 3:

=C2=A0This specification updates [RFC6130]. =C2=A0The optimization presente= d in
=C2=A0 =C2=A0 this specification is simply permissive, as it allows retaini= ng
=C2=A0 =C2=A0 information which otherwise would have been removed, but does= not use
=C2=A0 =C2=A0 that information except when it could have been used by [RFC6= 130].
=C2=A0 =C2=A0 This can, in some cases, ensure that the symmetric 2-hop neig= hborhood
=C2=A0 =C2=A0 is more robust against temporary link quality changes, and =C2=A0 =C2=A0 consequently yield a more stable network. =C2=A0The only othe= r consequence
=C2=A0 =C2=A0 of this optimization is that state for some otherwise expired= 2-Hop
=C2=A0 =C2=A0 Tuples may be maintained for longer.

=C2=A0Abdussalam Baryun Comment (AB)> the paragraph starts that it updat= es 6130 =C2=A0which is repeated many times before. The above paragraph has = no =C2=A0applicability statement. Please refer here to applicability statem= ents of =C2=A0the updated standards 6130 and 7181, and mention first that t= heir =C2=A0applicability applies for this update proposal. This is to avoid= =C2=A0confusion.

CMD: No. This draft updates RFC 6130. That is the key central fact about wh= ere it is applicable. It's said earlier in the abstract and introductio= n because it's the key fact about the whole specification. But the appl= icability statement stands alone, and will repeat things said in the introd= uction. In fact that's the nature of introductions, many things said th= ere are said in more detail later. (In the case of abstracts everything sai= d there is said in more detail later.)

[AB] the main point is the=C2=A0applicability within th= e MANET so draft=C2=A0should have that=C2=A0clear stated, and if this updat= e accepts the same applicability of 6130 and 7181.=C2=A0
=C2=A0

=C2=A0The draft states in section 3:
=C2=A0 This specification also updates [RFC7181]. =C2=A0This could be avoid= ed by
=C2=A0 =C2=A0 simply noting that this specification describes how the updat= es to
=C2=A0 =C2=A0 [RFC6130] may be handled so as to be invisible to any other p= rotocol
=C2=A0 =C2=A0 using it.

=C2=A0AB> I think that this proposal update is for only OLSRv2 routers, = this is =C2=A0clear from the abstract. However, the above confuses that as = separating =C2=A0the update of mentioning visibility of any other protocol.= I don't think =C2=A0this update can be used for AODVv2 (if I mistaken = please amend the text to =C2=A0avoid confusion).

CMD: No, again. Stating that it also updates RFC7181 later on is correct. T= here's no suggestion that this is the only possibility. Updates X and Y= in no way implies only updates X in Y context. It would if it were so limi= ted that you'd say so (unless obvious).

AB>=C2=A0When we=C2=A0say MANET we=C2=A0MUST not ign= ore that there are proactive and reactive routers. So in the draft ignores = reactive routing changes. So does the WG=C2=A0still think we should not men= tion clearly that this update is for both reactive and proactive or clearly= that it is for proactive only.=C2=A0

AB>=C2=A0I think when draft=C2=A0was adopted many of= WG considered it as OLSRv2/NHDP optimization (not sure but the chair and A= D can know better). Furthermore, there should be discussions related to AOD= Vv2 to see applicability.=C2=A0



=C2=A0The draft states in section 3:

=C2=A0 However as it is known that some implementations of
=C2=A0 =C2=A0 [RFC7181] are not independent of the implementation of [RFC61= 30] that
=C2=A0 =C2=A0 they use, it is useful to indicate the direct impact on [RFC7= 181].

=C2=A0AB> when you say "it is known", you should mean known by= IETF so please =C2=A0refer to that known document/reference otherwise it i= s only known by some =C2=A0people.

CMD: It's now known, because this informs you of that. Facts about impl= ementations are hard to pin down to references. However "it is known t= hat" could be removed as tautological.

No. I mean within RFC7181 IMHO it=C2=A0is dependent on 6130,=C2=A0so w= e don't have independent.=C2=A0=C2=A0
=09 =09 =09


IMHO I remember discussing this issue with OLSRv2 authors at IESG =C2=A0las= t call, I understood from them that OLSRv2 is not independent from =C2=A0RF= C6130. Now, let me assume I know there are routers independent of their
=C2=A0RFC6130 interface, then this optimisation proposal =C2=A0is mostly up= dating =C2=A0RFC6130, therefore, the changes recommended by the draft to th= e 7181 is =C2=A0only a must if there is dependancy, otherwise, please menti= on that the =C2=A0full changes required is a must even if OLSRv2 is not dep= endent on 6130.
=C2=A0Furthermore, if there are possibility of other protocol other than OL= SRv2 =C2=A0routers to use this draft, then mention that clearly and mention= that the =C2=A0Must is of all changes of section 4.

CMD: I just can't parse that. But the part I did understand is just rep= eating the same misreading.

The 7181 is dep= endent on 6130. So no need to update other independent that are not standar= ds on IETF.=C2=A0
=C2=A0

=C2=A0AB> to avoid confusion if this update is only for OLSRv2 routers t= hen =C2=A0mention that in its title. So the title will add words "for = OLSRv2 =C2=A0routers.

CMD: The only confusion is yours. There's no suggestion of that anywher= e, and it's not so.

Yes. I am a reader = of the draft and you are the author. So now the author notice the reader co= nfusion, which can happen again with other readers on future, I hope the WG= considers this issue.=C2=A0

AB

=C2=A0



=C2=A0
--20cf301af247a010d9050070b1bf-- From nobody Tue Aug 12 09:25: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 5C6891A01AA for ; Tue, 12 Aug 2014 09:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.567 X-Spam-Level: X-Spam-Status: No, score=-7.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 mCOcwfc33uXB for ; Tue, 12 Aug 2014 09:25:13 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468261A02D7 for ; Tue, 12 Aug 2014 09:25:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,849,1400022000"; d="scan'208,217";a="467650847" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Aug 2014 17:25:10 +0100 X-IronPort-AV: E=Sophos; i="5.01,849,1400022000"; d="scan'208,217"; a="61712453" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 12 Aug 2014 17:25:01 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Tue, 12 Aug 2014 17:25:02 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial issues) Thread-Index: AQHPthE/YX2SR9vCC0ebmGQra7VFqJvMttRQgABXz4CAABUQwA== Date: Tue, 12 Aug 2014 16:25:01 +0000 Message-ID: References: <066.0bb22f15b7c74448b0bb3821234ffc46@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D2070FGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ecWFUmeglqOezw-boN7oiR41zis Cc: "manet@ietf.org" , "draft-ietf-manet-nhdp-optimization@tools.ietf.org" Subject: Re: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial 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: Tue, 12 Aug 2014 16:25:20 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D2070FGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Q29tbWVudHMgYmVsb3cuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5j aXBhbCBFbmdpbmVlciwgSW5mb3JtYXRpb24gQXNzdXJhbmNlIEdyb3VwDQpDb21tdW5pY2F0aW9u cywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0ZW1zIEFk dmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBC YWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5NCB8ICBG YXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRv OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5j b20NCg0KQkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNl OiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUs IEZhcm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQg JiBXYWxlcyBObzogMTk5NjY4Nw0KDQpGcm9tOiBBYmR1c3NhbGFtIEJhcnl1biBbbWFpbHRvOmFi ZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tXQ0KU2VudDogMTIgQXVndXN0IDIwMTQgMTY6NTUNClRv OiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IG1hbmV0QGlldGYub3JnOyBkcmFmdC1p ZXRmLW1hbmV0LW5oZHAtb3B0aW1pemF0aW9uQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTog W21hbmV0XSAjNTIgKG5oZHAtb3B0aW1pemF0aW9uKTogQ29uZnVzZWQgcGFyYWdyYXBoICMxIChF ZGl0b3JpYWwgaXNzdWVzKQ0KDQpPbiBUdWVzZGF5LCBBdWd1c3QgMTIsIDIwMTQsIERlYXJsb3Zl LCBDaHJpc3RvcGhlciAoVUspIHdyb3RlOg0KDQpDTUQ6IEFjdHVhbGx5IGdldHRpbmcgaGFyZCB0 byB3b3JrIHRoaXMgb3V0LiBCdXQgaWYgaXQgZG9lc27igJl0IHNheSBDTUQgdGhlbiBJIGRpZG7i gJl0LiBVbmxlc3MgYSBxdW90ZSBmcm9tIHRoZSBkcmFmdC4NCg0KIFRoZSBkcmFmdCBzdGF0ZXMg aW4gc2VjdGlvbiAzOg0KDQogVGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMgW1JGQzYxMzBdLiAg VGhlIG9wdGltaXphdGlvbiBwcmVzZW50ZWQgaW4NCiAgICB0aGlzIHNwZWNpZmljYXRpb24gaXMg c2ltcGx5IHBlcm1pc3NpdmUsIGFzIGl0IGFsbG93cyByZXRhaW5pbmcNCiAgICBpbmZvcm1hdGlv biB3aGljaCBvdGhlcndpc2Ugd291bGQgaGF2ZSBiZWVuIHJlbW92ZWQsIGJ1dCBkb2VzIG5vdCB1 c2UNCiAgICB0aGF0IGluZm9ybWF0aW9uIGV4Y2VwdCB3aGVuIGl0IGNvdWxkIGhhdmUgYmVlbiB1 c2VkIGJ5IFtSRkM2MTMwXS4NCiAgICBUaGlzIGNhbiwgaW4gc29tZSBjYXNlcywgZW5zdXJlIHRo YXQgdGhlIHN5bW1ldHJpYyAyLWhvcCBuZWlnaGJvcmhvb2QNCiAgICBpcyBtb3JlIHJvYnVzdCBh Z2FpbnN0IHRlbXBvcmFyeSBsaW5rIHF1YWxpdHkgY2hhbmdlcywgYW5kDQogICAgY29uc2VxdWVu dGx5IHlpZWxkIGEgbW9yZSBzdGFibGUgbmV0d29yay4gIFRoZSBvbmx5IG90aGVyIGNvbnNlcXVl bmNlDQogICAgb2YgdGhpcyBvcHRpbWl6YXRpb24gaXMgdGhhdCBzdGF0ZSBmb3Igc29tZSBvdGhl cndpc2UgZXhwaXJlZCAyLUhvcA0KICAgIFR1cGxlcyBtYXkgYmUgbWFpbnRhaW5lZCBmb3IgbG9u Z2VyLg0KDQogQWJkdXNzYWxhbSBCYXJ5dW4gQ29tbWVudCAoQUIpPiB0aGUgcGFyYWdyYXBoIHN0 YXJ0cyB0aGF0IGl0IHVwZGF0ZXMgNjEzMCAgd2hpY2ggaXMgcmVwZWF0ZWQgbWFueSB0aW1lcyBi ZWZvcmUuIFRoZSBhYm92ZSBwYXJhZ3JhcGggaGFzIG5vICBhcHBsaWNhYmlsaXR5IHN0YXRlbWVu dC4gUGxlYXNlIHJlZmVyIGhlcmUgdG8gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnRzIG9mICB0aGUg dXBkYXRlZCBzdGFuZGFyZHMgNjEzMCBhbmQgNzE4MSwgYW5kIG1lbnRpb24gZmlyc3QgdGhhdCB0 aGVpciAgYXBwbGljYWJpbGl0eSBhcHBsaWVzIGZvciB0aGlzIHVwZGF0ZSBwcm9wb3NhbC4gVGhp cyBpcyB0byBhdm9pZCAgY29uZnVzaW9uLg0KDQpDTUQ6IE5vLiBUaGlzIGRyYWZ0IHVwZGF0ZXMg UkZDIDYxMzAuIFRoYXQgaXMgdGhlIGtleSBjZW50cmFsIGZhY3QgYWJvdXQgd2hlcmUgaXQgaXMg YXBwbGljYWJsZS4gSXQncyBzYWlkIGVhcmxpZXIgaW4gdGhlIGFic3RyYWN0IGFuZCBpbnRyb2R1 Y3Rpb24gYmVjYXVzZSBpdCdzIHRoZSBrZXkgZmFjdCBhYm91dCB0aGUgd2hvbGUgc3BlY2lmaWNh dGlvbi4gQnV0IHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBzdGFuZHMgYWxvbmUsIGFuZCB3 aWxsIHJlcGVhdCB0aGluZ3Mgc2FpZCBpbiB0aGUgaW50cm9kdWN0aW9uLiBJbiBmYWN0IHRoYXQn cyB0aGUgbmF0dXJlIG9mIGludHJvZHVjdGlvbnMsIG1hbnkgdGhpbmdzIHNhaWQgdGhlcmUgYXJl IHNhaWQgaW4gbW9yZSBkZXRhaWwgbGF0ZXIuIChJbiB0aGUgY2FzZSBvZiBhYnN0cmFjdHMgZXZl cnl0aGluZyBzYWlkIHRoZXJlIGlzIHNhaWQgaW4gbW9yZSBkZXRhaWwgbGF0ZXIuKQ0KDQpbQUJd IHRoZSBtYWluIHBvaW50IGlzIHRoZSBhcHBsaWNhYmlsaXR5IHdpdGhpbiB0aGUgTUFORVQgc28g ZHJhZnQgc2hvdWxkIGhhdmUgdGhhdCBjbGVhciBzdGF0ZWQsIGFuZCBpZiB0aGlzIHVwZGF0ZSBh Y2NlcHRzIHRoZSBzYW1lIGFwcGxpY2FiaWxpdHkgb2YgNjEzMCBhbmQgNzE4MS4NCg0KQ01EOiBJ ZiB5b3UgdXBkYXRlIHNvbWV0aGluZyB5b3UgZG8gbm90IG5lZWQgdG8gcmVwZWF0IGV2ZXJ5dGhp bmcgYWJvdXQgaXQuIElmIHRoZSBhcHBsaWNhYmlsaXR5IHdlcmUgY2hhbmdlZCB5b3XigJlkIG5l ZWQgdG8gc2F5IHNvLCBidXQgbm90IGlmIG5vdC4NCg0KIFRoZSBkcmFmdCBzdGF0ZXMgaW4gc2Vj dGlvbiAzOg0KICBUaGlzIHNwZWNpZmljYXRpb24gYWxzbyB1cGRhdGVzIFtSRkM3MTgxXS4gIFRo aXMgY291bGQgYmUgYXZvaWRlZCBieQ0KICAgIHNpbXBseSBub3RpbmcgdGhhdCB0aGlzIHNwZWNp ZmljYXRpb24gZGVzY3JpYmVzIGhvdyB0aGUgdXBkYXRlcyB0bw0KICAgIFtSRkM2MTMwXSBtYXkg YmUgaGFuZGxlZCBzbyBhcyB0byBiZSBpbnZpc2libGUgdG8gYW55IG90aGVyIHByb3RvY29sDQog ICAgdXNpbmcgaXQuDQoNCiBBQj4gSSB0aGluayB0aGF0IHRoaXMgcHJvcG9zYWwgdXBkYXRlIGlz IGZvciBvbmx5IE9MU1J2MiByb3V0ZXJzLCB0aGlzIGlzICBjbGVhciBmcm9tIHRoZSBhYnN0cmFj dC4gSG93ZXZlciwgdGhlIGFib3ZlIGNvbmZ1c2VzIHRoYXQgYXMgc2VwYXJhdGluZyAgdGhlIHVw ZGF0ZSBvZiBtZW50aW9uaW5nIHZpc2liaWxpdHkgb2YgYW55IG90aGVyIHByb3RvY29sLiBJIGRv bid0IHRoaW5rICB0aGlzIHVwZGF0ZSBjYW4gYmUgdXNlZCBmb3IgQU9EVnYyIChpZiBJIG1pc3Rh a2VuIHBsZWFzZSBhbWVuZCB0aGUgdGV4dCB0byAgYXZvaWQgY29uZnVzaW9uKS4NCg0KQ01EOiBO bywgYWdhaW4uIFN0YXRpbmcgdGhhdCBpdCBhbHNvIHVwZGF0ZXMgUkZDNzE4MSBsYXRlciBvbiBp cyBjb3JyZWN0LiBUaGVyZSdzIG5vIHN1Z2dlc3Rpb24gdGhhdCB0aGlzIGlzIHRoZSBvbmx5IHBv c3NpYmlsaXR5LiBVcGRhdGVzIFggYW5kIFkgaW4gbm8gd2F5IGltcGxpZXMgb25seSB1cGRhdGVz IFggaW4gWSBjb250ZXh0LiBJdCB3b3VsZCBpZiBpdCB3ZXJlIHNvIGxpbWl0ZWQgdGhhdCB5b3Un ZCBzYXkgc28gKHVubGVzcyBvYnZpb3VzKS4NCg0KQUI+IFdoZW4gd2Ugc2F5IE1BTkVUIHdlIE1V U1Qgbm90IGlnbm9yZSB0aGF0IHRoZXJlIGFyZSBwcm9hY3RpdmUgYW5kIHJlYWN0aXZlIHJvdXRl cnMuIFNvIGluIHRoZSBkcmFmdCBpZ25vcmVzIHJlYWN0aXZlIHJvdXRpbmcgY2hhbmdlcy4gU28g ZG9lcyB0aGUgV0cgc3RpbGwgdGhpbmsgd2Ugc2hvdWxkIG5vdCBtZW50aW9uIGNsZWFybHkgdGhh dCB0aGlzIHVwZGF0ZSBpcyBmb3IgYm90aCByZWFjdGl2ZSBhbmQgcHJvYWN0aXZlIG9yIGNsZWFy bHkgdGhhdCBpdCBpcyBmb3IgcHJvYWN0aXZlIG9ubHkuDQoNCkNNRDogVGhpcyBpcyBhbiB1cGRh dGUgdG8gTkhEUCBhbmQgT0xTUnYyLiBUaG9zZSBhcmUgbm90IHJlYWN0aXZlLiBSZWFjdGl2ZSBw cm90b2NvbHMgYXJlIGlycmVsZXZhbnQgaGVyZS4gSWYgYSBwcm90b2NvbHMgc3VjaCBhcyBBT0RW djIgY2hvc2UgdG8gdXNlIE5IRFAsIGl0IHdvdWxkIGp1c3QgYmUgdGhlIHByb2FjdGl2ZSBwYXJ0 IG9mIHRoaXMgcHJvdG9jb2wgdGhhdCB3b3VsZCBiZSBhZmZlY3RlZC4gU28gdGhpcyBpcyBhbm90 aGVyIHBvaW50bGVzcyBzdWdnZXN0aW9uLg0KDQpBQj4gSSB0aGluayB3aGVuIGRyYWZ0IHdhcyBh ZG9wdGVkIG1hbnkgb2YgV0cgY29uc2lkZXJlZCBpdCBhcyBPTFNSdjIvTkhEUCBvcHRpbWl6YXRp b24gKG5vdCBzdXJlIGJ1dCB0aGUgY2hhaXIgYW5kIEFEIGNhbiBrbm93IGJldHRlcikuIEZ1cnRo ZXJtb3JlLCB0aGVyZSBzaG91bGQgYmUgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byBBT0RWdjIgdG8g c2VlIGFwcGxpY2FiaWxpdHkuDQoNCk5vLiBOb3QgcmVsZXZhbnQuIEFPRFZ2MiBpcyBhbHNvIGlu IHNlcmlvdXMgbmVlZCBvZiB3b3JrLCBhbmQgd2FpdGluZyBmb3IgdGhhdCB3b3VsZCBiZSBzZXJp b3VzbHkgY291bnRlcnByb2R1Y3RpdmUsIGFuZCBzdGlsbCBub3QgcmVsZXZhbnQuDQoNCiBUaGUg ZHJhZnQgc3RhdGVzIGluIHNlY3Rpb24gMzoNCg0KICBIb3dldmVyIGFzIGl0IGlzIGtub3duIHRo YXQgc29tZSBpbXBsZW1lbnRhdGlvbnMgb2YNCiAgICBbUkZDNzE4MV0gYXJlIG5vdCBpbmRlcGVu ZGVudCBvZiB0aGUgaW1wbGVtZW50YXRpb24gb2YgW1JGQzYxMzBdIHRoYXQNCiAgICB0aGV5IHVz ZSwgaXQgaXMgdXNlZnVsIHRvIGluZGljYXRlIHRoZSBkaXJlY3QgaW1wYWN0IG9uIFtSRkM3MTgx XS4NCg0KIEFCPiB3aGVuIHlvdSBzYXkgIml0IGlzIGtub3duIiwgeW91IHNob3VsZCBtZWFuIGtu b3duIGJ5IElFVEYgc28gcGxlYXNlICByZWZlciB0byB0aGF0IGtub3duIGRvY3VtZW50L3JlZmVy ZW5jZSBvdGhlcndpc2UgaXQgaXMgb25seSBrbm93biBieSBzb21lICBwZW9wbGUuDQoNCkNNRDog SXQncyBub3cga25vd24sIGJlY2F1c2UgdGhpcyBpbmZvcm1zIHlvdSBvZiB0aGF0LiBGYWN0cyBh Ym91dCBpbXBsZW1lbnRhdGlvbnMgYXJlIGhhcmQgdG8gcGluIGRvd24gdG8gcmVmZXJlbmNlcy4g SG93ZXZlciAiaXQgaXMga25vd24gdGhhdCIgY291bGQgYmUgcmVtb3ZlZCBhcyB0YXV0b2xvZ2lj YWwuDQoNCk5vLiBJIG1lYW4gd2l0aGluIFJGQzcxODEgSU1ITyBpdCBpcyBkZXBlbmRlbnQgb24g NjEzMCwgc28gd2UgZG9uJ3QgaGF2ZSBpbmRlcGVuZGVudC4NCg0KQ01EOiBJIHJlYWxseSBhbSBu b3QgZ29pbmcgdG8gZXhwbGFpbiB0aGUgcmVsYXRpb25zaGlwIGhlcmUsIGFuZCBob3cgeW91IGNh biB3cml0ZSBzZXBhcmF0ZSBvciBpbnRlZ3JhdGVkIGltcGxlbWVudGF0aW9ucy4gQnV0IHBlcmhh cHMg4oCcc2VwYXJhdGUgZnJvbeKAnSBtaWdodCBiZSBiZXR0ZXIgdGhhbiDigJxpbmRlcGVuZGVu dCBvZuKAnS4NCg0KSU1ITyBJIHJlbWVtYmVyIGRpc2N1c3NpbmcgdGhpcyBpc3N1ZSB3aXRoIE9M U1J2MiBhdXRob3JzIGF0IElFU0cgIGxhc3QgY2FsbCwgSSB1bmRlcnN0b29kIGZyb20gdGhlbSB0 aGF0IE9MU1J2MiBpcyBub3QgaW5kZXBlbmRlbnQgZnJvbSAgUkZDNjEzMC4gTm93LCBsZXQgbWUg YXNzdW1lIEkga25vdyB0aGVyZSBhcmUgcm91dGVycyBpbmRlcGVuZGVudCBvZiB0aGVpcg0KIFJG QzYxMzAgaW50ZXJmYWNlLCB0aGVuIHRoaXMgb3B0aW1pc2F0aW9uIHByb3Bvc2FsICBpcyBtb3N0 bHkgdXBkYXRpbmcgIFJGQzYxMzAsIHRoZXJlZm9yZSwgdGhlIGNoYW5nZXMgcmVjb21tZW5kZWQg YnkgdGhlIGRyYWZ0IHRvIHRoZSA3MTgxIGlzICBvbmx5IGEgbXVzdCBpZiB0aGVyZSBpcyBkZXBl bmRhbmN5LCBvdGhlcndpc2UsIHBsZWFzZSBtZW50aW9uIHRoYXQgdGhlICBmdWxsIGNoYW5nZXMg cmVxdWlyZWQgaXMgYSBtdXN0IGV2ZW4gaWYgT0xTUnYyIGlzIG5vdCBkZXBlbmRlbnQgb24gNjEz MC4NCiBGdXJ0aGVybW9yZSwgaWYgdGhlcmUgYXJlIHBvc3NpYmlsaXR5IG9mIG90aGVyIHByb3Rv Y29sIG90aGVyIHRoYW4gT0xTUnYyICByb3V0ZXJzIHRvIHVzZSB0aGlzIGRyYWZ0LCB0aGVuIG1l bnRpb24gdGhhdCBjbGVhcmx5IGFuZCBtZW50aW9uIHRoYXQgdGhlICBNdXN0IGlzIG9mIGFsbCBj aGFuZ2VzIG9mIHNlY3Rpb24gNC4NCg0KQ01EOiBJIGp1c3QgY2FuJ3QgcGFyc2UgdGhhdC4gQnV0 IHRoZSBwYXJ0IEkgZGlkIHVuZGVyc3RhbmQgaXMganVzdCByZXBlYXRpbmcgdGhlIHNhbWUgbWlz cmVhZGluZy4NCg0KVGhlIDcxODEgaXMgZGVwZW5kZW50IG9uIDYxMzAuIFNvIG5vIG5lZWQgdG8g dXBkYXRlIG90aGVyIGluZGVwZW5kZW50IHRoYXQgYXJlIG5vdCBzdGFuZGFyZHMgb24gSUVURi4N Cg0KQ01EOiBTdGlsbCBjYW7igJl0IHBhcnNlIHRoYXQuDQoNCiBBQj4gdG8gYXZvaWQgY29uZnVz aW9uIGlmIHRoaXMgdXBkYXRlIGlzIG9ubHkgZm9yIE9MU1J2MiByb3V0ZXJzIHRoZW4gIG1lbnRp b24gdGhhdCBpbiBpdHMgdGl0bGUuIFNvIHRoZSB0aXRsZSB3aWxsIGFkZCB3b3JkcyAiZm9yIE9M U1J2MiAgcm91dGVycy4NCg0KQ01EOiBUaGUgb25seSBjb25mdXNpb24gaXMgeW91cnMuIFRoZXJl J3Mgbm8gc3VnZ2VzdGlvbiBvZiB0aGF0IGFueXdoZXJlLCBhbmQgaXQncyBub3Qgc28uDQoNClll cy4gSSBhbSBhIHJlYWRlciBvZiB0aGUgZHJhZnQgYW5kIHlvdSBhcmUgdGhlIGF1dGhvci4gU28g bm93IHRoZSBhdXRob3Igbm90aWNlIHRoZSByZWFkZXIgY29uZnVzaW9uLCB3aGljaCBjYW4gaGFw cGVuIGFnYWluIHdpdGggb3RoZXIgcmVhZGVycyBvbiBmdXR1cmUsIEkgaG9wZSB0aGUgV0cgY29u c2lkZXJzIHRoaXMgaXNzdWUuDQoNCkNNRDogU29tZXRpbWVzIHdoZW4gdGhlcmUgaXMgY29uZnVz aW9uIGl04oCZcyBkb3duIHRvIHRoZSBkcmFmdC4gU29tZXRpbWVzIGl04oCZcyBkb3duIHRvIHRo ZSByZWFkZXIuIFlvdSBzZWVtIHRvIGJlIHRoZSBvbmx5IG9uZSB3aXRoIGEgcHJvYmxlbS4NCg0K Q01EOiBMZXTigJlzIGJlIGNsZWFyLiBUaGlzIGlzIGEgdmVyeSBzaW1wbGUgbGl0dGxlIGRyYWZ0 LCBkb2luZyBzb21ldGhpbmcgcmVhbGx5IHF1aXRlIHN0cmFpZ2h0Zm9yd2FyZCDigJMgZXh0ZW5k aW5nIHRvIHR3byBob3BzIHRoYXQgYWxyZWFkeSBkb25lIGF0IG9uZSBob3AuIE5vdGhpbmcgaXMg cGVyZmVjdCBvZiBjb3Vyc2UsIGFuZCBpbXByb3ZpbmcgY2hhbmdlIGlzIGFsd2F5cyBwb3NzaWJs ZS4gQnV0IG5vdGhpbmcgaW4gdGhpcyB0aHJlYWQgaGFzIG1hZGUgYW55IHN1Y2ggc3VnZ2VzdGlv bi4gKEkgbWlnaHQgcGVyaGFwcyBtYWtlIHR3byBlZGl0cy4gQnV0IGJvdGggbXkgc3VnZ2VzdGlv biwgYW5kIG5vdCBkaXNjdXNzZWQgd2l0aCBjby1hdXRob3IuKQ0KDQpBQg0KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK VGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGlu dGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0 ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBp dCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D2070FGLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0K c3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbW1lbnRzIGJl bG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LS0NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RvcGhl ciBEZWFybG92ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5TZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFu Y2UgR3JvdXA8YnI+DQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lz IENhcGFiaWxpdHk8YnI+DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZTxi cj4NCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00y IDhITiwgVUs8YnI+DQpUZWw6ICYjNDM7NDQgMTI0NSAyNDIxOTQmbmJzcDt8Jm5ic3A7IEZheDog JiM0Mzs0NCAxMjQ1IDI0MjEyNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25l Ij5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+DQogfCBodHRwOi8vd3d3 LmJhZXN5c3RlbXMuY29tPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CQUUgU3lzdGVt cyAoT3BlcmF0aW9ucykgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhv dXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdo LCBIYW50cywgR1UxNCA2WVUsIFVLPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdh bGVzIE5vOiAxOTk2Njg3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFiZHVzc2FsYW0gQmFyeXVuIFttYWlsdG86YWJk dXNzYWxhbWJhcnl1bkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTIgQXVndXN0IDIw MTQgMTY6NTU8YnI+DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0K PGI+Q2M6PC9iPiBtYW5ldEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tYW5ldC1uaGRwLW9wdGltaXph dGlvbkB0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSAjNTIg KG5oZHAtb3B0aW1pemF0aW9uKTogQ29uZnVzZWQgcGFyYWdyYXBoICMxIChFZGl0b3JpYWwgaXNz dWVzKTwvc3Bhbj48YnI+DQo8YnI+DQpPbiBUdWVzZGF5LCBBdWd1c3QgMTIsIDIwMTQsIERlYXJs b3ZlLCBDaHJpc3RvcGhlciAoVUspIHdyb3RlOjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5DTUQ6IEFjdHVhbGx5IGdldHRpbmcgaGFyZCB0byB3b3JrIHRoaXMgb3V0LiBCdXQg aWYgaXQgZG9lc27igJl0IHNheSBDTUQgdGhlbiBJIGRpZG7igJl0LiBVbmxlc3MgYSBxdW90ZSBm cm9tIHRoZSBkcmFmdC48L3NwYW4+PGJyPg0KPGJyPg0KJm5ic3A7VGhlIGRyYWZ0IHN0YXRlcyBp biBzZWN0aW9uIDM6PGJyPg0KPGJyPg0KJm5ic3A7VGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMg W1JGQzYxMzBdLiAmbmJzcDtUaGUgb3B0aW1pemF0aW9uIHByZXNlbnRlZCBpbjxicj4NCiZuYnNw OyAmbmJzcDsgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIHNpbXBseSBwZXJtaXNzaXZlLCBhcyBpdCBh bGxvd3MgcmV0YWluaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyBpbmZvcm1hdGlvbiB3aGljaCBvdGhl cndpc2Ugd291bGQgaGF2ZSBiZWVuIHJlbW92ZWQsIGJ1dCBkb2VzIG5vdCB1c2U8YnI+DQombmJz cDsgJm5ic3A7IHRoYXQgaW5mb3JtYXRpb24gZXhjZXB0IHdoZW4gaXQgY291bGQgaGF2ZSBiZWVu IHVzZWQgYnkgW1JGQzYxMzBdLjxicj4NCiZuYnNwOyAmbmJzcDsgVGhpcyBjYW4sIGluIHNvbWUg Y2FzZXMsIGVuc3VyZSB0aGF0IHRoZSBzeW1tZXRyaWMgMi1ob3AgbmVpZ2hib3Job29kPGJyPg0K Jm5ic3A7ICZuYnNwOyBpcyBtb3JlIHJvYnVzdCBhZ2FpbnN0IHRlbXBvcmFyeSBsaW5rIHF1YWxp dHkgY2hhbmdlcywgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyBjb25zZXF1ZW50bHkgeWllbGQgYSBt b3JlIHN0YWJsZSBuZXR3b3JrLiAmbmJzcDtUaGUgb25seSBvdGhlciBjb25zZXF1ZW5jZTxicj4N CiZuYnNwOyAmbmJzcDsgb2YgdGhpcyBvcHRpbWl6YXRpb24gaXMgdGhhdCBzdGF0ZSBmb3Igc29t ZSBvdGhlcndpc2UgZXhwaXJlZCAyLUhvcDxicj4NCiZuYnNwOyAmbmJzcDsgVHVwbGVzIG1heSBi ZSBtYWludGFpbmVkIGZvciBsb25nZXIuPGJyPg0KPGJyPg0KJm5ic3A7QWJkdXNzYWxhbSBCYXJ5 dW4gQ29tbWVudCAoQUIpJmd0OyB0aGUgcGFyYWdyYXBoIHN0YXJ0cyB0aGF0IGl0IHVwZGF0ZXMg NjEzMCAmbmJzcDt3aGljaCBpcyByZXBlYXRlZCBtYW55IHRpbWVzIGJlZm9yZS4gVGhlIGFib3Zl IHBhcmFncmFwaCBoYXMgbm8gJm5ic3A7YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQuIFBsZWFzZSBy ZWZlciBoZXJlIHRvIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50cyBvZiAmbmJzcDt0aGUgdXBkYXRl ZCBzdGFuZGFyZHMgNjEzMCBhbmQgNzE4MSwgYW5kDQogbWVudGlvbiBmaXJzdCB0aGF0IHRoZWly ICZuYnNwO2FwcGxpY2FiaWxpdHkgYXBwbGllcyBmb3IgdGhpcyB1cGRhdGUgcHJvcG9zYWwuIFRo aXMgaXMgdG8gYXZvaWQgJm5ic3A7Y29uZnVzaW9uLjxicj4NCjxicj4NCkNNRDogTm8uIFRoaXMg ZHJhZnQgdXBkYXRlcyBSRkMgNjEzMC4gVGhhdCBpcyB0aGUga2V5IGNlbnRyYWwgZmFjdCBhYm91 dCB3aGVyZSBpdCBpcyBhcHBsaWNhYmxlLiBJdCdzIHNhaWQgZWFybGllciBpbiB0aGUgYWJzdHJh Y3QgYW5kIGludHJvZHVjdGlvbiBiZWNhdXNlIGl0J3MgdGhlIGtleSBmYWN0IGFib3V0IHRoZSB3 aG9sZSBzcGVjaWZpY2F0aW9uLiBCdXQgdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHN0YW5k cyBhbG9uZSwgYW5kIHdpbGwNCiByZXBlYXQgdGhpbmdzIHNhaWQgaW4gdGhlIGludHJvZHVjdGlv bi4gSW4gZmFjdCB0aGF0J3MgdGhlIG5hdHVyZSBvZiBpbnRyb2R1Y3Rpb25zLCBtYW55IHRoaW5n cyBzYWlkIHRoZXJlIGFyZSBzYWlkIGluIG1vcmUgZGV0YWlsIGxhdGVyLiAoSW4gdGhlIGNhc2Ug b2YgYWJzdHJhY3RzIGV2ZXJ5dGhpbmcgc2FpZCB0aGVyZSBpcyBzYWlkIGluIG1vcmUgZGV0YWls IGxhdGVyLik8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0FCXSB0aGUg bWFpbiBwb2ludCBpcyB0aGUmbmJzcDthcHBsaWNhYmlsaXR5IHdpdGhpbiB0aGUgTUFORVQgc28g ZHJhZnQmbmJzcDtzaG91bGQgaGF2ZSB0aGF0Jm5ic3A7Y2xlYXIgc3RhdGVkLCBhbmQgaWYgdGhp cyB1cGRhdGUgYWNjZXB0cyB0aGUgc2FtZSBhcHBsaWNhYmlsaXR5IG9mIDYxMzAgYW5kIDcxODEu Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkNNRDogSWYgeW91IHVwZGF0ZSBzb21ldGhpbmcgeW91IGRvIG5vdCBuZWVkIHRv IHJlcGVhdCBldmVyeXRoaW5nIGFib3V0IGl0LiBJZiB0aGUgYXBwbGljYWJpbGl0eSB3ZXJlIGNo YW5nZWQgeW914oCZZCBuZWVkIHRvIHNheSBzbywgYnV0IG5vdCBpZiBub3QuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5i c3A7VGhlIGRyYWZ0IHN0YXRlcyBpbiBzZWN0aW9uIDM6PGJyPg0KJm5ic3A7IFRoaXMgc3BlY2lm aWNhdGlvbiBhbHNvIHVwZGF0ZXMgW1JGQzcxODFdLiAmbmJzcDtUaGlzIGNvdWxkIGJlIGF2b2lk ZWQgYnk8YnI+DQombmJzcDsgJm5ic3A7IHNpbXBseSBub3RpbmcgdGhhdCB0aGlzIHNwZWNpZmlj YXRpb24gZGVzY3JpYmVzIGhvdyB0aGUgdXBkYXRlcyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgW1JG QzYxMzBdIG1heSBiZSBoYW5kbGVkIHNvIGFzIHRvIGJlIGludmlzaWJsZSB0byBhbnkgb3RoZXIg cHJvdG9jb2w8YnI+DQombmJzcDsgJm5ic3A7IHVzaW5nIGl0Ljxicj4NCjxicj4NCiZuYnNwO0FC Jmd0OyBJIHRoaW5rIHRoYXQgdGhpcyBwcm9wb3NhbCB1cGRhdGUgaXMgZm9yIG9ubHkgT0xTUnYy IHJvdXRlcnMsIHRoaXMgaXMgJm5ic3A7Y2xlYXIgZnJvbSB0aGUgYWJzdHJhY3QuIEhvd2V2ZXIs IHRoZSBhYm92ZSBjb25mdXNlcyB0aGF0IGFzIHNlcGFyYXRpbmcgJm5ic3A7dGhlIHVwZGF0ZSBv ZiBtZW50aW9uaW5nIHZpc2liaWxpdHkgb2YgYW55IG90aGVyIHByb3RvY29sLiBJIGRvbid0IHRo aW5rICZuYnNwO3RoaXMgdXBkYXRlIGNhbiBiZSB1c2VkIGZvciBBT0RWdjINCiAoaWYgSSBtaXN0 YWtlbiBwbGVhc2UgYW1lbmQgdGhlIHRleHQgdG8gJm5ic3A7YXZvaWQgY29uZnVzaW9uKS48YnI+ DQo8YnI+DQpDTUQ6IE5vLCBhZ2Fpbi4gU3RhdGluZyB0aGF0IGl0IGFsc28gdXBkYXRlcyBSRkM3 MTgxIGxhdGVyIG9uIGlzIGNvcnJlY3QuIFRoZXJlJ3Mgbm8gc3VnZ2VzdGlvbiB0aGF0IHRoaXMg aXMgdGhlIG9ubHkgcG9zc2liaWxpdHkuIFVwZGF0ZXMgWCBhbmQgWSBpbiBubyB3YXkgaW1wbGll cyBvbmx5IHVwZGF0ZXMgWCBpbiBZIGNvbnRleHQuIEl0IHdvdWxkIGlmIGl0IHdlcmUgc28gbGlt aXRlZCB0aGF0IHlvdSdkIHNheSBzbyAodW5sZXNzIG9idmlvdXMpLjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFCJmd0OyZuYnNwO1doZW4gd2UmbmJzcDtzYXkgTUFORVQgd2UmbmJz cDtNVVNUIG5vdCBpZ25vcmUgdGhhdCB0aGVyZSBhcmUgcHJvYWN0aXZlIGFuZCByZWFjdGl2ZSBy b3V0ZXJzLiBTbyBpbiB0aGUgZHJhZnQgaWdub3JlcyByZWFjdGl2ZSByb3V0aW5nIGNoYW5nZXMu IFNvIGRvZXMgdGhlIFdHJm5ic3A7c3RpbGwgdGhpbmsgd2Ugc2hvdWxkIG5vdCBtZW50aW9uIGNs ZWFybHkgdGhhdCB0aGlzIHVwZGF0ZSBpcyBmb3IgYm90aCByZWFjdGl2ZSBhbmQNCiBwcm9hY3Rp dmUgb3IgY2xlYXJseSB0aGF0IGl0IGlzIGZvciBwcm9hY3RpdmUgb25seS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q01E OiBUaGlzIGlzIGFuIHVwZGF0ZSB0byBOSERQIGFuZCBPTFNSdjIuIFRob3NlIGFyZSBub3QgcmVh Y3RpdmUuIFJlYWN0aXZlIHByb3RvY29scyBhcmUgaXJyZWxldmFudCBoZXJlLiBJZiBhIHByb3Rv Y29scyBzdWNoIGFzIEFPRFZ2MiBjaG9zZSB0byB1c2UgTkhEUCwNCiBpdCB3b3VsZCBqdXN0IGJl IHRoZSBwcm9hY3RpdmUgcGFydCBvZiB0aGlzIHByb3RvY29sIHRoYXQgd291bGQgYmUgYWZmZWN0 ZWQuIFNvIHRoaXMgaXMgYW5vdGhlciBwb2ludGxlc3Mgc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFCJmd0OyZu YnNwO0kgdGhpbmsgd2hlbiBkcmFmdCZuYnNwO3dhcyBhZG9wdGVkIG1hbnkgb2YgV0cgY29uc2lk ZXJlZCBpdCBhcyBPTFNSdjIvTkhEUCBvcHRpbWl6YXRpb24gKG5vdCBzdXJlIGJ1dCB0aGUgY2hh aXIgYW5kIEFEIGNhbiBrbm93IGJldHRlcikuIEZ1cnRoZXJtb3JlLCB0aGVyZSBzaG91bGQgYmUg ZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byBBT0RWdjIgdG8gc2VlIGFwcGxpY2FiaWxpdHkuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPk5vLiBOb3QgcmVsZXZhbnQuIEFPRFZ2MiBpcyBhbHNvIGluIHNlcmlvdXMgbmVlZCBvZiB3 b3JrLCBhbmQgd2FpdGluZyBmb3IgdGhhdCB3b3VsZCBiZSBzZXJpb3VzbHkgY291bnRlcnByb2R1 Y3RpdmUsIGFuZCBzdGlsbCBub3QgcmVsZXZhbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5ic3A7VGhlIGRyYWZ0IHN0YXRlcyBpbiBzZWN0aW9u IDM6PGJyPg0KPGJyPg0KJm5ic3A7IEhvd2V2ZXIgYXMgaXQgaXMga25vd24gdGhhdCBzb21lIGlt cGxlbWVudGF0aW9ucyBvZjxicj4NCiZuYnNwOyAmbmJzcDsgW1JGQzcxODFdIGFyZSBub3QgaW5k ZXBlbmRlbnQgb2YgdGhlIGltcGxlbWVudGF0aW9uIG9mIFtSRkM2MTMwXSB0aGF0PGJyPg0KJm5i c3A7ICZuYnNwOyB0aGV5IHVzZSwgaXQgaXMgdXNlZnVsIHRvIGluZGljYXRlIHRoZSBkaXJlY3Qg aW1wYWN0IG9uIFtSRkM3MTgxXS48YnI+DQo8YnI+DQombmJzcDtBQiZndDsgd2hlbiB5b3Ugc2F5 ICZxdW90O2l0IGlzIGtub3duJnF1b3Q7LCB5b3Ugc2hvdWxkIG1lYW4ga25vd24gYnkgSUVURiBz byBwbGVhc2UgJm5ic3A7cmVmZXIgdG8gdGhhdCBrbm93biBkb2N1bWVudC9yZWZlcmVuY2Ugb3Ro ZXJ3aXNlIGl0IGlzIG9ubHkga25vd24gYnkgc29tZSAmbmJzcDtwZW9wbGUuPGJyPg0KPGJyPg0K Q01EOiBJdCdzIG5vdyBrbm93biwgYmVjYXVzZSB0aGlzIGluZm9ybXMgeW91IG9mIHRoYXQuIEZh Y3RzIGFib3V0IGltcGxlbWVudGF0aW9ucyBhcmUgaGFyZCB0byBwaW4gZG93biB0byByZWZlcmVu Y2VzLiBIb3dldmVyICZxdW90O2l0IGlzIGtub3duIHRoYXQmcXVvdDsgY291bGQgYmUgcmVtb3Zl ZCBhcyB0YXV0b2xvZ2ljYWwuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Tm8uIEkgbWVhbiB3aXRoaW4gUkZDNzE4MSBJTUhPIGl0Jm5ic3A7aXMgZGVwZW5k ZW50IG9uIDYxMzAsJm5ic3A7c28gd2UgZG9uJ3QgaGF2ZSBpbmRlcGVuZGVudC4mbmJzcDsmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Q01EOiBJIHJlYWxseSBhbSBub3QgZ29pbmcgdG8gZXhwbGFpbiB0aGUgcmVsYXRpb25z aGlwIGhlcmUsIGFuZCBob3cgeW91IGNhbiB3cml0ZSBzZXBhcmF0ZSBvciBpbnRlZ3JhdGVkIGlt cGxlbWVudGF0aW9ucy4gQnV0IHBlcmhhcHMg4oCcc2VwYXJhdGUgZnJvbeKAnSBtaWdodA0KIGJl IGJldHRlciB0aGFuIOKAnGluZGVwZW5kZW50IG9m4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCklNSE8gSSByZW1lbWJlciBkaXNjdXNzaW5nIHRo aXMgaXNzdWUgd2l0aCBPTFNSdjIgYXV0aG9ycyBhdCBJRVNHICZuYnNwO2xhc3QgY2FsbCwgSSB1 bmRlcnN0b29kIGZyb20gdGhlbSB0aGF0IE9MU1J2MiBpcyBub3QgaW5kZXBlbmRlbnQgZnJvbSAm bmJzcDtSRkM2MTMwLiBOb3csIGxldCBtZSBhc3N1bWUgSSBrbm93IHRoZXJlIGFyZSByb3V0ZXJz IGluZGVwZW5kZW50IG9mIHRoZWlyPGJyPg0KJm5ic3A7UkZDNjEzMCBpbnRlcmZhY2UsIHRoZW4g dGhpcyBvcHRpbWlzYXRpb24gcHJvcG9zYWwgJm5ic3A7aXMgbW9zdGx5IHVwZGF0aW5nICZuYnNw O1JGQzYxMzAsIHRoZXJlZm9yZSwgdGhlIGNoYW5nZXMgcmVjb21tZW5kZWQgYnkgdGhlIGRyYWZ0 IHRvIHRoZSA3MTgxIGlzICZuYnNwO29ubHkgYSBtdXN0IGlmIHRoZXJlIGlzIGRlcGVuZGFuY3ks IG90aGVyd2lzZSwgcGxlYXNlIG1lbnRpb24gdGhhdCB0aGUgJm5ic3A7ZnVsbCBjaGFuZ2VzIHJl cXVpcmVkIGlzIGEgbXVzdCBldmVuIGlmDQogT0xTUnYyIGlzIG5vdCBkZXBlbmRlbnQgb24gNjEz MC48YnI+DQombmJzcDtGdXJ0aGVybW9yZSwgaWYgdGhlcmUgYXJlIHBvc3NpYmlsaXR5IG9mIG90 aGVyIHByb3RvY29sIG90aGVyIHRoYW4gT0xTUnYyICZuYnNwO3JvdXRlcnMgdG8gdXNlIHRoaXMg ZHJhZnQsIHRoZW4gbWVudGlvbiB0aGF0IGNsZWFybHkgYW5kIG1lbnRpb24gdGhhdCB0aGUgJm5i c3A7TXVzdCBpcyBvZiBhbGwgY2hhbmdlcyBvZiBzZWN0aW9uIDQuPGJyPg0KPGJyPg0KQ01EOiBJ IGp1c3QgY2FuJ3QgcGFyc2UgdGhhdC4gQnV0IHRoZSBwYXJ0IEkgZGlkIHVuZGVyc3RhbmQgaXMg anVzdCByZXBlYXRpbmcgdGhlIHNhbWUgbWlzcmVhZGluZy48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgNzE4MSBpcyBkZXBlbmRlbnQgb24gNjEzMC4g U28gbm8gbmVlZCB0byB1cGRhdGUgb3RoZXIgaW5kZXBlbmRlbnQgdGhhdCBhcmUgbm90IHN0YW5k YXJkcyBvbiBJRVRGLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DTUQ6IFN0aWxsIGNhbuKAmXQgcGFyc2UgdGhhdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8YnI+DQombmJzcDtBQiZndDsgdG8gYXZvaWQgY29uZnVzaW9uIGlmIHRoaXMgdXBkYXRl IGlzIG9ubHkgZm9yIE9MU1J2MiByb3V0ZXJzIHRoZW4gJm5ic3A7bWVudGlvbiB0aGF0IGluIGl0 cyB0aXRsZS4gU28gdGhlIHRpdGxlIHdpbGwgYWRkIHdvcmRzICZxdW90O2ZvciBPTFNSdjIgJm5i c3A7cm91dGVycy48YnI+DQo8YnI+DQpDTUQ6IFRoZSBvbmx5IGNvbmZ1c2lvbiBpcyB5b3Vycy4g VGhlcmUncyBubyBzdWdnZXN0aW9uIG9mIHRoYXQgYW55d2hlcmUsIGFuZCBpdCdzIG5vdCBzby48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMuIEkgYW0gYSByZWFkZXIgb2YgdGhl IGRyYWZ0IGFuZCB5b3UgYXJlIHRoZSBhdXRob3IuIFNvIG5vdyB0aGUgYXV0aG9yIG5vdGljZSB0 aGUgcmVhZGVyIGNvbmZ1c2lvbiwgd2hpY2ggY2FuIGhhcHBlbiBhZ2FpbiB3aXRoIG90aGVyIHJl YWRlcnMgb24gZnV0dXJlLCBJIGhvcGUgdGhlIFdHIGNvbnNpZGVycyB0aGlzIGlzc3VlLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5DTUQ6IFNvbWV0aW1lcyB3aGVuIHRoZXJlIGlzIGNvbmZ1c2lvbiBpdOKAmXMgZG93biB0 byB0aGUgZHJhZnQuIFNvbWV0aW1lcyBpdOKAmXMgZG93biB0byB0aGUgcmVhZGVyLiBZb3Ugc2Vl bSB0byBiZSB0aGUgb25seSBvbmUgd2l0aCBhIHByb2JsZW0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DTUQ6IExldOKA mXMgYmUgY2xlYXIuIFRoaXMgaXMgYSB2ZXJ5IHNpbXBsZSBsaXR0bGUgZHJhZnQsIGRvaW5nIHNv bWV0aGluZyByZWFsbHkgcXVpdGUgc3RyYWlnaHRmb3J3YXJkIOKAkyBleHRlbmRpbmcgdG8gdHdv IGhvcHMgdGhhdCBhbHJlYWR5IGRvbmUgYXQgb25lIGhvcC4NCiBOb3RoaW5nIGlzIHBlcmZlY3Qg b2YgY291cnNlLCBhbmQgaW1wcm92aW5nIGNoYW5nZSBpcyBhbHdheXMgcG9zc2libGUuIEJ1dCBu b3RoaW5nIGluIHRoaXMgdGhyZWFkIGhhcyBtYWRlIGFueSBzdWNoIHN1Z2dlc3Rpb24uIChJIG1p Z2h0IHBlcmhhcHMgbWFrZSB0d28gZWRpdHMuIEJ1dCBib3RoIG15IHN1Z2dlc3Rpb24sIGFuZCBu b3QgZGlzY3Vzc2VkIHdpdGggY28tYXV0aG9yLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFCPHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4qKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKjxicj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwg dG8gdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUg aXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZb3Ugc2hvdWxk IG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJy PgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKio8L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D2070FGLKXM0002VGREEN_-- From nobody Tue Aug 12 13: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 E86A21A09AB for ; Tue, 12 Aug 2014 13:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 2zyxaWwguPKU for ; Tue, 12 Aug 2014 13:13:27 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC451A0110 for ; Tue, 12 Aug 2014 13:13:27 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so13683463vcb.8 for ; Tue, 12 Aug 2014 13:13:26 -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=oai4AvU1ZlTKJz/EMpeguRtfWD4PCkYVGKOK2LS5haY=; b=eHUc2TzGLYzDsykFTMhqynKoFiIOoiHazK2B6DnvMzdd2C57k8ukvjhqMyLjh+Lh79 rrNP3X/X0qzRxHeW38qrARDtw4R77I+HVrAPk7mpMOTtfvUD1GXAeUF6wKOIoDkqxLm5 yXEEhgKw88riMe5UDq33ymjgH08Qc2/gc+Yb8= 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=oai4AvU1ZlTKJz/EMpeguRtfWD4PCkYVGKOK2LS5haY=; b=g9mogLigwEVjmj4igl6d1HyN8xW3ZKYHLRcDw2Jq/5ok0lCOByrFIXmL00kYTViu6p bovqMjVdiLZuv0nV0FZH+esfeuFBaaO4w7KnMzrut67TofG4y26PeyB4UabMSUKlU+iF AEkkQmkb7Q1z3wjSjy9GmNzdtum97bdP1coDbwJaaeWLNoVuGw5bR61GPFJvef+ne2h0 TgFmhV67A18tCO9l1alSfW/twYs4gtdSMSsT+XijXbvqxPKZfU9BUiH+xDRfgYf7DKXu 8jF5aKIdmkoPBLoTKJbiEaFYfBdD5YSj0nVwCVhdhi53GhLhD2n3Te0WDFSsPh39ayJo KLMQ== X-Gm-Message-State: ALoCoQlwbvIvW3fcSXEPaKToSjIPel7y9iBTYt43IZHtVCf6ww3AjU4B3hODMQG/wvQZ0jRdkFgM MIME-Version: 1.0 X-Received: by 10.52.142.102 with SMTP id rv6mr46714vdb.26.1407874406759; Tue, 12 Aug 2014 13:13:26 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Tue, 12 Aug 2014 13:13:26 -0700 (PDT) In-Reply-To: <20140812193035.5127.64469.idtracker@ietfa.amsl.com> References: <20140812193035.5127.64469.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 13:13:26 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CgqE1yeFH0O9lbw9-vT3TJAAGwM Subject: [manet] Fwd: New Version Notification for draft-clausen-manet-olsrv2-sec-threats-01.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, 12 Aug 2014 20:13:30 -0000 Hi, we have submitted a new revision of the OLSRv2-sec-threats draft. Main difference is a new section analyzing protection of RFC7181 and RFC7183 against the vulnerabilities described in the draft. Our plan is to ask for WG adoption at the end of August. Best regards Ulrich ---------- Forwarded message ---------- From: Date: Tue, Aug 12, 2014 at 12:30 PM Subject: New Version Notification for draft-clausen-manet-olsrv2-sec-threats-01.txt To: Thomas Clausen , Ulrich Herberg , "Thomas H. Clausen" , Jiazi Yi A new version of I-D, draft-clausen-manet-olsrv2-sec-threats-01.txt has been successfully submitted by Ulrich Herberg and posted to the IETF repository. Name: draft-clausen-manet-olsrv2-sec-threats Revision: 01 Title: Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2) Document date: 2014-08-12 Group: Individual Submission Pages: 24 URL: http://www.ietf.org/internet-drafts/draft-clausen-manet-olsrv2-sec-threats-01.txt Status: https://datatracker.ietf.org/doc/draft-clausen-manet-olsrv2-sec-threats/ Htmlized: http://tools.ietf.org/html/draft-clausen-manet-olsrv2-sec-threats-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-clausen-manet-olsrv2-sec-threats-01 Abstract: This document analyzes common security threats of the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It then analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2, and how the vulnerabilities are mitigated. 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 From nobody Tue Aug 12 19:28: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 765D41A6F36; Tue, 12 Aug 2014 19:28:51 -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 6AKh8822WNUk; Tue, 12 Aug 2014 19:28:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE52C1A6FDC; Tue, 12 Aug 2014 19:28:45 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140813022845.5536.82487.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 19:28:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/VfGH6-4jbGWJ54YaazXDM8qJQIU Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-mib-13.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, 13 Aug 2014 02:28:51 -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-13.txt Pages : 66 Date : 2014-08-12 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-smf-mib-13 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 Aug 12 23:29: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 0111A1A6FFB; Tue, 12 Aug 2014 23:29:37 -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 SCc7-m7M0JvK; Tue, 12 Aug 2014 23:29:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 530331A6FFF; Tue, 12 Aug 2014 23:29: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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140813062933.19571.76418.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 23:29:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/I-zCwf-49h3hDyotPapaLYoaWLw Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-06.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, 13 Aug 2014 06:29:37 -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 : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Bo Berry Greg Harrison Shawn Jury Darryl Satterwhite Filename : draft-ietf-manet-dlep-06.txt Pages : 53 Date : 2014-08-12 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-dlep-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-06 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 Aug 12 23:34: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 0448E1A7000 for ; Tue, 12 Aug 2014 23:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 oGzYl_-wxfnK for ; Tue, 12 Aug 2014 23:34:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F370C1A6FFB for ; Tue, 12 Aug 2014 23:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=798; q=dns/txt; s=iport; t=1407911678; x=1409121278; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=xV9q90MWPbrw8jLvOY3AUPfL4c/hOV9Rb+aC8WwRfZk=; b=MuyS3uw5WCVloTHAN/C7l+4thch7yP9YeDdN6peW65tgFU+kDK9IMDv2 fGey2OpMQYXVe7M/MpcIvinCM37Lo9P0qDn3xnne0Jqef96iA/CeJQWr3 ii1XUwJ2e8BL9JIyEEatpwSlZhwTEabWzxzG4TzHFVsXZORNXO4B/jIC3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAAUG61OtJV2b/2dsb2JhbABagw2BLdYHFneECoELAYEAJwSIVaEHpGcXkwKBHQWRHYsclH6DXII0 X-IronPort-AV: E=Sophos;i="5.01,855,1400025600"; d="scan'208";a="344027363" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 13 Aug 2014 06:34:38 +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 s7D6YbEk004829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Aug 2014 06:34:37 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 01:34:37 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: DLEP-06 Thread-Index: AQHPtsCm8bF2enkvEEWjvaUFXyrxJA== Date: Wed, 13 Aug 2014 06:34:36 +0000 Message-ID: <1AC6F6CB-E63D-42EA-B279-01F6CCC0DFB9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.225.103] 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/oQQBeKs3pQ76qi6shWpElm-FWlM Subject: [manet] DLEP-06 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, 13 Aug 2014 06:34:39 -0000 Working Group participants,=20 I've posted a new version of DLEP. There are some caveats here:=20 1. The Appendix is pretty much broken. If I were you, I'd probably ignore i= t. It will be fixed in an 07 version.=20 2. With this version, there is a new proposed "DLEP Vendor Extension" TLV. = It's not documented correctly - the doc refers to a Vendor OUI, which I don= 't think will work. I believe that if vendor extensions are used, they are = going to be *device specific*, not *vendor specific*. So if anyone has reco= mmendations on how to tighten that up, it would be appreciated.=20 3. There is also verbiage in a new section 3 on "Mandatory versus Optional"= items. It probably isn't clear=85 That said, I've adjusted my fire suit, so=85=85 Flame on. Regards, Stan= From nobody Wed Aug 13 01:56: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 9DCED1A8029 for ; Wed, 13 Aug 2014 01:56:06 -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 1TgUweELSpvD for ; Wed, 13 Aug 2014 01:56:05 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E7A1A8028 for ; Wed, 13 Aug 2014 01:56:05 -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; Wed, 13 Aug 2014 09:55:34 +0100 From: Rick Taylor To: "Stan Ratliff (sratliff)" , manet IETF Thread-Topic: [manet] DLEP-06 Thread-Index: AQHPttRXqKUI08bMPkSWYy3bT8FZzQ== Date: Wed, 13 Aug 2014 08:55:33 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801148EA03E@tss-server1.home.tropicalstormsoftware.com> References: <1AC6F6CB-E63D-42EA-B279-01F6CCC0DFB9@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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/8fzLJelTUS23udnrxjPg-YU4DD0 Subject: Re: [manet] DLEP-06 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, 13 Aug 2014 08:56:06 -0000 Thank you for your hard work Stan.=0A= =0A= Given the issues you have outlined, can we look forward to a draft-07 =0A= fairly soon?=0A= =0A= Rick Taylor=0A= =0A= =0A= On 13/08/14 07:34, Stan Ratliff (sratliff) wrote:=0A= > Working Group participants,=0A= >=0A= > I've posted a new version of DLEP. There are some caveats here:=0A= >=0A= > 1. The Appendix is pretty much broken. If I were you, I'd probably ignore= it. It will be fixed in an 07 version.=0A= > 2. With this version, there is a new proposed "DLEP Vendor Extension" TLV= . It's not documented correctly - the doc refers to a Vendor OUI, which I d= on't think will work. I believe that if vendor extensions are used, they ar= e going to be *device specific*, not *vendor specific*. So if anyone has re= commendations on how to tighten that up, it would be appreciated.=0A= > 3. There is also verbiage in a new section 3 on "Mandatory versus Optiona= l" items. It probably isn't clear=85=0A= >=0A= > That said, I've adjusted my fire suit, so=85=85 Flame on.=0A= >=0A= > Regards,=0A= > Stan=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= =0A= From nobody Wed Aug 13 02:07: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 375711A802F for ; Wed, 13 Aug 2014 02:07:21 -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 Ag4jMIIJE7gE for ; Wed, 13 Aug 2014 02:07:18 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9861A802D for ; Wed, 13 Aug 2014 02:07:17 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 131so8053680ykp.0 for ; Wed, 13 Aug 2014 02:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mvCr2D89MElAsibfDIUbNF/sdsQh6dMq2OmQZJfZKs0=; b=WBn/j1otBh8RSg2Ic/zHchixsJcf0lXBGaNCSnIwZMu+opZi110YQt+RO4Z7qKyomL n4SGbqn/yKejuDO2RYxpTQ5bX6owXc9DJlYbuDVKzb7ujaT3VcphaOgjeCpZIpV9LcPh XLPjTadP4E7aWfQGsJOnGA8mg4/gzfpQpB0l6jNoeY7+XrFMAYt9r3rCrwEZjri2AufF yyhPqpkng9USFbQknHXKej8r668BVWwrYtIzIFZ2W+b6lhg4xh3YAO3EMCp1D6xSsnOi hJJanerIXSPVxZ5+JgXLuXyLajF6aAmleTySeTyMSnYIh0L+zYocWMF0NqJ1tfj4rV5+ ytHw== MIME-Version: 1.0 X-Received: by 10.236.116.202 with SMTP id g50mr4784660yhh.147.1407920836786; Wed, 13 Aug 2014 02:07:16 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Wed, 13 Aug 2014 02:07:16 -0700 (PDT) In-Reply-To: References: <066.0bb22f15b7c74448b0bb3821234ffc46@trac.tools.ietf.org> Date: Wed, 13 Aug 2014 11:07:16 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=20cf3036388d5942e805007f1def Archived-At: http://mailarchive.ietf.org/arch/msg/manet/uEh1BANlLs_5abqh57-GKUBVwwA Cc: "manet@ietf.org" , "draft-ietf-manet-nhdp-optimization@tools.ietf.org" Subject: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial 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, 13 Aug 2014 09:07:21 -0000 --20cf3036388d5942e805007f1def Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I hope that the WG considers this thread points, and to put in mind: 1- that RFC7181 depends on 6130 and its other normative references. IETF did not standard any independent OLSRv2 from the RFC6130. 2- MANET routers are proactive, reactive, and hybrid. 3- neighbour discovery is part of routing as the 1-hop/2-hop neighbours can become possible destinations. Any update to RFC6130 is an update to all MANET routers that use RFC6130. 4- as this WG decided to do RFC6130/RFC5444 (I disagree with the approach but it's the hard way and can be best way) before finishing its both routing standards (reactive and proactive) it is important to consider both routings needs while updating such RFCs 5444 and 6130. On Tuesday, August 12, 2014, Dearlove, Christopher (UK) wrote: > Comments below. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance 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:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > *Sent:* 12 August 2014 16:55 > *To:* Dearlove, Christopher (UK) > *Cc:* manet@ietf.org; draft-ietf-manet-nhdp-optimization@tools.ietf.org > *Subject:* Re: [manet] #52 (nhdp-optimization): Confused paragraph #1 > (Editorial issues) > > On Tuesday, August 12, 2014, Dearlove, Christopher (UK) wrote: > > > > CMD: Actually getting hard to work this out. But if it doesn=E2=80=99t sa= y CMD > then I didn=E2=80=99t. Unless a quote from the draft. > > The draft states in section 3: > > This specification updates [RFC6130]. The optimization presented in > this specification is simply permissive, as it allows retaining > information which otherwise would have been removed, but does not use > that information except when it could have been used by [RFC6130]. > This can, in some cases, ensure that the symmetric 2-hop neighborhood > is more robust against temporary link quality changes, and > consequently yield a more stable network. The only other consequence > of this optimization is that state for some otherwise expired 2-Hop > Tuples may be maintained for longer. > > Abdussalam Baryun Comment (AB)> the paragraph starts that it updates 613= 0 > which is repeated many times before. The above paragraph has no > applicability statement. Please refer here to applicability statements o= f > the updated standards 6130 and 7181, and mention first that their > applicability applies for this update proposal. This is to avoid > confusion. > > CMD: No. This draft updates RFC 6130. That is the key central fact about > where it is applicable. It's said earlier in the abstract and introductio= n > because it's the key fact about the whole specification. But the > applicability statement stands alone, and will repeat things said in the > introduction. In fact that's the nature of introductions, many things sai= d > there are said in more detail later. (In the case of abstracts everything > said there is said in more detail later.) > > > > [AB] the main point is the applicability within the MANET so draft should > have that clear stated, and if this update accepts the same applicability > of 6130 and 7181. > > > > CMD: If you update something you do not need to repeat everything about > it. If the applicability were changed you=E2=80=99d need to say so, but n= ot if not. > > We need to mention that this update does not consider reactive routing as the 6130 does. The update is an update for 6130 and 7181. You mention in the draft the word "a router" but you only mention the MANET proactive routing protocol changes. IMHO there must be refer to reactive (as future work) as long you updated 7181. > > The draft states in section 3: > This specification also updates [RFC7181]. This could be avoided by > simply noting that this specification describes how the updates to > [RFC6130] may be handled so as to be invisible to any other protocol > using it. > > AB> I think that this proposal update is for only OLSRv2 routers, this i= s > clear from the abstract. However, the above confuses that as separating > the update of mentioning visibility of any other protocol. I don't think > this update can be used for AODVv2 (if I mistaken please amend the text = to > avoid confusion). > > CMD: No, again. Stating that it also updates RFC7181 later on is correct. > There's no suggestion that this is the only possibility. Updates X and Y = in > no way implies only updates X in Y context. It would if it were so limite= d > that you'd say so (unless obvious). > Ok, so you believe this update can be done for to interface of reactive router that uses 6130. > > > AB> When we say MANET we MUST not ignore that there are proactive and > reactive routers. So in the draft ignores reactive routing changes. So do= es > the WG still think we should not mention clearly that this update is for > both reactive and proactive or clearly that it is for proactive only. > > > > CMD: This is an update to NHDP and OLSRv2. Those are not reactive. > Reactive protocols are irrelevant here. If a protocols such as AODVv2 cho= se > to use NHDP, it would just be the proactive part of this protocol that > would be affected. So this is another pointless suggestion. > > Not pointless, I suggest strongly to not ignore the fact that this update is for MANET routers and that this draft needs to mention reactive router either as future work or as that the update does not consider that routing. > > > AB> I think when draft was adopted many of WG considered it as OLSRv2/NHD= P > optimization (not sure but the chair and AD can know better). Furthermore= , > there should be discussions related to AODVv2 to see applicability. > > > > No. Not relevant. AODVv2 is also in serious need of work, and waiting for > that would be seriously counterproductive, and still not relevant. > > I did not say wait, just reactive issue discussions. I hardly find much discussion related to this draft nor analysis. We need to analyse for reactive also not only proactive. Did WG do any analysis of this update for reactive routers? The chair mentioned that usually IETF does analysis for standards, so I just want to check if the WG done some analysis before WGLC. I think there was no analysis so the efforts to analyse with reactive can be relevant. > > The draft states in section 3: > > However as it is known that some implementations of > [RFC7181] are not independent of the implementation of [RFC6130] that > they use, it is useful to indicate the direct impact on [RFC7181]. > > AB> when you say "it is known", you should mean known by IETF so please > refer to that known document/reference otherwise it is only known by som= e > people. > > CMD: It's now known, because this informs you of that. Facts about > implementations are hard to pin down to references. However "it is known > that" could be removed as tautological. > > > > No. I mean within RFC7181 IMHO it is dependent on 6130, so we don't have > independent. > > > > CMD: I really am not going to explain the relationship here, and how you > can write separate or integrated implementations. But perhaps =E2=80=9Cse= parate > from=E2=80=9D might be better than =E2=80=9Cindependent of=E2=80=9D. > > Therefore, please delete the texts mentioning independent (it is not relevant). I don't know so far any OLSRv2 standard that is separate/independent to RFC6130 NHDP. > > IMHO I remember discussing this issue with OLSRv2 authors at IESG last > call, I understood from them that OLSRv2 is not independent from RFC6130= . > Now, let me assume I know there are routers independent of their > RFC6130 interface, then this optimisation proposal is mostly updating > RFC6130, therefore, the changes recommended by the draft to the 7181 is > only a must if there is dependancy, otherwise, please mention that the > full changes required is a must even if OLSRv2 is not dependent on 6130. > Furthermore, if there are possibility of other protocol other than OLSRv= 2 > routers to use this draft, then mention that clearly and mention that th= e > Must is of all changes of section 4. > > CMD: I just can't parse that. But the part I did understand is just > repeating the same misreading. > > > > The 7181 is dependent on 6130. So no need to update other independent tha= t > are not standards on IETF. > > > > CMD: Still can=E2=80=99t parse that. > > Ok, delete below statement from the draft: { However as it is known that some implementations of [RFC7181] are not independent of the implementation of [RFC6130] that they use, it is useful to indicate the direct impact on [RFC7181]. } > > AB> to avoid confusion if this update is only for OLSRv2 routers then > mention that in its title. So the title will add words "for OLSRv2 > routers. > > CMD: The only confusion is yours. There's no suggestion of that anywhere, > and it's not so. > > > > Yes. I am a reader of the draft and you are the author. So now the author > notice the reader confusion, which can happen again with other readers on > future, I hope the WG considers this issue. > > > > CMD: Sometimes when there is confusion it=E2=80=99s down to the draft. So= metimes > it=E2=80=99s down to the reader. > > Ok, I will prepare my suggestion for editing to clarify that confusions. > You seem to be the only one with a problem. > > I know I always been in rough in this WG, it is not a problem and a reviewer's detection of confusion possibility in reading is not a problem also but a quality measure issue (can improve performance as an optimize router is sensitive to change). Please note that this WG participation is a small size so even one has a value that IETF should not ignore. AB --20cf3036388d5942e805007f1def Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I hope that the WG considers this thread points, and to put in mind:
1- that RFC7181 depends on 6130 and its=C2=A0other normative r= eferences. IETF did not standard any independent OLSRv2 from the=C2=A0RFC61= 30.=C2=A0

2- MANET routers are proactive, reactive, and hybrid.= =C2=A0

3- neighbour discovery is part of routing a= s the 1-hop/2-hop neighbours can become possible destinations. Any update t= o RFC6130 is an update to all MANET routers that use RFC6130.=C2=A0

4- as this WG decided to do RFC6130/RFC5444 (I disagree= with the=C2=A0approach=C2=A0but it's the=C2=A0hard way and=C2=A0can be= best way)=C2=A0before=C2=A0finishing its both routing=C2=A0standards (reac= tive and proactive)=C2=A0it is important to consider both routings=C2=A0nee= ds while updating such RFCs 5444 and 6130.=C2=A0

On Tuesday, August 12, 2014, Dearlove, Christopher (UK) wrote:

Comments below.=

=C2=A0

--

Christopher Dearlove

Senior Principal Engineer= , Information Assurance 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=

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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.c= om]
Sent: 12 August 2014 16:55
To: Dearlove, Christopher (UK)
Cc: manet@ietf.org; draft-ietf-manet-nhdp-optimization@too= ls.ietf.org
Subject: Re: [manet] #52 (nhdp-optimization): Confused paragraph #1 = (Editorial issues)

On Tuesday, August 12, 2014, Dearlove, Christopher (UK) wrote:

=C2=A0

CMD: Actually getting har= d to work this out. But if it doesn=E2=80=99t say CMD then I didn=E2=80=99t= . Unless a quote from the draft.

=C2=A0The draft states in section 3:

=C2=A0This specification updates [RFC6130]. =C2=A0The optimization presente= d in
=C2=A0 =C2=A0 this specification is simply permissive, as it allows retaini= ng
=C2=A0 =C2=A0 information which otherwise would have been removed, but does= not use
=C2=A0 =C2=A0 that information except when it could have been used by [RFC6= 130].
=C2=A0 =C2=A0 This can, in some cases, ensure that the symmetric 2-hop neig= hborhood
=C2=A0 =C2=A0 is more robust against temporary link quality changes, and =C2=A0 =C2=A0 consequently yield a more stable network. =C2=A0The only othe= r consequence
=C2=A0 =C2=A0 of this optimization is that state for some otherwise expired= 2-Hop
=C2=A0 =C2=A0 Tuples may be maintained for longer.

=C2=A0Abdussalam Baryun Comment (AB)> the paragraph starts that it updat= es 6130 =C2=A0which is repeated many times before. The above paragraph has = no =C2=A0applicability statement. Please refer here to applicability statem= ents of =C2=A0the updated standards 6130 and 7181, and mention first that their =C2=A0applicability applies for this update propo= sal. This is to avoid =C2=A0confusion.

CMD: No. This draft updates RFC 6130. That is the key central fact about wh= ere it is applicable. It's said earlier in the abstract and introductio= n because it's the key fact about the whole specification. But the appl= icability statement stands alone, and will repeat things said in the introduction. In fact that's the nature of i= ntroductions, many things said there are said in more detail later. (In the= case of abstracts everything said there is said in more detail later.)

=C2=A0

[AB] the main point is the=C2=A0applicability within= the MANET so draft=C2=A0should have that=C2=A0clear stated, and if this up= date accepts the same applicability of 6130 and 7181.=C2=A0

=C2=A0

CMD: If you update someth= ing you do not need to repeat everything about it. If the applicability wer= e changed you=E2=80=99d need to say so, but not if not.

We=C2=A0need= to mention=C2=A0that this update does not consider reactive routing as the= 6130 does. The update is an update for 6130 and 7181. You mention in the d= raft the word=C2=A0"a router"=C2=A0but you only mention the MANET= =C2=A0proactive routing protocol changes.=C2=A0IMHO there must be refer to = reactive (as future work)=C2=A0as long you updated 7181.=C2=A0


=C2=A0The draft states in section 3:
=C2=A0 This specification also updates [RFC7181]. =C2=A0This could be avoid= ed by
=C2=A0 =C2=A0 simply noting that this specification describes how the updat= es to
=C2=A0 =C2=A0 [RFC6130] may be handled so as to be invisible to any other p= rotocol
=C2=A0 =C2=A0 using it.

=C2=A0AB> I think that this proposal update is for only OLSRv2 routers, = this is =C2=A0clear from the abstract. However, the above confuses that as = separating =C2=A0the update of mentioning visibility of any other protocol.= I don't think =C2=A0this update can be used for AODVv2 (if I mistaken please amend the text to =C2=A0avoid confusion).

CMD: No, again. Stating that it also updates RFC7181 later on is correct. T= here's no suggestion that this is the only possibility. Updates X and Y= in no way implies only updates X in Y context. It would if it were so limi= ted that you'd say so (unless obvious).

Ok, so you believe this update can be d= one for to interface of=C2=A0reactive router that uses 6130.=C2=A0

=C2=A0

AB>=C2=A0When we=C2=A0say MANET we=C2=A0MUST not = ignore that there are proactive and reactive routers. So in the draft ignor= es reactive routing changes. So does the WG=C2=A0still think we should not = mention clearly that this update is for both reactive and proactive or clearly that it is for proactive only.=C2=A0

=C2=A0

CMD: This is an update to= NHDP and OLSRv2. Those are not reactive. Reactive protocols are irrelevant= here. If a protocols such as AODVv2 chose to use NHDP, it would just be the proactive part of this protocol that would be affecte= d. So this is another pointless suggestion.

Not pointless, I su= ggest strongly to not ignore the fact that this update is for MANET routers= and that this draft needs to mention reactive router either as future work= or as that the update does not consider that routing.=C2=A0

=C2=A0

AB>=C2=A0I think when draft=C2=A0was adopted many= of WG considered it as OLSRv2/NHDP optimization (not sure but the chair an= d AD can know better). Furthermore, there should be discussions related to = AODVv2 to see applicability.=C2=A0

=C2=A0

No. Not relevant. AODVv2 = is also in serious need of work, and waiting for that would be seriously co= unterproductive, and still not relevant.


I did not say wait, just reactive issue=C2=A0discussions. I hardly find = much=C2=A0discussion related to this draft nor analysis.=C2=A0=C2=A0We need= to analyse for reactive also not only proactive. Did WG=C2=A0do any analys= is of this update=C2=A0for reactive routers? The chair mentioned that usual= ly=C2=A0IETF does analysis for standards,=C2=A0so I just want to check if t= he WG done some analysis before WGLC. I think there was no analysis so the= =C2=A0efforts to analyse with reactive can be=C2=A0relevant.=C2=A0


=C2=A0The draft states in section 3:

=C2=A0 However as it is known that some implementations of
=C2=A0 =C2=A0 [RFC7181] are not independent of the implementation of [RFC61= 30] that
=C2=A0 =C2=A0 they use, it is useful to indicate the direct impact on [RFC7= 181].

=C2=A0AB> when you say "it is known", you should mean known by= IETF so please =C2=A0refer to that known document/reference otherwise it i= s only known by some =C2=A0people.

CMD: It's now known, because this informs you of that. Facts about impl= ementations are hard to pin down to references. However "it is known t= hat" could be removed as tautological.

=C2=A0

No. I mean within RFC7181 IMHO it=C2=A0is dependent = on 6130,=C2=A0so we don't have independent.=C2=A0=C2=A0

=C2=A0

CMD: I really am not goin= g to explain the relationship here, and how you can write separate or integ= rated implementations. But perhaps =E2=80=9Cseparate from=E2=80=9D might be better than =E2=80=9Cindependent of=E2=80=9D.

<= p class=3D"MsoNormal">


Therefore, please delete the texts mentioning independent (it is not rele= vant).=C2=A0I don't know so far any OLSRv2=C2=A0standard that is=C2=A0s= eparate/independent to=C2=A0RFC6130 NHDP.=C2=A0


IMHO I remember discussing this issue with OLSRv2 authors at IESG =C2=A0las= t call, I understood from them that OLSRv2 is not independent from =C2=A0RF= C6130. Now, let me assume I know there are routers independent of their
=C2=A0RFC6130 interface, then this optimisation proposal =C2=A0is mostly up= dating =C2=A0RFC6130, therefore, the changes recommended by the draft to th= e 7181 is =C2=A0only a must if there is dependancy, otherwise, please menti= on that the =C2=A0full changes required is a must even if OLSRv2 is not dependent on 6130.
=C2=A0Furthermore, if there are possibility of other protocol other than OL= SRv2 =C2=A0routers to use this draft, then mention that clearly and mention= that the =C2=A0Must is of all changes of section 4.

CMD: I just can't parse that. But the part I did understand is just rep= eating the same misreading.=

=C2=A0

The 7181 is dependent on 6130. So no need to update = other independent that are not standards on IETF.=C2=A0

=C2=A0

CMD: Still can=E2=80=99t = parse that.

=
Ok, delete below statement from the draft:

{<= /div>
However as it is known that some implementations of=C2=A0 [RFC7181] = are not independent of the implementation of [RFC6130] that=C2=A0they use,= it is useful to indicate the direct impact on [RFC7181].
}

=C2=A0
=C2=A0AB> to avoid confusion if this update is only for OLSRv2 routers t= hen =C2=A0mention that in its title. So the title will add words "for = OLSRv2 =C2=A0routers.

CMD: The only confusion is yours. There's no suggestion of that anywher= e, and it's not so.<= /p>

=C2=A0

Yes. I am a reader of the draft and you are the auth= or. So now the author notice the reader confusion, which can happen again w= ith other readers on future, I hope the WG considers this issue.=C2=A0

=C2=A0

CMD: Sometimes when there= is confusion it=E2=80=99s down to the draft. Sometimes it=E2=80=99s down t= o the reader.=C2=A0

=C2=A0Ok, I will prepare my suggestion for editing to= clarify that=C2=A0confusions.=C2=A0

You seem= to be the only one with a problem.

I know I alw= ays been in rough in this WG, it is not a problem=C2=A0and a reviewer's= detection of=C2=A0confusion possibility=C2=A0in reading is not a problem a= lso=C2=A0but a quality measure issue (can improve performance as an=C2=A0op= timize router is sensitive to change). Please note that this WG participati= on=C2=A0is a small size so even one has a value that IETF should not ignore= .=C2=A0


AB
--20cf3036388d5942e805007f1def-- From nobody Wed Aug 13 02:13: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 06D401A037B for ; Wed, 13 Aug 2014 02:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.567 X-Spam-Level: X-Spam-Status: No, score=-7.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 jQTjGZeyCvnv for ; Wed, 13 Aug 2014 02:13:04 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684C31A802F for ; Wed, 13 Aug 2014 02:13:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,855,1400022000"; d="scan'208,217";a="467814425" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 13 Aug 2014 10:13:02 +0100 X-IronPort-AV: E=Sophos; i="5.01,855,1400022000"; d="scan'208,217"; a="61772514" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 13 Aug 2014 10:13:18 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Wed, 13 Aug 2014 10:13:18 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial issues) Thread-Index: AQHPthE/YX2SR9vCC0ebmGQra7VFqJvMttRQgABXz4CAABUQwIABC1sAgAAQ+PA= Date: Wed, 13 Aug 2014 09:13:17 +0000 Message-ID: References: <066.0bb22f15b7c74448b0bb3821234ffc46@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D208B9GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/fMBPG9-WIQyd67tB6qkx7zGMU-8 Cc: "manet@ietf.org" , "draft-ietf-manet-nhdp-optimization@tools.ietf.org" Subject: Re: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial 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, 13 Aug 2014 09:13:06 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D208B9GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Q29tbWVudHMgQ01EIGJlbG93Lg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQ cmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5jZSBHcm91cA0KQ29tbXVuaWNh dGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpCQUUgU3lzdGVt cyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3Jl YXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0NSAyNDIxOTQg fCAgRmF4OiArNDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1h aWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRwOi8vd3d3LmJhZXN5c3Rl bXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9m ZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2Vu dHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmds YW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KRnJvbTogQWJkdXNzYWxhbSBCYXJ5dW4gW21haWx0 bzphYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbV0NClNlbnQ6IDEzIEF1Z3VzdCAyMDE0IDEwOjA3 DQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBtYW5ldEBpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1tYW5ldC1uaGRwLW9wdGltaXphdGlvbkB0b29scy5pZXRmLm9yZw0KU3ViamVjdDog W21hbmV0XSAjNTIgKG5oZHAtb3B0aW1pemF0aW9uKTogQ29uZnVzZWQgcGFyYWdyYXBoICMxIChF ZGl0b3JpYWwgaXNzdWVzKQ0KDQpJIGhvcGUgdGhhdCB0aGUgV0cgY29uc2lkZXJzIHRoaXMgdGhy ZWFkIHBvaW50cywgYW5kIHRvIHB1dCBpbiBtaW5kOg0KDQoxLSB0aGF0IFJGQzcxODEgZGVwZW5k cyBvbiA2MTMwIGFuZCBpdHMgb3RoZXIgbm9ybWF0aXZlIHJlZmVyZW5jZXMuIElFVEYgZGlkIG5v dCBzdGFuZGFyZCBhbnkgaW5kZXBlbmRlbnQgT0xTUnYyIGZyb20gdGhlIFJGQzYxMzAuDQoNCkNN RDogTm90IHJlbGV2YW50LCB3aXRoIHRoZSBwb3NzaWJsZSBleGNlcHRpb24gb2YgY2hhbmdpbmcg b25lIHdvcmQuDQoNCjItIE1BTkVUIHJvdXRlcnMgYXJlIHByb2FjdGl2ZSwgcmVhY3RpdmUsIGFu ZCBoeWJyaWQuDQoNCkNNRDogTm90IHJlbGV2YW50Lg0KDQozLSBuZWlnaGJvdXIgZGlzY292ZXJ5 IGlzIHBhcnQgb2Ygcm91dGluZyBhcyB0aGUgMS1ob3AvMi1ob3AgbmVpZ2hib3VycyBjYW4gYmVj b21lIHBvc3NpYmxlIGRlc3RpbmF0aW9ucy4gQW55IHVwZGF0ZSB0byBSRkM2MTMwIGlzIGFuIHVw ZGF0ZSB0byBhbGwgTUFORVQgcm91dGVycyB0aGF0IHVzZSBSRkM2MTMwLg0KDQpDTUQ6IE5vIG90 aGVyIHN0YW5kYXJkaXNlZCBwcm90b2NvbHMgbmVlZCB1cGRhdGluZy4gKFN0cm9uZ2VyIHRoYW4g dGhhdCBhY3R1YWxseSwgc2VlIHNlY29uZCBwYXJ0IG9mIG5leHQgY29tbWVudC4pDQoNCjQtIGFz IHRoaXMgV0cgZGVjaWRlZCB0byBkbyBSRkM2MTMwL1JGQzU0NDQgKEkgZGlzYWdyZWUgd2l0aCB0 aGUgYXBwcm9hY2ggYnV0IGl0J3MgdGhlIGhhcmQgd2F5IGFuZCBjYW4gYmUgYmVzdCB3YXkpIGJl Zm9yZSBmaW5pc2hpbmcgaXRzIGJvdGggcm91dGluZyBzdGFuZGFyZHMgKHJlYWN0aXZlIGFuZCBw cm9hY3RpdmUpIGl0IGlzIGltcG9ydGFudCB0byBjb25zaWRlciBib3RoIHJvdXRpbmdzIG5lZWRz IHdoaWxlIHVwZGF0aW5nIHN1Y2ggUkZDcyA1NDQ0IGFuZCA2MTMwLg0KDQpDTUQ6IE5vIG9uZSBp cyBwbGFubmluZyB0byB1cGRhdGUgNTQ0NCwgYW5kIHRoZXJlIGFyZSBzdHJvbmcgcmVhc29ucyBu b3QgdG8gZG8gc28gdW5sZXNzIGVzc2VudGlhbC4gVGhpcyB1cGRhdGUgdG8gNjEzMCBpcyBmdWxs eSBpbnRlcm9wZXJhYmxlIHdpdGggbm9uLXVwZGF0ZWQgaW1wbGVtZW50YXRpb25zLCBzbyBubyBp bXBhY3QgdGhlcmUgZWl0aGVyLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVu dCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVy LgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRp c2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D208B9GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNt Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6 MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCnNw YW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db21tZW50cyBDTUQg YmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdG9w aGVyIERlYXJsb3ZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3Vy YW5jZSBHcm91cDxicj4NCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlz aXMgQ2FwYWJpbGl0eTxicj4NCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJl PGJyPg0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBD TTIgOEhOLCBVSzxicj4NClRlbDogJiM0Mzs0NCAxMjQ1IDI0MjE5NCZuYnNwO3wmbmJzcDsgRmF4 OiAmIzQzOzQ0IDEyNDUgMjQyMTI0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT4NCiB8IGh0dHA6Ly93 d3cuYmFlc3lzdGVtcy5jb208YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJBRSBTeXN0 ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sg SG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91 Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUs8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsg V2FsZXMgTm86IDE5OTY2ODc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWJkdXNzYWxhbSBCYXJ5dW4gW21haWx0bzph YmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMyBBdWd1c3Qg MjAxNCAxMDowNzxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+ DQo8Yj5DYzo8L2I+IG1hbmV0QGlldGYub3JnOyBkcmFmdC1pZXRmLW1hbmV0LW5oZHAtb3B0aW1p emF0aW9uQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFttYW5ldF0gIzUyIChu aGRwLW9wdGltaXphdGlvbik6IENvbmZ1c2VkIHBhcmFncmFwaCAjMSAoRWRpdG9yaWFsIGlzc3Vl cyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaG9wZSB0aGF0IHRoZSBXRyBjb25z aWRlcnMgdGhpcyB0aHJlYWQgcG9pbnRzLCBhbmQgdG8gcHV0IGluIG1pbmQ6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLSB0aGF0IFJGQzcxODEgZGVwZW5k cyBvbiA2MTMwIGFuZCBpdHMmbmJzcDtvdGhlciBub3JtYXRpdmUgcmVmZXJlbmNlcy4gSUVURiBk aWQgbm90IHN0YW5kYXJkIGFueSBpbmRlcGVuZGVudCBPTFNSdjIgZnJvbSB0aGUmbmJzcDtSRkM2 MTMwLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5D TUQ6IE5vdCByZWxldmFudCwgd2l0aCB0aGUgcG9zc2libGUgZXhjZXB0aW9uIG9mIGNoYW5naW5n IG9uZSB3b3JkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLSBNQU5F VCByb3V0ZXJzIGFyZSBwcm9hY3RpdmUsIHJlYWN0aXZlLCBhbmQgaHlicmlkLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5D TUQ6IE5vdCByZWxldmFudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMtIG5laWdoYm91ciBkaXNjb3ZlcnkgaXMgcGFydCBvZiBy b3V0aW5nIGFzIHRoZSAxLWhvcC8yLWhvcCBuZWlnaGJvdXJzIGNhbiBiZWNvbWUgcG9zc2libGUg ZGVzdGluYXRpb25zLiBBbnkgdXBkYXRlIHRvIFJGQzYxMzAgaXMgYW4gdXBkYXRlIHRvIGFsbCBN QU5FVCByb3V0ZXJzIHRoYXQgdXNlIFJGQzYxMzAuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNNRDogTm8gb3RoZXIgc3Rh bmRhcmRpc2VkIHByb3RvY29scyBuZWVkIHVwZGF0aW5nLiAoU3Ryb25nZXIgdGhhbiB0aGF0IGFj dHVhbGx5LCBzZWUgc2Vjb25kIHBhcnQgb2YgbmV4dCBjb21tZW50Lik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQtIGFzIHRoaXMg V0cgZGVjaWRlZCB0byBkbyBSRkM2MTMwL1JGQzU0NDQgKEkgZGlzYWdyZWUgd2l0aCB0aGUmbmJz cDthcHByb2FjaCZuYnNwO2J1dCBpdCdzIHRoZSZuYnNwO2hhcmQgd2F5IGFuZCZuYnNwO2NhbiBi ZSBiZXN0IHdheSkmbmJzcDtiZWZvcmUmbmJzcDtmaW5pc2hpbmcgaXRzIGJvdGggcm91dGluZyZu YnNwO3N0YW5kYXJkcyAocmVhY3RpdmUgYW5kIHByb2FjdGl2ZSkmbmJzcDtpdCBpcyBpbXBvcnRh bnQgdG8gY29uc2lkZXIgYm90aCByb3V0aW5ncyZuYnNwO25lZWRzIHdoaWxlDQogdXBkYXRpbmcg c3VjaCBSRkNzIDU0NDQgYW5kIDYxMzAuJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Q01EOiBObyBvbmUgaXMgcGxhbm5pbmcgdG8gdXBkYXRlIDU0NDQsIGFuZCB0 aGVyZSBhcmUgc3Ryb25nIHJlYXNvbnMgbm90IHRvIGRvIHNvIHVubGVzcyBlc3NlbnRpYWwuIFRo aXMgdXBkYXRlIHRvIDYxMzAgaXMgZnVsbHkgaW50ZXJvcGVyYWJsZSB3aXRoIG5vbi11cGRhdGVk DQogaW1wbGVtZW50YXRpb25zLCBzbyBubyBpbXBhY3QgdGhlcmUgZWl0aGVyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4KVGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJy PgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3Rl bSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPgpkaXN0cmlidXRlIGl0cyBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3A+PC9ib2R5Pg0K PC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D208B9GLKXM0002VGREEN_-- From nobody Wed Aug 13 05:55: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 002F11A0051; Wed, 13 Aug 2014 05:55:20 -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 gKbZudhisTPr; Wed, 13 Aug 2014 05:55:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 785BB1A00A9; Wed, 13 Aug 2014 05:55:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140813125500.11385.42194.idtracker@ietfa.amsl.com> Date: Wed, 13 Aug 2014 05:55:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/OkxHD_dOMSF0nxPkTAVJpPNOYrM Cc: manet chair , manet mailing list , RFC Editor Subject: [manet] Protocol Action: 'Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process' to Proposed Standard (draft-ietf-manet-smf-mib-13.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, 13 Aug 2014 12:55:20 -0000 The IESG has approved the following document: - 'Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process' (draft-ietf-manet-smf-mib-13.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 Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ Technical Summary This document defines a portion of the Management Information Base (MIB) for use with the Simplified Multicast Framework (SMF) RFC6621 developed in the MANET working group. Working Group Summary The process for reaching working group consensus on this was smooth; no controversy existed. Working group consensus behind the document is solid. Document Quality This document shepherd is not aware of existing implementations of this MIB module; although a joint development is underway between the US Naval Research laboratory and the US Army CERDEC organizations. MIB doctor review during IETF last call resulted in considerable discussion and document revision. The version entering IESG evaluation is believed to address all issues needing change although there was one issue where the authors believe the MIB Doctor is advocating a different approach rather than stating something that needs to be changed. Personnel Stan Ratliff (sratliff@cisco.com) is the Document Shepherd. Adrian Farrel (Adrian@olddog.co.uk) the Responsible AD From nobody Wed Aug 13 09:08:30 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 8431C1A08D0 for ; Wed, 13 Aug 2014 09:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_ABOUTYOU=0.5, 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 NrX18pIzq0wF for ; Wed, 13 Aug 2014 09:08:25 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27FC1A08C1 for ; Wed, 13 Aug 2014 09:08:13 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x3so4366478qcv.9 for ; Wed, 13 Aug 2014 09:08: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=4SbPSWBwuRwSz7J8i04sRP+ayBLah5FE7bOjjmLD4ck=; b=buRFQRv/UW8bM7JET52Z1dpYAxot1qYGijBO+lUMekbb/JgWdz+TqOQuWx2tk+WIvQ 47a/bzVUTEOi6nNPAxZHMRJQGY526Opvjgyv4lJbF+Qh7UZ2wKb8i/UWgoWFg3ybA2ID pQX8vdCSfCZgumLCO8NbSoSGbHTgUMH2I4OC9QW1bLMjk/ta7yawzZoi/hnqNWd6+txw 2mbzvQoTJ9I2A42MNPxOKcYPbJt/Ahvf5GiWopX6LI9QqocTlGEYU5KF6WRmLfUOTUgz soTHqRqIv5jpSkUp65NDJaspl8tmGIQT/1M5fRURZcJJAN6PSvjFZHfXQzT0lNy6w79A 0gYA== MIME-Version: 1.0 X-Received: by 10.224.12.134 with SMTP id x6mr8156197qax.1.1407946093064; Wed, 13 Aug 2014 09:08:13 -0700 (PDT) Received: by 10.140.101.140 with HTTP; Wed, 13 Aug 2014 09:08:13 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148EA03E@tss-server1.home.tropicalstormsoftware.com> References: <1AC6F6CB-E63D-42EA-B279-01F6CCC0DFB9@cisco.com> <38A5475DE83986499AEACD2CFAFC3F9801148EA03E@tss-server1.home.tropicalstormsoftware.com> Date: Wed, 13 Aug 2014 12:08:13 -0400 Message-ID: From: Joseph Macker To: Rick Taylor Content-Type: multipart/alternative; boundary=089e013a07e4bd99f3050084fec8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5Drvdwn7UG9yGNrGo3d54m7CuX4 Cc: manet IETF , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP-06 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, 13 Aug 2014 16:08:27 -0000 --089e013a07e4bd99f3050084fec8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stan: As Rick states thanks for updating and also curious about your anticipated turn around for an -07 rev. Thanks, -Joe On Wed, Aug 13, 2014 at 4:55 AM, Rick Taylor wrote: > Thank you for your hard work Stan. > > Given the issues you have outlined, can we look forward to a draft-07 > fairly soon? > > Rick Taylor > > > On 13/08/14 07:34, Stan Ratliff (sratliff) wrote: > > Working Group participants, > > > > I've posted a new version of DLEP. There are some caveats here: > > > > 1. The Appendix is pretty much broken. If I were you, I'd probably > ignore it. It will be fixed in an 07 version. > > 2. With this version, there is a new proposed "DLEP Vendor Extension" > TLV. It's not documented correctly - the doc refers to a Vendor OUI, whic= h > I don't think will work. I believe that if vendor extensions are used, th= ey > are going to be *device specific*, not *vendor specific*. So if anyone ha= s > recommendations on how to tighten that up, it would be appreciated. > > 3. There is also verbiage in a new section 3 on "Mandatory versus > Optional" items. It probably isn't clear=E2=80=A6 > > > > That said, I've adjusted my fire suit, so=E2=80=A6=E2=80=A6 Flame on. > > > > 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 > --089e013a07e4bd99f3050084fec8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stan:

As Rick states thanks for updatin= g and also curious about your anticipated turn around for an -07 rev.
=

Thanks,
-Joe


On Wed, Aug 13, 2014 at 4:55 AM, Rick Ta= ylor <rick@tropicalstormsoftware.com> wrote:
Thank you for your hard work Stan.

Given the issues you have outlined, can we look forward to a draft-07
fairly soon?

Rick Taylor


On 13/08/14 07:34, Stan Ratliff (sratliff) wrote:
> Working Group participants,
>
> I've posted a new version of DLEP. There are some caveats here: >
> 1. The Appendix is pretty much broken. If I were you, I'd probably= ignore it. It will be fixed in an 07 version.
> 2. With this version, there is a new proposed "DLEP Vendor Extens= ion" TLV. It's not documented correctly - the doc refers to a Vend= or OUI, which I don't think will work. I believe that if vendor extensi= ons are used, they are going to be *device specific*, not *vendor specific*= . So if anyone has recommendations on how to tighten that up, it would be a= ppreciated.
> 3. There is also verbiage in a new section 3 on "Mandatory versus= Optional" items. It probably isn't clear=E2=80=A6
>
> That said, I've adjusted my fire suit, so=E2=80=A6=E2=80=A6 Flame = on.
>
> 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

--089e013a07e4bd99f3050084fec8-- From nobody Wed Aug 13 09:16: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 B31231A08FF for ; Wed, 13 Aug 2014 09:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 f7P8vgdrXphw for ; Wed, 13 Aug 2014 09:16:22 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC531A0900 for ; Wed, 13 Aug 2014 09:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1638; q=dns/txt; s=iport; t=1407946581; x=1409156181; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SktqmV1KY1RLbreGaKNpZACfMHvhxeHcFmOVquxJaLk=; b=asBYaGZ/ey41v3UkgxwDdFQ5fUFOYZiw4sBHeO2cjqPNsApdRH42PQ/p GfnUsZfdVfw7cPisuRntuADUkkreJ1KFeeMUDLVTP3fnxbRIdfUgDMPNh lgHbGypeiyxLL8M2RQsEhg1YxyH5dSDc1jO4jCSqmFeSwmYteJuRIG1B1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFANGO61OtJA2L/2dsb2JhbABagw1SVwTNHgqHSAGBFBZ3hAMBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgWIOggNxlwTBI8ZMweDL4EdBZEdixyUfoNcbIFI X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="68946517" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP; 13 Aug 2014 16:16:21 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7DGGLvA026186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 16:16:21 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 11:16:21 -0500 From: "Stan Ratliff (sratliff)" To: Rick Taylor Thread-Topic: [manet] DLEP-06 Thread-Index: AQHPtsCm8bF2enkvEEWjvaUFXyrxJJvPCiYA Date: Wed, 13 Aug 2014 16:16:20 +0000 Message-ID: <29A0C675-B86B-455F-A614-7B8B7B14DFDC@cisco.com> References: <1AC6F6CB-E63D-42EA-B279-01F6CCC0DFB9@cisco.com> <38A5475DE83986499AEACD2CFAFC3F9801148EA03E@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801148EA03E@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.84.63] 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/yiYd8h3PhRcxHu2dSnhMROG1VOQ Cc: manet IETF Subject: Re: [manet] DLEP-06 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, 13 Aug 2014 16:16:24 -0000 Rick/All,=20 Yes, I think we can get to an 07 very quickly. I'll be working on the broke= n appendix today/tonight. The other items that I'm aware of will only depen= d on the amount of time required to work them out in this forum (the update= s shouldn't be very onerous, once we reach consensus on what they are).=20 Regards, Stan On Aug 13, 2014, at 4:55 AM, Rick Taylor wrote: > Thank you for your hard work Stan. >=20 > Given the issues you have outlined, can we look forward to a draft-07=20 > fairly soon? >=20 > Rick Taylor >=20 >=20 > On 13/08/14 07:34, Stan Ratliff (sratliff) wrote: >> Working Group participants, >>=20 >> I've posted a new version of DLEP. There are some caveats here: >>=20 >> 1. The Appendix is pretty much broken. If I were you, I'd probably ignor= e it. It will be fixed in an 07 version. >> 2. With this version, there is a new proposed "DLEP Vendor Extension" TL= V. It's not documented correctly - the doc refers to a Vendor OUI, which I = don't think will work. I believe that if vendor extensions are used, they a= re going to be *device specific*, not *vendor specific*. So if anyone has r= ecommendations on how to tighten that up, it would be appreciated. >> 3. There is also verbiage in a new section 3 on "Mandatory versus Option= al" items. It probably isn't clear=85 >>=20 >> That said, I've adjusted my fire suit, so=85=85 Flame on. >>=20 >> Regards, >> Stan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From nobody Wed Aug 13 09:20:30 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 D36ED1A03F1 for ; Wed, 13 Aug 2014 09:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 wTWr0wI6tLFi for ; Wed, 13 Aug 2014 09:20:21 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30761A0408 for ; Wed, 13 Aug 2014 09:20:21 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id id10so15113757vcb.21 for ; Wed, 13 Aug 2014 09:20:20 -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=7NwGXPimIxtFQxpw9b15yrDTf25MuAQq3z3YlxBtLLQ=; b=tZNHVolvbpEghp5uFi0QAKvcyqoU/vKRmLGFcKUo3nIV2ScAbXyXijzNBLy77iqMPb 4QRU8V8fPwmMxxbNDaQVQoZczukmr9Sem8VPMBe9v93zzTuSSTAdm8p7gpHzvMB5zhCy kUW5zWT36l48oJRWA3Odc9F7KLz/b5W9HiRss= 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=7NwGXPimIxtFQxpw9b15yrDTf25MuAQq3z3YlxBtLLQ=; b=Mw505hsLFOKFn6uPwpLzaVGsVbrGpPp2WI/56XtVvxqz4sbwzatwww0reogKDODMa2 8DjYbsHnd5Oy6DyLeQWa85kfy5gLLBpl2FimBs3wJnUHIC3W/W0rCToSy7UnZvpPLDck Z9jLKlvpszbJpJ+d3Ni8gEi74IpV9Nab6qRh2RCBOW5kl15G7DVsbNDAis3Lwl2eVixz hF2TReVT+Bxbns0MIRsO/IRPoqZ74ZZrz0pVcZ+Lz0z5B+JfXssSN4ln8SuEIjPGFSzt bHGPzOEEHymj4NU72Q960Kh5bOydI+/abAEajMsyHksbj1q1HBYhbhmz0dIhJXboegZk RHCQ== X-Gm-Message-State: ALoCoQmkgQWQQlOOeBGC+UBeBah0mc4yyYI/tI7ByUErUNkbOiq2/k6NolVG+r3golfIMR/4JWbZ MIME-Version: 1.0 X-Received: by 10.221.21.201 with SMTP id qt9mr4659411vcb.39.1407946820767; Wed, 13 Aug 2014 09:20:20 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Wed, 13 Aug 2014 09:20:20 -0700 (PDT) In-Reply-To: References: <066.0bb22f15b7c74448b0bb3821234ffc46@trac.tools.ietf.org> Date: Wed, 13 Aug 2014 09:20:20 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/LZh8OqP7BHfQGfIkcQvHkVCX4cA Cc: "manet@ietf.org" , "draft-ietf-manet-nhdp-optimization@tools.ietf.org" Subject: Re: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial 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, 13 Aug 2014 16:20:28 -0000 I concur with everything Chris said. I don't think that the draft should be updated as suggested. I object to update RFC5444 or RFC6130 unless it is essential (which I don't think it is). Best regards Ulrich On Wed, Aug 13, 2014 at 2:13 AM, Dearlove, Christopher (UK) wrote: > Comments CMD below. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 13 August 2014 10:07 > > > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; draft-ietf-manet-nhdp-optimization@tools.ietf.org > Subject: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial > issues) > > > > I hope that the WG considers this thread points, and to put in mind: > > > > 1- that RFC7181 depends on 6130 and its other normative references. IETF did > not standard any independent OLSRv2 from the RFC6130. > > > > CMD: Not relevant, with the possible exception of changing one word. > > > > 2- MANET routers are proactive, reactive, and hybrid. > > > > CMD: Not relevant. > > > > 3- neighbour discovery is part of routing as the 1-hop/2-hop neighbours can > become possible destinations. Any update to RFC6130 is an update to all > MANET routers that use RFC6130. > > > > CMD: No other standardised protocols need updating. (Stronger than that > actually, see second part of next comment.) > > > > 4- as this WG decided to do RFC6130/RFC5444 (I disagree with the approach > but it's the hard way and can be best way) before finishing its both routing > standards (reactive and proactive) it is important to consider both routings > needs while updating such RFCs 5444 and 6130. > > > > CMD: No one is planning to update 5444, and there are strong reasons not to > do so unless essential. This update to 6130 is fully interoperable with > non-updated implementations, so no impact there either. > > ******************************************************************** > 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 > From nobody Wed Aug 13 09:21: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 B7E3F1A0875 for ; Wed, 13 Aug 2014 09:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 poj3BjbTKbhm for ; Wed, 13 Aug 2014 09:21:26 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC011A0408 for ; Wed, 13 Aug 2014 09:21:25 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so15054912vcb.6 for ; Wed, 13 Aug 2014 09:21:24 -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:content-transfer-encoding; bh=REqZkbQI37VK5xqTgxRExa6arc6RQZ4md9kJktAJmTE=; b=mURZHaSdpQ5SU4liYcD6gvhADCJsV/oSROfeU8Lt6HH+QTxd0PQzBz7JITbC/YJY7l JVc3Qssyz/UBPwjq+ysFq9XXpjXEsYkU8AfPPiVgRc4lg4CyVR9QiLN7+UVSIh3dZ7qY IS5YyNhRJbbI/tbrkLbA/ZlLkE4QHUYpZfu/Q= 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 :content-transfer-encoding; bh=REqZkbQI37VK5xqTgxRExa6arc6RQZ4md9kJktAJmTE=; b=VtIGzl5+YPvRia0QWx/eBq+nemrRptSIoPTQH+vSiWW+Hh3qALqpWNuD68A7Aahaa4 bvzmuVapIUF9ffkTe+dv4r6SvOJnY5rbfwEXSvac4IBeY9ms3L6w1ugYSc6E+on0QMr/ tnkQY2Wy0w8cHtraAGrtAAO1wJAuwVTdG+CIfVXgGMQb2jVMebU0xXqtOOxLd7OUK6cb li4yujWOZ/PQLxeRXrWKXtMKrBGzF7gyP6+vsWJjTcdxQR8iT+3oyNDElERdpFRTFZ+D xHBARb1DdGU5Ywf+CsrUI1u/PxY5SSaB4uoJqoyNSKnM00ZlXXdvqTOn8OKtRBsd9bOI y17g== X-Gm-Message-State: ALoCoQlQzZKgcG89oK6hTXg5QJAhwi+4FYHGxBLV2EZjrwGoUSeP+vE5UMk77IpJ7YjOj3hzrGQD MIME-Version: 1.0 X-Received: by 10.52.148.2 with SMTP id to2mr3996659vdb.38.1407946884581; Wed, 13 Aug 2014 09:21:24 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Wed, 13 Aug 2014 09:21:24 -0700 (PDT) In-Reply-To: References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> Date: Wed, 13 Aug 2014 09:21:24 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/McKSS9ccsbL3MnAMEaTkK4hWZG8 Cc: Christopher Dearlove , "manet@ietf.org" , Thomas Clausen Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 13 Aug 2014 16:21:31 -0000 I concur with Chris. Ulrich On Mon, Aug 11, 2014 at 5:10 AM, Dearlove, Christopher (UK) wrote: > There is no need (or even advantage) to change (amending suggests a probl= em, > which there isn=E2=80=99t) the draft based on anything you have posted. > > > > There isn=E2=80=99t even anything that could be changed because, and let= =E2=80=99s say it > again, link quality information is not communicated. In addition two hop > information is not communicated (only one hop information that becomes tw= o > hop information, but it=E2=80=99s about it as two hop information that th= is > applies). > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 11 August 2014 12:28 > To: Dearlove, Christopher (UK) > Cc: Thomas Clausen; Christopher Dearlove; manet@ietf.org > > > Subject: Re: [manet] #51 (nhdp-optimization): Analysis of > OLSRv2/NHDP-optimized Handling neighbor connection with link quality chan= ge > > > > > > *** 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 y= ou > receive, click here. > If you feel the email is suspicious, please follow this process. > > > > On Monday, August 11, 2014, Dearlove, Christopher (UK) wrote: > > The key words there are =E2=80=9Ccan have=E2=80=9D. Not =E2=80=9Cwill hav= e=E2=80=9D. > > Yes I used that "can have" because I want to consider the real full > possibilities, so we not trying to make the problem but we consider it in > our draft. so I think you agree with the word I used. > > > > And even then you weren=E2=80=99t consistent, you assume B-C went down wh= en A-B did, > but not that B-C went up when A-B did. This may be considered attempting = to > have your cake and eat it, if the cake is finding a problem. (I=E2=80=99m= not sure > why you are trying hard to find a problem no one else has, but that seems= to > be the case.) > > I think this is the analysis of one possible issue. I did consider that t= hey > become up together as well and they may not be together. The key problem > that you may missed is that each neighbour node don't need to have same > quality level threshold so the becoming up together may not happen with t= ime > difference period of when they went down. The examples considers > optimization as if each node can have different quality level (I think th= is > is allowed that optimized routers can have different measures). So three > factors to consider within the example: the routers (optimizing/normal), = the > optimized-routers' measures of quality same/different, and the links' > frequency of change below threshold. > > > > And, as has been said several times, if you have a scenario with a proble= m, > just don=E2=80=99t use it. > > Or we can find a way to amend the draft to consider such situation/condit= ion > and solve it. > > > > (Similarly if you have a scenario where it is pointless, you can decide n= ot > to use it. An example there could be a heavily damped link quality that i= f > it goes down can=E2=80=99t come back up in less than REFRESH_INTERVAL tim= e. It won=E2=80=99t > do any harm =E2=80=93 except a trivial amount of storage and processing = =E2=80=93 but it > won=E2=80=99t do much good either.) > > > > The optimization is working to improve for the time below the refresh > interval. So my example is about times below that time. The draft mention= s > that the optimization is used to improve when there are temporary short > quality changes. IMHO it only considers one link failure, which is A-B th= e > first hop (I suggest to mention that in the applicability statement). wha= t > about if both neighbor hops get considered changed by optimize-routers of > the routing path. > > > > AB > > > > -- > > > > ******************************************************************** > > > 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 > From nobody Wed Aug 13 09:25: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 5B8041A08C0 for ; Wed, 13 Aug 2014 09:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 EkKTFLOXJ6ak for ; Wed, 13 Aug 2014 09:24:58 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8216E1A03EA for ; Wed, 13 Aug 2014 09:24:58 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so15111431vcb.22 for ; Wed, 13 Aug 2014 09:24:57 -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:content-transfer-encoding; bh=fG18OyJVFXfBBy0woQYuC0CTxfdBhO+4WUt8l9oKJPg=; b=OwUtuuL5Iees8erV2RKRRTKXbB0WqAYxZHBnNdMB4mfv4Se8wGxXm/HRvJqJO4Zp3B 1117XPBURSQwAIb1G3UOD3BA0OQr63SA4zY7aIeZrHVN1jvZaL/mXxR6aU43CM3RAJL0 m595fl/nD4Bhh8Vrk0499vNd6ZckJCgH7IrqI= 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 :content-transfer-encoding; bh=fG18OyJVFXfBBy0woQYuC0CTxfdBhO+4WUt8l9oKJPg=; b=X8j71UeVZeyCUt6EN7mal5+M6tEgxsEeOoPgETn+9QWH40BMmZoZMW7FuDBqTo/Nk/ aK267NJT8ZfOevdgxfEl584D+VmreMuVznpHxZ+abbaFZIpnxcssu9hSz2/r+NC6uMMt DHSFst0QplFT5nThr1gzayHY9JLgaDOH4HDRtVRAKy31khLwN+izK85Q2GQ8JQ67n5jH 6wIQdTBGaw/XBlpTzslf97QKLPGU82P5jS17GgCM3FCQNcbul2xBGAtPmgFuCSlUQZXA a528uxCbYn382wxmTOTD9bB8s8Qx5yE4Kn78EShHFiolON9Iz1dqtqf0ZDMljBJiAXYv wDMQ== X-Gm-Message-State: ALoCoQlQyNpAB8z6RI8x20dwdNUhlnEQZ0k5aiLf9xySc0XsO/EwtHzTkkwpB6f4k7Ktj6nmAMUf MIME-Version: 1.0 X-Received: by 10.221.21.201 with SMTP id qt9mr4681214vcb.39.1407947097688; Wed, 13 Aug 2014 09:24:57 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Wed, 13 Aug 2014 09:24:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Aug 2014 09:24:57 -0700 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bitWWu3hTXPkcySxGagEFRgstnQ Cc: manet IETF Subject: Re: [manet] Call to adopt draft-yi-manet-smf-sec-threats as a working group document 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, 13 Aug 2014 16:24:59 -0000 Hi Stan, the 2-week call for adoption has completed without objections yesterday. Can we submit the document as WG document? Best regards Ulrich On Tue, Jul 29, 2014 at 12:07 PM, Stan Ratliff (sratliff) wrote: > Working group participants - > > This is a call to adopt draft-yi-manet-smf-sec-threats as a Working Group= document. If you have issues with the WG accepting this document, please n= ote them on the list before close of business on Aug 12, 2014. The 2-week c= all for adoption is due to the number of other documents currently on the w= orking group's queue. Lack of a response will be seen as approval for accep= ting the document. > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Aug 13 09:28: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 155181A041C for ; Wed, 13 Aug 2014 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 lcxS-67ziTZm for ; Wed, 13 Aug 2014 09:28:39 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F6F1A08B8 for ; Wed, 13 Aug 2014 09:28:39 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so15363803vcb.17 for ; Wed, 13 Aug 2014 09:28:38 -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=E8kSonQhj6jVHzjSYyyFcBN9cIHMMY4GcVOy5txeZHU=; b=Vf3fMb1JkLLfcg3VHsOABmE+2oCyUdPYB0mW3BUt/EcJ2JQp0kBilfZAShZSFRlfFD 5eOgfZRYtQSszUbSnubjkXlfFfLHTw+f7O24YJiTY7kV3C+f4nbvHPYrJ4PIQs+xlvLw T9c58QOXqd/23+2Qul+RyOwv8R9DlMP8SXFfM= 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=E8kSonQhj6jVHzjSYyyFcBN9cIHMMY4GcVOy5txeZHU=; b=VSsk2o2kZMOB9kg7Jl/0gt4Fq5HkANj1WQSwZP4UaAXmN0lh9gRT0rdLIleMd2uVG5 uWoLIRs7ExWzTM/oz/LfJggHE/1Gyx4YbgMBXYFG6ED+zH76QenuWzf+o4frm9GhktHo zGg4GeqIsVluwo0iVNTbSdhOnD/lX9aD09230D7JmrqgSkFs7D1Cfcjfmj2f8xTED3nd ba52swZqnEtXXPS+xgjiorB2iTrG9QW+8aZi0lg38g8bEZ4NR8q7wBaTn+3lV8+pLrNw HDq06Wm3TZFq84ToUrzQb/a9X8a4EGghn5DoeMtrJvvfnK+m0Z7iVvR2qnfRaV8FIV4p Ltfw== X-Gm-Message-State: ALoCoQn3vG85iePc8y9Uss9PDwR5o7U/jeGEr+PNaGnMCWNx/t7Ag9Uf3T1wHZ8WsaS875SRPb6Z MIME-Version: 1.0 X-Received: by 10.52.30.2 with SMTP id o2mr600298vdh.12.1407947318866; Wed, 13 Aug 2014 09:28:38 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Wed, 13 Aug 2014 09:28:38 -0700 (PDT) In-Reply-To: <20140813125500.11385.42194.idtracker@ietfa.amsl.com> References: <20140813125500.11385.42194.idtracker@ietfa.amsl.com> Date: Wed, 13 Aug 2014 09:28:38 -0700 Message-ID: From: Ulrich Herberg To: manet mailing list Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/mvC-GPs5WV6u91t1SimfvUIMfJs Subject: Re: [manet] Protocol Action: 'Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process' to Proposed Standard (draft-ietf-manet-smf-mib-13.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, 13 Aug 2014 16:28:41 -0000 Congratulations! :-) Regards Ulrich On Wed, Aug 13, 2014 at 5:55 AM, The IESG wrote: > The IESG has approved the following document: > - 'Definition of Managed Objects for the Manet Simplified Multicast > Framework Relay Set Process' > (draft-ietf-manet-smf-mib-13.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 Alia Atlas. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ > > > > > Technical Summary > > This document defines a portion of the Management Information > Base (MIB) for use with the Simplified Multicast Framework (SMF) > RFC6621 developed in the MANET working group. > > Working Group Summary > > The process for reaching working group consensus on this was > smooth; no controversy existed. Working group consensus > behind the document is solid. > > Document Quality > > This document shepherd is not aware of existing implementations > of this MIB module; although a joint development is underway > between the US Naval Research laboratory and the US Army > CERDEC organizations. > > MIB doctor review during IETF last call resulted in considerable > discussion and document revision. The version entering IESG > evaluation is believed to address all issues needing change > although there was one issue where the authors believe the MIB > Doctor is advocating a different approach rather than stating > something that needs to be changed. > > Personnel > > Stan Ratliff (sratliff@cisco.com) is the Document Shepherd. > Adrian Farrel (Adrian@olddog.co.uk) the Responsible AD From nobody Wed Aug 13 10:13: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 EC9CC1A0947 for ; Wed, 13 Aug 2014 10:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 MoOhITESsWEp for ; Wed, 13 Aug 2014 10:13:42 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24A91A0396 for ; Wed, 13 Aug 2014 10:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1120; q=dns/txt; s=iport; t=1407950002; x=1409159602; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UlZF2FRWSXxznLr0mOFjoH6L6idfgT1hynvwdm96Hm0=; b=X7EqVC7ZQEwpqPPxzH7zdOqcaI60JNeEZIggUbmWfIOhS6/vmVuUQezw DDKTSE7+zirXXr7iAgtVOTWaSANYK1glAlMiftelE9AGmPzOVNR82fRtr 4U0skuqVhs688DwaKz0K5faURt1a+CzF6Pur6n5hFUbsO4a/lVtk1lM3l g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAHCc61OtJA2F/2dsb2JhbABagw1SVwTNHgqHSAGBFBZ3hAMBAQEDAQEBARodNAsFCwIBCBgeECcLJQIEDgWIOggNxmMTBI8ZMweDL4EdBZEdixyUfoIWgUZsgUg X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="68916675" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 13 Aug 2014 17:13:16 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7DHDFAt012516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 17:13:15 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 12:13:15 -0500 From: "Stan Ratliff (sratliff)" To: Ulrich Herberg Thread-Topic: [manet] Call to adopt draft-yi-manet-smf-sec-threats as a working group document Thread-Index: AQHPq2BJEg628njluUyoGaHiTjfUjJvPI0+AgAANfQA= Date: Wed, 13 Aug 2014 17:13:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.84.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <1C2A117C86EA31469B7786827BAD7717@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zI1nbfYNfFiAz0RK4K5S-s9wmtY Cc: manet IETF Subject: Re: [manet] Call to adopt draft-yi-manet-smf-sec-threats as a working group document 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, 13 Aug 2014 17:13:44 -0000 Ulrich/Working Group Participants,=20 Yes. draft-yi-manet-smf-sec-threats has been accepted as a working group do= cument.=20 Regards, Stan On Aug 13, 2014, at 12:24 PM, Ulrich Herberg wrote: > Hi Stan, >=20 > the 2-week call for adoption has completed without objections > yesterday. Can we submit the document as WG document? >=20 > Best regards > Ulrich >=20 > On Tue, Jul 29, 2014 at 12:07 PM, Stan Ratliff (sratliff) > wrote: >> Working group participants - >>=20 >> This is a call to adopt draft-yi-manet-smf-sec-threats as a Working Grou= p document. If you have issues with the WG accepting this document, please = note them on the list before close of business on Aug 12, 2014. The 2-week = call for adoption is due to the number of other documents currently on the = working group's queue. Lack of a response will be seen as approval for acce= pting the document. >>=20 >> Regards, >> Stan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From nobody Wed Aug 13 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 E01551A00E7; Wed, 13 Aug 2014 10:24:05 -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 F-f-JaXGn3Az; Wed, 13 Aug 2014 10:24:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0985E1A007D; Wed, 13 Aug 2014 10:24:00 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140813172400.22995.13716.idtracker@ietfa.amsl.com> Date: Wed, 13 Aug 2014 10:24:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/FGtFa3URz1sAonr5rFN2nMPpWBk Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-sec-threats-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, 13 Aug 2014 17:24:06 -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 : Security Threats for Simplified Multicast Forwarding (SMF) Authors : Jiazi Yi Thomas Heide Clausen Ulrich Herberg Filename : draft-ietf-manet-smf-sec-threats-00.txt Pages : 12 Date : 2014-08-13 Abstract: This document analyzes security threats of the Simplified Multicast Forwarding (SMF), including the vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-smf-sec-threats/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-smf-sec-threats-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 Aug 13 10:25: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 194151A0162 for ; Wed, 13 Aug 2014 10:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 MFIZrrd9cyyw for ; Wed, 13 Aug 2014 10:25:05 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8621A015B for ; Wed, 13 Aug 2014 10:25:04 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id la4so64773vcb.37 for ; Wed, 13 Aug 2014 10:25:04 -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:content-transfer-encoding; bh=z1zmGgptydfKYNGWP0znNSgiOMwexw77urAiW4l/ggk=; b=26ikncsIN1d3gJZALd8m7k4e9PT9KwYd7eAtCUIbzL8UAl0J9Cc7LZx9c+EcVzKduq XZcK8L8wg7uXDG0+a7nYOOvrpzMnrnkvIHtcK3qheTEHWCe2ybkZZqbAhfmApGB7bEdf yUOlCf0AChIGCBqrdAczmOwl4AAPMh9Ynbhno= 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 :content-transfer-encoding; bh=z1zmGgptydfKYNGWP0znNSgiOMwexw77urAiW4l/ggk=; b=DeEq5bJxTMs5pKvmIGbI2VFnTaPMpKNQCtw2A6/usVLHy+Sz0YnfQ3yhK9QVHBZ2D7 Av+9C4bshI/T/MyRpW+428riJe+fs9SXBuI9wpYNXE8hnWj7u2r+wfiy1uXJxqVO78D4 pEjzsY2n5V231f0E+IWe4yX/PTTO8ohKIug4P6TYsvwpAuDNuzC4jEZ8iIWdvXA7DVbI H4Z0Qaf7w+J5DRl5BT2xZnb3cd2O68q8LwqbEbl9L8NzIoibtM0Ktfmof6cv8J09ER09 tMxbkVnd52Nfmn1eruyCGPEOqpqMZ+g4PJIwrBLoecDRN+yVZ86Oxzflt5Y9Ubww1T3v +fjA== X-Gm-Message-State: ALoCoQlngDR3Ez92YFB7bZYjCyaun9mVQ7+EuLkTWJhkvK1gRZSRgrsiNu0C2H1ROLkdmLpjzhAa MIME-Version: 1.0 X-Received: by 10.52.127.5 with SMTP id nc5mr1816755vdb.59.1407950704167; Wed, 13 Aug 2014 10:25:04 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Wed, 13 Aug 2014 10:25:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Aug 2014 10:25:04 -0700 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8z6IjngFDm1aLPnIGx-Z0Bf-qv0 Cc: manet IETF Subject: Re: [manet] Call to adopt draft-yi-manet-smf-sec-threats as a working group document 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, 13 Aug 2014 17:25:06 -0000 Thanks, Stan. I have submitted http://www.ietf.org/id/draft-ietf-manet-smf-sec-threats-00.txt As usual, no difference from the individual draft other than draft moniker and submission date. Best regards Ulrich On Wed, Aug 13, 2014 at 10:13 AM, Stan Ratliff (sratliff) wrote: > Ulrich/Working Group Participants, > > Yes. draft-yi-manet-smf-sec-threats has been accepted as a working group = document. > > Regards, > Stan > > On Aug 13, 2014, at 12:24 PM, Ulrich Herberg wrote: > >> Hi Stan, >> >> the 2-week call for adoption has completed without objections >> yesterday. Can we submit the document as WG document? >> >> Best regards >> Ulrich >> >> On Tue, Jul 29, 2014 at 12:07 PM, Stan Ratliff (sratliff) >> wrote: >>> Working group participants - >>> >>> This is a call to adopt draft-yi-manet-smf-sec-threats as a Working Gro= up document. If you have issues with the WG accepting this document, please= note them on the list before close of business on Aug 12, 2014. The 2-week= call for adoption is due to the number of other documents currently on the= working group's queue. Lack of a response will be seen as approval for acc= epting the document. >>> >>> Regards, >>> Stan >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet > From nobody Wed Aug 13 11:44: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 7BD5A1A0348 for ; Wed, 13 Aug 2014 11:44:56 -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 NOnIiUfsmFuA for ; Wed, 13 Aug 2014 11:44:54 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C2A1A032C for ; Wed, 13 Aug 2014 11:44:54 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so131320qae.6 for ; Wed, 13 Aug 2014 11:44:53 -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=kyocHkm3N41aVS/GrJHvzEpAw1AjeKZawo6khrl8WBY=; b=nj0AD0Wlz13o1aPuz7GgCkpDWOivEuj/xIUw+Zlfkka+3S6NY8W6oecMvh9+47bOTU oGPA+y3/S2H/n6vURhBlXfOxWXf5mKlrhGw9UDGLhdE3HRGgpexcIipq73y1DXj8QKa/ LSgdKwdVJVehSANzxKwehwx/PGTagMgggUK3T+QxUAH3qwjbGyXrsQ/HURYtG25ZaPV9 zWI+jXc1f9ImIWGW2cMULQ2dZpYCg2bObPsOBlKk9fhUz0affnRaXzL88iff4Y+g3weY QZ4S5ic+uBYpiLUTWYtWUEJQ2BI+s4NB/4nKAt5B/nIEN3kJhldLffu/RDorcyxS6bn8 wNEw== MIME-Version: 1.0 X-Received: by 10.224.111.193 with SMTP id t1mr9523497qap.103.1407955493705; Wed, 13 Aug 2014 11:44:53 -0700 (PDT) Received: by 10.96.77.227 with HTTP; Wed, 13 Aug 2014 11:44:53 -0700 (PDT) In-Reply-To: References: <20140813125500.11385.42194.idtracker@ietfa.amsl.com> Date: Wed, 13 Aug 2014 14:44:53 -0400 Message-ID: From: James Nguyen To: Ulrich Herberg Content-Type: multipart/alternative; boundary=047d7b6737f00fded90500872f64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/o9LgOxpnCfj0BpCTEUoJFKP1u-8 Cc: manet mailing list Subject: Re: [manet] Protocol Action: 'Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process' to Proposed Standard (draft-ietf-manet-smf-mib-13.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, 13 Aug 2014 18:44:56 -0000 --047d7b6737f00fded90500872f64 Content-Type: text/plain; charset=UTF-8 Another milestone. congratulations! :) On Wed, Aug 13, 2014 at 12:28 PM, Ulrich Herberg wrote: > Congratulations! :-) > > Regards > Ulrich > > On Wed, Aug 13, 2014 at 5:55 AM, The IESG wrote: > > The IESG has approved the following document: > > - 'Definition of Managed Objects for the Manet Simplified Multicast > > Framework Relay Set Process' > > (draft-ietf-manet-smf-mib-13.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 Alia Atlas. > > > > A URL of this Internet Draft is: > > http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ > > > > > > > > > > Technical Summary > > > > This document defines a portion of the Management Information > > Base (MIB) for use with the Simplified Multicast Framework (SMF) > > RFC6621 developed in the MANET working group. > > > > Working Group Summary > > > > The process for reaching working group consensus on this was > > smooth; no controversy existed. Working group consensus > > behind the document is solid. > > > > Document Quality > > > > This document shepherd is not aware of existing implementations > > of this MIB module; although a joint development is underway > > between the US Naval Research laboratory and the US Army > > CERDEC organizations. > > > > MIB doctor review during IETF last call resulted in considerable > > discussion and document revision. The version entering IESG > > evaluation is believed to address all issues needing change > > although there was one issue where the authors believe the MIB > > Doctor is advocating a different approach rather than stating > > something that needs to be changed. > > > > Personnel > > > > Stan Ratliff (sratliff@cisco.com) is the Document Shepherd. > > Adrian Farrel (Adrian@olddog.co.uk) the Responsible AD > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- James Nguyen Email: james.huy.nguyen@gmail.com --047d7b6737f00fded90500872f64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Another milestone.=C2=A0 congratulations! :)


On Wed, Aug 13, 2= 014 at 12:28 PM, Ulrich Herberg <ulrich@herberg.name> wrot= e:
Congratulations! :-)

Regards
Ulrich

On Wed, Aug 13, 2014 at 5:55 AM, The IESG <iesg-secretary@ietf.org> wrote:
> The IESG has approved the following document:
> - 'Definition of Managed Objects for the Manet Simplified Multicas= t
> =C2=A0 =C2=A0Framework Relay Set Process'
> =C2=A0 (draft-ietf-manet-smf-mib-13.txt) as Proposed Standard
>
> This document is the product of the Mobile Ad-hoc Networks Working Gro= up.
>
> The IESG contact persons are Adrian Farrel and Alia Atlas.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/=
>
>
>
>
> Technical Summary
>
> =C2=A0 =C2=A0This document defines a portion of the Management Informa= tion
> =C2=A0 =C2=A0Base (MIB) for use with the Simplified Multicast Framewor= k (SMF)
> =C2=A0 =C2=A0RFC6621 developed in the MANET working group.
>
> Working Group Summary
>
> =C2=A0 =C2=A0The process for reaching working group consensus on this = was
> =C2=A0 =C2=A0smooth; no controversy existed. Working group consensus > =C2=A0 =C2=A0behind the document is solid.
>
> Document Quality
>
> =C2=A0 =C2=A0This document shepherd is not aware of existing implement= ations
> =C2=A0 =C2=A0of this MIB module; although a joint development is under= way
> =C2=A0 =C2=A0between the US Naval Research laboratory and the US Army<= br> > =C2=A0 =C2=A0CERDEC organizations.
>
> =C2=A0 =C2=A0MIB doctor review during IETF last call resulted in consi= derable
> =C2=A0 =C2=A0discussion and document revision. The version entering IE= SG
> =C2=A0 =C2=A0evaluation is believed to address all issues needing chan= ge
> =C2=A0 =C2=A0although there was one issue where the authors believe th= e MIB
> =C2=A0 =C2=A0Doctor is advocating a different approach rather than sta= ting
> =C2=A0 =C2=A0something that needs to be changed.
>
> Personnel
>
> =C2=A0 =C2=A0Stan Ratliff (sratl= iff@cisco.com) is the Document Shepherd.
> =C2=A0 =C2=A0Adrian Farrel (Adr= ian@olddog.co.uk) the Responsible AD

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



--
James Nguye= n
Email: james.huy.nguyen@= gmail.com --047d7b6737f00fded90500872f64-- From nobody Wed Aug 13 22:27: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 050991A0731 for ; Wed, 13 Aug 2014 22:27: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 xTPMJ2uZppNi for ; Wed, 13 Aug 2014 22:27:12 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACC61A0729 for ; Wed, 13 Aug 2014 22:27:12 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 131so617913ykp.4 for ; Wed, 13 Aug 2014 22:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UlXyEJbJH8OMfu+Lw3YA968Ul7myozCgGxNRTGsXOYs=; b=iK1z0aRY7J4RZ4D4E3ZwKDYJiwNvGt3cCkXju9xJub2I1jbfRvSjj1+IUxmztl+i81 pak8/8FC7FTTOPyEvQb00/cxNH/xyeiLl6yEzyZqYhp+nC8gPVfHxRf4fOWe9gUKJQ1W jK0bXfGx63AC5SQKJ/j/NVrrKDR95IVLmOtR/bCABddFq8DydhT8FMe6GvfFmPizXY0+ Y4CM8Gi1N1pEBr1mwTjJjg2DSyzrhq77vj6MeRb+1l1K/H4lPwT9UknFxkvatXCOZfYy /hEh0619B43mj8vv88NPq67Hzn7mAbokKy5Nh0uecCs/XC5F3q3uF+WpHjdCLT6kHjPh ZwzQ== MIME-Version: 1.0 X-Received: by 10.236.96.198 with SMTP id r46mr13822739yhf.92.1407994031520; Wed, 13 Aug 2014 22:27:11 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Wed, 13 Aug 2014 22:27:11 -0700 (PDT) In-Reply-To: References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> Date: Thu, 14 Aug 2014 07:27:11 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a11c1e6a818443a0500902874 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Oc73qFKxktYcZd3aoPf85ZXVRQg Cc: "manet@ietf.org" , Christopher Dearlove , Thomas Clausen Subject: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 14 Aug 2014 05:27:14 -0000 --001a11c1e6a818443a0500902874 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable WG to analyse the packet loss problem for this optimization. All MANETs have packet lost but the proposed optimized routers need to avoid its possible increase. On Monday, August 11, 2014, Dearlove, Christopher (UK) wrote: > There is no need (or even advantage) to change (amending suggests a > problem, which there isn=E2=80=99t) the draft based on anything you have = posted. > > You did not analyse by saying no need or isn't a problem. IMHO there is the packet loss problem because router A when recovered it considers C as reached through B but B has the link B-C as lost. The optimization improves packet delay issues but increases packet loss or decreases average delivery rate for the MANET that has many optimiz-routers. > > > There isn=E2=80=99t even anything that could be changed because, and let= =E2=80=99s say it > again, link quality information is not communicated. > > This draft has no update to nhdp's information exchange communication, an= d I did not mention communication. The performance difference between normal router and optimize-router is within packet-delay and packet-loss. However, the draft gives the opportunity that each optimize-router may change its link information which may loose consistency with its neighbours' information, so packets can get lost with higher possibility. I will look into the draft's update of nhdp/olsv2 algorithm and see if I can solve the issue without communicating any info. AB --001a11c1e6a818443a0500902874 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable WG to analyse the packet loss problem for this optimization. All MANETs hav= e packet lost but the proposed=C2=A0optimized=C2=A0routers need to avoid it= s possible=C2=A0increase.=C2=A0

On Monday, August 11, 2014, Dearlove= , Christopher (UK) wrote:

There is no need (or even= advantage) to change (amending suggests a problem, which there isn=E2=80= =99t) the draft based on anything you have posted.

You did not analys= e by saying no need or isn't a problem.=C2=A0IMHO there=C2=A0is the=C2= =A0packet loss problem because router A when recovered it considers C as re= ached through B=C2=A0but B has the link B-C as lost. The optimization impro= ves=C2=A0packet delay issues but increases packet loss or decreases average= =C2=A0delivery rate for the=C2=A0MANET that has many optimiz-routers.=C2=A0=

=C2=A0

There isn=E2=80=99t even = anything that could be changed because, and let=E2=80=99s say it again, lin= k quality information is not communicated.=C2=A0

This draft has no update to nhdp's=C2=A0information exc= hange=C2=A0communication,=C2=A0and I did not mention communica= tion. The performance difference between normal router and optimize-router = is within packet-delay and packet-loss.=C2=A0However, the draft gives the o= pportunity that=C2=A0each optimize-router=C2=A0may change its link=C2=A0inf= ormation which may loose consistency with its neighbours' information, = so packets can get lost with higher possibility.=C2=A0I will look into the = draft's update of=C2=A0nhdp/olsv2=C2=A0algorithm and see i= f I can solve the issue without communicating any info.=C2=A0

AB

--001a11c1e6a818443a0500902874-- From nobody Wed Aug 13 22:34: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 CCF841A0743 for ; Wed, 13 Aug 2014 22:34: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 3A5FTmC5LZDw for ; Wed, 13 Aug 2014 22:34:13 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EC71A0735 for ; Wed, 13 Aug 2014 22:34:13 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 19so625413ykq.16 for ; Wed, 13 Aug 2014 22:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=te6FHTN/Yb8HrDbO5KhzfqEBKGiBm+d0+BcioVcDlQ4=; b=qYZZqq5s1TP8apNH8Qi0GEP/jmNyYmSpq5wRLO5VirAjd8/OEe6DCKo83r+5yD5AsB zY8v/1398bsDo3C9RK6nYlshvi9Dzey7QBlWvLO9Zpd3KGTkrfPrRRzKuq8+4RzCpZ+P dU1DV+lIg3Ww3cfDrEIanrJkwFkdKH7SzjirEduQ5RB8cwoafzbrmDWTACDzt7vQfcHJ TuGyIDT8D0fziRytyQi9uCQJxc9WW3I7pL0HkiN5ZZPWiXBXI93CkIDU7HDfXXDLjwNd ksLky+mpAhbklSdL5ZY+zu9meGwALFqDx8MfEQpIYV+/6uWC0sPHd3dqNwZ8U3HCfR/f giBg== MIME-Version: 1.0 X-Received: by 10.236.134.208 with SMTP id s56mr14000464yhi.4.1407994452894; Wed, 13 Aug 2014 22:34:12 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Wed, 13 Aug 2014 22:34:12 -0700 (PDT) In-Reply-To: References: <066.0bb22f15b7c74448b0bb3821234ffc46@trac.tools.ietf.org> Date: Thu, 14 Aug 2014 07:34:12 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf303a2bbb35e9a7050090419e Archived-At: http://mailarchive.ietf.org/arch/msg/manet/IMjreWd1yDf25U629YYtP17zkCE Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "draft-ietf-manet-nhdp-optimization@tools.ietf.org" Subject: Re: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial 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: Thu, 14 Aug 2014 05:34:15 -0000 --20cf303a2bbb35e9a7050090419e Content-Type: text/plain; charset=UTF-8 On Wednesday, August 13, 2014, Ulrich Herberg wrote: > I concur with everything Chris said. I don't think that the draft > should be updated as suggested. I object to update RFC5444 or RFC6130 > unless it is essential (which I don't think it is). I don't think some one suggested update for 5444 in this thread. However the draft under WGLC is proposing updating 6130 (optional update). OLSRv2 RFC7181 depends on 5444 and 6130. AB --20cf303a2bbb35e9a7050090419e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, August 13, 2014, Ulrich Herberg wrote:
I concur with everything Chris said. I don't think= that the draft
should be updated as suggested. I object to update RFC5444 or RFC6130
unless it is essential (which I don't think it is).
I don't think some=C2=A0=C2=A0one suggested update for 544= 4 in this thread. However the draft under WGLC is proposing updating 6130 (= optional update).=C2=A0

OLSRv2 RFC7181=C2=A0depends on 5444 and 6130.=C2=A0

AB
--20cf303a2bbb35e9a7050090419e-- From nobody Thu Aug 14 00:54: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 DFE111A0930 for ; Thu, 14 Aug 2014 00:54:24 -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 oky94N43Skqx for ; Thu, 14 Aug 2014 00:54:23 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9090B1A092B for ; Thu, 14 Aug 2014 00:54:22 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so8505192wiv.7 for ; Thu, 14 Aug 2014 00:54:21 -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=zDUVAefBrlJDX/GnzWveOzWMVHI9VvqgMsA1/S3b6IE=; b=aKvnEaUgb/aG1/yBGJa/Y4CDfqCrJDwEgiVOnVJz5xOoRIYvlQW9UafkPVDaHU+kzI l8KGHt/LAAeYX34xTbIl5SSKNXGdF3wDRJLYF0DL31D2bu9aU10SR6S9vToYbcI903cG e+SvdrdpIDUil+hKXcXAV5xOaTXXKCiJMNCG6slQKyva4DQQ/BtRdn94X7XJBUzxfXlL n3jDWjWQfC3kw1BWodfy4uz/3+GqA94d1jYH1/lAT4VNNhvOkhfh5IXJ8tmRk9JGQVIN EIZSODDhLZtKvnHBooQ0EO6nvznYHNc1PFuVFIn9KctvEW6d5aV50pjaysf8a+FxpzSR LIOw== MIME-Version: 1.0 X-Received: by 10.194.95.166 with SMTP id dl6mr1392363wjb.115.1408002861151; Thu, 14 Aug 2014 00:54:21 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Thu, 14 Aug 2014 00:54:21 -0700 (PDT) In-Reply-To: References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> Date: Thu, 14 Aug 2014 09:54:21 +0200 X-Google-Sender-Auth: WpoILlUVB6Tqzhi-8aSwsbrNRuw Message-ID: From: Jiazi YI To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7bb0398261babe0500923602 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/agLtKPs8BOt8xUSSdNI5SKyrkM0 Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org" , Thomas Clausen Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 14 Aug 2014 07:54:25 -0000 --047d7bb0398261babe0500923602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Thu, Aug 14, 2014 at 7:27 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > > >> >> >> There isn=E2=80=99t even anything that could be changed because, and let= =E2=80=99s say it >> again, link quality information is not communicated. >> >> This draft has no update to nhdp's information exchange communication, a= nd > I did not mention communication. > > I will look into the draft's update of nhdp/olsv2 algorithm and see if I > can solve the issue without communicating any info. > > To be honest, what you said is kind of self-contradictory, and hard to parse. Jiazi > AB > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7bb0398261babe0500923602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0


On Thu, Aug 14, 2014 at 7:27 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
<snip>

=C2=A0

There isn=E2=80=99t even = anything that could be changed because, and let=E2=80=99s say it again, lin= k quality information is not communicated.=C2=A0

This draft has no update to nhdp's=C2=A0informati= on exchange=C2=A0communication,=C2=A0and I did not mention com= munication.

<snip>=C2=A0
=
=C2=A0I will look into the draft's update of=C2=A0nhdp/olsv2=C2=A0= algorithm and see if I can solve the issue without communicati= ng any info.=C2=A0


To be honest,= what you said is kind of self-contradictory, and hard to parse.=C2=A0

Jiazi
=C2=A0
AB


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


--047d7bb0398261babe0500923602-- From nobody Thu Aug 14 01:42: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 19E831A0982 for ; Thu, 14 Aug 2014 01:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 rKdJX7HKUXBg for ; Thu, 14 Aug 2014 01:42:08 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDD31A097E for ; Thu, 14 Aug 2014 01:42:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,861,1400022000"; d="scan'208";a="395691163" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Aug 2014 09:41:46 +0100 X-IronPort-AV: E=Sophos;i="5.01,861,1400022000"; d="scan'208";a="69453456" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 14 Aug 2014 09:42:03 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Thu, 14 Aug 2014 09:42:03 +0100 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg Thread-Topic: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial issues) Thread-Index: AQHPthE/YX2SR9vCC0ebmGQra7VFqJvMttRQgABXz4CAABUQwIABC1sAgAAQ+PCAAGgHAIABIkPQ Date: Thu, 14 Aug 2014 08:42:02 +0000 Message-ID: References: <066.0bb22f15b7c74448b0bb3821234ffc46@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xxYpk0wwM-R2VSOfinLImyab37s Cc: "manet@ietf.org" , "draft-ietf-manet-nhdp-optimization@tools.ietf.org" Subject: Re: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editorial 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: Thu, 14 Aug 2014 08:42:11 -0000 As later pointed out, but it's easier to reply to this, we have no plans (I= n fact more than that) to update 5444. This is an update to 6130, but we ha= ve no plans to obsolete 6130 (i.e. replace it with a 6130bis). Clash of nor= mal English and RFC Editor jargon. --=20 Christopher Dearlove Senior Principal Engineer, Information Assurance 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 Ulrich Herberg Sent: 13 August 2014 17:20 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; draft-ietf-manet-nhdp-optimization@tools.ietf.org Subject: Re: [manet] #52 (nhdp-optimization): Confused paragraph #1 (Editor= ial issues) ----------------------! 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. -------------------------------------------------------- I concur with everything Chris said. I don't think that the draft should be= updated as suggested. I object to update RFC5444 or RFC6130 unless it is e= ssential (which I don't think it is). Best regards Ulrich On Wed, Aug 13, 2014 at 2:13 AM, Dearlove, Christopher (UK) wrote: > Comments CMD below. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Information Assurance Group Communications,=20 > Networks and Image Analysis Capability BAE Systems Advanced Technology=20 > 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=20 > Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales=20 > No: 1996687 > > > > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 13 August 2014 10:07 > > > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; draft-ietf-manet-nhdp-optimization@tools.ietf.org > Subject: [manet] #52 (nhdp-optimization): Confused paragraph #1=20 > (Editorial > issues) > > > > I hope that the WG considers this thread points, and to put in mind: > > > > 1- that RFC7181 depends on 6130 and its other normative references.=20 > IETF did not standard any independent OLSRv2 from the RFC6130. > > > > CMD: Not relevant, with the possible exception of changing one word. > > > > 2- MANET routers are proactive, reactive, and hybrid. > > > > CMD: Not relevant. > > > > 3- neighbour discovery is part of routing as the 1-hop/2-hop=20 > neighbours can become possible destinations. Any update to RFC6130 is=20 > an update to all MANET routers that use RFC6130. > > > > CMD: No other standardised protocols need updating. (Stronger than=20 > that actually, see second part of next comment.) > > > > 4- as this WG decided to do RFC6130/RFC5444 (I disagree with the=20 > approach but it's the hard way and can be best way) before finishing=20 > its both routing standards (reactive and proactive) it is important to=20 > consider both routings needs while updating such RFCs 5444 and 6130. > > > > CMD: No one is planning to update 5444, and there are strong reasons=20 > not to do so unless essential. This update to 6130 is fully=20 > interoperable with non-updated implementations, so no impact there either= . > > ******************************************************************** > This email and any attachments are confidential to the intended=20 > recipient and may also be privileged. If you are not the intended=20 > 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=20 > distribute its contents to any other person. > ******************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From nobody Thu Aug 14 01: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 B478E1A0982 for ; Thu, 14 Aug 2014 01:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.567 X-Spam-Level: X-Spam-Status: No, score=-7.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 kDu2jE1ZWX-v for ; Thu, 14 Aug 2014 01:43:30 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4731B1A0980 for ; Thu, 14 Aug 2014 01:43:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,861,1400022000"; d="scan'208,217";a="395691550" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Aug 2014 09:43:08 +0100 X-IronPort-AV: E=Sophos; i="5.01,861,1400022000"; d="scan'208,217"; a="69453614" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 14 Aug 2014 09:43:25 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Thu, 14 Aug 2014 09:43:25 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change Thread-Index: AQHPtIU24If+JKsjMkmNfqDgEX2L75vJqzsAgAA4e4CAAAXkAIABNPAAgAASK5CAAAQFgIAAGxkQgAQ3KoCAAEdS4A== Date: Thu, 14 Aug 2014 08:43:25 +0000 Message-ID: References: <066.245678a3beb580a2324b5f543ed942a8@trac.tools.ietf.org> <3EF88342-669E-47F9-BCB4-C45BFBC7B217@mnemosyne.demon.co.uk> <037A3801-B720-472A-ACB9-0785E5571244@thomasclausen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D20BE1GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/OsNfsOjR-Z9r9czGusPaZkAlPks Cc: "manet@ietf.org" , Christopher Dearlove , Thomas Clausen Subject: Re: [manet] #51 (nhdp-optimization): Analysis of OLSRv2/NHDP-optimized Handling neighbor connection with link quality change 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, 14 Aug 2014 08:43:36 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D20BE1GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGhlIGZsYXdzIGluIHlvdXIgYW5hbHlzaXMgaGF2ZSBiZWVuIHBvaW50ZWQgb3V0IHNldmVyYWwg dGltZXMuIEnigJltIG5vdCBnb2luZyB0byByZXBlYXQgdGhlbS4NCg0KLS0NCkNocmlzdG9waGVy IERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFu Y2UgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2Fw YWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3QgSGFu bmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNClRl bDogKzQ0IDEyNDUgMjQyMTk0IHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+IHwg aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGlt aXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJv cm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUsN ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoNCkZyb206IEFiZHVz c2FsYW0gQmFyeXVuIFttYWlsdG86YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb21dDQpTZW50OiAx NCBBdWd1c3QgMjAxNCAwNjoyNw0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzog VGhvbWFzIENsYXVzZW47IENocmlzdG9waGVyIERlYXJsb3ZlOyBtYW5ldEBpZXRmLm9yZw0KU3Vi amVjdDogW21hbmV0XSAjNTEgKG5oZHAtb3B0aW1pemF0aW9uKTogQW5hbHlzaXMgb2YgT0xTUnYy L05IRFAtb3B0aW1pemVkIEhhbmRsaW5nIG5laWdoYm9yIGNvbm5lY3Rpb24gd2l0aCBsaW5rIHF1 YWxpdHkgY2hhbmdlDQoNCldHIHRvIGFuYWx5c2UgdGhlIHBhY2tldCBsb3NzIHByb2JsZW0gZm9y IHRoaXMgb3B0aW1pemF0aW9uLiBBbGwgTUFORVRzIGhhdmUgcGFja2V0IGxvc3QgYnV0IHRoZSBw cm9wb3NlZCBvcHRpbWl6ZWQgcm91dGVycyBuZWVkIHRvIGF2b2lkIGl0cyBwb3NzaWJsZSBpbmNy ZWFzZS4NCg0KT24gTW9uZGF5LCBBdWd1c3QgMTEsIDIwMTQsIERlYXJsb3ZlLCBDaHJpc3RvcGhl ciAoVUspIHdyb3RlOg0KVGhlcmUgaXMgbm8gbmVlZCAob3IgZXZlbiBhZHZhbnRhZ2UpIHRvIGNo YW5nZSAoYW1lbmRpbmcgc3VnZ2VzdHMgYSBwcm9ibGVtLCB3aGljaCB0aGVyZSBpc27igJl0KSB0 aGUgZHJhZnQgYmFzZWQgb24gYW55dGhpbmcgeW91IGhhdmUgcG9zdGVkLg0KWW91IGRpZCBub3Qg YW5hbHlzZSBieSBzYXlpbmcgbm8gbmVlZCBvciBpc24ndCBhIHByb2JsZW0uIElNSE8gdGhlcmUg aXMgdGhlIHBhY2tldCBsb3NzIHByb2JsZW0gYmVjYXVzZSByb3V0ZXIgQSB3aGVuIHJlY292ZXJl ZCBpdCBjb25zaWRlcnMgQyBhcyByZWFjaGVkIHRocm91Z2ggQiBidXQgQiBoYXMgdGhlIGxpbmsg Qi1DIGFzIGxvc3QuIFRoZSBvcHRpbWl6YXRpb24gaW1wcm92ZXMgcGFja2V0IGRlbGF5IGlzc3Vl cyBidXQgaW5jcmVhc2VzIHBhY2tldCBsb3NzIG9yIGRlY3JlYXNlcyBhdmVyYWdlIGRlbGl2ZXJ5 IHJhdGUgZm9yIHRoZSBNQU5FVCB0aGF0IGhhcyBtYW55IG9wdGltaXotcm91dGVycy4NCg0KVGhl cmUgaXNu4oCZdCBldmVuIGFueXRoaW5nIHRoYXQgY291bGQgYmUgY2hhbmdlZCBiZWNhdXNlLCBh bmQgbGV04oCZcyBzYXkgaXQgYWdhaW4sIGxpbmsgcXVhbGl0eSBpbmZvcm1hdGlvbiBpcyBub3Qg Y29tbXVuaWNhdGVkLg0KVGhpcyBkcmFmdCBoYXMgbm8gdXBkYXRlIHRvIG5oZHAncyBpbmZvcm1h dGlvbiBleGNoYW5nZSBjb21tdW5pY2F0aW9uLCBhbmQgSSBkaWQgbm90IG1lbnRpb24gY29tbXVu aWNhdGlvbi4gVGhlIHBlcmZvcm1hbmNlIGRpZmZlcmVuY2UgYmV0d2VlbiBub3JtYWwgcm91dGVy IGFuZCBvcHRpbWl6ZS1yb3V0ZXIgaXMgd2l0aGluIHBhY2tldC1kZWxheSBhbmQgcGFja2V0LWxv c3MuIEhvd2V2ZXIsIHRoZSBkcmFmdCBnaXZlcyB0aGUgb3Bwb3J0dW5pdHkgdGhhdCBlYWNoIG9w dGltaXplLXJvdXRlciBtYXkgY2hhbmdlIGl0cyBsaW5rIGluZm9ybWF0aW9uIHdoaWNoIG1heSBs b29zZSBjb25zaXN0ZW5jeSB3aXRoIGl0cyBuZWlnaGJvdXJzJyBpbmZvcm1hdGlvbiwgc28gcGFj a2V0cyBjYW4gZ2V0IGxvc3Qgd2l0aCBoaWdoZXIgcG9zc2liaWxpdHkuIEkgd2lsbCBsb29rIGlu dG8gdGhlIGRyYWZ0J3MgdXBkYXRlIG9mIG5oZHAvb2xzdjIgYWxnb3JpdGhtIGFuZCBzZWUgaWYg SSBjYW4gc29sdmUgdGhlIGlzc3VlIHdpdGhvdXQgY29tbXVuaWNhdGluZyBhbnkgaW5mby4NCg0K QUINCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRl IGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5v dCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3Ry aWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D20BE1GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBmbGF3cyBpbiB5b3VyIGFuYWx5c2lzIGhhdmUgYmVl biBwb2ludGVkIG91dCBzZXZlcmFsIHRpbWVzLiBJ4oCZbSBub3QgZ29pbmcgdG8gcmVwZWF0IHRo ZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLQ0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdG9waGVy IERlYXJsb3ZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5j ZSBHcm91cDxicj4NCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMg Q2FwYWJpbGl0eTxicj4NCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlPGJy Pg0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIg OEhOLCBVSzxicj4NClRlbDogJiM0Mzs0NCAxMjQ1IDI0MjE5NCZuYnNwO3wmbmJzcDsgRmF4OiAm IzQzOzQ0IDEyNDUgMjQyMTI0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT4NCiB8IGh0dHA6Ly93d3cu YmFlc3lzdGVtcy5jb208YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJBRSBTeXN0ZW1z IChPcGVyYXRpb25zKSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91 c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gs IEhhbnRzLCBHVTE0IDZZVSwgVUs8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2Fs ZXMgTm86IDE5OTY2ODc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWJkdXNzYWxhbSBCYXJ5dW4gW21haWx0bzphYmR1 c3NhbGFtYmFyeXVuQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxNCBBdWd1c3QgMjAx NCAwNjoyNzxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8 Yj5DYzo8L2I+IFRob21hcyBDbGF1c2VuOyBDaHJpc3RvcGhlciBEZWFybG92ZTsgbWFuZXRAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21hbmV0XSAjNTEgKG5oZHAtb3B0aW1pemF0aW9u KTogQW5hbHlzaXMgb2YgT0xTUnYyL05IRFAtb3B0aW1pemVkIEhhbmRsaW5nIG5laWdoYm9yIGNv bm5lY3Rpb24gd2l0aCBsaW5rIHF1YWxpdHkgY2hhbmdlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XRyB0byBhbmFseXNlIHRoZSBwYWNrZXQgbG9zcyBwcm9ibGVtIGZvciB0aGlzIG9w dGltaXphdGlvbi4gQWxsIE1BTkVUcyBoYXZlIHBhY2tldCBsb3N0IGJ1dCB0aGUgcHJvcG9zZWQm bmJzcDtvcHRpbWl6ZWQmbmJzcDtyb3V0ZXJzIG5lZWQgdG8gYXZvaWQgaXRzIHBvc3NpYmxlJm5i c3A7aW5jcmVhc2UuJm5ic3A7PGJyPg0KPGJyPg0KT24gTW9uZGF5LCBBdWd1c3QgMTEsIDIwMTQs IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyBubyBuZWVkIChvciBldmVuIGFkdmFudGFnZSkgdG8g Y2hhbmdlIChhbWVuZGluZyBzdWdnZXN0cyBhIHByb2JsZW0sIHdoaWNoIHRoZXJlIGlzbuKAmXQp IHRoZQ0KIGRyYWZ0IGJhc2VkIG9uIGFueXRoaW5nIHlvdSBoYXZlIHBvc3RlZC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PllvdSBkaWQgbm90IGFuYWx5c2UgYnkgc2F5aW5nIG5vIG5lZWQgb3IgaXNuJ3QgYSBwcm9ibGVt LiZuYnNwO0lNSE8gdGhlcmUmbmJzcDtpcyB0aGUmbmJzcDtwYWNrZXQgbG9zcyBwcm9ibGVtIGJl Y2F1c2Ugcm91dGVyIEEgd2hlbiByZWNvdmVyZWQgaXQgY29uc2lkZXJzIEMgYXMgcmVhY2hlZCB0 aHJvdWdoIEImbmJzcDtidXQgQiBoYXMgdGhlIGxpbmsgQi1DIGFzIGxvc3QuIFRoZSBvcHRpbWl6 YXRpb24gaW1wcm92ZXMmbmJzcDtwYWNrZXQgZGVsYXkgaXNzdWVzDQogYnV0IGluY3JlYXNlcyBw YWNrZXQgbG9zcyBvciBkZWNyZWFzZXMgYXZlcmFnZSZuYnNwO2RlbGl2ZXJ5IHJhdGUgZm9yIHRo ZSZuYnNwO01BTkVUIHRoYXQgaGFzIG1hbnkgb3B0aW1pei1yb3V0ZXJzLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBpc27igJl0IGV2ZW4gYW55 dGhpbmcgdGhhdCBjb3VsZCBiZSBjaGFuZ2VkIGJlY2F1c2UsIGFuZCBsZXTigJlzIHNheSBpdCBh Z2FpbiwgbGluayBxdWFsaXR5IGluZm9ybWF0aW9uDQogaXMgbm90IGNvbW11bmljYXRlZC4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZHJhZnQgaGFzIG5vIHVwZGF0ZSB0byBu aGRwJ3MmbmJzcDtpbmZvcm1hdGlvbiBleGNoYW5nZSZuYnNwO2NvbW11bmljYXRpb24sJm5ic3A7 YW5kIEkgZGlkIG5vdCBtZW50aW9uIGNvbW11bmljYXRpb24uIFRoZSBwZXJmb3JtYW5jZSBkaWZm ZXJlbmNlIGJldHdlZW4gbm9ybWFsIHJvdXRlciBhbmQgb3B0aW1pemUtcm91dGVyIGlzIHdpdGhp biBwYWNrZXQtZGVsYXkgYW5kIHBhY2tldC1sb3NzLiZuYnNwO0hvd2V2ZXIsIHRoZSBkcmFmdA0K IGdpdmVzIHRoZSBvcHBvcnR1bml0eSB0aGF0Jm5ic3A7ZWFjaCBvcHRpbWl6ZS1yb3V0ZXImbmJz cDttYXkgY2hhbmdlIGl0cyBsaW5rJm5ic3A7aW5mb3JtYXRpb24gd2hpY2ggbWF5IGxvb3NlIGNv bnNpc3RlbmN5IHdpdGggaXRzIG5laWdoYm91cnMnIGluZm9ybWF0aW9uLCBzbyBwYWNrZXRzIGNh biBnZXQgbG9zdCB3aXRoIGhpZ2hlciBwb3NzaWJpbGl0eS4mbmJzcDtJIHdpbGwgbG9vayBpbnRv IHRoZSBkcmFmdCdzIHVwZGF0ZSBvZiZuYnNwO25oZHAvb2xzdjImbmJzcDthbGdvcml0aG0gYW5k IHNlZQ0KIGlmIEkgY2FuIHNvbHZlIHRoZSBpc3N1ZSB3aXRob3V0IGNvbW11bmljYXRpbmcgYW55 IGluZm8uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFCPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4qKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKjxicj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwg dG8gdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUg aXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZb3Ugc2hvdWxk IG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJy PgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKio8L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D20BE1GLKXM0002VGREEN_-- From nobody Thu Aug 14 09:42: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 05FB61A0872 for ; Thu, 14 Aug 2014 09:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 AZlBG_3virKG for ; Thu, 14 Aug 2014 09:42:27 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03A01A0747 for ; Thu, 14 Aug 2014 09:42:27 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so1675699vcb.24 for ; Thu, 14 Aug 2014 09:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=/zJd0tnZBbx3KCwu2dz2iXPKsYhxEmw5cP5A7GWIQfo=; b=LHSdNctOIikamo3Fof0lexd83TVzhUuJGqECmsg+JwdLcLhfMG9IX2O/VU5UPo0dXX mcgOiWNc+GikKoKVjwwz1MJyyZSo56rrjSE5jrX5e2nlRdPR2jpUHqGWD5VwIhjnOTY/ XvGJrZSE5br4BeOafDzwfFdACOD0fq+SRvkis= 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=/zJd0tnZBbx3KCwu2dz2iXPKsYhxEmw5cP5A7GWIQfo=; b=fCogbx9WNTPd4rcPU0CIFdrRfSy8B972MWuh03CnuyBU9ocsLbWmPDDW4KnEXvlh84 qMkJbnEBYIuc0J13ususJc3S7F83z47TWcKntqaJlG7XtCiSfkBIN4b0+Vatcb7IjpQh K07SExPqRZ3bzgWfbGi/aaECG+VWrIYV4qJlZRTVcl2oAS0Ln6wIvu0z75+P6N+DgOsg 1r7Q2TW6eZBsjt4DVColcZDt73H36Z8ME4FVADxkbHfH3jBrPEbgAxij4EnAa/4IvyDK mz3PE5I59/S3TT7jKxBytDYnmji9bNnekdF8bpEJShz0GrbYCG9MvcZRSjJDQiA2ku6v rhZw== X-Gm-Message-State: ALoCoQmjUVCIi312qjqMHtex3iTxbbsbWOvr+5rHTf/oK3LUFjrcYwqTar87pE0j/n646fsLq99z MIME-Version: 1.0 X-Received: by 10.220.97.5 with SMTP id j5mr5467389vcn.16.1408034546802; Thu, 14 Aug 2014 09:42:26 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Thu, 14 Aug 2014 09:42:26 -0700 (PDT) Date: Thu, 14 Aug 2014 09:42:26 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6bo77mIvgxFnkdN0tdux_lXXo-s Subject: [manet] Preliminary minutes available 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, 14 Aug 2014 16:42:29 -0000 Hi, I uploaded the minutes that Ronald sent me (thanks!) http://www.ietf.org/proceedings/90/minutes/minutes-90-manet Please check them and let me know if changes are required. Best regards Ulrixh From nobody Thu Aug 14 18:21: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 C0BC61A89CC for ; Thu, 14 Aug 2014 18:21:45 -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, 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 ekdEs-TtU8iQ for ; Thu, 14 Aug 2014 18:21:44 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271251A6F39 for ; Thu, 14 Aug 2014 18:21:44 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x3so1818300qcv.23 for ; Thu, 14 Aug 2014 18:21:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=/oKZj8SPnh1VWJ8iUdM++i6EzgRi1js731i8iz85Ltk=; b=MKkuGZAqIP5pfaxIwLM2UrEY9yoO9poROhK0XnlSN6bW7iRvPBQGWAhl2SvIxBePKb jJO01BBhCJe2lWe5KSF07bF/0xzEz2zaYn7xJaulUStO4RVx7zoGb1jdzawWCBXk8cuR mivpdA03PriTl372YCCQ+x99FiTcnbGhgYz2VEHtp34yi866ji9aloJ9k6jgu5lM7c9/ 4fHLPz5gRip0Ky9+wjcdnRl/l1oNOy3nR0MpHDiMHeEqJ4jH/9a8b1d+240nxKgsJ5dQ QnpLcCKJgaKqShlHXqkE7iXTy39KjEk+wxXUnY+3R4Qzd8/xd3Y0q5QG7gA1CBKvLesL x5HA== X-Gm-Message-State: ALoCoQnfdf1PjoiuIfpFWwG7hl5pdktmaN2W+IMnTbz8qeXg4PwJjqJ3tABgKdmPUt5xaSby4mZ/ X-Received: by 10.224.65.196 with SMTP id k4mr23521330qai.56.1408065703392; Thu, 14 Aug 2014 18:21:43 -0700 (PDT) Received: from GLLaptop (c-98-216-180-107.hsd1.ma.comcast.net. [98.216.180.107]) by mx.google.com with ESMTPSA id 38sm7277194qgp.30.2014.08.14.18.21.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Aug 2014 18:21:42 -0700 (PDT) From: "Geoff Ladwig" To: References: <53E4C4C7.1050905@fkie.fraunhofer.de> In-Reply-To: <53E4C4C7.1050905@fkie.fraunhofer.de> Date: Thu, 14 Aug 2014 21:21:59 -0400 Message-ID: <000301cfb827$501df690$f059e3b0$@verdantnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlJulcUGCGokfNzifK60dvIy9XFwL0NwyVnA5eZEA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/manet/VkXOVshNNh7td3x-6mYZ8LLw83k Subject: Re: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document 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, 15 Aug 2014 01:21:45 -0000 I am also in favor of adopting this as an experimental draft. Geoff Ladwig Verdant Networks -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: Friday, August 8, 2014 8:39 AM To: manet@ietf.org Subject: Re: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document On 08/08/2014 02:34 PM, Sylvain David wrote: > I'm in favor of WG adoption. I am also in favor adopting it as an experimental draft. I think multipath-routing in radio networks is still a quite complicated topic = and it will need quite a bit experimentation to find a "one size fits all" variant of the Dijkstra algorithm that maintains enough separation = between the different paths. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From nobody Thu Aug 14 19:04: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 2016D1A06B5 for ; Thu, 14 Aug 2014 19:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 tRRycc0Ct8Vk for ; Thu, 14 Aug 2014 19:03:57 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672411A06A4 for ; Thu, 14 Aug 2014 19:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=277; q=dns/txt; s=iport; t=1408068238; x=1409277838; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DDi1HqadkZgn1wFYhU/6Lk1rPv+aW6DSh/qwuym6aZk=; b=Ls9zZDR9Uer8QB7YSxrhM/2vibHWUeOTqZ7nc3lPjbjVsqlqxfGjy+bC Gm0igT7XSMdPzmppD32PvIbe4ncxgX7r4H29NKGYXZ+kGbyhgJzpb3Ad+ Hn+b/HPr+CPQhMFmww1KtW4NhZIj7Pt+jSwmOhSJM6k1QhjXoY67m2nqC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFALFp7VOtJV2Y/2dsb2JhbABagw2BLtU8AYEUFneEBAEBBIEJAgEIRjIlAgSIVcVEF48ZOoMvgR0FimOGOosclH6CFoFGgjSBBwEBAQ X-IronPort-AV: E=Sophos;i="5.01,867,1400025600"; d="scan'208";a="69440292" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 15 Aug 2014 02:03:58 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7F23uYb005572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Aug 2014 02:03:56 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 21:03:56 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document Thread-Index: AQHPswUsjazKnY/7nEKhlHIHI/4YwJvG+RmAgApDTICAAAu4gA== Date: Fri, 15 Aug 2014 02:03:55 +0000 Message-ID: References: <53E4C4C7.1050905@fkie.fraunhofer.de> <000301cfb827$501df690$f059e3b0$@verdantnetworks.com> In-Reply-To: <000301cfb827$501df690$f059e3b0$@verdantnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.216.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NlGPFEM1QLmIYeWk_BmDUY6sRAA Subject: Re: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document 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, 15 Aug 2014 02:03:59 -0000 Working Group Participants,=20 It appears that we have sufficient interest (and no objections) to acceptin= g this draft as a working group document. Document accepted.=20 Authors, if you would, please re-post as draft-ietf-manet-olsrv2-multipath. Regards, Stan From nobody Fri Aug 15 03:21: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 E010D1A8A37; Fri, 15 Aug 2014 03:21:02 -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 kg3wWV8WahWl; Fri, 15 Aug 2014 03:21:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D64221A8A33; Fri, 15 Aug 2014 03:21:01 -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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140815102101.13128.25119.idtracker@ietfa.amsl.com> Date: Fri, 15 Aug 2014 03:21:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pHpLKUxUvvF5KPq66ViBfTkHxiQ Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-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: Fri, 15 Aug 2014 10:21: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 : Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Jiazi Yi Benoit Parrein Filename : draft-ietf-manet-olsrv2-multipath-00.txt Pages : 17 Date : 2014-08-15 Abstract: This document specifies a multi-path extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-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 Fri Aug 15 03:30: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 EA0081A8A35 for ; Fri, 15 Aug 2014 03:30:24 -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 MYEehBbah0Sm for ; Fri, 15 Aug 2014 03:30:23 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5684C1A09CA for ; Fri, 15 Aug 2014 03:30:23 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so2180766wes.35 for ; Fri, 15 Aug 2014 03:30:22 -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:content-type; bh=HStWXzI+6+8SLK58eRnRYcHJToPdcgn4NKW7X473J00=; b=wd+f36aBrKFDC12NM1uPylqU86PKgJH2JdDPeKJfRM35Qjp3VKxuuTuk/yOLKJYgct 9KW+TzVyH1gmbux9nIRrQFqawKQ2tYDIjGmOJyADrcpHXJ8l8G3hWb9mxTC9oN9jL6c4 a5lDb3uDKpdjDHFz8VdsLmwWmv17lcSq1uhPD9xPI1Pcn2WnLwICYQ+gzpSVhxD/wLTm 6LuMGlfEiUimg8bZi+Lopp4vp8W5U8Q2cHFAl+E7taqtSoSykN3DiEIi7qwnS7paXWrA MqAldxe0/RxPUjmOC9NhNgFWQxxuIGL2JK+yaHLd5VF9K96QTOlKAXGm01rRS/U2uPeN WHXg== MIME-Version: 1.0 X-Received: by 10.180.86.225 with SMTP id s1mr19339022wiz.46.1408098621946; Fri, 15 Aug 2014 03:30:21 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Fri, 15 Aug 2014 03:30:21 -0700 (PDT) In-Reply-To: <20140815102101.13128.25119.idtracker@ietfa.amsl.com> References: <20140815102101.13128.25119.idtracker@ietfa.amsl.com> Date: Fri, 15 Aug 2014 12:30:21 +0200 X-Google-Sender-Auth: dXN8xy-lqnMnwz3-Hkfmn9xOgVY Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=f46d044286102b80b80500a8825b Archived-At: http://mailarchive.ietf.org/arch/msg/manet/cE9cCrcjOblHfO6CaI-iTEUqFEc Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-00.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: Fri, 15 Aug 2014 10:30:25 -0000 --f46d044286102b80b80500a8825b Content-Type: text/plain; charset=UTF-8 Dear all, As you might have seen, we have submitted draft-ietf-manet-olsrv2- multipath-00. As usual, it's the same as the previous draft-yi-manet-olsrv2-multipath-02 (except fixing the code point issue that Ulrich pointed out at http://www.ietf.org/mail-archive/web/manet/current/msg16777.html ). We will submit a new revision based on the comments that we received later. thanks very much for all your support! cheers Jiazi On Fri, Aug 15, 2014 at 12:21 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 : Multi-path Extension for the Optimized Link > State Routing Protocol version 2 (OLSRv2) > Authors : Jiazi Yi > Benoit Parrein > Filename : draft-ietf-manet-olsrv2-multipath-00.txt > Pages : 17 > Date : 2014-08-15 > > Abstract: > This document specifies a multi-path extension to the Optimized Link > State Routing Protocol version 2 (OLSRv2) to discover multiple > disjoint paths, so as to improve reliability of the OLSRv2 protocol. > The interoperability with OLSRv2 is retained. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-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/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --f46d044286102b80b80500a8825b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

As you might have seen,= we have submitted=C2=A0draft-ietf-manet-olsrv2-multipath-00.=C2=A0

As = usual, it's the same as the previous draft-yi-manet-olsrv2-multipath-02= (except fixing the code point issue that Ulrich pointed out at=C2=A0http://www.ietf.org/mail-archive/web/ma= net/current/msg16777.html=C2=A0).=C2=A0

We = will submit a new revision based on the comments that we received later.=C2= =A0

tha= nks very much for all your support!

cheers

Jiazi


On Fri,= Aug 15, 2014 at 12:21 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Mobile Ad-hoc Networks Working Group= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Multi-path Extension for the Optimized Link State Routing Protocol version= 2 (OLSRv2)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Jiaz= i Yi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Benoit Parrein
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-manet-olsrv2-multipath-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-08-15

Abstract:
=C2=A0 =C2=A0This document specifies a multi-path extension to the Optimize= d Link
=C2=A0 =C2=A0State Routing Protocol version 2 (OLSRv2) to discover multiple=
=C2=A0 =C2=A0disjoint paths, so as to improve reliability of the OLSRv2 pro= tocol.
=C2=A0 =C2=A0The interoperability with OLSRv2 is retained.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-ol= srv2-multipath/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-olsrv2-multi= path-00


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

--f46d044286102b80b80500a8825b-- From nobody Sun Aug 17 14:51: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 0A4A91A0054 for ; Sun, 17 Aug 2014 14:51:29 -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 CQr1kEiNnzkZ for ; Sun, 17 Aug 2014 14:51:27 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691661A0053 for ; Sun, 17 Aug 2014 14:51:27 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so2819568wiv.9 for ; Sun, 17 Aug 2014 14:51:26 -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:content-type; bh=dESlxacR+fFbnQbb+DLeAX9JBYOvsn/TjZ6KwNvOEaQ=; b=KakloKUUmmFGuBlraLQ3ejHHs39Xh0CG5z4cjxjXtix1A56+QKb8YPWZ7szXNeuZTX S6Ky1cFQwsbzyZEIlnNNJ/bK/CLTzfMeGT7oRUqnubNCUVILqfvtQylkUVcCyzVSyywc x3xueGvl02TlEGX0DDHCfQBWJ2AiMkI6BjIbf3X2xTQ2u0Zzu7PSwg1OB4i1tqax4f7O XTsoJiY8GaCB/og+FHirNCqbu97NvJYQkqxnTlO+IZnCTGL3oG2KSvQakbiM+OI2+obX qulljiyC/uQlEgs4hq1jo5/R0jxErioazJ27kDlP4vZBkPIyvgfq54EU4I0FXU9urQVu /w+g== MIME-Version: 1.0 X-Received: by 10.194.134.70 with SMTP id pi6mr38113918wjb.1.1408312285782; Sun, 17 Aug 2014 14:51:25 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.21.69 with HTTP; Sun, 17 Aug 2014 14:51:25 -0700 (PDT) In-Reply-To: References: <53E4C4C7.1050905@fkie.fraunhofer.de> <000301cfb827$501df690$f059e3b0$@verdantnetworks.com> Date: Sun, 17 Aug 2014 23:51:25 +0200 X-Google-Sender-Auth: NN7ng8sg4H9IcTm64moJ0NsSgvs Message-ID: From: Jiazi YI To: manet IETF Content-Type: multipart/alternative; boundary=089e01175d9d86ea800500da4153 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6jWbigf3A7GEQ6QOTzO-0OUojNE Subject: Re: [manet] Call to adopt draft-yi-manet-olsrv2-multipath as a working group document 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, 17 Aug 2014 21:51:29 -0000 --089e01175d9d86ea800500da4153 Content-Type: text/plain; charset=UTF-8 Dear all, Thanks again for your support on the document. We have summarised the open issues of the document based on the comments and feedback that we received so far, and plan to submit a new revision addressing those issues, preferably in the end of August. Our plan is to resolve all the questions raised before November, and discuss the document at IETF 91 in Hawaii. We would like to aim for WGLC after the Hawaii meeting. regards Jiazi Questions/comments currently on the table: - Security consideration, which is now missing. It would be based on the RFC 7182 and olsrv2-sec-threats draft, plus the security issues of source routing. - Illustrate the potential issues of multi-path routing, such as possible packet re-ordering, etc. As an experimental draft, it's important to describe all facets of the extension. - The relationship with OLSRv2. After the exchange with some participants, I'm more convinced that the multipath extension can exist as a "plug-in" for OLSRv2: it can be applied to certain applications that are suitable for multipath routing (such as multi-media services), while retaining OLSRv2 routing for services for which OLSRv2 is advantageous. - More details in the Configuration parameters section. As some of the configurations are in the scope of "experiments to conducted", it would be helpful to elaborate the considerations of the authors based on the experiences obtained, and the possible directions to explore. On Fri, Aug 15, 2014 at 4:03 AM, Stan Ratliff (sratliff) wrote: > Working Group Participants, > > It appears that we have sufficient interest (and no objections) to > accepting this draft as a working group document. > > Document accepted. > > Authors, if you would, please re-post as draft-ietf-manet-olsrv2-multipath. > > Regards, > Stan > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e01175d9d86ea800500da4153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

Thanks again= for your support on the document.=C2=A0

We have s= ummarised the open issues of the document based on the comments and feedbac= k that we received so far, and plan to submit a new revision addressing tho= se issues, preferably in the end of August.=C2=A0
Our plan is to resolve all the questions raised before November, and d= iscuss the document at IETF 91 in Hawaii. We would like to aim for WGLC aft= er the Hawaii meeting.=C2=A0

regards
Jiazi

Questions/comments currently on t= he table:

=C2=A0- Security consideration, which is= now missing. It would be based on the RFC 7182 and olsrv2-sec-threats draf= t, plus the security issues of source routing.=C2=A0
=C2=A0
=C2=A0- Illustrate the potential issues of multi-path= routing, such as possible packet re-ordering, etc. As an experimental draf= t, it's important to describe all facets of the extension.=C2=A0
<= div>=C2=A0
=C2=A0- The relationship with OLSRv2. After the exchange with some par= ticipants, I'm more convinced that the multipath extension can exist as= a "plug-in" for OLSRv2: it can be applied to certain application= s that are suitable for multipath routing (such as multi-media services), w= hile retaining OLSRv2 routing for services for which OLSRv2 is advantageous= .=C2=A0
=C2=A0
=C2=A0- More details in the Configuration parameters = section. As some of the configurations are in the scope of "experiment= s to conducted", it would be helpful to elaborate the considerations o= f the authors based on the experiences obtained, and the possible direction= s to explore.=C2=A0


On Fri,= Aug 15, 2014 at 4:03 AM, Stan Ratliff (sratliff) <sratliff@cisco.com= > wrote:
Working Group Participants,

It appears that we have sufficient interest (and no objections) to acceptin= g this draft as a working group document.

Document accepted.

Authors, if you would, please re-post as draft-ietf-manet-olsrv2-multipath.=

Regards,
Stan

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

--089e01175d9d86ea800500da4153-- From nobody Mon Aug 18 05:47: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 4E76D1A01BD for ; Mon, 18 Aug 2014 05:47:55 -0700 (PDT) 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 2ZSQzc1EFqRK for ; Mon, 18 Aug 2014 05:47:53 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F041A0197 for ; Mon, 18 Aug 2014 05:47:52 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7ICloPl014928; Mon, 18 Aug 2014 13:47:50 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7ICln7B014906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2014 13:47:50 +0100 From: "Adrian Farrel" To: Date: Mon, 18 Aug 2014 13:47:48 +0100 Message-ID: <00f701cfbae2$9dbf5110$d93df330$@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: Ac+64mvEANyRLPOUQ8yCPW+VZPQnvg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20888.007 X-TM-AS-Result: No--21.623-10.0-31-10 X-imss-scan-details: No--21.623-10.0-31-10 X-TMASE-MatchedRID: JCQNKC1sm2PMXKkorvNQjq91/YHX0i1lFJFr2qlKix+638ZUY6gSd1vZ d+pzqSxfzi6yb6MGq76n5uJOTcAA0MLk3xw1Sf9eA9lly13c/gGe8Eev9oWcztfq9P8IurSdPNZ otZu3jXmL6rcFZTWLOT4rhiXdUNbmBR2X5okNNicJT7rPzEqgu1AI6wCVrE3vW/Kb+C9IfiLf2V Jhj/WJG9TU7rx0lPTWFwNwQXpdRk7jNn0Okk5VX0TmBPe5ghof8GRhP/nTHNYcNoFOQs4hFTzc7 SOu3coJM6dA3q/rQVC9IDmfKlAy8I+uMz+W0xT5rK1919cGzDIL8TGleseLPDDJ9a3KikGoEGJC a/oTwlnv/Djx8CKFr6oHQUwwNtGsfYgoHl6iERItMfCdg6KRDfaS52LUPfcSaVpwbrclutyMCVZ q/S/h8k2N9yTxrC2sWBWLObgG5aA+ntlO46BrOpqrexa4CbEQguwtqyXlE6GP8rMhpdqTHk6Pne ZGFcPxkLae+Z8yyg0tnIPOoWVaUEft3VbicuzyaJiWzzHYz3SNxR0omuRmzazFQLYFPhyy6uCyh qdQTTMhJ/ufappeEpGTpe1iiCJqtD9qpBlNF8oLbigRnpKlKT4yqD4LKu3A Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ePZvLgh8Quy5rKgy5XFKjIY9CwY Cc: manet@ietf.org Subject: [manet] IANA section of draft-ietf-manet-olsrv2-multitopology 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: Mon, 18 Aug 2014 12:47:55 -0000 Hi, I have started my AD review of your draft having received the publication request. before I get too far into the document, I want to discuss the IANA Considerations section which, I think, needs a little work. - - - The IANA Considerations section of the document does not give IANA clear instructions about what they should do. They need to hear: - go to registry named foo - go to sub-registry named bar - make the following change to the registry... Everything else is a distraction to them and needs to come out of the document completely or be moved to another section. - - - But first, two meta questions: 1. In some of the sub-registries where you are assigning new Type Extensions, there is already scope for "Experimental Use." Why do you feel the need to have Expert Review assignments rather than using experimental values (the latter would not have their values recorded against this RFC nor have the values recorded in this RFC)? I should add here that you *are* allowed to have Expert Review assignments for Experimental RFCs (if the experts so agree). 2. I am fixing (on this week's IESG telechat) the fact that many of these sub-registries are missing their Designated Experts. That's a formality, and the WG chairs can stand in these roles. However, I suspect that the DEs have not explicitly made clear that they are OK with the assignments in this document. That's OK, but I just need to know (normally in the Shepherd write-up) and to let you know that IANA will ping the DEs at some point to get them to sign off, so making sure that they are happy in advance is a good way to avoid surprises. (The guidance to DEs in 5444/6.1 seems very clear.) - - - Section 13.1 as far as I can tell does not change the guidelines to the Designated Experts that have already been established. So I think you can safely delete this section. In particular, this section does not give IANA any information. - - - Section 13.2 > This specification replaces Table 11 of [RFC7181]. This reads like you are Updating 7181 (i.e. changing that specification). I don't believe that is your intention > That specified a > Message MPR Type described as MPR_WILLING, for which only Type > Extension 0 was defined. This specification reserves that name > MPR_WILLING for Type Extension 0, I think you mean "retains". "Reserve" has a specific IANA meaning of "not available for use". However, it appears that you are updating the text for the MPR_WILLING/0 value in the "MPR_WILLING Message Type Extensions" sub-registry found at https://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#mpr-wil ling-message-type-extension This you observe in the next sentence where you say: > It also changes the Value field > specification of the MPR_WILLING TLV. You need to show IANA the old text and the new text. I think that the text in your Table 2 may be useful to retain in this document (in another section) but is too much text for IANA to include in their registry. > defines a new Type Extension 1, with a new name MPR_TYPES, I don't think you can do this! Type 7 is already entirely known as MPR_WILLING (see the "Message TLV Types" sub-registry). So your choice here is to use a new Message TLV or to retain the same name for the new Type Extension. As far as IANA is concerned, you need to tell them: - in which sub-registry to include Type Extension 1 - what text to include with it > and leaves the remaining Type Extensions > of this TLV Type unnamed. "Unnamed"? Maybe you mean "Unassigned"? > Specifications of these TLVs are in Table 2. Each of these TLVs MUST > NOT be included more than once in a Message TLV Block. I don't think that IANA needs to see this table, and certainly doesn't need to know about the protocol rules. - - - Section 13.3 > Table 16 of [RFC7181] is replaced by Table 3. Note that the only > change is to the description of the Value field. If you are replacing a table in 7181 then you are updating 7181. But is that what this draft is doing? Anyway, I don't think IANA is interested in this point. They want to know what changes to make to the "GATEWAY Address Block TLV Type Extensions" sub-registry at https://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#gateway -address-block-tlv-type-extension Again, just old and new text. If you want to include Table 3 in this document, then please put it outside this section. > Table 13 of [RFC7181] is replaced by Table 4. Note that the only > change is to allocate 8 Type Extensions as assigned by administrative > action, in order to support administratively determined multi- > topologies. Pretty much exactly the same considerations. - - - If you can answer all this quickly, I can go ahead with the rest of my review. I suspect that the answers will need a revised I-D, but we can batch that with the rest of my review once I know what the answers are. Thanks, Adrian From nobody Mon Aug 18 07:18: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 EAA351A03CF for ; Mon, 18 Aug 2014 07:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 Lus70B9Yaf07 for ; Mon, 18 Aug 2014 07:18:53 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1DA1A03E6 for ; Mon, 18 Aug 2014 07:18:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,886,1400022000"; d="scan'208";a="396553057" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 18 Aug 2014 15:18:35 +0100 X-IronPort-AV: E=Sophos;i="5.01,886,1400022000"; d="scan'208";a="69857873" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 18 Aug 2014 15:18:54 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Mon, 18 Aug 2014 15:18:55 +0100 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , "draft-ietf-manet-olsrv2-multitopology.all@tools.ietf.org" Thread-Topic: [manet] IANA section of draft-ietf-manet-olsrv2-multitopology Thread-Index: Ac+64mvEANyRLPOUQ8yCPW+VZPQnvgACzbeg Date: Mon, 18 Aug 2014 14:18:55 +0000 Message-ID: References: <00f701cfbae2$9dbf5110$d93df330$@olddog.co.uk> In-Reply-To: <00f701cfbae2$9dbf5110$d93df330$@olddog.co.uk> 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/HR4dhZ_lvIvQcDGHnaE8GZpfMeI Cc: "manet@ietf.org" Subject: Re: [manet] IANA section of draft-ietf-manet-olsrv2-multitopology 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, 18 Aug 2014 14:18:55 -0000 Just an acknowledgement of this. No time today at least to get to most of i= t. And what follows is the problem, without any proposed solution. I will just note that we have a n issue as to whether names should be assig= ned to TLV types, or extended types. Sometimes a type naturally takes a who= le set of type and type extension, such as link metric. But sometimes just = a single extended type is required, and there's no reason for the other ext= ended types with the same type to have the same name. In fact it would be q= uite confusing to have to do so. So here we have an extended type that's related, but quite confusing to use= the same name for. Really here we want to name extended types. Simply usin= g the same name across all the extended types is not going to work longer t= erm (such as if we run out of types with extension zero). Of course this is a problem in that 5444 didn't describe a policy here, and= usage just evolved. With hindsight, I think I'd give types a name, and allow extended types to = have a name. So in this case the type might be MPR related, type extension = 0 would be MPR_WILLING, then this would be proposing (just for the moment l= et's ignore the experimental issue) that type extension 1 was MPR_TYPES etc= . Even that might be too restrictive (type name MPR is a rather narrow). Bu= t several of our existing TLVs have no reason to have a block of 256 all wi= th same name (I do not see 256 variants of LINK_STATUS). -- = Christopher Dearlove Senior Principal Engineer, Information Assurance 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 Adrian Farrel Sent: 18 August 2014 13:48 To: draft-ietf-manet-olsrv2-multitopology.all@tools.ietf.org Cc: manet@ietf.org Subject: [manet] IANA section of draft-ietf-manet-olsrv2-multitopology ----------------------! 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. -------------------------------------------------------- Hi, I have started my AD review of your draft having received the publication r= equest. before I get too far into the document, I want to discuss the IANA = Considerations section which, I think, needs a little work. - - - The IANA Considerations section of the document does not give IANA clear in= structions about what they should do. They need to hear: - go to registry named foo - go to sub-registry named bar - make the following change to the registry... Everything else is a distraction to them and needs to come out of the docum= ent completely or be moved to another section. - - - = But first, two meta questions: 1. In some of the sub-registries where you are assigning new Type = Extensions, there is already scope for "Experimental Use." Why do you feel the need to have Expert Review assignments rather than using experimental values (the latter would not have their values recorded against this RFC nor have the values recorded in this RFC)? I should add here that you *are* allowed to have Expert Review = assignments for Experimental RFCs (if the experts so agree). 2. I am fixing (on this week's IESG telechat) the fact that many of = these sub-registries are missing their Designated Experts. That's a formality, and the WG chairs can stand in these roles. However, I suspect that the DEs have not explicitly made clear that they are OK with the assignments in this document. That's OK, but I just need to know (normally in the Shepherd write-up) and to let you know that IANA will ping the DEs at some point to get them to sign off, so making sure that they are happy in advance is a good way to avoid surprises. (The guidance to DEs in 5444/6.1 seems very clear.) - - - Section 13.1 as far as I can tell does not change the guidelines to the Des= ignated Experts that have already been established. So I think you can safe= ly delete this section. In particular, this section does not give IANA any = information. - - - Section 13.2 > This specification replaces Table 11 of [RFC7181]. This reads like you are Updating 7181 (i.e. changing that specification). I don't believe that is your intention = = > That specified a > Message MPR Type described as MPR_WILLING, for which only Type = > Extension 0 was defined. This specification reserves that name = > MPR_WILLING for Type Extension 0, I think you mean "retains". "Reserve" has a specific IANA meaning of "not a= vailable for use". However, it appears that you are updating the text for the MPR_WILLING/0 va= lue in the "MPR_WILLING Message Type Extensions" sub-registry found at http= s://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#mpr-wil ling-message-type-extension This you observe in the next sentence where you say: > It also changes the Value field > specification of the MPR_WILLING TLV. You need to show IANA the old text and the new text. I think that the text = in your Table 2 may be useful to retain in this document (in another sectio= n) but is too much text for IANA to include in their registry. > defines a new Type Extension 1, with a new name MPR_TYPES, I don't think you can do this! Type 7 is already entirely known as MPR_WILLING (see the "Message TLV Types= " sub-registry). So your choice here is to use a new Message TLV or to retain the same name = for the new Type Extension. As far as IANA is concerned, you need to tell them: - in which sub-registry to include Type Extension 1 - what text to include with it > and leaves the remaining Type Extensions of this TLV Type unnamed. "Unnamed"? Maybe you mean "Unassigned"? > Specifications of these TLVs are in Table 2. Each of these TLVs MUST = > NOT be included more than once in a Message TLV Block. I don't think that IANA needs to see this table, and certainly doesn't need= to know about the protocol rules. - - - Section 13.3 > Table 16 of [RFC7181] is replaced by Table 3. Note that the only = > change is to the description of the Value field. If you are replacing a table in 7181 then you are updating 7181. But is tha= t what this draft is doing? Anyway, I don't think IANA is interested in this point. They want to know w= hat changes to make to the "GATEWAY Address Block TLV Type Extensions" sub-= registry at https://www.iana.org/assignments/manet-parameters/manet-paramet= ers.xhtml#gateway -address-block-tlv-type-extension Again, just old and new text. If you want to include Table 3 in this document, then please put it outside= this section. > Table 13 of [RFC7181] is replaced by Table 4. Note that the only = > change is to allocate 8 Type Extensions as assigned by administrative = > action, in order to support administratively determined multi- = > topologies. Pretty much exactly the same considerations. - - - If you can answer all this quickly, I can go ahead with the rest of my revi= ew. I suspect that the answers will need a revised I-D, but we can batch th= at with the rest of my review once I know what the answers are. Thanks, Adrian _______________________________________________ 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 Thu Aug 21 10: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 A39561A069C for ; Thu, 21 Aug 2014 10:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 EKwv-hMxZ2Hy for ; Thu, 21 Aug 2014 10:24:15 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6D01A03C8 for ; Thu, 21 Aug 2014 10:24:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,909,1406588400"; d="scan'208,217";a="397505660" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 21 Aug 2014 18:24:12 +0100 X-IronPort-AV: E=Sophos; i="5.04,909,1406588400"; d="scan'208,217"; a="70324285" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 21 Aug 2014 18:24:12 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Thu, 21 Aug 2014 18:24:12 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: draft-ietf-manet-olsrv2-management-snapshot-02 Thread-Index: Ac+9ZJKhh4WjrovCQIWLo5IzZkTiJw== Date: Thu, 21 Aug 2014 17:24:11 +0000 Message-ID: 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D21842GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vUVApQKu24unShMbWtAe5CUQWGM Cc: "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: [manet] draft-ietf-manet-olsrv2-management-snapshot-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, 21 Aug 2014 17:24:18 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D21842GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I failed to get any review comments in on draft-ietf-manet-olsrv2-managemen= t-snapshot-02 in before WGLC end. As such if I want any comments considered= , I will have to put them in at IETF review. Whether or not I do that, here are some comments. To be clear, I'm the docu= ment shepherd for this document, but that hat is off in making these commen= ts. (There are a couple of editorial errors that with that hat back on do need = fixing to avoid every reviewer making them. The authors were already aware = of these, though I wasn't aware they were aware, but there will need to be = a -03 to fix those for beyond the WG. Anyway, hat back off.) "C" is referred to as a parameter. That's appropriate at the management lev= el, but slightly confusing when put up against 6130/7181 which define it as= a constant, a separate category from parameters. I think I might have sugg= ested a comment in one place on that. The introduction could also list 7187 and 7188, but I'm not sure if there's= any gain there. 1.1 says this applies to some networks, while the abstract says typical. = Not quite the same thing. 3.1 could (as Henning might well point out) say that while the messages and= protocol instantiations are separate, the message could share a packet. T= hough there are some implications of saying so in terms of the 5444 multipl= exing not quite stated assumptions. 3.1 second paragraph I might have mentioned MAC as well as radio channel. B= ut definitely not necessary. 3.2 first paragraph "an IP address" might have been clearer as "a single IP= address". 3.2, it is actually possible to have dynamic MANET interface addresses. Esp= ecially if you change from address A to address B going via A and B for con= tinuity. 3.3 Was "USB key" meant? Overloads the word key. 3.3 paragraph 3. It's probably obvious to everyone interested in MANETs tha= t there's a chicken and egg problem in using the routing fabric you are con= structing to distribute the keys to establish that fabric. But not necessar= ily to everyone else. (I'm not suggesting this is insoluble of course.) 4.1 Minimum intervals are not discussed anywhere, but can have a significan= t effect (see also section 5 comment). 4.2 I can confirm some things speculated about here are not just speculatio= n - but I have no public domain information to back that up. (I suspect the= authors' position is similar.) 5. You can survive a long HELLO_INTERVAL if you operate all of the permitte= d responsive mechanisms (to send a HELLO when things change) and minimum in= tervals are small. Except that one HELLO may get lost, and now we would hav= e to consider how to behave. (One possibility is to reduce HELLO_INTERVAL t= o minimum for a few HELLO messages, then put it back up.) Details are beyon= d this document, but I think that here and/or 4.1 some comment on minimum i= ntervals would be useful. (Better still would be a longer discussion, but t= hat's for another document another day.) 7 (which has an odd mixed-case title) is "reflective" meant rather than "re= flexive"? 9 An example attack following directly from earlier in the document is to = set message intervals excessively long or short. -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D21842GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

I failed to get any review comments in on draft-ietf= -manet-olsrv2-management-snapshot-02 in before WGLC end. As such if I want = any comments considered, I will have to put them in at IETF review.

 

Whether or not I do that, here are some comments. To= be clear, I’m the document shepherd for this document, but that hat = is off in making these comments.

 

(There are a couple of editorial errors that with th= at hat back on do need fixing to avoid every reviewer making them. The auth= ors were already aware of these, though I wasn’t aware they were awar= e, but there will need to be a -03 to fix those for beyond the WG. Anyway, hat back off.)

 

“C” is referred to as a parameter. That&= #8217;s appropriate at the management level, but slightly confusing when pu= t up against 6130/7181 which define it as a constant, a separate category f= rom parameters. I think I might have suggested a comment in one place on that.

 

The introduction could also list 7187 and 7188, but = I’m not sure if there’s any gain there.

 

1.1   says this applies to some networks, while the abstr= act says typical. Not quite the same thing.

 

3.1 could (as Henning might well point out) say that= while the messages and protocol instantiations are separate, the message c= ould share a packet.  Though there are some implications of saying so = in terms of the 5444 multiplexing not quite stated  assumptions.

 

3.1 second paragraph I might have mentioned MAC as w= ell as radio channel. But definitely not necessary.

 

3.2 first paragraph “an IP address” migh= t have been clearer as “a single IP address”.

 

3.2, it is actually possible to have dynamic MANET i= nterface addresses. Especially if you change from address A to address B go= ing via A and B for continuity.

 

3.3 Was “USB key” meant? Overloads the w= ord key.

 

3.3 paragraph 3. It’s probably obvious to ever= yone interested in MANETs that there’s a chicken and egg problem in u= sing the routing fabric you are constructing to distribute the keys to esta= blish that fabric. But not necessarily to everyone else. (I’m not suggesting this is insoluble of course.)

 

4.1 Minimum intervals are not discussed anywhere, bu= t can have a significant effect (see also section 5 comment).

 

4.2 I can confirm some things speculated about here = are not just speculation – but I have no public domain information to= back that up. (I suspect the authors’ position is similar.)

 

5. You can survive a long HELLO_INTERVAL if you oper= ate all of the permitted responsive mechanisms (to send a HELLO when things= change) and minimum intervals are small. Except that one HELLO may get los= t, and now we would have to consider how to behave. (One possibility is to reduce HELLO_INTERVAL to minimum for= a few HELLO messages, then put it back up.) Details are beyond this docume= nt, but I think that here and/or 4.1 some comment on minimum intervals woul= d be useful. (Better still would be a longer discussion, but that’s for another document another day.= )

 

7 (which has an odd mixed-case title) is “refl= ective” meant rather than “reflexive”?

 

9 An example attack  following directly from ea= rlier in the document is to set message intervals excessively long or short= .

 

-- <= /p>

Christopher Dearlove

Senior Principal Engin= eer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

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

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40D21842GLKXM0002VGREEN_-- From nobody Thu Aug 21 12:52: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 72C621A06CD for ; Thu, 21 Aug 2014 12:52:06 -0700 (PDT) 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 bVTIKvnBkzHZ for ; Thu, 21 Aug 2014 12:52:04 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1621A0698 for ; Thu, 21 Aug 2014 12:52:03 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7LJq1ss023298 for ; Thu, 21 Aug 2014 20:52:01 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7LJq1Ks023270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Aug 2014 20:52:01 +0100 From: "Adrian Farrel" To: References: <20140821180236.2352.38028.idtracker@ietfa.amsl.com> In-Reply-To: <20140821180236.2352.38028.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 20:51:56 +0100 Message-ID: <08d501cfbd79$5d6d4b50$1847e1f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFjZdzCqmKuz3HsMnXtLIoJGo8DfZy0JXZg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20898.002 X-TM-AS-Result: No--16.396-10.0-31-10 X-imss-scan-details: No--16.396-10.0-31-10 X-TMASE-MatchedRID: DbzvN+Ajrp9F9oq0S8wOxgPZZctd3P4BpfVcx39Kq+4EC1L5wWS9ivJs l+USu3BFV5N52tjhLiJByeJbXcsTpuClVqpL2c7Q4bl1FkKDELeeimGtNywjttp1biJhIyNRcBa 45GbRMhpFXcm/C/kiiXr9jjo4bRPUnuDmJvURYiAPiKpzmP1kmrs4WAMCqeyxB6d3D+KIwZA5UX cd4A5MhJ6Ss6O2bihGdJ8YUKjfpI7fq6lKkGAwoR03I0O1uBQRcbniFtnyrsh8+r7fJ9jXgKPFj JEFr+olSlnU38LCY8tp7Kxueu/Dit0H8LFZNFG7bkV4e2xSge7uz06z4TasFwvDL3VpeGdaf0qk WBNtpRDJyLx9EOzlWkuFvzEYSdV+ Archived-At: http://mailarchive.ietf.org/arch/msg/manet/nalZD82Cfr8kwxCCyTlWJ8jX5Ew Subject: [manet] FW: Appointment of Designated Experts for outstanding MANET registries 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: Thu, 21 Aug 2014 19:52:06 -0000 Hi, Just to keep you in the loop... We had a number of registries for MANET protocols that had "Expert = Review" as their IANA assignment policies, but where no expert had been = assigned.=20 The IESG has done the bit of process magic to appoint experts (the = chairs) and the email below is the kick to IANA to get them to update = the registries to show this. Thanks, Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: 21 August 2014 19:03 > To: iana@iana.org > Cc: iesg@ietf.org > Subject: Appointment of Designated Experts for outstanding MANET = registries >=20 > IANA, >=20 > The IESG has approved Joe Macker and Stan > Ratliff as the designated experts for the = following > sub-registries: >=20 > TC Message-Type-specific Message TLV Types > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#tc-message-type-specific-message >=20 > TC Message-Type-specific Address Block TLV Types > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#tc-message-type-specific-address-block >=20 > MPR_WILLING Message Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#mpr-willing-message-type-extension >=20 > CONT_SEQ_NUM Message Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#cont-seq-num-message-type-extension >=20 > HELLO Message-Type-specific Message TLV Types > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#message-tlv-hello >=20 > LOCAL_IF Address Block TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#local-if-address-block-tlv-type-extension >=20 > LINK_STATUS Address Block TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#link-status-address-block-tlv-type-extension >=20 > OTHER_NEIGHB Address Block TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#other-neighb-address-block-tlv-type-extension >=20 > LINK_METRIC Address Block TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#link-metric-address-block-tlv-type-extension >=20 > MPR Address Block TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#mpr-address-block-tlv-type-extension >=20 > NBR_ADDR_TYPE Address Block TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#nbr-addr-type-address-block-tlv-type-extension >=20 > GATEWAY Address Block TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#gateway-address-block-tlv-type-extension >=20 > HELLO Message-Type-specific Address Block TLV Types (range 128-223) > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#address-tlv-hello >=20 > ICV Packet TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#icv-packet-tlv-types >=20 > TIMESTAMP Packet TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#timestamp-packet-tlv-types >=20 > ICV Message TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#icv-message-tlv-types >=20 > TIMESTAMP Message TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#timestamp-message-tlv-types >=20 > ICV Address TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#icv-address-tlv-types >=20 > TIMESTAMP Address TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#timestamp-address-tlv-types >=20 > Hash Functions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#hash-functions >=20 > Cryptographic Functions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#cryptographic-algorithm >=20 > SMF_TYPE Message TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#smf-type-extensions >=20 > SMF_NBR_TYPE Address Block TLV Type Extensions > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#smf-nbr-types >=20 > SMF Relay Algorithm IDs > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#smf-relay-ids >=20 > LOCAL_IF TLV Values > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#local_if-tlv >=20 > LINK_STATUS TLV Values > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#link_status-tlv >=20 > OTHER_NEIGHB TLV Values > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#other_neighb-tlv >=20 > MPR TLV BIT Values > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#mpr-tlv-bit >=20 > NBR_ADDR_TYPE Address Block TLV Bit Values > https://www.iana.org/assignments/manet-parameters/manet- > parameters.xhtml#nbr_addr_type-address-block-tlv-bit >=20 > Best regards, > IESG Secretary From nobody Thu Aug 21 18:26: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 187161A6F8F for ; Thu, 21 Aug 2014 18:26:37 -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 WDvUzIsLNtyH for ; Thu, 21 Aug 2014 18:26:35 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2731A06AB for ; Thu, 21 Aug 2014 18:26:35 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 142so8182863ykq.24 for ; Thu, 21 Aug 2014 18:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=KbLOp7DYBscr6izLPzyL0ANH1pjpqrqUHAU9uFBunfM=; b=QDhBTh9cfltR97tNNWMxuXqHmjR1r7PJEWCY1OzwRkha1PktRDva33I7rtsJfqygBR 6ToL6otsnyBw4AGo3cN1T/At6oFdSvywgNQ27qTiC+iweiZYgQ6+wS+1JWriXC6W8vix YUYZ4UAzlESpev1Bzc+ZYTqLOeUfr3UOtEGMwO8/q7qiUiYknUSqLhHySWNxTN9p1O24 nBJiUwjy+Y4ljJi3EyxoM5tV3jxpXlDoAslQmfq0Pt7gNPyWRxZV9WVxOUFYRM+A3zhv be3gJ5+M/3bJtFZeKo2Lv+6oti14qXn/nIZvbBbHLqOMxEXDPwOp6+2lxaITMe63EBee yhdg== MIME-Version: 1.0 X-Received: by 10.236.25.105 with SMTP id y69mr2694617yhy.33.1408670794589; Thu, 21 Aug 2014 18:26:34 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Thu, 21 Aug 2014 18:26:34 -0700 (PDT) Date: Fri, 22 Aug 2014 03:26:34 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=089e013cb8b0512c9a05012dbae9 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/fOzjaju9Q6NixY0ojGkqFSllcHU Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" Subject: [manet] MANET Parameters Review (Related to IANA sections of RFC7181 - RFC7188) 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, 22 Aug 2014 01:26:37 -0000 --089e013cb8b0512c9a05012dbae9 Content-Type: text/plain; charset=UTF-8 Reviewer: Abdussalam Baryun (AB) Dated: 25.04.2014 (not completed) This is AB review of the MANET parameters documents [1][2] that were updated on 14.04.2014 in relation of the new RFCs [7181-7188]. However, not completed for future review, but it may help. [1] https://www.iana.org/assignments/manet-parameters/manet-parameters.txt [2] ftp://ftp.ietf.org/iana/manet-parameters/manet-parameters.txt Comments below as [AB]: +++++++++++++++++++++++++++++++++++++++++ Mobile Ad hoc NETwork (MANET) Parameters Created 2008-12-23 Last Updated 2014-04-14 Available Formats [IMG] XML [IMG] HTML [IMG] Plain text Created 2008-12-23 Last Updated 2014-04-14 Available Formats [IMG] XML [IMG] HTML [IMG] Plain text Registries included below * Message Types * TC Message-Type-specific Message TLV Types [AB] please amend registery to: Message-Type-Specific Message TLV Types for the TC Message Type. [AB] or amend registery to: Message-Type-Specific Message TLV Types for Message Type 1. * TC Message-Type-specific Address Block TLV Types [AB] please amend registery to: Message-Type-Specific Address Block TLV Types for the TC Message Type. [AB] or amend registery to: Message-Type-Specific Address Block TLV Types for Message Type 1. * Packet TLV Types * Message TLV Types * INTERVAL_TIME Message Type Extensions [AB] INTERVAL_TIME is a message TLV Type, please amend from message Type to message TLV Type * VALIDITY_TIME Message Type Extensions [AB] VALIDITY_TIME is a message TLV Type, please amend from message Type to message TLV Type. * MPR_WILLING Message Type Extensions [AB] MPR_WILLING is a message TLV Type, please amend from message Type to message TLV Type. * CONT_SEQ_NUM Message Type Extensions [AB] CONT_SEQ_NUM is a message TLV Type, please amend from message Type to message TLV Type. ------------- I think the WG should review the parameters/registries. AB --089e013cb8b0512c9a05012dbae9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Reviewer: Abdussalam Baryun (AB)
Dated: 25.04.2014 (not completed)
=C2=A0
This is AB review of the MANET parameters=C2=A0documents [1][2] that w= ere updated on 14.04.2014 in relation of=C2=A0the new RFCs [7181-7188]. How= ever, not completed for future review, but it may help.=C2=A0
=C2=A0
=C2=A0
=C2=A0
Comments below as [AB]:
=C2=A0
+++++++++++++++++++++++++++++++++++++++++
=C2=A0
Mobile Ad hoc NETwork (MANET) Parameters

=C2=A0=C2=A0 Created=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2008-12-23
=C2=A0=C2=A0 Last Updated
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 2014-04-14

=C2=A0=C2=A0 Available Formats
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [IMG]
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XML [IMG]
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HTML [IMG]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Plain text
=
Created
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 2008-12-23

=C2=A0=C2=A0 Last Updated
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2014-04-14

=C2=A0=C2=A0 Availab= le Formats
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = [IMG]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XML [= IMG]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HTML [= IMG]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Plain = text

=C2=A0=C2=A0 Registries included below

=C2=A0=C2=A0=C2=A0=C2=A0 * Message Types

=C2=A0=C2=A0=C2=A0=C2=A0 * TC Message-Type-specific Message TLV Ty= pes
=C2=A0
[AB]=C2=A0please amend registery to: Message-Type-Specific Message TLV= Types for the TC Message Type.
[AB]=C2=A0or=C2=A0amend registery to: Message-Type-Specific Message TL= V Types for Message Type 1.

=C2=A0=C2=A0=C2=A0=C2=A0 * TC Message-Type-specific Address Block = TLV Types
=C2=A0
[AB]=C2=A0please amend registery to: Message-Type-Specific=C2=A0Addres= s Block TLV Types for the TC Message Type.
[AB]=C2=A0or amend registery = to: Message-Type-Specific=C2=A0Address Block TLV Types for Message Type 1.<= /div>
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0 * Packet TLV Types
=C2=A0=C2=A0=C2=A0=C2= =A0 * Message TLV Types

=C2=A0=C2=A0=C2=A0=C2=A0 * INTERVAL_TIME Message Type Extensions
=C2=A0
[AB] INTERVAL_TIME is a message TLV Type, please amend from message Ty= pe to message TLV Type

=C2=A0=C2=A0=C2=A0=C2=A0 * VALIDITY_TIME Message Type Extensions
=C2=A0
[AB] VALIDITY_TIME is a message TLV Type, please amend from message Ty= pe to message TLV Type.

=C2=A0=C2=A0=C2=A0=C2=A0 * MPR_WILLING Message Type Extensions
=C2=A0
[AB] MPR_WILLING is a message TLV Type, please amend from message Type= to message TLV Type.

=C2=A0=C2=A0=C2=A0=C2=A0 * CONT_SEQ_NUM Message Type Extensions
=C2=A0
[AB] CONT_SEQ_NUM is a message TLV Type, please amend from message Typ= e to message TLV Type.

-------------

I think the WG should= review the parameters/registries.=C2=A0

AB --089e013cb8b0512c9a05012dbae9-- From nobody Thu Aug 21 18: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 0A5151A7022 for ; Thu, 21 Aug 2014 18:30:45 -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 me329-_l_YNA for ; Thu, 21 Aug 2014 18:30:43 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C403C1A8754 for ; Thu, 21 Aug 2014 18:30:42 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id c41so8634100yho.26 for ; Thu, 21 Aug 2014 18:30:42 -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=E342zLnbRq+f/UchPdbbJPV2gKWtzppYk4Ifv1LJJCg=; b=kWNV3Mzni8+TPkqte3bvMy4h5fhcCAVMk4FSNbexUNKRobizB/2w/CcYquMe1jCT/Y Vg/SzBlrCtqT29onFno8dNSyCUIoibqYL1U/Dfp/e4y4P+T/NT++FH33DvNDs/Lf6GPk 8S9hr7cBGshKDi/TEYDiZ9OT2XNYbfq5XTtQeUMWrtRGj3YbwSf39ct1xyoSI/8uUWnl ZG7ek3GdWc6/8f4hi2tUMgXnh0vl4Vp1iSmOyIOcLJNSVbN2J8DdY11LuHWzzEMMB0bS PK1X27HoMUB52TpkypJOD5rwqZP4JDc0mcoudqcAOEPH5hXkiImKKLoxmXPpIOvgaXMw IKiA== MIME-Version: 1.0 X-Received: by 10.236.25.105 with SMTP id y69mr2718284yhy.33.1408671042119; Thu, 21 Aug 2014 18:30:42 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Thu, 21 Aug 2014 18:30:42 -0700 (PDT) In-Reply-To: <08d501cfbd79$5d6d4b50$1847e1f0$@olddog.co.uk> References: <20140821180236.2352.38028.idtracker@ietfa.amsl.com> <08d501cfbd79$5d6d4b50$1847e1f0$@olddog.co.uk> Date: Fri, 22 Aug 2014 03:30:42 +0200 Message-ID: From: Abdussalam Baryun To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=089e013cb8b0122c7705012dc934 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/LMWo-QoTfySTUgoZM71upLeKfxs Cc: "manet@ietf.org" Subject: Re: [manet] FW: Appointment of Designated Experts for outstanding MANET registries 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, 22 Aug 2014 01:30:45 -0000 --089e013cb8b0122c7705012dc934 Content-Type: text/plain; charset=UTF-8 Hi Adrian, I have seen some updates of that before months. I checked the MANET registries in April and I thought there were some amendment needed for the users of our protocols. I did not finish my review of that. However, will send it to the WG as well. I hope we are allowed to discuss that here. On Thursday, August 21, 2014, Adrian Farrel wrote: > Hi, > > Just to keep you in the loop... > > We had a number of registries for MANET protocols that had "Expert Review" > as their IANA assignment policies, but where no expert had been assigned. > > The IESG has done the bit of process magic to appoint experts (the chairs) > and the email below is the kick to IANA to get them to update the > registries to show this. > > Thanks, > Adrian > > > -----Original Message----- > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary > > Sent: 21 August 2014 19:03 > > To: iana@iana.org > > Cc: iesg@ietf.org > > Subject: Appointment of Designated Experts for outstanding MANET > registries > > > > IANA, > > > > The IESG has approved Joe Macker and Stan > > Ratliff as the designated experts for the following > > sub-registries: > > > > TC Message-Type-specific Message TLV Types > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#tc-message-type-specific-message > > > > TC Message-Type-specific Address Block TLV Types > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#tc-message-type-specific-address-block > > > > MPR_WILLING Message Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#mpr-willing-message-type-extension > > > > CONT_SEQ_NUM Message Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#cont-seq-num-message-type-extension > > > > HELLO Message-Type-specific Message TLV Types > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#message-tlv-hello > > > > LOCAL_IF Address Block TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#local-if-address-block-tlv-type-extension > > > > LINK_STATUS Address Block TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#link-status-address-block-tlv-type-extension > > > > OTHER_NEIGHB Address Block TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#other-neighb-address-block-tlv-type-extension > > > > LINK_METRIC Address Block TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#link-metric-address-block-tlv-type-extension > > > > MPR Address Block TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#mpr-address-block-tlv-type-extension > > > > NBR_ADDR_TYPE Address Block TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#nbr-addr-type-address-block-tlv-type-extension > > > > GATEWAY Address Block TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#gateway-address-block-tlv-type-extension > > > > HELLO Message-Type-specific Address Block TLV Types (range 128-223) > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#address-tlv-hello > > > > ICV Packet TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#icv-packet-tlv-types > > > > TIMESTAMP Packet TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#timestamp-packet-tlv-types > > > > ICV Message TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#icv-message-tlv-types > > > > TIMESTAMP Message TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#timestamp-message-tlv-types > > > > ICV Address TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#icv-address-tlv-types > > > > TIMESTAMP Address TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#timestamp-address-tlv-types > > > > Hash Functions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#hash-functions > > > > Cryptographic Functions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#cryptographic-algorithm > > > > SMF_TYPE Message TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#smf-type-extensions > > > > SMF_NBR_TYPE Address Block TLV Type Extensions > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#smf-nbr-types > > > > SMF Relay Algorithm IDs > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#smf-relay-ids > > > > LOCAL_IF TLV Values > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#local_if-tlv > > > > LINK_STATUS TLV Values > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#link_status-tlv > > > > OTHER_NEIGHB TLV Values > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#other_neighb-tlv > > > > MPR TLV BIT Values > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#mpr-tlv-bit > > > > NBR_ADDR_TYPE Address Block TLV Bit Values > > https://www.iana.org/assignments/manet-parameters/manet- > > parameters.xhtml#nbr_addr_type-address-block-tlv-bit > > > > Best regards, > > IESG Secretary > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e013cb8b0122c7705012dc934 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian,

I have seen some updates of that before month= s. I checked the MANET=C2=A0registries in April=C2=A0and I thought there we= re some amendment needed for the users of our protocols.=C2=A0I did not fin= ish my review of that. However, will send it to the WG as well. I hope we a= re allowed to discuss that here.=C2=A0

On Thursday, August 21, 2014, Adrian Farrel wrote:
Hi,

Just to keep you in the loop...

We had a number of registries for MANET protocols that had "Expert Rev= iew" as their IANA assignment policies, but where no expert had been a= ssigned.

The IESG has done the bit of process magic to appoint experts (the chairs) = and the email below is the kick to IANA to get them to update the registrie= s to show this.

Thanks,
Adrian

> -----Original Message-----
> From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Sec= retary
> Sent: 21 August 2014 19:03
> To: iana@iana.org
> Cc: iesg@ietf.org
> Subject: Appointment of Designated Experts for outstanding MANET regis= tries
>
> IANA,
>
> The IESG has approved Joe Macker <macker@itd.nrl.navy.mil>= ; and Stan
> Ratliff <ratliff@cisco.com> as the designated experts for= the following
> sub-registries:
>
> TC Message-Type-specific Message TLV Types
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#tc-message-type-specific-message
>
> TC Message-Type-specific Address Block TLV Types
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#tc-message-type-specific-address-block
>
> MPR_WILLING Message Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#mpr-willing-message-type-extension
>
> CONT_SEQ_NUM Message Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#cont-seq-num-message-type-extension
>
> HELLO Message-Type-specific Message TLV Types
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#message-tlv-hello
>
> LOCAL_IF Address Block TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#local-if-address-block-tlv-type-extension
>
> LINK_STATUS Address Block TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#link-status-address-block-tlv-type-extension
>
> OTHER_NEIGHB Address Block TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#other-neighb-address-block-tlv-type-extension
>
> LINK_METRIC Address Block TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#link-metric-address-block-tlv-type-extension
>
> MPR Address Block TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#mpr-address-block-tlv-type-extension
>
> NBR_ADDR_TYPE Address Block TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#nbr-addr-type-address-block-tlv-type-extension
>
> GATEWAY Address Block TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#gateway-address-block-tlv-type-extension
>
> HELLO Message-Type-specific Address Block TLV Types (range 128-223) > https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#address-tlv-hello
>
> ICV Packet TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#icv-packet-tlv-types
>
> TIMESTAMP Packet TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#timestamp-packet-tlv-types
>
> ICV Message TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#icv-message-tlv-types
>
> TIMESTAMP Message TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#timestamp-message-tlv-types
>
> ICV Address TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#icv-address-tlv-types
>
> TIMESTAMP Address TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#timestamp-address-tlv-types
>
> Hash Functions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#hash-functions
>
> Cryptographic Functions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#cryptographic-algorithm
>
> SMF_TYPE Message TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#smf-type-extensions
>
> SMF_NBR_TYPE Address Block TLV Type Extensions
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#smf-nbr-types
>
> SMF Relay Algorithm IDs
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#smf-relay-ids
>
> LOCAL_IF TLV Values
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#local_if-tlv
>
> LINK_STATUS TLV Values
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#link_status-tlv
>
> OTHER_NEIGHB TLV Values
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#other_neighb-tlv
>
> MPR TLV BIT Values
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#mpr-tlv-bit
>
> NBR_ADDR_TYPE Address Block TLV Bit Values
> https://www.iana.org/assignments/manet-parameters/manet-
> parameters.xhtml#nbr_addr_type-address-block-tlv-bit
>
> Best regards,
> IESG Secretary

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--089e013cb8b0122c7705012dc934-- From nobody Thu Aug 21 23:52: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 65AC11A00EC for ; Thu, 21 Aug 2014 23:52:24 -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 cFjvZLgXBpbE for ; Thu, 21 Aug 2014 23:52:23 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0485A1A00E8 for ; Thu, 21 Aug 2014 23:52:22 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id j15so9109623qaq.25 for ; Thu, 21 Aug 2014 23:52:22 -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=fji8rnmsiCNzS5xrRd4gJcThMZB/K7V6Sb+xBdUnzCY=; b=AvSMrQDoKrMtOR/EaSamJjsFJa4iBNGMIm0oRP/cxQdIaBE9C3BPTX0MCvVqXnOGkQ LS3nxQl8sa8VrM+L7gNC4PDVVyXAwMAuEV6pmuS0zrYnC7kqSyExzbbnQLV7i4TQpHbQ mrPawa7QPq9xtIL0R1EkpYCSQcrRIHgp/3wpqn3hBx3A/GrYN/OcQGGAIpwfPHb/l90j c1yQmLSaMlPq5VIpfTNYitrQKHrz+Vf7SucVj4UmFlLRhfHe1e62dFCsX+jnRewUx0n2 O0y6D+tolCHS1AhnLG6P35SZA7OfQ6LDDqs9SgCISgMVRaXNpM3YdFUWDY+SToukNC9n cqZg== X-Received: by 10.140.94.100 with SMTP id f91mr4691618qge.41.1408690342204; Thu, 21 Aug 2014 23:52:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.46.68 with HTTP; Thu, 21 Aug 2014 23:52:02 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 22 Aug 2014 08:52:02 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MJzxp2M4f52LDkp-Bn5aKZ9X94M Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-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, 22 Aug 2014 06:52:24 -0000 On Thu, Aug 21, 2014 at 7:24 PM, Dearlove, Christopher (UK) wrote: > 3.1 could (as Henning might well point out) say that while the messages and protocol instantiations are separate, the message could share a packet. Isn't this the same as message aggregation of OLSRv2 and NHDP? Separate protocol instances, but can share a common RFC5444 packet? Of course some protocols (as NHDP) have some mandatory constraints for the packet level (e.g. IP addresses with same address length as in the message), but thats a protocol specific thing. OLSRv2 RFC5444 messages have no constraints on the IP address type of the surrounding packet. Henning Rogge From nobody Fri Aug 22 00:47: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 382D61A010E for ; Fri, 22 Aug 2014 00:47:04 -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 fa8yC4Owt511 for ; Fri, 22 Aug 2014 00:47:02 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22D11A00AD for ; Fri, 22 Aug 2014 00:47:01 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so10016798wgh.26 for ; Fri, 22 Aug 2014 00:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:mime-version:content-type:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fg3bCmFDR56imNzTLcnvxRSu2CMzcmabjdKH51uwowE=; b=yg/RaQocmyJ3RmBsetsDLC27mw7TmIwRz/2+820PxP+HBtQjOQiNn8eXPjbg1p6lMz mPQ9opGgGkoUMlozmlTwEBDXFNh97CuGNRz4Bwe19ZmGgVcrRvpnOlMcvuWbFIDMnXat uQPQrHWMCGHw2aLdFnpkn89+HsQLuEjA3Dmk3qZgEphxPXjqQZhKoW5Muvi6InojCz3T N3X+5ioKIfoDgPXUGlysfWLRiDP4SzUf+3oGt7oebAgTiE7hRw0nLFPJ/m9Kl/Kbor21 uEtBRR/v8VKYQ+Hn6e0g9lmv5VgzmYWW2jc6jU+rsmdaX5CQJKOYAsi3+1Ig5lw5sMwY Tg+g== X-Received: by 10.180.39.73 with SMTP id n9mr9128856wik.70.1408693620465; Fri, 22 Aug 2014 00:47:00 -0700 (PDT) Received: from [192.168.254.4] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id ft7sm28483371wib.9.2014.08.22.00.46.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Aug 2014 00:46:59 -0700 (PDT) From: Christopher Dearlove X-Google-Original-From: Christopher Dearlove Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii In-Reply-To: Date: Fri, 22 Aug 2014 08:46:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <33511460-38DA-43BD-9791-21E5BC11DBA3@mnemosyne.demon.co.uk> References: To: Henning Rogge X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YvD0UnSvNzGZSTbVstatgBcap_8 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-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, 22 Aug 2014 07:47:04 -0000 No, not quite the same. 5444 explicitly discusses separate protocols. It = doesn't explicitly discuss address lengths. The 5444 model assumes that = all HELLO messages are sent to a single entity, regardless of address = type. (It doesn't say regardless of address type, it just doesn't = mention it.) That would be NHDP of course. But the NHDP description is = of a protocol that has a certain type of address. I don't recall if it = explicitly says drop HELLO messages with wrong address length or not. There's nothing actually specified anywhere which describes a process = something like 5444 gets HELLO, sends to NHDP. NHDP looks at address = length and sends to NHDP/IPv4 or NHDP/IPv6 for address lengths 4 or 16 = (and drops HELLO messages with other lengths?). Here NHPD/IPv4 and = NHDP/IPv6 are separate instantiations of 6130. (And ditto for OLSRv2.) = Of course that's a reasonably obvious approach, just not explicitly = specified anywhere,because 5444 can say it's up to the protocol, and the = protocol can say it's really a multiplexing thing. There is an alternative to multiplexing, mapping addresses. That is a = valid alternative model. For example a network a.b.c.0/24 could be = designed assuming everyone knows a.b.c and then uses 1 octet addresses, = saving even on address compression. I'm not sure if that's technically = allowed or not, but it would work (though not, I suspect, in most = implementations if the out of band compression is optional). I'm not suggesting this is a major issue, it's mostly a technicality, = which I think is how I characterised it in text cut from the quote = below. (I don't have my posting to hand here.) And the comment that messages have no constraints on the IP address type = of the surrounding packet is true for 5444. It's not true for NHDP, = which uses the IP datagram source address. That's actually an issue that = a dual stack approach needs to cover. On 22 Aug 2014, at 07:52, Henning Rogge wrote: > On Thu, Aug 21, 2014 at 7:24 PM, Dearlove, Christopher (UK) > wrote: >> 3.1 could (as Henning might well point out) say that while the = messages and protocol instantiations are separate, the message could = share a packet. > Isn't this the same as message aggregation of OLSRv2 and NHDP? > Separate protocol instances, but can share a common RFC5444 packet? Of > course some protocols (as NHDP) have some mandatory constraints for > the packet level (e.g. IP addresses with same address length as in the > message), but thats a protocol specific thing. OLSRv2 RFC5444 messages > have no constraints on the IP address type of the surrounding packet. >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Fri Aug 22 01: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 356F61A0149 for ; Fri, 22 Aug 2014 01:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 DKWiycT7ySZc for ; Fri, 22 Aug 2014 01:05:30 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695A81A0119 for ; Fri, 22 Aug 2014 01:05:30 -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 1XKjqi-0007JD-S4 for manet@ietf.org; Fri, 22 Aug 2014 10:05:28 +0200 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 1XKjqi-0004gy-Oc for manet@ietf.org; Fri, 22 Aug 2014 10:05:28 +0200 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; Fri, 22 Aug 2014 10:05:28 +0200 Message-ID: <53F6F9C1.1080709@fkie.fraunhofer.de> Date: Fri, 22 Aug 2014 10:05:21 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <33511460-38DA-43BD-9791-21E5BC11DBA3@mnemosyne.demon.co.uk> In-Reply-To: <33511460-38DA-43BD-9791-21E5BC11DBA3@mnemosyne.demon.co.uk> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060107030908060502040405" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/19300/Thu Aug 21 21:20:00 2014) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 912e0972ada2ab87c171579937f55793 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rp9Y9ebwkaRhAymBbf_h7hYYe2E Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-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, 22 Aug 2014 08:05:33 -0000 --------------ms060107030908060502040405 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 08/22/2014 09:46 AM, Christopher Dearlove wrote: > No, not quite the same. 5444 explicitly discusses separate protocols. > It doesn't explicitly discuss address lengths. The 5444 model assumes > that all HELLO messages are sent to a single entity, regardless of > address type. (It doesn't say regardless of address type, it just > doesn't mention it.) That would be NHDP of course. But the NHDP > description is of a protocol that has a certain type of address. I > don't recall if it explicitly says drop HELLO messages with wrong > address length or not. http://tools.ietf.org/html/rfc6130#section-12.1 A received HELLO message is invalid for processing by this router if any of the following conditions are true: o The address length as specified in the Message Header is not equal to the length of the addresses used by this router. > There's nothing actually specified anywhere which describes a process > something like 5444 gets HELLO, sends to NHDP. NHDP looks at address > length and sends to NHDP/IPv4 or NHDP/IPv6 for address lengths 4 or > 16 (and drops HELLO messages with other lengths?). Here NHPD/IPv4 and > NHDP/IPv6 are separate instantiations of 6130. (And ditto for > OLSRv2.) Of course that's a reasonably obvious approach, just not > explicitly specified anywhere,because 5444 can say it's up to the > protocol, and the protocol can say it's really a multiplexing thing. You could argue that if you want to do a dualstack thing, you just need a second level of multiplexer. > And the comment that messages have no constraints on the IP address > type of the surrounding packet is true for 5444. It's not true for > NHDP, which uses the IP datagram source address. That's actually an > issue that a dual stack approach needs to cover. My draft already covers this, it only allows messages with a hop-limit larger than one to be put into a UDP/RFC-5444 packet with a different address length. 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 --------------ms060107030908060502040405 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 Fw0xNDA4MjIwODA1MjdaMCMGCSqGSIb3DQEJBDEWBBSJtH3PXOFFqZffE5HGEPy/30vMkDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAeUbV6h3MZjBtRAuMr3bAHhgKhnZZzDOXq3x8Sa58cXle 0mTEwZCZAlMLy0V5HMJB5wC/qnavLZcJr1K7saQEUAFKENWRGbdwM05JhwPs3+AcXj9Xb3Dy OjUieiognYkNk4bhY8Y0DqYi6oly5QFyfQiOW/8OlxY64aLLyQRXHJVSDtDaWDaiqWnBi9iQ meiZxVcV+uoZ60POye/oBBTefyFXNCN0dqGQlzelwtAlrcASdU8yB8L8WuDxUHSKMLqJGBG0 mBM/ek/JfcRfoVroVmUIcvDVnsKxO0S5/bViwKjIrCPAzH+5iM3/t6kJIOHJ59QmnoZUKZej JZ2qYvbWJAAAAAAAAA== --------------ms060107030908060502040405-- From nobody Fri Aug 22 02:15: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 DEBEF1A01A9 for ; Fri, 22 Aug 2014 02:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 UlgTwj9Hy8dT for ; Fri, 22 Aug 2014 02:14:57 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F841A0195 for ; Fri, 22 Aug 2014 02:14:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,378,1406588400"; d="scan'208";a="397618318" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Aug 2014 10:14:55 +0100 X-IronPort-AV: E=Sophos;i="5.04,378,1406588400"; d="scan'208";a="70372564" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 22 Aug 2014 10:14:36 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Fri, 22 Aug 2014 10:14:36 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: Dual stack operations (was RE: [manet] draft-ietf-manet-olsrv2-management-snapshot-02) Thread-Index: Ac+96JYiwWthqXxJSkeAbUk408QDdQ== Date: Fri, 22 Aug 2014 09:14:36 +0000 Message-ID: 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/WlqXCtFynq3tNJ9O4M69QZ8PsKw Subject: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-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, 22 Aug 2014 09:15:00 -0000 (Changed subject line. As far as management draft is concerned this is one = of those possible futures.) I need to read your draft. I don't understand from your comment the relevan= ce of the hop limit greater than one or how it addresses the issue. I think we are both agreed that a second level of multiplexing is implicit.= Should it be explicit? Also suppose we have IPv4 and IPv6 versions of NHDP and OLSRv2. We can demu= ltiplex 4 and 16 byte addressed HELLO and TC messages appropriately. What s= hould we do with a, say, 2 byte address? Should address expansion to one or= the other be allowed? (the quote you give - thanks - disallows this). And, as I didn't fully say, NHDP may use the IP source address to avoid hav= ing to include a sending interface address (otherwise using LOCAL_IF). That= needs covering if the HELLO address length and IP address length don't mat= ch. That can be done by not doing that. What I didn't say at all is that OL= SRv2 uses the sending address to know whether to forward the message. That = can't be handled by not doing that, and needs a solution. -- = Christopher Dearlove Senior Principal Engineer, Information Assurance 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 Henning Rogge Sent: 22 August 2014 09:05 To: manet@ietf.org Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-02 On 08/22/2014 09:46 AM, Christopher Dearlove wrote: > No, not quite the same. 5444 explicitly discusses separate protocols. > It doesn't explicitly discuss address lengths. The 5444 model assumes = > that all HELLO messages are sent to a single entity, regardless of = > address type. (It doesn't say regardless of address type, it just = > doesn't mention it.) That would be NHDP of course. But the NHDP = > description is of a protocol that has a certain type of address. I = > don't recall if it explicitly says drop HELLO messages with wrong = > address length or not. http://tools.ietf.org/html/rfc6130#section-12.1 A received HELLO message is invalid for processing by this router if any of= the following conditions are true: o The address length as specified in the Message Header is not equal to the length of the addresses used by this router. > There's nothing actually specified anywhere which describes a process = > something like 5444 gets HELLO, sends to NHDP. NHDP looks at address = > length and sends to NHDP/IPv4 or NHDP/IPv6 for address lengths 4 or > 16 (and drops HELLO messages with other lengths?). Here NHPD/IPv4 and > NHDP/IPv6 are separate instantiations of 6130. (And ditto for > OLSRv2.) Of course that's a reasonably obvious approach, just not = > explicitly specified anywhere,because 5444 can say it's up to the = > protocol, and the protocol can say it's really a multiplexing thing. You could argue that if you want to do a dualstack thing, you just need a s= econd level of multiplexer. > And the comment that messages have no constraints on the IP address = > type of the surrounding packet is true for 5444. It's not true for = > NHDP, which uses the IP datagram source address. That's actually an = > issue that a dual stack approach needs to cover. My draft already covers this, it only allows messages with a hop-limit larg= er than one to be put into a UDP/RFC-5444 packet with a different address l= ength. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation= , Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) F= raunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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 Aug 22 02:24: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 CFB2E1A01AE for ; Fri, 22 Aug 2014 02:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 PB_EOG6-yeTo for ; Fri, 22 Aug 2014 02:24:47 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0C11A01A9 for ; Fri, 22 Aug 2014 02:24:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,378,1406588400"; d="scan'208";a="470486063" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Aug 2014 10:24:45 +0100 X-IronPort-AV: E=Sophos;i="5.04,378,1406588400"; d="scan'208";a="62771244" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 22 Aug 2014 10:24:44 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0174.001; Fri, 22 Aug 2014 10:24:44 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , manet Thread-Topic: [manet] MANET Parameters Review (Related to IANA sections of RFC7181 - RFC7188) Thread-Index: AQHPvagimzBW0SNLckWxaDjrbCrHbpvcV7jg Date: Fri, 22 Aug 2014 09:24:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/p_fGxrKkcIm8gNLjvE6Vi9mQOfo Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" Subject: Re: [manet] MANET Parameters Review (Related to IANA sections of RFC7181 - RFC7188) 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, 22 Aug 2014 09:24:49 -0000 WW914oCZZCBmaW5kIHBlb3BsZSBtb3JlIHJlY2VwdGl2ZSBpZiB5b3Ugd29yZGVkIHRoaW5ncyBh cyBzdWdnZXN0aW9ucyByYXRoZXIgdGhhbiBpbnN0cnVjdGlvbnMgKHdoaWNoIHlvdSBjYW7igJl0 IGdpdmUpLiBBbmQgaXTigJlzIHJlZ2lzdHJ5Lg0KDQpCdXQgcHV0dGluZyB0aGF0IG9uIG9uZSBz aWRlLCBsZXTigJlzIGNvbnNpZGVyIHlvdXIgZmlyc3QsIHdoZXJlIHlvdSBzdWdnZXN0IGNoYW5n aW5nICJUQyBNZXNzYWdlLVR5cGUtc3BlY2lmaWMgTWVzc2FnZSBUTFYgVHlwZXMiIHRvICJNZXNz YWdlLVR5cGUtU3BlY2lmaWMgTWVzc2FnZSBUTFYgVHlwZXMgZm9yIHRoZSBUQyBNZXNzYWdlIFR5 cGUiIChJ4oCZbSBnb2luZyB0byBpZ25vcmUgdGhlIG11Y2ggbGVzcyB1c2VmdWwgdHlwZSAxKS4N Cg0KV2h5IFR5cGUtc3BlY2lmaWMgcmF0aGVyIHRoYW4gVHlwZS1TcGVjaWZpYz8gQmVjYXVzZSB0 aGF0IG1hdGNoZXMgdGhlIHNvdXJjZSBkb2N1bWVudCBjYXNlIHVzYWdlLiBXaGljaCwgaWYgSSBy ZW1lbWJlciBjb3JyZWN0bHksIHdhcyB0aGUgUkZDIEVkaXRvciAod2hvIHdhbnRlZCB0byBjaGFu Z2UgYSBsb3Qgb2YgdGhlIGF1dGhvcnMnIHVzYWdlKS4gQnV0IG5vdCBpbXBvcnRhbnQgZWl0aGVy IHdheS4NCg0KVGhlIG90aGVyIHN1Z2dlc3RlZCBjaGFuZ2UsIGZyb20gYW4gaW5pdGlhbCAiVEMg TWVzc2FnZSIgdG8gYSBmaW5hbCAiZm9yIHRoZSBUQyBNZXNzYWdlIFR5cGUiPyBCb3RoIHNheSB0 aGUgc2FtZSB0aGluZy4gU29tZSBtYXkgcHJlZmVyIG9uZSwgc29tZSBtYXkgcHJlZmVyIHRoZSBv dGhlci4gTXkgcHJlZmVyZW5jZSBpcyBmb3Igbm90IG1ha2luZyBJQU5BIGRvIHRoaW5ncyB3aXRo IGxpdHRsZSBvciBubyB2YWx1ZS4NCg0KKFVudGlsIHlvdSd2ZSBhY3R1YWxseSBkZWFsdCB3aXRo IG1ha2luZyByZWdpc3RyeSBjaGFuZ2VzIHRocm91Z2ggSUFOQSwgeW91IG1heSBub3QgcmVhbGlz ZSBpdCdzIGEgbm9uLXRyaXZpYWwgcHJvY2VzcyBmb3IgYWxsIGNvbmNlcm5lZC4pDQoNCkhvd2V2 ZXIgeW91ciBsYXN0IGZvdXIgcG9pbnRzIGFwcGVhciAoSSBoYXZlbid0IGNoZWNrZWQgdGhlIHJl Z2lzdHJ5IGRpcmVjdGx5KSB0byBiZSBjb3JyZWN0LiBCdXQgd2UgbWF5IChnaXZlbiBzb21lIHJl Y2VudCBjb21tZW50cyBieSBBZHJpYW4pIGhhdmUgdG8gYWRkcmVzcyBhIHNlcGFyYXRlIG5hbWlu ZyBpc3N1ZSBoZXJlLCBhbmQgaXQgd291bGQgdGhlcmVmb3JlIHByb2JhYmx5IGJlIHNlbnNpYmxl IHRvIGhvbGQgdGhpcyB1bnRpbCB0aGVuLg0KDQotLSANCkNocmlzdG9waGVyIERlYXJsb3ZlDQpT ZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXANCkNv bW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KQkFF IFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3QgSGFubmluZ2ZpZWxkIFJv YWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNClRlbDogKzQ0IDEyNDUg MjQyMTk0wqB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVt cy5jb20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRp b25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3 LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQg NllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KRnJv bTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWJk dXNzYWxhbSBCYXJ5dW4NClNlbnQ6IDIyIEF1Z3VzdCAyMDE0IDAyOjI3DQpUbzogbWFuZXQNCkNj OiBtYW5ldC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1hbmV0LWFkc0B0b29scy5pZXRmLm9yZw0K U3ViamVjdDogW21hbmV0XSBNQU5FVCBQYXJhbWV0ZXJzIFJldmlldyAoUmVsYXRlZCB0byBJQU5B IHNlY3Rpb25zIG9mIFJGQzcxODEgLSBSRkM3MTg4KQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhp cyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhl ciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2Fy ZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0 dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3Mg dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhl cmUuDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0 aGlzIHByb2Nlc3MuDQpSZXZpZXdlcjogQWJkdXNzYWxhbSBCYXJ5dW4gKEFCKQ0KRGF0ZWQ6IDI1 LjA0LjIwMTQgKG5vdCBjb21wbGV0ZWQpDQrCoA0KVGhpcyBpcyBBQiByZXZpZXcgb2YgdGhlIE1B TkVUIHBhcmFtZXRlcnPCoGRvY3VtZW50cyBbMV1bMl0gdGhhdCB3ZXJlIHVwZGF0ZWQgb24gMTQu MDQuMjAxNCBpbiByZWxhdGlvbiBvZsKgdGhlIG5ldyBSRkNzIFs3MTgxLTcxODhdLiBIb3dldmVy LCBub3QgY29tcGxldGVkIGZvciBmdXR1cmUgcmV2aWV3LCBidXQgaXQgbWF5IGhlbHAuwqANCsKg DQrCoA0KWzFdIGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL21hbmV0LXBhcmFtZXRl cnMvbWFuZXQtcGFyYW1ldGVycy50eHQNClsyXcKgZnRwOi8vZnRwLmlldGYub3JnL2lhbmEvbWFu ZXQtcGFyYW1ldGVycy9tYW5ldC1wYXJhbWV0ZXJzLnR4dA0KwqANCkNvbW1lbnRzIGJlbG93IGFz IFtBQl06DQrCoA0KKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCsKg DQpNb2JpbGUgQWQgaG9jIE5FVHdvcmsgKE1BTkVUKSBQYXJhbWV0ZXJzDQoNCsKgwqAgQ3JlYXRl ZA0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgMjAwOC0xMi0yMw0KDQrCoMKgIExhc3QgVXBkYXRlZA0K wqDCoMKgwqDCoMKgwqDCoMKgwqAgMjAxNC0wNC0xNA0KDQrCoMKgIEF2YWlsYWJsZSBGb3JtYXRz DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBbSU1HXQ0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgWE1MIFtJ TUddDQrCoMKgwqDCoMKgwqDCoMKgwqDCoCBIVE1MIFtJTUddDQrCoMKgwqDCoMKgwqDCoMKgwqDC oCBQbGFpbiB0ZXh0DQpDcmVhdGVkDQrCoMKgwqDCoMKgwqDCoMKgwqDCoCAyMDA4LTEyLTIzDQoN CsKgwqAgTGFzdCBVcGRhdGVkDQrCoMKgwqDCoMKgwqDCoMKgwqDCoCAyMDE0LTA0LTE0DQoNCsKg wqAgQXZhaWxhYmxlIEZvcm1hdHMNCsKgwqDCoMKgwqDCoMKgwqDCoMKgIFtJTUddDQrCoMKgwqDC oMKgwqDCoMKgwqDCoCBYTUwgW0lNR10NCsKgwqDCoMKgwqDCoMKgwqDCoMKgIEhUTUwgW0lNR10N CsKgwqDCoMKgwqDCoMKgwqDCoMKgIFBsYWluIHRleHQNCg0KwqDCoCBSZWdpc3RyaWVzIGluY2x1 ZGVkIGJlbG93DQoNCsKgwqDCoMKgICogTWVzc2FnZSBUeXBlcw0KDQrCoMKgwqDCoCAqIFRDIE1l c3NhZ2UtVHlwZS1zcGVjaWZpYyBNZXNzYWdlIFRMViBUeXBlcw0KwqANCltBQl3CoHBsZWFzZSBh bWVuZCByZWdpc3RlcnkgdG86IE1lc3NhZ2UtVHlwZS1TcGVjaWZpYyBNZXNzYWdlIFRMViBUeXBl cyBmb3IgdGhlIFRDIE1lc3NhZ2UgVHlwZS4NCltBQl3CoG9ywqBhbWVuZCByZWdpc3RlcnkgdG86 IE1lc3NhZ2UtVHlwZS1TcGVjaWZpYyBNZXNzYWdlIFRMViBUeXBlcyBmb3IgTWVzc2FnZSBUeXBl IDEuDQoNCsKgwqDCoMKgICogVEMgTWVzc2FnZS1UeXBlLXNwZWNpZmljIEFkZHJlc3MgQmxvY2sg VExWIFR5cGVzDQrCoA0KW0FCXcKgcGxlYXNlIGFtZW5kIHJlZ2lzdGVyeSB0bzogTWVzc2FnZS1U eXBlLVNwZWNpZmljwqBBZGRyZXNzIEJsb2NrIFRMViBUeXBlcyBmb3IgdGhlIFRDIE1lc3NhZ2Ug VHlwZS4NCltBQl3CoG9yIGFtZW5kIHJlZ2lzdGVyeSB0bzogTWVzc2FnZS1UeXBlLVNwZWNpZmlj wqBBZGRyZXNzIEJsb2NrIFRMViBUeXBlcyBmb3IgTWVzc2FnZSBUeXBlIDEuDQrCoA0KwqDCoMKg wqAgKiBQYWNrZXQgVExWIFR5cGVzDQrCoMKgwqDCoCAqIE1lc3NhZ2UgVExWIFR5cGVzDQoNCsKg wqDCoMKgICogSU5URVJWQUxfVElNRSBNZXNzYWdlIFR5cGUgRXh0ZW5zaW9ucw0KwqANCltBQl0g SU5URVJWQUxfVElNRSBpcyBhIG1lc3NhZ2UgVExWIFR5cGUsIHBsZWFzZSBhbWVuZCBmcm9tIG1l c3NhZ2UgVHlwZSB0byBtZXNzYWdlIFRMViBUeXBlDQoNCsKgwqDCoMKgICogVkFMSURJVFlfVElN RSBNZXNzYWdlIFR5cGUgRXh0ZW5zaW9ucw0KwqANCltBQl0gVkFMSURJVFlfVElNRSBpcyBhIG1l c3NhZ2UgVExWIFR5cGUsIHBsZWFzZSBhbWVuZCBmcm9tIG1lc3NhZ2UgVHlwZSB0byBtZXNzYWdl IFRMViBUeXBlLg0KDQrCoMKgwqDCoCAqIE1QUl9XSUxMSU5HIE1lc3NhZ2UgVHlwZSBFeHRlbnNp b25zDQrCoA0KW0FCXSBNUFJfV0lMTElORyBpcyBhIG1lc3NhZ2UgVExWIFR5cGUsIHBsZWFzZSBh bWVuZCBmcm9tIG1lc3NhZ2UgVHlwZSB0byBtZXNzYWdlIFRMViBUeXBlLg0KDQrCoMKgwqDCoCAq IENPTlRfU0VRX05VTSBNZXNzYWdlIFR5cGUgRXh0ZW5zaW9ucw0KwqANCltBQl0gQ09OVF9TRVFf TlVNIGlzIGEgbWVzc2FnZSBUTFYgVHlwZSwgcGxlYXNlIGFtZW5kIGZyb20gbWVzc2FnZSBUeXBl IHRvIG1lc3NhZ2UgVExWIFR5cGUuDQoNCi0tLS0tLS0tLS0tLS0NCg0KSSB0aGluayB0aGUgV0cg c2hvdWxkIHJldmlldyB0aGUgcGFyYW1ldGVycy9yZWdpc3RyaWVzLsKgDQoNCkFCIA0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8g dGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91 ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9y IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== From nobody Fri Aug 22 02:29: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 45AC61A01C3 for ; Fri, 22 Aug 2014 02:29:41 -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 zLSkrRkGD47N for ; Fri, 22 Aug 2014 02:29:39 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382701A01B0 for ; Fri, 22 Aug 2014 02:29:38 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id x13so10484916qcv.40 for ; Fri, 22 Aug 2014 02:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=X552ic/a9Z8FjG0keq7hyaXl4ThJOE3Ss72BLVM+xV4=; b=rOoK2QmgWz6oAnx3uvsApEDt1Q44Ywgyr1/KiGS5v2XH7TG71MCgmZEVyjtdS3teze PmopX/dX2fXHkAP5o25RmQmRCsvAXzmxQrwUMS8+KAda2u5MEsI3hC3nildgmjFaS8Ou bOQ1hjYIsTx8L3zr3TNzWxE+Y529NuPhN5JXFTokw7rx/ggHcoJ50moPuBBcYqXbysjc wKzKyMskTeyIh3RaKd8kYN9PGE3VotdfZmrwWf8s2hh+rL7MoEukL0JFQRf3M9N3/KTQ W6OzfyqQXIEWiX/wCx9eRSzzLtUoE/V42WPqVw4Dku4aUAOZAUfxqM03nvJg/W81LUwH Rmrw== X-Received: by 10.224.66.7 with SMTP id l7mr6228850qai.46.1408699778224; Fri, 22 Aug 2014 02:29:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.46.68 with HTTP; Fri, 22 Aug 2014 02:29:18 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 22 Aug 2014 11:29:18 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/oDz13krmo3hnvQWqYSlD-pKzQ40 Cc: "manet@ietf.org" Subject: Re: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-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, 22 Aug 2014 09:29:41 -0000 On Fri, Aug 22, 2014 at 11:14 AM, Dearlove, Christopher (UK) wrote: > (Changed subject line. As far as management draft is concerned this is on= e of those possible futures.) > > I need to read your draft. I don't understand from your comment the relev= ance of the hop limit greater than one or how it addresses the issue. I think yes, because everything with hoplimit>1 will be forwarded by other nodes, which changes the src-ip address. > I think we are both agreed that a second level of multiplexing is implici= t. Should it be explicit? Phh... good question. I don't know. Some implementation might just combine both multiplexing decisions, some might just have a protocol that understands two different kind of address types (or more). > Also suppose we have IPv4 and IPv6 versions of NHDP and OLSRv2. We can de= multiplex 4 and 16 byte addressed HELLO and TC messages appropriately. What= should we do with a, say, 2 byte address? Should address expansion to one = or the other be allowed? (the quote you give - thanks - disallows this). I do the same a "single address family" implementation is doing. When I get a message with an address length I don't support (in the case of my dualstack implementation, 4 and 16) I drop the address. > And, as I didn't fully say, NHDP may use the IP source address to avoid h= aving to include a sending interface address (otherwise using LOCAL_IF). Th= at needs covering if the HELLO address length and IP address length don't m= atch. That can be done by not doing that. What I didn't say at all is that = OLSRv2 uses the sending address to know whether to forward the message. Tha= t can't be handled by not doing that, and needs a solution. The forwarding can be done based on the MPR set fitting the the IP address of the incoming packet, the duplicate detection will be then done by using the Duplicate Set with the address length of the message. Example: *********** you get a IPv4 OLSRv2 message inside an IPv6 UDP packet (with an RFC5444 packet header inside). You first check the IPv6 flooding MPR set if you should forward the message at all (based on the IPv6 NHDP Hello messages). If yes, you check in the IPv4 duplicate set if you already have forwarded the message, based on the message header fields of the RFC5444 message with address length 4. (I have to remember to put this explanation into the next revision of the dualstack draft) Henning Rogge From nobody Fri Aug 22 04:32: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 997EC1A01D2 for ; Fri, 22 Aug 2014 04:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 uMb3DIubQI30 for ; Fri, 22 Aug 2014 04:32:49 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F2A1A011F for ; Fri, 22 Aug 2014 04:32:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,379,1406588400"; d="scan'208";a="470541099" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 22 Aug 2014 12:32:47 +0100 X-IronPort-AV: E=Sophos;i="5.04,379,1406588400"; d="scan'208";a="62793561" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 22 Aug 2014 12:32:47 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Fri, 22 Aug 2014 12:32:47 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-02) Thread-Index: AQHPveugYegT9JQhI0+QeBRa126rLZvcfDJg Date: Fri, 22 Aug 2014 11:32:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tGClcRX1zW3MZB4Qf13ixONX99Q Cc: "manet@ietf.org" Subject: Re: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-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, 22 Aug 2014 11:32:52 -0000 Aha, when you refer to hop limit, you mean IP hop limit. I think that's red= undant, we already say that. Use of the IPv6 process's information to decide whether to flood an IPv4 me= ssage (or vice versa) strikes me as dodgy at best. It assumes that everythi= ng is the same in the IPv4 and IPv6 worlds: same set of routers, same links= and their status etc. I think this needs more consideration. (Terminologically, we don't have an MPR Set - now flags in the Neighbor Set= - or Duplicate Set - divided in three. Doesn't matter here, matters when w= riting drafts.) -- = Christopher Dearlove Senior Principal Engineer, Information Assurance 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 Henning Rogge Sent: 22 August 2014 10:29 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2= -management-snapshot-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. -------------------------------------------------------- On Fri, Aug 22, 2014 at 11:14 AM, Dearlove, Christopher (UK) wrote: > (Changed subject line. As far as management draft is concerned this is = > one of those possible futures.) > > I need to read your draft. I don't understand from your comment the relev= ance of the hop limit greater than one or how it addresses the issue. I think yes, because everything with hoplimit>1 will be forwarded by other = nodes, which changes the src-ip address. > I think we are both agreed that a second level of multiplexing is implici= t. Should it be explicit? Phh... good question. I don't know. Some implementation might just combine = both multiplexing decisions, some might just have a protocol that understan= ds two different kind of address types (or more). > Also suppose we have IPv4 and IPv6 versions of NHDP and OLSRv2. We can de= multiplex 4 and 16 byte addressed HELLO and TC messages appropriately. What= should we do with a, say, 2 byte address? Should address expansion to one = or the other be allowed? (the quote you give - thanks - disallows this). I do the same a "single address family" implementation is doing. When I get= a message with an address length I don't support (in the case of my dualst= ack implementation, 4 and 16) I drop the address. > And, as I didn't fully say, NHDP may use the IP source address to avoid h= aving to include a sending interface address (otherwise using LOCAL_IF). Th= at needs covering if the HELLO address length and IP address length don't m= atch. That can be done by not doing that. What I didn't say at all is that = OLSRv2 uses the sending address to know whether to forward the message. Tha= t can't be handled by not doing that, and needs a solution. The forwarding can be done based on the MPR set fitting the the IP address = of the incoming packet, the duplicate detection will be then done by using = the Duplicate Set with the address length of the message. Example: *********** you get a IPv4 OLSRv2 message inside an IPv6 UDP packet (with an RFC5444 packet header inside). You first check the IPv6 flooding MPR set if you should forward the message= at all (based on the IPv6 NHDP Hello messages). If yes, you check in the I= Pv4 duplicate set if you already have forwarded the message, based on the m= essage header fields of the RFC5444 message with address length 4. (I have to remember to put this explanation into the next revision of the d= ualstack draft) Henning Rogge _______________________________________________ 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 Fri Aug 22 05:18: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 B905B1A02A2 for ; Fri, 22 Aug 2014 05:18:00 -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 W0rVOeWtK5KH for ; Fri, 22 Aug 2014 05:17:58 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9388E1A0262 for ; Fri, 22 Aug 2014 05:17:58 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x3so10673966qcv.37 for ; Fri, 22 Aug 2014 05:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=1NNBh801E0zK5pkqgrP1vNsQEqcgxg0pcObWZ5hgISw=; b=v6exrbKxwRlfnV1I6BzT5TpBX/Y09jOR0715MtHs5hPDA3B3C+v3I3IS9D4ekKy+i5 6RZu+eP44pIowe7U59WJ2pF3X30KOPfzyFvCj1QyF1sNaPlztVrGiGRDknhZQ9U6lD3D w/LV3MlPzYlUXwCu0OgQbYH+o3UgTKaZUMsNPkZD7rtq856wvknEkyls/jB2gZjJJ3bq jMScThv3GjJzViE06Um5FoEWZslWEsUQ6ubdlwlqQWFNNZMCPeY7UAqHidTWsB5UJBer Q9qK+8iquZR7lakmricH8UhPtSfAOyOYDervsmuikv79pal7YYYDVjb6RU9yhAWXqgjS ZpyA== X-Received: by 10.229.38.3 with SMTP id z3mr7248237qcd.17.1408709877876; Fri, 22 Aug 2014 05:17:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.46.68 with HTTP; Fri, 22 Aug 2014 05:17:37 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 22 Aug 2014 14:17:37 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JQPCVvPq1tNSPqiFIh0npBeHL10 Cc: "manet@ietf.org" Subject: Re: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-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, 22 Aug 2014 12:18:01 -0000 On Fri, Aug 22, 2014 at 1:32 PM, Dearlove, Christopher (UK) wrote: > Aha, when you refer to hop limit, you mean IP hop limit. I think that's r= edundant, we already say that. No, I am talking about the RFC5444 message header field "Hop Limit". > Use of the IPv6 process's information to decide whether to flood an IPv4 = message (or vice versa) strikes me as dodgy at best. It assumes that everyt= hing is the same in the IPv4 and IPv6 worlds: same set of routers, same lin= ks and their status etc. I think this needs more consideration. You only use the IPv6 MPRs for an IPv4 (RFC5444) message if you don't have neighbors that are "IPv4 only". That's in the rules in chapter 7.5 of my draft. Henning Rogge From nobody Fri Aug 22 07:17: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 D9D0E1A0430 for ; Fri, 22 Aug 2014 07:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 fDdEypyKzD-h for ; Fri, 22 Aug 2014 07:17:44 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC3E1A0428 for ; Fri, 22 Aug 2014 07:17:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,381,1406588400"; d="scan'208";a="397722940" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Aug 2014 15:17:42 +0100 X-IronPort-AV: E=Sophos;i="5.04,381,1406588400"; d="scan'208";a="70422678" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 22 Aug 2014 15:17:42 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Fri, 22 Aug 2014 15:17:42 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-02) Thread-Index: AQHPveugYegT9JQhI0+QeBRa126rLZvcfDJg///9UoCAADAxgA== Date: Fri, 22 Aug 2014 14:17:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/EUHxoHXb_LjaerzRXIiF7InGuig Cc: "manet@ietf.org" Subject: Re: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-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, 22 Aug 2014 14:17:47 -0000 T0ssIHdpdGggcmVnYXJkIHRvIGhvcCBsaW1pdCwgSSdtIGJhY2sgd2l0aCBpdC4NCg0KPiBNeSBk cmFmdCBhbHJlYWR5IGNvdmVycyB0aGlzLCBpdCBvbmx5IGFsbG93cyBtZXNzYWdlcyB3aXRoIGEg aG9wLWxpbWl0IGxhcmdlciB0aGFuIG9uZSB0byBiZSBwdXQgaW50byBhIFVEUC9SRkMtNTQ0NCBw YWNrZXQgd2l0aCBhIGRpZmZlcmVudCBhZGRyZXNzIGxlbmd0aC4NCg0KT3IgaW4gb3RoZXIgd29y ZHMsIHlvdSBjYW4ndCBwdXQgSEVMTE8gbWVzc2FnZXMgaW4gYW4gSVAgZGF0YWdyYW0gKHRoYXQn cyB0aGUgbGV2ZWwgdGhhdCBtYXR0ZXJzKSBmb3IgYW5vdGhlciBzaXplIGxpbWl0LiBCdXQgeW91 IGNhbiBwdXQgKGV2ZXJ5IHJlYWwpIFRDIG1lc3NhZ2VzIHRoZXJlLg0KVGhhdCdzIHVubmVjZXNz YXJpbHkgcmVzdHJpY3RpbmcsIGF0IGxlYXN0IGluIHByaW5jaXBsZSwgYXMgSEVMTE8gbWVzc2Fn ZXMgZG9uJ3QgaGF2ZSB0byB1c2UgdGhlIElQIHNvdXJjZSBhZGRyZXNzLiBJdCB3b3VsZCBiZSBw b3NzaWJsZSB0byBzYXkgaW4gdGhhdCBjYXNlIHRoZXJlJ3MgYW4gZXJyb3IuIE9mIGNvdXJzZSB0 aGF0IHdvdWxkIGV4dGVuZCA2MTMwLCB3aGljaCB3b3VsZCBiZSBhbiBpc3N1ZSBpbiBzb21ldGhp bmcgZXhwZXJpbWVudGFsLg0KDQpJIG5lZWQgdG8gcmVhZCB5b3VyIGRyYWZ0LiBCdXQgSSdkIHdh bnQgdG8gc2VlIGEgcHJvb2YgdGhhdCBtZXNzYWdlcyBhbHdheXMgZ2V0IHdoZXJlIHRoZXkgbmVl ZCB0byBnby4gV2hhdCBpZiB5b3UgaGF2ZSAyLWhvcCBuZWlnaGJvdXJzIHRoYXQgYXJlIElQdjQg b25seT8gV2lsbCB0aGUgSVB2NiBNUFJzIGNvdmVyIHRoZW0/IEFuZCBJJ20gc3RpbGwgZG91YnRm dWwgYWJvdXQgZGlmZmVyZW50IElQdjQvdjYgbGluayBzdGF0ZXMgYW5kIGludGVyYWN0aW9uIHdp dGggTVBSIHNlbGVjdGlvbi4gV2hhdCBpZiB5b3UgdXNlIGxpbmsgbWV0cmljcyBpbiBmbG9vZGlu ZyBNUFIgc2VsZWN0aW9uIChhbiBhbGxvd2VkIG9wdGlvbik/DQoNCi0tIA0KQ2hyaXN0b3BoZXIg RGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIEluZm9ybWF0aW9uIEFzc3VyYW5j ZSBHcm91cA0KQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBh YmlsaXR5DQpCQUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5u aW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVs OiArNDQgMTI0NSAyNDIxOTTCoHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbSB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3Rl bXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNl LCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBI YW50cywgR1UxNCA2WVUsIFVLDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5 NjY4Nw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIZW5uaW5nIFJvZ2dl IFttYWlsdG86aHJvZ2dlQGdtYWlsLmNvbV0gDQpTZW50OiAyMiBBdWd1c3QgMjAxNCAxMzoxOA0K VG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbbWFuZXRdIER1YWwgc3RhY2sgb3BlcmF0aW9ucyAod2FzIFJFOiBkcmFmdC1pZXRm LW1hbmV0LW9sc3J2Mi1tYW5hZ2VtZW50LXNuYXBzaG90LTAyKQ0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3Jp Z2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0 ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3 aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50 cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBv biBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1h aWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpPbiBGcmksIEF1ZyAyMiwgMjAxNCBhdCAxOjMyIFBNLCBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+IHdyb3Rl Og0KPiBBaGEsIHdoZW4geW91IHJlZmVyIHRvIGhvcCBsaW1pdCwgeW91IG1lYW4gSVAgaG9wIGxp bWl0LiBJIHRoaW5rIHRoYXQncyByZWR1bmRhbnQsIHdlIGFscmVhZHkgc2F5IHRoYXQuDQoNCk5v LCBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIFJGQzU0NDQgbWVzc2FnZSBoZWFkZXIgZmllbGQgIkhv cCBMaW1pdCIuDQoNCj4gVXNlIG9mIHRoZSBJUHY2IHByb2Nlc3MncyBpbmZvcm1hdGlvbiB0byBk ZWNpZGUgd2hldGhlciB0byBmbG9vZCBhbiBJUHY0IG1lc3NhZ2UgKG9yIHZpY2UgdmVyc2EpIHN0 cmlrZXMgbWUgYXMgZG9kZ3kgYXQgYmVzdC4gSXQgYXNzdW1lcyB0aGF0IGV2ZXJ5dGhpbmcgaXMg dGhlIHNhbWUgaW4gdGhlIElQdjQgYW5kIElQdjYgd29ybGRzOiBzYW1lIHNldCBvZiByb3V0ZXJz LCBzYW1lIGxpbmtzIGFuZCB0aGVpciBzdGF0dXMgZXRjLiBJIHRoaW5rIHRoaXMgbmVlZHMgbW9y ZSBjb25zaWRlcmF0aW9uLg0KDQpZb3Ugb25seSB1c2UgdGhlIElQdjYgTVBScyBmb3IgYW4gSVB2 NCAoUkZDNTQ0NCkgbWVzc2FnZSBpZiB5b3UgZG9uJ3QgaGF2ZSBuZWlnaGJvcnMgdGhhdCBhcmUg IklQdjQgb25seSIuIFRoYXQncyBpbiB0aGUgcnVsZXMgaW4gY2hhcHRlcg0KNy41IG9mIG15IGRy YWZ0Lg0KDQpIZW5uaW5nIFJvZ2dlDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBp ZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5k ZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3Ig ZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioK From nobody Fri Aug 22 16:43: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 909861A7007 for ; Fri, 22 Aug 2014 16:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 r0l4SWQVWIux for ; Fri, 22 Aug 2014 16:42:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DBF1A6FFF; Fri, 22 Aug 2014 16:42:55 -0700 (PDT) Received: from localhost ([::1]:45910 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XKyTs-0007zz-4E; Fri, 22 Aug 2014 16:42:52 -0700 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: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org, abdussalambaryun@gmail.com X-Trac-Project: manet Date: Fri, 22 Aug 2014 23:42:52 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/manet/trac/ticket/53 Message-ID: <066.e623060914b6e950c057f764be31e6ae@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org, abdussalambaryun@gmail.com, Manet@ietf.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: chris.dearlove@baesystems.com, t.clausen@computer.org Archived-At: http://mailarchive.ietf.org/arch/msg/manet/DmkSmUEIoah8Nm3boTICyQ3d01o Cc: Manet@ietf.org Subject: [manet] #53 (olsrv2-multitopology): MT terminology 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: Fri, 22 Aug 2014 23:42:59 -0000 #53: MT terminology The draft must define MT routers, and non-MT routers. The draft must define MT-OLSRv2 router and non-MT-OLSRv2 router. If we mention non it can mean non-OLSRv2 router, so not defining non-MT-OLSRv2 is confusing. Another Suggest to amend non-MT-OLSRv2 to non-MT router because the document is already for one routing protocol which is OLSRv2. Otherwise, the terms non-MT-OLSRv2 must be defined. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-manet- abdussalambaryun@gmail.com | olsrv2-multitopology@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: olsrv2-multitopology | Version: Severity: Waiting for Shepherd | Keywords: Writeup | -------------------------------------+------------------------------------- Ticket URL: manet From nobody Fri Aug 22 16:50:30 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 471331A6F52 for ; Fri, 22 Aug 2014 16:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 q3N1ijZra7AL for ; Fri, 22 Aug 2014 16:50:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69B21A6F27; Fri, 22 Aug 2014 16:50:27 -0700 (PDT) Received: from localhost ([::1]:46192 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XKybC-0000OA-5u; Fri, 22 Aug 2014 16:50:26 -0700 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: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org, abdussalambaryun@gmail.com X-Trac-Project: manet Date: Fri, 22 Aug 2014 23:50:26 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/manet/trac/ticket/53#comment:1 Message-ID: <081.ad38784e10f06d053d20986c2e7c8d2e@trac.tools.ietf.org> References: <066.e623060914b6e950c057f764be31e6ae@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <066.e623060914b6e950c057f764be31e6ae@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org, abdussalambaryun@gmail.com, Manet@ietf.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: chris.dearlove@baesystems.com, t.clausen@computer.org Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6hOghXoHiC89mcuWue3ClZp0s_o Cc: Manet@ietf.org Subject: Re: [manet] #53 (olsrv2-multitopology): MT terminology 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: Fri, 22 Aug 2014 23:50:29 -0000 #53: MT terminology Comment (by abdussalambaryun@gmail.com): Replying to [ticket:53 abdussalambaryun@…]: > The draft must define MT routers, and non-MT routers. The draft must define MT-OLSRv2 router and non-MT-OLSRv2 router. If we mention non it can mean non-OLSRv2 router, so not defining non-MT-OLSRv2 is confusing. > > Another Suggest to amend non-MT-OLSRv2 to non-MT router because the document is already for one routing protocol which is OLSRv2. Otherwise, the terms non-MT-OLSRv2 must be defined. The above is request to be defined in Terminology section. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-manet- abdussalambaryun@gmail.com | olsrv2-multitopology@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: olsrv2-multitopology | Version: Severity: Waiting for Shepherd | Resolution: Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: manet From nobody Fri Aug 22 20:18: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 8BC4B1A00B8 for ; Fri, 22 Aug 2014 20:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 U4g2kLqe9CPy for ; Fri, 22 Aug 2014 20:18:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8595B1A6F7D; Fri, 22 Aug 2014 20:18:45 -0700 (PDT) Received: from localhost ([::1]:52914 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XL1qh-000193-RT; Fri, 22 Aug 2014 20:18:39 -0700 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: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org, abdussalambaryun@gmail.com X-Trac-Project: manet Date: Sat, 23 Aug 2014 03:18:39 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/54 Message-ID: <066.fd1047696fec4b35feb9b71ea0fb9f62@trac.tools.ietf.org> X-Trac-Ticket-ID: 54 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org, abdussalambaryun@gmail.com, Manet@ietf.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: chris.dearlove@baesystems.com, t.clausen@computer.org Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2fhTEyn6Fk9850DEcplbianLwzI Cc: Manet@ietf.org Subject: [manet] #54 (olsrv2-multitopology): Associative Mapping 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, 23 Aug 2014 03:18:48 -0000 #54: Associative Mapping The terminology is not clear for the term "map" which is replacing many elements in the router's information bases. Is the term map: a function or an information element or an associated data structure? From the definition in the terminology section the draft seems to define as a function that returns values. The map[A->B] which A domain and B codomain are not described well, as that each type in A has only one value in B or not, or that each A must have a value in B, etc. The above suggests to describe the term and domains. ==OLD Edit== A Routing Set is calculated for each link metric type in ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except that where an element is now represented by a map, the value from the map for the selected link metric type is used. Where this is a link metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for the calculation. ==New Edit== A Routing Set is calculated for each link metric type in ROUTER_METRIC_TYPES independently. The calculation may be as for [RFC7181], except that where an element is replaced by a map, the metric value from the map for the selected link metric type is used. Where this is a link metric of value UNKNOWN_METRIC, then the protocol Tuple is ignored for the calculation. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-manet- abdussalambaryun@gmail.com | olsrv2-multitopology@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: olsrv2-multitopology | Version: Severity: Waiting for Shepherd | Keywords: Writeup | -------------------------------------+------------------------------------- Ticket URL: manet From nobody Sat Aug 23 00:17: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 4ACDB1A8703 for ; Sat, 23 Aug 2014 00:17:09 -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 H7LsOFBOp3xi for ; Sat, 23 Aug 2014 00:17:08 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFDB1A8030 for ; Sat, 23 Aug 2014 00:17:07 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id f12so10385053qad.17 for ; Sat, 23 Aug 2014 00:17: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:from:date:message-id:subject:to :cc:content-type; bh=lHeBit9qA1Lf6rOkez2jAt55cPu9PJN/Ovw9Ji4ZPs4=; b=ygMBLRbWJzNQW7ZU4zo28roHB1fBeFSbX9ZAZ/tKb8Fk8PCKjp6Zz+keEKFsc9Zj4T K3ppmXHbhe3UWzF1QLCurNbofpTPqr8SmAX9f6KfmUdy2gemHOeZQmDm+YYhFyVtnYXD knNK3RYZQAvTFGn3Pr/XUFXdTbOHRqiHgpOrFl+7by9xotmvPzK36Sg3eOBmw6pUPNj3 uKyJN/1U48nwxuKmMtxkg/l80YdIx7jdTE5dVzLV6dLVV3FmRJ+A6X62VjyImMJ5lpBk O2zEa1d1NEdjiNyRYOfvr07FFWH8sm9cLTBJKt9k+sqTRPgrURYbGpP9/4ouZPS+muwq S4gQ== X-Received: by 10.224.76.9 with SMTP id a9mr10735163qak.38.1408778227227; Sat, 23 Aug 2014 00:17:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.46.68 with HTTP; Sat, 23 Aug 2014 00:16:47 -0700 (PDT) In-Reply-To: <066.fd1047696fec4b35feb9b71ea0fb9f62@trac.tools.ietf.org> References: <066.fd1047696fec4b35feb9b71ea0fb9f62@trac.tools.ietf.org> From: Henning Rogge Date: Sat, 23 Aug 2014 09:16:47 +0200 Message-ID: To: MANET IETF Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zQsTyaywK1sg_3tnlMFOS750ZIM Subject: Re: [manet] #54 (olsrv2-multitopology): Associative Mapping 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, 23 Aug 2014 07:17:09 -0000 On Sat, Aug 23, 2014 at 5:18 AM, manet issue tracker wrote: > #54: Associative Mapping > > The terminology is not clear for the term "map" which is replacing many > elements in the router's information bases. Is the term map: a function or > an information element or an associated data structure? From the > definition in the terminology section the draft seems to define as a > function that returns values. > > The map[A->B] which A domain and B codomain are not described well, as > that each type in A has only one value in B or not, or that each A must > have a value in B, etc. > > The above suggests to describe the term and domains. > Not sure how much experience do you have with programming, but in computer programs a map is normally an associative memory storage that maps keys to values... google for "hashmap" or "treemap" to find examples for Java. Henning Rogge From nobody Sat Aug 23 03:27: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 BB76C1A8747 for ; Sat, 23 Aug 2014 03:26:58 -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 69F1IeGJHEP8 for ; Sat, 23 Aug 2014 03:26:57 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5D31A06AA for ; Sat, 23 Aug 2014 03:26:56 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id x13so11948589qcv.22 for ; Sat, 23 Aug 2014 03:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=85gBNax7J9dr51O2CG2QbTLmXSTmQMY+lQSSY5Xwuic=; b=r4qanG7fS+yHR9M+JYyware4p8tLT6FjmGk0OGCxZFEOT3FquWd4RO1ufIaLIj2/V0 tjDw23O6AL1Am8BIpdDC00aMIZ7cRymRdDVb3azLHRTN5xX45bswrUDpRyUkXFC5KNvX qz7WcU6JXfuOjrDNudKbix+QkGJ1ec0n1Vbar10Ae8qwhne2CYs7y3iH4dNFdq+SEm7c ajnEeo9j/xhdtveg9gl/vIA5D/xAuVhuFiCihM28cZM8Qc+5ddA9tdVBiypw95M0/H7Q XhAqQeqGFBq51vznlI42w3kv32BMb0f4LEHRwM8af+gKrIgftgRuNSYf1CtmW+lQ2oKZ z1iQ== X-Received: by 10.224.130.201 with SMTP id u9mr16671236qas.58.1408789615934; Sat, 23 Aug 2014 03:26:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.46.68 with HTTP; Sat, 23 Aug 2014 03:26:35 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sat, 23 Aug 2014 12:26:35 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NHAMEypp51kpxrrxK3S1Az__TnY Cc: "manet@ietf.org" Subject: Re: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-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: Sat, 23 Aug 2014 10:26:58 -0000 On Fri, Aug 22, 2014 at 4:17 PM, Dearlove, Christopher (UK) wrote: > OK, with regard to hop limit, I'm back with it. > >> My draft already covers this, it only allows messages with a hop-limit l= arger than one to be put into a UDP/RFC-5444 packet with a different addres= s length. > > Or in other words, you can't put HELLO messages in an IP datagram (that's= the level that matters) for another size limit. Exactly. > But you can put (every real) TC messages there. Yes. I restrict the "dualstack" optimization to multihop messages just to be sure I don't grab a message that needs the source-IP address. > That's unnecessarily restricting, at least in principle, as HELLO message= s don't have to use the IP source address. It would be possible to say in t= hat case there's an error. Of course that would extend 6130, which would be= an issue in something experimental. And it would make the whole thing a LOT more complicated. > I need to read your draft. But I'd want to see a proof that messages alwa= ys get where they need to go. What if you have 2-hop neighbours that are IP= v4 only? Will the IPv6 MPRs cover them? And I'm still doubtful about differ= ent IPv4/v6 link states and interaction with MPR selection. What if you use= link metrics in flooding MPR selection (an allowed option)? Thats a good point, i have to look into the MPR calculation again, most likely there is additional work to do. Henning Rogge From nobody Sat Aug 23 09:38: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 7352F1A0416 for ; Sat, 23 Aug 2014 09:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 vBFbM_FIIpIn for ; Sat, 23 Aug 2014 09:38:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D166F1A0417 for ; Sat, 23 Aug 2014 09:38:47 -0700 (PDT) Received: from localhost ([::1]:51961 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XLEKv-0003s2-Jq; Sat, 23 Aug 2014 09:38:41 -0700 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: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org, abdussalambaryun@gmail.com X-Trac-Project: manet Date: Sat, 23 Aug 2014 16:38:41 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/manet/trac/ticket/55 Message-ID: <066.3e1906b2a4af830a63b2dc76aad57fbe@trac.tools.ietf.org> X-Trac-Ticket-ID: 55 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org, abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: chris.dearlove@baesystems.com, t.clausen@computer.org Archived-At: http://mailarchive.ietf.org/arch/msg/manet/S2lJac7sxYbIAfR6jplyqJsIzL8 Cc: manet@ietf.org Subject: [manet] #55 (olsrv2-multitopology): Maintaining Multiple Routing Sets 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, 23 Aug 2014 16:38:49 -0000 #55: Maintaining Multiple Routing Sets --- Old Edit --- In a similar way, the role of this extension can be described as to create and maintain multiple Routing Sets, one for each link metric type supported by the router maintaining the sets. --- New Edit --- In a similar way, the role of this extension can be described as to maintain multiple Routing Sets, one for each link metric type supported by the router maintaining the sets. AB> the draft does not specify creating routing sets. AB> I am trying to find the routing sets maintenance of this extension, no information about the router's handling of multiple topologies within its processing time. What are the priorities of the single MT-routing function while receiving different messages for the different topologies, which that maintenance is not specified by RFC7181 and needs to be in this extension. Suggest a clear section to describe maintenance of multiple routing sets (as introduction mentions that this extension is about routing sets maintenance). ---- The draft mentions> each router will maintain a Routing Set for each topology that it forms part of, allowing separate routing of packets for each topology. AB> the draft needs to describe, How does MT-router do that separation for the multiple topology packets? If that answer in open for implementors then I don't think there is a maximum interoperability between MT-routers. Section 11 should describe updates and maintenance of multiple routing sets with packet separation (this should not to be left out of the draft as just considerations in last sections). --------- Section 12> MT-OLSRv2 may require greater management than unextended OLSRv2. In particular MT-OLSRv2 requires the following management considerations: ... AB> these MT routers require administration and specific management considerations to ensure good performance. Section 12 mentions it as MAY but I suggest to replace to MUST. The section is a must requirement not just recommendations, the section needs to be updated and moved after section 4. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-manet- abdussalambaryun@gmail.com | olsrv2-multitopology@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: olsrv2-multitopology | Version: Severity: Waiting for Shepherd | Keywords: Writeup | -------------------------------------+------------------------------------- Ticket URL: manet From nobody Sat Aug 23 10:21: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 8A6221A8859 for ; Sat, 23 Aug 2014 10:21:07 -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 oR8ZOBPiJ7zS for ; Sat, 23 Aug 2014 10:21:05 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A9C1A885A for ; Sat, 23 Aug 2014 10:21:05 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so894996wib.10 for ; Sat, 23 Aug 2014 10:21:03 -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=lYpxIBAKt1CBOdrs0ot0tS2EMJNa7JJ3glMBMkSzFWc=; b=MJlBQHd6FDzVymRHH4OvuzA778xaUT+cNL/2jdUyGWaX/ndCanduGuJ9Z9JO/cbctl wVO3mmK32WPltIVEBBq+b2j2DD3wjMYNrFP55WHgJxNDgg2mokGrqvKeuFZxnfUj/GEW /qAnQtNe9KdIdBeb4cCtB7xAwsUDO5dLXTg9l4PpJlK1uuennj+Rb0CYMoChBLhhj0Qr xLl1bXnGZBnLA7GObCLKbTZA3U12QxDEKvw1xDrhVkjYlCzCY7dLFWOww+WCRTkVnFnw Fu05JqVipp7D42nKzAKQwsV5ayRAQd0cO15jQBg8XLV46jLPQLr6ME3LRGEMQHHuRD+n 6ANg== X-Received: by 10.180.207.105 with SMTP id lv9mr4839167wic.23.1408814463826; Sat, 23 Aug 2014 10:21:03 -0700 (PDT) Received: from [10.2.239.49] (dab-ell1-h-17-3.dab.02.net. [82.132.237.71]) by mx.google.com with ESMTPSA id m5sm11177331wiz.19.2014.08.23.10.21.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Aug 2014 10:21:02 -0700 (PDT) References: <066.3e1906b2a4af830a63b2dc76aad57fbe@trac.tools.ietf.org> Mime-Version: 1.0 (1.0) In-Reply-To: <066.3e1906b2a4af830a63b2dc76aad57fbe@trac.tools.ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Christopher Dearlove Date: Sat, 23 Aug 2014 18:20:57 +0100 To: "manet@ietf.org" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gv2RMsoevCixj1fmreqnH8V0Zs0 Cc: "draft-ietf-manet-olsrv2-multitopology@tools.ietf.org" Subject: Re: [manet] #55 (olsrv2-multitopology): Maintaining Multiple Routing Sets 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, 23 Aug 2014 17:21:07 -0000 It would help if you read the drafts you comment on properly and were famili= ar with what they build on. Then there would be less time wasted. Also comme= nts before WGLC closes would be timely. However as nothing here suggests a n= eed for a change, that doesn't matter. I didn't comment on your last posting= for similar reasons. Yes, the draft does describe creating multiple routing sets. See Section 11.= If familiar with OLSRv2, that's all you need - because OLSRv2 describes how= a Routing Set is calculated and when it needs to change. How are things separated? By metric type, as is clearly said more than once.= Metric types are defined in OLSRv2. And what does the phrase "within its pr= ocessing time" even mean? I don't believe there's an incompatibility between implementations. Of cours= e I might be wrong, but nothing here makes me think otherwise. The may is a may, not a must. I'm afraid suggesting it's a MUST shows a fail= ure to understand what a MUST is. It's even carefully a may not a MAY. And i= t does not need moving. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 23 Aug 2014, at 17:38, "manet issue tracker" wrote: >=20 > #55: Maintaining Multiple Routing Sets >=20 > --- Old Edit --- >=20 > In a similar way, the role of this extension > can be described as to create and maintain multiple Routing Sets, one > for each link metric type supported by the router maintaining the > sets. >=20 > --- New Edit --- >=20 > In a similar way, the role of this extension > can be described as to maintain multiple Routing Sets, one > for each link metric type supported by the router maintaining the > sets. >=20 > AB> the draft does not specify creating routing sets. >=20 > AB> I am trying to find the routing sets maintenance of this extension, no= > information about the router's handling of multiple topologies within its > processing time. What are the priorities of the single MT-routing function= > while receiving different messages for the different topologies, which > that maintenance is not specified by RFC7181 and needs to be in this > extension. Suggest a clear section to describe maintenance of multiple > routing sets (as introduction mentions that this extension is about > routing sets maintenance). >=20 > ---- >=20 > The draft mentions> >=20 > each router will maintain a Routing Set for each topology that it forms > part of, allowing separate routing of packets for each topology. >=20 >=20 > AB> the draft needs to describe, How does MT-router do that separation for= > the multiple topology packets? If that answer in open for implementors > then I don't think there is a maximum interoperability between MT-routers.= > Section 11 should describe updates and maintenance of multiple routing > sets with packet separation (this should not to be left out of the draft > as just considerations in last sections). >=20 > --------- >=20 > Section 12> > MT-OLSRv2 may require greater management than unextended OLSRv2. In > particular MT-OLSRv2 requires the following management > considerations: ... >=20 > AB> these MT routers require administration and specific management > considerations to ensure good performance. Section 12 mentions it as MAY > but I suggest to replace to MUST. The section is a must requirement not > just recommendations, the section needs to be updated and moved after > section 4. >=20 > --=20 > -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-manet- > abdussalambaryun@gmail.com | olsrv2-multitopology@tools.ietf.org= > Type: defect | Status: new > Priority: major | Milestone: > Component: olsrv2-multitopology | Version: > Severity: Waiting for Shepherd | Keywords: > Writeup | > -------------------------------------+------------------------------------= - >=20 > Ticket URL: > manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Sun Aug 24 02:06: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 ACAC61A8727 for ; Sun, 24 Aug 2014 02:06:53 -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 T_bNlCxumYtm for ; Sun, 24 Aug 2014 02:06:52 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7177E1A0174 for ; Sun, 24 Aug 2014 02:06:52 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so12203586qga.1 for ; Sun, 24 Aug 2014 02:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=AABTPF3VBnGQtdiK0x/dzC9JLED/KOon5Y98GuV9lBU=; b=EZZFPfMBc2H8yhUHwlCtbHTE0cHghQmt0+EMSzC9qy5PKor3XWY9CK8KM+wu3yFn7U peHM8N3fNmHZ3QPnosE6sAe4qq7VfVOJ8sH+L32syMmHOkygIbopZBCtHS4rloHzDMpg g5T7xSJC8v24Srnxl7Zzo8hScb7NmkKLX/yLgFJ8zBBaVgWxFziJkHZ02+HBKRjUuk3t Uq6XL9fAajJWQ/q7TVoFRArRsNK01efKAC7p5XRcLufCR0DkGU+GGZctFkGC+iwLFjRI fUAyhVh2WOiyI7HbcMRoCsLVUrmEvEMOsGC6gfaB5xXDhxN0yaxrDONbj+mNb+9vS9Gw s6PQ== X-Received: by 10.229.57.138 with SMTP id c10mr23858204qch.30.1408871211686; Sun, 24 Aug 2014 02:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.46.68 with HTTP; Sun, 24 Aug 2014 02:06:31 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sun, 24 Aug 2014 11:06:31 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kWmzQOXQj8ij3bFt2MV1KgsqS2c Cc: "manet@ietf.org" Subject: Re: [manet] Dual stack operations (was RE: draft-ietf-manet-olsrv2-management-snapshot-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: Sun, 24 Aug 2014 09:06:53 -0000 On Sat, Aug 23, 2014 at 12:26 PM, Henning Rogge wrote: >> I need to read your draft. But I'd want to see a proof that messages alw= ays get where they need to go. What if you have 2-hop neighbours that are I= Pv4 only? Will the IPv6 MPRs cover them? And I'm still doubtful about diffe= rent IPv4/v6 link states and interaction with MPR selection. What if you us= e link metrics in flooding MPR selection (an allowed option)? > > Thats a good point, i have to look into the MPR calculation again, > most likely there is additional work to do. Okay, I had some time to think about the MPR situation and I think it will work without adding a third MPR set... but we (somehow) have to use the IPv4 MPR set for IPv4 messages, even if they come inside an IPv6 UDP packet (plus RFC5444 header of course). So the trick is to determine the "other" IP address of your neighbors interfaces... so that you can take (as an example) the IPv6 source address, transform it into an IPv4 source address of the same interface of the neighbor and then use the IPv4 MPR set and duplicate set. I think this should already be possible with the existing data structure, because it stores the "ipv4 originator" in the IPv6 Link Set Tuple, which means we can search for the corresponding IPv4 Link Set Tuple on the same interface. Thank you for finding this issue, I will work on formulating the necessary = text. Henning Rogge From nobody Sun Aug 24 02:10: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 CFD9F1A8727 for ; Sun, 24 Aug 2014 02:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, 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 3i-CrmR4gW6e for ; Sun, 24 Aug 2014 02:10:30 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DC71A884F for ; Sun, 24 Aug 2014 02:10:29 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id i8so12786534qcq.13 for ; Sun, 24 Aug 2014 02:10:29 -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=Z0sEZXDToaTMVXQdjT7fsLCRCeBm/Dy6kQrq9SE3FE8=; b=Ab28m2mdNuz9Zi+VUzvzjYKLg0xmvkQtcgbF07jvYscExRwfYh65zD4+bD3V4T1cC0 TZgdx0iXRIzKSynIzS4je/Oaxo170HPDOHUqbncN2PQXXJ2I9VwNAoANS24Cmskvaj7J MXOuvNNc23bk9JVkvGWc0u2se9V2u7Bf0D+fSrzEIqUWqUhb3RSixsYHyr8d2EdZCzzo OwHk+cPPUygT0Mz2AcMVyPIv6Y4imTdFO0T/FbVxlhI9egK3psv/znaVvQParTymi/oP TLydtAmebNsPQ4oXjGd2oqIMrg1OtxXXJ0UHz4mJUwGhIScz2srXSZaeJqrd8XNaCJ3G u0oA== X-Received: by 10.224.130.201 with SMTP id u9mr24790656qas.58.1408871429063; Sun, 24 Aug 2014 02:10:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.46.68 with HTTP; Sun, 24 Aug 2014 02:10:08 -0700 (PDT) In-Reply-To: <066.3e1906b2a4af830a63b2dc76aad57fbe@trac.tools.ietf.org> References: <066.3e1906b2a4af830a63b2dc76aad57fbe@trac.tools.ietf.org> From: Henning Rogge Date: Sun, 24 Aug 2014 11:10:08 +0200 Message-ID: To: MANET IETF Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0m8Y3A6XinicaiivW3fGGeq18JI Subject: Re: [manet] #55 (olsrv2-multitopology): Maintaining Multiple Routing Sets 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, 24 Aug 2014 09:10:31 -0000 Abdussalam, I think you should take a step back... your recent bug tracker posts were again a mixture of "yes, we might think about it" and "this is a waste of time"... this one is more of the second category. Please work a bit more on your feedback before sending it to the list/bugtracker and try to focus on the important parts. Mixing both categories make people stop reading your posts without checking if they contain something useful or not. Henning Rogge On Sat, Aug 23, 2014 at 6:38 PM, manet issue tracker wrote: > #55: Maintaining Multiple Routing Sets > > --- Old Edit --- > > In a similar way, the role of this extension > can be described as to create and maintain multiple Routing Sets, one > for each link metric type supported by the router maintaining the > sets. > > --- New Edit --- > > In a similar way, the role of this extension > can be described as to maintain multiple Routing Sets, one > for each link metric type supported by the router maintaining the > sets. > > AB> the draft does not specify creating routing sets. > > AB> I am trying to find the routing sets maintenance of this extension, no > information about the router's handling of multiple topologies within its > processing time. What are the priorities of the single MT-routing function > while receiving different messages for the different topologies, which > that maintenance is not specified by RFC7181 and needs to be in this > extension. Suggest a clear section to describe maintenance of multiple > routing sets (as introduction mentions that this extension is about > routing sets maintenance). > > ---- > > The draft mentions> > > each router will maintain a Routing Set for each topology that it forms > part of, allowing separate routing of packets for each topology. > > > AB> the draft needs to describe, How does MT-router do that separation for > the multiple topology packets? If that answer in open for implementors > then I don't think there is a maximum interoperability between MT-routers. > Section 11 should describe updates and maintenance of multiple routing > sets with packet separation (this should not to be left out of the draft > as just considerations in last sections). > > --------- > > Section 12> > MT-OLSRv2 may require greater management than unextended OLSRv2. In > particular MT-OLSRv2 requires the following management > considerations: ... > > AB> these MT routers require administration and specific management > considerations to ensure good performance. Section 12 mentions it as MAY > but I suggest to replace to MUST. The section is a must requirement not > just recommendations, the section needs to be updated and moved after > section 4. > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-manet- > abdussalambaryun@gmail.com | olsrv2-multitopology@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: olsrv2-multitopology | Version: > Severity: Waiting for Shepherd | Keywords: > Writeup | > -------------------------------------+------------------------------------- > > Ticket URL: > manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Sun Aug 24 10:45: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 C301E1A041C for ; Sun, 24 Aug 2014 10:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.831 X-Spam-Level: X-Spam-Status: No, score=-0.831 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, RCVD_IN_SORBS_WEB=0.77, 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 YaJxin5gDxIZ for ; Sun, 24 Aug 2014 10:45:14 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFF91A0417 for ; Sun, 24 Aug 2014 10:45:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8F6541BC16AB for ; Sun, 24 Aug 2014 10:45:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.43.173] (13.17.90.92.rev.sfr.net [92.90.17.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B8D7C1BC168B for ; Sun, 24 Aug 2014 10:45:12 -0700 (PDT) From: =?iso-8859-1?Q?Axel_Colin_de_Verdi=E8re?= Content-Type: multipart/alternative; boundary="Apple-Mail=_D5B447CD-575D-4D16-AC0C-C9A9E13D0AE5" Date: Sun, 24 Aug 2014 19:45:09 +0200 References: <20140824174121.16879.48031.idtracker@ietfa.amsl.com> To: "" Message-Id: <57DC5F21-7068-4258-9D87-345169FA88E5@axelcdv.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pze1Zs1Nuwc-q1lUDC6zCqtzGY4 Subject: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-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: Sun, 24 Aug 2014 17:45:15 -0000 --Apple-Mail=_D5B447CD-575D-4D16-AC0C-C9A9E13D0AE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear WG, We submitted a new revision for the ODMRP draft. The main changes concern the handling of interfaces with multiple = addresses, which previously could prevent the blacklist from working = correctly, and the security considerations section. Comments and reviews would be much appreciated. Best, Axel D=E9but du message r=E9exp=E9di=E9 : > De: internet-drafts@ietf.org > Objet: New Version Notification for draft-gerla-manet-odmrp-04.txt > Date: 24 ao=FBt 2014 19:41:21 UTC+2 > =C0: "William Su" , "Yunjung Yi" = , "Axel Coli Verdiere" = , Mario Gerla , "Professor Mario = Gerla" , William Su , Axel = Colin de Verdiere >=20 >=20 > A new version of I-D, draft-gerla-manet-odmrp-04.txt > has been successfully submitted by Axel Colin de Verdiere and posted = to the > IETF repository. >=20 > Name: draft-gerla-manet-odmrp > Revision: 04 > Title: On-Demand Multicast Routing Protocol (ODMRP) for = Ad Hoc Networks > Document date: 2014-08-24 > Group: Individual Submission > Pages: 37 > URL: = http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-04.txt > Status: = https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/ > Htmlized: http://tools.ietf.org/html/draft-gerla-manet-odmrp-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-04 >=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, without relying on pre-existing unicast > routing protocols. 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=_D5B447CD-575D-4D16-AC0C-C9A9E13D0AE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = WG,

We submitted a new revision for the ODMRP = draft.
The main changes concern the handling of interfaces = with multiple addresses, which previously could prevent the blacklist = from working correctly, and the security considerations = section.
Comments and reviews would be much = appreciated.

Best,

Axel<= br>

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

De: internet-drafts@ietf.org
<= /span>
Objet: = New Version = Notification for draft-gerla-manet-odmrp-04.txt
Date: 24 ao=FBt 2014 19:41:21 = UTC+2
=C0: = "William Su" <william.su@boeing.com>, = "Yunjung Yi" <unknown-email-Yunj= ung-Yi@ietfa.amsl.com>, "Axel Coli Verdiere" <axel@axelcdv.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-04.txt
has = been successfully submitted by Axel Colin de Verdiere and posted to = the
IETF repository.

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

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, without relying on = pre-existing unicast
  routing protocols.  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=_D5B447CD-575D-4D16-AC0C-C9A9E13D0AE5-- From nobody Mon Aug 25 19:06: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 3566E1A066C for ; Mon, 25 Aug 2014 19:06:08 -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 dxVKAVpGJ8RZ for ; Mon, 25 Aug 2014 19:06:06 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9670F1A0666 for ; Mon, 25 Aug 2014 19:06:06 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id w7so14697184qcr.6 for ; Mon, 25 Aug 2014 19:06:05 -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=DuJCnDZWnLXqYc1C1537TvVqUdcl4+1bduL3lWkRqbQ=; b=gLtEL7pc1jvnIA7ikE5+9qjaDVH1IQ5H+3+fKDm8lIjrgU8sf2pIWXX4bELHHLsu2d Y3OsszAuBF/Q9DdC7MApUIRvek9eE81mvt5i4emYILrf9CMSWSN2t3ClPYLYemhYQV+S pWiD6SNGH7cjZpaVH9mQum7fc8AHfu2D2AxCNY5B2l+/rYktj2uuqjFbzENDaWOgMLaI n+C2ZiCKws8vPynJugRoNZI1/YXHx19upVmEj9kgLHqcwEZAvN1M/ZQ1EiXh9aSauAHS attSsvqYeCTZud9yyDreaLCjVSqbGJXDaGqGph0JZEOzUswz7vfk+k7jAG8NaSSOBrbI znKg== MIME-Version: 1.0 X-Received: by 10.224.75.130 with SMTP id y2mr41529191qaj.72.1409018765837; Mon, 25 Aug 2014 19:06:05 -0700 (PDT) Received: by 10.140.101.140 with HTTP; Mon, 25 Aug 2014 19:06:05 -0700 (PDT) In-Reply-To: <57DC5F21-7068-4258-9D87-345169FA88E5@axelcdv.com> References: <20140824174121.16879.48031.idtracker@ietfa.amsl.com> <57DC5F21-7068-4258-9D87-345169FA88E5@axelcdv.com> Date: Mon, 25 Aug 2014 22:06:05 -0400 Message-ID: From: Joseph Macker To: =?UTF-8?Q?Axel_Colin_de_Verdi=C3=A8re?= Content-Type: multipart/alternative; boundary=001a11c2ef7e050bc005017ebf70 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/W9_bryWp17mbRezy2wIG0_ZpsRs Cc: "" Subject: Re: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-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, 26 Aug 2014 02:06:08 -0000 --001a11c2ef7e050bc005017ebf70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Axel: Thanks for the update look forward to reading. -Joe On Sun, Aug 24, 2014 at 1:45 PM, Axel Colin de Verdi=C3=A8re wrote: > Dear WG, > > We submitted a new revision for the ODMRP draft. > The main changes concern the handling of interfaces with multiple > addresses, which previously could prevent the blacklist from working > correctly, and the security considerations section. > Comments and reviews would be much appreciated. > > Best, > > Axel > > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : > > *De: *internet-drafts@ietf.org > *Objet: **New Version Notification for draft-gerla-manet-odmrp-04.txt* > *Date: *24 ao=C3=BBt 2014 19:41:21 UTC+2 > *=C3=80: *"William Su" , "Yunjung Yi" < > unknown-email-Yunjung-Yi@ietfa.amsl.com>, "Axel Coli Verdiere" < > axel@axelcdv.com>, Mario Gerla , "Professor Mario > Gerla" , William Su , Axel > Colin de Verdiere > > > A new version of I-D, draft-gerla-manet-odmrp-04.txt > has been successfully submitted by Axel Colin de Verdiere and posted to t= he > IETF repository. > > Name: draft-gerla-manet-odmrp > Revision: 04 > Title: On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks > Document date: 2014-08-24 > Group: Individual Submission > Pages: 37 > URL: > http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-04.txt > Status: https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/ > Htmlized: http://tools.ietf.org/html/draft-gerla-manet-odmrp-04 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-04 > > 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, without relying on pre-existing unicast > routing protocols. 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 > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11c2ef7e050bc005017ebf70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Axel:

Thanks for the update look forwar= d to reading.

-Joe


On Sun, Aug 24, 2014 at 1:45 PM, = Axel Colin de Verdi=C3=A8re <axel@axelcdv.com> wrote:
Dear WG,=

We submitted a new revision for the ODMRP draft.
<= div> The main changes concern the handling of interfaces with multiple addresses= , which previously could prevent the blacklist from working correctly, and = the security considerations section.
Comments and reviews would b= e much appreciated.

Best,

Axel

D= =C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 :

Objet: New Version Notification for draft-gerla-manet-odmrp-04.txt<= br>
Date: 24 ao=C3=BBt 2014 19:41:21 UTC+2
=C3=80: "William Su" <william.su@boeing.com>, "Yunjung Yi" &= lt;unknown-email-Yunjung-Yi@ietfa.amsl.com>, "Axel Coli Verdi= ere" <axel@ax= elcdv.com>, Mario Gerla <gerla@cs.ucla.edu>, "Professor Mario Gerla"= <gerla@cs.ucla.e= du>, William Su <william.su@boeing.com>, Axel Colin de Verdiere <axel@axelcdv.com>


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

Name: draft-gerla-manet-od= mrp
Revision: 04
Title: <= /span>On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks
D= ocument date: 2014-08-24
Group: Individual Submission
Pages: 37
UR= L: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp= -04.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https:= //datatracker.ietf.org/doc/draft-gerla-manet-odmrp/
Htmlized: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://tools.ietf.org/html/draft-ger= la-manet-odmrp-04
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-gerla-manet-odmrp-04

Abstract:
=C2=A0=C2=A0The On-Demand Multicast Routing Protoco= l (ODMRP) is a multicast
=C2=A0=C2=A0routing protocol designed for ad hoc networks with mobile host= s.
=C2=A0=C2=A0ODMRP is a mesh-based, rather than a conventional tree-b= ased,
=C2=A0=C2=A0multicast scheme and uses a forwarding group concept = (only a subset
=C2=A0=C2=A0of nodes forwards the multicast packets via = scoped flooding). =C2=A0It
=C2=A0=C2=A0applies on-demand procedures to dynamically build routes and m= aintain
=C2=A0=C2=A0multicast group membership, without relying on pre-= existing unicast
=C2=A0=C2=A0routing protocols. =C2=A0ODMRP is well sui= ted for ad hoc wireless networks
=C2=A0=C2=A0with mobile hosts where bandwidth is limited, topology changes=
=C2=A0=C2=A0frequently and rapidly, and power is constrained.

<= br>

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

The IETF Secretari= at



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


--001a11c2ef7e050bc005017ebf70-- From nobody Wed Aug 27 15:39: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 D36FA1A0123 for ; Wed, 27 Aug 2014 15:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 DhpGTsfKiJmm for ; Wed, 27 Aug 2014 15:39:01 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF80A1A011F for ; Wed, 27 Aug 2014 15:39:00 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ik5so14533vcb.21 for ; Wed, 27 Aug 2014 15:39:00 -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:content-transfer-encoding; bh=8esASqcuaVDWLujWFCnv4Gph2PyqZTZU7pITIzMp1Jc=; b=mLOhVYOyBD1gAiVO9S1t+uZSKXS9MY8JohjsBy196Dtcnzief4rTAfzZ7eE8bEZb3D StPx/bk8WjKusMVqdR1OrdTKNsXUWWSdsUdVz2dRMRfYfLE1ZUEXQmOGMh9RD0x6zAmY yjEL7Nd0qo0BW46skVSmSZuFJdGc195hvB1+4= 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:content-transfer-encoding; bh=8esASqcuaVDWLujWFCnv4Gph2PyqZTZU7pITIzMp1Jc=; b=ZV59UeUP0H3aKO8kGYAD/xRCTKOsVx1MaUGbRNmHx16pCcKsrBoX9L2OlqJ7IdkSkA 3JkAqblOTStK5BGhZkQVpILel9MB6EZcGkgPWpEbSLf5N61w77YXGg5rSKCLVqq7Rx8F K56DEZ8EAz4gC2ezvqLuiyZwIzwapy3LE3Pm1OHtXJ1MzG2y/D3ygLEt35sf/Mouco5y 6WCsCLi2e8GBGhFUnQ1AiLxVEUwoDi5jJCtQKzNRCaxhUwP7967Nxf0DFXHOEZW8TSPn qbCLOZakF2ck1clKhh8pHwotUJyUBzULK0lckNN3wujkoh3T+7eUcvs/t7gqhXtlG97A iz3A== X-Gm-Message-State: ALoCoQnc44G2AU61f7HOumq4YxTyHX4JjKUHI69s+d/E7GK4m1bt2pHpbX10ucohQsPn00ERuSnp MIME-Version: 1.0 X-Received: by 10.220.105.142 with SMTP id t14mr92088vco.14.1409179140001; Wed, 27 Aug 2014 15:39:00 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Wed, 27 Aug 2014 15:38:59 -0700 (PDT) In-Reply-To: <53F6F9C1.1080709@fkie.fraunhofer.de> References: <33511460-38DA-43BD-9791-21E5BC11DBA3@mnemosyne.demon.co.uk> <53F6F9C1.1080709@fkie.fraunhofer.de> Date: Wed, 27 Aug 2014 15:38:59 -0700 Message-ID: From: Ulrich Herberg To: Henning Rogge , manet@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6mIVdOpkME1tkFtBsmJTDAY9sp0 Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-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: Wed, 27 Aug 2014 22:39:03 -0000 Henning, Chris, I am currently working on Chris' review. Can you propose a sentence for the mgmt draft that reflects this accurately? > 3.1 could (as Henning might well point out) say that while the messages a= nd protocol instantiations are separate, the message could share a packet. = Though there are some implications of saying so in terms of the 5444 multi= plexing not quite stated assumptions. How about something like: OLD In particular, all routers in the same MANET topology must be pre-configured to use the same IP address family (IPv4 or IPv6). In a single OLSRv2 topology, it is not possible to mix IPv4 and IPv6 addresses, notably because [RFC5444] messages can contain either IPv4 *or* IPv6 addresses, but not both at the same time. It is, however, possible to run two instances of OLSRv2, one instance for IPv4 and another one for IPv6, within the same network. NEW In particular, all routers in the same MANET topology must be pre-configured to use the same IP address family (IPv4 or IPv6). In a single OLSRv2 topology, it is not possible to mix IPv4 and IPv6 addresses, notably because [RFC5444] messages can contain either IPv4 *or* IPv6 addresses, but not both at the same time. It is, however, possible to run two instances of OLSRv2, one instance for IPv4 and another one for IPv6, within the same network. In general, [RFC5444] packets may contain messages with different address lengths; however, some protocols using [RFC5444] may constrain this further: For example, NHDP may use the IP source address of the packet containing a HELLO message as originator address. Thoughts? Regards Ulrich On Fri, Aug 22, 2014 at 1:05 AM, Henning Rogge wrote: > On 08/22/2014 09:46 AM, Christopher Dearlove wrote: >> No, not quite the same. 5444 explicitly discusses separate protocols. >> It doesn't explicitly discuss address lengths. The 5444 model assumes >> that all HELLO messages are sent to a single entity, regardless of >> address type. (It doesn't say regardless of address type, it just >> doesn't mention it.) That would be NHDP of course. But the NHDP >> description is of a protocol that has a certain type of address. I >> don't recall if it explicitly says drop HELLO messages with wrong >> address length or not. > > http://tools.ietf.org/html/rfc6130#section-12.1 > > A received HELLO message is invalid for processing by this router if any > of the following conditions are true: > > o The address length as specified in the Message Header is not equal > to the length of the addresses used by this router. > >> There's nothing actually specified anywhere which describes a process >> something like 5444 gets HELLO, sends to NHDP. NHDP looks at address >> length and sends to NHDP/IPv4 or NHDP/IPv6 for address lengths 4 or >> 16 (and drops HELLO messages with other lengths?). Here NHPD/IPv4 and >> NHDP/IPv6 are separate instantiations of 6130. (And ditto for >> OLSRv2.) Of course that's a reasonably obvious approach, just not >> explicitly specified anywhere,because 5444 can say it's up to the >> protocol, and the protocol can say it's really a multiplexing thing. > > You could argue that if you want to do a dualstack thing, you just need > a second level of multiplexer. > >> And the comment that messages have no constraints on the IP address >> type of the surrounding packet is true for 5444. It's not true for >> NHDP, which uses the IP datagram source address. That's actually an >> issue that a dual stack approach needs to cover. > > My draft already covers this, it only allows messages with a hop-limit > larger than one to be put into a UDP/RFC-5444 packet with a different > address length. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed Aug 27 23:30: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 308971A03C0 for ; Wed, 27 Aug 2014 23:30:23 -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 LiqaXhHMlLSo for ; Wed, 27 Aug 2014 23:30:22 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD391A043D for ; Wed, 27 Aug 2014 23:30:21 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id e89so327536qgf.32 for ; Wed, 27 Aug 2014 23:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=knjkFJYNMkyGM8BBsKf0HCINvj782cNqGNiQ6becvY4=; b=lSDMk45K1FmdNOnyywDDbXMe2HbQ/J5UyGT0WfgDgFXAjN2Q4G6sdebH2KmmLVtCQv PmcQvZFrKN65K0LFovb5KMdQg8zDmdH8op4Of3oyON5Tg0qJX0PW8GHnv/v4Q97Pdb46 Q9e1t3+dD4Mh1gw0xH04q5Q2nOFALbGJtSSsJp6dnMzMszbkeebALwhK1R+acmFCnqow sGz0TBZ+I90TFXwemS+S3jPL/MGuJh5pbFMXnGRZeqJKAVIe6H/6osT8RSRVslJUMfEO P9ZiL62utvwPcIk1ytaoN23aF38DIVBT1wEjl6e8UvM8ifI5lQHjiwzsFgDYyg8qjysH tQog== X-Received: by 10.224.66.7 with SMTP id l7mr3362213qai.46.1409207421020; Wed, 27 Aug 2014 23:30:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.46.68 with HTTP; Wed, 27 Aug 2014 23:30:00 -0700 (PDT) In-Reply-To: References: <33511460-38DA-43BD-9791-21E5BC11DBA3@mnemosyne.demon.co.uk> <53F6F9C1.1080709@fkie.fraunhofer.de> From: Henning Rogge Date: Thu, 28 Aug 2014 08:30:00 +0200 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9E80yZhYmvnsMI_2qoJ58w3SbT0 Cc: MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-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, 28 Aug 2014 06:30:23 -0000 On Thu, Aug 28, 2014 at 12:38 AM, Ulrich Herberg wrot= e: > Henning, Chris, > > I am currently working on Chris' review. Can you propose a sentence > for the mgmt draft that reflects this accurately? > >> 3.1 could (as Henning might well point out) say that while the messages = and protocol instantiations are separate, the message could share a packet.= Though there are some implications of saying so in terms of the 5444 mult= iplexing not quite stated assumptions. > > How about something like: > > OLD > In particular, all routers in the same MANET topology must be > pre-configured to use the same IP address family (IPv4 or IPv6). In a > single OLSRv2 topology, it is not possible to mix IPv4 and IPv6 > addresses, notably because [RFC5444] messages can contain either IPv4 > *or* IPv6 addresses, but not both at the same time. It is, however, > possible to run two instances of OLSRv2, one instance for IPv4 and > another one for IPv6, within the same network. > > NEW > In particular, all routers in the same MANET topology must be > pre-configured to use the same IP address family (IPv4 or IPv6). In a > single OLSRv2 topology, it is not possible to mix IPv4 and IPv6 > addresses, notably because [RFC5444] messages can contain either IPv4 > *or* IPv6 addresses, but not both at the same time. It is, however, > possible to run two instances of OLSRv2, one instance for IPv4 and > another one for IPv6, within the same network. > In general, [RFC5444] packets may contain messages with different > address lengths; however, some protocols using [RFC5444] may constrain > this further: For example, NHDP may use the IP source address of the > packet containing a HELLO message as originator address. Sounds good to me. Henning Rogge From nobody Thu Aug 28 01:47: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 ABDC61A04D2 for ; Thu, 28 Aug 2014 01:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.568 X-Spam-Level: X-Spam-Status: No, score=-9.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 E7LqLiNMTIFV for ; Thu, 28 Aug 2014 01:47:17 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBABA1A047C for ; Thu, 28 Aug 2014 01:47:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,416,1406588400"; d="scan'208";a="398804424" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 28 Aug 2014 09:47:15 +0100 X-IronPort-AV: E=Sophos;i="5.04,416,1406588400"; d="scan'208";a="70916480" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 28 Aug 2014 09:47:16 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.13]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Thu, 28 Aug 2014 09:47:14 +0100 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg , Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] draft-ietf-manet-olsrv2-management-snapshot-02 Thread-Index: AQHPvdWjP6y4mAtQLU6oLzxu8Kv6w5vcLhEAgAAFI4CACM+/gIAAucoQ Date: Thu, 28 Aug 2014 08:47:14 +0000 Message-ID: References: <33511460-38DA-43BD-9791-21E5BC11DBA3@mnemosyne.demon.co.uk> <53F6F9C1.1080709@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/FCLYaft3HYq97OlGqV8Gq9D8Zz8 Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-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, 28 Aug 2014 08:47:20 -0000 VGhlIGltcG9ydGFudCB0aGluZyBJIHRoaW5rIGlzIHRvIHN0ZWVyIGEgbWlkZGxlIGNvdXJzZS4g SXQgd291bGRuJ3QgYmUgcmlnaHQgdG8gc2F5IGp1c3QgSVB2NCBvciBJUHY2IGlzIHBvc3NpYmxl LCBiZWNhdXNlIHRoZXJlIGlzIHRoZSBwb3NzaWJpbGl0eSBvZiBib3RoLiBCdXQgb24gdGhlIG90 aGVyIGhhbmQgdGhpcyBkb2N1bWVudCBpcyBhYm91dCBjdXJyZW50IG5vcm1hbCBwcmFjdGljZSwg d2hpY2ggZG9lc24ndCBkbyB0aGF0LCBzbyBJIHdvdWxkbid0IGdvIGludG8gdG9vIG1hbnkgZGV0 YWlscywgd2hpY2ggSSB0aGluayBoZXJlIG1pZ2h0IGJlIGEgYml0IGRpc3RyYWN0aW5nLg0KDQoo QW5kIHRoZXJlJ3MgYSBjb2xvbiB3aXRoIGEgZm9sbG93aW5nIGNhcGl0YWwgbGV0dGVyIHRoYXQg aXNuJ3QgcmlnaHQuKQ0KDQotLSANCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNp cGFsIEVuZ2luZWVyLCBJbmZvcm1hdGlvbiBBc3N1cmFuY2UgR3JvdXANCkNvbW11bmljYXRpb25z LCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2 YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJh ZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNClRlbDogKzQ0IDEyNDUgMjQyMTk0wqB8ICBG YXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20gfCBodHRw Oi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVk DQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3Vn aCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVn aXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFVscmljaCBIZXJiZXJnDQpTZW50OiAyNyBBdWd1c3QgMjAxNCAyMzozOQ0K VG86IEhlbm5pbmcgUm9nZ2U7IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBk cmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tYW5hZ2VtZW50LXNuYXBzaG90LTAyDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVz c2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJv bSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2Fy ZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0 dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxz JyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGlj aW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkhlbm5pbmcsIENocmlzLA0KDQpJIGFtIGN1cnJlbnRs eSB3b3JraW5nIG9uIENocmlzJyByZXZpZXcuIENhbiB5b3UgcHJvcG9zZSBhIHNlbnRlbmNlIGZv ciB0aGUgbWdtdCBkcmFmdCB0aGF0IHJlZmxlY3RzIHRoaXMgYWNjdXJhdGVseT8NCg0KPiAzLjEg Y291bGQgKGFzIEhlbm5pbmcgbWlnaHQgd2VsbCBwb2ludCBvdXQpIHNheSB0aGF0IHdoaWxlIHRo ZSBtZXNzYWdlcyBhbmQgcHJvdG9jb2wgaW5zdGFudGlhdGlvbnMgYXJlIHNlcGFyYXRlLCB0aGUg bWVzc2FnZSBjb3VsZCBzaGFyZSBhIHBhY2tldC4gIFRob3VnaCB0aGVyZSBhcmUgc29tZSBpbXBs aWNhdGlvbnMgb2Ygc2F5aW5nIHNvIGluIHRlcm1zIG9mIHRoZSA1NDQ0IG11bHRpcGxleGluZyBu b3QgcXVpdGUgc3RhdGVkICBhc3N1bXB0aW9ucy4NCg0KSG93IGFib3V0IHNvbWV0aGluZyBsaWtl Og0KDQpPTEQNCkluIHBhcnRpY3VsYXIsIGFsbCByb3V0ZXJzIGluIHRoZSBzYW1lIE1BTkVUIHRv cG9sb2d5IG11c3QgYmUgcHJlLWNvbmZpZ3VyZWQgdG8gdXNlIHRoZSBzYW1lIElQIGFkZHJlc3Mg ZmFtaWx5IChJUHY0IG9yIElQdjYpLiBJbiBhIHNpbmdsZSBPTFNSdjIgdG9wb2xvZ3ksIGl0IGlz IG5vdCBwb3NzaWJsZSB0byBtaXggSVB2NCBhbmQgSVB2NiBhZGRyZXNzZXMsIG5vdGFibHkgYmVj YXVzZSBbUkZDNTQ0NF0gbWVzc2FnZXMgY2FuIGNvbnRhaW4gZWl0aGVyIElQdjQNCipvciogSVB2 NiBhZGRyZXNzZXMsIGJ1dCBub3QgYm90aCBhdCB0aGUgc2FtZSB0aW1lLiBJdCBpcywgaG93ZXZl ciwgcG9zc2libGUgdG8gcnVuIHR3byBpbnN0YW5jZXMgb2YgT0xTUnYyLCBvbmUgaW5zdGFuY2Ug Zm9yIElQdjQgYW5kIGFub3RoZXIgb25lIGZvciBJUHY2LCB3aXRoaW4gdGhlIHNhbWUgbmV0d29y ay4NCg0KTkVXDQpJbiBwYXJ0aWN1bGFyLCBhbGwgcm91dGVycyBpbiB0aGUgc2FtZSBNQU5FVCB0 b3BvbG9neSBtdXN0IGJlIHByZS1jb25maWd1cmVkIHRvIHVzZSB0aGUgc2FtZSBJUCBhZGRyZXNz IGZhbWlseSAoSVB2NCBvciBJUHY2KS4gSW4gYSBzaW5nbGUgT0xTUnYyIHRvcG9sb2d5LCBpdCBp cyBub3QgcG9zc2libGUgdG8gbWl4IElQdjQgYW5kIElQdjYgYWRkcmVzc2VzLCBub3RhYmx5IGJl Y2F1c2UgW1JGQzU0NDRdIG1lc3NhZ2VzIGNhbiBjb250YWluIGVpdGhlciBJUHY0DQoqb3IqIElQ djYgYWRkcmVzc2VzLCBidXQgbm90IGJvdGggYXQgdGhlIHNhbWUgdGltZS4gSXQgaXMsIGhvd2V2 ZXIsIHBvc3NpYmxlIHRvIHJ1biB0d28gaW5zdGFuY2VzIG9mIE9MU1J2Miwgb25lIGluc3RhbmNl IGZvciBJUHY0IGFuZCBhbm90aGVyIG9uZSBmb3IgSVB2Niwgd2l0aGluIHRoZSBzYW1lIG5ldHdv cmsuDQpJbiBnZW5lcmFsLCBbUkZDNTQ0NF0gcGFja2V0cyBtYXkgY29udGFpbiBtZXNzYWdlcyB3 aXRoIGRpZmZlcmVudCBhZGRyZXNzIGxlbmd0aHM7IGhvd2V2ZXIsIHNvbWUgcHJvdG9jb2xzIHVz aW5nIFtSRkM1NDQ0XSBtYXkgY29uc3RyYWluIHRoaXMgZnVydGhlcjogRm9yIGV4YW1wbGUsIE5I RFAgbWF5IHVzZSB0aGUgSVAgc291cmNlIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBjb250YWluaW5n IGEgSEVMTE8gbWVzc2FnZSBhcyBvcmlnaW5hdG9yIGFkZHJlc3MuDQoNCg0KVGhvdWdodHM/DQoN ClJlZ2FyZHMNClVscmljaA0KDQoNCg0KDQpPbiBGcmksIEF1ZyAyMiwgMjAxNCBhdCAxOjA1IEFN LCBIZW5uaW5nIFJvZ2dlIDxoZW5uaW5nLnJvZ2dlQGZraWUuZnJhdW5ob2Zlci5kZT4gd3JvdGU6 DQo+IE9uIDA4LzIyLzIwMTQgMDk6NDYgQU0sIENocmlzdG9waGVyIERlYXJsb3ZlIHdyb3RlOg0K Pj4gTm8sIG5vdCBxdWl0ZSB0aGUgc2FtZS4gNTQ0NCBleHBsaWNpdGx5IGRpc2N1c3NlcyBzZXBh cmF0ZSBwcm90b2NvbHMuDQo+PiBJdCBkb2Vzbid0IGV4cGxpY2l0bHkgZGlzY3VzcyBhZGRyZXNz IGxlbmd0aHMuIFRoZSA1NDQ0IG1vZGVsIGFzc3VtZXMgDQo+PiB0aGF0IGFsbCBIRUxMTyBtZXNz YWdlcyBhcmUgc2VudCB0byBhIHNpbmdsZSBlbnRpdHksIHJlZ2FyZGxlc3Mgb2YgDQo+PiBhZGRy ZXNzIHR5cGUuIChJdCBkb2Vzbid0IHNheSByZWdhcmRsZXNzIG9mIGFkZHJlc3MgdHlwZSwgaXQg anVzdCANCj4+IGRvZXNuJ3QgbWVudGlvbiBpdC4pIFRoYXQgd291bGQgYmUgTkhEUCBvZiBjb3Vy c2UuIEJ1dCB0aGUgTkhEUCANCj4+IGRlc2NyaXB0aW9uIGlzIG9mIGEgcHJvdG9jb2wgdGhhdCBo YXMgYSBjZXJ0YWluIHR5cGUgb2YgYWRkcmVzcy4gSSANCj4+IGRvbid0IHJlY2FsbCBpZiBpdCBl eHBsaWNpdGx5IHNheXMgZHJvcCBIRUxMTyBtZXNzYWdlcyB3aXRoIHdyb25nIA0KPj4gYWRkcmVz cyBsZW5ndGggb3Igbm90Lg0KPg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTMw I3NlY3Rpb24tMTIuMQ0KPg0KPiBBIHJlY2VpdmVkIEhFTExPIG1lc3NhZ2UgaXMgaW52YWxpZCBm b3IgcHJvY2Vzc2luZyBieSB0aGlzIHJvdXRlciBpZiANCj4gYW55IG9mIHRoZSBmb2xsb3dpbmcg Y29uZGl0aW9ucyBhcmUgdHJ1ZToNCj4NCj4gbyAgVGhlIGFkZHJlc3MgbGVuZ3RoIGFzIHNwZWNp ZmllZCBpbiB0aGUgTWVzc2FnZSBIZWFkZXIgaXMgbm90IGVxdWFsDQo+ICAgIHRvIHRoZSBsZW5n dGggb2YgdGhlIGFkZHJlc3NlcyB1c2VkIGJ5IHRoaXMgcm91dGVyLg0KPg0KPj4gVGhlcmUncyBu b3RoaW5nIGFjdHVhbGx5IHNwZWNpZmllZCBhbnl3aGVyZSB3aGljaCBkZXNjcmliZXMgYSBwcm9j ZXNzIA0KPj4gc29tZXRoaW5nIGxpa2UgNTQ0NCBnZXRzIEhFTExPLCBzZW5kcyB0byBOSERQLiBO SERQIGxvb2tzIGF0IGFkZHJlc3MgDQo+PiBsZW5ndGggYW5kIHNlbmRzIHRvIE5IRFAvSVB2NCBv ciBOSERQL0lQdjYgZm9yIGFkZHJlc3MgbGVuZ3RocyA0IG9yDQo+PiAxNiAoYW5kIGRyb3BzIEhF TExPIG1lc3NhZ2VzIHdpdGggb3RoZXIgbGVuZ3Rocz8pLiBIZXJlIE5IUEQvSVB2NCBhbmQNCj4+ IE5IRFAvSVB2NiBhcmUgc2VwYXJhdGUgaW5zdGFudGlhdGlvbnMgb2YgNjEzMC4gKEFuZCBkaXR0 byBmb3INCj4+IE9MU1J2Mi4pIE9mIGNvdXJzZSB0aGF0J3MgYSByZWFzb25hYmx5IG9idmlvdXMg YXBwcm9hY2gsIGp1c3Qgbm90IA0KPj4gZXhwbGljaXRseSBzcGVjaWZpZWQgYW55d2hlcmUsYmVj YXVzZSA1NDQ0IGNhbiBzYXkgaXQncyB1cCB0byB0aGUgDQo+PiBwcm90b2NvbCwgYW5kIHRoZSBw cm90b2NvbCBjYW4gc2F5IGl0J3MgcmVhbGx5IGEgbXVsdGlwbGV4aW5nIHRoaW5nLg0KPg0KPiBZ b3UgY291bGQgYXJndWUgdGhhdCBpZiB5b3Ugd2FudCB0byBkbyBhIGR1YWxzdGFjayB0aGluZywg eW91IGp1c3QgDQo+IG5lZWQgYSBzZWNvbmQgbGV2ZWwgb2YgbXVsdGlwbGV4ZXIuDQo+DQo+PiBB bmQgdGhlIGNvbW1lbnQgdGhhdCBtZXNzYWdlcyBoYXZlIG5vIGNvbnN0cmFpbnRzIG9uIHRoZSBJ UCBhZGRyZXNzIA0KPj4gdHlwZSBvZiB0aGUgc3Vycm91bmRpbmcgcGFja2V0IGlzIHRydWUgZm9y IDU0NDQuIEl0J3Mgbm90IHRydWUgZm9yIA0KPj4gTkhEUCwgd2hpY2ggdXNlcyB0aGUgSVAgZGF0 YWdyYW0gc291cmNlIGFkZHJlc3MuIFRoYXQncyBhY3R1YWxseSBhbiANCj4+IGlzc3VlIHRoYXQg YSBkdWFsIHN0YWNrIGFwcHJvYWNoIG5lZWRzIHRvIGNvdmVyLg0KPg0KPiBNeSBkcmFmdCBhbHJl YWR5IGNvdmVycyB0aGlzLCBpdCBvbmx5IGFsbG93cyBtZXNzYWdlcyB3aXRoIGEgaG9wLWxpbWl0 IA0KPiBsYXJnZXIgdGhhbiBvbmUgdG8gYmUgcHV0IGludG8gYSBVRFAvUkZDLTU0NDQgcGFja2V0 IHdpdGggYSBkaWZmZXJlbnQgDQo+IGFkZHJlc3MgbGVuZ3RoLg0KPg0KPiBIZW5uaW5nIFJvZ2dl DQo+DQo+IC0tDQo+IERpcGxvbS1JbmZvcm1hdGlrZXIgSGVubmluZyBSb2dnZSAsIEZyYXVuaG9m ZXItSW5zdGl0dXQgZsO8ciANCj4gS29tbXVuaWthdGlvbiwgSW5mb3JtYXRpb25zdmVyYXJiZWl0 dW5nIHVuZCBFcmdvbm9taWUgRktJRSANCj4gS29tbXVuaWthdGlvbnNzeXN0ZW1lIChLT00pIEZy YXVuaG9mZXIgU3RyYcOfZSAyMCwgNTMzNDMgV2FjaHRiZXJnLCANCj4gR2VybWFueQ0KPiBUZWxl Zm9uICs0OSAyMjggOTQzNS05NjEsICAgRmF4ICs0OSAyMjggOTQzNSA2ODUNCj4gbWFpbHRvOmhl bm5pbmcucm9nZ2VAZmtpZS5mcmF1bmhvZmVyLmRlIGh0dHA6Ly93d3cuZmtpZS5mcmF1bmhvZmVy LmRlDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBtYW5ldEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0 QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh bCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJv bSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkg aXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBp dHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK From nobody Thu Aug 28 12:21: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 463F31A6EF1 for ; Thu, 28 Aug 2014 12:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 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, GB_I_LETTER=-2] 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 iq8MfqatvkqF for ; Thu, 28 Aug 2014 12:21:10 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210271A017D for ; Thu, 28 Aug 2014 12:21:09 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id ij19so1398712vcb.17 for ; Thu, 28 Aug 2014 12:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gLu0PpYBC7UeAKcpM0SpZ8jNIYTTBIfPwvTHrXcDRG8=; b=G02gVh0yIAZDg7WgJkOL7hLLKJN6jy1UZIEXFOXC5eh11s9PLg33OF5mHPLFCKlxeU 4OR1kgkBmNwt3FFp9q8I6wsZOUFhm0tOdrKMBnNiqZ1DllkhEudQJWBwDAbPE8EgPPwW lxS8STGGwjeK2PYp94c3gf+RUjQok6BniBMag= 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 :content-transfer-encoding; bh=gLu0PpYBC7UeAKcpM0SpZ8jNIYTTBIfPwvTHrXcDRG8=; b=GxYrOkRXDAkgXIQQ1HHtX7drrGyRbA0JCieJ0g3x3NrT5/jkMMYz3GzpHVoUlobgde vKAd9w0BW5bO1RG9NnvSrwxYlDAMZxgRocGCmKF8KxRbG8OviOLOJ3t6fpLGI9cTJZd0 GWjyuNU8gr4LuaxljN884LGkVKVs8lcloI4mSIe0FKw6W8P2DyIfH3W2hf3GbrfNKaFX uukavzisXtA+UPT8lQ1pMUaz0lok6g+eZwvxM1V8+aT8+ZFV4wCLpWu0eb+ylBJJGo1Y 8hH15Xr3ClV6KA92KaoX8Qjv4qlKSfNjGSfxb4puXIDyUp+E3l9fiNRRojHF4Z3OeMrq 9kRQ== X-Gm-Message-State: ALoCoQnul1Hd+56OR71S9LzQQMMRJKFFuyU4G+okp+jxnfOKJG45CSn7SlkjWZ4tRpTVCtbxc8QP MIME-Version: 1.0 X-Received: by 10.53.10.65 with SMTP id dy1mr2762868vdd.92.1409253668108; Thu, 28 Aug 2014 12:21:08 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Thu, 28 Aug 2014 12:21:08 -0700 (PDT) In-Reply-To: References: <33511460-38DA-43BD-9791-21E5BC11DBA3@mnemosyne.demon.co.uk> <53F6F9C1.1080709@fkie.fraunhofer.de> Date: Thu, 28 Aug 2014 12:21:08 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tDB1m1vUC_epSmezEeI91QhxXK8 Cc: "manet@ietf.org" Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-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, 28 Aug 2014 19:21:13 -0000 Okay, that makes sense. We will revise the text accordingly. Thanks! Ulrich On Thu, Aug 28, 2014 at 1:47 AM, Dearlove, Christopher (UK) wrote: > The important thing I think is to steer a middle course. It wouldn't be r= ight to say just IPv4 or IPv6 is possible, because there is the possibility= of both. But on the other hand this document is about current normal pract= ice, which doesn't do that, so I wouldn't go into too many details, which I= think here might be a bit distracting. > > (And there's a colon with a following capital letter that isn't right.) > > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 27 August 2014 23:39 > To: Henning Rogge; manet@ietf.org > Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-02 > > ----------------------! WARNING ! ---------------------- This message ori= ginates from outside our organisation, either from an external partner or f= rom the internet. > Consider carefully whether you should click on any links, open any attach= ments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions= on reporting suspicious email messages. > -------------------------------------------------------- > > Henning, Chris, > > I am currently working on Chris' review. Can you propose a sentence for t= he mgmt draft that reflects this accurately? > >> 3.1 could (as Henning might well point out) say that while the messages = and protocol instantiations are separate, the message could share a packet.= Though there are some implications of saying so in terms of the 5444 mult= iplexing not quite stated assumptions. > > How about something like: > > OLD > In particular, all routers in the same MANET topology must be pre-configu= red to use the same IP address family (IPv4 or IPv6). In a single OLSRv2 to= pology, it is not possible to mix IPv4 and IPv6 addresses, notably because = [RFC5444] messages can contain either IPv4 > *or* IPv6 addresses, but not both at the same time. It is, however, possi= ble to run two instances of OLSRv2, one instance for IPv4 and another one f= or IPv6, within the same network. > > NEW > In particular, all routers in the same MANET topology must be pre-configu= red to use the same IP address family (IPv4 or IPv6). In a single OLSRv2 to= pology, it is not possible to mix IPv4 and IPv6 addresses, notably because = [RFC5444] messages can contain either IPv4 > *or* IPv6 addresses, but not both at the same time. It is, however, possi= ble to run two instances of OLSRv2, one instance for IPv4 and another one f= or IPv6, within the same network. > In general, [RFC5444] packets may contain messages with different address= lengths; however, some protocols using [RFC5444] may constrain this furthe= r: For example, NHDP may use the IP source address of the packet containing= a HELLO message as originator address. > > > Thoughts? > > Regards > Ulrich > > > > > On Fri, Aug 22, 2014 at 1:05 AM, Henning Rogge wrote: >> On 08/22/2014 09:46 AM, Christopher Dearlove wrote: >>> No, not quite the same. 5444 explicitly discusses separate protocols. >>> It doesn't explicitly discuss address lengths. The 5444 model assumes >>> that all HELLO messages are sent to a single entity, regardless of >>> address type. (It doesn't say regardless of address type, it just >>> doesn't mention it.) That would be NHDP of course. But the NHDP >>> description is of a protocol that has a certain type of address. I >>> don't recall if it explicitly says drop HELLO messages with wrong >>> address length or not. >> >> http://tools.ietf.org/html/rfc6130#section-12.1 >> >> A received HELLO message is invalid for processing by this router if >> any of the following conditions are true: >> >> o The address length as specified in the Message Header is not equal >> to the length of the addresses used by this router. >> >>> There's nothing actually specified anywhere which describes a process >>> something like 5444 gets HELLO, sends to NHDP. NHDP looks at address >>> length and sends to NHDP/IPv4 or NHDP/IPv6 for address lengths 4 or >>> 16 (and drops HELLO messages with other lengths?). Here NHPD/IPv4 and >>> NHDP/IPv6 are separate instantiations of 6130. (And ditto for >>> OLSRv2.) Of course that's a reasonably obvious approach, just not >>> explicitly specified anywhere,because 5444 can say it's up to the >>> protocol, and the protocol can say it's really a multiplexing thing. >> >> You could argue that if you want to do a dualstack thing, you just >> need a second level of multiplexer. >> >>> And the comment that messages have no constraints on the IP address >>> type of the surrounding packet is true for 5444. It's not true for >>> NHDP, which uses the IP datagram source address. That's actually an >>> issue that a dual stack approach needs to cover. >> >> My draft already covers this, it only allows messages with a hop-limit >> larger than one to be put into a UDP/RFC-5444 packet with a different >> address length. >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, >> Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ********************************************************************