From nobody Tue Jan 3 07:04:10 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D2E129616; Tue, 3 Jan 2017 07:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XSMikd_RanAP; Tue, 3 Jan 2017 07:04:04 -0800 (PST) Received: from isabel.astrium.eads.net (isabel.astrium.eads.net [194.62.210.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3FF1294B8; Tue, 3 Jan 2017 07:04:03 -0800 (PST) Received: from rosout.astrium.eads.net ([10.221.0.46]) by isabel.astrium.eads.net (8.14.4/8.14.4) with ESMTP id v03F3w1v009963; Tue, 3 Jan 2017 15:03:58 GMT Received: from rosout.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A473F3C8060; Tue, 3 Jan 2017 15:03:58 +0000 (GMT) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 998A93C805E; Tue, 3 Jan 2017 15:03:58 +0000 (GMT) X-IMSS-HAND-OFF-DIRECTIVE: 127.0.0.1:10026 Received: from AUK52840.UKN.UKNROOT.ASTRIUM.CORP (unknown [10.221.1.31]) by rosout.astrium.eads.net (Postfix) with ESMTPS id DF49E3C805E; Tue, 3 Jan 2017 15:03:54 +0000 (GMT) Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52840.UKN.UKNROOT.ASTRIUM.CORP ([fe80::7584:4b98:38c0:4ce7%15]) with mapi id 14.03.0301.000; Tue, 3 Jan 2017 15:03:54 +0000 From: "MATTY, Steven" To: "'Henning Rogge'" , Alexey Melnikov Thread-Topic: [manet] Alexey Melnikov's Discuss on draft-ietf-manet-dlep-26: (with DISCUSS and COMMENT) Thread-Index: AQHSVrSkSFUo7CcP10alwAWz9UhIGKEm9pCQ Date: Tue, 3 Jan 2017 15:03:53 +0000 Message-ID: References: <148156334986.22491.1152871712874859894.idtracker@ietfa.amsl.com> <79D48CEB-2CFC-43A8-8D01-5C5CB1778966@fastmail.fm> <9B802ACF-84EF-4C47-92F8-122CA724C71A@fastmail.fm> <8913_1481793738_585260CA_8913_1480_3_CAGnRvuqKEwSU0nnkufzetGGUVzPSFjNOF6wrW=CRqc=t0x4dsQ@mail.gmail.com> In-Reply-To: <8913_1481793738_585260CA_8913_1480_3_CAGnRvuqKEwSU0nnkufzetGGUVzPSFjNOF6wrW=CRqc=t0x4dsQ@mail.gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.1.73] X-TM-AS-Product-Ver: IMSVA-9.0.0.1549-8.0.0.1202-22802.000 X-TM-AS-Result: No--2.307-5.0-31-10 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-imss-scan-details: No--2.307-5.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1549-8.0.1202-22802.000 X-TMASE-Result: 10--2.306700-10.000000 X-TMASE-MatchedRID: 7ySqCuYCpfgOwH4pD14DsPHkpkyUphL9JPNIV6GF8ms5yqWxi+AoVcmq 1AoDXwwx6kKbiMDnAdujPY90dM+gdxLmJd2F/yFu94LF3uHAprQXZ6k61HUJz9/AY5O98XB+PDO wv0cUZsA7UqG0F6LDPZomP6bbNeQVj2hRzH1UwuD+xOhjarOnHmMVPzx/r2cb+gtHj7OwNO2Ohz Oa6g8KrZIAc6dLBTx6ay0LMoUOZqul39L++LkbFpVXjtvr+QTpGU26s7xDDbWxTVs1u9Nvxg7S5 c2DqtWOWYBZrXIOKn3JETaBLVCGrE5FYunfGF1oOV7VP/blKK5x44VAUUfBllfvqZH4yCCf/urc y+agieaUTGVAhB5EbQ== X-TMASE-SNAP-Result: 1.811037.0001-0-1-22:0,12:0 Archived-At: Cc: MANET IETF , The IESG , "draft-ietf-manet-dlep@ietf.org" , "manet-chairs@ietf.org" Subject: Re: [manet] Alexey Melnikov's Discuss on draft-ietf-manet-dlep-26: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 15:04:06 -0000 On 15 Dec 2016, at 09:22, Henning Rogge wrote: >On Thu, Dec 15, 2016 at 10:23 AM, Alexey Melnikov > wrote: > >>What kind of security does unauthenticated TLS provide against an >>attacker that sits on your local LAN segment? Its not that DLEP carry >>any "secret" data... > >I have spoken with a few radio vendors and from what I got none of >them considers to implement TLS. Nobody sees any advantage of it, but >everyone sees a huge cost. Cost in terms of performance (Flow control >is delay dependent), cost in terms of complexity, costs in terms of >interoperability. FWIW, I can state with some certainty that the roadmap for our DLEP implementation does NOT include support for TLS. Steve This email (including any attachments) may contain confidential and/or pr= ivileged information or information otherwise protected from disclosure. = If you are not the intended recipient, please notify the sender immediate= ly, do not copy this message or any attachments and do not use it for any= purpose or disclose its content to any person, but delete this message a= nd any attachments from your system. Airbus Defence and Space Limited dis= claims any and all liability if this email transmission was virus corrupt= ed, altered or falsified. -o- Emails to Airbus Defence and Space Limited may be processed, recorded and= monitored outside the UK. -o- Airbus Defence and Space Limited, Registered in England and Wales No. 244= 9259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, = England From peterlau@memphis.edu Tue Jan 3 09:09:54 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B151296B5 for ; Tue, 3 Jan 2017 09:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mVoF5YgCM2Rv for ; Tue, 3 Jan 2017 09:09:52 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0065.outbound.protection.outlook.com [104.47.36.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573B51296B6 for ; Tue, 3 Jan 2017 09:09:52 -0800 (PST) Received: from BLUPR0401MB1731.namprd04.prod.outlook.com (10.162.215.21) by BLUPR0401MB1732.namprd04.prod.outlook.com (10.162.215.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Tue, 3 Jan 2017 17:09:50 +0000 Received: from BLUPR0401MB1731.namprd04.prod.outlook.com ([10.162.215.21]) by BLUPR0401MB1731.namprd04.prod.outlook.com ([10.162.215.21]) with mapi id 15.01.0817.009; Tue, 3 Jan 2017 17:09:50 +0000 From: "Peter S Lau (peterlau)" To: "manet@ietf.org" Thread-Topic: A proposed draft "draft-peterlau-manet-topology-refresh" Thread-Index: AQHSZeN4eitj+utMfUKMGDE1x3UIoQ== Date: Tue, 3 Jan 2017 17:09:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=peterlau@memphis.edu; x-originating-ip: [99.43.174.101] x-ms-office365-filtering-correlation-id: 6dda1510-db84-4668-0ebe-08d433fb5425 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BLUPR0401MB1732; x-microsoft-exchange-diagnostics: 1; BLUPR0401MB1732; 7:4OMYzuCEygm8rKdoBV7cX0JY+7BWIh1Qyj2JZhBL1XiSF5cJOAupXVs5w1SoV+2i6Hc6g0+DkDCj3lFTVfBJEEStCV5NS8iEqdUwNdL6mea2sVbbAi5/4kDIWdrzEx2bsA5LYhjetIjaUdGsZnjQ1XvezVAw/Q66PZaqVlizdfRMYkN/vjwge2NEBXF54ISw0CBBXiR0jCtQe9Jfb6Thp7WXuUfeqQUml6IBiov1Qlc7aaLV/SpZDujLCUtNiXHB/4YxqNPTssbkycyUnHBryLgGdv7+TcNMoyGIu1UYbGFszbIr4uGXyaWpi+qisOgQd22CDzz1VSua2RxYMBKLfykeGEmW4GSa8E4tXKAA+4GbSUtH47FxYm6f1jxs8+N7O989nPH+/pXmR/SHQEDJ2rmjDrie69w7BhFIHPC2cXN579PTv6F8By5u1tvZORfMnMFv+uqphUPhkLqiKmDGNg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BLUPR0401MB1732; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0401MB1732; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(122556002)(54356999)(50986999)(450100001)(2351001)(19627405001)(25786008)(5640700003)(105586002)(106116001)(106356001)(230783001)(3280700002)(66066001)(3660700001)(107886002)(189998001)(6506006)(77096006)(6436002)(5660300001)(97736004)(101416001)(38730400001)(6116002)(3846002)(33656002)(102836003)(92566002)(68736007)(558084003)(2906002)(86362001)(7736002)(75432002)(74316002)(2501003)(99286003)(88552002)(110136003)(55016002)(1730700003)(8936002)(81166006)(7696004)(6606003)(9686002)(2900100001)(8676002)(81156014)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0401MB1732; H:BLUPR0401MB1731.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: memphis.edu does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0401MB1731F4A2461F01E0550CBE70C96E0BLUPR0401MB1731_" MIME-Version: 1.0 X-OriginatorOrg: memphis.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 17:09:50.6494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ae145aea-cdb2-446a-b05a-7858dde5ddba X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0401MB1732 Archived-At: Subject: [manet] A proposed draft "draft-peterlau-manet-topology-refresh" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 17:17:18 -0000 --_000_BLUPR0401MB1731F4A2461F01E0550CBE70C96E0BLUPR0401MB1731_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear manet Working Group: I have uploaded a proposed draft entitled "draft-peterlau-manet-topology-re= fresh-00". for the WG to consider. Regards, Peter Lau Peter Lau The University of Memphis Electrical and Computer Engineering --_000_BLUPR0401MB1731F4A2461F01E0550CBE70C96E0BLUPR0401MB1731_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear manet Working Group:

I have uploaded a proposed draft entitled "draft-peterlau-manet-topolo= gy-refresh-00". for the WG to consider.

Regards,
Peter Lau

Peter Lau
The University of Memphis
Electrical and Computer Engineering
--_000_BLUPR0401MB1731F4A2461F01E0550CBE70C96E0BLUPR0401MB1731_-- From nobody Wed Jan 4 01:07:46 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0BA129C79 for ; Wed, 4 Jan 2017 01:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 46mKFh10a6LL for ; Wed, 4 Jan 2017 01:07:43 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA0D129C71 for ; Wed, 4 Jan 2017 01:07:43 -0800 (PST) Received: from [192.168.1.101] (95.248.86.88.rdns.comcable.net [88.86.248.95]) by mx.zohomail.com with SMTPS id 1483520857053634.8688610695589; Wed, 4 Jan 2017 01:07:37 -0800 (PST) From: Jiazi Yi Message-Id: <97591271-9997-4245-BDED-056BE872AF8B@jiaziyi.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_914C9BE5-DCAF-468A-BD79-A1B0BEE1966A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 4 Jan 2017 10:07:33 +0100 In-Reply-To: To: "Peter S Lau (peterlau)" References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 09:07:45 -0000 --Apple-Mail=_914C9BE5-DCAF-468A-BD79-A1B0BEE1966A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Peter,=20 Thanks very much for your draft.=20 Looking at the overview section: > TRP is a table-driven proactive data forwarding protocol and at the > same time allows users to announce their presence to the network. = A > node, wishing to be contacted, periodically broadcasts control > messages about itself to the network. A node, receiving control > messages, caches an optimal path to each of the originators of the > control messages. =20 Could you please briefly introduce what=E2=80=99s the difference between = TRP and other proactive protocols like OLSR(v2)? Especially, it would be very helpful for the readers to understand by = providing a bit more text about the mechanism of the protocol in the = overview.=20 best Jiazi > On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) = wrote: >=20 > Dear manet Working Group: >=20 > I have uploaded a proposed draft entitled = "draft-peterlau-manet-topology-refresh-00". for the WG to consider. >=20 > Regards, > Peter Lau >=20 > Peter Lau > The University of Memphis > Electrical and Computer Engineering > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = --Apple-Mail=_914C9BE5-DCAF-468A-BD79-A1B0BEE1966A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Peter, 

Thanks very much for your = draft. 

Looking at the overview section:

   TRP is a = table-driven proactive data forwarding protocol and at the
   same time allows users to announce their = presence to the network.  A
   node, = wishing to be contacted, periodically broadcasts control
   messages about itself to the network.  A = node, receiving control
   messages, = caches an optimal path to each of the originators of the
   control messages.  

Could you please briefly = introduce what=E2=80=99s the difference between TRP and other proactive = protocols like OLSR(v2)?

Especially, it would be very helpful for the readers to = understand by providing a bit more text about the mechanism of the = protocol in the overview. 

best

Jiazi

On = 3 Jan 2017, at 18:09, Peter S Lau (peterlau) <peterlau@memphis.edu> wrote:

Dear manet Working = Group:

I have uploaded a proposed draft = entitled "draft-peterlau-manet-topology-refresh-00". for the WG to = consider.

Regards,
Peter = Lau

Peter Lau
The University of Memphis
Electrical and Computer = Engineering
_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

= --Apple-Mail=_914C9BE5-DCAF-468A-BD79-A1B0BEE1966A-- From nobody Wed Jan 4 02:10:20 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5BB128DF6 for ; Wed, 4 Jan 2017 02:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.019 X-Spam-Level: X-Spam-Status: No, score=-10.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 uyxNyMUuo0Rn for ; Wed, 4 Jan 2017 02:10:17 -0800 (PST) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931F712711D for ; Wed, 4 Jan 2017 02:10:16 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.33,458,1477958400"; d="scan'208,217"; a="48389624" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 04 Jan 2017 10:10:13 +0000 X-IronPort-AV: E=Sophos;i="5.33,458,1477958400"; d="scan'208,217";a="149926662" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 04 Jan 2017 10:10:13 +0000 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.144]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Wed, 4 Jan 2017 10:10:13 +0000 From: "Dearlove, Christopher (UK)" To: Jiazi Yi , "Peter S Lau (peterlau)" Thread-Topic: [manet] A proposed draft "draft-peterlau-manet-topology-refresh" Thread-Index: AQHSZeN4eitj+utMfUKMGDE1x3UIoaEoCDCAgAAKmOA= Date: Wed, 4 Jan 2017 10:10:13 +0000 Message-ID: References: <97591271-9997-4245-BDED-056BE872AF8B@jiaziyi.com> In-Reply-To: <97591271-9997-4245-BDED-056BE872AF8B@jiaziyi.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DA51A9158GLKXM0003vGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 10:10:19 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DA51A9158GLKXM0003vGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGhlcmUgc29tZSBpbW1lZGlhdGUgcmV0cm9ncmFkZSBzdGVwcyBjb21wYXJlZCB0byBleGlzdGlu ZyBwcm90b2NvbHM6IGZpeGVkIG1lc3NhZ2UgZm9ybWF0IChtYWtpbmcgYWRkaW5nIG5ldyBpbmZv cm1hdGlvbiB0byBiZSB1c2VkIGJ5IHRoZSBwcm90b2NvbCBoYXJkKSwgZm9yd2FyZGluZyBieSBi bGluZCBmbG9vZGluZyAoaGVuY2Ugc2NhbGFiaWxpdHkgaXNzdWVzKSwgYW5kIG5vIHNlY3VyaXR5 IChhbiBleGFtcGxlIG9mIHNvbWV0aGluZyB0aGF0IHRvIGFkZCB3b3VsZCByZXF1aXJlIGEgY2hh bmdlZCBmb3JtYXQpLiBUaGUgcmF0aGVyIHBlY3VsaWFyIGxpbmsgbWV0cmljIChpbiBlZmZlY3Qp IHRoYXQgbWl4ZXMgaG9wIGNvdW50LCB0aW1lIGFuZCBiYXR0ZXJ5IHBvd2VyIGxlYWRzIHRvIG1h bnkgcXVlc3Rpb25zIChhbmQgd2hpbGUgbm90IHNpbXBseSBob3AgY291bnQgaXMgbGlrZWx5IHRv IGJlIGEgYmFja3dhcmQgc3RlcCBpbiBmbGV4aWJpbGl0eSkuIFRoZXJl4oCZcyBhIHJhdGhlciB1 bnVzdWFsIG1lc3NhZ2UgYm9keSB0aGF0IGlzIG5vdCB1c2VkIGJ5IHRoaXMgcHJvdG9jb2wgYnV0 IHNhaWQgdG8gYmUgZm9yIHRoZSBhcHBsaWNhdGlvbiwgd2hpY2ggaXMgYSBiaXQgb2YgYSBsYXll cmluZyBpc3N1ZS4gR1BTIGlzIGluY2x1ZGVkIHdpdGggbm8gaW5kaWNhdGlvbiBob3cgdG8gdXNl IGFuZCBoZW5jZSBubyBpbmRpY2F0aW9uIHdoeSBpdCBpcyB0aGVyZS4gVGhleSBhcmUgYWxzbyB1 bmRlcnNwZWNpZmllZCBpbiB0ZXJtcyBvZiBmb3JtYXQgaW5mb3JtYXRpb24gKGFuZCBmb3IgR1BT IGF0IGxlYXN0IGV2ZW4gc2l6ZSBvZiBmaWVsZCkuIFRoZXJl4oCZcyBxdWl0ZSBhIGxvdCB1bmRl cnNwZWNpZmllZCwgc3VjaCBhcyByb3V0ZSBkZXRlcm1pbmF0aW9uLCBhbmQgdGhlcmXigJlzIG5v IGNvbnNpZGVyYXRpb24gb2YgaG93IHRoZSBhY2tub3dsZWRnZW1lbnRzIGFyZSB1c2VkIC0gYW5k IGV2ZW4gd2hhdCB0aGUgbWVhbmluZyBvZiBhY2tub3dsZWRnZW1lbnRzIGluIHdoYXQgbXVzdCBi ZSAoYnV0IGlzIG5vdCBzbyBkZXNjcmliZWQpIGFzIGEgbG9jYWwgYnJvYWRjYXN0L211bHRpY2Fz dCBtZXNzYWdlICh3aXRoIHBvdGVudGlhbGx5IHVua25vd24gcmVjaXBpZW50cykuIEkgZG9u4oCZ dCBzZWUgYW55IGhhbmRsaW5nIG9mIHRoZSBwcm9ibGVtcyB0aGF0IGxpbmsgYXN5bW1ldHJ5IHBy b2R1Y2VzLiBJ4oCZZCBoYXZlIGlzc3VlcyBvdmVyIHRpbWluZyBwYXJhbWV0ZXJzIGFuZCB0aGVp ciBtYW5hZ2VtZW50ICh0aGVzZSBiZWluZyBub3QgcmVmbGVjdGVkIGluIHRoZSBtZXNzYWdlKS4g QW5kIGluIGEgcHJvcG9zZWQgSUVURiBwcm90b2NvbCwgSSBkb27igJl0IHNlZSBhbnkgSVAgYWRk cmVzc2VzLiBUaGF0IGl0IGhhc27igJl0IGV2ZW4gY2F1Z2h0IHVwIHdpdGggdGhlIGV4aXN0ZW5j ZSBvZiBSRkMgNzE4MSAob25seSBxdW90aW5nIFJGQyAzNjI2KSBpcyBub3QgYSBnb29kIHNpZ24u IEl0IGlzIHN1Z2dlc3RlZCB0aGF0IFJGQyAzNjI2IChhbmQgaGVuY2UsIG5vIGRvdWJ0LCBSRkMg NzE4MSkgaXMgdG9vIGNvbXBsZXguIFRoYXQgbWF5IG9yIG1heSBub3QgYmUgc28gKHRoZXJlIGFy ZSByZWFzb25zIGZvciB0aGUgYWRkZWQgY29tcGxleGl0eSBpbiBSRkMgNzE4MSwgd2hpY2ggbmVl ZCB0byBiZSB1bmRlcnN0b29kIGJlZm9yZSBkZWNpZGluZyB3aGV0aGVyIHlvdSBuZWVkIHRoZW0p IGFuZCB0aGVyZSB0aHVzIG1heSBvciBtYXkgbm90IGJlIGEgc3BhY2UgZm9yIGEgbGlnaHR3ZWln aHQgcHJvYWN0aXZlIHByb3RvY29sLCBidXQgdGhpcyBpcyBub3QgdGhhdCBwcm90b2NvbCBpbiBj dXJyZW50IG9yIGZvcmVzZWVhYmxlIGV2b2x1dGlvbmFyeSBmb3JtLg0KDQotLQ0KQ2hyaXN0b3Bo ZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0 NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFp bHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywg Q2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8v d3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Ug TGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdp c3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBH VTIgN1lQDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEppYXppIFlpDQpTZW50OiAwNCBKYW51YXJ5IDIwMTcgMDk6MDgNClRvOiBQZXRl ciBTIExhdSAocGV0ZXJsYXUpDQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFu ZXRdIEEgcHJvcG9zZWQgZHJhZnQgImRyYWZ0LXBldGVybGF1LW1hbmV0LXRvcG9sb2d5LXJlZnJl c2giDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91 dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBv ciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNs aWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5m b3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGlu IGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vd3Mtc2l0ZXMuZW50LmJhZXN5 c3RlbXMuY29tL3NpdGVzL0hPU0VDU3Rkc0xpYnJhcnkvU3RhbmRhcmRzTGlicmFyeS9FdmVyeW9u ZS9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMs IHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly93cy1zaXRlcy5lbnQuYmFlc3lzdGVt cy5jb20vc2l0ZXMvSE9TRUNTdGRzTGlicmFyeS9TdGFuZGFyZHNMaWJyYXJ5L0V2ZXJ5b25lL0Rl YWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KKioqIFdBUk5JTkcgKioq DQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUg b3VyIG9yZ2FuaXphdGlvbi4NCg0KRGVhciBQZXRlciwNCg0KVGhhbmtzIHZlcnkgbXVjaCBmb3Ig eW91ciBkcmFmdC4NCg0KTG9va2luZyBhdCB0aGUgb3ZlcnZpZXcgc2VjdGlvbjoNCg0KICAgVFJQ IGlzIGEgdGFibGUtZHJpdmVuIHByb2FjdGl2ZSBkYXRhIGZvcndhcmRpbmcgcHJvdG9jb2wgYW5k IGF0IHRoZQ0KICAgc2FtZSB0aW1lIGFsbG93cyB1c2VycyB0byBhbm5vdW5jZSB0aGVpciBwcmVz ZW5jZSB0byB0aGUgbmV0d29yay4gIEENCiAgIG5vZGUsIHdpc2hpbmcgdG8gYmUgY29udGFjdGVk LCBwZXJpb2RpY2FsbHkgYnJvYWRjYXN0cyBjb250cm9sDQogICBtZXNzYWdlcyBhYm91dCBpdHNl bGYgdG8gdGhlIG5ldHdvcmsuICBBIG5vZGUsIHJlY2VpdmluZyBjb250cm9sDQogICBtZXNzYWdl cywgY2FjaGVzIGFuIG9wdGltYWwgcGF0aCB0byBlYWNoIG9mIHRoZSBvcmlnaW5hdG9ycyBvZiB0 aGUNCiAgIGNvbnRyb2wgbWVzc2FnZXMuDQoNCkNvdWxkIHlvdSBwbGVhc2UgYnJpZWZseSBpbnRy b2R1Y2Ugd2hhdOKAmXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBUUlAgYW5kIG90aGVyIHByb2Fj dGl2ZSBwcm90b2NvbHMgbGlrZSBPTFNSKHYyKT8NCg0KRXNwZWNpYWxseSwgaXQgd291bGQgYmUg dmVyeSBoZWxwZnVsIGZvciB0aGUgcmVhZGVycyB0byB1bmRlcnN0YW5kIGJ5IHByb3ZpZGluZyBh IGJpdCBtb3JlIHRleHQgYWJvdXQgdGhlIG1lY2hhbmlzbSBvZiB0aGUgcHJvdG9jb2wgaW4gdGhl IG92ZXJ2aWV3Lg0KDQpiZXN0DQoNCkppYXppDQoNCk9uIDMgSmFuIDIwMTcsIGF0IDE4OjA5LCBQ ZXRlciBTIExhdSAocGV0ZXJsYXUpIDxwZXRlcmxhdUBtZW1waGlzLmVkdTxtYWlsdG86cGV0ZXJs YXVAbWVtcGhpcy5lZHU+PiB3cm90ZToNCg0KRGVhciBtYW5ldCBXb3JraW5nIEdyb3VwOg0KDQpJ IGhhdmUgdXBsb2FkZWQgYSBwcm9wb3NlZCBkcmFmdCBlbnRpdGxlZCAiZHJhZnQtcGV0ZXJsYXUt bWFuZXQtdG9wb2xvZ3ktcmVmcmVzaC0wMCIuIGZvciB0aGUgV0cgdG8gY29uc2lkZXIuDQoNClJl Z2FyZHMsDQpQZXRlciBMYXUNCg0KUGV0ZXIgTGF1DQpUaGUgVW5pdmVyc2l0eSBvZiBNZW1waGlz DQpFbGVjdHJpY2FsIGFuZCBDb21wdXRlciBFbmdpbmVlcmluZw0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRA aWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tYW5ldA0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBp ZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5k ZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3Ig ZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioK --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DA51A9158GLKXM0003vGREEN_ 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 Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoZXJlIHNvbWUgaW1tZWRpYXRlIHJldHJvZ3JhZGUgc3RlcHMgY29tcGFyZWQgdG8gZXhp c3RpbmcgcHJvdG9jb2xzOiBmaXhlZCBtZXNzYWdlIGZvcm1hdCAobWFraW5nIGFkZGluZyBuZXcg aW5mb3JtYXRpb24gdG8gYmUgdXNlZCBieSB0aGUgcHJvdG9jb2wgaGFyZCksDQogZm9yd2FyZGlu ZyBieSBibGluZCBmbG9vZGluZyAoaGVuY2Ugc2NhbGFiaWxpdHkgaXNzdWVzKSwgYW5kIG5vIHNl Y3VyaXR5IChhbiBleGFtcGxlIG9mIHNvbWV0aGluZyB0aGF0IHRvIGFkZCB3b3VsZCByZXF1aXJl IGEgY2hhbmdlZCBmb3JtYXQpLiBUaGUgcmF0aGVyIHBlY3VsaWFyIGxpbmsgbWV0cmljIChpbiBl ZmZlY3QpIHRoYXQgbWl4ZXMgaG9wIGNvdW50LCB0aW1lIGFuZCBiYXR0ZXJ5IHBvd2VyIGxlYWRz IHRvIG1hbnkgcXVlc3Rpb25zDQogKGFuZCB3aGlsZSBub3Qgc2ltcGx5IGhvcCBjb3VudCBpcyBs aWtlbHkgdG8gYmUgYSBiYWNrd2FyZCBzdGVwIGluIGZsZXhpYmlsaXR5KS4gVGhlcmXigJlzIGEg cmF0aGVyIHVudXN1YWwgbWVzc2FnZSBib2R5IHRoYXQgaXMgbm90IHVzZWQgYnkgdGhpcyBwcm90 b2NvbCBidXQgc2FpZCB0byBiZSBmb3IgdGhlIGFwcGxpY2F0aW9uLCB3aGljaCBpcyBhIGJpdCBv ZiBhIGxheWVyaW5nIGlzc3VlLiBHUFMgaXMgaW5jbHVkZWQgd2l0aCBubyBpbmRpY2F0aW9uDQog aG93IHRvIHVzZSBhbmQgaGVuY2Ugbm8gaW5kaWNhdGlvbiB3aHkgaXQgaXMgdGhlcmUuIFRoZXkg YXJlIGFsc28gdW5kZXJzcGVjaWZpZWQgaW4gdGVybXMgb2YgZm9ybWF0IGluZm9ybWF0aW9uIChh bmQgZm9yIEdQUyBhdCBsZWFzdCBldmVuIHNpemUgb2YgZmllbGQpLiBUaGVyZeKAmXMgcXVpdGUg YSBsb3QgdW5kZXJzcGVjaWZpZWQsIHN1Y2ggYXMgcm91dGUgZGV0ZXJtaW5hdGlvbiwgYW5kIHRo ZXJl4oCZcyBubyBjb25zaWRlcmF0aW9uIG9mIGhvdw0KIHRoZSBhY2tub3dsZWRnZW1lbnRzIGFy ZSB1c2VkIC0gYW5kIGV2ZW4gd2hhdCB0aGUgbWVhbmluZyBvZiBhY2tub3dsZWRnZW1lbnRzIGlu IHdoYXQgbXVzdCBiZSAoYnV0IGlzIG5vdCBzbyBkZXNjcmliZWQpIGFzIGEgbG9jYWwgYnJvYWRj YXN0L211bHRpY2FzdCBtZXNzYWdlICh3aXRoIHBvdGVudGlhbGx5IHVua25vd24gcmVjaXBpZW50 cykuIEkgZG9u4oCZdCBzZWUgYW55IGhhbmRsaW5nIG9mIHRoZSBwcm9ibGVtcyB0aGF0IGxpbmsg YXN5bW1ldHJ5DQogcHJvZHVjZXMuIEnigJlkIGhhdmUgaXNzdWVzIG92ZXIgdGltaW5nIHBhcmFt ZXRlcnMgYW5kIHRoZWlyIG1hbmFnZW1lbnQgKHRoZXNlIGJlaW5nIG5vdCByZWZsZWN0ZWQgaW4g dGhlIG1lc3NhZ2UpLiBBbmQgaW4gYSBwcm9wb3NlZCBJRVRGIHByb3RvY29sLCBJIGRvbuKAmXQg c2VlIGFueSBJUCBhZGRyZXNzZXMuIFRoYXQgaXQgaGFzbuKAmXQgZXZlbiBjYXVnaHQgdXAgd2l0 aCB0aGUgZXhpc3RlbmNlIG9mIFJGQyA3MTgxIChvbmx5IHF1b3RpbmcgUkZDDQogMzYyNikgaXMg bm90IGEgZ29vZCBzaWduLiBJdCBpcyBzdWdnZXN0ZWQgdGhhdCBSRkMgMzYyNiAoYW5kIGhlbmNl LCBubyBkb3VidCwgUkZDIDcxODEpIGlzIHRvbyBjb21wbGV4LiBUaGF0IG1heSBvciBtYXkgbm90 IGJlIHNvICh0aGVyZSBhcmUgcmVhc29ucyBmb3IgdGhlIGFkZGVkIGNvbXBsZXhpdHkgaW4gUkZD IDcxODEsIHdoaWNoIG5lZWQgdG8gYmUgdW5kZXJzdG9vZCBiZWZvcmUgZGVjaWRpbmcgd2hldGhl ciB5b3UgbmVlZCB0aGVtKSBhbmQNCiB0aGVyZSB0aHVzIG1heSBvciBtYXkgbm90IGJlIGEgc3Bh Y2UgZm9yIGEgbGlnaHR3ZWlnaHQgcHJvYWN0aXZlIHByb3RvY29sLCBidXQgdGhpcyBpcyBub3Qg dGhhdCBwcm90b2NvbCBpbiBjdXJyZW50IG9yIGZvcmVzZWVhYmxlIGV2b2x1dGlvbmFyeSBmb3Jt LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpw PjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdF N0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxi cj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwv c3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3 RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6 DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENo ZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4 IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNw YW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl bmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAx MzM3NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNB OEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQs IFN1cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkppYXppIFlpPGJyPg0KPGI+U2VudDo8L2I+IDA0IEphbnVhcnkgMjAx NyAwOTowODxicj4NCjxiPlRvOjwvYj4gUGV0ZXIgUyBMYXUgKHBldGVybGF1KTxicj4NCjxiPkNj OjwvYj4gbWFuZXRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gQSBw cm9wb3NlZCBkcmFmdCAmcXVvdDtkcmFmdC1wZXRlcmxhdS1tYW5ldC10b3BvbG9neS1yZWZyZXNo JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlk IGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9 InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+ PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3Jv dW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIi PlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBl aXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9l bT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBh bnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4N CjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwv c3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+ UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91 IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL3dzLXNpdGVzLmVudC5iYWVzeXN0ZW1z LmNvbS9zaXRlcy9IT1NFQ1N0ZHNMaWJyYXJ5L1N0YW5kYXJkc0xpYnJhcnkvRXZlcnlvbmUvUmVk JTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0 aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL3dz LXNpdGVzLmVudC5iYWVzeXN0ZW1zLmNvbS9zaXRlcy9IT1NFQ1N0ZHNMaWJyYXJ5L1N0YW5kYXJk c0xpYnJhcnkvRXZlcnlvbmUvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBk ZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6MS4wcHQgNC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qPHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+KioNCjwvc3Bhbj48L3N0cm9uZz48L3NwYW4+PHN0cm9uZz48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5XQVJOSU5HDQo8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+KioqPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVz c2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIFBldGVyLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgdmVyeSBtdWNoIGZvciB5 b3VyIGRyYWZ0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Mb29raW5nIGF0IHRoZSBvdmVydmlldyBzZWN0aW9uOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7VFJQIGlzIGEgdGFibGUtZHJpdmVuIHByb2FjdGl2ZSBkYXRhIGZvcndhcmRpbmcg cHJvdG9jb2wgYW5kIGF0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3NhbWUgdGltZSBhbGxvd3MgdXNlcnMgdG8gYW5u b3VuY2UgdGhlaXIgcHJlc2VuY2UgdG8gdGhlIG5ldHdvcmsuICZuYnNwO0E8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtub2Rl LCB3aXNoaW5nIHRvIGJlIGNvbnRhY3RlZCwgcGVyaW9kaWNhbGx5IGJyb2FkY2FzdHMgY29udHJv bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwO21lc3NhZ2VzIGFib3V0IGl0c2VsZiB0byB0aGUgbmV0d29yay4gJm5ic3A7QSBu b2RlLCByZWNlaXZpbmcgY29udHJvbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO21lc3NhZ2VzLCBjYWNoZXMgYW4gb3B0aW1h bCBwYXRoIHRvIGVhY2ggb2YgdGhlIG9yaWdpbmF0b3JzIG9mIHRoZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2NvbnRyb2wg bWVzc2FnZXMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db3VsZCB5b3UgcGxlYXNlIGJyaWVmbHkgaW50 cm9kdWNlIHdoYXTigJlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gVFJQIGFuZCBvdGhlciBwcm9h Y3RpdmUgcHJvdG9jb2xzIGxpa2UgT0xTUih2Mik/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RXNwZWNpYWxseSwgaXQgd291bGQgYmUgdmVyeSBoZWxwZnVs IGZvciB0aGUgcmVhZGVycyB0byB1bmRlcnN0YW5kIGJ5IHByb3ZpZGluZyBhIGJpdCBtb3JlIHRl eHQgYWJvdXQgdGhlIG1lY2hhbmlzbSBvZiB0aGUgcHJvdG9jb2wgaW4gdGhlIG92ZXJ2aWV3LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5iZXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkppYXppPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIDMgSmFuIDIwMTcsIGF0IDE4OjA5LCBQZXRlciBTIExhdSAocGV0ZXJsYXUpICZsdDs8YSBo cmVmPSJtYWlsdG86cGV0ZXJsYXVAbWVtcGhpcy5lZHUiPnBldGVybGF1QG1lbXBoaXMuZWR1PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFw cGVyIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZWFyIG1hbmV0 IFdvcmtpbmcgR3JvdXA6PGJyPg0KPGJyPg0KSSBoYXZlIHVwbG9hZGVkIGEgcHJvcG9zZWQgZHJh ZnQgZW50aXRsZWQgJnF1b3Q7ZHJhZnQtcGV0ZXJsYXUtbWFuZXQtdG9wb2xvZ3ktcmVmcmVzaC0w MCZxdW90Oy4gZm9yIHRoZSBXRyB0byBjb25zaWRlci48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4N ClBldGVyIExhdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBpZD0i U2lnbmF0dXJlIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5QZXRlciBMYXU8YnI+DQpUaGUgVW5pdmVyc2l0eSBvZiBNZW1w aGlzPGJyPg0KRWxlY3RyaWNhbCBhbmQgQ29tcHV0ZXIgRW5naW5lZXJpbmc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0K PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+bWFuZXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21hbmV0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHA+KioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+ClRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRl ZDxicj4KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBz eXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4KWW91IHNob3VsZCBub3QgY29weSBpdCBv ciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4KZGlzdHJpYnV0ZSBp dHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+CioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9wPjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DA51A9158GLKXM0003vGREEN_-- From nobody Wed Jan 4 07:47:04 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2806B1295E3 for ; Wed, 4 Jan 2017 07:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG0FPfpbdDXV for ; Wed, 4 Jan 2017 07:46:54 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 EF51E1295CD for ; Wed, 4 Jan 2017 07:46:44 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id y197so140114474vky.2 for ; Wed, 04 Jan 2017 07:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=niDiV5kQefP/HK/HX/NtLneemszMRxP2RLQ6TPcXwuI=; b=BG9b3w5YUajKzlLwkZcM6BvHxeNT/kbbZMMNV7aflimDqEim2Puvvmj9D/9svDnPo9 qmjd/yaLCsyhuyDBIrcyHR3SRBsfVaLEeLbypYYbY597ItDUYH+4HUgPIVSNurSozDAs nq2Y0gBAnZsyltflcRl7qTEDzRBfEUtl5bV+27h3H92Yohdbhc5HL4ikySgAOGHBxG5C kIQp/PHbAwBHJJN79RCH6xB0m1Hh7vczeIbTMoucd5OefIT5ff/VmlMzVNTozMVIOFeV 755uRRSVjND2rQvdfO0rpBK2/ZAGYKPZmnmeTcmofSfcRuDtNfEhzXbmXzCxZPaeQhas p/TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=niDiV5kQefP/HK/HX/NtLneemszMRxP2RLQ6TPcXwuI=; b=MLnGPenHmrR75RVrqewU4OsC35gwxMWlHuhl2gW4HQXhIXP2WCXh8qcci94mY1daER WxiMUeQ0d9mqIwxjJ4SB+ViQPyR5akYD2k+zLMVOWLrWEbQqX8QvT1hM6o3Xj+uu3B+K XqXQ0h4BajZ4l4XRhewhF9xDmTebkXtkH67m0HAuFw1YEts1xtGwpLQvzrJfG5Vve3zE ketxHeFvK4D7436VBkB2mwhfuunywHccQvBoQd/okDTx5YLSFDpxvEZP9Se6U68mSI4Q iEykis8trntAcimMiFQ+2sFI3KZqf56dIGdkd2DEvPmcf5zi3NofnycYM3uokg0OOfxY BD3Q== X-Gm-Message-State: AIkVDXKEs+6PRolRefXA3X60emcT9AAP832c3si25NZpgPQpyrj2gWrplo9Tku3HdvnfKkH4UYI7fyLOS+0TuA== X-Received: by 10.31.86.132 with SMTP id k126mr23852197vkb.8.1483544804021; Wed, 04 Jan 2017 07:46:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.140.76 with HTTP; Wed, 4 Jan 2017 07:46:43 -0800 (PST) In-Reply-To: References: <97591271-9997-4245-BDED-056BE872AF8B@jiaziyi.com> From: Justin Dean Date: Wed, 4 Jan 2017 10:46:43 -0500 Message-ID: To: "Peter S Lau (peterlau)" Content-Type: multipart/alternative; boundary=001a114e63c20d5b19054546b12c Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 15:46:57 -0000 --001a114e63c20d5b19054546b12c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for the submission. I too have some misgivings about the documents current state and tradeoffs with regard to packet format and lack of use of the Manet building blocks which seem like they could be easily incorporated. RFC5444 has Hop-limit/count and sequence number fields, and NHDP (RFC6130) has neighbor discovery and fixes the bidirectional problem. In addition to the other security pieces and leveraging of CDS algorithms found in either SMF or OLSRv2 one could build a similar protocol with only the addition of a message type and a few TLVS. The two that jump out at me for being useful beyond just this proposed protocol would be GPS and Application/Higher Layer ID TLV encodings. Justin Dean On Wed, Jan 4, 2017 at 5:10 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > There some immediate retrograde steps compared to existing protocols: > fixed message format (making adding new information to be used by the > protocol hard), forwarding by blind flooding (hence scalability issues), > and no security (an example of something that to add would require a > changed format). The rather peculiar link metric (in effect) that mixes h= op > count, time and battery power leads to many questions (and while not simp= ly > hop count is likely to be a backward step in flexibility). There=E2=80=99= s a rather > unusual message body that is not used by this protocol but said to be for > the application, which is a bit of a layering issue. GPS is included with > no indication how to use and hence no indication why it is there. They ar= e > also underspecified in terms of format information (and for GPS at least > even size of field). There=E2=80=99s quite a lot underspecified, such as = route > determination, and there=E2=80=99s no consideration of how the acknowledg= ements are > used - and even what the meaning of acknowledgements in what must be (but > is not so described) as a local broadcast/multicast message (with > potentially unknown recipients). I don=E2=80=99t see any handling of the = problems > that link asymmetry produces. I=E2=80=99d have issues over timing paramet= ers and > their management (these being not reflected in the message). And in a > proposed IETF protocol, I don=E2=80=99t see any IP addresses. That it has= n=E2=80=99t even > caught up with the existence of RFC 7181 (only quoting RFC 3626) is not a > good sign. It is suggested that RFC 3626 (and hence, no doubt, RFC 7181) = is > too complex. That may or may not be so (there are reasons for the added > complexity in RFC 7181, which need to be understood before deciding wheth= er > you need them) and there thus may or may not be a space for a lightweight > proactive protocol, but this is not that protocol in current or foreseeab= le > evolutionary form. > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 <+44%201245%20242194> | *E: * > chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Jiazi Yi > *Sent:* 04 January 2017 09:08 > *To:* Peter S Lau (peterlau) > *Cc:* manet@ietf.org > *Subject:* Re: [manet] A proposed draft "draft-peterlau-manet- > topology-refresh" > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > **** **WARNING ****** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > Dear Peter, > > > > Thanks very much for your draft. > > > > Looking at the overview section: > > > > TRP is a table-driven proactive data forwarding protocol and at the > > same time allows users to announce their presence to the network. A > > node, wishing to be contacted, periodically broadcasts control > > messages about itself to the network. A node, receiving control > > messages, caches an optimal path to each of the originators of the > > control messages. > > > > Could you please briefly introduce what=E2=80=99s the difference between = TRP and > other proactive protocols like OLSR(v2)? > > > > Especially, it would be very helpful for the readers to understand by > providing a bit more text about the mechanism of the protocol in the > overview. > > > > best > > > > Jiazi > > > > On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) > wrote: > > > > Dear manet Working Group: > > I have uploaded a proposed draft entitled "draft-peterlau-manet-topology-= refresh-00". > for the WG to consider. > > Regards, > Peter Lau > > > > Peter Lau > The University of Memphis > Electrical and Computer Engineering > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a114e63c20d5b19054546b12c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the submission. I too have some misgivings a= bout the documents current state and tradeoffs with regard to packet format= and lack of use of the Manet building blocks which seem like they could be= easily incorporated. RFC5444 has Hop-limit/count and sequence number field= s, and NHDP (RFC6130) has neighbor discovery and fixes the bidirectional pr= oblem. In addition to the other security pieces and leveraging of CDS algor= ithms found in either SMF or OLSRv2 one could build a similar protocol with= only the addition of a message type and a few TLVS. The two that jump out = at me for being useful beyond just this proposed protocol would be GPS and = Application/Higher Layer ID TLV encodings.

Justin Dean

On Wed,= Jan 4, 2017 at 5:10 AM, Dearlove, Christopher (UK) <<= a href=3D"mailto:chris.dearlove@baesystems.com" target=3D"_blank">chris.dea= rlove@baesystems.com> wrote:

There some immediate retr= ograde steps compared to existing protocols: fixed message format (making a= dding new information to be used by the protocol hard), forwarding by blind flooding (hence scalability issues), and no security (= an example of something that to add would require a changed format). The ra= ther peculiar link metric (in effect) that mixes hop count, time and batter= y power leads to many questions (and while not simply hop count is likely to be a backward step in flexibi= lity). There=E2=80=99s a rather unusual message body that is not used by th= is protocol but said to be for the application, which is a bit of a layerin= g issue. GPS is included with no indication how to use and hence no indication why it is there. They are also underspe= cified in terms of format information (and for GPS at least even size of fi= eld). There=E2=80=99s quite a lot underspecified, such as route determinati= on, and there=E2=80=99s no consideration of how the acknowledgements are used - and even what the meaning of acknowledgeme= nts in what must be (but is not so described) as a local broadcast/multicas= t message (with potentially unknown recipients). I don=E2=80=99t see any ha= ndling of the problems that link asymmetry produces. I=E2=80=99d have issues over timing parameters and their managem= ent (these being not reflected in the message). And in a proposed IETF prot= ocol, I don=E2=80=99t see any IP addresses. That it hasn=E2=80=99t even cau= ght up with the existence of RFC 7181 (only quoting RFC 3626) is not a good sign. It is suggested that RFC 3626 (and hence, no dou= bt, RFC 7181) is too complex. That may or may not be so (there are reasons = for the added complexity in RFC 7181, which need to be understood before de= ciding whether you need them) and there thus may or may not be a space for a lightweight proactive protocol,= but this is not that protocol in current or foreseeable evolutionary form.=

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
_______________________________= ___________________________________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi Yi
Sent: 04 January 2017 09:08
To: Peter S Lau (peterlau)
Cc: manet@ietf.o= rg
Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"

=C2=A0

=C2=A0

*** WARNING ***<= /b>

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.=

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside ou= r organization.

=C2=A0

Dear Peter,=C2=A0

=C2=A0

Thanks very much for your draft.=C2=A0=

=C2=A0

Looking at the overview section:

=C2=A0

=C2=A0 =C2=A0TRP is a table-driven proactive data fo= rwarding protocol and at the

=C2=A0 =C2=A0same time allows users to announce thei= r presence to the network. =C2=A0A

=C2=A0 =C2=A0node, wishing to be contacted, periodic= ally broadcasts control

=C2=A0 =C2=A0messages about itself to the network.= =C2=A0 A node, receiving control

=C2=A0 =C2=A0messages, caches an optimal path to eac= h of the originators of the

=C2=A0 =C2=A0control messages. =C2=A0<= /p>

=C2=A0

Could you please briefly introduce what=E2=80=99s th= e difference between TRP and other proactive protocols like OLSR(v2)?

=C2=A0

Especially, it would be very helpful for the readers= to understand by providing a bit more text about the mechanism of the prot= ocol in the overview.=C2=A0

=C2=A0

best

=C2=A0

Jiazi

=C2=A0

On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) <= peterlau@memphis.= edu> wrote:

=C2=A0

Dear manet Working Group:

I have uploaded a proposed draft entitled "draft-peterlau-manet-t= opology-refresh-00". for the WG to consider.

Regards,
Peter Lau

=C2=A0

Peter Lau
The University of Memphis
Electrical and Computer Engineering

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

=C2=A0

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


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


--001a114e63c20d5b19054546b12c-- From nobody Wed Jan 4 13:36:20 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EAF129A82; Wed, 4 Jan 2017 13:36:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148356577913.12984.10765616917681899932.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 13:36:19 -0800 Archived-At: Cc: manet-chairs@ietf.org, manet@ietf.org, draft-ietf-manet-olsrv2-sec-threats@ietf.org Subject: [manet] Spencer Dawkins' Yes on draft-ietf-manet-olsrv2-sec-threats-03: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 21:36:19 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-manet-olsrv2-sec-threats-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm no expert on OLSRv2, and this may be the clearest security threats doc I've seen. Thanks for that! From nobody Wed Jan 4 19:13:29 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FE512987C; Wed, 4 Jan 2017 19:13:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148358600785.13006.4415679112806345898.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 19:13:27 -0800 Archived-At: Cc: manet-chairs@ietf.org, manet@ietf.org, draft-ietf-manet-olsrv2-sec-threats@ietf.org Subject: [manet] Kathleen Moriarty's No Objection on draft-ietf-manet-olsrv2-sec-threats-03: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 03:13:28 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-manet-olsrv2-sec-threats-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The SecDir reviewer makes a good point on the draft not covering delays and that replay mechanisms will defend against the attack described in different ways. The review is linked off the draft. Please ket me know if there is a reason to not add this threat or if you have text to propose to address it. Full review: https://www.ietf.org/mail-archive/web/secdir/current/msg07028.html Relevant section for convenience: "One issue that I did not see discussed in the draft would be for the attacker to effectively delay packets. For example, the attacker captures packets while jamming to prevent some stations from receiving packets. The attacker can collect a sequence of traffic and replay at a later time, with different timing and in a different location. Not all replay mechanisms will defend against this attack int he same way. Sequence number validation (which appears to be allowed in 7183) may not be as effective as timestamps, depending upon the time skew allowed. The document does discuss timestamps , but I think it should probably make the following clearer: There are several places in sections 4 and 5 where the document says something like "This kind of attack can be mitigated using integrity check mechanisms". I think in most of these instances replay protection is also important. One solution would be to remove these instances and just relay on section 6.2 which has a better description of the available protections. Since it seems that the integrity check could be deployed with just sequence number instead of timestamps it might be good to mention that it is important to include and verify timestamps for replay protection." From nobody Thu Jan 5 00:34:51 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBDC129438; Thu, 5 Jan 2017 00:34:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148360528696.20579.6013305676126157111.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 00:34:46 -0800 Archived-At: Cc: draft-ietf-manet-olsrv2-sec-threats@ietf.org, manet-chairs@ietf.org, manet@ietf.org, victor@jvknet.com Subject: [manet] Benoit Claise's No Objection on draft-ietf-manet-olsrv2-sec-threats-03: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 08:34:47 -0000 Benoit Claise has entered the following ballot position for draft-ietf-manet-olsrv2-sec-threats-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Below is cut/pasted Victor Kuarsingh's OPS DIR review. Summary: The document analyzes currently assessed (known) security threats for the OLSRv2 protocol and how these threats may impact a Mobile Ad Hoc Network (MANET). The document points to reference documents such as RFC7186, RFC7183, RFC7188 and RFC7181 and expands on the explanation of security vulnerabilities and how such vulnerabilities can be mitigated by currently documented security mechanisms. Text updates (suggestions / recommendations) are provided below the general feedback. General Comments and Feedback: Overall the document does cover the intention described per the abstract (summarized above). Descriptions of the vulnerabilities seem consistent with documents such as RFC7186 and RFC8183 which already cover detailed explanation of similar material. A few comments are noted in the in-line text overview below (some NITs / suggestions on wording), and a preference for avoiding such conventions which use taxonomy like "fresh", "lie" with preference for other options like "recent", "incorrect/ erroneous " may be better suited for such a document. Given this document is attempting to provide a incremental analysis of the security threats vs. how such threats fair with known security mechanisms in place, I would recommend that the a slight incremental bit of text (in-line or separate table) to show which mechanisms are purely related to implementation level protection (i.e. software written to enable protocol function) vs. deployment level options. It appears most of the protections are implementation level, but there seems to (at least) two examples of mitigations which may be deployment level (e.g. it was noted about IP forwarding on Linux boxes as well as wormholes which create [potentially undesirable] direct comm paths between participating nodes.). I think noting surveillance related activity for compromised hosts may also be useful to discuss in section 6 (hard to detect, but a potential threat). Other then that, I find the document useful as an analysis which discusses how the known threats are potentially mitigated by known mitigations. There are a few more editing items that can be found, but that can be addressed by the RFC editor. Section Review of - Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2) Abstract - ok Introduction 1. P2 operating with the assumption, that participants can be "trusted" to behave in a non-destructive way, is utopia. operating with the assumption, that participants can be "trusted" to behave in a non-destructive way, is utopian. P4 A first step towards hardening against attacks disrupting the connectivity of a network, is to understand the vulnerabilities of routing protocol, A first step towards hardening against attacks disrupting the connectivity of a network, is to understand the vulnerabilities of the routing protocol, 1.1. OSLRv2 Overview P1 They are described in the below with sufficient.. They are described in the sections below with sufficient.. 1.1.1. Neighbour Discovery Good 1.1.2 MPR Selection Good 1.2 Link State Advertisement OK 1.3 OLSRv2 Attack Vectors ** use of honestly, lie, etc **. 2. Terminology ** for compromised router, it’s possible that only surveillance is the goal (may not actually send erroneous or incorrect information) ** . This may not be detectable, but dangerous none-the-less. 3. Topology Map Acquisition OK 3.1 Attack on Jittering OK 3.2 Hop-Count and Hop-limit Attacks OK 3.2.1 Modifying the Hop Limit OK 3.2.2 Modifying the Hop Count OK 4. Effective Topology OK 4.1 Incorrect Forwarding ** IP forwarding can also be turned of on commercial routers as well via config - quite easily ** Likely ops level mitigation needed. 4.2 Wormholes ** comment on section above. ** 4.3 Sequence Number Attacks P1 Not sure the word “fresher” in the sentence “long paths or other delays, is not allowed to overwrite fresher information” is the best choice. Technically, the latter arriving message due to delay/etc is fresher from the receivers point of view, but less desirable given the delay or path. 4.3.1 Message Sequence Number similar to above comment, perhaps “recent” is a better word to use vs. “Fresh” in the sentence “”Routers will retain this larger ANSN as "the most fresh information" and …”” 4.4 Indirect Jamming OK 5. Inconsistent Topologies OK 5.1 Identity Spoofing OK 5.2 Link Spoofing OK 5.2.1 Inconsistent Topology Maps due to Link State Advertisements 6. Mitigation of Security Vulnerabilities for OLSRv2 OK 6.1 Inherent OLSRv2 Resilience OK 6.2 Resilience by using RFC7183 with OLSRv2 OK 6.2.1 Topology Map Acquisition OK 6.2.2 Effective Topology OK 6.2.3 Inconsistent Topology From nobody Thu Jan 5 04:46:25 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D221F1293EC; Thu, 5 Jan 2017 04:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 BEFfauJE4L-x; Thu, 5 Jan 2017 04:46:15 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id E66B91288B8; Thu, 5 Jan 2017 04:46:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3DF5E2D291; Thu, 5 Jan 2017 14:46:08 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-TTWCd1MN9S; Thu, 5 Jan 2017 14:46:07 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id C7D952D290; Thu, 5 Jan 2017 14:46:07 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9CDC37B3-7315-4D60-B61F-69043E0403F7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: Date: Thu, 5 Jan 2017 14:46:07 +0200 Message-Id: <95C109DF-B140-4C2B-BB01-92008A13B44F@piuha.net> References: To: Elwyn Davies X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "gen-art@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-olsrv2-sec-threats.all@ietf.org" , "ietf@ietf.org" Subject: Re: [manet] Review of draft-ietf-manet-olsrv2-sec-threats-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 12:46:16 -0000 --Apple-Mail=_9CDC37B3-7315-4D60-B61F-69043E0403F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Many thanks Elwyn for your detailed review. I also found the discussion = afterwards enlightening. I=92m expecting the authors to draw some conclusions re: possible = modifications based on the questions and answers. Jari --Apple-Mail=_9CDC37B3-7315-4D60-B61F-69043E0403F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYbkAPAAoJEM80gCTQU46qBJ8P/2KFFIMjbBVLRNn2P1qBb8DQ XRz1fS4mCtKXkbBbAu0qJ8u26oilwPUiLLsPAY3aiAynjLrp6KLE/kt3XrG3iGM7 5T4oZxKPN5x1/gGnFXPs/y1AS9GXCNUQAmZFofi14TPyQ3Y705DhHnj5SToT8kU+ fDEjVD+VmocTaT+9qGi8B5cis6gLct96UBMaIGPacVfSUzBOruabnDJtl6T5pfDx sluuodBdWqpAgFynqbmwkfLu4T1XTYElXjqBNX0YCGmtitdMgd+c129faFCS6SI4 L6FQekuiuyi9vT6daqEBDmC3cPG63Xs6PZwuoWZLKJxOLOSmZX1h78xNeOdeX23e ZWHqOMSB7OnRdNWyrVPjE20zb2xFk4scIMNQREzetb9QP5XZDvKTuBUZqv1vem87 3mKXHvwTKbsKBtxU/FGomvdLlZBnQ4e2NEtn2BUA5+pb9Odu9fNFUBU5KbiwNbQc 8XQyoh3IlJqXT08P2hG9E88a5r2G1RFddRTxPuvyu9eQSknh6BPXUIfIfNQfwBkt MUQZCX/vqVkAqZz56eIClO/UriRXwtIVs/vZhDpiybKlSFxkRUW8m9wUpWKyTEcR irMiEL2bNsWE6/mCjur14NAAwPak4wkQLkgUV4P8J2cVxu+1v84CMvjCRVoM0t0Z Zw/u2FjvlaGpKhuRM1Oi =fyyZ -----END PGP SIGNATURE----- --Apple-Mail=_9CDC37B3-7315-4D60-B61F-69043E0403F7-- From nobody Thu Jan 5 05:27:53 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7001288B8; Thu, 5 Jan 2017 05:27:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148362287164.20543.5367631671159172919.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 05:27:51 -0800 Archived-At: Cc: manet-chairs@ietf.org, manet@ietf.org, draft-ietf-manet-olsrv2-sec-threats@ietf.org Subject: [manet] Stephen Farrell's Discuss on draft-ietf-manet-olsrv2-sec-threats-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:27:51 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-manet-olsrv2-sec-threats-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have two things I'd like to discuss to see if changes are needed or not: (1) Neither this nor RFC7186 seem to consider battery depletion attacks. Why is that ok? (2) 6.2: HMAC is *not* a digital signature mechanism. While loose terminology may be ok elsewhere, in this case, you shouldn't do that as it can lead to wrong conclusions. Digital signatures do provide origin authentication of sorts, but MACs do not, especially if keys are shared. It is not clear to me that some of the claims in 6.2.x of attacks being mitigated are in fact correct, given shared secrets. (Note: It could be that the claims are correct, I didn't have time to check back on all the vulnerability definitions, sorry. But I'd like to check, given the defective terminology.) From nobody Thu Jan 5 06:21:25 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF641293F3; Thu, 5 Jan 2017 06:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.02 X-Spam-Level: X-Spam-Status: No, score=-10.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 at-iWTpOJ-RC; Thu, 5 Jan 2017 06:21:23 -0800 (PST) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CDF12954D; Thu, 5 Jan 2017 06:21:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208";a="48506216" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 05 Jan 2017 14:21:21 +0000 X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208";a="150177877" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 05 Jan 2017 14:21:20 +0000 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.144]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Thu, 5 Jan 2017 14:21:19 +0000 From: "Dearlove, Christopher (UK)" To: Stephen Farrell , The IESG Thread-Topic: [manet] Stephen Farrell's Discuss on draft-ietf-manet-olsrv2-sec-threats-03: (with DISCUSS) Thread-Index: AQHSZ1eMKtUvcDWWUE+rDawmlNcFa6Ep5hKQ Date: Thu, 5 Jan 2017 14:21:18 +0000 Message-ID: References: <148362287164.20543.5367631671159172919.idtracker@ietfa.amsl.com> In-Reply-To: <148362287164.20543.5367631671159172919.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-manet-olsrv2-sec-threats@ietf.org" , "manet@ietf.org" , "manet-chairs@ietf.org" Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-olsrv2-sec-threats-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:21:24 -0000 Not an author, but I hope this is useful. It follows up Stephen's second po= int. RFC 7182 describes a mechanism for adding ICVs to anything based on RFC 544= 4 format (which includes OLSRv2). It includes code points for some ICVs tha= t may be signatures and some that aren't - I think more of the latter. RFC 7183 is, roughly speaking, an RFC 7182 option for OLSRv2 (and NHDP) imp= lementation. It's called out from RFC 7181 (OLSRv2) as a "must implement, d= on't need to use" mechanism. It specifies the HMAC/SHA-256 option indicated= . It is shared secret key, and thus isn't a signature (as Stephen notes). Reading Section 6.2 with that in mind, apart from the use of signature, I t= hink mostly it's OK, the RFC 7183 option will work as described if nothing = is compromised, but I'm not sure about the final parenthesised piece at the= end of the first long paragraph. If you want to be able to revoke you want= to be using a different RFC 7182 (or extension) option, as noted an asymme= tric one, not the RFC 7183 option, and I don't think that's clear. Possibly= "in addition" is meant to mean something more like "alternatively" (though= it is not a simple text change like that) but should reference RFC 7182. (I think the ICVs that might be signatures in RFC 7182 are probably undersp= ecified, which goes back to RFC 6622 of which it is an update. There is an = ICV that is a signature in RFC 7859, an extension to RFC 7182, but that is = experimental, although specified in some detail.) -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: 05 January 2017 13:28 To: The IESG Cc: manet-chairs@ietf.org; manet@ietf.org; draft-ietf-manet-olsrv2-sec-thre= ats@ietf.org Subject: [manet] Stephen Farrell's Discuss on draft-ietf-manet-olsrv2-sec-t= hreats-03: (with DISCUSS) ----------------------! 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. -------------------------------------------------------- *** WARNING *** EXTERNAL EMAIL -- This message originates from outside our organization. Stephen Farrell has entered the following ballot position for draft-ietf-manet-olsrv2-sec-threats-03: Discuss When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have two things I'd like to discuss to see if changes are needed or not: (1) Neither this nor RFC7186 seem to consider battery depletion attacks. Wh= y is that ok? (2) 6.2: HMAC is *not* a digital signature mechanism. While loose terminology may be ok elsewhere, in this case, you shouldn't do= that as it can lead to wrong conclusions. Digital signatures do provide or= igin authentication of sorts, but MACs do not, especially if keys are share= d. It is not clear to me that some of the claims in 6.2.x of attacks being = mitigated are in fact correct, given shared secrets. (Note: It could be tha= t the claims are correct, I didn't have time to check back on all the vulne= rability definitions, sorry. But I'd like to check, given the defective terminology.) _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From nobody Mon Jan 9 12:07:02 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F347A1295A2 for ; Mon, 9 Jan 2017 12:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GgMkCb6fyNiR for ; Mon, 9 Jan 2017 12:06:54 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0082.outbound.protection.outlook.com [104.47.37.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2979D120727 for ; Mon, 9 Jan 2017 12:06:54 -0800 (PST) Received: from BLUPR0401MB1731.namprd04.prod.outlook.com (10.162.215.21) by BLUPR0401MB1731.namprd04.prod.outlook.com (10.162.215.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Mon, 9 Jan 2017 20:06:52 +0000 Received: from BLUPR0401MB1731.namprd04.prod.outlook.com ([10.162.215.21]) by BLUPR0401MB1731.namprd04.prod.outlook.com ([10.162.215.21]) with mapi id 15.01.0829.013; Mon, 9 Jan 2017 20:06:52 +0000 From: "Peter S Lau (peterlau)" To: Justin Dean Thread-Topic: [manet] A proposed draft "draft-peterlau-manet-topology-refresh" Thread-Index: AQHSZeN4eitj+utMfUKMGDE1x3UIoaEoCDCAgAAKmOCAAGTvgIAII4rH Date: Mon, 9 Jan 2017 20:06:52 +0000 Message-ID: References: <97591271-9997-4245-BDED-056BE872AF8B@jiaziyi.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=peterlau@memphis.edu; x-originating-ip: [132.245.8.5] x-ms-office365-filtering-correlation-id: dee17580-7b36-4462-1f40-08d438cb0d92 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BLUPR0401MB1731; x-microsoft-exchange-diagnostics: 1; BLUPR0401MB1731; 7:Y+GQqL4DuPGsrzmeHHHEEQhBm4NWbjbl9eT9cFsQgJf+uqBP7ofoQwJNUoAiV6tC9L64MFZ7Jrf+Y6POGp3VcBGwDH+vytQDMyUuL/GCChbMYUav1jwW4KShzebz1vQRYa7I+/CMCJddDfc5WV3xWlL+1IgHIfeZnbLrivk8kT7gBflIXnuEsu790EYlAlHJ6VLDUZtEa2xBUSrVrdpbggUOwI2jDetJm3atH0OXGq4OH2bTgbXdV0ZDHeMCwZqcQtRkgIFYF3XBblf2JIq2unuc0ybOfFvJz+urlFoheomRJfvFhVH4W+SOQb/H9JYSa3zzBBw+aRzY6AeHsCOd2p8OTQq2VUdIA+lazWLrH+f0JMpXmJb4b8Bc9knWmD5kxfjhgdngPxGlDgxlzXMg2KGkwRwOTPCRUvxHP47C4leY5HUSwCtOFDNZJV54OuwakcivNi2RbMM2vZCctWiNAA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(113876321673885)(278428928389397)(192374486261705)(84894511551618); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BLUPR0401MB1731; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0401MB1731; x-forefront-prvs: 0182DBBB05 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(377454003)(199003)(24454002)(7696004)(3846002)(230783001)(6606003)(19627405001)(8936002)(6116002)(102836003)(110136003)(105586002)(106356001)(106116001)(8676002)(88552002)(7066003)(4326007)(5660300001)(81166006)(81156014)(92566002)(6916009)(9686003)(2950100002)(6306002)(68736007)(1411001)(66066001)(2906002)(3280700002)(3660700001)(122556002)(93886004)(86362001)(50986999)(54906002)(3900700001)(74316002)(97736004)(101416001)(6436002)(7736002)(345774005)(54896002)(7906003)(229853002)(38730400001)(189998001)(606005)(39060400001)(33656002)(5890100001)(99286003)(55016002)(76176999)(6506006)(75432002)(77096006)(54356999)(2900100001)(10126002)(25786008); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0401MB1731; H:BLUPR0401MB1731.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: memphis.edu does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0401MB17312C9FDBE9613555713CC3C9640BLUPR0401MB1731_" MIME-Version: 1.0 X-OriginatorOrg: memphis.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2017 20:06:52.1477 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ae145aea-cdb2-446a-b05a-7858dde5ddba X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0401MB1731 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:06:58 -0000 --_000_BLUPR0401MB17312C9FDBE9613555713CC3C9640BLUPR0401MB1731_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear all: Thank you for the comments. I am going to respond to some comments and leave the others at a later time. Thanks, Peter Lau 1. Response to the comment "there thus may or may not be a space for a lightweight proactive protocol" made by Christopher. 1.a TRP is intended for nearby social network where people are moving around with smartphones (installed with TRP) discover and communicate with each other on the fly when they move into the vicinity of each other. I believe OLSR/OLSv2 and others were not conceived to support such an application. I list three requirements that may justify a space for a lightweight protocol, like TRP. 1.b Delay is very important in highly interactive applications, such as nearby social network, that must be kept low. This calls for a proactive protocol. For such a real-time interactive application, it is reasonably to expect the response time to be a fraction of a second. Performance study in [WTS2015] shows that TRP achieves sub-second message end-to-end delay. A rough estimate of OLSR/OLSRv2 message end-to-end delay includes HNDP (link break detection) delay, TC message delay, and routing set calculation delay. An experiment done in [www.dtic.mil/cgi-bin/ GetTRDoc?AD=3DADA521173] has demonstrated that the delay for OLSR is multiple seconds for a 18-node manet. Perhaps, solely from the delay perspective for the intended application, a lightweight protocol, like TRP, is warranted. 1.c Conserving battery energy for smartphones is another important issue. TRP attacks the problem in two fronts: less taxing the CPU with a lightweight protocol and selecting forwarding paths to exclude devices with low remaining battery energy. By contrast, OLSR/OLSRv2 are running in routers (which are not smartphones) and presummably have no energy depletion issue. 1.d Participants in a nearby social network are constantly and rapidly changing. Users need to know who are in the network to be able to select them to chat. TRP solves the problem by periodically presenting to the users with an updated list of all users who are happen nearby, i.e., in the nearby social network. OLSR/OLSRv2 and others do not have such capability essential to nearby social networks. 1.e The above argue for a lightweight protocol for nearby social networks. I think we need to decide first whether there is a space for a lightweight protocol, like TRP. Are there any existing protocols that can support nearby social network applications? 2. Response to the comment "Could you please briefly introduce what's the difference between TRP and other proactive protocols like OLSR(v2)?" made by Jiazi 2.a OLSR/OLSRv2 use MPRs to aggregate LS information to thereby reducing LS flooding overhead and for topology reduction. The current form of TRP does not aggregate type 2 control information. After some thought, aggregation may be possible in TRP, any ideas? 2.b While OLSR/OLSRv2 requires neighborhood discovery, TRP does not, contributing to its light weight. Because nearby social networks are highly dynamic (users are constantly moving), a discovered neighborhood could quickly become outdated. 2.c While OLSR/OLSRv2 carry out routing set calculation from the network topology graph after receiving TC messages for the link states, TRP creates and updates forwarding entries on the fly when processing individual control messages, eliminating the extra calculations. This contributes to the TRP's light weight. 2.d While OLSR/OLSRv2 can actively remove advertised content, TRP relies on timeout to remove users, who have left the network, from the user list. 2.e While OLSR/OLSRv2 requires bidirectional links, TRP does not test if a link is bidirectional because directionality could quickly change as users are moving around. After some thought, it makes sense that once a node has chosen the next node for a destination, the node confirms the bidirectional link between the next node and itself. 2.f TRP supports devices with and without cellular data, with and without a connection to an access point, and therefore, they may or may not have an IP address. A TRP node self-assigns a node id (which is neither a 4- byte nor 16-byte IP address but a 2-byte quantity for overhead efficiency) and relies on id collision detection. Unique IP addresses are configured (or by some other means) into OLSR/OLSRv2 routers. 2.g While OLSR/OLSRv2 operates up to the transport layer, TRP remains in the data link layer. 2.h Smartphones have very limited battery energy but OLSR/OLSRv2 routers do not have energy limitation. 2.i A TRP user can dynamically limit other users to within a physical distance from herself. OLSR/OLSRv2 do not have such capability. 2.j A TRP user is constantly updated with a list of users within a distance from her. OLSR/OLSRv2 do not have such capability. 2.k TRP users can independently choose how frequent to broadcast their presence in the network. OLSR/OLSRv2 do not allow such an option. 2.l While OLSR/OLSRv2 are optimized for large and dense networks, TRP must support large/small and dense/sparse networks. 2.m While OLSR/OLSRv2 supports security, TRP in its current state does not call for security. I cannot think of scenarios that require security in a nearby social network application. Any ideas? 2.n I think the protocol differences are due to the different intended applications. 3. Response to the comment "Especially, it would be very helpful for the readers to understand by providing a bit more text about the mechanism of the protocol in the overview" made by Jiazi 3.a A node (say node X), upon receiving a control message, knows the node who originated the message (say Node S, the originator) and the node from which the message was received (say Node N, the forwarder). It is because the originator puts its id in the control message and the forwarder modifies the message by putting its id in it before retransmitting it. N must be a neighbor of X. For example, if S sent the message, then N =3D S. 3.b An entry (destination node, forwarding node) =3D (S, N) in the forwarding table is either created or updated in X. Of course the entry contains other information such as sequence number, hop count, etc.) 3.c When X needs to forward a user message to S, X will transmit it to N. The user message may be generated locally in X or forwarded to X by a neighbor of X. 3.d It is entirely possible that X receives two or more control messages, each with the same originator but different forwarders. Among these control messages, X will select the one based on the sequence number, hop count, etc. to create or update the entry. The other control messages are discarded. 3.e X then modifies the selected message by putting its id in it and retransmits it. 3.f As the control messages, with S as the originator, propagate throughout the network, a tree rooted at S is built. The size of the tree is limited by the maximum allowable hop count and the physical distance between S and a leaf node. 3.g Since every node originates control messages, the result is a complete topology of end-to-end paths. 3.h The tree rooted at a node is updated every time the node transmits a control message. Since every node periodically transmits control messages, the result is that the topology is constantly tracking the movement of the users. Peter Lau The University of Memphis Electrical and Computer Engineering ________________________________ From: Justin Dean Sent: Wednesday, January 4, 2017 9:46 AM To: Peter S Lau (peterlau) Cc: Jiazi Yi; manet@ietf.org; Dearlove, Christopher (UK) Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refres= h" Thank you for the submission. I too have some misgivings about the document= s current state and tradeoffs with regard to packet format and lack of use = of the Manet building blocks which seem like they could be easily incorpora= ted. RFC5444 has Hop-limit/count and sequence number fields, and NHDP (RFC6= 130) has neighbor discovery and fixes the bidirectional problem. In additio= n to the other security pieces and leveraging of CDS algorithms found in ei= ther SMF or OLSRv2 one could build a similar protocol with only the additio= n of a message type and a few TLVS. The two that jump out at me for being u= seful beyond just this proposed protocol would be GPS and Application/Highe= r Layer ID TLV encodings. Justin Dean On Wed, Jan 4, 2017 at 5:10 AM, Dearlove, Christopher (UK) > wrote: There some immediate retrograde steps compared to existing protocols: fixed= message format (making adding new information to be used by the protocol h= ard), forwarding by blind flooding (hence scalability issues), and no secur= ity (an example of something that to add would require a changed format). T= he rather peculiar link metric (in effect) that mixes hop count, time and b= attery power leads to many questions (and while not simply hop count is lik= ely to be a backward step in flexibility). There=92s a rather unusual messa= ge body that is not used by this protocol but said to be for the applicatio= n, which is a bit of a layering issue. GPS is included with no indication h= ow to use and hence no indication why it is there. They are also underspeci= fied in terms of format information (and for GPS at least even size of fiel= d). There=92s quite a lot underspecified, such as route determination, and = there=92s no consideration of how the acknowledgements are used - and even = what the meaning of acknowledgements in what must be (but is not so describ= ed) as a local broadcast/multicast message (with potentially unknown recipi= ents). I don=92t see any handling of the problems that link asymmetry produ= ces. I=92d have issues over timing parameters and their management (these b= eing not reflected in the message). And in a proposed IETF protocol, I don= =92t see any IP addresses. That it hasn=92t even caught up with the existen= ce of RFC 7181 (only quoting RFC 3626) is not a good sign. It is suggested = that RFC 3626 (and hence, no doubt, RFC 7181) is too complex. That may or m= ay not be so (there are reasons for the added complexity in RFC 7181, which= need to be understood before deciding whether you need them) and there thu= s may or may not be a space for a lightweight proactive protocol, but this = is not that protocol in current or foreseeable evolutionary form. -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesy= stems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP From: manet [mailto:manet-bounces@ietf.org] = On Behalf Of Jiazi Yi Sent: 04 January 2017 09:08 To: Peter S Lau (peterlau) Cc: manet@ietf.org Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refres= h" *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. *** WARNING *** EXTERNAL EMAIL -- This message originates from outside our organization. Dear Peter, Thanks very much for your draft. Looking at the overview section: TRP is a table-driven proactive data forwarding protocol and at the same time allows users to announce their presence to the network. A node, wishing to be contacted, periodically broadcasts control messages about itself to the network. A node, receiving control messages, caches an optimal path to each of the originators of the control messages. Could you please briefly introduce what=92s the difference between TRP and = other proactive protocols like OLSR(v2)? Especially, it would be very helpful for the readers to understand by provi= ding a bit more text about the mechanism of the protocol in the overview. best Jiazi On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) > wrote: Dear manet Working Group: I have uploaded a proposed draft entitled "draft-peterlau-manet-topology-re= fresh-00". for the WG to consider. Regards, Peter Lau Peter Lau The University of Memphis Electrical and Computer Engineering _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_BLUPR0401MB17312C9FDBE9613555713CC3C9640BLUPR0401MB1731_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear all:

Thank you for the comments. I am going to respond to some comments and
leave the others at a later time.

Thanks,

Peter Lau



1. Response to the comment "there thus may or may not be a space for a=
lightweight proactive protocol" made by Christopher.

1.a TRP is intended for nearby social network where people are moving
around with smartphones (installed with TRP) discover and communicate
with each other on the fly when they move into the vicinity of each
other. I believe OLSR/OLSv2 and others were not conceived to support such <= br> an application. I list three requirements that may justify a space for a lightweight protocol, like TRP.

1.b Delay is very important in highly interactive applications, such as nearby social network, that must be kept low. This calls for a proactive protocol. For such a real-time interactive application, it is reasonably to expect the response time to be a fraction of a second. Performance
study in [WTS2015] shows that TRP achieves sub-second message end-to-end delay. A rough estimate of OLSR/OLSRv2 message end-to-end delay includes HNDP (link break detection) delay, TC message delay, and routing set
calculation delay. An experiment done in [www.dtic.mil/cgi-bin/
GetTRDoc?AD=3DADA521173] has demonstrated that the delay for OLSR is
multiple seconds for a 18-node manet. Perhaps, solely from the delay
perspective for the intended application, a lightweight protocol, like
TRP, is warranted.

1.c Conserving battery energy for smartphones is another important issue. <= br> TRP attacks the problem in two fronts: less taxing the CPU with a
lightweight protocol and selecting forwarding paths to exclude devices
with low remaining battery energy. By contrast, OLSR/OLSRv2 are running in routers (which are not smartphones) and presummably have no energy
depletion issue.

1.d Participants in a nearby social network are constantly and rapidly
changing. Users need to know who are in the network to be able to select them to chat. TRP solves the problem by periodically presenting to the
users with an updated list of all users who are happen nearby, i.e., in the nearby social network. OLSR/OLSRv2 and others do not have such
capability essential to nearby social networks.

1.e The above argue for a lightweight protocol for nearby social
networks. I think we need to decide first whether there is a space for a lightweight protocol, like TRP. Are there any existing protocols that can <= br> support nearby social network applications?

2. Response to the comment "Could you please briefly introduce what's = the
difference between TRP and other proactive protocols like OLSR(v2)?" m= ade
by Jiazi

2.a OLSR/OLSRv2 use MPRs to aggregate LS information to thereby reducing LS flooding overhead and for topology reduction. The current form of TRP does not aggregate type 2 control information. After some thought,
aggregation may be possible in TRP, any ideas?

2.b While OLSR/OLSRv2 requires neighborhood discovery, TRP does not,
contributing to its light weight. Because nearby social networks are
highly dynamic (users are constantly moving), a discovered neighborhood could quickly become outdated.

2.c While OLSR/OLSRv2 carry out routing set calculation from the network topology graph after receiving TC messages for the link states, TRP
creates and updates forwarding entries on the fly when processing
individual control messages, eliminating the extra calculations. This
contributes to the TRP's light weight.

2.d While OLSR/OLSRv2 can actively remove advertised content, TRP relies on timeout to remove users, who have left the network, from the user
list.

2.e While OLSR/OLSRv2 requires bidirectional links, TRP does not test if a link is bidirectional because directionality could quickly change as
users are moving around. After some thought, it makes sense that once a node has chosen the next node for a destination, the node confirms the
bidirectional link between the next node and itself.

2.f TRP supports devices with and without cellular data, with and without <= br> a connection to an access point, and therefore, they may or may not have an IP address. A TRP node self-assigns a node id (which is neither a 4-
byte nor 16-byte IP address but a 2-byte quantity for overhead
efficiency) and relies on id collision detection. Unique IP addresses are <= br> configured (or by some other means) into OLSR/OLSRv2 routers.

2.g While OLSR/OLSRv2 operates up to the transport layer, TRP remains in the data link layer.

2.h Smartphones have very limited battery energy but OLSR/OLSRv2 routers do not have energy limitation.

2.i A TRP user can dynamically limit other users to within a physical
distance from herself. OLSR/OLSRv2 do not have such capability.

2.j A TRP user is constantly updated with a list of users within a
distance from her. OLSR/OLSRv2 do not have such capability.

2.k TRP users can independently choose how frequent to broadcast their
presence in the network. OLSR/OLSRv2 do not allow such an option.

2.l While OLSR/OLSRv2 are optimized for large and dense networks, TRP
must support large/small and dense/sparse networks.

2.m While OLSR/OLSRv2 supports security, TRP in its current state does
not call for security. I cannot think of scenarios that require security in a nearby social network application. Any ideas?

2.n I think the protocol differences are due to the different intended
applications.

3. Response to the comment "Especially, it would be very helpful for t= he
readers to understand by providing a bit more text about the mechanism of <= br> the protocol in the overview" made by Jiazi

3.a A node (say node X), upon receiving a control message, knows the node <= br> who originated the message (say Node S, the originator) and the node from <= br> which the message was received (say Node N, the forwarder). It is because <= br> the originator puts its id in the control message and the forwarder
modifies the message by putting its id in it before retransmitting it. N must be a neighbor of X. For example, if S sent the message, then N =3D S.<= br>
3.b An entry (destination node, forwarding node) =3D (S, N) in the
forwarding table is either created or updated in X. Of course the entry contains other information such as sequence number, hop count, etc.)

3.c When X needs to forward a user message to S, X will transmit it to N. <= br> The user message may be generated locally in X or forwarded to X by a
neighbor of X.

3.d It is entirely possible that X receives two or more control messages, <= br> each with the same originator but different forwarders. Among these
control messages, X will select the one based on the sequence number, hop <= br> count, etc. to create or update the entry. The other control messages are <= br> discarded.

3.e X then modifies the selected message by putting its id in it and
retransmits it.

3.f As the control messages, with S as the originator, propagate
throughout the network, a tree rooted at S is built. The size of the tree <= br> is limited by the maximum allowable hop count and the physical distance between S and a leaf node.

3.g Since every node originates control messages, the result is a
complete topology of end-to-end paths.

3.h The tree rooted at a node is updated every time the node transmits a control message. Since every node periodically transmits control
messages, the result is that the topology is constantly tracking the
movement of the users.

Peter Lau
The University of Memphis
Electrical and Computer Engineering


From: Justin Dean <beb= emaster@gmail.com>
Sent: Wednesday, January 4, 2017 9:46 AM
To: Peter S Lau (peterlau)
Cc: Jiazi Yi; manet@ietf.org; Dearlove, Christopher (UK)
Subject: Re: [manet] A proposed draft "draft-peterlau-manet-top= ology-refresh"
 
Thank you for the submission. I too have some misgivings a= bout the documents current state and tradeoffs with regard to packet format= and lack of use of the Manet building blocks which seem like they could be= easily incorporated. RFC5444 has Hop-limit/count and sequence number fields, and NHDP (RFC6130) has neighbo= r discovery and fixes the bidirectional problem. In addition to the other s= ecurity pieces and leveraging of CDS algorithms found in either SMF or OLSR= v2 one could build a similar protocol with only the addition of a message type and a few TLVS. The two that jump= out at me for being useful beyond just this proposed protocol would be GPS= and Application/Higher Layer ID TLV encodings.

Justin Dean

On Wed, Jan 4, 2017 at 5:10 AM, Dearlove, Christ= opher (UK) <chris.dearlove@baesystems.com> wrote:

There some immediate re= trograde steps compared to existing protocols: fixed message format (making= adding new information to be used by the protocol hard), forwarding by blind flooding (hence scalability issues), and no security (= an example of something that to add would require a changed format). The ra= ther peculiar link metric (in effect) that mixes hop count, time and batter= y power leads to many questions (and while not simply hop count is likely to be a backward step in flexibi= lity). There=92s a rather unusual message body that is not used by this pro= tocol but said to be for the application, which is a bit of a layering issu= e. GPS is included with no indication how to use and hence no indication why it is there. They are also underspe= cified in terms of format information (and for GPS at least even size of fi= eld). There=92s quite a lot underspecified, such as route determination, an= d there=92s no consideration of how the acknowledgements are used - and even what the meaning of acknowledgeme= nts in what must be (but is not so described) as a local broadcast/multicas= t message (with potentially unknown recipients). I don=92t see any handling= of the problems that link asymmetry produces. I=92d have issues over timing parameters and their management (t= hese being not reflected in the message). And in a proposed IETF protocol, = I don=92t see any IP addresses. That it hasn=92t even caught up with the ex= istence of RFC 7181 (only quoting RFC 3626) is not a good sign. It is suggested that RFC 3626 (and hence, no dou= bt, RFC 7181) is too complex. That may or may not be so (there are reasons = for the added complexity in RFC 7181, which need to be understood before de= ciding whether you need them) and there thus may or may not be a space for a lightweight proactive protocol,= but this is not that protocol in current or foreseeable evolutionary form.=

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:=  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsfo= rd Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intell= igence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP=

 

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi Yi
Sent: 04 January 2017 09:08
To: Peter S Lau (peterlau)
Cc: manet@ietf.o= rg
Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"

 

 

*** WARNING ***

This message originates from outside our org= anisation, either from an external partner or the internet.<= span style=3D"font-size:10.5pt; font-family:"Arial","sans-se= rif"; color:#333972">
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding Red Flags that you can look out for in emails you receive, click here.
If= you feel the email is suspicious, please follow this process.<= u>

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside o= ur organization.

 

Dear Peter, 

 

Thanks very much for your draft. =

 

Looking at the overview section:

 

   TRP is a table-driven proactive data fo= rwarding protocol and at the

   same time allows users to announce thei= r presence to the network.  A

   node, wishing to be contacted, periodic= ally broadcasts control

   messages about itself to the network.&n= bsp; A node, receiving control

   messages, caches an optimal path to eac= h of the originators of the

   control messages.  <= /p>

 

Could you please briefly introduce what=92s the diff= erence between TRP and other proactive protocols like OLSR(v2)?

 

Especially, it would be very helpful for the readers= to understand by providing a bit more text about the mechanism of the prot= ocol in the overview. 

 

best

 

Jiazi

 

On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) <= peterlau@memphis.= edu> wrote:

 

Dear manet Working Group:

I have uploaded a proposed draft entitled "draft-peterlau-manet-t= opology-refresh-00". for the WG to consider.

Regards,
Peter Lau

 

Peter Lau
The University of Memphis
Electrical and Computer Engineering

________________________________= _______________
manet mailing list
m= anet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 

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


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


--_000_BLUPR0401MB17312C9FDBE9613555713CC3C9640BLUPR0401MB1731_-- From nobody Mon Jan 9 12:34:00 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7381295A5 for ; Mon, 9 Jan 2017 12:33:57 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgJ6qHKVhGl5 for ; Mon, 9 Jan 2017 12:33:53 -0800 (PST) Received: from mail-wj0-x241.google.com (mail-wj0-x241.google.com [IPv6:2a00:1450:400c:c01::241]) (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 3836D127071 for ; Mon, 9 Jan 2017 12:33:53 -0800 (PST) Received: by mail-wj0-x241.google.com with SMTP id kp2so85677316wjc.0 for ; Mon, 09 Jan 2017 12:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=KbLiaUCwNyAUgLwYEJp/wJ+CTMkteUFb2d27GSML29k=; b=S4tC9oSpsaACpa57CufZUVRm0AzrgnQFLAmwOp7RIb/WbBai+FNGQcjgdUjk9S7fQr 8LB7jeEDvGDqehKNKtq/67C8nqtjhIBwjgGEpXg70wWNngSuMO8jHAPLAQMJR/kmpN0n qmOzzm40x69fGM4/y12WsFgzGlmHg9kfj7OtjCYvZVXb23dXk7ZopNd477AtATaT2rvB D9zb/aRHzDhFHReoGriRrF/DQYFpdn7S//bvk0SFEkH7wY+9OBcyBU2DzdXXImwLYAvJ HxYAY5WAhiSQzs0XzRtJ5G6cPYTySyC6Mz2rWyP1b7ndJoClgrVOZiC8uFLpA/2ff3dT 18aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=KbLiaUCwNyAUgLwYEJp/wJ+CTMkteUFb2d27GSML29k=; b=LRa8IPM8+4GRL1j/NbNr4j0wpGtgAcd10T8v+/mbUwQSds5R+y+QbZiNn92iQOw1d5 pXOBw4lEfpVYoUFNMd4k8tPfCbK00Ipqqu+/R4lpayKOkXugPouusTSWZQ+LLIxraaRI Tz1ipZfDG8Qm6iVg7Eq/vl2gqDMme4vJx/SI6q3CKC5C5MiZlvlWQyhjd3qFQzbNaj98 GNE6fgK3RxVu5Gs+InDfibmAFrc3RrDtrHwRi0gIKGB8mE0taTzQXpeGAj6+omZIPPQU 9QsbARhqXqnBUY/nfgbPPp1sU9czVgBU3GqKdqTD0de78VbAEcZ1YoMH8z+FznBTfP3R gOQQ== X-Gm-Message-State: AIkVDXIQUmrEpmtC4gyyKWCdsQnhdK4kF7JTw+SepHuUzAjGuCNrYjcT8QX6to2q+ktfhg== X-Received: by 10.194.141.239 with SMTP id rr15mr64836515wjb.144.1483994031306; Mon, 09 Jan 2017 12:33:51 -0800 (PST) Received: from [192.168.1.154] ([213.205.251.103]) by smtp.gmail.com with ESMTPSA id c202sm20605533wmd.10.2017.01.09.12.33.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 12:33:50 -0800 (PST) References: <97591271-9997-4245-BDED-056BE872AF8B@jiaziyi.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-A8E6B63B-FF5A-44A7-967A-60AB75E715C4 Message-Id: X-Mailer: iPhone Mail (14C92) From: Christopher Dearlove Date: Mon, 9 Jan 2017 20:33:47 +0000 To: "Peter S Lau (peterlau)" Archived-At: Cc: "manet@ietf.org" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:33:58 -0000 --Apple-Mail-A8E6B63B-FF5A-44A7-967A-60AB75E715C4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On the contrary, that's exactly the sort of scenario OLSRv2, and before it O= LSR were developed for. Well, for OLSR it was laptops and PDAs. Several of u= s have networked such devices in that way. Delay in OLSRv2 is a function of its parameters. It's not meaningful to defi= ne a single delay value. I've yet to see why you think TRP is inherently fas= ter. The comments about smartphones and routers completely misses the point. A ro= uter is a function, not a device. If you run OLSRv2 in a smartphone, the sma= rtphone is a router. The comment about OLSRv2 not knowing who is in the network is simply wrong. At that point I've just decided to stop answering point by point. I suggest f= irst understanding what exists, and why it has the features it has, before t= rying to suggest you have something better. -- =20 Christopher Dearlove christopher.dearlove@gmail.com chris@mnemosyne.demon.co.uk is dead > On 9 Jan 2017, at 20:06, Peter S Lau (peterlau) wro= te: >=20 > Dear all: >=20 > Thank you for the comments. I am going to respond to some comments and=20 > leave the others at a later time. >=20 > Thanks, >=20 > Peter Lau >=20 >=20 >=20 > 1. Response to the comment "there thus may or may not be a space for a=20 > lightweight proactive protocol" made by Christopher. >=20 > 1.a TRP is intended for nearby social network where people are moving=20 > around with smartphones (installed with TRP) discover and communicate=20 > with each other on the fly when they move into the vicinity of each=20 > other. I believe OLSR/OLSv2 and others were not conceived to support such=20= > an application. I list three requirements that may justify a space for a=20= > lightweight protocol, like TRP. >=20 > 1.b Delay is very important in highly interactive applications, such as=20= > nearby social network, that must be kept low. This calls for a proactive=20= > protocol. For such a real-time interactive application, it is reasonably=20= > to expect the response time to be a fraction of a second. Performance=20 > study in [WTS2015] shows that TRP achieves sub-second message end-to-end=20= > delay. A rough estimate of OLSR/OLSRv2 message end-to-end delay includes=20= > HNDP (link break detection) delay, TC message delay, and routing set=20 > calculation delay. An experiment done in [www.dtic.mil/cgi-bin/ > GetTRDoc?AD=3DADA521173] has demonstrated that the delay for OLSR is=20 > multiple seconds for a 18-node manet. Perhaps, solely from the delay=20 > perspective for the intended application, a lightweight protocol, like=20 > TRP, is warranted. >=20 > 1.c Conserving battery energy for smartphones is another important issue.=20= > TRP attacks the problem in two fronts: less taxing the CPU with a=20 > lightweight protocol and selecting forwarding paths to exclude devices=20 > with low remaining battery energy. By contrast, OLSR/OLSRv2 are running=20= > in routers (which are not smartphones) and presummably have no energy=20 > depletion issue. >=20 > 1.d Participants in a nearby social network are constantly and rapidly=20 > changing. Users need to know who are in the network to be able to select=20= > them to chat. TRP solves the problem by periodically presenting to the=20 > users with an updated list of all users who are happen nearby, i.e., in=20= > the nearby social network. OLSR/OLSRv2 and others do not have such=20 > capability essential to nearby social networks.=20 >=20 > 1.e The above argue for a lightweight protocol for nearby social=20 > networks. I think we need to decide first whether there is a space for a=20= > lightweight protocol, like TRP. Are there any existing protocols that can=20= > support nearby social network applications? >=20 > 2. Response to the comment "Could you please briefly introduce what's the=20= > difference between TRP and other proactive protocols like OLSR(v2)?" made=20= > by Jiazi >=20 > 2.a OLSR/OLSRv2 use MPRs to aggregate LS information to thereby reducing=20= > LS flooding overhead and for topology reduction. The current form of TRP=20= > does not aggregate type 2 control information. After some thought,=20 > aggregation may be possible in TRP, any ideas? >=20 > 2.b While OLSR/OLSRv2 requires neighborhood discovery, TRP does not,=20 > contributing to its light weight. Because nearby social networks are=20 > highly dynamic (users are constantly moving), a discovered neighborhood=20= > could quickly become outdated. >=20 > 2.c While OLSR/OLSRv2 carry out routing set calculation from the network=20= > topology graph after receiving TC messages for the link states, TRP=20 > creates and updates forwarding entries on the fly when processing=20 > individual control messages, eliminating the extra calculations. This=20 > contributes to the TRP's light weight. >=20 > 2.d While OLSR/OLSRv2 can actively remove advertised content, TRP relies=20= > on timeout to remove users, who have left the network, from the user=20 > list.=20 >=20 > 2.e While OLSR/OLSRv2 requires bidirectional links, TRP does not test if=20= > a link is bidirectional because directionality could quickly change as=20 > users are moving around. After some thought, it makes sense that once a=20= > node has chosen the next node for a destination, the node confirms the=20 > bidirectional link between the next node and itself. >=20 > 2.f TRP supports devices with and without cellular data, with and without=20= > a connection to an access point, and therefore, they may or may not have=20= > an IP address. A TRP node self-assigns a node id (which is neither a 4- > byte nor 16-byte IP address but a 2-byte quantity for overhead=20 > efficiency) and relies on id collision detection. Unique IP addresses are=20= > configured (or by some other means) into OLSR/OLSRv2 routers. >=20 > 2.g While OLSR/OLSRv2 operates up to the transport layer, TRP remains in=20= > the data link layer. >=20 > 2.h Smartphones have very limited battery energy but OLSR/OLSRv2 routers=20= > do not have energy limitation. >=20 > 2.i A TRP user can dynamically limit other users to within a physical=20 > distance from herself. OLSR/OLSRv2 do not have such capability. >=20 > 2.j A TRP user is constantly updated with a list of users within a=20 > distance from her. OLSR/OLSRv2 do not have such capability. >=20 > 2.k TRP users can independently choose how frequent to broadcast their=20 > presence in the network. OLSR/OLSRv2 do not allow such an option. >=20 > 2.l While OLSR/OLSRv2 are optimized for large and dense networks, TRP=20 > must support large/small and dense/sparse networks. >=20 > 2.m While OLSR/OLSRv2 supports security, TRP in its current state does=20 > not call for security. I cannot think of scenarios that require security=20= > in a nearby social network application. Any ideas? >=20 > 2.n I think the protocol differences are due to the different intended=20 > applications. >=20 > 3. Response to the comment "Especially, it would be very helpful for the=20= > readers to understand by providing a bit more text about the mechanism of=20= > the protocol in the overview" made by Jiazi >=20 > 3.a A node (say node X), upon receiving a control message, knows the node=20= > who originated the message (say Node S, the originator) and the node from=20= > which the message was received (say Node N, the forwarder). It is because=20= > the originator puts its id in the control message and the forwarder=20 > modifies the message by putting its id in it before retransmitting it. N=20= > must be a neighbor of X. For example, if S sent the message, then N =3D S.= >=20 > 3.b An entry (destination node, forwarding node) =3D (S, N) in the=20 > forwarding table is either created or updated in X. Of course the entry=20= > contains other information such as sequence number, hop count, etc.) >=20 > 3.c When X needs to forward a user message to S, X will transmit it to N.=20= > The user message may be generated locally in X or forwarded to X by a=20 > neighbor of X. >=20 > 3.d It is entirely possible that X receives two or more control messages,=20= > each with the same originator but different forwarders. Among these=20 > control messages, X will select the one based on the sequence number, hop=20= > count, etc. to create or update the entry. The other control messages are=20= > discarded. >=20 > 3.e X then modifies the selected message by putting its id in it and=20 > retransmits it. >=20 > 3.f As the control messages, with S as the originator, propagate=20 > throughout the network, a tree rooted at S is built. The size of the tree=20= > is limited by the maximum allowable hop count and the physical distance=20= > between S and a leaf node. >=20 > 3.g Since every node originates control messages, the result is a=20 > complete topology of end-to-end paths. >=20 > 3.h The tree rooted at a node is updated every time the node transmits a=20= > control message. Since every node periodically transmits control=20 > messages, the result is that the topology is constantly tracking the=20 > movement of the users. >=20 > Peter Lau > The University of Memphis > Electrical and Computer Engineering >=20 >=20 > =20 > From: Justin Dean > Sent: Wednesday, January 4, 2017 9:46 AM > To: Peter S Lau (peterlau) > Cc: Jiazi Yi; manet@ietf.org; Dearlove, Christopher (UK) > Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refre= sh" > =20 > Thank you for the submission. I too have some misgivings about the documen= ts current state and tradeoffs with regard to packet format and lack of use o= f the Manet building blocks which seem like they could be easily incorporate= d. RFC5444 has Hop-limit/count and sequence number fields, and NHDP (RFC6130= ) has neighbor discovery and fixes the bidirectional problem. In addition to= the other security pieces and leveraging of CDS algorithms found in either S= MF or OLSRv2 one could build a similar protocol with only the addition of a m= essage type and a few TLVS. The two that jump out at me for being useful bey= ond just this proposed protocol would be GPS and Application/Higher Layer ID= TLV encodings. >=20 > Justin Dean >=20 >> On Wed, Jan 4, 2017 at 5:10 AM, Dearlove, Christopher (UK) wrote: >> There some immediate retrograde steps compared to existing protocols: fix= ed message format (making adding new information to be used by the protocol h= ard), forwarding by blind flooding (hence scalability issues), and no securi= ty (an example of something that to add would require a changed format). The= rather peculiar link metric (in effect) that mixes hop count, time and batt= ery power leads to many questions (and while not simply hop count is likely t= o be a backward step in flexibility). There=E2=80=99s a rather unusual messa= ge body that is not used by this protocol but said to be for the application= , which is a bit of a layering issue. GPS is included with no indication how= to use and hence no indication why it is there. They are also underspecifie= d in terms of format information (and for GPS at least even size of field). T= here=E2=80=99s quite a lot underspecified, such as route determination, and t= here=E2=80=99s no consideration of how the acknowledgements are used - and e= ven what the meaning of acknowledgements in what must be (but is not so desc= ribed) as a local broadcast/multicast message (with potentially unknown reci= pients). I don=E2=80=99t see any handling of the problems that link asymmetr= y produces. I=E2=80=99d have issues over timing parameters and their managem= ent (these being not reflected in the message). And in a proposed IETF proto= col, I don=E2=80=99t see any IP addresses. That it hasn=E2=80=99t even caugh= t up with the existence of RFC 7181 (only quoting RFC 3626) is not a good si= gn. It is suggested that RFC 3626 (and hence, no doubt, RFC 7181) is too com= plex. That may or may not be so (there are reasons for the added complexity i= n RFC 7181, which need to be understood before deciding whether you need the= m) and there thus may or may not be a space for a lightweight proactive prot= ocol, but this is not that protocol in current or foreseeable evolutionary f= orm. >>=20 >> =20 >>=20 >> -- >>=20 >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> _________________________________________________________________________= _ >>=20 >> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>=20 >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddo= w, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >>=20 >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >>=20 >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>=20 >> =20 >>=20 >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi Yi >> Sent: 04 January 2017 09:08 >> To: Peter S Lau (peterlau) >> Cc: manet@ietf.org >> Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refr= esh" >>=20 >> =20 >>=20 >> =20 >>=20 >> *** WARNING *** >>=20 >> This message originates from outside our organisation, either from an ext= ernal partner or the internet. >> Consider carefully whether you should click on any links, open any attach= ments 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. >>=20 >> *** WARNING *** >> EXTERNAL EMAIL -- This message originates from outside our organization. >>=20 >> =20 >>=20 >> Dear Peter,=20 >>=20 >> =20 >>=20 >> Thanks very much for your draft.=20 >>=20 >> =20 >>=20 >> Looking at the overview section: >>=20 >> =20 >>=20 >> TRP is a table-driven proactive data forwarding protocol and at the >>=20 >> same time allows users to announce their presence to the network. A >>=20 >> node, wishing to be contacted, periodically broadcasts control >>=20 >> messages about itself to the network. A node, receiving control >>=20 >> messages, caches an optimal path to each of the originators of the >>=20 >> control messages. =20 >>=20 >> =20 >>=20 >> Could you please briefly introduce what=E2=80=99s the difference between T= RP and other proactive protocols like OLSR(v2)? >>=20 >> =20 >>=20 >> Especially, it would be very helpful for the readers to understand by pro= viding a bit more text about the mechanism of the protocol in the overview.=20= >>=20 >> =20 >>=20 >> best >>=20 >> =20 >>=20 >> Jiazi >>=20 >> =20 >>=20 >> On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) wr= ote: >>=20 >> =20 >>=20 >> Dear manet Working Group: >>=20 >> I have uploaded a proposed draft entitled "draft-peterlau-manet-topology-= refresh-00". for the WG to consider. >>=20 >> Regards, >> Peter Lau >>=20 >> =20 >>=20 >> Peter Lau >> The University of Memphis >> Electrical and Computer Engineering >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> =20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-A8E6B63B-FF5A-44A7-967A-60AB75E715C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On the contrary, that's exactly the so= rt of scenario OLSRv2, and before it OLSR were developed for. Well, for OLSR= it was laptops and PDAs. Several of us have networked such devices in that w= ay.

Delay in OLSRv2 is a function of its parameters. It's not meaningful to= define a single delay value. I've yet to see why you think TRP is inherentl= y faster.

The comments about smartphones and routers completely misses the p= oint. A router is a function, not a device. If you run OLSRv2 in a smartphon= e, the smartphone is a router.

The comment about OLSRv2 not knowing who is i= n the network is simply wrong.

At that point I've just decided to stop answ= ering point by point. I suggest first understanding what exists, and why it h= as the features it has, before trying to suggest you have something better.<= /div>

--  

On 9 Jan 2017, at= 20:06, Peter S Lau (peterlau) <p= eterlau@memphis.edu> wrote:

Dear all:

Thank you for the comments. I am going to respond to some comments and
leave the others at a later time.

Thanks,

Peter Lau



1. Response to the comment "there thus may or may not be a space for a
lightweight proactive protocol" made by Christopher.

1.a TRP is intended for nearby social network where people are moving
around with smartphones (installed with TRP) discover and communicate
with each other on the fly when they move into the vicinity of each
other. I believe OLSR/OLSv2 and others were not conceived to support such an application. I list three requirements that may justify a space for a lightweight protocol, like TRP.

1.b Delay is very important in highly interactive applications, such as
= nearby social network, that must be kept low. This calls for a proactive protocol. For such a real-time interactive application, it is reasonably to expect the response time to be a fraction of a second. Performance
study in [WTS2015] shows that TRP achieves sub-second message end-to-end delay. A rough estimate of OLSR/OLSRv2 message end-to-end delay includes HNDP (link break detection) delay, TC message delay, and routing set
calculation delay. An experiment done in [www.dtic.mil/cgi-bin/
GetTRDoc?AD=3DADA521173] has demonstrated that the delay for OLSR is
multiple seconds for a 18-node manet. Perhaps, solely from the delay
perspective for the intended application, a lightweight protocol, like
TRP, is warranted.

1.c Conserving battery energy for smartphones is another important issue. TRP attacks the problem in two fronts: less taxing the CPU with a
lightweight protocol and selecting forwarding paths to exclude devices
with low remaining battery energy. By contrast, OLSR/OLSRv2 are running
= in routers (which are not smartphones) and presummably have no energy
depletion issue.

1.d Participants in a nearby social network are constantly and rapidly
changing. Users need to know who are in the network to be able to select them to chat. TRP solves the problem by periodically presenting to the
users with an updated list of all users who are happen nearby, i.e., in
= the nearby social network. OLSR/OLSRv2 and others do not have such
capability essential to nearby social networks.

1.e The above argue for a lightweight protocol for nearby social
networks. I think we need to decide first whether there is a space for a lightweight protocol, like TRP. Are there any existing protocols that can support nearby social network applications?

2. Response to the comment "Could you please briefly introduce what's the difference between TRP and other proactive protocols like OLSR(v2)?" made by Jiazi

2.a OLSR/OLSRv2 use MPRs to aggregate LS information to thereby reducing LS flooding overhead and for topology reduction. The current form of TRP does not aggregate type 2 control information. After some thought,
aggregation may be possible in TRP, any ideas?

2.b While OLSR/OLSRv2 requires neighborhood discovery, TRP does not,
contributing to its light weight. Because nearby social networks are
highly dynamic (users are constantly moving), a discovered neighborhood
= could quickly become outdated.

2.c While OLSR/OLSRv2 carry out routing set calculation from the network topology graph after receiving TC messages for the link states, TRP
creates and updates forwarding entries on the fly when processing
individual control messages, eliminating the extra calculations. This
contributes to the TRP's light weight.

2.d While OLSR/OLSRv2 can actively remove advertised content, TRP relies on timeout to remove users, who have left the network, from the user
list.

2.e While OLSR/OLSRv2 requires bidirectional links, TRP does not test if a link is bidirectional because directionality could quickly change as
users are moving around. After some thought, it makes sense that once a
= node has chosen the next node for a destination, the node confirms the
bidirectional link between the next node and itself.

2.f TRP supports devices with and without cellular data, with and without a connection to an access point, and therefore, they may or may not have an IP address. A TRP node self-assigns a node id (which is neither a 4-
byte nor 16-byte IP address but a 2-byte quantity for overhead
efficiency) and relies on id collision detection. Unique IP addresses are configured (or by some other means) into OLSR/OLSRv2 routers.

2.g While OLSR/OLSRv2 operates up to the transport layer, TRP remains in the data link layer.

2.h Smartphones have very limited battery energy but OLSR/OLSRv2 routers do not have energy limitation.

2.i A TRP user can dynamically limit other users to within a physical
distance from herself. OLSR/OLSRv2 do not have such capability.

2.j A TRP user is constantly updated with a list of users within a
distance from her. OLSR/OLSRv2 do not have such capability.

2.k TRP users can independently choose how frequent to broadcast their
presence in the network. OLSR/OLSRv2 do not allow such an option.

2.l While OLSR/OLSRv2 are optimized for large and dense networks, TRP
must support large/small and dense/sparse networks.

2.m While OLSR/OLSRv2 supports security, TRP in its current state does
not call for security. I cannot think of scenarios that require security in a nearby social network application. Any ideas?

2.n I think the protocol differences are due to the different intended
applications.

3. Response to the comment "Especially, it would be very helpful for the readers to understand by providing a bit more text about the mechanism of the protocol in the overview" made by Jiazi

3.a A node (say node X), upon receiving a control message, knows the node who originated the message (say Node S, the originator) and the node from which the message was received (say Node N, the forwarder). It is because the originator puts its id in the control message and the forwarder
modifies the message by putting its id in it before retransmitting it. N must be a neighbor of X. For example, if S sent the message, then N =3D S.
3.b An entry (destination node, forwarding node) =3D (S, N) in the
forwarding table is either created or updated in X. Of course the entry
= contains other information such as sequence number, hop count, etc.)

3.c When X needs to forward a user message to S, X will transmit it to N. The user message may be generated locally in X or forwarded to X by a
neighbor of X.

3.d It is entirely possible that X receives two or more control messages, each with the same originator but different forwarders. Among these
control messages, X will select the one based on the sequence number, hop count, etc. to create or update the entry. The other control messages are discarded.

3.e X then modifies the selected message by putting its id in it and
retransmits it.

3.f As the control messages, with S as the originator, propagate
throughout the network, a tree rooted at S is built. The size of the tree is limited by the maximum allowable hop count and the physical distance
= between S and a leaf node.

3.g Since every node originates control messages, the result is a
complete topology of end-to-end paths.

3.h The tree rooted at a node is updated every time the node transmits a control message. Since every node periodically transmits control
messages, the result is that the topology is constantly tracking the
movement of the users.

Peter Lau
The University of Memphis
Electrical and Computer Engineering


From: Justin Dean <bebemaster@gmail.com>
Sent: Wednesday, January 4, 2017 9:46 AM
To: Peter S Lau (peterlau)
Cc: Jiazi Yi; manet@ietf.org; D= earlove, Christopher (UK)
Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-= refresh"
 
Thank you for the submission. I too have some misgivings ab= out the documents current state and tradeoffs with regard to packet format a= nd lack of use of the Manet building blocks which seem like they could be ea= sily incorporated. RFC5444 has Hop-limit/count and sequence number fields, and NHDP (RFC6130) has neighbor= discovery and fixes the bidirectional problem. In addition to the other sec= urity pieces and leveraging of CDS algorithms found in either SMF or OLSRv2 o= ne could build a similar protocol with only the addition of a message type and a few TLVS. The two that jump o= ut at me for being useful beyond just this proposed protocol would be GPS an= d Application/Higher Layer ID TLV encodings.

Justin Dean

On Wed, Jan 4, 2017 at 5:10 AM, Dearlove, Christo= pher (UK) <chris.dearlove@baesystems.com> wrote:

There some immediate retr= ograde steps compared to existing protocols: fixed message format (making ad= ding new information to be used by the protocol hard), forwarding by blind flooding (hence scalability issues), and no security (a= n example of something that to add would require a changed format). The rath= er peculiar link metric (in effect) that mixes hop count, time and battery p= ower leads to many questions (and while not simply hop count is likely to be a backward step in flexibil= ity). There=E2=80=99s a rather unusual message body that is not used by this= protocol but said to be for the application, which is a bit of a layering i= ssue. GPS is included with no indication how to use and hence no indication why it is there. They are also underspec= ified in terms of format information (and for GPS at least even size of fiel= d). There=E2=80=99s quite a lot underspecified, such as route determination,= and there=E2=80=99s no consideration of how the acknowledgements are used - and even what the meaning of acknowledgemen= ts in what must be (but is not so described) as a local broadcast/multicast m= essage (with potentially unknown recipients). I don=E2=80=99t see any handli= ng of the problems that link asymmetry produces. I=E2=80=99d have issues over timing parameters and their manageme= nt (these being not reflected in the message). And in a proposed IETF protoc= ol, I don=E2=80=99t see any IP addresses. That it hasn=E2=80=99t even caught= up with the existence of RFC 7181 (only quoting RFC 3626) is not a good sign. It is suggested that RFC 3626 (and hence, no doub= t, RFC 7181) is too complex. That may or may not be so (there are reasons fo= r the added complexity in RFC 7181, which need to be understood before decid= ing whether you need them) and there thus may or may not be a space for a lightweight proactive protocol, b= ut this is not that protocol in current or foreseeable evolutionary form.=

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
_______________________________= ___________________________________________

T: &n= bsp;+44 (0)1245 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

 

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi Yi
Sent: 04 January 2017 09:08
To: Peter S Lau (peterlau)
Cc: manet@ietf.or= g
Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topo= logy-refresh"

 

 

*** WARNING ***

This message originates from outside our organ= isation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments o= r reply.
For= information regarding Red Flags that you can look out for in emails you receive, click here.
If y= ou feel the email is suspicious, please follow this process.=

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our= organization.

 

Dear Peter, 

 

Thanks very much for your draft. <= /p>

 

Looking at the overview section:

 

   TRP is a table-driven proactive data for= warding protocol and at the

   same time allows users to announce their= presence to the network.  A

   node, wishing to be contacted, periodica= lly broadcasts control

   messages about itself to the network.&nb= sp; A node, receiving control

   messages, caches an optimal path to each= of the originators of the

   control messages.  

 

Could you please briefly introduce what=E2=80=99s the= difference between TRP and other proactive protocols like OLSR(v2)?<= u>

 

Especially, it would be very helpful for the readers t= o understand by providing a bit more text about the mechanism of the protoco= l in the overview. 

 

best

 

Jiazi

 

On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) <<= a href=3D"mailto:peterlau@memphis.edu" target=3D"_blank">peterlau@memphis.ed= u> wrote:

 

Dear manet Working Group:

I have uploaded a proposed draft entitled "draft-peterlau-manet-topolog= y-refresh-00". for the WG to consider.

Regards,
Peter Lau

 

Peter Lau
The University of Memphis
Electrical and Computer Engineering

__________________________________= _____________
manet mailing list
man= et@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 

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


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


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-A8E6B63B-FF5A-44A7-967A-60AB75E715C4-- From nobody Wed Jan 11 15:15:59 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC631295C9; Wed, 11 Jan 2017 15:15:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148417655478.8211.17190680386465568609.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 15:15:54 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-sec-threats-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 23:15:55 -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 of the IETF. Title : Security Threats to the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Thomas Clausen Ulrich Herberg Jiazi Yi Filename : draft-ietf-manet-olsrv2-sec-threats-04.txt Pages : 24 Date : 2017-01-11 Abstract: This document analyzes common security threats that might apply to 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-sec-threats-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-sec-threats-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 11 15:19:35 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2F4129542 for ; Wed, 11 Jan 2017 15:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 qEeEsCTqpkVS for ; Wed, 11 Jan 2017 15:19:31 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C0E1295E9 for ; Wed, 11 Jan 2017 15:19:31 -0800 (PST) Received: from [192.168.1.101] (95.248.86.88.rdns.comcable.net [88.86.248.95]) by mx.zohomail.com with SMTPS id 148417676679953.65251951292487; Wed, 11 Jan 2017 15:19:26 -0800 (PST) From: Jiazi Yi Content-Type: multipart/alternative; boundary="Apple-Mail=_ECA472BF-9C61-4BF8-AF6E-92578CBBAC48" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <0ADA2123-C77A-435B-AB95-F810EF93028B@jiaziyi.com> References: <148417655499.8211.1320217047081461303.idtracker@ietfa.amsl.com> To: "Alvaro Retana (aretana)" , Elwyn Davies , Joseph Salowey , manet Date: Thu, 12 Jan 2017 00:19:23 +0100 X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-olsrv2-sec-threats-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 23:19:34 -0000 --Apple-Mail=_ECA472BF-9C61-4BF8-AF6E-92578CBBAC48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all,=20 We just submitted a new revision of draft-ietf-manet-olsrv2-sec-threats. = During the IETF LC of draft-ietf-manet-olsrv2-sec-threats-03, we have = received valuable comments from Alvaro, Elwyn and Joseph. Thanks very = much! Based on the comments provided, we updated the draft. Other than = the editorial modifications, here is our reply to some of the comments = and how the ID is updated: =46rom Alvaro = (https://mailarchive.ietf.org/arch/msg/manet/K5QhTvHztC36YEU06PjbSFA0-ZA = )= : > C1. Do we really need all the references in the Introduction to = describe OSLRv2? I think that a reference to RFC7181 is enough. Trying = to be exhaustive has the risk of missing other potential references; for = example, RFC7466 Updates RFC7181, but it isn=E2=80=99t mentioned = anywhere. I=E2=80=99m not suggesting that you add a reference to = RFC7466, but that you only use RFC7181 when describing OLSRv2 (in this = part of the Introduction). It=E2=80=99s true that it=E2=80=99s a bit overwhelming to put so many = references in the first sentence. On the other hand, every component of = OLSRv2 contribute (positively or negatively) to security. E.g., 5444 is = the container for ICV TLVs, but has mutable fields (TC messages) ; 5148 = opens up for timer attacks (or, not =E2=80=A6vtime/htime constraints, = which are retained in 7181?) etc. It=E2=80=99d be incomplete to neglect = those. So we rearranged the paragraph a bit: The Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181] = is a successor to OLSR [RFC3626] as a routing protocol for MANETs = (Mobile Ad hoc NETworks). OLSRv2 retains the same basic algorithms as = its predecessor, however offers various improvements, e.g., a modular = and flexible architecture allowing extensions, such as for security, to = be developed as add-ons to the basic protocol. Such building-blocks and = modules include [RFC5148], [RFC5444], [RFC5497], [RFC6130], [RFC7182], = [RFC7183], [RFC7187], [RFC7188], [RFC7466], etc. > C9. The Security Considerations Section basically says nothing. It = would be nice to say in it that this whole document is about security = considerations =E2=80=93 and maybe include a summary (couple of = sentences). FWIW, what stuck with me is that most of the threats can be = mitigated, but many depend on RFC7183, which is not effective if the = compromised router is one with valid credentials =E2=80=93 this fact was = mentioned, but brushed over fairly quickly. A summary of the whole document is provided as suggested:=20 This document does not specify a protocol or a procedure, but reflects = on security considerations for OLSRv2, and for its constituent parts, = including NHDP. The document initially analyses threats to topology map = acquisition, with the assumption that no security mechanism (including = the mandatory-to-implement mechanisms from [RFC7182], [RFC7183]) is in = use - then, proceeds to discuss how the use of [RFC7182] and [RFC7183] = mitigate the identified threats.=20 When [RFC7183] is used with routers using a single shared key, the = protection offered is not effective if a compromised router has valid = credentials. =46rom Elwyn = (https://mailarchive.ietf.org/arch/msg/manet/A3-pw1iVKIqEaHwSVat0xhx7Xp4 = )= > s3.2: I do not know enough about the details of NHDP and OLSRv2 to > know if this is a silly question: Would it be possible for a > compromised node to perform hop-limit or hop-count modification > attacks even with RFC 6183 security in place just by modifying these > fields and reforwarding the packet even if it wasn't actually in the > network topology? If so, it would be desirable to mention this if it > can do any harm. Following the discussion in the thread = https://mailarchive.ietf.org/arch/search/?email_list=3Dmanet&gbt=3D1&index= =3DA3-pw1iVKIqEaHwSVat0xhx7Xp4 = We now have the following text in section 6.2.1:=20 Modifying the Hop Limit and the Hop Count - As the hop limit and hop count are not protected by [RFC7183] (since it = is a mutable field, changing at every hop), this attack is still = feasible. It is possible to apply [RFC5444] packet-level protection by = using ICV Packet TLV defined in [RFC7182]. However, in such case, the = hop-by-hop verification requires trust between each pair of neighbor = routers . =20 > s6: I am unclear whether the RFC 6183 security mitigates all the > threats mentioned here and in RFC 7186. It would be useful to list > any that remain unmitigated at the end of s9 as items for further > study (or say that all of these are covered). =20 We added a summary in the last section (security considerations).=20 =46rom Joseph Salowey > One issue that I did not see discussed in the draft would be for the = attacker to effectively delay packets. For example, the attacker = captures packets while jamming to prevent some stations from receiving = packets. The attacker can collect a sequence of traffic and replay at a = later time, with different timing and in a different location. Not all = replay mechanisms will defend against this attack int he same way. = Sequence number validation (which appears to be allowed in 7183) may = not be as effective as timestamps, depending upon the time skew allowed. = The document does discuss timestamps , but I think it should probably = make the following clearer: >=20 > There are several places in sections 4 and 5 where the document says = something like "This kind of attack can be mitigated using integrity = check mechanisms". I think in most of these instances replay protection = is also important. One solution would be to remove these instances and = just relay on section 6.2 which has a better description of the = available protections. Since it seems that the integrity check could = be deployed with just sequence number instead of timestamps it might be = good to mention that it is important to include and verify timestamps = for replay protection.=20 We have removed related sentences and relayed to section 6.2.=20 Again, thanks very much for your review! cheers Jiazi > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-manet-olsrv2-sec-threats-04.txt > Date: 12 January 2017 at 00:15:54 GMT+1 > To: "Thomas Clausen" , "Thomas Clausen" = , "Jiazi Yi" , "Ulrich = Herberg" , >=20 >=20 > A new version of I-D, draft-ietf-manet-olsrv2-sec-threats-04.txt > has been successfully submitted by Jiazi Yi and posted to the > IETF repository. >=20 > Name: draft-ietf-manet-olsrv2-sec-threats > Revision: 04 > Title: Security Threats to the Optimized Link State = Routing Protocol version 2 (OLSRv2) > Document date: 2017-01-12 > Group: manet > Pages: 24 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-sec-threats-0= 4.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-manet-olsrv2-sec-threats-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-sec-threats-04= >=20 > Abstract: > This document analyzes common security threats that might apply to > 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. >=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=_ECA472BF-9C61-4BF8-AF6E-92578CBBAC48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear all, 

We just submitted a new revision = of draft-ietf-manet-olsrv2-sec-threats. During the IETF LC of = draft-ietf-manet-olsrv2-sec-threats-03, we have received valuable = comments from Alvaro, Elwyn and Joseph. Thanks very much! Based on the = comments provided, we updated the draft. Other than the editorial = modifications, here is our reply to some of the comments and how the ID = is updated:

=46r= om Alvaro (https://mailarchive.ietf.org/arch/msg/manet/K5QhTvHztC36YEU06Pj= bSFA0-ZA):

C1. Do we really need = all the references in the Introduction to describe OSLRv2?  I think = that a reference to RFC7181 is enough.  Trying to be exhaustive has = the risk of missing other potential references; for example, RFC7466 = Updates RFC7181, but it isn=E2=80=99t mentioned anywhere.  I=E2=80=99= m not suggesting that you add a reference to RFC7466, but that you only = use RFC7181 when describing OLSRv2 (in this part of the = Introduction).

It=E2=80=99s true that it=E2=80=99s a bit overwhelming to = put so many references in the first sentence. On the other hand, =  every component of OLSRv2 contribute (positively or negatively) to = security. E.g., 5444 is the container for ICV TLVs, but has mutable = fields (TC messages) ; 5148 opens up for timer attacks (or, not = =E2=80=A6vtime/htime constraints, which are retained in 7181?) etc. = It=E2=80=99d be incomplete to neglect those. So we rearranged the = paragraph a bit:

The Optimized Link State Routing = Protocol version 2 (OLSRv2) [RFC7181] is a successor to = OLSR [RFC3626] as a routing protocol for MANETs (Mobile = Ad hoc NETworks). OLSRv2 retains the same basic algorithms as its = predecessor, however offers various improvements, e.g., a modular = and flexible architecture allowing extensions, such as = for security, to be developed as add-ons to the basic protocol. = Such building-blocks and modules = include [RFC5148], [RFC5444], [RFC5497], [RFC6130],&nb= sp; [RFC7182], [RFC7183], [RFC7187], [RFC7188], [= RFC7466], etc.

C9. The Security Considerations Section = basically says nothing.  It would be nice to say in it that this = whole document is about security considerations =E2=80=93 and maybe = include a summary (couple of sentences).  FWIW, what stuck with me = is that most of the threats can be mitigated, but many depend on = RFC7183, which is not effective if the compromised router is one with = valid credentials =E2=80=93 this fact was mentioned, but brushed = over fairly quickly.

A summary of the whole document is = provided as suggested: 

This = document does not specify a protocol or a procedure, but reflects on = security considerations for OLSRv2, and for its constituent parts, = including NHDP. The document initially analyses threats to topology map = acquisition, with the assumption that no security mechanism = (including the mandatory-to-implement mechanisms = from [RFC7182], [RFC7183]) is in use - then, proceeds to = discuss how the use = of [RFC7182] and [RFC7183] mitigate the = identified threats. 

When  [RFC7183] is used with routers using a = single shared key, the protection offered is not effective if a = compromised router has valid = credentials.

=46rom Elwyn (https://mailarchive.ietf.org/arch/msg/manet/A3-pw1iVKIqEaHwSVat= 0xhx7Xp4)

s3.2: =  I do not know enough about the details of NHDP and OLSRv2 to
know if this is a silly question:  Would it be possible = for a
compromised node to perform hop-limit or hop-count = modification
attacks even with RFC 6183 security in place = just by modifying these
fields and reforwarding the packet = even if it wasn't actually in the
network topology?   = If so, it would be desirable to mention this if it
can do = any harm.

Following the discussion in the thread https://mailarchive.ietf.org/arch/search/?email_list=3Dmanet&am= p;gbt=3D1&index=3DA3-pw1iVKIqEaHwSVat0xhx7Xp4

We now have the = following text in section 6.2.1: 

Modifying the Hop Limit = and the Hop Count -
As the hop limit and hop count are not = protected by [RFC7183] (since it is a mutable field, changing = at every hop), this attack is still feasible. It is possible to = apply [RFC5444] packet-level protection by using ICV Packet = TLV defined in [RFC7182].  However, in such case, the = hop-by-hop verification requires trust between each pair of neighbor = routers .  

s6:  I am unclear = whether the RFC 6183 security mitigates all the
threats = mentioned  here and in RFC 7186.  It would be useful to = list
any that remain unmitigated at the end of s9 as items = for further
study (or say that all of these are covered). =   

We added a = summary in the last section (security = considerations). 

=46rom Joseph Salowey

One issue that I did not see = discussed in the draft would be for the attacker to effectively delay = packets.  For example, the attacker captures packets while = jamming to prevent some stations from receiving packets.  The = attacker can collect a sequence of traffic and replay at a later time, = with different timing and in a different location.  Not all = replay mechanisms will defend against this attack int he same way. =  Sequence number validation (which appears to be allowed =  in 7183) may not be as effective as timestamps, depending upon the = time skew allowed.  The document does discuss timestamps , but = I think it should probably make the following clearer:

There are several places in sections 4 and 5 where the = document says something like "This kind of attack can be mitigated using = integrity check mechanisms".  I think in most of these = instances replay protection is also important.  One solution would = be to remove these instances and just relay on section 6.2 which = has a better description of the available protections.   Since it = seems that the integrity check could be deployed with just sequence = number instead of timestamps it might be good to mention that it is = important to include and verify timestamps for replay = protection. 

We have removed related sentences and = relayed to section 6.2. 

Again, thanks very much for your = review!

cheers

Jiazi


Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-ietf-manet-olsrv2-sec-threats-04.txt
Date: = 12 January 2017 at 00:15:54 = GMT+1
To: = "Thomas Clausen" <t.clausen@computer.org>, "Thomas Clausen" <T.Clausen@computer.org>, "Jiazi Yi" <jiazi@jiaziyi.com>, = "Ulrich Herberg" <ulrich@herberg.name>, <manet-chairs@ietf.org>


A new version = of I-D, draft-ietf-manet-olsrv2-sec-threats-04.txt
has = been successfully submitted by Jiazi Yi and posted to the
IETF repository.

Name: = draft-ietf-manet-olsrv2-sec-threats
Revision: 04
Title:= = Security Threats to the Optimized Link State Routing Protocol = version 2 (OLSRv2)
Document date: = 2017-01-12
Group: manet
Pages: 24
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-se= c-threats-04.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-th= reats/
Htmlized: =       https://tools.ietf.org/html/draft-ietf-manet-olsrv2-sec-threats= -04
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-sec= -threats-04

Abstract:
=   This document analyzes common security threats that might = apply to
  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


= --Apple-Mail=_ECA472BF-9C61-4BF8-AF6E-92578CBBAC48-- From nobody Wed Jan 11 15:23:25 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13861129DC3; Wed, 11 Jan 2017 15:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 UV7IaPEsRHj3; Wed, 11 Jan 2017 15:23:21 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38414129DA4; Wed, 11 Jan 2017 15:23:21 -0800 (PST) Received: from [192.168.1.101] (95.248.86.88.rdns.comcable.net [88.86.248.95]) by mx.zohomail.com with SMTPS id 14841769979751022.9174540370219; Wed, 11 Jan 2017 15:23:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Jiazi Yi In-Reply-To: <148360528696.20579.6013305676126157111.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 00:23:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148360528696.20579.6013305676126157111.idtracker@ietfa.amsl.com> To: Benoit Claise X-Mailer: Apple Mail (2.3259) Archived-At: Cc: victor@jvknet.com, manet , draft-ietf-manet-olsrv2-sec-threats@ietf.org, The IESG , Mobile Ad-hoc Networks Working Group Subject: Re: [manet] Benoit Claise's No Objection on draft-ietf-manet-olsrv2-sec-threats-03: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 23:23:23 -0000 Dear Benoit,=20 Thanks very much for your detailed review.=20 A new revision (-04) has been updated considering the comments provided.=20= Other than the editorial issues, we added a short subsection 6.3 to call = out the importance of correct deployment for mitigating some of the = vulnerabilities.=20 regards Jiazi > On 5 Jan 2017, at 09:34, Benoit Claise wrote: >=20 > Benoit Claise has entered the following ballot position for > draft-ietf-manet-olsrv2-sec-threats-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Below is cut/pasted Victor Kuarsingh's OPS DIR review. >=20 > Summary: >=20 > The document analyzes currently assessed (known) security threats for = the > OLSRv2 protocol and how these threats may impact a Mobile Ad Hoc = Network > (MANET). The document points to reference documents such as RFC7186, > RFC7183, RFC7188 and RFC7181 and expands on the explanation of = security > vulnerabilities and how such vulnerabilities can be mitigated by > currently documented security mechanisms. >=20 > Text updates (suggestions / recommendations) are provided below the > general feedback. >=20 > General Comments and Feedback: >=20 > Overall the document does cover the intention described per the = abstract > (summarized above). Descriptions of the vulnerabilities seem = consistent > with documents such as RFC7186 and RFC8183 which already cover = detailed > explanation of similar material. =20 >=20 > A few comments are noted in the in-line text overview below (some NITs = / > suggestions on wording), and a preference for avoiding such = conventions > which use taxonomy like "fresh", "lie" with preference for other = options > like "recent", "incorrect/ erroneous " may be better suited for such a > document. >=20 > Given this document is attempting to provide a incremental analysis of > the security threats vs. how such threats fair with known security > mechanisms in place, I would recommend that the a slight incremental = bit > of text (in-line or separate table) to show which mechanisms are = purely > related to implementation level protection (i.e. software written to > enable protocol function) vs. deployment level options. It appears = most > of the protections are implementation level, but there seems to (at > least) two examples of mitigations which may be deployment level (e.g. = it > was noted about IP forwarding on Linux boxes as well as wormholes = which > create [potentially undesirable] direct comm paths between = participating > nodes.). I think noting surveillance related activity for compromised > hosts may also be useful to discuss in section 6 (hard to detect, but = a > potential threat). >=20 > Other then that, I find the document useful as an analysis which > discusses how the known threats are potentially mitigated by known > mitigations. There are a few more editing items that can be found, = but > that can be addressed by the RFC editor. >=20 > Section Review of - Security Threats for the Optimized Link State > Routing Protocol version 2 (OLSRv2) >=20 >=20 > Abstract - ok >=20 >=20 > Introduction=20 >=20 >=20 > 1. P2=20 >=20 > operating with the assumption, that participants can >=20 > be "trusted" to behave in a non-destructive way, is utopia. >=20 > >=20 > operating with the assumption, that participants can >=20 > be "trusted" to behave in a non-destructive way, is utopian. >=20 >=20 > P4 >=20 > A first step towards hardening against attacks disrupting the >=20 > connectivity of a network, is to understand the vulnerabilities of >=20 > routing protocol, >=20 > A first step towards hardening against attacks disrupting > the >=20 > connectivity of a network, is to understand the vulnerabilities of > the >=20 > routing protocol, >=20 >=20 > 1.1. OSLRv2 Overview >=20 >=20 > P1 >=20 > They are described in the below with sufficient.. >=20 > They are described in the sections below with sufficient.. >=20 >=20 > 1.1.1. Neighbour Discovery >=20 >=20 > Good >=20 >=20 > 1.1.2 MPR Selection >=20 >=20 > Good >=20 >=20 > 1.2 Link State Advertisement=20 >=20 >=20 > OK >=20 >=20 > 1.3 OLSRv2 Attack Vectors >=20 >=20 > ** use of honestly, lie, etc **. >=20 >=20 > 2. Terminology >=20 >=20 > ** for compromised router, it=E2=80=99s possible that only = surveillance is the > goal (may not actually send erroneous or incorrect information) ** . = This > may not be detectable, but dangerous none-the-less. >=20 >=20 > 3. Topology Map Acquisition >=20 >=20 > OK >=20 >=20 > 3.1 Attack on Jittering >=20 >=20 > OK >=20 >=20 > 3.2 Hop-Count and Hop-limit Attacks >=20 >=20 > OK >=20 >=20 > 3.2.1 Modifying the Hop Limit >=20 >=20 > OK >=20 >=20 > 3.2.2 Modifying the Hop Count >=20 >=20 > OK >=20 >=20 > 4. Effective Topology >=20 >=20 > OK >=20 >=20 > 4.1 Incorrect Forwarding >=20 >=20 > ** IP forwarding can also be turned of on commercial routers as well = via > config - quite easily ** Likely ops level mitigation needed. >=20 >=20 > 4.2 Wormholes >=20 >=20 > ** comment on section above. ** >=20 >=20 > 4.3 Sequence Number Attacks >=20 >=20 > P1 >=20 > Not sure the word =E2=80=9Cfresher=E2=80=9D in the sentence = =E2=80=9Clong paths or > other delays, is not allowed to >=20 > overwrite fresher information=E2=80=9D is the best choice. = Technically, the > latter arriving message due to delay/etc is fresher from the receivers > point of view, but less desirable given the delay or path. >=20 >=20 > 4.3.1 Message Sequence Number >=20 >=20 > similar to above comment, perhaps =E2=80=9Crecent=E2=80=9D = is a better word to > use vs. =E2=80=9CFresh=E2=80=9D in the sentence =E2=80=9C=E2=80=9DRouter= s will retain this larger ANSN as > "the most fresh information" and =E2=80=A6=E2=80=9D=E2=80=9D >=20 >=20 > 4.4 Indirect Jamming=20 >=20 >=20 > OK >=20 >=20 > 5. Inconsistent Topologies >=20 >=20 > OK >=20 >=20 > 5.1 Identity Spoofing >=20 >=20 > OK >=20 >=20 > 5.2 Link Spoofing >=20 >=20 > OK >=20 >=20 > 5.2.1 Inconsistent Topology Maps due to Link State Advertisements=20 >=20 >=20 > 6. Mitigation of Security Vulnerabilities for OLSRv2 >=20 >=20 > OK >=20 >=20 > 6.1 Inherent OLSRv2 Resilience >=20 >=20 > OK >=20 >=20 > 6.2 Resilience by using RFC7183 with OLSRv2 >=20 >=20 > OK >=20 >=20 > 6.2.1 Topology Map Acquisition >=20 >=20 > OK >=20 >=20 > 6.2.2 Effective Topology >=20 >=20 > OK >=20 >=20 > 6.2.3 Inconsistent Topology >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jan 11 15:26:03 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF801295C6; Wed, 11 Jan 2017 15:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 IOZODlIafu8e; Wed, 11 Jan 2017 15:25:57 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60922129542; Wed, 11 Jan 2017 15:25:57 -0800 (PST) Received: from [192.168.1.101] (95.248.86.88.rdns.comcable.net [88.86.248.95]) by mx.zohomail.com with SMTPS id 1484177152943505.7801684064684; Wed, 11 Jan 2017 15:25:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Jiazi Yi In-Reply-To: <148362287164.20543.5367631671159172919.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 00:25:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99F73546-CE48-47EF-8A38-73EE2EC62E25@jiaziyi.com> References: <148362287164.20543.5367631671159172919.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-manet-olsrv2-sec-threats@ietf.org, manet , "Dearlove, Christopher \(UK\)" , The IESG , Mobile Ad-hoc Networks Working Group Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-olsrv2-sec-threats-03: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 23:25:59 -0000 Hi,=20 Thanks very much for the comments and the reply from Chris.=20 > On 5 Jan 2017, at 14:27, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-manet-olsrv2-sec-threats-03: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > I have two things I'd like to discuss to see if > changes are needed or not: >=20 > (1) Neither this nor RFC7186 seem to consider battery > depletion attacks. Why is that ok? The battery depletion is a kind of attacks by consuming extra resources. = In RFC7186, we mentioned: In some MANETs, the routers are powered by battery. Another consequence of a DoS attack in such networks is that the power will be drained quickly by unnecessary processing, transmitting, and receiving of messages. And it=E2=80=99s true that we didn=E2=80=99t call it out in the current = draft. We made it more explicit in the new revision: In a different class of attacks, a compromised OLSRv2 router injects control traffic, designed so as to cause an in-router resource exhaustion, e.g., by causing the algorithms calculating routing tables or MPR sets to be invoked continuously, preventing the internal state of a router from converging, depleting the energy of battery-driven routers, etc. >=20 > (2) 6.2: HMAC is *not* a digital signature mechanism. > While loose terminology may be ok elsewhere, in this > case, you shouldn't do that as it can lead to wrong > conclusions. Digital signatures do provide origin > authentication of sorts, but MACs do not, especially > if keys are shared. It is not clear to me that some of > the claims in 6.2.x of attacks being mitigated are in > fact correct, given shared secrets. (Note: It could be > that the claims are correct, I didn't have time to > check back on all the vulnerability definitions, > sorry. But I'd like to check, given the defective > terminology.) We updated the term used and the phrase that Chris mentioned.=20 thanks very much! regards Jiazi=20 >=20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jan 11 15:41:45 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62D01295C6; Wed, 11 Jan 2017 15:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 5apjXHxHFwOF; Wed, 11 Jan 2017 15:41:40 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD2B129476; Wed, 11 Jan 2017 15:41:40 -0800 (PST) Received: from [192.168.1.101] (95.248.86.88.rdns.comcable.net [88.86.248.95]) by mx.zohomail.com with SMTPS id 1484178097697934.9890670472956; Wed, 11 Jan 2017 15:41:37 -0800 (PST) From: Jiazi Yi Message-Id: <2D2CBE5B-F432-4358-8819-21564259F3F2@jiaziyi.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1A3753E0-4A65-46C9-932B-9FFAB3E4C6BF" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 12 Jan 2017 00:41:34 +0100 In-Reply-To: <148358600785.13006.4415679112806345898.idtracker@ietfa.amsl.com> To: Kathleen Moriarty References: <148358600785.13006.4415679112806345898.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-manet-olsrv2-sec-threats@ietf.org, manet@ietf.org, The IESG , Mobile Ad-hoc Networks Working Group Subject: Re: [manet] Kathleen Moriarty's No Objection on draft-ietf-manet-olsrv2-sec-threats-03: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 23:41:42 -0000 --Apple-Mail=_1A3753E0-4A65-46C9-932B-9FFAB3E4C6BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Kathleen, Firstly, thanks very much for the review and comments.=20 We discussed the replay attack RFC7186 = (https://tools.ietf.org/html/rfc7186#section-4.5 = , a normative reference = of this document). And we updated the document as the SecDir suggested.=20= Hopefully it addresses your concern.=20 regards Jiazi > On 5 Jan 2017, at 04:13, Kathleen Moriarty = wrote: >=20 > Kathleen Moriarty has entered the following ballot position for > draft-ietf-manet-olsrv2-sec-threats-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The SecDir reviewer makes a good point on the draft not covering = delays > and that replay mechanisms will defend against the attack described in > different ways. The review is linked off the draft. Please ket me = know > if there is a reason to not add this threat or if you have text to > propose to address it. >=20 > Full review: > https://www.ietf.org/mail-archive/web/secdir/current/msg07028.html >=20 > Relevant section for convenience: > "One issue that I did not see discussed in the draft would be for the > attacker to effectively delay packets. For example, the attacker > captures packets while jamming to prevent some stations from receiving > packets. The attacker can collect a sequence of traffic and replay at = a > later time, with different timing and in a different location. Not = all > replay mechanisms will defend against this attack int he same way.=20 > Sequence number validation (which appears to be allowed in 7183) may = not > be as effective as timestamps, depending upon the time skew allowed. = The > document does discuss timestamps , but I think it should probably make > the following clearer: >=20 > There are several places in sections 4 and 5 where the document says > something like "This kind of attack can be mitigated using integrity > check mechanisms". I think in most of these instances replay = protection > is also important. One solution would be to remove these instances = and > just relay on section 6.2 which has a better description of the = available > protections. Since it seems that the integrity check could be = deployed > with just sequence number instead of timestamps it might be good to > mention that it is important to include and verify timestamps for = replay > protection." >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_1A3753E0-4A65-46C9-932B-9FFAB3E4C6BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear Kathleen,

Firstly, thanks very much for the = review and comments. 

We discussed the replay attack RFC7186 (https://tools.ietf.org/html/rfc7186#section-4.5, a = normative reference of this document). And we updated the document as = the SecDir suggested. 

Hopefully it addresses your concern. 

regards

Jiazi

On = 5 Jan 2017, at 04:13, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:

Kathleen Moriarty has entered the following ballot position = for
draft-ietf-manet-olsrv2-sec-threats-03: No = Objection

When responding, please keep the = subject line intact and reply to all
email addresses = included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-th= reats/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

The SecDir reviewer makes a good = point on the draft not covering delays
and that replay = mechanisms will defend against the attack described in
different ways.  The review is linked off the draft. =  Please ket me know
if there is a reason to not add = this threat or if you have text to
propose to address = it.

Full review:
https://www.ietf.org/mail-archive/web/secdir/current/msg07028.h= tml

Relevant section for convenience:
"One issue that I did not see discussed in the draft would be = for the
attacker to effectively delay packets.  For = example, the attacker
captures packets while jamming to = prevent some stations from receiving
packets.  The = attacker can collect a sequence of traffic and replay at a
later time, with different timing and in a different = location.  Not all
replay mechanisms will defend = against this attack int he same way.
Sequence number = validation (which appears to be allowed  in 7183) may not
be as effective as timestamps, depending upon the time skew = allowed.  The
document does discuss timestamps , but = I think it should probably make
the following clearer:

There are several places in sections 4 and 5 = where the document says
something like "This kind of = attack can be mitigated using integrity
check mechanisms". =  I think in most of these instances replay protection
is also important.  One solution would be to remove = these instances and
just relay on section 6.2 which has a = better description of the available
protections. =   Since it seems that the integrity check could be deployed
with just sequence number instead of timestamps it might be = good to
mention that it is important to include and verify = timestamps for replay
protection."


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

= --Apple-Mail=_1A3753E0-4A65-46C9-932B-9FFAB3E4C6BF-- From nobody Wed Jan 11 23:35:10 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA36129489; Wed, 11 Jan 2017 23:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TlPqwBx8Ew7; Wed, 11 Jan 2017 23:35:03 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD801293E4; Wed, 11 Jan 2017 23:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7264; q=dns/txt; s=iport; t=1484206502; x=1485416102; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=1lV/NyjJ06lrYMTnmIswL6ynY80k5REkUPBN9cvchHg=; b=Nercd1UMEw+NkPPbpIuE33fwErO/cWso1oNgvSkzgtBe0AU+fuugY+nB m/rSaClZUDD9xJ+queFCSFecUmZy+g6QyJmvPdflTX8LDqCi3gfkVHpHg 0MLHM/GoOC5aUg45lXd6GziwrZw39hhy6W93W8EDdtxcwvnVFkeX++lu1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAQDWMHdY/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM7AQEBAQF+A4EKg1CKCHKRIZUogg0fC4JCgzYCgk0UAQIBAQE?= =?us-ascii?q?BAQEBYyiEagEBBAEBIQ8BBTYLEAkCDgoCAiYCAicwBg0GAgEBiHwOkmWdToIli?= =?us-ascii?q?hUBAQEBAQEBAQIBAQEBAQEBARsFgQuFOoICgVmBBoQYBwQGAYMkgl4BBIh1kjW?= =?us-ascii?q?GW4p7gXeFDIMqhjiKaYd7HzhxJBIIFRU6hGiBSD01AYYoAQYIF4IXAQEB?= X-IronPort-AV: E=Sophos;i="5.33,349,1477958400"; d="scan'208";a="648710009" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 07:34:57 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0C7Yuns006135; Thu, 12 Jan 2017 07:34:56 GMT To: Jiazi Yi References: <148360528696.20579.6013305676126157111.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: Date: Thu, 12 Jan 2017 08:34:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: victor@jvknet.com, manet , draft-ietf-manet-olsrv2-sec-threats@ietf.org, The IESG , Mobile Ad-hoc Networks Working Group Subject: Re: [manet] Benoit Claise's No Objection on draft-ietf-manet-olsrv2-sec-threats-03: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 07:35:05 -0000 Thanks Jiazi, Regards, B. > Dear Benoit, > > Thanks very much for your detailed review. > A new revision (-04) has been updated considering the comments provided. > > Other than the editorial issues, we added a short subsection 6.3 to call out the importance of correct deployment for mitigating some of the vulnerabilities. > > regards > > Jiazi > >> On 5 Jan 2017, at 09:34, Benoit Claise wrote: >> >> Benoit Claise has entered the following ballot position for >> draft-ietf-manet-olsrv2-sec-threats-03: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Below is cut/pasted Victor Kuarsingh's OPS DIR review. >> >> Summary: >> >> The document analyzes currently assessed (known) security threats for the >> OLSRv2 protocol and how these threats may impact a Mobile Ad Hoc Network >> (MANET). The document points to reference documents such as RFC7186, >> RFC7183, RFC7188 and RFC7181 and expands on the explanation of security >> vulnerabilities and how such vulnerabilities can be mitigated by >> currently documented security mechanisms. >> >> Text updates (suggestions / recommendations) are provided below the >> general feedback. >> >> General Comments and Feedback: >> >> Overall the document does cover the intention described per the abstract >> (summarized above). Descriptions of the vulnerabilities seem consistent >> with documents such as RFC7186 and RFC8183 which already cover detailed >> explanation of similar material. >> >> A few comments are noted in the in-line text overview below (some NITs / >> suggestions on wording), and a preference for avoiding such conventions >> which use taxonomy like "fresh", "lie" with preference for other options >> like "recent", "incorrect/ erroneous " may be better suited for such a >> document. >> >> Given this document is attempting to provide a incremental analysis of >> the security threats vs. how such threats fair with known security >> mechanisms in place, I would recommend that the a slight incremental bit >> of text (in-line or separate table) to show which mechanisms are purely >> related to implementation level protection (i.e. software written to >> enable protocol function) vs. deployment level options. It appears most >> of the protections are implementation level, but there seems to (at >> least) two examples of mitigations which may be deployment level (e.g. it >> was noted about IP forwarding on Linux boxes as well as wormholes which >> create [potentially undesirable] direct comm paths between participating >> nodes.). I think noting surveillance related activity for compromised >> hosts may also be useful to discuss in section 6 (hard to detect, but a >> potential threat). >> >> Other then that, I find the document useful as an analysis which >> discusses how the known threats are potentially mitigated by known >> mitigations. There are a few more editing items that can be found, but >> that can be addressed by the RFC editor. >> >> Section Review of - Security Threats for the Optimized Link State >> Routing Protocol version 2 (OLSRv2) >> >> >> Abstract - ok >> >> >> Introduction >> >> >> 1. P2 >> >> operating with the assumption, that participants can >> >> be "trusted" to behave in a non-destructive way, is utopia. >> >> >> >> operating with the assumption, that participants can >> >> be "trusted" to behave in a non-destructive way, is utopian. >> >> >> P4 >> >> A first step towards hardening against attacks disrupting the >> >> connectivity of a network, is to understand the vulnerabilities of >> >> routing protocol, >> >> A first step towards hardening against attacks disrupting >> the >> >> connectivity of a network, is to understand the vulnerabilities of >> the >> >> routing protocol, >> >> >> 1.1. OSLRv2 Overview >> >> >> P1 >> >> They are described in the below with sufficient.. >> >> They are described in the sections below with sufficient.. >> >> >> 1.1.1. Neighbour Discovery >> >> >> Good >> >> >> 1.1.2 MPR Selection >> >> >> Good >> >> >> 1.2 Link State Advertisement >> >> >> OK >> >> >> 1.3 OLSRv2 Attack Vectors >> >> >> ** use of honestly, lie, etc **. >> >> >> 2. Terminology >> >> >> ** for compromised router, it’s possible that only surveillance is the >> goal (may not actually send erroneous or incorrect information) ** . This >> may not be detectable, but dangerous none-the-less. >> >> >> 3. Topology Map Acquisition >> >> >> OK >> >> >> 3.1 Attack on Jittering >> >> >> OK >> >> >> 3.2 Hop-Count and Hop-limit Attacks >> >> >> OK >> >> >> 3.2.1 Modifying the Hop Limit >> >> >> OK >> >> >> 3.2.2 Modifying the Hop Count >> >> >> OK >> >> >> 4. Effective Topology >> >> >> OK >> >> >> 4.1 Incorrect Forwarding >> >> >> ** IP forwarding can also be turned of on commercial routers as well via >> config - quite easily ** Likely ops level mitigation needed. >> >> >> 4.2 Wormholes >> >> >> ** comment on section above. ** >> >> >> 4.3 Sequence Number Attacks >> >> >> P1 >> >> Not sure the word “fresher” in the sentence “long paths or >> other delays, is not allowed to >> >> overwrite fresher information” is the best choice. Technically, the >> latter arriving message due to delay/etc is fresher from the receivers >> point of view, but less desirable given the delay or path. >> >> >> 4.3.1 Message Sequence Number >> >> >> similar to above comment, perhaps “recent” is a better word to >> use vs. “Fresh” in the sentence “”Routers will retain this larger ANSN as >> "the most fresh information" and …”” >> >> >> 4.4 Indirect Jamming >> >> >> OK >> >> >> 5. Inconsistent Topologies >> >> >> OK >> >> >> 5.1 Identity Spoofing >> >> >> OK >> >> >> 5.2 Link Spoofing >> >> >> OK >> >> >> 5.2.1 Inconsistent Topology Maps due to Link State Advertisements >> >> >> 6. Mitigation of Security Vulnerabilities for OLSRv2 >> >> >> OK >> >> >> 6.1 Inherent OLSRv2 Resilience >> >> >> OK >> >> >> 6.2 Resilience by using RFC7183 with OLSRv2 >> >> >> OK >> >> >> 6.2.1 Topology Map Acquisition >> >> >> OK >> >> >> 6.2.2 Effective Topology >> >> >> OK >> >> >> 6.2.3 Inconsistent Topology >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > . > From nobody Mon Jan 16 15:06:35 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 850AF129857; Mon, 16 Jan 2017 15:06:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148460799253.22560.4191662502788745219.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 15:06:32 -0800 Archived-At: Cc: manet-chairs@ietf.org, manet@ietf.org, draft-ietf-manet-olsrv2-sec-threats@ietf.org Subject: [manet] Stephen Farrell's No Objection on draft-ietf-manet-olsrv2-sec-threats-04: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 23:06:33 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-manet-olsrv2-sec-threats-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss points. I'm happy to chat further if that's useful. From nobody Thu Jan 19 08:19:16 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0098129629 for ; Thu, 19 Jan 2017 08:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9iSeSVUT7X9 for ; Thu, 19 Jan 2017 08:19:13 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 EF53F129476 for ; Thu, 19 Jan 2017 08:19:12 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id r185so276764ita.0 for ; Thu, 19 Jan 2017 08:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qmlOQcc3oeo8GAsXHjhx25wr7wT7lg2Mw52nE9jLRV0=; b=U2vlxnwQBzFgVoJDlKXfJhWfzTKVnU+HyHeKX6doQZviWDNEuuAYqI4OFFTNKvW9gE w8VhHyGFNwywLMMdocUzh1daGpnO6FhJaJINipw3glfHZk84DR6yJtWc/xV3sHE0fJYi 0/CFD1qvttNoPy9ZiaQVPjDDvgHGPxiozlHNxxjaJODAjXUSPCj1GwoHav7A/EFP0Kpt AwNJpD0bSYOjNSVzUS6CM6tdNyitZfnbiuOHyBq3e6OCNPetuNJjiM4/rXr7v2c2ctTB kVIao2W7v38fOEWupmJ3lyluV8ofNLv4kLMPb+U/EZVLcLVgVegQlKwI70y7gwfVTSnQ QsYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qmlOQcc3oeo8GAsXHjhx25wr7wT7lg2Mw52nE9jLRV0=; b=rCIxwksRz91hGCQMWjC023wKLYc7zmnQEGRUCxYnD0VfuOwdhCBf36a10d3yMC8208 8elm0JESboBaPoPLkTTiJeWI4yT9e/141z7ygSHk7qj96rC7Atzbn+R0ZMaMZKT+G3kj 3NHHHNna23/JYvTP/8oYZLUtWx8NFK1mrsxQ6nGI3fwpwCcZ892AuyPpRlORFhIRZTK8 grBxHMbHeKtPcLyzNOdU0MDUuPSX/dg1+FeitnGDR9VXrFbPp4Iikc2cNwf8uuZzER4X DJpumHBsqU53nGwKsti1VNo2nH6uAmeT/fxfVWIja5AOS9nG6Ft4mQgNO4s//+DUsRim dEbg== X-Gm-Message-State: AIkVDXIczam4ebNMvP1/CRDWWPtE943w0+qR6CPn/sh12OujN9AsXLa95xRc7VZY/1m+ppNOo6KQBdgVF5SU/w== X-Received: by 10.36.68.130 with SMTP id o124mr29785430ita.62.1484842752244; Thu, 19 Jan 2017 08:19:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.158.87 with HTTP; Thu, 19 Jan 2017 08:19:11 -0800 (PST) In-Reply-To: References: From: Stan Ratliff Date: Thu, 19 Jan 2017 11:19:11 -0500 Message-ID: To: MANET IETF Content-Type: multipart/alternative; boundary=001a11350cd6cb8520054674e419 Archived-At: Subject: [manet] Fwd: Call for acceptance as Working Group documents X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:19:14 -0000 --001a11350cd6cb8520054674e419 Content-Type: text/plain; charset=UTF-8 WG participants, Based on earlier complaints, we held off accepting these as WG documents. The concerns about the "log jam" of documents appears to be resolved, so I'm restarting this request. Please let the chairs know your thoughts on acceptance by Feb 2. Regards, Stan ---------- Forwarded message ---------- From: Stan Ratliff Date: Mon, Nov 28, 2016 at 10:26 AM Subject: Call for acceptance as Working Group documents To: MANET IETF Hello working group participants, One of the items identified during the WG meeting in Seoul was to formally request, via the list, Working Group adoption of 5 extension drafts related to DLEP. This email is that formal request. The drafts are: 1. https://tools.ietf.org/html/draft-cheng-manet-dlep- latency-extension-00.html 2. https://tools.ietf.org/html/draft-cheng-manet-dlep-pause-extension-00 3. https://tools.ietf.org/html/draft-cheng-manet-dlep-multi-hop-extension-00 4. https://tools.ietf.org/html/draft-cheng-manet-dlep-da-credit-extension-00 I have put all 4 extensions on this email for expediency only; please do not assume that they must be adopted as a group. The chairs would greatly appreciate thoughts from the WG, both positive and negative. For purposes of determining WG consensus, a lack of a response will be seen as indicating support for adopting the draft (e.g. silence == acceptance). Regards, Stan --001a11350cd6cb8520054674e419 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
WG participants,

Based on earlier compl= aints, we held off accepting these as WG documents. The concerns about the = "log jam" of documents appears to be resolved, so I'm restart= ing this request. Please let the chairs know your thoughts on acceptance by= Feb 2.=C2=A0

Regards,
Stan
---------- Forwarded message ----------
Fro= m: Stan Ratliff <ratliffstan@gmail.com><= br>Date: Mon, Nov 28, 2016 at 10:26 AM
Subject: Call for acceptance as W= orking Group documents
To: MANET IETF <manet@ietf.org>


Hello working group = participants,

One of the items identified during the WG = meeting in Seoul was to formally request, via the list, Working Group adopt= ion of 5 extension drafts related to DLEP. This email is that formal reques= t.=C2=A0

The drafts are:=C2=A0

I have put all 4 extensions on this email for expediency on= ly; please do not assume that they must be adopted as a group. The chairs w= ould greatly appreciate thoughts from the WG, both positive and negative.

For purposes of determining WG consensus, a lack of= a response will be seen as indicating support for adopting the draft (e.g.= silence =3D=3D acceptance).=C2=A0

Regards,
<= div>Stan


--001a11350cd6cb8520054674e419-- From nobody Thu Jan 19 08:49:16 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED5212945A for ; Thu, 19 Jan 2017 08:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOcfmaHumO89 for ; Thu, 19 Jan 2017 08:49:13 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id F0A711293DB for ; Thu, 19 Jan 2017 08:49:12 -0800 (PST) Received: (qmail 14719 invoked by uid 0); 19 Jan 2017 16:49:10 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 19 Jan 2017 16:49:10 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id aGp51u00V2SSUrH01Gp8L1; Thu, 19 Jan 2017 09:49:09 -0700 X-Authority-Analysis: v=2.1 cv=J7g5smXS c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=IgFoBzBjUZAA:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=-JXR2q-7F0x2GqfyFLgA:9 a=WaTAf8e11ZRRhxY8:21 a=b86-bn6J2fbeTsAL:21 a=pILNOxqGKmIA:10 a=JPbjMjx8mw8A:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=RFcRYbJRPGgUw0EgOJDGSjnabOcQeSYggZ9UeUsddmg=; b=C8Rde0e9qHM6F+r+z/o6V8HHf6 bcJlKCd/3OUqW3/xXPeFI7kwPZIJFNbN2DKNKOSo3+qHTXUoM3OiyxTY2u4WNeT/RLcIlmW+rO8ZZ k+OuO4FFDKGmtIz/yx9MBBBFL; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:43227 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cUFta-0000gF-Ub; Thu, 19 Jan 2017 09:49:07 -0700 To: Stan Ratliff , MANET IETF References: From: Lou Berger Message-ID: <67fbb872-c2c6-19ec-c0c6-40a21600f959@labn.net> Date: Thu, 19 Jan 2017 11:49:03 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cUFta-0000gF-Ub X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:43227 X-Source-Auth: lberger@labn.net X-Email-Count: 19 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [manet] Fwd: Call for acceptance as Working Group documents X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:49:14 -0000 Stan, Is it safe to assume that those who responded in support, don't need to restate their position? Thanks, Lou On 1/19/2017 11:19 AM, Stan Ratliff wrote: > WG participants, > > Based on earlier complaints, we held off accepting these as WG > documents. The concerns about the "log jam" of documents appears to be > resolved, so I'm restarting this request. Please let the chairs know > your thoughts on acceptance by Feb 2. > > Regards, > Stan > > ---------- Forwarded message ---------- > From: *Stan Ratliff* > > Date: Mon, Nov 28, 2016 at 10:26 AM > Subject: Call for acceptance as Working Group documents > To: MANET IETF > > > > Hello working group participants, > > One of the items identified during the WG meeting in Seoul was to > formally request, via the list, Working Group adoption of 5 extension > drafts related to DLEP. This email is that formal request. > > The drafts are: > 1. > https://tools.ietf.org/html/draft-cheng-manet-dlep-latency-extension-00.html > > 2. https://tools.ietf.org/html/draft-cheng-manet-dlep-pause-extension-00 > > 3. https://tools.ietf.org/html/draft-cheng-manet-dlep-multi-hop-extension-00 > > 4. https://tools.ietf.org/html/draft-cheng-manet-dlep-da-credit-extension-00 > > > I have put all 4 extensions on this email for expediency only; please > do not assume that they must be adopted as a group. The chairs would > greatly appreciate thoughts from the WG, both positive and negative. > > For purposes of determining WG consensus, a lack of a response will be > seen as indicating support for adopting the draft (e.g. silence == > acceptance). > > Regards, > Stan > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Jan 19 08:51:01 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB93129448 for ; Thu, 19 Jan 2017 08:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuPFfjVb4HPR for ; Thu, 19 Jan 2017 08:50:57 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 700EC12945A for ; Thu, 19 Jan 2017 08:50:48 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id v96so42129174ioi.0 for ; Thu, 19 Jan 2017 08:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X2g0vPAyOiCtVrWPq8JPswDcucI9yd22Z759GwUbMrc=; b=H0v1g6Ym2nEXOGeDdr9/JdwqdmuiD4UtNQaU6xrgJvnaPqYgAmpQmX+/hR2fgepdRj vw2xeaNC/wxXsmXXu1gegBG1iUoRlviFJxHO5rkTqP8QQ5jE9EyqEkQE/2we+iQQfmz8 XCpidc1uGxNkOu3En40ds3twsHkJp3btW5C33nZ+zBNrlyFq0TB5hMXeHR3yAJ20sImj x+eDM7hnk/Pj30Hn3lvW67v8ohuuptavgeaLXyXMJiuxfTeIzBpgLK4Mg/tRExuy2mm+ 3GTISJ8a6fz1nyjhP4ggpwJ2d32JGAerKRw2mvZthZXurXVucQvJ6gleWRi7hF0T5Xqz g8/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X2g0vPAyOiCtVrWPq8JPswDcucI9yd22Z759GwUbMrc=; b=aBRQUhwggxBlH5GcW42zNYDCemTAuSqxq+MLmZsewRztUeWQnH7WToRe4H/Aqnjzn5 DH0YqVZpHkIwOhC99dFgyWcNUCRvNk4grOqtg4mNMvKesYA/diSqr6O5D0JiuG4x19Oj HDBzCZG/SGDx0sXyouoq1plSVDwJD0lMub3Wt7TYbB2cf6f8J1R1G8e6CNUyCNWQvow6 kONKMzSt2FPb+GVvImIfMBVrXc4sPpV6q/Ld/4H0qF7jJmmdOfpl+EUyeTlA6A9Y6yVD A9uF591IOTg8wV+HmLmqbkQd8l2UQUTDw2eaA4DEBl/qc9TozWsL36CKSdOBqGdl/5d/ /UdA== X-Gm-Message-State: AIkVDXISRD05HSVCYsvySS9feVf4vueYN4T8nmt2FsT4I0y5v3IIcomyfjIX2m3DAXd1M/Vt21S7cNPVycpAzA== X-Received: by 10.107.135.42 with SMTP id j42mr8933063iod.171.1484844647810; Thu, 19 Jan 2017 08:50:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.158.87 with HTTP; Thu, 19 Jan 2017 08:50:47 -0800 (PST) In-Reply-To: <67fbb872-c2c6-19ec-c0c6-40a21600f959@labn.net> References: <67fbb872-c2c6-19ec-c0c6-40a21600f959@labn.net> From: Stan Ratliff Date: Thu, 19 Jan 2017 11:50:47 -0500 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a113eca08c7b204054675556b Archived-At: Cc: MANET IETF Subject: Re: [manet] Fwd: Call for acceptance as Working Group documents X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:50:59 -0000 --001a113eca08c7b204054675556b Content-Type: text/plain; charset=UTF-8 Lou, Yes, that is a safe assumption. Regards, Stan On Thu, Jan 19, 2017 at 11:49 AM, Lou Berger wrote: > Stan, > > Is it safe to assume that those who responded in support, don't need > to restate their position? > > Thanks, > > Lou > > > On 1/19/2017 11:19 AM, Stan Ratliff wrote: > > WG participants, > > > > Based on earlier complaints, we held off accepting these as WG > > documents. The concerns about the "log jam" of documents appears to be > > resolved, so I'm restarting this request. Please let the chairs know > > your thoughts on acceptance by Feb 2. > > > > Regards, > > Stan > > > > ---------- Forwarded message ---------- > > From: *Stan Ratliff* > > > > Date: Mon, Nov 28, 2016 at 10:26 AM > > Subject: Call for acceptance as Working Group documents > > To: MANET IETF > > > > > > > Hello working group participants, > > > > One of the items identified during the WG meeting in Seoul was to > > formally request, via the list, Working Group adoption of 5 extension > > drafts related to DLEP. This email is that formal request. > > > > The drafts are: > > 1. > > https://tools.ietf.org/html/draft-cheng-manet-dlep- > latency-extension-00.html > > latency-extension-00.html> > > 2. https://tools.ietf.org/html/draft-cheng-manet-dlep-pause-extension-00 > > > > 3. https://tools.ietf.org/html/draft-cheng-manet-dlep-multi- > hop-extension-00 > > hop-extension-00> > > 4. https://tools.ietf.org/html/draft-cheng-manet-dlep-da- > credit-extension-00 > > credit-extension-00> > > > > I have put all 4 extensions on this email for expediency only; please > > do not assume that they must be adopted as a group. The chairs would > > greatly appreciate thoughts from the WG, both positive and negative. > > > > For purposes of determining WG consensus, a lack of a response will be > > seen as indicating support for adopting the draft (e.g. silence == > > acceptance). > > > > Regards, > > Stan > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > --001a113eca08c7b204054675556b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lou,=C2=A0

Yes, that is a safe assumpti= on.=C2=A0

Regards,
Stan


On Thu, Jan 19, 201= 7 at 11:49 AM, Lou Berger <lberger@labn.net> wrote:
Stan,

=C2=A0 =C2=A0 Is it safe to assume that those who responded in support, don= 't need
to restate their position?

Thanks,

Lou


On 1/19/2017 11:19 AM, Stan Ratliff wrote:
> WG participants,
>
> Based on earlier complaints, we held off accepting these as WG
> documents. The concerns about the "log jam" of documents app= ears to be
> resolved, so I'm restarting this request. Please let the chairs kn= ow
> your thoughts on acceptance by Feb 2.
>
> Regards,
> Stan
>
> ---------- Forwarded message ----------
> From: *Stan Ratliff* <ratl= iffstan@gmail.com
> <mailto:ratliffstan@gmail.= com>>
> Date: Mon, Nov 28, 2016 at 10:26 AM
> Subject: Call for acceptance as Working Group documents
> To: MANET IETF <manet@ietf.org <mailto:manet@ietf.org>> >
>
> Hello working group participants,
>
> One of the items identified during the WG meeting in Seoul was to
> formally request, via the list, Working Group adoption of 5 extension<= br> > drafts related to DLEP. This email is that formal request.
>
> The drafts are:
> 1.
> https://tools.ietf.= org/html/draft-cheng-manet-dlep-latency-extension-00.html
> <https://tools.i= etf.org/html/draft-cheng-manet-dlep-latency-extension-00.html= >
> 2. https://tools.ietf.org/= html/draft-cheng-manet-dlep-pause-extension-00
> <https://tools.ietf.org= /html/draft-cheng-manet-dlep-pause-extension-00>
> 3. https://tools.ietf.= org/html/draft-cheng-manet-dlep-multi-hop-extension-00
> <https://tools.ietf= .org/html/draft-cheng-manet-dlep-multi-hop-extension-00> > 4. https://tools.ietf.= org/html/draft-cheng-manet-dlep-da-credit-extension-00
> <https://tools.ietf= .org/html/draft-cheng-manet-dlep-da-credit-extension-00> >
> I have put all 4 extensions on this email for expediency only; please<= br> > do not assume that they must be adopted as a group. The chairs would > greatly appreciate thoughts from the WG, both positive and negative. >
> For purposes of determining WG consensus, a lack of a response will be=
> seen as indicating support for adopting the draft (e.g. silence =3D=3D=
> acceptance).
>
> Regards,
> Stan
>
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet=


--001a113eca08c7b204054675556b-- From nobody Fri Jan 20 07:28:12 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C175129601 for ; Fri, 20 Jan 2017 07:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.772 X-Spam-Level: X-Spam-Status: No, score=-5.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 gnFMomez0-le for ; Fri, 20 Jan 2017 07:28:07 -0800 (PST) Received: from kos.feec.vutbr.cz (kos6.feec.vutbr.cz [IPv6:2001:67c:1220:9848::93e5:480a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0001295FA for ; Fri, 20 Jan 2017 07:28:07 -0800 (PST) Received: from [147.229.146.42] (PC-SC7077-nh.utko.feec.vutbr.cz [147.229.146.42]) (authenticated bits=0) by kos.feec.vutbr.cz (8.15.2/8.14.5) with ESMTPSA id v0KFS4KL066640 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Jan 2017 16:28:05 +0100 (CET) To: manet@ietf.org From: TSP 2017 Message-ID: <58822C87.80906@feec.vutbr.cz> Date: Fri, 20 Jan 2017 16:28:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070803080102060205070905" X-Scanned-By: MIMEDefang 2.78 on 147.229.72.10 Archived-At: Subject: [manet] =?utf-8?q?TSP_2017_=7C_IEEE_R8_=7C_Barcelona=2C_Spain=2C_?= =?utf-8?q?July_5-7=2C_2017_-_40th_Int=2E_Conf=2E_on_Telecommunications_an?= =?utf-8?q?d_Signal_Processing_-_IEEE_Xplore=C2=AE_-_SCOPUS_-_Thomson_Reut?= =?utf-8?q?ers_ISI_Proceedings_-_DBLP_-_Google_Scholar?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 15:28:10 -0000 This is a multi-part message in MIME format. --------------070803080102060205070905 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Colleague, [ Weapologize if you receive multiple copies of this CfP. Please distribute this CfP to your colleagues. ] ************************************************************************************ ***INVITATION*** *2017 40th International Conference on Telecommunications and Signal Processing (TSP) July 5-7, 2017, Barcelona, Spain **Web: http://tsp.vutbr.cz/ * ************************************************************************************ Technically co-sponsored by IEEE Region 8 , EEE Spain Section , IEEE Czechoslovakia Section , IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter , and IEEE Croatia Section Communications Chapter . The TSP 2017 Proceedings, containing presented papers at the Conference, will be sent for indexing in the IEEE Xplore® Digital Library registered under _IEEE Conference Record #41294 _, SCOPUS , Conference Proceedings Citation Index (CPCI) of Thomson Reuters , DBLP , and Google Scholar databases. Authors of the best rated and presented papers will be invited for publishing in special issues of international journals. ************************************************************************************ Dear Colleague, You are kindly invited to participate in the *2017 40th International Conference on Telecommunications and Signal Processing (TSP - *http://tsp.vutbr.cz/*)*, which will be held on *July 5-7, 2017, in Barcelona, Spain*. The TSP Conference serves as a premier annual international forum to promote the exchange of the latest advances in telecommunication technology and signal processing. The aim of the Conference is to bring together both novice and experienced scientists, developers, and specialists, to meet new colleagues, collect new ideas, and establish new cooperation between research groups from universities, research centers, and private sectors from the whole Europe, America, Asia, Australia, and Africa. *TOPICS: *TSP 2017 has opened *Call for Special Session and Workshop Proposals* (deadline set for February 20, 2017) and *Call for Regular Full Paper Submissions* with a deadline February 24, 2017. We look forward to your innovative contributions in any of the following areas: * *AREA 1: Telecommunications 1. Information Systems 2. Network Services 3. Network Technologies 4. Telecommunication Systems 5. Modelling, Simulation and Measurement AREA 2: Signal Processing 6. Analog Signal Processing 7. Audio, Speech and Language Processing 8. Biomedical Signal Processing 9. Digital Signal Processing 10. Image and Video Signal Processing For more details please visit the Conference website at http://tsp.vutbr.cz/?page_id=121. *SPECIAL SESSIONS: *Prospective Organizers are invited to submit proposals for *Special Sessions and Workshops* held during the TSP 2017 Conference. The following Workshop and Special Sessions are approved so far: WS1: 7th SPLab Workshop of Signal Processing Laboratory SS1: Special Session on Image Processing to Diagnose, Monitor, and Control by Prof. Dan Popescu & Dr. Loretta Ichim (University Politehnica of Bucharest, Romania) SS2: Special Session on Fractional-Order Systems; Analysis, Synthesis and Their Importance for Future Design by Assoc. Prof. Jaroslav Koton et. al (Brno University of Technology, Czech Republic) - COST Action CA15225 MC Chair *STUDENT BEST PAPER AWARD: *In cooperation with IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter, to recognize outstanding technical contributions by students, as evidenced by the quality of papers, their presentations, and their technical excellence, the authors of the _Best 3 Student Papers_ will be awarded during the conference by the Technical Committee. /The Best Student Paper Award consists in a Certificate of Appreciation Plaque and an IEEE Student or IEEE Graduate Student membership for 2018./ *ORGANIZERS: *The TSP 2017 is IEEE technically co-sponsored Conference organized in cooperation with sixteen universities: - Brno University of Technology, Department of Telecommunications, Brno, Czech Republic - Budapest University of Technology and Economics, Department of Telecommunications and Media Informatics, Budapest, Hungary - Czech Technical University in Prague, Department of Telecommunication Engineering, Prague, Czech Republic - Isik University, Department of Electrical and Electronics Engineering, Sile/Istanbul, Turkey - Istanbul Technical University, Electronics and Communication Engineering Department, Istanbul, Turkey - Karadeniz Technical University, Department of Electrical and Electronics Engineering, Trabzon, Turkey - National Taiwan University of Science and Technology, Department of Electronic and Computer Engineering, Taipei, Taiwan - Seikei University, Graduate School and Faculty of Science and Technology, Information Networking Laboratory, Tokyo, Japan - Slovak University of Technology, Institute of Telecommunications, Bratislava, Slovak Republic - Tecnocampus, Escola Universitaria Politecnica de Mataro, Mataro, Spain - Technical University of Sofia, Faculty of Telecommunications, Sofia, Bulgaria - Universite Paris 8, UFR MITSIC, Laboratoire d'Informatique Avancee de Saint-Denis (LIASD), France - University of Ljubljana, Laboratory for Telecommunications, Ljubljana, Slovenia - University of Osijek, Faculty of Electrical Engineering, Computer Science and Information Technology Osijek, Croatia - VSB - Technical University of Ostrava, Department of Telecommunications, Ostrava, Czech Republic - West Pomeranian University of Technology, Faculty of Electrical Engineering, Szczecin, Poland *COMMITTEES: * - Miloslav Filka, Brno University of Technology, Czech Republic - Full Professor, TSP Conference Founder - Honorary Chair - Norbert Herencsar, Brno University of Technology, Czech Republic - IEEE Czechoslovakia Section CAS/COM/SP Joint Chapter Chair, IEEE Senior Member - General Co-Chair - Marcos Faundez-Zanuy, Escola Universitaria Politecnica de Mataro, Tecnocampus, Spain - Dean - General Co-Chair - Jaroslav Koton, Brno University of Technology, Czech Republic, IEEE Senior Member - Publications Chair - Jiri Hosek, Brno University of Technology, Czech Republic, IEEE Member - Student Paper Contest Chair - Aslihan Kartci, Brno University of Technology, Czech Republic - Publicity & Social Media Chair - Nandor Matrai, Asszisztencia Congress Bureau, Hungary - Managing Director - Finance Chair - Dora Kapitany, Asszisztencia Congress Bureau, Hungary - Project Manager - Registrations Chair /Steering//Committee: / - Larbi Boubchir, Université Paris 8, France - Associate Professor, IEEE Senior Member - Izzet Cem Goknar, Isik University, Turkey - Institute of Science Director & Circuits and Systems (CAS) Society Turkey Chapter Chair, IEEE Life Fellow - Ray-Guang Cheng, National Taiwan University of Science and Technology (NTUST), Taiwan - Full Professor, IEEE Senior Member - Ismail Kaya, Karadeniz Technical University, Turkey - Sridhar Krishnan, Ryerson University, Canada - Associate Dean, IEEE Senior Member - Mario Kusek, University of Zagreb, Croatia, IEEE Member - IEEE Croatia Section Communications Chapter Chair - Shahram Minaei, Dogus University, Turkey - Full Professor, IEEE Senior Member - Ram M. Narayanan, The Pennsylvania State University, USA - Full Professor, IEEE Fellow - Kimio Oguchi, Seikei University, Japan - Full Professor, IEEE Senior Member - Serdar Ozoguz, Istanbul Technical University, Turkey - Full Professor, Associate Chair - Jakub Peksinski, West Pomeranian University of Technology, Poland - Hector Perez-Meana, National Polytechnic Institute, Mexico - Full Professor, IEEE Senior Member - Vladimir Poulkov, Technical University of Sofia, Bulgaria - Dean, IEEE Senior Member - Costas Psychalinos, University of Patras, Greece - Full Professor, IEEE Senior Member - Markus Rupp, Vienna University of Technology, Austria - Dean, IEEE Fellow - Zdenek Smekal, Brno University of Technology, Czech Republic - Full Professor, IEEE Senior Member - Attila Vidacs, Budapest University of Technology and Economics, Hungary - Deputy Head of Department - Miroslav Voznak, VŠB-Technical University of Ostrava, Czech Republic - Department Chair, IEEE Senior Member - Drago Zagar, University of Osijek, Croatia - Dean, IEEE Senior Member *IMPORTANT DATES: Special Session and Workshop Proposals: *February 20, 2017* Full Paper Submission: *February 24, 2017* **Notification of Paper Acceptance: *April 14, 2017* Final Paper Submission: *April 28, 2017* Authors' Early Registration and Payment: *May 14, 2017* Authors' Late Registration and Payment: *May 24, 2017* Listeners' Registration: *July 5, 2017* * *CONTACTS: *Formore information please visit the Conference website at http://tsp.vutbr.cz/. We are also ready to answer your questions emailed to tsp@feec.vutbr.cz . Looking forward to meeting you in Barcelona, Spain. With best regards, Norbert Herencsar and Marcos Faundez-Zanuy TSP 2017 General Co-Chairs Web: http://tsp.vutbr.cz/ E-mail: tsp@feec.vutbr.cz Follow us on: - Facebook https://www.facebook.com/tspconf - Twitter https://twitter.com/tspconf =============================================================== doc. Ing. Norbert Herencsar, Ph.D., IEEE Senior Member - IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter Chair Department of Telecommunications Brno University of Technology Brno, Czech Republic & Prof. Dr. Marcos Faundez-Zanuy - Dean Escola Universitaria Politecnica de Mataro, Tecnocampus Mataro, Spain ************************************************************************************ TSP Organizers reserve the right to exclude a paper from distribution after the Conference (e.g., non-indexing in IEEE Xplore® and other databases) if the paper is not presented at the Conference. However, this paper will be distributed as part of the Conference proceedings issued on an USB drive. ************************************************************************************ *** Click to UNSUBSCRIBE , it you wish to be removed from this mailing list *** --------------070803080102060205070905 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear Colleague,

[ We apologize if you receive multiple copies of this CfP. Please distribute this CfP to your colleagues. ]

************************************************************************************
***   INVITATION   ***

2017 40th International Conference on Telecommunications and Signal Processing (TSP)
July 5-7, 2017, Barcelona, Spain
Web: http://tsp.vutbr.cz/

************************************************************************************
Technically co-sponsored by IEEE Region 8, EEE Spain Section, IEEE Czechoslovakia Section, IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter, and IEEE Croatia Section Communications Chapter.

The TSP 2017 Proceedings, containing presented papers at the Conference, will be sent for indexing in the IEEE Xplore® Digital Library registered under IEEE Conference Record #41294, SCOPUS, Conference Proceedings Citation Index (CPCI) of Thomson Reuters, DBLP, and Google Scholar databases.

Authors of the best rated and presented papers will be invited for publishing in special issues of international journals.
************************************************************************************

Dear Colleague,

You are kindly invited to participate in the 2017 40th International Conference on Telecommunications and Signal Processing (TSP - http://tsp.vutbr.cz/), which will be held on July 5-7, 2017, in Barcelona, Spain.

The TSP Conference serves as a premier annual international forum to promote the exchange of the latest advances in telecommunication technology and signal processing. The aim of the Conference is to bring together both novice and experienced scientists, developers, and specialists, to meet new colleagues, collect new ideas, and establish new cooperation between research groups from universities, research centers, and private sectors from the whole Europe, America, Asia, Australia, and Africa.

TOPICS:

TSP 2017 has opened Call for Special Session and Workshop Proposals (deadline set for February 20, 2017) and Call for Regular Full Paper Submissions with a deadline February 24, 2017. We look forward to your innovative contributions in any of the following areas:

AREA 1: Telecommunications

1. Information Systems
2. Network Services
3. Network Technologies
4. Telecommunication Systems
5. Modelling, Simulation and Measurement

AREA 2: Signal Processing

6. Analog Signal Processing
7. Audio, Speech and Language Processing
8. Biomedical Signal Processing
9. Digital Signal Processing
10. Image and Video Signal Processing

For more details please visit the Conference website at http://tsp.vutbr.cz/?page_id=121.

SPECIAL SESSIONS:

Prospective Organizers are invited to submit proposals for Special Sessions and Workshops held during the TSP 2017 Conference. The following Workshop and Special Sessions are approved so far:

WS1: 7th SPLab Workshop of Signal Processing Laboratory
SS1: Special Session on Image Processing to Diagnose, Monitor, and Control by Prof. Dan Popescu & Dr. Loretta Ichim (University Politehnica of Bucharest, Romania)
SS2: Special Session on Fractional-Order Systems; Analysis, Synthesis and Their Importance for Future Design by Assoc. Prof. Jaroslav Koton et. al (Brno University of Technology, Czech Republic) - COST Action CA15225 MC Chair

STUDENT BEST PAPER AWARD:

In cooperation with IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter, to recognize outstanding technical contributions by students, as evidenced by the quality of papers, their presentations, and their technical excellence, the authors of the Best 3 Student Papers will be awarded during the conference by the Technical Committee. The Best Student Paper Award consists in a Certificate of Appreciation Plaque and an IEEE Student or IEEE Graduate Student membership for 2018.

ORGANIZERS:

The TSP 2017 is IEEE technically co-sponsored Conference organized in cooperation with sixteen universities:

- Brno University of Technology, Department of Telecommunications, Brno, Czech Republic
- Budapest University of Technology and Economics, Department of Telecommunications and Media Informatics, Budapest, Hungary
- Czech Technical University in Prague, Department of Telecommunication Engineering, Prague, Czech Republic
- Isik University, Department of Electrical and Electronics Engineering, Sile/Istanbul, Turkey
- Istanbul Technical University, Electronics and Communication Engineering Department, Istanbul, Turkey
- Karadeniz Technical University, Department of Electrical and Electronics Engineering, Trabzon, Turkey
- National Taiwan University of Science and Technology, Department of Electronic and Computer Engineering, Taipei, Taiwan
- Seikei University, Graduate School and Faculty of Science and Technology, Information Networking Laboratory, Tokyo, Japan
- Slovak University of Technology, Institute of Telecommunications, Bratislava, Slovak Republic
- Tecnocampus, Escola Universitaria Politecnica de Mataro, Mataro, Spain
- Technical University of Sofia, Faculty of Telecommunications, Sofia, Bulgaria
- Universite Paris 8, UFR MITSIC, Laboratoire d'Informatique Avancee de Saint-Denis (LIASD), France
- University of Ljubljana, Laboratory for Telecommunications, Ljubljana, Slovenia
- University of Osijek, Faculty of Electrical Engineering, Computer Science and Information Technology Osijek, Croatia
- VSB - Technical University of Ostrava, Department of Telecommunications, Ostrava, Czech Republic
- West Pomeranian University of Technology, Faculty of Electrical Engineering, Szczecin, Poland

COMMITTEES:

- Miloslav Filka, Brno University of Technology, Czech Republic - Full Professor, TSP Conference Founder - Honorary Chair
- Norbert Herencsar, Brno University of Technology, Czech Republic - IEEE Czechoslovakia Section CAS/COM/SP Joint Chapter Chair, IEEE Senior Member - General Co-Chair
- Marcos Faundez-Zanuy, Escola Universitaria Politecnica de Mataro, Tecnocampus, Spain - Dean - General Co-Chair
- Jaroslav Koton, Brno University of Technology, Czech Republic, IEEE Senior Member - Publications Chair
- Jiri Hosek, Brno University of Technology, Czech Republic, IEEE Member - Student Paper Contest Chair
- Aslihan Kartci, Brno University of Technology, Czech Republic - Publicity & Social Media Chair
- Nandor Matrai, Asszisztencia Congress Bureau, Hungary - Managing Director - Finance Chair
- Dora Kapitany, Asszisztencia Congress Bureau, Hungary - Project Manager - Registrations Chair

Steering Committee:

- Larbi Boubchir, Université Paris 8, France - Associate Professor, IEEE Senior Member
- Izzet Cem Goknar, Isik University, Turkey - Institute of Science Director & Circuits and Systems (CAS) Society Turkey Chapter Chair, IEEE Life Fellow
- Ray-Guang Cheng, National Taiwan University of Science and Technology (NTUST), Taiwan - Full Professor, IEEE Senior Member
- Ismail Kaya, Karadeniz Technical University, Turkey
- Sridhar Krishnan, Ryerson University, Canada - Associate Dean, IEEE Senior Member
- Mario Kusek, University of Zagreb, Croatia, IEEE Member - IEEE Croatia Section Communications Chapter Chair
- Shahram Minaei, Dogus University, Turkey - Full Professor, IEEE Senior Member
- Ram M. Narayanan, The Pennsylvania State University, USA - Full Professor, IEEE Fellow
- Kimio Oguchi, Seikei University, Japan - Full Professor, IEEE Senior Member
- Serdar Ozoguz, Istanbul Technical University, Turkey - Full Professor, Associate Chair
- Jakub Peksinski, West Pomeranian University of Technology, Poland
- Hector Perez-Meana, National Polytechnic Institute, Mexico - Full Professor, IEEE Senior Member
- Vladimir Poulkov, Technical University of Sofia, Bulgaria - Dean, IEEE Senior Member
- Costas Psychalinos, University of Patras, Greece - Full Professor, IEEE Senior Member
- Markus Rupp, Vienna University of Technology, Austria - Dean, IEEE Fellow
- Zdenek Smekal, Brno University of Technology, Czech Republic - Full Professor, IEEE Senior Member
- Attila Vidacs, Budapest University of Technology and Economics, Hungary - Deputy Head of Department
- Miroslav Voznak, VŠB-Technical University of Ostrava, Czech Republic - Department Chair, IEEE Senior Member
- Drago Zagar, University of Osijek, Croatia - Dean, IEEE Senior Member

IMPORTANT DATES:

Special Session and Workshop Proposals: February 20, 2017
Full Paper Submission: February 24, 2017
Notification of Paper Acceptance: April 14, 2017
Final Paper Submission: April 28, 2017
Authors' Early Registration and Payment: May 14, 2017
Authors' Late Registration and Payment: May 24, 2017
Listeners' Registration: July 5, 2017

CONTACTS:

For more information please visit the Conference website at http://tsp.vutbr.cz/. We are also ready to answer your questions emailed to tsp@feec.vutbr.cz.

Looking forward to meeting you in Barcelona, Spain.

With best regards,

Norbert Herencsar and Marcos Faundez-Zanuy
TSP 2017 General Co-Chairs

Web: http://tsp.vutbr.cz/
E-mail: tsp@feec.vutbr.cz

Follow us on:
 - Facebook https://www.facebook.com/tspconf
 - Twitter https://twitter.com/tspconf
===============================================================
doc. Ing. Norbert Herencsar, Ph.D., IEEE Senior Member - IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter Chair
Department of Telecommunications
Brno University of Technology
Brno, Czech Republic

&

Prof. Dr. Marcos Faundez-Zanuy - Dean
Escola Universitaria Politecnica de Mataro, Tecnocampus
Mataro, Spain


************************************************************************************
TSP Organizers reserve the right to exclude a paper from distribution after the Conference (e.g., non-indexing in IEEE Xplore® and other databases) if the paper is not presented at the Conference. However, this paper will be distributed as part of the Conference proceedings issued on an USB drive.
************************************************************************************

*** Click to UNSUBSCRIBE, it you wish to be removed from this mailing list ***

--------------070803080102060205070905-- From nobody Tue Jan 24 08:18:51 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F1512962C; Tue, 24 Jan 2017 08:18:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148527472522.12598.17039375382524226738.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2017 08:18:45 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-27.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 16:18:45 -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 of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Shawn Jury Darryl Satterwhite Rick Taylor Bo Berry Filename : draft-ietf-manet-dlep-27.txt Pages : 78 Date : 2017-01-24 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 routing 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. DLEP describes a new protocol for a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics. 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: https://tools.ietf.org/html/draft-ietf-manet-dlep-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-27 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 Jan 25 05:36:00 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC25F1298D3 for ; Wed, 25 Jan 2017 05:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swr1YYeGi2pm for ; Wed, 25 Jan 2017 05:35:57 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 E26091298C5 for ; Wed, 25 Jan 2017 05:35:56 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id v23so19521800qtb.0 for ; Wed, 25 Jan 2017 05:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=tD0rIJgE3G0LtHny4BT3iCWpB1kPkq3fxzN0ggXDczM=; b=ZE14X1bqijp7/Is9rssDBwGr+leaS1/G5ZMqZA7dkwy65hw2PtvRLcBiFvHAKYppcU vR3mf+1BWTdpaYQLHP3+qsLF7k2MbfOzW/PxTIxiibLVMjVkWQUzi2UEA4EiSkT/jY4o IwKcPsfCUxS/FSurqOF6IV1iMBwHoxOtmc7eStlmWWIAmq8YeI6TmnVJEiNtVIWjrOx9 jS6Eu029LTuLISCtBcxsxTT/+qU2lpm8xwJ2/+Va2cdlpC1zDEcxumRdJtJOXtscTISa wun2o89CQ2d7FsKWlJRyN/C2xuaIJqegGvKLz2LlKF2cjNjLiLpD7noaJTToXmRz3VzT Iq0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=tD0rIJgE3G0LtHny4BT3iCWpB1kPkq3fxzN0ggXDczM=; b=hJHN9l/OKFiiJJh7t+Jdw1yu2Pf1sFbmwYm5/yoXRiMaW7NJYFQMu77Dc4cKSlvYI3 tuEfvUp/Toan731kt1KTWdpeMt4SZDLmdfB0nBKrfRkUEsBeCnN41GLI/qmW+5mcsj8S 1BwzVx+8R+GT6THHuyFdnNwdzMMYUQwLD+M/ycN1mKCADud7xfcr50dVZgqqE5aMcpVv HIJFnvtAplsDNw68XLiDa5mzyPlUSs6GbS3F256i2RP9fhasQPJPO72VczcVueBBCklS l8/T4ovjnhDQbkHxr+3mwUbP1rUKfEb4ziYbzTou1TXWK1bnu9YxUEDYSnUpRD6L4ByC 3HXQ== X-Gm-Message-State: AIkVDXJQs1woGGC2JgdOsP7lOcwcJhLSGpUtysUAvsl9baLS3C49v7lcBeP9oC9YsOMKNnnqzyCW9GoQ0UOhTQ== X-Received: by 10.237.37.50 with SMTP id v47mr32295503qtc.126.1485351355872; Wed, 25 Jan 2017 05:35:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.35.228 with HTTP; Wed, 25 Jan 2017 05:35:25 -0800 (PST) In-Reply-To: <148527472522.12598.17039375382524226738.idtracker@ietfa.amsl.com> References: <148527472522.12598.17039375382524226738.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Wed, 25 Jan 2017 14:35:25 +0100 Message-ID: To: MANET IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-27.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 13:35:59 -0000 Hi, I am a bit worried about the "secure" flag being pulled into the main RFC... security comes in different "flavors", which could be an excellent point in writing a DLEP extension where the radio informs the router about the security concerns (per radio channel, per client, ...) and maybe even gives the router an information how to send secured/unsecured frames. Just a single bit is not really that helpful. If we need more revisions for DLEP we should work on making them leaner, not heavier. Henning Rogge On Tue, Jan 24, 2017 at 5:18 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 of the IETF. > > Title : Dynamic Link Exchange Protocol (DLEP) > Authors : Stan Ratliff > Shawn Jury > Darryl Satterwhite > Rick Taylor > Bo Berry > Filename : draft-ietf-manet-dlep-27.txt > Pages : 78 > Date : 2017-01-24 > > 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 > routing 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. DLEP describes a new > protocol for a bidirectional, event-driven communication channel > between the router and the modem to facilitate communication of > changing link characteristics. > > > 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: > https://tools.ietf.org/html/draft-ietf-manet-dlep-27 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-27 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jan 25 06:23:53 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F996129953 for ; Wed, 25 Jan 2017 06:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PoAqxyLXnMJx for ; Wed, 25 Jan 2017 06:23:50 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B610812995C for ; Wed, 25 Jan 2017 06:23:49 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 25 Jan 2017 14:23:22 +0000 From: Rick Taylor To: "hrogge@gmail.com" , "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-27.txt Thread-Index: AQHSdl2fqSnpVOrRAkOko5MVXcnvsqFJMwmAgAANZoA= Date: Wed, 25 Jan 2017 14:23:23 +0000 Message-ID: <1485354203.14098.14.camel@tropicalstormsoftware.com> References: <148527472522.12598.17039375382524226738.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <8decb824-1307-4943-a8e4-b41ae16533ca> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-27.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 14:23:52 -0000 SGVubmluZywNCg0KSSB0YWtlIHlvdXIgcG9pbnQgdGhhdCB0aGUgJ1NlY3VyZWQgTWVkaXVtJyBm bGFnIGRvZXMgbm90IGdpdmUgYW55DQpmaW5lLWdyYWluZWQgaW5mb3JtYXRpb24gYWJvdXQgd2hh dCBzZWN1cml0eSBpcyBhcHBsaWVkIG9uIHRoZSBvdmVyLQ0KdGhlLWFpciBzaWduYWxsaW5nLg0K DQpJdCB3YXMgYWRkZWQgdG8gYWRkcmVzcyBhbiBlbnRpcmVseSB2YWxpZCBESVNDVVNTLCB3aGVy ZSBpdCB3YXMgcG9pbnRlZA0Kb3V0IHRoYXQgYSByb3V0ZXIgaGFzIG5vIGlkZWEgd2hldGhlciB0 byBibGluZGx5IHRydXN0IHRoZSByZW1vdGUNCmRlc3RpbmF0aW9uIGluZm9ybWF0aW9uLCBvciB3 aGV0aGVyIHNvbWUga2luZCBvZiBkZXBsb3ltZW50IHNwZWNpZmljDQpyZXN0cmljdGlvbiBzaG91 bGQgYmUgYXBwbGllZC4NCg0KVGhlIGFsdGVybmF0aXZlIGFwcHJvYWNoIHdhcyB0byBhZGQgKm1v cmUqIHNwZWNpZmljaXR5LCBpLmUuIGV4dHJhIERhdGENCkl0ZW1zIGFuZCBzcGVjaWZpY2F0aW9u IG9mIG92ZXItdGhlLWFpciBzaWduYWxsaW5nLCBhbmQvb3IgYXJiaXRyYXJ5DQpyZXN0cmljdGlv bnMgb24gd2hhdCBkYXRhIGl0ZW1zIGNvdWxkL3Nob3VsZCBiZSB0cnVzdGVkIG9yIG5vdC4gwqBU aGlzDQphcHByb2FjaCB3YXMgZGlzY2FyZGVkIGFzIGl0IGp1c3QgYWRkZWQgbW9yZSAnd2VpZ2h0 JyB0aGF0IHdvdWxkIGJlDQpiZXR0ZXIgYWRkcmVzc2VkIGluIGV4dGVuc2lvbnMuDQoNClRoZSAn U2VjdXJlIE1lZGl1bScgZmxhZyBpcyBub3QgYSBwYW5hY2VhLCBhbmQgcHVyZWx5IGFjdHMgYXMg YSBzaW1wbGUNCmNhbmFyeSBmb3IgdXNlIGluIHVucGxhbm5lZC9hZC1ob2MgZGVwbG95bWVudHMu IMKgQW4gZXh0ZW5zaW9uIGRyYWZ0DQp0aGF0IGFkZHJlc3NlcyBzcGVjaWZpYyBzZWN1cml0eSBh c3BlY3RzLCBmb3IgZXhhbXBsZSA4MDIuMTENCldFUC9XUEEvZXRjIG1vZGVzLCBpcyBpbmRlZWQg bW9yZSB1c2VmdWwuDQoNCkluIHNob3J0OiB3ZSBiZWxpZXZlIHRoZSAnU2VjdXJlZCBNZWRpdW0n IGZsYWcgaXMgYSBjb21wcm9taXNlIG9mIGxlYXN0DQppbXBhY3QuDQoNCkNoZWVycywNCg0KUmlj aw0KDQpPbiBXZWQsIDIwMTctMDEtMjUgYXQgMTQ6MzUgKzAxMDAsIEhlbm5pbmcgUm9nZ2Ugd3Jv dGU6DQo+IEhpLA0KPiANCj4gSSBhbSBhIGJpdCB3b3JyaWVkIGFib3V0IHRoZSAic2VjdXJlIiBm bGFnIGJlaW5nIHB1bGxlZCBpbnRvIHRoZSBtYWluDQo+IFJGQy4uLiBzZWN1cml0eSBjb21lcyBp biBkaWZmZXJlbnQgImZsYXZvcnMiLCB3aGljaCBjb3VsZCBiZSBhbg0KPiBleGNlbGxlbnQgcG9p bnQgaW4gd3JpdGluZyBhIERMRVAgZXh0ZW5zaW9uIHdoZXJlIHRoZSByYWRpbyBpbmZvcm1zDQo+ IHRoZSByb3V0ZXIgYWJvdXQgdGhlIHNlY3VyaXR5IGNvbmNlcm5zIChwZXIgcmFkaW8gY2hhbm5l bCwgcGVyDQo+IGNsaWVudCwNCj4gLi4uKSBhbmQgbWF5YmUgZXZlbiBnaXZlcyB0aGUgcm91dGVy IGFuIGluZm9ybWF0aW9uIGhvdyB0byBzZW5kDQo+IHNlY3VyZWQvdW5zZWN1cmVkIGZyYW1lcy4N Cj4gDQo+IEp1c3QgYSBzaW5nbGUgYml0IGlzIG5vdCByZWFsbHkgdGhhdCBoZWxwZnVsLg0KPiAN Cj4gSWYgd2UgbmVlZCBtb3JlIHJldmlzaW9ucyBmb3IgRExFUCB3ZSBzaG91bGQgd29yayBvbiBt YWtpbmcgdGhlbQ0KPiBsZWFuZXIsIG5vdCBoZWF2aWVyLg0KPiANCj4gSGVubmluZyBSb2dnZQ0K PiANCj4gT24gVHVlLCBKYW4gMjQsIDIwMTcgYXQgNToxOCBQTSzCoMKgPGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz4gd3JvdGU6DQo+ID4gDQo+ID4gDQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ID4gZGlyZWN0 b3JpZXMuDQo+ID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTW9iaWxlIEFkLWhv YyBOZXR3b3JrcyBvZiB0aGUNCj4gPiBJRVRGLg0KPiA+IA0KPiA+IMKgwqDCoMKgwqDCoMKgwqBU aXRsZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqA6IER5bmFtaWMgTGluayBFeGNoYW5nZSBQcm90b2Nv bCAoRExFUCkNCj4gPiDCoMKgwqDCoMKgwqDCoMKgQXV0aG9yc8KgwqDCoMKgwqDCoMKgwqDCoDog U3RhbiBSYXRsaWZmDQo+ID4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoFNoYXduIEp1cnkNCj4gPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgRGFycnlsIFNhdHRlcndoaXRlDQo+ID4gwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoFJpY2sgVGF5bG9yDQo+ ID4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoEJv IEJlcnJ5DQo+ID4gwqDCoMKgwqDCoMKgwqDCoEZpbGVuYW1lwqDCoMKgwqDCoMKgwqDCoDogZHJh ZnQtaWV0Zi1tYW5ldC1kbGVwLTI3LnR4dA0KPiA+IMKgwqDCoMKgwqDCoMKgwqBQYWdlc8KgwqDC oMKgwqDCoMKgwqDCoMKgwqA6IDc4DQo+ID4gwqDCoMKgwqDCoMKgwqDCoERhdGXCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqA6IDIwMTctMDEtMjQNCj4gPiANCj4gPiBBYnN0cmFjdDoNCj4gPiDCoMKg wqBXaGVuIHJvdXRpbmcgZGV2aWNlcyByZWx5IG9uIG1vZGVtcyB0byBlZmZlY3QgY29tbXVuaWNh dGlvbnMNCj4gPiBvdmVyDQo+ID4gwqDCoMKgd2lyZWxlc3MgbGlua3MsIHRoZXkgbmVlZCB0aW1l bHkgYW5kIGFjY3VyYXRlIGtub3dsZWRnZSBvZiB0aGUNCj4gPiDCoMKgwqBjaGFyYWN0ZXJpc3Rp Y3Mgb2YgdGhlIGxpbmsgKHNwZWVkLCBzdGF0ZSwgZXRjLikgaW4gb3JkZXIgdG8NCj4gPiBtYWtl DQo+ID4gwqDCoMKgcm91dGluZyBkZWNpc2lvbnMuwqDCoEluIG1vYmlsZSBvciBvdGhlciBlbnZp cm9ubWVudHMgd2hlcmUgdGhlc2UNCj4gPiDCoMKgwqBjaGFyYWN0ZXJpc3RpY3MgY2hhbmdlIGZy ZXF1ZW50bHksIG1hbnVhbCBjb25maWd1cmF0aW9ucyBvciB0aGUNCj4gPiDCoMKgwqBpbmZlcmVu Y2Ugb2Ygc3RhdGUgdGhyb3VnaCByb3V0aW5nIG9yIHRyYW5zcG9ydCBwcm90b2NvbHMgZG9lcw0K PiA+IG5vdA0KPiA+IMKgwqDCoGFsbG93IHRoZSByb3V0ZXIgdG8gbWFrZSB0aGUgYmVzdCBkZWNp c2lvbnMuwqDCoERMRVAgZGVzY3JpYmVzIGENCj4gPiBuZXcNCj4gPiDCoMKgwqBwcm90b2NvbCBm b3IgYSBiaWRpcmVjdGlvbmFsLCBldmVudC1kcml2ZW4gY29tbXVuaWNhdGlvbiBjaGFubmVsDQo+ ID4gwqDCoMKgYmV0d2VlbiB0aGUgcm91dGVyIGFuZCB0aGUgbW9kZW0gdG8gZmFjaWxpdGF0ZSBj b21tdW5pY2F0aW9uIG9mDQo+ID4gwqDCoMKgY2hhbmdpbmcgbGluayBjaGFyYWN0ZXJpc3RpY3Mu DQo+ID4gDQo+ID4gDQo+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1tYW5ldC1kbGVwLw0KPiA+IA0KPiA+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNp b24gYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW1hbmV0LWRsZXAtMjcNCj4gPiANCj4gPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtbWFuZXQtZGxlcC0yNw0KPiA+IA0KPiA+IA0KPiA+IFBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ ID4gc3VibWlzc2lvbg0KPiA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQNCj4gPiB0b29scy5pZXRmLm9yZy4NCj4gPiANCj4gPiBJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPiANCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG1hbmV0IG1haWxpbmcgbGlzdA0K PiA+IG1hbmV0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA== From nobody Wed Jan 25 08:34:30 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730A2129A32; Wed, 25 Jan 2017 08:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5zTMD-U4M4jA; Wed, 25 Jan 2017 08:34:21 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF43129A2C; Wed, 25 Jan 2017 08:34:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 64743B81C21; Wed, 25 Jan 2017 08:34:21 -0800 (PST) To: nmalykh@gmail.com, T.Clausen@computer.org, chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170125163421.64743B81C21@rfc-editor.org> Date: Wed, 25 Jan 2017 08:34:21 -0800 (PST) Archived-At: Cc: manet@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Errata Held for Document Update] RFC6130 (4866) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 16:34:23 -0000 The following errata report has been held for document update for RFC6130, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6130&eid=4866 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Nikolai Malykh Date Reported: 2016-11-15 Held by: Alvaro Retana (IESG) Section: 4.3.2 Original Text ------------- o For each MANET interface, within every time interval equal to the corresponding REFRESH_INTERVAL, sent HELLO messages MUST collectively include all of the relevant information in the corresponding Link Set and the Neighbor Information Base. Note that when determining whether to include information in a HELLO message, the sender MUST consider all times up to the latest time when it may send its next HELLO message on this MANET interface. o For each MANET interface, within every time interval equal to the corresponding REFRESH_INTERVAL, sent HELLO messages MUST collectively include all of the relevant information in the corresponding Link Set and the Neighbor Information Base. Corrected Text -------------- o For each MANET interface, within every time interval equal to the corresponding REFRESH_INTERVAL, sent HELLO messages MUST collectively include all of the relevant information in the corresponding Link Set and the Neighbor Information Base. Note that when determining whether to include information in a HELLO message, the sender MUST consider all times up to the latest time when it may send its next HELLO message on this MANET interface. Notes ----- The second statement is already contained in the first one. ===== >From Christopher Dearlove (author): it is the other paragraph that should be deleted. Because the paragraph following the two quoted paragraphs, which I copy here: o When determining whether to include a given piece of neighbor information in a HELLO message, it is not sufficient to consider whether that information has been sent in the interval of length REFRESH_INTERVAL up to the current time. Instead, the router MUST consider the interval of length REFRESH_INTERVAL that will end at the latest possible time at which the next HELLO message will be sent on this MANET interface. (Normally, this will be HELLO_INTERVAL past the current time, but MAY be earlier if this router elects to divide its neighbor information among more than one HELLO message in order to reduce the size of its HELLO messages.) All neighbor information MUST be sent in this interval, i.e., the router MUST ensure that this HELLO message includes all neighbor information that has not already been included in any HELLO messages sent since the start of this interval (normally, the current time - (REFRESH_INTERVAL - HELLO_INTERVAL)). contains the additional information in the longer paragraph, expanded to explain what it means. Thus the resolution is to delete the first paragraph: OLD: o For each MANET interface, within every time interval equal to the corresponding REFRESH_INTERVAL, sent HELLO messages MUST collectively include all of the relevant information in the corresponding Link Set and the Neighbor Information Base. Note that when determining whether to include information in a HELLO message, the sender MUST consider all times up to the latest time when it may send its next HELLO message on this MANET interface. NEW: -------------------------------------- RFC6130 (draft-ietf-manet-nhdp-15) -------------------------------------- Title : Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) Publication Date : April 2011 Author(s) : T. Clausen, C. Dearlove, J. Dean Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Jan 25 08:40:43 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7150D129A54; Wed, 25 Jan 2017 08:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 a5th90nNq0ao; Wed, 25 Jan 2017 08:40:41 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F664129A37; Wed, 25 Jan 2017 08:40:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 45CC7B81C44; Wed, 25 Jan 2017 08:40:41 -0800 (PST) To: nmalykh@gmail.com, T.Clausen@computer.org, chris.dearlove@baesystems.com, philippe.jacquet@alcatel-lucent.com, ulrich@herberg.name X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170125164041.45CC7B81C44@rfc-editor.org> Date: Wed, 25 Jan 2017 08:40:41 -0800 (PST) Archived-At: Cc: manet@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Errata Rejected] RFC7181 (4872) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 16:40:42 -0000 The following errata report has been rejected for RFC7181, "The Optimized Link State Routing Protocol Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7181&eid=4872 -------------------------------------- Status: Rejected Type: Editorial Reported by: Nikolai Malykh Date Reported: 2016-11-30 Rejected by: Alvaro Retana (IESG) Section: 16.2 Original Text ------------- TC messages MAY be generated in response to a change in the information that they are to advertise, indicated by a change in the ANSN in the Neighbor Information Base. In this case, a router MAY send a complete TC message and, if so, MAY restart its TC message schedule. Alternatively, a router MAY send an incomplete TC message with at least the newly advertised network addresses (i.e., not previously, but now, an N_orig_addr or in an N_neighbor_addr_list in a Neighbor Tuple with N_advertised = true or an AL_net_addr) in its Address Blocks, with associated Address Block TLV(s). Note that a router cannot report removal of advertised content using an incomplete TC message. Corrected Text -------------- TC messages MAY be generated in response to a change in the information that they are to advertise, indicated by a change in the ANSN in the Neighbor Information Base. In this case, a router MAY send a complete TC message and, if so, MAY restart its TC message schedule. Alternatively, a router MAY send an incomplete TC message with at least the newly advertised network addresses (i.e., not previously, but now, an N_orig_addr or an N_neighbor_addr_list in a Neighbor Tuple with N_advertised = true or an AL_net_addr) in its Address Blocks, with associated Address Block TLV(s). Note that a router cannot report removal of advertised content using an incomplete TC message. Notes ----- Unnecessary preposition "in" --VERIFIER NOTES-- From Christopher Dearlove (author): The "in" distinguishes the cases of N_orig_addr and an N_neighbor_addr_list. The former is a single address, the latter is a list of addresses. Therefore one looks for the address as the former, or in (the word that should not be deleted) the latter. This erratum must be rejected. -------------------------------------- RFC7181 (draft-ietf-manet-olsrv2-19) -------------------------------------- Title : The Optimized Link State Routing Protocol Version 2 Publication Date : April 2014 Author(s) : T. Clausen, C. Dearlove, P. Jacquet, U. Herberg Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Jan 25 08:48:30 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78ACC129A62; Wed, 25 Jan 2017 08:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 nXLBYdfhemIV; Wed, 25 Jan 2017 08:48:26 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1501129A5B; Wed, 25 Jan 2017 08:48:26 -0800 (PST) Received: from fips236155.nrl.navy.mil (fips236155.nrl.navy.mil [132.250.236.155]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id v0PGmIBI025756 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Jan 2017 11:48:18 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Justin Dean In-Reply-To: <20170125163421.64743B81C21@rfc-editor.org> Date: Wed, 25 Jan 2017 11:49:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6ADE8DB4-9803-4611-866B-09BE92D9C974@nrl.navy.mil> References: <20170125163421.64743B81C21@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3259) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Cc: nmalykh@gmail.com, T.Clausen@computer.org, chris.dearlove@baesystems.com, manet@ietf.org, iesg@ietf.org, jdean@itd.nrl.navy.mil Subject: Re: [manet] [Errata Held for Document Update] RFC6130 (4866) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 16:48:28 -0000 I agree with Chris, the fix is to remove the longer paragraph. > On Jan 25, 2017, at 11:34 AM, RFC Errata System = wrote: >=20 > The following errata report has been held for document update=20 > for RFC6130, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery = Protocol (NHDP)".=20 >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6130&eid=3D4866 >=20 > -------------------------------------- > Status: Held for Document Update > Type: Editorial >=20 > Reported by: Nikolai Malykh > Date Reported: 2016-11-15 > Held by: Alvaro Retana (IESG) >=20 > Section: 4.3.2 >=20 > Original Text > ------------- > o For each MANET interface, within every time interval equal to the > corresponding REFRESH_INTERVAL, sent HELLO messages MUST > collectively include all of the relevant information in the > corresponding Link Set and the Neighbor Information Base. Note > that when determining whether to include information in a HELLO > message, the sender MUST consider all times up to the latest time > when it may send its next HELLO message on this MANET interface. >=20 > o For each MANET interface, within every time interval equal to the > corresponding REFRESH_INTERVAL, sent HELLO messages MUST > collectively include all of the relevant information in the > corresponding Link Set and the Neighbor Information Base. >=20 >=20 > Corrected Text > -------------- > o For each MANET interface, within every time interval equal to the > corresponding REFRESH_INTERVAL, sent HELLO messages MUST > collectively include all of the relevant information in the > corresponding Link Set and the Neighbor Information Base. Note > that when determining whether to include information in a HELLO > message, the sender MUST consider all times up to the latest time > when it may send its next HELLO message on this MANET interface. >=20 >=20 >=20 > Notes > ----- > The second statement is already contained in the first one. >=20 > =3D=3D=3D=3D=3D > =46rom Christopher Dearlove (author): >=20 > it is the other paragraph that should be deleted. Because the = paragraph following the two quoted paragraphs, which I copy here: >=20 > o When determining whether to include a given piece of neighbor > information in a HELLO message, it is not sufficient to consider > whether that information has been sent in the interval of length > REFRESH_INTERVAL up to the current time. Instead, the router = MUST > consider the interval of length REFRESH_INTERVAL that will end at > the latest possible time at which the next HELLO message will be > sent on this MANET interface. (Normally, this will be > HELLO_INTERVAL past the current time, but MAY be earlier if this > router elects to divide its neighbor information among more than > one HELLO message in order to reduce the size of its HELLO > messages.) All neighbor information MUST be sent in this > interval, i.e., the router MUST ensure that this HELLO message > includes all neighbor information that has not already been > included in any HELLO messages sent since the start of this > interval (normally, the current time - (REFRESH_INTERVAL - > HELLO_INTERVAL)). >=20 > contains the additional information in the longer paragraph, expanded = to explain what it means. >=20 > Thus the resolution is to delete the first paragraph: >=20 > OLD: >=20 > o For each MANET interface, within every time interval equal to the > corresponding REFRESH_INTERVAL, sent HELLO messages MUST > collectively include all of the relevant information in the > corresponding Link Set and the Neighbor Information Base. Note > that when determining whether to include information in a HELLO > message, the sender MUST consider all times up to the latest time > when it may send its next HELLO message on this MANET interface. >=20 > NEW: >=20 >=20 > -------------------------------------- > RFC6130 (draft-ietf-manet-nhdp-15) > -------------------------------------- > Title : Mobile Ad Hoc Network (MANET) Neighborhood = Discovery Protocol (NHDP) > Publication Date : April 2011 > Author(s) : T. Clausen, C. Dearlove, J. Dean > Category : PROPOSED STANDARD > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG From nobody Wed Jan 25 09:06:11 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3718129A34 for ; Wed, 25 Jan 2017 08:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So8Vgigje_LX for ; Wed, 25 Jan 2017 08:48:05 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4581129A32 for ; Wed, 25 Jan 2017 08:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35368; q=dns/txt; s=iport; t=1485362884; x=1486572484; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lXbMd9p5OeFvvOM2Dj/8PrI6e5w0mk/J1AQAHTsEknI=; b=L2GJ+wwilCUjretE+iRtFYM/SL2bBaISaxaXzgKbE0iSjWkwseEzYRwe 2cq44JIDakLd9zfW9S6n+fBSMyH8+dHDB1SvuhhkDx51ouYhVjiPc2kSO XfPXV3xzTFb8ynjZ7d3UMeqAU8n1425uVCLdpC5kGkXyGyOtgJMkh6uvF 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAQCv1YhY/4wNJK1EGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvRgEBAQEBH2CBCQeDTYoIkgmIBo0ogg0qhXgCGoIBPxgBAgE?= =?us-ascii?q?BAQEBAQFiKIRpAQEBBCMmHgoIDAQCAQYCEQQBASEHAwICAh8RFAkIAgQBDQUbi?= =?us-ascii?q?GYDGA4tkHmcLoEggiUrhxINgxcBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhkuCBYF?= =?us-ascii?q?hgQmBPIEVO4EPCgcBCg4UBxUEglYugjEFiQIRhhuBRoRIhVo4AYk5hC2EDIF3h?= =?us-ascii?q?RCJaIojIoQghBQBHzgRY1QVGDMBhCsND4FhcwEThVsPF4EKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,284,1477958400"; d="scan'208,217";a="203596459" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jan 2017 16:48:03 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0PGm3XK028256 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2017 16:48:03 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 25 Jan 2017 10:48:02 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 25 Jan 2017 10:48:02 -0600 From: "Alvaro Retana (aretana)" To: "Dearlove, Christopher (UK)" , "RFC Errata System" , "T.Clausen@computer.org" , "philippe.jacquet@alcatel-lucent.com" , "ulrich@herberg.name" , "akatlas@gmail.com" , "db3546@att.com" , "sratliff@idirect.net" , "bebemaster@gmail.com" Thread-Topic: [Technical Errata Reported] RFC7181 (4874) Thread-Index: AQHSS60S8tE1ma2kV0WOSLoszC5oF6DzQJoAgFaOY4A= Date: Wed, 25 Jan 2017 16:48:02 +0000 Message-ID: References: <20161201082942.785D0B801CF@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.254.11] Content-Type: multipart/alternative; boundary="_000_FEE0854C4E2643AD934B7A15F603724Cciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 25 Jan 2017 09:06:11 -0800 Cc: "manet@ietf.org" , "nmalykh@gmail.com" Subject: Re: [manet] [Technical Errata Reported] RFC7181 (4874) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 16:48:06 -0000 --_000_FEE0854C4E2643AD934B7A15F603724Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hyaXN0b3BoZXI6DQoNClRoYW5rcyBmb3IgbG9va2luZyBpbnRvIHRoaXMgcmVwb3J0Lg0KDQpJ IGRvbuKAmXQgaGF2ZSBhbiBvcGluaW9uIGFzIHRvIHdoaWNoIG9wdGlvbiBpcyBiZXR0ZXIsIGJ1 dCBJIGRvIGhhdmUgYSBxdWVzdGlvbjogIFdoYXQgaXMgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVk PyAgIFNlY3Rpb24gMTcuIChJbmZvcm1hdGlvbiBCYXNlIENoYW5nZXMpLCB3aGljaCBpcyB0aGUg aGVhZGVyIGZvciB0aGUgY2hhbmdlcyB0aGUgZm9sbG93IChpbmNsdWRpbmcgb2YgY291cnNlIDE3 LjEpIG1ha2VzIHRoZSBwcm9jZXNzIG5vcm1hdGl2ZSBhbmQgbWFuZGF0b3J5OiDigJxUaGUgY2hh bmdlcyBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucyBNVVNUIGJlIGNhcnJpZWQg b3V04oCm4oCdICBTbyBpdCBpcyBpbXBvcnRhbnQgdG8gY2hvb3NlIHRoZSDigJxyaWdodOKAnSBz b2x1dGlvbi4NCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCk9uIDEyLzEvMTYsIDU6MDAgQU0sICJE ZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSIgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t PG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0KDQpBdXRob3Iu DQoNClRoZXJlIGlzIGFuIGlzc3VlLCBhbmQgdGhlIHByb3Bvc2VkIHJlc29sdXRpb24gd291bGQg d29yaywgYW5kIGlzIHByb2JhYmx5IHRoZSBtaW5pbWFsIHRleHR1YWwgY2hhbmdlLiBCdXQgaXQn cyBwb3RlbnRpYWxseSBjb25mdXNpbmcgY3JlYXRpbmcgYSB0dXBsZSB0byBpbW1lZGlhdGVseSBj aGFuZ2UgaXQuDQoNCkkgY2FuIHNlZSB0d28gcG9zc2libGUgYmV0dGVyIChpbiBteSBvcGluaW9u KSB0ZXh0cywgSSdkIGFwcHJlY2lhdGUgY29tbWVudCAoZXNwZWNpYWxseSBmcm9tIGNvLWF1dGhv cikgb24gcHJlZmVyZW5jZSB0byByZWNvbW1lbmQgYXMgY29ycmVjdGlvbiAoaW5jbHVkaW5nIHBv c3NpYmx5IGZvciB2ZXJzaW9uIEkgZGlzbGlrZSkuDQoNCk5FVyAoMSk6DQoNCiAgIElmIHRoZSBy b3V0ZXIgY2hhbmdlcyBpdHMgb3JpZ2luYXRvciBhZGRyZXNzLCB0aGVuOg0KDQogICAxLiAgSWYg dGhlcmUgaXMgYW4gT3JpZ2luYXRvciBUdXBsZSB3aXRoOg0KDQogICAgICAgKiAgT19vcmlnX2Fk ZHIgPSBvbGQgb3JpZ2luYXRvciBhZGRyZXNzDQoNCiAgICAgICB0aGVuIG1vZGlmeSBpdCBhcyBm b2xsb3dzOg0KDQogICAgICAgKiAgT19vcmlnX2FkZHIgOj0gbmV3IG9yaWdpbmF0b3IgYWRkcmVz cw0KICAgICAgICogIE9fdGltZSA6PSBjdXJyZW50IHRpbWUgKyBPX0hPTERfVElNRQ0KDQogICAg ICAgb3RoZXJ3aXNlIGNyZWF0ZSBhbiBPcmlnaW5hdG9yIFR1cGxlIHdpdGg6DQoNCiAgICAgICAq ICBPX29yaWdfYWRkciA6PSBuZXcgb3JpZ2luYXRvciBhZGRyZXNzDQogICAgICAgKiAgT190aW1l IDo9IGN1cnJlbnQgdGltZSArIE9fSE9MRF9USU1FDQoNCk5FVyAoMik6DQoNCiAgIElmIHRoZSBy b3V0ZXIgY2hhbmdlcyBpdHMgb3JpZ2luYXRvciBhZGRyZXNzLCB0aGVuOg0KDQogICAxLiAgSWYg dGhlcmUgaXMgYW4gT3JpZ2luYXRvciBUdXBsZSB3aXRoOg0KDQogICAgICAgKiAgT19vcmlnX2Fk ZHIgPSBvbGQgb3JpZ2luYXRvciBhZGRyZXNzDQoNCiAgICAgICB0aGVuIHJlbW92ZSBpdC4NCg0K ICAgMi4gIENyZWF0ZSBhbiBPcmlnaW5hdG9yIFR1cGxlIHdpdGg6DQoNCiAgICAgICAqICBPX29y aWdfYWRkciA6PSBuZXcgb3JpZ2luYXRvciBhZGRyZXNzDQogICAgICAgKiAgT190aW1lIDo9IGN1 cnJlbnQgdGltZSArIE9fSE9MRF9USU1FDQoNCkkgdGhpbmsgSSBwcmVmZXIgTkVXICgyKS4NCg0K LS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUg U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBH cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5j b20vYWkNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1 cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUkZDIEVycmF0YSBTeXN0ZW0gW21haWx0bzpyZmMt ZWRpdG9yQHJmYy1lZGl0b3Iub3JnXQ0KU2VudDogMDEgRGVjZW1iZXIgMjAxNiAwODozMA0KVG86 IFQuQ2xhdXNlbkBjb21wdXRlci5vcmc8bWFpbHRvOlQuQ2xhdXNlbkBjb21wdXRlci5vcmc+OyBE ZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgcGhpbGlwcGUuamFjcXVldEBhbGNhdGVsLWx1Y2Vu dC5jb208bWFpbHRvOnBoaWxpcHBlLmphY3F1ZXRAYWxjYXRlbC1sdWNlbnQuY29tPjsgdWxyaWNo QGhlcmJlcmcubmFtZTxtYWlsdG86dWxyaWNoQGhlcmJlcmcubmFtZT47IGFrYXRsYXNAZ21haWwu Y29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT47IGRiMzU0NkBhdHQuY29tPG1haWx0bzpkYjM1 NDZAYXR0LmNvbT47IGFyZXRhbmFAY2lzY28uY29tPG1haWx0bzphcmV0YW5hQGNpc2NvLmNvbT47 IHNyYXRsaWZmQGlkaXJlY3QubmV0PG1haWx0bzpzcmF0bGlmZkBpZGlyZWN0Lm5ldD47IGJlYmVt YXN0ZXJAZ21haWwuY29tPG1haWx0bzpiZWJlbWFzdGVyQGdtYWlsLmNvbT4NCkNjOiBubWFseWto QGdtYWlsLmNvbTxtYWlsdG86bm1hbHlraEBnbWFpbC5jb20+OyBtYW5ldEBpZXRmLm9yZzxtYWls dG86bWFuZXRAaWV0Zi5vcmc+OyByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMt ZWRpdG9yQHJmYy1lZGl0b3Iub3JnPg0KU3ViamVjdDogW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0 ZWRdIFJGQzcxODEgKDQ4NzQpDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lk ZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZy b20gdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBj bGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93 IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGlu c3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRo ZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzcxODEs ICJUaGUgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyBQcm90b2NvbCBWZXJzaW9uIDIiLg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWW91IG1heSByZXZpZXcg dGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQpodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0 YV9zZWFyY2gucGhwP3JmYz03MTgxJmVpZD00ODc0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUeXBlOiBUZWNobmljYWwNClJlcG9ydGVkIGJ5OiBOaWtvbGFpIE1h bHlraCA8bm1hbHlraEBnbWFpbC5jb208bWFpbHRvOm5tYWx5a2hAZ21haWwuY29tPj4NCg0KU2Vj dGlvbjogMTcuMQ0KDQpPcmlnaW5hbCBUZXh0DQotLS0tLS0tLS0tLS0tDQogICBJZiB0aGUgcm91 dGVyIGNoYW5nZXMgaXRzIG9yaWdpbmF0b3IgYWRkcmVzcywgdGhlbjoNCg0KICAgMS4gIElmIHRo ZXJlIGlzIG5vIE9yaWdpbmF0b3IgVHVwbGUgd2l0aDoNCg0KICAgICAgICogIE9fb3JpZ19hZGRy ID0gb2xkIG9yaWdpbmF0b3IgYWRkcmVzcw0KDQogICAgICAgdGhlbiBjcmVhdGUgYW4gT3JpZ2lu YXRvciBUdXBsZSB3aXRoOg0KDQogICAgICAgKiAgT19vcmlnX2FkZHIgOj0gb2xkIG9yaWdpbmF0 b3IgYWRkcmVzcw0KDQogICAgICAgVGhlIE9yaWdpbmF0b3IgVHVwbGUgKGV4aXN0aW5nIG9yIG5l dykgd2l0aDoNCg0KICAgICAgICogIE9fb3JpZ19hZGRyID0gbmV3IG9yaWdpbmF0b3IgYWRkcmVz cw0KDQogICAgICAgaXMgdGhlbiBtb2RpZmllZCBhcyBmb2xsb3dzOg0KDQogICAgICAgKiAgT190 aW1lIDo9IGN1cnJlbnQgdGltZSArIE9fSE9MRF9USU1FDQoNCg0KQ29ycmVjdGVkIFRleHQNCi0t LS0tLS0tLS0tLS0tDQogICBJZiB0aGUgcm91dGVyIGNoYW5nZXMgaXRzIG9yaWdpbmF0b3IgYWRk cmVzcywgdGhlbjoNCg0KICAgMS4gIElmIHRoZXJlIGlzIG5vIE9yaWdpbmF0b3IgVHVwbGUgd2l0 aDoNCg0KICAgICAgICogIE9fb3JpZ19hZGRyID0gb2xkIG9yaWdpbmF0b3IgYWRkcmVzcw0KDQog ICAgICAgdGhlbiBjcmVhdGUgYW4gT3JpZ2luYXRvciBUdXBsZSB3aXRoOg0KDQogICAgICAgKiAg T19vcmlnX2FkZHIgOj0gb2xkIG9yaWdpbmF0b3IgYWRkcmVzcw0KDQogICAgICAgVGhlIE9yaWdp bmF0b3IgVHVwbGUgKGV4aXN0aW5nIG9yIG5ldykgd2l0aDoNCg0KICAgICAgICogIE9fb3JpZ19h ZGRyID0gb2xkIG9yaWdpbmF0b3IgYWRkcmVzcw0KDQogICAgICAgaXMgdGhlbiBtb2RpZmllZCBh cyBmb2xsb3dzOg0KDQogICAgICAgKiAgT19vcmlnX2FkZHIgOj0gbmV3IG9yaWdpbmF0b3IgYWRk cmVzcw0KDQogICAgICAgKiAgT190aW1lIDo9IGN1cnJlbnQgdGltZSArIE9fSE9MRF9USU1FDQoN Cg0KTm90ZXMNCi0tLS0tDQpBdCB0aGUgdGltZSBvZiB0aGUgbW9kaWZpY2F0aW9uIE9yaWdpbmF0 b3IgVHVwbGUgd2l0aCBPX29yaWdfYWRkciA9IG5ldyBvcmlnaW5hdG9yIGFkZHJlc3MgZG9lcyBu b3QgeWV0IGV4aXN0Lg0KDQpJbnN0cnVjdGlvbnM6DQotLS0tLS0tLS0tLS0tDQpUaGlzIGVycmF0 dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFz ZSB1c2UgIlJlcGx5IEFsbCIgdG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmll ZCBvciByZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcg cGFydHkgY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0 LCBpZiBuZWNlc3NhcnkuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpSRkM3MTgxIChkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi0xOSkNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaXRsZSAgICAgICAgICAgICAgIDogVGhlIE9wdGltaXpl ZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgVmVyc2lvbiAyDQpQdWJsaWNhdGlvbiBEYXRl ICAgIDogQXByaWwgMjAxNA0KQXV0aG9yKHMpICAgICAgICAgICA6IFQuIENsYXVzZW4sIEMuIERl YXJsb3ZlLCBQLiBKYWNxdWV0LCBVLiBIZXJiZXJnDQpDYXRlZ29yeSAgICAgICAgICAgIDogUFJP UE9TRUQgU1RBTkRBUkQNClNvdXJjZSAgICAgICAgICAgICAgOiBNb2JpbGUgQWQtaG9jIE5ldHdv cmtzDQpBcmVhICAgICAgICAgICAgICAgIDogUm91dGluZw0KU3RyZWFtICAgICAgICAgICAgICA6 IElFVEYNClZlcmlmeWluZyBQYXJ0eSAgICAgOiBJRVNHDQoNCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQN CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkDQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFu ZCBub3RpZnkgdGhlIHNlbmRlci4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZv ciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3INCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24uDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoNCg== --_000_FEE0854C4E2643AD934B7A15F603724Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5DaHJp c3RvcGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MgZm9yIGxvb2tpbmcgaW50 byB0aGlzIHJlcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5JIGRvbuKAmXQgaGF2ZSBh biBvcGluaW9uIGFzIHRvIHdoaWNoIG9wdGlvbiBpcyBiZXR0ZXIsIGJ1dCBJIGRvIGhhdmUgYSBx dWVzdGlvbjombmJzcDsgV2hhdCBpcyBpbXBsZW1lbnRlZCBhbmQgZGVwbG95ZWQ/Jm5ic3A7ICZu YnNwO1NlY3Rpb24gMTcuIChJbmZvcm1hdGlvbiBCYXNlIENoYW5nZXMpLCB3aGljaCBpcyB0aGUg aGVhZGVyIGZvciB0aGUNCiBjaGFuZ2VzIHRoZSBmb2xsb3cgKGluY2x1ZGluZyBvZiBjb3Vyc2Ug MTcuMSkgbWFrZXMgdGhlIHByb2Nlc3Mgbm9ybWF0aXZlIGFuZCBtYW5kYXRvcnk6IOKAnFRoZSBj aGFuZ2VzIGRlc2NyaWJlZCBpbiB0aGUgZm9sbG93aW5nIHNlY3Rpb25zIE1VU1QgYmUgY2Fycmll ZCBvdXTigKbigJ0mbmJzcDsgU28gaXQgaXMgaW1wb3J0YW50IHRvIGNob29zZSB0aGUg4oCccmln aHTigJ0gc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPkFsdmFyby4gPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTIvMS8xNiwgNTowMCBBTSwgJnF1 b3Q7RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdXRob3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIGFuIGlzc3VlLCBhbmQgdGhlIHBy b3Bvc2VkIHJlc29sdXRpb24gd291bGQgd29yaywgYW5kIGlzIHByb2JhYmx5IHRoZSBtaW5pbWFs IHRleHR1YWwgY2hhbmdlLiBCdXQgaXQncyBwb3RlbnRpYWxseSBjb25mdXNpbmcgY3JlYXRpbmcg YSB0dXBsZSB0byBpbW1lZGlhdGVseSBjaGFuZ2UgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY2FuIHNlZSB0d28gcG9zc2libGUgYmV0 dGVyIChpbiBteSBvcGluaW9uKSB0ZXh0cywgSSdkIGFwcHJlY2lhdGUgY29tbWVudCAoZXNwZWNp YWxseSBmcm9tIGNvLWF1dGhvcikgb24gcHJlZmVyZW5jZSB0byByZWNvbW1lbmQgYXMgY29ycmVj dGlvbiAoaW5jbHVkaW5nIHBvc3NpYmx5IGZvciB2ZXJzaW9uIEkgZGlzbGlrZSkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5FVyAoMSk6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyBJZiB0aGUgcm91dGVyIGNoYW5nZXMgaXRzIG9yaWdpbmF0b3IgYWRkcmVzcywgdGhl bjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7IDEuJm5ic3A7Jm5ic3A7SWYgdGhlcmUgaXMgYW4gT3JpZ2luYXRvciBUdXBs ZSB3aXRoOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwO09f b3JpZ19hZGRyID0gb2xkIG9yaWdpbmF0b3IgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhlbiBtb2RpZnkgaXQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDtPX29yaWdfYWRkciA6PSBuZXcgb3JpZ2luYXRv ciBhZGRyZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwO09f dGltZSA6PSBjdXJyZW50IHRpbWUgJiM0MzsgT19IT0xEX1RJTUU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG90aGVyd2lzZSBjcmVhdGUgYW4gT3JpZ2luYXRvciBUdXBsZSB3aXRo OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwO09fb3JpZ19h ZGRyIDo9IG5ldyBvcmlnaW5hdG9yIGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAqJm5ic3A7Jm5ic3A7T190aW1lIDo9IGN1cnJlbnQgdGltZSAmIzQzOyBPX0hPTERfVElN RTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O RVcgKDIpOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgSWYgdGhlIHJvdXRlciBjaGFuZ2VzIGl0cyBvcmlnaW5hdG9yIGFk ZHJlc3MsIHRoZW46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAxLiZuYnNwOyZuYnNwO0lmIHRoZXJlIGlzIGFuIE9yaWdp bmF0b3IgVHVwbGUgd2l0aDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJz cDsmbmJzcDtPX29yaWdfYWRkciA9IG9sZCBvcmlnaW5hdG9yIGFkZHJlc3M8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZW4gcmVtb3ZlIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgMi4mbmJzcDsm bmJzcDtDcmVhdGUgYW4gT3JpZ2luYXRvciBUdXBsZSB3aXRoOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwO09fb3JpZ19hZGRyIDo9IG5ldyBvcmlnaW5hdG9y IGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7T190 aW1lIDo9IGN1cnJlbnQgdGltZSAmIzQzOyBPX0hPTERfVElNRTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIEkgcHJlZmVyIE5FVyAo MikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJBRSBTeXN0ZW1zIEFwcGxpZWQg SW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VDogJm5ic3A7JiM0Mzs0NCAoMCkx MjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwO0U6IDxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbSI+DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBH cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJBRSBT eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1w OyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywg R3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb206IFJGQyBF cnJhdGEgU3lzdGVtIFs8YSBocmVmPSJtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyI+ bWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8L2E+XQ0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50OiAwMSBEZWNlbWJlciAyMDE2 IDA4OjMwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UbzogPGEgaHJlZj0ibWFpbHRvOlQuQ2xhdXNlbkBjb21wdXRlci5vcmciPlQuQ2xhdXNlbkBj b21wdXRlci5vcmc8L2E+OyBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsNCjxhIGhyZWY9Im1h aWx0bzpwaGlsaXBwZS5qYWNxdWV0QGFsY2F0ZWwtbHVjZW50LmNvbSI+cGhpbGlwcGUuamFjcXVl dEBhbGNhdGVsLWx1Y2VudC5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnVscmljaEBoZXJiZXJn Lm5hbWUiPnVscmljaEBoZXJiZXJnLm5hbWU8L2E+OyA8YSBocmVmPSJtYWlsdG86YWthdGxhc0Bn bWFpbC5jb20iPg0KYWthdGxhc0BnbWFpbC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZGIzNTQ2 QGF0dC5jb20iPmRiMzU0NkBhdHQuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmFyZXRhbmFAY2lz Y28uY29tIj4NCmFyZXRhbmFAY2lzY28uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNyYXRsaWZm QGlkaXJlY3QubmV0Ij5zcmF0bGlmZkBpZGlyZWN0Lm5ldDwvYT47DQo8YSBocmVmPSJtYWlsdG86 YmViZW1hc3RlckBnbWFpbC5jb20iPmJlYmVtYXN0ZXJAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2M6IDxhIGhyZWY9Im1h aWx0bzpubWFseWtoQGdtYWlsLmNvbSI+bm1hbHlraEBnbWFpbC5jb208L2E+Ow0KPGEgaHJlZj0i bWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0 bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnIj4NCnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T dWJqZWN0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNzE4MSAoNDg3NCk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNz YWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9t IGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25zaWRlciBjYXJlZnVsbHkg d2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVu dHMgb3IgcmVwbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Gb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQg bWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1l c3NhZ2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNzE4 MSwgJnF1b3Q7VGhlIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgVmVyc2lv biAyJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IG1heSByZXZpZXcg dGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2Vy cmF0YV9zZWFyY2gucGhwP3JmYz03MTgxJmFtcDtlaWQ9NDg3NCI+aHR0cDovL3d3dy5yZmMtZWRp dG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9NzE4MSZhbXA7ZWlkPTQ4NzQ8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UeXBlOiBUZWNobmljYWw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlcG9ydGVkIGJ5OiBOaWtvbGFp IE1hbHlraCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5tYWx5a2hAZ21haWwuY29tIj5ubWFseWtoQGdt YWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNlY3Rpb246IDE3LjE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3JpZ2luYWwgVGV4dDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IElm IHRoZSByb3V0ZXIgY2hhbmdlcyBpdHMgb3JpZ2luYXRvciBhZGRyZXNzLCB0aGVuOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsgMS4mbmJzcDsmbmJzcDtJZiB0aGVyZSBpcyBubyBPcmlnaW5hdG9yIFR1cGxlIHdpdGg6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7T19vcmlnX2FkZHIg PSBvbGQgb3JpZ2luYXRvciBhZGRyZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0aGVuIGNyZWF0ZSBhbiBPcmlnaW5hdG9yIFR1cGxlIHdpdGg6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7T19vcmlnX2FkZHIgOj0gb2xkIG9yaWdpbmF0 b3IgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIE9yaWdpbmF0 b3IgVHVwbGUgKGV4aXN0aW5nIG9yIG5ldykgd2l0aDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICombmJzcDsmbmJzcDtPX29yaWdfYWRkciA9IG5ldyBvcmlnaW5hdG9yIGFkZHJl c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIHRoZW4gbW9kaWZpZWQgYXMg Zm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDtP X3RpbWUgOj0gY3VycmVudCB0aW1lICYjNDM7IE9fSE9MRF9USU1FPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29ycmVjdGVkIFRleHQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0t LS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgSWYgdGhlIHJvdXRlciBjaGFuZ2VzIGl0cyBvcmlnaW5hdG9yIGFkZHJl c3MsIHRoZW46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyAxLiZuYnNwOyZuYnNwO0lmIHRoZXJlIGlzIG5vIE9yaWdpbmF0 b3IgVHVwbGUgd2l0aDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsm bmJzcDtPX29yaWdfYWRkciA9IG9sZCBvcmlnaW5hdG9yIGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZW4gY3JlYXRlIGFuIE9yaWdpbmF0b3IgVHVwbGUgd2l0aDo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDtPX29yaWdfYWRk ciA6PSBvbGQgb3JpZ2luYXRvciBhZGRyZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBUaGUgT3JpZ2luYXRvciBUdXBsZSAoZXhpc3Rpbmcgb3IgbmV3KSB3aXRoOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwO09fb3JpZ19hZGRyID0gb2xk IG9yaWdpbmF0b3IgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMg dGhlbiBtb2RpZmllZCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgKiZuYnNwOyZuYnNwO09fb3JpZ19hZGRyIDo9IG5ldyBvcmlnaW5hdG9yIGFkZHJlc3M8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDtPX3RpbWUgOj0gY3Vy cmVudCB0aW1lICYjNDM7IE9fSE9MRF9USU1FPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0aGUgdGltZSBvZiB0aGUgbW9kaWZpY2F0 aW9uIE9yaWdpbmF0b3IgVHVwbGUgd2l0aCBPX29yaWdfYWRkciA9IG5ldyBvcmlnaW5hdG9yIGFk ZHJlc3MgZG9lcyBub3QgeWV0IGV4aXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbnN0cnVjdGlvbnM6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tLS0tPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGVycmF0dW0gaXMg Y3VycmVudGx5IHBvc3RlZCBhcyAmcXVvdDtSZXBvcnRlZCZxdW90Oy4gSWYgbmVjZXNzYXJ5LCBw bGVhc2UgdXNlICZxdW90O1JlcGx5IEFsbCZxdW90OyB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hv dWxkIGJlIHZlcmlmaWVkIG9yIHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwg dGhlIHZlcmlmeWluZyBwYXJ0eSBjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBl ZGl0IHRoZSByZXBvcnQsDQogaWYgbmVjZXNzYXJ5LiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJGQzcxODEgKGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLTE5KTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogVGhlIE9w dGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgVmVyc2lvbiAyPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QdWJsaWNhdGlvbiBEYXRl Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBBcHJpbCAyMDE0PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdXRob3IocykmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBULiBDbGF1c2Vu LCBDLiBEZWFybG92ZSwgUC4gSmFjcXVldCwgVS4gSGVyYmVyZzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2F0ZWdvcnkmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6 IFBST1BPU0VEIFNUQU5EQVJEPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Tb3VyY2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IE1vYmlsZSBB ZC1ob2MgTmV0d29ya3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFyZWEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IFJv dXRpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlN0cmVhbSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogSUVURjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VmVyaWZ5aW5nIFBhcnR5Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogSUVTRzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWNpcGllbnQgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVjaXBpZW50IHBsZWFzZSBkZWxl dGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3Ugc2hvdWxkIG5vdCBj b3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kaXN0cmlidXRlIGl0 cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FEE0854C4E2643AD934B7A15F603724Cciscocom_-- From nobody Wed Jan 25 11:05:39 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEEB129AAF for ; Wed, 25 Jan 2017 09:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkajE9Gb45ix for ; Wed, 25 Jan 2017 09:58:06 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 E7782129AA2 for ; Wed, 25 Jan 2017 09:58:05 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id d140so44324202wmd.2 for ; Wed, 25 Jan 2017 09:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=TZSw31AAjoOEpagVzalKr0t/XOaWX3bTqT238f3CuT4=; b=BXFD6vuxfiR0vzY90wuumjotcxY8kczfbsiPYEpaJn//ILZ/C3OdPD5SHV6RSqiV3i mXFIhMiNT4dFnL8d3F2tdvj05o7SQAmnoRal/VJDBWOmUD9S+5C3BQt27WCuk6fyyX4P fda1uYZDeekadjIXzpnI/ZG/GAj+2fbohhe+MHXbQLEeVPZDojTMhtF2h/yNms9chmwl 0iPXpR5hXBvCgyb9EQQw+PfLN4jZKK+VbCb1PQXZPe0M9W6TXWhndn8S/PTS/69IOouQ EtG4+myh8TkrNwVauCqtSATcvMiaptEMVcnTT0rtcRfMc4FV/OBBFuB7waFPArc0+RVo Wh3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=TZSw31AAjoOEpagVzalKr0t/XOaWX3bTqT238f3CuT4=; b=ccU8vCfZRtRjK92T0JJoVSTQNIWLm84jQip4b+GU/YsT27QBrndKh1Ax5XCl7L38Us 1sAD6C9LMS0MgOy75xmgbbUKokgJxCvX68JaFYKJvV5gU/xYFsVbSAxTtDqNnQbF4w8A szcddGX16DAUWf1Hw5u9sHz28WPfbILSFwbdargn2TjPHzUTotfVKHQdeE/83143wDEH wUs2R8xhp7wIJeZnbg75g3WcM5eQGedq5xTwquQMwBHon45WjtZFAlCh6OHkLQKt+K4q d+decFpNRDYimq6gcbyEaE37ygXSvb4jebfD6hI9po+TuVHpJSzgGaE8ZBvLHpZO54Kz oeTg== X-Gm-Message-State: AIkVDXJZYLh0OSx6cBHpn7ep2DL463YX9tZqjTf9O9nA6w2EKk9IvFC3Ib27hxeKxjYRrQ== X-Received: by 10.28.94.2 with SMTP id s2mr22320468wmb.127.1485367084275; Wed, 25 Jan 2017 09:58:04 -0800 (PST) Received: from [10.170.18.157] (82-132-239-183.dab.02.net. [82.132.239.183]) by smtp.gmail.com with ESMTPSA id x135sm1756698wme.23.2017.01.25.09.58.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 09:58:03 -0800 (PST) References: <20161201082942.785D0B801CF@rfc-editor.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-8281F671-56D8-4D0C-89F4-9671A1F61C64 Message-Id: X-Mailer: iPhone Mail (14C92) From: Christopher Dearlove Date: Wed, 25 Jan 2017 12:57:56 -0500 To: "Alvaro Retana (aretana)" Archived-At: X-Mailman-Approved-At: Wed, 25 Jan 2017 11:05:37 -0800 Cc: "nmalykh@gmail.com" , "db3546@att.com" , "T.Clausen@computer.org" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "akatlas@gmail.com" , "philippe.jacquet@alcatel-lucent.com" , RFC Errata System Subject: Re: [manet] [Technical Errata Reported] RFC7181 (4874) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 17:58:09 -0000 --Apple-Mail-8281F671-56D8-4D0C-89F4-9671A1F61C64 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The point should be that both produce functionally identical results, it's a= question of which is clearer. Whichever is written, an implementation can a= lways do either, or even a third option - there's a specific permission give= n to do whatever you like as long as you behave as if you followed the rules= precisely. I'm fairly sure there are implementations that take advantage of= that in places (not necessarily here). (I'm doing this on a phone, without being able to check details. But I'm ass= uming the preference I gave below is still my preference. But others may hav= e other opinions.) -- =20 Christopher Dearlove christopher.dearlove@gmail.com > On 25 Jan 2017, at 11:48, Alvaro Retana (aretana) wrot= e: >=20 > Christopher: > =20 > Thanks for looking into this report. > =20 > I don=E2=80=99t have an opinion as to which option is better, but I do hav= e a question: What is implemented and deployed? Section 17. (Information B= ase Changes), which is the header for the changes the follow (including of c= ourse 17.1) makes the process normative and mandatory: =E2=80=9CThe changes d= escribed in the following sections MUST be carried out=E2=80=A6=E2=80=9D So= it is important to choose the =E2=80=9Cright=E2=80=9D solution. > =20 > Thanks! > =20 > Alvaro. > =20 > On 12/1/16, 5:00 AM, "Dearlove, Christopher (UK)" wrote: > =20 > Author. > =20 > There is an issue, and the proposed resolution would work, and is probably= the minimal textual change. But it's potentially confusing creating a tuple= to immediately change it. > =20 > I can see two possible better (in my opinion) texts, I'd appreciate commen= t (especially from co-author) on preference to recommend as correction (incl= uding possibly for version I dislike). > =20 > NEW (1): > =20 > If the router changes its originator address, then: > =20 > 1. If there is an Originator Tuple with: > =20 > * O_orig_addr =3D old originator address > =20 > then modify it as follows: > =20 > * O_orig_addr :=3D new originator address > * O_time :=3D current time + O_HOLD_TIME > =20 > otherwise create an Originator Tuple with: > =20 > * O_orig_addr :=3D new originator address > * O_time :=3D current time + O_HOLD_TIME > =20 > NEW (2): > =20 > If the router changes its originator address, then: > =20 > 1. If there is an Originator Tuple with: > =20 > * O_orig_addr =3D old originator address > =20 > then remove it. > =20 > 2. Create an Originator Tuple with: > =20 > * O_orig_addr :=3D new originator address > * O_time :=3D current time + O_HOLD_TIME > =20 > I think I prefer NEW (2). > =20 > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > __________________________________________________________________________= > =20 > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > =20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow= , Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > =20 > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 01 December 2016 08:30 > To: T.Clausen@computer.org; Dearlove, Christopher (UK); philippe.jacquet@a= lcatel-lucent.com; ulrich@herberg.name; akatlas@gmail.com; db3546@att.com; a= retana@cisco.com; sratliff@idirect.net; bebemaster@gmail.com > Cc: nmalykh@gmail.com; manet@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC7181 (4874) > =20 > ----------------------! WARNING ! ---------------------- This message orig= inates 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 attachm= ents or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. > -------------------------------------------------------- > =20 > The following errata report has been submitted for RFC7181, "The Optimized= Link State Routing Protocol Version 2". > =20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7181&eid=3D4874 > =20 > -------------------------------------- > Type: Technical > Reported by: Nikolai Malykh > =20 > Section: 17.1 > =20 > Original Text > ------------- > If the router changes its originator address, then: > =20 > 1. If there is no Originator Tuple with: > =20 > * O_orig_addr =3D old originator address > =20 > then create an Originator Tuple with: > =20 > * O_orig_addr :=3D old originator address > =20 > The Originator Tuple (existing or new) with: > =20 > * O_orig_addr =3D new originator address > =20 > is then modified as follows: > =20 > * O_time :=3D current time + O_HOLD_TIME > =20 > =20 > Corrected Text > -------------- > If the router changes its originator address, then: > =20 > 1. If there is no Originator Tuple with: > =20 > * O_orig_addr =3D old originator address > =20 > then create an Originator Tuple with: > =20 > * O_orig_addr :=3D old originator address > =20 > The Originator Tuple (existing or new) with: > =20 > * O_orig_addr =3D old originator address > =20 > is then modified as follows: > =20 > * O_orig_addr :=3D new originator address > =20 > * O_time :=3D current time + O_HOLD_TIME > =20 > =20 > Notes > ----- > At the time of the modification Originator Tuple with O_orig_addr =3D new o= riginator address does not yet exist. > =20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please use "= Reply All" to discuss whether it should be verified or rejected. When a deci= sion is reached, the verifying party can log in to change the status and edi= t the report, if necessary. > =20 > -------------------------------------- > RFC7181 (draft-ietf-manet-olsrv2-19) > -------------------------------------- > Title : The Optimized Link State Routing Protocol Version 2 > Publication Date : April 2014 > Author(s) : T. Clausen, C. Dearlove, P. Jacquet, U. Herberg > Category : PROPOSED STANDARD > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > =20 > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-8281F671-56D8-4D0C-89F4-9671A1F61C64 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The point should be that both produce f= unctionally identical results, it's a question of which is clearer. Whicheve= r is written, an implementation can always do either, or even a third option= - there's a specific permission given to do whatever you like as long as yo= u behave as if you followed the rules precisely. I'm fairly sure there are i= mplementations that take advantage of that in places (not necessarily here).=

(I'm doing this on a phone, without being able to check details. But I'm a= ssuming the preference I gave below is still my preference. But others may h= ave other opinions.)

--  
Christopher Dearlove

On 25 Jan 2017, at 11:48, Alvaro Retana (aretana) &= lt;aretana@cisco.com> wrote:
=

= Christopher:

=  

= Thanks for looking into this report.

=  

= I don=E2=80=99t have an opinion as to which option is better, but I do have a= question:  What is implemented and deployed?   Section 17. (= Information Base Changes), which is the header for the changes the follow (including of course 17.1) makes the process normative a= nd mandatory: =E2=80=9CThe changes described in the following sections MUST b= e carried out=E2=80=A6=E2=80=9D  So it is important to choose the =E2=80= =9Cright=E2=80=9D solution.

=  

= Thanks!

=  

= Alvaro.

=  

On 12/1/16, 5:00 AM, "Dearlove, Christopher (UK)" <= ;chris.dearlove@baesystems.= com> wrote:

 

Author.

 

There is an issue, and the proposed resolution would w= ork, and is probably the minimal textual change. But it's potentially confus= ing creating a tuple to immediately change it.

 

I can see two possible better (in my opinion) texts, I= 'd appreciate comment (especially from co-author) on preference to recommend= as correction (including possibly for version I dislike).

 

NEW (1):

 

   If the router changes its originator add= ress, then:

 

   1.  If there is an Originator T= uple with:

 

       *  O_o= rig_addr =3D old originator address

 

       then modify it a= s follows:

 

       *  O_o= rig_addr :=3D new originator address

       *  O_t= ime :=3D current time + O_HOLD_TIME

 

       otherwise create= an Originator Tuple with:

 

       *  O_o= rig_addr :=3D new originator address

       *  O_t= ime :=3D current time + O_HOLD_TIME

 

NEW (2):

 

   If the router changes its originator add= ress, then:

 

   1.  If there is an Originator T= uple with:

 

       *  O_o= rig_addr =3D old originator address

 

       then remove it.<= o:p>

 

   2.  Create an Originator Tuple= with:

 

       *  O_o= rig_addr :=3D new originator address

       *  O_t= ime :=3D current time + O_HOLD_TIME

 

I think I prefer NEW (2).

 

--

Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________= _____________________

 

T:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com

 

BAE Systems Applied Intelligence, Chelmsford Technolo= gy Park, Great Baddow, Chelmsford, Essex CM2 8HN.

BAE Systems Applied Intelligence Limited

Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, S= urrey, GU2 7YP

 

-----Original Message-----

From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]

Sent: 01 December 2016 08:30

Subject: [Technical Errata Reported] RFC7181 (4874)

 

----------------------! WARNING ! -------------------= --- This message originates from outside our organisation, either from an ex= ternal partner or from the internet.

Consider carefully whether you should click on any li= nks, open any attachments or reply.

Follow the 'Report Suspicious Emails' link on IT matt= ers for instructions on reporting suspicious email messages.

-----------------------------------------------------= ---

 

The following errata report has been submitted for RFC= 7181, "The Optimized Link State Routing Protocol Version 2".

 

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

=

You may review the report below and at:

 

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

=

Type: Technical

Reported by: Nikolai Malykh <nmalykh@gmail.com>

 

Section: 17.1

 

Original Text

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

   If the router changes its originator add= ress, then:

 

   1.  If there is no Originator T= uple with:

 

       *  O_o= rig_addr =3D old originator address

 

       then create an O= riginator Tuple with:

 

       *  O_o= rig_addr :=3D old originator address

 

       The Originator T= uple (existing or new) with:

 

       *  O_o= rig_addr =3D new originator address

 

       is then modified= as follows:

 

       *  O_t= ime :=3D current time + O_HOLD_TIME

 

 

Corrected Text

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

   If the router changes its originator add= ress, then:

 

   1.  If there is no Originator T= uple with:

 

       *  O_o= rig_addr =3D old originator address

 

       then create an O= riginator Tuple with:

 

       *  O_o= rig_addr :=3D old originator address

 

       The Originator T= uple (existing or new) with:

 

       *  O_o= rig_addr =3D old originator address

 

       is then modified= as follows:

 

       *  O_o= rig_addr :=3D new originator address

 

       *  O_t= ime :=3D current time + O_HOLD_TIME

 

 

Notes

-----

At the time of the modification Originator Tuple with= O_orig_addr =3D new originator address does not yet exist.

 

Instructions:

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

This erratum is currently posted as "Reported". If ne= cessary, please use "Reply All" to discuss whether it should be verified or r= ejected. When a decision is reached, the verifying party can log in to chang= e the status and edit the report, if necessary.

 

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

=

RFC7181 (draft-ietf-manet-olsrv2-19)

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

=

Title        =        : The Optimized Link State Routing Prot= ocol Version 2

Publication Date    : April 2014<= o:p>

Author(s)       &n= bsp;   : T. Clausen, C. Dearlove, P. Jacquet, U. Herberg

Category       &nb= sp;    : PROPOSED STANDARD

Source        = ;      : Mobile Ad-hoc Networks

=

Area        &= nbsp;       : Routing

Stream        = ;      : IETF

Verifying Party     : IESG

 

*****************************************************= ***************

This email and any attachments are confidential to th= e intended

recipient and may also be privileged. If you are not t= he intended

recipient please delete it from your system and notif= y the sender.

You should not copy it or use it for any purpose nor d= isclose or

distribute its contents to any other person.

*****************************************************= ***************

 

 

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-8281F671-56D8-4D0C-89F4-9671A1F61C64-- From nobody Wed Jan 25 11:05:42 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43649129ADE for ; Wed, 25 Jan 2017 10:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06JpJhR5G6rq for ; Wed, 25 Jan 2017 10:42:09 -0800 (PST) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (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 D9ADE129AD4 for ; Wed, 25 Jan 2017 10:42:08 -0800 (PST) Received: by mail-vk0-x244.google.com with SMTP id r136so17131791vke.1 for ; Wed, 25 Jan 2017 10:42:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C9z5XIEy7p+iRNHkQW1ukrUnhigtTC7ATMpj39DqGcU=; b=FfmqsRzvtgVqfGETvDK6JNFCbLvvFFKbAUlBAt3vPK4LSt8cOkyuIevdw02jQACAiJ DfXe6jUHcn9Xynh7cIceZi20acY35Pt5YsZ9sG57jHY5TbQRMYqMRXdLhrhLOPXrUF9D NlX2nb4VfiCm20M229IJREGbqvKAGB/KJNhtZUzQWHRLaKtYv6+lBHYdhnrsEoy5v60L z0sC7IEbSN0Pp0Gp9rkB7auFZV812ZigZCA75wkeZJR2KogPPlrWMgnN5+gn56gG4k6l CLLiNqh1oM9ZFwSzDR4YGd/cDXoSOZMamns7kyc4mEpwYxkEjJPPwbNdpi+NVgfl/+Ro SumQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C9z5XIEy7p+iRNHkQW1ukrUnhigtTC7ATMpj39DqGcU=; b=D+tbPVQvBxg2xoJboWByXoraZi91/THGYQKJJQ6YxZjspRhBHl2ipnZTK2SsmUR9gw pFsWgopb6yOGeghws/kASr4RcZonZIvm3YMDsxH9qgPuw6IJdQV63pLgoi+qjLQiC7k/ puHZ03KBLeA3XZaC9uaYP2VAyFQLt574T8FhgDNmqcyJ47NqFvK3eaF9chhaNFZ2UYhT YdI0YhIjMcQ0Ah+M4GFQbWCF4xAEu22APxiBxt2Nr/7DBPBQPj+fbWRIP7yBxZnult1f E+kbHxpjZZrBYSGaB/SD3l3M0raRKW4HojM6/lGYAQyyMpaNMik4KkItPmdXcaly70w/ Rorw== X-Gm-Message-State: AIkVDXIBWJC0mwr3fCNIloYpY9shJPcX1PBrRkEnENfxJMEyfOf/5zD/ndSbnQoxwUKNVk6l8soBZHlvptudbw== X-Received: by 10.31.6.72 with SMTP id 69mr15056722vkg.19.1485369727905; Wed, 25 Jan 2017 10:42:07 -0800 (PST) MIME-Version: 1.0 References: <20161201082942.785D0B801CF@rfc-editor.org> In-Reply-To: From: Justin Dean Date: Wed, 25 Jan 2017 18:41:57 +0000 Message-ID: To: Christopher Dearlove , "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=001a1143dc6cfdf4020546ef9625 Archived-At: X-Mailman-Approved-At: Wed, 25 Jan 2017 11:05:37 -0800 Cc: "nmalykh@gmail.com" , "db3546@att.com" , "T.Clausen@computer.org" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "akatlas@gmail.com" , "philippe.jacquet@alcatel-lucent.com" , RFC Errata System Subject: Re: [manet] [Technical Errata Reported] RFC7181 (4874) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 18:42:12 -0000 --001a1143dc6cfdf4020546ef9625 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I prefer Chris' first proposal as it's what I do in my code to preserve other metadata associated with the entry. The delete then add is just as clean consepually but not how I tend to do things. Both of Chris' proposals are more clear in the intent (although functionally identical) than the proposed change. Justin On Wed, Jan 25, 2017, 12:58 PM Christopher Dearlove < christopher.dearlove@gmail.com> wrote: > The point should be that both produce functionally identical results, it'= s > a question of which is clearer. Whichever is written, an implementation c= an > always do either, or even a third option - there's a specific permission > given to do whatever you like as long as you behave as if you followed th= e > rules precisely. I'm fairly sure there are implementations that take > advantage of that in places (not necessarily here). > > (I'm doing this on a phone, without being able to check details. But I'm > assuming the preference I gave below is still my preference. But others m= ay > have other opinions.) > > -- > Christopher Dearlove > christopher.dearlove@gmail.com > > On 25 Jan 2017, at 11:48, Alvaro Retana (aretana) > wrote: > > Christopher: > > > > Thanks for looking into this report. > > > > I don=E2=80=99t have an opinion as to which option is better, but I do ha= ve a > question: What is implemented and deployed? Section 17. (Information > Base Changes), which is the header for the changes the follow (including = of > course 17.1) makes the process normative and mandatory: =E2=80=9CThe chan= ges > described in the following sections MUST be carried out=E2=80=A6=E2=80=9D= So it is > important to choose the =E2=80=9Cright=E2=80=9D solution. > > > > Thanks! > > > > Alvaro. > > > > On 12/1/16, 5:00 AM, "Dearlove, Christopher (UK)" < > chris.dearlove@baesystems.com> wrote: > > > > Author. > > > > There is an issue, and the proposed resolution would work, and is probabl= y > the minimal textual change. But it's potentially confusing creating a tup= le > to immediately change it. > > > > I can see two possible better (in my opinion) texts, I'd appreciate > comment (especially from co-author) on preference to recommend as > correction (including possibly for version I dislike). > > > > NEW (1): > > > > If the router changes its originator address, then: > > > > 1. If there is an Originator Tuple with: > > > > * O_orig_addr =3D old originator address > > > > then modify it as follows: > > > > * O_orig_addr :=3D new originator address > > * O_time :=3D current time + O_HOLD_TIME > > > > otherwise create an Originator Tuple with: > > > > * O_orig_addr :=3D new originator address > > * O_time :=3D current time + O_HOLD_TIME > > > > NEW (2): > > > > If the router changes its originator address, then: > > > > 1. If there is an Originator Tuple with: > > > > * O_orig_addr =3D old originator address > > > > then remove it. > > > > 2. Create an Originator Tuple with: > > > > * O_orig_addr :=3D new originator address > > * O_time :=3D current time + O_HOLD_TIME > > > > I think I prefer NEW (2). > > > > -- > > Christopher Dearlove > > Senior Principal Engineer > > BAE Systems Applied Intelligence Laboratories > > _________________________________________________________________________= _ > > > > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > > > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org > ] > > Sent: 01 December 2016 08:30 > > To: T.Clausen@computer.org; Dearlove, Christopher (UK); > philippe.jacquet@alcatel-lucent.com; ulrich@herberg.name; > akatlas@gmail.com; db3546@att.com; aretana@cisco.com; sratliff@idirect.ne= t; > bebemaster@gmail.com > > Cc: nmalykh@gmail.com; manet@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC7181 (4874) > > > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner > or from the internet. > > Consider carefully whether you should click on any links, open any > attachments or reply. > > Follow the 'Report Suspicious Emails' link on IT matters for instructions > on reporting suspicious email messages. > > -------------------------------------------------------- > > > > The following errata report has been submitted for RFC7181, "The Optimize= d > Link State Routing Protocol Version 2". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D7181&eid=3D4874 > > > > -------------------------------------- > > Type: Technical > > Reported by: Nikolai Malykh > > > > Section: 17.1 > > > > Original Text > > ------------- > > If the router changes its originator address, then: > > > > 1. If there is no Originator Tuple with: > > > > * O_orig_addr =3D old originator address > > > > then create an Originator Tuple with: > > > > * O_orig_addr :=3D old originator address > > > > The Originator Tuple (existing or new) with: > > > > * O_orig_addr =3D new originator address > > > > is then modified as follows: > > > > * O_time :=3D current time + O_HOLD_TIME > > > > > > Corrected Text > > -------------- > > If the router changes its originator address, then: > > > > 1. If there is no Originator Tuple with: > > > > * O_orig_addr =3D old originator address > > > > then create an Originator Tuple with: > > > > * O_orig_addr :=3D old originator address > > > > The Originator Tuple (existing or new) with: > > > > * O_orig_addr =3D old originator address > > > > is then modified as follows: > > > > * O_orig_addr :=3D new originator address > > > > * O_time :=3D current time + O_HOLD_TIME > > > > > > Notes > > ----- > > At the time of the modification Originator Tuple with O_orig_addr =3D new > originator address does not yet exist. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please use > "Reply All" to discuss whether it should be verified or rejected. When a > decision is reached, the verifying party can log in to change the status > and edit the report, if necessary. > > > > -------------------------------------- > > RFC7181 (draft-ietf-manet-olsrv2-19) > > -------------------------------------- > > Title : The Optimized Link State Routing Protocol Version 2 > > Publication Date : April 2014 > > Author(s) : T. Clausen, C. Dearlove, P. Jacquet, U. Herberg > > Category : PROPOSED STANDARD > > Source : Mobile Ad-hoc Networks > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > > > ******************************************************************** > > 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 > > --001a1143dc6cfdf4020546ef9625 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I prefer Chris' first proposal as it's what I do in = my code to preserve other metadata associated with the entry. The delete th= en add is just as clean consepually but not how I tend to do things.=C2=A0 = Both of Chris' proposals are more clear in the intent (although functio= nally identical) than the proposed change.

Justin


 --001a1143dc6cfdf4020546ef9625-- From nobody Wed Jan 25 12:44:43 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4538E129BC6 for ; Wed, 25 Jan 2017 12:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqr0F2AzVrAi for ; Wed, 25 Jan 2017 12:32:05 -0800 (PST) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (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 92195129BC2 for ; Wed, 25 Jan 2017 12:32:03 -0800 (PST) Received: by mail-qt0-x244.google.com with SMTP id l7so33657699qtd.3 for ; Wed, 25 Jan 2017 12:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=LSWHD5tMsY0jS1EXMTNfRU+5YYvAPQwnJgcsEGWw7Hs=; b=sPtniZGiwDaucvU52ARHm8YQ1Oh6aw44d5h3lMN2hqsaxGq2zBwE+eIDr6YS1BEIkl /I3zvzcZbcv/lXRyKoZSK4kwqh7KkBIbWpoki62p+rcZsVAkx/JfEHLENGYFLbNlg12n vB4QI5X3lD2f2j3yqD9Pwe0shrvr6XgXOZE0YT5CKKIVtHuf2k4+VX69EpJy2BFGtowv LGeRD3QIjqCodxIk+t2l4kp8w3yhrdSzo96gfkXAGYupOvrdBdkI2olYmrK78htt2RSD Gh94Ursbr04ED3FCAzCqfbQl6ZX0dGinGqZC8k3Ij1tpmjoyZ4CwoTJitVN1yUgjev2A HavQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=LSWHD5tMsY0jS1EXMTNfRU+5YYvAPQwnJgcsEGWw7Hs=; b=roDygEKmbaTx7J1aJ5rnnume4AMz33e2gV/vFaH4IzXYczTCVHHfTBl6P7X73YWmI+ 9TE9nQEyP+ACdzw3yT9Cl4lUP1M8viCSHJcohii3JUC0HZvFqz+R/Olsv21IMhr01qui 4oK5i7Hdgs4fEGCbO6EYyd3crs4eF319CnnqGyaukusLmuvI3eYpSJWeOUUX5Q9Q7c+7 RGikg7paUbzXNhmYhhdhQIAS+LCNIG6VFXft0VP3wcR9mU2tUo2i1ZXrCtx5HfP91app 2IU60xh8jL+Nwk8Cr7cLUQUvrNRYDwfMexVu79Qz6DsTqWKy+K1h3U9mqsH3lO3lAaY6 w6kA== X-Gm-Message-State: AIkVDXL9noe3fIl8C/tblueOqkm5BweTJJfvVkFSPZbUC5ZL2UyblG6psStrnEJeTxEUmQ== X-Received: by 10.55.148.71 with SMTP id w68mr29838739qkd.130.1485376322631; Wed, 25 Jan 2017 12:32:02 -0800 (PST) Received: from [9.59.144.242] ([129.34.8.20]) by smtp.gmail.com with ESMTPSA id h33sm18491385qtc.42.2017.01.25.12.32.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 12:32:01 -0800 (PST) References: <20161201082942.785D0B801CF@rfc-editor.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-7ECF6846-A810-44E1-855F-7438F1B26C92 Message-Id: <5CF1E8A2-DC63-4A0E-9363-C2F8E3DFE95F@gmail.com> X-Mailer: iPhone Mail (14C92) From: Christopher Dearlove Date: Wed, 25 Jan 2017 15:32:00 -0500 To: Justin Dean Archived-At: X-Mailman-Approved-At: Wed, 25 Jan 2017 12:44:34 -0800 Cc: "nmalykh@gmail.com" , "db3546@att.com" , "T.Clausen@computer.org" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "akatlas@gmail.com" , "philippe.jacquet@alcatel-lucent.com" , RFC Errata System Subject: Re: [manet] [Technical Errata Reported] RFC7181 (4874) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 20:32:15 -0000 --Apple-Mail-7ECF6846-A810-44E1-855F-7438F1B26C92 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Having just re-read both, today I agree with Justin, I prefer (1). If I'm th= at inconsistent in my preferences, I definitely could accept either. --=20 Christopher Dearlove christopher.dearlove@gmail.com chris@mnemosyne.demon.co.uk is dead > On 25 Jan 2017, at 13:41, Justin Dean wrote: >=20 > I prefer Chris' first proposal as it's what I do in my code to preserve ot= her metadata associated with the entry. The delete then add is just as clean= consepually but not how I tend to do things. Both of Chris' proposals are m= ore clear in the intent (although functionally identical) than the proposed c= hange. >=20 > Justin >=20 >=20 >> On Wed, Jan 25, 2017, 12:58 PM Christopher Dearlove wrote: >> The point should be that both produce functionally identical results, it'= s a question of which is clearer. Whichever is written, an implementation ca= n always do either, or even a third option - there's a specific permission g= iven to do whatever you like as long as you behave as if you followed the ru= les precisely. I'm fairly sure there are implementations that take advantage= of that in places (not necessarily here). >>=20 >> (I'm doing this on a phone, without being able to check details. But I'm a= ssuming the preference I gave below is still my preference. But others may h= ave other opinions.) >>=20 >> -- =20 >> Christopher Dearlove >> christopher.dearlove@gmail.com >>=20 >>> On 25 Jan 2017, at 11:48, Alvaro Retana (aretana) wr= ote: >>>=20 >>> Christopher: >>>=20 >>> =20 >>>=20 >>> Thanks for looking into this report. >>>=20 >>> =20 >>>=20 >>> I don=E2=80=99t have an opinion as to which option is better, but I do h= ave a question: What is implemented and deployed? Section 17. (Informatio= n Base Changes), which is the header for the changes the follow (including o= f course 17.1) makes the process normative and mandatory: =E2=80=9CThe chang= es described in the following sections MUST be carried out=E2=80=A6=E2=80=9D= So it is important to choose the =E2=80=9Cright=E2=80=9D solution. >>>=20 >>> =20 >>>=20 >>> Thanks! >>>=20 >>> =20 >>>=20 >>> Alvaro. >>>=20 >>> =20 >>>=20 >>> On 12/1/16, 5:00 AM, "Dearlove, Christopher (UK)" wrote: >>>=20 >>> =20 >>>=20 >>> Author. >>>=20 >>> =20 >>>=20 >>> There is an issue, and the proposed resolution would work, and is probab= ly the minimal textual change. But it's potentially confusing creating a tup= le to immediately change it. >>>=20 >>> =20 >>>=20 >>> I can see two possible better (in my opinion) texts, I'd appreciate comm= ent (especially from co-author) on preference to recommend as correction (in= cluding possibly for version I dislike). >>>=20 >>> =20 >>>=20 >>> NEW (1): >>>=20 >>> =20 >>>=20 >>> If the router changes its originator address, then: >>>=20 >>> =20 >>>=20 >>> 1. If there is an Originator Tuple with: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr =3D old originator address >>>=20 >>> =20 >>>=20 >>> then modify it as follows: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr :=3D new originator address >>>=20 >>> * O_time :=3D current time + O_HOLD_TIME >>>=20 >>> =20 >>>=20 >>> otherwise create an Originator Tuple with: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr :=3D new originator address >>>=20 >>> * O_time :=3D current time + O_HOLD_TIME >>>=20 >>> =20 >>>=20 >>> NEW (2): >>>=20 >>> =20 >>>=20 >>> If the router changes its originator address, then: >>>=20 >>> =20 >>>=20 >>> 1. If there is an Originator Tuple with: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr =3D old originator address >>>=20 >>> =20 >>>=20 >>> then remove it. >>>=20 >>> =20 >>>=20 >>> 2. Create an Originator Tuple with: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr :=3D new originator address >>>=20 >>> * O_time :=3D current time + O_HOLD_TIME >>>=20 >>> =20 >>>=20 >>> I think I prefer NEW (2). >>>=20 >>> =20 >>>=20 >>> -- >>>=20 >>> Christopher Dearlove >>>=20 >>> Senior Principal Engineer >>>=20 >>> BAE Systems Applied Intelligence Laboratories >>>=20 >>> ________________________________________________________________________= __ >>>=20 >>> =20 >>>=20 >>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>=20 >>> =20 >>>=20 >>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Badd= ow, Chelmsford, Essex CM2 8HN. >>>=20 >>> www.baesystems.com/ai >>>=20 >>> BAE Systems Applied Intelligence Limited >>>=20 >>> Registered in England & Wales No: 01337451 >>>=20 >>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>=20 >>> =20 >>>=20 >>> -----Original Message----- >>>=20 >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>=20 >>> Sent: 01 December 2016 08:30 >>>=20 >>> To: T.Clausen@computer.org; Dearlove, Christopher (UK); philippe.jacquet= @alcatel-lucent.com; ulrich@herberg.name; akatlas@gmail.com; db3546@att.com;= aretana@cisco.com; sratliff@idirect.net; bebemaster@gmail.com >>>=20 >>> Cc: nmalykh@gmail.com; manet@ietf.org; rfc-editor@rfc-editor.org >>>=20 >>> Subject: [Technical Errata Reported] RFC7181 (4874) >>>=20 >>> =20 >>>=20 >>> ----------------------! WARNING ! ---------------------- This message or= iginates from outside our organisation, either from an external partner or f= rom the internet. >>>=20 >>> Consider carefully whether you should click on any links, open any attac= hments or reply. >>>=20 >>> Follow the 'Report Suspicious Emails' link on IT matters for instruction= s on reporting suspicious email messages. >>>=20 >>> -------------------------------------------------------- >>>=20 >>> =20 >>>=20 >>> The following errata report has been submitted for RFC7181, "The Optimiz= ed Link State Routing Protocol Version 2". >>>=20 >>> =20 >>>=20 >>> -------------------------------------- >>>=20 >>> You may review the report below and at: >>>=20 >>> http://www.rfc-editor.org/errata_search.php?rfc=3D7181&eid=3D4874 >>>=20 >>> =20 >>>=20 >>> -------------------------------------- >>>=20 >>> Type: Technical >>>=20 >>> Reported by: Nikolai Malykh >>>=20 >>> =20 >>>=20 >>> Section: 17.1 >>>=20 >>> =20 >>>=20 >>> Original Text >>>=20 >>> ------------- >>>=20 >>> If the router changes its originator address, then: >>>=20 >>> =20 >>>=20 >>> 1. If there is no Originator Tuple with: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr =3D old originator address >>>=20 >>> =20 >>>=20 >>> then create an Originator Tuple with: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr :=3D old originator address >>>=20 >>> =20 >>>=20 >>> The Originator Tuple (existing or new) with: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr =3D new originator address >>>=20 >>> =20 >>>=20 >>> is then modified as follows: >>>=20 >>> =20 >>>=20 >>> * O_time :=3D current time + O_HOLD_TIME >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> Corrected Text >>>=20 >>> -------------- >>>=20 >>> If the router changes its originator address, then: >>>=20 >>> =20 >>>=20 >>> 1. If there is no Originator Tuple with: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr =3D old originator address >>>=20 >>> =20 >>>=20 >>> then create an Originator Tuple with: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr :=3D old originator address >>>=20 >>> =20 >>>=20 >>> The Originator Tuple (existing or new) with: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr =3D old originator address >>>=20 >>> =20 >>>=20 >>> is then modified as follows: >>>=20 >>> =20 >>>=20 >>> * O_orig_addr :=3D new originator address >>>=20 >>> =20 >>>=20 >>> * O_time :=3D current time + O_HOLD_TIME >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> Notes >>>=20 >>> ----- >>>=20 >>> At the time of the modification Originator Tuple with O_orig_addr =3D ne= w originator address does not yet exist. >>>=20 >>> =20 >>>=20 >>> Instructions: >>>=20 >>> ------------- >>>=20 >>> This erratum is currently posted as "Reported". If necessary, please use= "Reply All" to discuss whether it should be verified or rejected. When a de= cision is reached, the verifying party can log in to change the status and e= dit the report, if necessary. >>>=20 >>> =20 >>>=20 >>> -------------------------------------- >>>=20 >>> RFC7181 (draft-ietf-manet-olsrv2-19) >>>=20 >>> -------------------------------------- >>>=20 >>> Title : The Optimized Link State Routing Protocol Version 2= >>>=20 >>> Publication Date : April 2014 >>>=20 >>> Author(s) : T. Clausen, C. Dearlove, P. Jacquet, U. Herberg >>>=20 >>> Category : PROPOSED STANDARD >>>=20 >>> Source : Mobile Ad-hoc Networks >>>=20 >>> Area : Routing >>>=20 >>> Stream : IETF >>>=20 >>> Verifying Party : IESG >>>=20 >>> =20 >>>=20 >>> ******************************************************************** >>>=20 >>> 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. >>>=20 >>> You should not copy it or use it for any purpose nor disclose or >>>=20 >>> distribute its contents to any other person. >>>=20 >>> ******************************************************************** >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-7ECF6846-A810-44E1-855F-7438F1B26C92 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Having just re-read both, today I agre= e with Justin, I prefer (1). If I'm that inconsistent in my preferences, I d= efinitely could accept either.

-- 

On 25 Jan 2017, at 1= 3:41, Justin Dean <bebemaster@gma= il.com> wrote:

I prefer Chris' first proposal as it's what I do in my code to preserve= other metadata associated with the entry. The delete then add is just as cl= ean consepually but not how I tend to do things.  Both of Chris' propos= als are more clear in the intent (although functionally identical) than the p= roposed change.

Justin


On Wed, Jan 25, 2017, 12:58 P= M Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
The= point should be that both produce functionally identical results, it's a qu= estion of which is clearer. Whichever is written, an implementation can alwa= ys do either, or even a third option - there's a specific permission given t= o do whatever you like as long as you behave as if you followed the rules pr= ecisely. I'm fairly sure there are implementations that take advantage of th= at in places (not necessarily here).

(I'm doing thi= s on a phone, without being able to check details. But I'm assuming the pref= erence I gave below is still my preference. But others may have other opinio= ns.)

--  
Christopher Dearlove
chr= istopher.dearlove@gmail.com

On 25 Jan 2017, a= t 11:48, Alvaro Retana (aretana) <aretana@cisco.com> wrote:

Christopher:

 

Thanks for looking into this report.

 

I don=E2=80=99t have an opinion as to which op= tion is better, but I do have a question:  What is implemented and depl= oyed?   Section 17. (Information Base Changes), which is the heade= r for the changes the follow (including of course 17.1) makes the process normative a= nd mandatory: =E2=80=9CThe changes described in the following sections MUST b= e carried out=E2=80=A6=E2=80=9D  So it is important to choose the =E2=80= =9Cright=E2=80=9D solution.

 

Thanks!

 

Alvaro.

 

On 12/1/16, 5:00 AM, "Dearlove, Christopher= (UK)" <chris.dearlove@baesystems.com> wrote:

 

Author.

 

There is an issue, and the proposed resolut= ion would work, and is probably the minimal textual change. But it's potenti= ally confusing creating a tuple to immediately change it.

 

I can see two possible better (in my opinio= n) texts, I'd appreciate comment (especially from co-author) on preference t= o recommend as correction (including possibly for version I dislike).

 

NEW (1):

 

   If the router changes its orig= inator address, then:<= /p>

 

   1.  If there is an O= riginator Tuple with:<= /p>

 

       * = ; O_orig_addr =3D old originator address

 

       then m= odify it as follows:

 

       * = ; O_orig_addr :=3D new originator address

       * = ; O_time :=3D current time + O_HOLD_TIME

 

       otherw= ise create an Originator Tuple with:

 

       * = ; O_orig_addr :=3D new originator address

       * = ; O_time :=3D current time + O_HOLD_TIME

 

NEW (2):

 

   If the router changes its orig= inator address, then:<= /p>

 

   1.  If there is an O= riginator Tuple with:<= /p>

 

       * = ; O_orig_addr =3D old originator address

 

       then r= emove it.

 

   2.  Create an Origin= ator Tuple with:

 

       * = ; O_orig_addr :=3D new originator address

       * = ; O_time :=3D current time + O_HOLD_TIME

 

I think I prefer NEW (2).

 

--

Christopher Dearlove=

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratori= es

___________________________________________= _______________________________

 

T:  +44 (0)1245 242194  |  E= : chris.dearlove@baesystems.com

 

BAE Systems Applied Intelligence, Chelmsfor= d Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.

www.baesystems.com/ai

BAE Systems Applied Intelligence Limited

Registered in England & Wales No: 01337= 451

Registered Office: Surrey Research Park, Gu= ildford, Surrey, GU2 7YP

 

-----Original Message-----

From: RFC Errata System [mailto:rfc-= editor@rfc-editor.org]

Sent: 01 December 2016 08:30

To: T.Clausen@computer.org; Dearlov= e, Christopher (UK); philippe.jacquet@alcatel-lucent.com; ulrich@herberg.name; akatlas@gmail.com; db3546@att.com; aretana@cisco.com; sratliff@idirect.net; bebemaster@gmail.com=

Cc: nmalykh@gmail.com; mane= t@ietf.org; rfc-editor@rfc-editor.org

Subject: [Technical Errata Reported] RFC718= 1 (4874)

 

----------------------! WARNING ! ---------= ------------- This message originates from outside our organisation, either f= rom an external partner or from the internet.

Consider carefully whether you should click= on any links, open any attachments or reply.

Follow the 'Report Suspicious Emails' link o= n IT matters for instructions on reporting suspicious email messages.

-------------------------------------------= -------------

 

The following errata report has been submit= ted for RFC7181, "The Optimized Link State Routing Protocol Version 2".

 

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

You may review the report below and at:

http://www.rfc-editor.org/errata_search.php?rfc=3D7181&eid=3D4874

 

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

Type: Technical<= u class=3D"gmail_msg">

Reported by: Nikolai Malykh <nmalykh@gmai= l.com>

 

Section: 17.1

 

Original Text

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

   If the router changes its orig= inator address, then:<= /p>

 

   1.  If there is no O= riginator Tuple with:<= /p>

 

       * = ; O_orig_addr =3D old originator address

 

       then c= reate an Originator Tuple with:

 

       * = ; O_orig_addr :=3D old originator address

 

       The Or= iginator Tuple (existing or new) with:

 

       * = ; O_orig_addr =3D new originator address

 

       is the= n modified as follows:=

 

       * = ; O_time :=3D current time + O_HOLD_TIME

 

 

Corrected Text

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

   If the router changes its orig= inator address, then:<= /p>

 

   1.  If there is no O= riginator Tuple with:<= /p>

 

       * = ; O_orig_addr =3D old originator address

 

       then c= reate an Originator Tuple with:

 

       * = ; O_orig_addr :=3D old originator address

 

       The Or= iginator Tuple (existing or new) with:

 

       * = ; O_orig_addr =3D old originator address

 

       is the= n modified as follows:=

 

       * = ; O_orig_addr :=3D new originator address

 

       * = ; O_time :=3D current time + O_HOLD_TIME

 

 

Notes

-----

At the time of the modification Originator T= uple with O_orig_addr =3D new originator address does not yet exist.

 

Instructions:

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

This erratum is currently posted as "Report= ed". If necessary, please use "Reply All" to discuss whether it should be ve= rified or rejected. When a decision is reached, the verifying party can log i= n to change the status and edit the report, if necessary.

 

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

RFC7181 (draft-ietf-manet-olsrv2-19)

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

Title      &n= bsp;        : The Optimized Link State Ro= uting Protocol Version 2

Publication Date    : A= pril 2014

Author(s)     &nbs= p;     : T. Clausen, C. Dearlove, P. Jacquet, U. Herberg=

Category      = ;      : PROPOSED STANDARD

Source      &= nbsp;       : Mobile Ad-hoc Networks

Area      &nb= sp;         : Routing

Stream      &= nbsp;       : IETF=

Verifying Party     : I= ESG

 

*******************************************= *************************<= /u>

This email and any attachments are confiden= tial to the intended

recipient and may also be privileged. If yo= u 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 pu= rpose nor disclose or<= /p>

distribute its contents to any other person= .

*******************************************= *************************<= /u>

 

 

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/= listinfo/manet
= --Apple-Mail-7ECF6846-A810-44E1-855F-7438F1B26C92-- From nobody Mon Jan 30 19:26:58 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31FF129D0A; Mon, 30 Jan 2017 19:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMeuCp3BSuNa; Mon, 30 Jan 2017 19:26:49 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 9C905129D09; Mon, 30 Jan 2017 19:26:49 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id c7so116694952itd.1; Mon, 30 Jan 2017 19:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fu/5ci1yF0AEy7+jlW1T/WKbGcCv06GsqLS/Iin6WUU=; b=JgowL0F7KAcwuZDTMNCRRejqFi8aiuXg8yif1cXK/ghLA2EQvewHhZ3kTaYfFEUZi1 VfAQVO5c2rNCRZxTmF57Yl5T+3/G3fKrUriWh2k+EvgeVoo3/CisHjwL7+1G8jQxpFPP 0W2nmU4XVJvTwHnm272RDgVLWm2x580RvmZH8s+tlxxtn149nYR8qxRDywKo8FawBigJ hm24EjwVMiNaA91vMv+FzC4INCTNHZU8ZK29xhorYHqYnLXjx0WGkqZcN2ijrdleL1+4 Cus0nRQU6Jg12kXMEgNi0mbgcB4LdEdWkmg2TzKzq6CQ/X0SFe2AhChLU/xzYGyzA4qB qbmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fu/5ci1yF0AEy7+jlW1T/WKbGcCv06GsqLS/Iin6WUU=; b=MLsuV26u/YCFHA5q+ZMdmXc4hcMmQivRqVyaDGDMWQJQU0hGWMN/giMhhqvMpj5dvO TpX4BAKbo847dskWDwmOtFXR5MmTF2UrjuOGptLdatZuuwVyim8aodg9Sp1xqZ7XZ0UW 7LA+Yh55ZxscyOkk4My6HnHSwDULxMvkbGTxc4KnaCUGsHEoZ26CyYRrTphXX76iBngI EtvxkWYAvPri5NaNa3U7n8PC+UKB1XqdGYXulmqkc3/OsFMvziL7WzBol2C40ujx5puW Bi5QH/bc9OY/joBZMcAyjfUOpEXluPos7k+BKhbpA+B5+2S9/4hTTUkTYiFbmMkNXdBa Sa8Q== X-Gm-Message-State: AIkVDXIwvnfUs/E9HDNGIGKKlKdEqhGgpJ5svzz3PN6vvTEq48uJLLD/GlajZ8FcqFCEySwmafKEr9Yrq0G0mg== X-Received: by 10.36.57.10 with SMTP id l10mr17911639ita.88.1485833208925; Mon, 30 Jan 2017 19:26:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.158.87 with HTTP; Mon, 30 Jan 2017 19:26:48 -0800 (PST) In-Reply-To: <1481814927.2566.30.camel@tropicalstormsoftware.com> References: <148156334986.22491.1152871712874859894.idtracker@ietfa.amsl.com> <79D48CEB-2CFC-43A8-8D01-5C5CB1778966@fastmail.fm> <9B802ACF-84EF-4C47-92F8-122CA724C71A@fastmail.fm> <1481813917.419436.820073297.68E45D5D@webmail.messagingengine.com> <1481814927.2566.30.camel@tropicalstormsoftware.com> From: Stan Ratliff Date: Mon, 30 Jan 2017 22:26:48 -0500 Message-ID: To: Rick Taylor Content-Type: multipart/alternative; boundary=001a114aa1a09d159205475b80f6 Archived-At: Cc: "manet-chairs@ietf.org" , "aamelnikov@fastmail.fm" , "manet@ietf.org" , "draft-ietf-manet-dlep@ietf.org" , "iesg@ietf.org" Subject: Re: [manet] Alexey Melnikov's Discuss on draft-ietf-manet-dlep-26: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 03:26:52 -0000 --001a114aa1a09d159205475b80f6 Content-Type: text/plain; charset=UTF-8 All, The authors have submitted DLEP-27 to address the DISCUSS items. With regard to Alexey's DISCUSS points, On Thu, Dec 15, 2016 at 10:15 AM, Rick Taylor wrote: > On Thu, 2016-12-15 at 14:58 +0000, Alexey Melnikov wrote: > > On Thu, Dec 15, 2016, at 09:21 AM, Henning Rogge wrote: > > > > > > On Thu, Dec 15, 2016 at 10:23 AM, Alexey Melnikov > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > On 15 Dec 2016, at 08:59, Henning Rogge > > > > > wrote: > > > > > > > > > > On Tue, Dec 13, 2016 at 11:11 AM, Alexey Melnikov > > > > > wrote: > > > > > > > > > > > > Hi Stan, > > > > > > > > > > > > All your answers look good to me. But I think credential > > > > > > validation might need a bit more thought/discussion in the > > > > > > WG. Maybe you can specify how preconfigured IP or MAC > > > > > > addresses can be checked in X.509 certificates? (Just an > > > > > > idea, not necessarily saying that it is the right or the only > > > > > > way of doing this) > > > > > I raised the point of the certificate problem ages ago as an > > > > > argument > > > > > to DROP TLS from DLEP completely. > > > > Even unauthenticated TLS is better than no TLS, so I would rather > > > > the document continues to recommend it. > > > What kind of security does unauthenticated TLS provide against an > > > attacker that sits on your local LAN segment? > > I am not really concerned about that, but I am concerned about VPN or > > virtualized environment where router is across the globe from the > > modem. > We have added an "Assumptions" section (Section 5), and have added text (paragraph 2) stating that in a VPN environment between router and modem, link statistics reported by DLEP may be inadequate for route selection. We've also added text to the security considerations section concerning use of pre-shared keys in mobile environments. We hope this additional text addresses your concerns. Regards, Stan > > This was why we put in the text in the security considerations stating > that those environments need all security provided by whatever Layer-2 > tunnelling protocols are used. However, we had several discuss's > suggesting that this wasn't enough... > > > > > > > > > Its not that DLEP carry > > > any "secret" data... > > That is the question really. If the date is exposed outside of LAN, > > does > > it contain no sensitive information? > > > I have spoken with a few radio vendors and from what I got none of > > > them considers to implement TLS. Nobody sees any advantage of it, > > > but > > > everyone sees a huge cost. Cost in terms of performance (Flow > > > control > > > is delay dependent), cost in terms of complexity, costs in terms of > > > interoperability. > > > > > > Henning Rogge > > _______________________________________________ > > 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 > --001a114aa1a09d159205475b80f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,=C2=A0

The authors have submitted D= LEP-27 to address the DISCUSS items. With regard to Alexey's DISCUSS po= ints,=C2=A0

On= Thu, Dec 15, 2016 at 10:15 AM, Rick Taylor <rick@tropicals= tormsoftware.com> wrote:
On Thu, 2016-12-15 at 14:58 +0000, Alexey Melnikov wrote:
> On Thu, Dec 15, 2016, at 09:21 AM, Henning Rogge wrote:
> >
> > On Thu, Dec 15, 2016 at 10:23 AM, Alexey Melnikov
> > <a= amelnikov@fastmail.fm> wrote:
> > >
> > > Hi,
> > >
> > > >
> > > > On 15 Dec 2016, at 08:59, Henning Rogge <hrogge@gmail.com>
> > > > wrote:
> > > >
> > > > On Tue, Dec 13, 2016 at 11:11 AM, Alexey Melnikov
> > > > <aamelnikov@fastmail.fm> wrote:
> > > > >
> > > > > Hi Stan,
> > > > >
> > > > > All your answers look good to me. But I think cred= ential
> > > > > validation might need a bit more thought/discussio= n in the
> > > > > WG. Maybe you can specify how preconfigured IP or = MAC
> > > > > addresses can be checked in X.509 certificates? (J= ust an
> > > > > idea, not necessarily saying that it is the right = or the only
> > > > > way of doing this)
> > > > I raised the point of the certificate problem ages ago = as an
> > > > argument
> > > > to DROP TLS from DLEP completely.
> > > Even unauthenticated TLS is better than no TLS, so I would r= ather
> > > the document continues to recommend it.
> > What kind of security does unauthenticated TLS provide against an=
> > attacker that sits on your local LAN segment?
> I am not really concerned about that, but I am concerned about VPN or<= br> > virtualized environment where router is across the globe from the
> modem.

We have added an "Assu= mptions" section (Section 5), and have added text (paragraph 2) statin= g that in a VPN environment between router and modem, link statistics repor= ted by DLEP may be inadequate for route selection.=C2=A0

We've also added text to the security considerations section con= cerning use of pre-shared keys in mobile environments.=C2=A0

=
We hope this additional text addresses your concerns.=C2=A0

Regards,
Stan
=C2=A0

This was why we put in the text in the security considerations stating
that those environments need all security provided by whatever Layer-2
tunnelling protocols are used.=C2=A0 However, we had several discuss's<= br> suggesting that this wasn't enough...

>
> >
> > Its not that DLEP carry
> > any "secret" data...
> That is the question really. If the date is exposed outside of LAN, > does
> it contain no sensitive information?
> > I have spoken with a few radio vendors and from what I got none o= f
> > them considers to implement TLS. Nobody sees any advantage of it,=
> > but
> > everyone sees a huge cost. Cost in terms of performance (Flow
> > control
> > is delay dependent), cost in terms of complexity, costs in terms = of
> > interoperability.
> >
> > Henning Rogge
> _______________________________________________
> 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

--001a114aa1a09d159205475b80f6-- From nobody Mon Jan 30 19:30:33 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DF5129D09; Mon, 30 Jan 2017 19:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfTwl9uZvZBj; Mon, 30 Jan 2017 19:30:27 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 7C1E41298D2; Mon, 30 Jan 2017 19:30:27 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id c7so116735339itd.1; Mon, 30 Jan 2017 19:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ecf8sN19PhKmgG+HbEnWkYasLGm3O2XTg1c4sRUTvhk=; b=qlKVtNqgshUYtYhc2brfS/kYJc3kBTipkbJz81NkALs9SqCUq8pA1MgVyGaWxkcCxz SBNkHpjStBXYLCHaVfdkBtLdfSuaAqDw+OSruNsIaWrqisWDBvwk4mwCCRMpdO7yXarR LszO3OLWg3F7fF9GsOKYelQM/lDgNKZocnr5eMkGEnT9J1IHPjHT0qTom2e9wJhlLGK+ BCkM/5CPoa8S6sEHD8E6YnoqtzcbKTyo7V2VmSBZPRjMxARTXbJStmk1DBaE+TAL8+Y1 5UYFDKTH7v8RxotwEyyR6er2h1A+j1+SE8rhpw41vEYVsm5uGBVYcPtjV8BN8H6Yo0VD FfTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ecf8sN19PhKmgG+HbEnWkYasLGm3O2XTg1c4sRUTvhk=; b=G0Jl0yro3pZUTPHxRZXO1B6HVZf9mncR3LjyWYxmBLfwtvo9PUyHwfE81hIyOyiSxw 35m4B6M0ldtOOFlKRwaYKO0eJMWip4bBP1cpp58nFvkH80097jRUeV3Iy87P9ibkfUzz lpeUUzZndNCp4iwhK0pCM/8hk7YAJ0sot9tYbGNZJe8PBnvusoV7l+JeUFU6qMDSX+Cw rxp8UoT0AQhB155u4/VoQN04W9TShMoAqJ2CThJwqPyPd4dw1D75NoyczfYlAY3zV8Xs qmrXvQU2Y1byNsLdX6BynQk3KKUeo21FBNylIXGPhKduiqVqa2EmAV8OIbMd2Hu7N+Wp foAA== X-Gm-Message-State: AIkVDXLMJrAmNZLbcJuSUeq2e9rpo4APJflNmIApsaNjzpeSTudiIwR0hOXOi4KAx7UWKRGk2qYD1WMgJ458MQ== X-Received: by 10.36.123.145 with SMTP id q139mr18229041itc.62.1485833426855; Mon, 30 Jan 2017 19:30:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.158.87 with HTTP; Mon, 30 Jan 2017 19:30:26 -0800 (PST) In-Reply-To: <148169297159.10864.11213404330614218630.idtracker@ietfa.amsl.com> References: <148169297159.10864.11213404330614218630.idtracker@ietfa.amsl.com> From: Stan Ratliff Date: Mon, 30 Jan 2017 22:30:26 -0500 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a1146f0309a8d5305475b8d7a Archived-At: Cc: MANET IETF , The IESG , draft-ietf-manet-dlep@ietf.org, manet-chairs@ietf.org Subject: Re: [manet] Suresh Krishnan's Discuss on draft-ietf-manet-dlep-26: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 03:30:29 -0000 --001a1146f0309a8d5305475b8d7a Content-Type: text/plain; charset=UTF-8 Suresh, Thank you for the review comments. We have submitted DLEP-27, and we believe it addresses your concerns. Additional information inline: On Wed, Dec 14, 2016 at 12:22 AM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-manet-dlep-26: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > * Section 11.7 > The MAC address encoding on the wire seems to be wrong. Instead of using > 6 bytes for MAC-48 the document seems to using 8 bytes. Similarly for > EUI-64 the document seems to be using 12 bytes instead of 8. Please fix > this (Also Note that the length values specified under the format of the > data item seem to be correct i.e. 6 & 8 - it is the data item format that > is wrong) > > Corrected the ASCII art. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Sections 11.2, 11.3, 11.9 and 11.10 > The IPv4 and IPv6 addresses do not seem to be aligned on word boundaries. > Didn't you face any inefficiencies/difficulties due to this in your > implementations (I saw there were four independent ones)? > Due to the nature of TLV processing, and the fact that DLEP does not place ordering constraints on TLVs, the notion of alignment was pretty much given up long ago. Since DLEP is a control plane protocol, the performance penalties are not deemed sufficiently painful (e.g., there's just not enough traffic for it to be a huge problem). > > * Section 11.11.1 > Agree with Alia's point that there seems to be a typo in "IPv4 Attached > Subnet" > Fixed. Regards, Stan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a1146f0309a8d5305475b8d7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Suresh,=C2=A0

Thank you for the review = comments. We have submitted DLEP-27, and we believe it addresses your conce= rns. Additional information inline:=C2=A0
<= br>
On Wed, Dec 14, 2016 at 12:22 AM, Suresh Kris= hnan <suresh.krishnan@ericsson.com> wrote:
Suresh Krishnan has entered the following ballo= t position for
draft-ietf-manet-dlep-26: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-manet-dlep/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

* Section 11.7
The MAC address encoding on the wire seems to be wrong. Instead of using 6 bytes for MAC-48 the document seems to using 8 bytes. Similarly for
EUI-64 the document seems to be using 12 bytes instead of 8. Please fix
this (Also Note that the length values specified under the format of the data item seem to be correct i.e. 6 & 8 - it is the data item format th= at
is wrong)


Corrected the ASCII art.=C2=A0
=C2=A0

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

* Sections 11.2, 11.3, 11.9 and 11.10
The IPv4 and IPv6 addresses do not seem to be aligned on word boundaries. Didn't you face any inefficiencies/difficulties due to this in your
implementations (I saw there were four independent ones)?
<= div>
Due to the nature of TLV processing, and the fact that D= LEP does not place ordering constraints on TLVs, the notion of alignment wa= s pretty much given up long ago. Since DLEP is a control plane protocol, th= e performance penalties are not deemed sufficiently painful (e.g., there= 9;s just not enough traffic for it to be a huge problem).=C2=A0
= =C2=A0

* Section 11.11.1
Agree with Alia's point that there seems to be a typo in "IPv4 Att= ached
Subnet"

Fixed.=C2=A0
Regards,
Stan
=C2=A0


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

--001a1146f0309a8d5305475b8d7a-- From nobody Tue Jan 31 02:08:14 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE92E120725; Tue, 31 Jan 2017 02:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 c7T26MT7MdcP; Tue, 31 Jan 2017 02:08:11 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6AB1204D9; Tue, 31 Jan 2017 02:08:10 -0800 (PST) X-AuditID: c6180641-e73ff70000000a0b-ab-58900d9c5607 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id 88.79.02571.C9D00985; Tue, 31 Jan 2017 05:07:58 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0319.002; Tue, 31 Jan 2017 05:08:07 -0500 From: Suresh Krishnan To: Stan Ratliff Thread-Topic: [manet] Suresh Krishnan's Discuss on draft-ietf-manet-dlep-26: (with DISCUSS and COMMENT) Thread-Index: AQHSVcohsd/RbZGzekagDZY0o+pV+qFSjPYAgAB/3wA= Date: Tue, 31 Jan 2017 10:08:07 +0000 Message-ID: <4E7AE205-FD94-48C4-9719-92AB36F5BE54@ericsson.com> References: <148169297159.10864.11213404330614218630.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyuXRPlO483gkRBn8WClhc6pnMaDHjz0Rm i1V/tzBb/NvyhN1i3csdLA6sHjtn3WX3WLLkJ1MAUxSXTUpqTmZZapG+XQJXxq3J05gKfslX HDs2m7GBcYJ8FyMnh4SAicSlVR+Zuhi5OIQE1jNK7F83kx3CWc4o8XvKciaQKjagqg07P4PZ IgIaEvMvbGAEKWIW2Mgoca39HVsXIweHsECGRPN6foiaTIlrcy4ygYRFBKwk5p2vBwmzCKhK NDxayAJi8wrYS0y4vYUNYtdURold7/sZQeo5BQIlFnU6gdQwCohJfD+1Bmwts4C4xK0n85kg jhaQWLLnPDOELSrx8vE/VhBbVEBPYuOFaewQcSWJSUvPsYKMZBbQlFi/Sx9ijLXEzj0f2SBs RYkp3Q/ZIc4RlDg58wnLBEbxWUi2zULonoWkexaS7llIuhcwsq5i5CgtLsjJTTcy3MQIjLdj EmyOOxj39noeYhTgYFTi4f0Q0h8hxJpYVlyZe4hRgoNZSYT32xKgEG9KYmVValF+fFFpTmrx IUZpDhYlcd7rIffDhQTSE0tSs1NTC1KLYLJMHJxSDYxr1e5wxNx4Pr903ZJlFrX3xNVUdn99 36X4fpP5xodvhZp78gU/R7H+ONx2gzldsjnuZjDnddfrglHJIiU2UZkx4V88lwsdzDt8a0r4 lqO9PrkdMQULhNU93JenpC6IWGGSv91e6YzlF+19PBJSau/Xec9TObx35rnf/A/j/ze/3KKf n2nlFqjEUpyRaKjFXFScCABaie2RswIAAA== Archived-At: Cc: MANET IETF , The IESG , "draft-ietf-manet-dlep@ietf.org" , "manet-chairs@ietf.org" Subject: Re: [manet] Suresh Krishnan's Discuss on draft-ietf-manet-dlep-26: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 10:08:13 -0000 VGhhbmtzIFN0YW4uIEkgaGF2ZSBjbGVhcmVkLg0KDQpSZWdhcmRzDQpTdXJlc2gNCg0KT24gMS8z MS8xNywgNDozMCBBTSwgIlN0YW4gUmF0bGlmZiIgPHJhdGxpZmZzdGFuQGdtYWlsLmNvbT4gd3Jv dGU6DQoNCiAgICBTdXJlc2gsIA0KICAgIA0KICAgIA0KICAgIFRoYW5rIHlvdSBmb3IgdGhlIHJl dmlldyBjb21tZW50cy4gV2UgaGF2ZSBzdWJtaXR0ZWQgRExFUC0yNywgYW5kIHdlIGJlbGlldmUg aXQgYWRkcmVzc2VzIHlvdXIgY29uY2VybnMuIEFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW5saW5l OiANCiAgICANCiAgICBPbiBXZWQsIERlYyAxNCwgMjAxNiBhdCAxMjoyMiBBTSwgU3VyZXNoIEty aXNobmFuIA0KICAgIDxzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tPiB3cm90ZToNCiAgICAN CiAgICBTdXJlc2ggS3Jpc2huYW4gaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9z aXRpb24gZm9yDQogICAgZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTI2OiBEaXNjdXNzDQogICAgDQog ICAgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsDQogICAgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBh bmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCiAgICBpbnRyb2R1Y3RvcnkgcGFy YWdyYXBoLCBob3dldmVyLikNCiAgICANCiAgICANCiAgICBQbGVhc2UgcmVmZXIgdG8gDQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1s IDxodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0 bWw+DQogICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01N RU5UIHBvc2l0aW9ucy4NCiAgICANCiAgICANCiAgICBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLw0KICAgIA0KICAg IA0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBESVNDVVNTOg0KICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCiAgICANCiAgICAqIFNlY3Rpb24gMTEuNw0KICAgIFRoZSBNQUMgYWRkcmVzcyBlbmNvZGlu ZyBvbiB0aGUgd2lyZSBzZWVtcyB0byBiZSB3cm9uZy4gSW5zdGVhZCBvZiB1c2luZw0KICAgIDYg Ynl0ZXMgZm9yIE1BQy00OCB0aGUgZG9jdW1lbnQgc2VlbXMgdG8gdXNpbmcgOCBieXRlcy4gU2lt aWxhcmx5IGZvcg0KICAgIEVVSS02NCB0aGUgZG9jdW1lbnQgc2VlbXMgdG8gYmUgdXNpbmcgMTIg Ynl0ZXMgaW5zdGVhZCBvZiA4LiBQbGVhc2UgZml4DQogICAgdGhpcyAoQWxzbyBOb3RlIHRoYXQg dGhlIGxlbmd0aCB2YWx1ZXMgc3BlY2lmaWVkIHVuZGVyIHRoZSBmb3JtYXQgb2YgdGhlDQogICAg ZGF0YSBpdGVtIHNlZW0gdG8gYmUgY29ycmVjdCBpLmUuIDYgJiA4IC0gaXQgaXMgdGhlIGRhdGEg aXRlbSBmb3JtYXQgdGhhdA0KICAgIGlzIHdyb25nKQ0KICAgIA0KICAgIA0KICAgIA0KICAgIA0K ICAgIA0KICAgIENvcnJlY3RlZCB0aGUgQVNDSUkgYXJ0LiANCiAgICAgDQogICAgDQogICAgDQog ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0K ICAgICogU2VjdGlvbnMgMTEuMiwgMTEuMywgMTEuOSBhbmQgMTEuMTANCiAgICBUaGUgSVB2NCBh bmQgSVB2NiBhZGRyZXNzZXMgZG8gbm90IHNlZW0gdG8gYmUgYWxpZ25lZCBvbiB3b3JkIGJvdW5k YXJpZXMuDQogICAgRGlkbid0IHlvdSBmYWNlIGFueSBpbmVmZmljaWVuY2llcy9kaWZmaWN1bHRp ZXMgZHVlIHRvIHRoaXMgaW4geW91cg0KICAgIGltcGxlbWVudGF0aW9ucyAoSSBzYXcgdGhlcmUg d2VyZSBmb3VyIGluZGVwZW5kZW50IG9uZXMpPw0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAg IER1ZSB0byB0aGUgbmF0dXJlIG9mIFRMViBwcm9jZXNzaW5nLCBhbmQgdGhlIGZhY3QgdGhhdCBE TEVQIGRvZXMgbm90IHBsYWNlIG9yZGVyaW5nIGNvbnN0cmFpbnRzIG9uIFRMVnMsIHRoZSBub3Rp b24gb2YgYWxpZ25tZW50IHdhcyBwcmV0dHkgbXVjaCBnaXZlbiB1cCBsb25nIGFnby4gU2luY2Ug RExFUCBpcyBhIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wsIHRoZSBwZXJmb3JtYW5jZSBwZW5hbHRp ZXMgYXJlIG5vdCBkZWVtZWQgc3VmZmljaWVudGx5DQogICAgIHBhaW5mdWwgKGUuZy4sIHRoZXJl J3MganVzdCBub3QgZW5vdWdoIHRyYWZmaWMgZm9yIGl0IHRvIGJlIGEgaHVnZSBwcm9ibGVtKS4g DQogICAgIA0KICAgIA0KICAgIA0KICAgICogU2VjdGlvbiAxMS4xMS4xDQogICAgQWdyZWUgd2l0 aCBBbGlhJ3MgcG9pbnQgdGhhdCB0aGVyZSBzZWVtcyB0byBiZSBhIHR5cG8gaW4gIklQdjQgQXR0 YWNoZWQNCiAgICBTdWJuZXQiDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgRml4ZWQuIA0K ICAgIA0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgU3Rhbg0KICAgICANCiAgICANCiAgICANCiAg ICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ICAgIG1hbmV0IG1haWxpbmcgbGlzdA0KICAgIG1hbmV0QGlldGYub3JnDQogICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KICAgIA0KICAgIA0KICAgIA0KICAg IA0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Tue Jan 31 02:09:07 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D15501204D9; Tue, 31 Jan 2017 02:09:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148585734185.2491.2581640090106756702.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 02:09:01 -0800 Archived-At: Cc: manet@ietf.org, draft-ietf-manet-dlep@ietf.org, manet-chairs@ietf.org Subject: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-dlep-27: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 10:09:02 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-manet-dlep-27: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and COMMENT points.
On Wed, Jan 25, 2017, 12:58= PM Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
The point should be that both produce functionally identical results, it= 's a question of which is clearer. Whichever is written, an implementat= ion can always do either, or even a third option - there's a specific p= ermission given to do whatever you like as long as you behave as if you fol= lowed the rules precisely. I'm fairly sure there are implementations th= at take advantage of that in places (not necessarily here).

(I'm doing this on a phone, without being able to check = details. But I'm assuming the preference I gave below is still my prefe= rence. But others may have other opinions.)

-- =C2=A0
Christopher Dearlove
christopher.dearlove@gmail.com

On 25 Jan 2017, at 11:48, Alvaro Retana (aretan= a) <aretana@cisco.com> wrote:

Christopher:

=C2=A0

Thanks for looking into this report.

=C2=A0

I don=E2=80=99t have an opinion as to which = option is better, but I do have a question:=C2=A0 What is implemented and d= eployed?=C2=A0 =C2=A0Section 17. (Information Base Changes), which is the h= eader for the changes the follow (including of course 17.1) makes the process normative = and mandatory: =E2=80=9CThe changes described in the following sections MUS= T be carried out=E2=80=A6=E2=80=9D=C2=A0 So it is important to choose the = =E2=80=9Cright=E2=80=9D solution.

=C2=A0

Thanks!

=C2=A0

Alvaro.

=C2=A0

On 12/1/16, 5:00 AM, "Dearlove, Chris= topher (UK)" <chris.dearlove@baesystems.com> wro= te:

=C2=A0

Author.

=C2=A0

There is an issue, and the proposed resolu= tion would work, and is probably the minimal textual change. But it's p= otentially confusing creating a tuple to immediately change it.

=C2=A0

I can see two possible better (in my opini= on) texts, I'd appreciate comment (especially from co-author) on prefer= ence to recommend as correction (including possibly for version I dislike).=

=C2=A0

NEW (1):

=C2=A0

=C2=A0=C2=A0 If the router changes its ori= ginator address, then:

=C2=A0

=C2=A0=C2=A0 1.=C2=A0=C2=A0If there is an = Originator Tuple with:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr =3D old originator address<= u class=3D"gmail_msg">

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then = modify it as follows:=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr :=3D new originator address=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_time :=3D current time + O_HOLD_TIME<= u class=3D"gmail_msg">

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 other= wise create an Originator Tuple with:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr :=3D new originator address=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_time :=3D current time + O_HOLD_TIME<= u class=3D"gmail_msg">

=C2=A0

NEW (2):

=C2=A0

=C2=A0=C2=A0 If the router changes its ori= ginator address, then:

=C2=A0

=C2=A0=C2=A0 1.=C2=A0=C2=A0If there is an = Originator Tuple with:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr =3D old originator address<= u class=3D"gmail_msg">

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then = remove it.

=C2=A0

=C2=A0=C2=A0 2.=C2=A0=C2=A0Create an Origi= nator Tuple with:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr :=3D new originator address=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_time :=3D current time + O_HOLD_TIME<= u class=3D"gmail_msg">

=C2=A0

I think I prefer NEW (2).

=C2=A0

--

Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laborator= ies

__________________________________________= ________________________________

=C2=A0

T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0= E: chris.dearlove@baesystems.com

=C2=A0

BAE Systems Applied Intelligence, Chelmsfo= rd Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.

www.baesystems.com/ai

BAE Systems Applied Intelligence Limited

Registered in England & Wales No: 0133= 7451

Registered Office: Surrey Research Park, G= uildford, Surrey, GU2 7YP=

=C2=A0

-----Original Message-----

From: RFC Errata System [mailto:rf= c-editor@rfc-editor.org]

Sent: 01 December 2016 08:30

To: T.Clausen@computer.org; Dearl= ove, Christopher (UK); philippe.jacquet@alcatel-lucent.com; ulrich@herberg.name; akatlas@gmail.com; db3546@att.com; aretana@cisco.com; sratliff@idirect.net; bebemaster@gmail.com

Cc: nmalykh@gmail.com; man= et@ietf.org; rfc-editor@rfc-editor.org

Subject: [Technical Errata Reported] RFC71= 81 (4874)

=C2=A0

----------------------! WARNING ! --------= -------------- This message originates from outside our organisation, eithe= r from an external partner or from the internet.=

Consider carefully whether you should clic= k on any links, open any attachments or reply.

Follow the 'Report Suspicious Emails&#= 39; link on IT matters for instructions on reporting suspicious email messa= ges.

------------------------------------------= --------------

=C2=A0

The following errata report has been submi= tted for RFC7181, "The Optimized Link State Routing Protocol Version 2= ".

=C2=A0

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

You may review the report below and at:

http://www.rfc-editor.org/errata_search.php?rfc=3D7181&eid=3D4874

=C2=A0

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

Type: Technical=

Reported by: Nikolai Malykh <nmalykh@gm= ail.com>

=C2=A0

Section: 17.1

=C2=A0

Original Text

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

=C2=A0=C2=A0 If the router changes its ori= ginator address, then:

=C2=A0

=C2=A0=C2=A0 1.=C2=A0=C2=A0If there is no = Originator Tuple with:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr =3D old originator address<= u class=3D"gmail_msg">

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then = create an Originator Tuple with:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr :=3D old originator address=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The O= riginator Tuple (existing or new) with:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr =3D new originator address<= u class=3D"gmail_msg">

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is th= en modified as follows:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_time :=3D current time + O_HOLD_TIME<= u class=3D"gmail_msg">

=C2=A0

=C2=A0

Corrected Text<= u class=3D"gmail_msg">

--------------<= u class=3D"gmail_msg">

=C2=A0=C2=A0 If the router changes its ori= ginator address, then:

=C2=A0

=C2=A0=C2=A0 1.=C2=A0=C2=A0If there is no = Originator Tuple with:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr =3D old originator address<= u class=3D"gmail_msg">

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then = create an Originator Tuple with:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr :=3D old originator address=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The O= riginator Tuple (existing or new) with:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr =3D old originator address<= u class=3D"gmail_msg">

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is th= en modified as follows:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_orig_addr :=3D new originator address=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2= =A0=C2=A0O_time :=3D current time + O_HOLD_TIME<= u class=3D"gmail_msg">

=C2=A0

=C2=A0

Notes

-----

At the time of the modification Originator= Tuple with O_orig_addr =3D new originator address does not yet exist.

=C2=A0

Instructions:

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

This erratum is currently posted as "= Reported". If necessary, please use "Reply All" to discuss w= hether it should be verified or rejected. When a decision is reached, the v= erifying party can log in to change the status and edit the report, if necessary.

=C2=A0

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

RFC7181 (draft-ietf-manet-olsrv2-19)

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

Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : The Optimized Link State= Routing Protocol Version 2

Publication Date=C2=A0=C2=A0=C2=A0=C2=A0: = April 2014

Author(s)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 : T. Clausen, C. Dearlove, P. Jacquet, U. Herbe= rg

Category=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: PROPOSED STANDARD

Source=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Mobile Ad-hoc Networks

Area=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Routing

Stream=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: IETF

Verifying Party=C2=A0=C2=A0=C2=A0=C2=A0 : = IESG

=C2=A0

******************************************= **************************

This email and any attachments are confide= ntial to the intended=

recipient and may also be privileged. If y= ou are not the intended

recipient please delete it from your syste= m and notify the sender.<= /u>

You should not copy it or use it for any p= urpose nor disclose or

distribute its contents to any other perso= n.

******************************************= **************************

=C2=A0

=C2=A0

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