From nobody Tue Feb 4 07:31:34 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F2B12011F for ; Tue, 4 Feb 2020 07:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 KJb5K0a0YyVG for ; Tue, 4 Feb 2020 07:31:30 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651851200B2 for ; Tue, 4 Feb 2020 07:31:30 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 48BpZT27rZzBsWl; Tue, 4 Feb 2020 16:31:29 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 48BpZT163rzCqwW; Tue, 4 Feb 2020 16:31:29 +0100 (CET) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([fe80::2c53:f99a:e2a9:19c6%21]) with mapi id 14.03.0468.000; Tue, 4 Feb 2020 16:31:29 +0100 From: To: "abdussalambaryun@gmail.com" CC: Routing Over Low power and Lossy networks Thread-Topic: [Roll] FW: New Version Notification for draft-ietf-roll-dis-modifications-01.txt Thread-Index: AQHV23ArjbD0HNlh60KdrwmeISxTnw== Date: Tue, 4 Feb 2020 15:31:28 +0000 Message-ID: <21408_1580830289_5E398E51_21408_27_3_DA5F4B97.6FD52%dominique.barthel@orange.com> References: <157432667505.28806.8545289298360479311.idtracker@ietfa.amsl.com> <4781_1574326974_5DD652BE_4781_95_8_D9FC72FE.6C3EC%dominique.barthel@orange.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_DA5F4B976FD52dominiquebarthelorangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] FW: New Version Notification for draft-ietf-roll-dis-modifications-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:31:33 -0000 --_000_DA5F4B976FD52dominiquebarthelorangecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWJkdXNzYWxhbSwNCg0KU29ycnkgdG8gcmVzcG9uZCBzbyBsYXRlLCB5b3VyIG1haWwg YmVsb3cgYmVjYW1lIGhpZGRlbiB1bmRlciB0aGUgcGlsZS11cCBhZnRlciBJRVRGMTA2Lg0KWW91 J3JlIHJpZ2h0IHRoYXQgZHJhZnQtaWV0Zi1yb2xsLWRpcy1tb2RpZmljYXRpb25zLTAxLnR4dCBh ZGRzIG5ldyBiZWhhdmlvdXIgdG8gNjU1MCwgYW5kIHNvIGl0IGxvb2tzIHRoYXQgaXQgc2hvdWxk IHVwZGF0ZSA2NTUwLg0KSG93ZXZlciwgd2UgYWxyZWFkeSBrbmV3IHdlIHdhbnRlZCB0byBkbyBk aXMtbW9kaWZpY2F0aW9ucyBhdCB0aGUgdGltZSB3ZSB3cm90ZSA2NTUwLCB0aGVyZWZvcmUgd2Ug cHV0IGEgc2VudGVuY2UgaW4gdGhlcmUgInVubGVzcyBhIGZsYWcgbW9kaWZpZXMgdGhpcyBiZWhh dmlvdXIiLg0KSSB3b3VsZCB0aGVyZWZvcmUgdGhpbmsgdGhhdCwgZm9ybWFsbHksIDY1NTAgaXMg bm90IHVwZGF0ZWQgYnkgZGlzLW1vZGlmaWNhdGlvbnMuDQpJIHdpbGwgbmVlZCB0byBkb3VibGUg Y2hlY2sgd2l0aCBvdXIgQUQncyBvbiB0aGlzLCB0aG91Z2guDQpUaGFua3MgZm9yIHNwb3R0aW5n IHRoaXMgYW5kIGxldHRpbmcgdXMgbm93IQ0KQmVzdCByZWdhcmRzLA0KDQpEb21pbmlxdWUNCg0K RGUgOiBSb2xsIDxyb2xsLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJvbGwtYm91bmNlc0BpZXRm Lm9yZz4+IG9uIGJlaGFsZiBvZiBBYmR1c3NhbGFtIEJhcnl1biA8YWJkdXNzYWxhbWJhcnl1bkBn bWFpbC5jb208bWFpbHRvOmFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPj4NClLDqXBvbmRyZSDD oCA6ICJyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPiIgPHJvbGxAaWV0Zi5vcmc8 bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0KRGF0ZSA6IE1vbmRheSAyNSBOb3ZlbWJlciAyMDE5IDA3 OjQzDQrDgCA6ICJyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPiIgPHJvbGxAaWV0 Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0KT2JqZXQgOiBSZTogW1JvbGxdIEZXOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtcm9sbC1kaXMtbW9kaWZpY2F0aW9u cy0wMS50eHQNCg0KSGkNCg0KSSB0aGluayB0aGlzIGRyYWZ0IHNob3VsZCB1cGRhdGUgdGhlIFJG QzY1NTAgYnV0IHRoZSBkcmFmdCBkaWQgbm90IG1lbnRpb24gdXBkYXRpbmcsDQoNCkFCDQoNCk9u IFRodSwgTm92IDIxLCAyMDE5IGF0IDExOjAzIEFNIDxkb21pbmlxdWUuYmFydGhlbEBvcmFuZ2Uu Y29tPG1haWx0bzpkb21pbmlxdWUuYmFydGhlbEBvcmFuZ2UuY29tPj4gd3JvdGU6DQpIZWxsbyBh bGwsDQoNCkluIGxpZ2h0IG9mIHRoZSBjdXJyZW50IGRpc2N1c3Npb25zIG9uIGFkZGluZyBmbGFn cyBhbmQgZ2VuZXJhbGx5DQppbXByb3ZpbmcgdGhlIGJlaGF2aW9yIG9mIERJUyBtZXNzYWdlcywg SSd2ZSBqdXN0IHJlcHVibGlzaGVkIHRoZSBvbGQNCmRpcy1tb2RpZmljYXRpb25zIGRyYWZ0IHdp dGggSW5mb3JtYXRpb25hbCBzdGF0dXMuDQpUaGUgcHVycG9zZSBpcyB0byBwcm92aWRlIHRoZSBX RyB3aXRoIHRoZSB1c2UgY2FzZXMgdGhhdCB3ZXJlIGRlc2NyaWJlZCBpbg0KdGhhdCBkcmFmdC4N CkV4Y2VwdCBmb3IgdGhlIGlzc3VlIGRhdGUgYW5kIHZlcnNpb24sIHRoZSBkcmFmdCBpcyB1bmNo YW5nZWQgZnJvbSAtMDAuDQpCZXN0IHJlZ2FyZHMsDQoNCkRvbWluaXF1ZQ0KDQpMZSAyMS8xMS8x OSAxNjo1NywgwqsgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IMK7IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4+DQphIMOpY3JpdCA6DQoNCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtaWV0Zi1yb2xsLWRpcy1tb2RpZmljYXRpb25zLTAxLnR4dA0KPmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRG9taW5pcXVlIEJhcnRoZWwgYW5kIHBvc3RlZCB0byB0 aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+TmFtZTogICAgICAgICAgZHJhZnQtaWV0Zi1yb2xs LWRpcy1tb2RpZmljYXRpb25zDQo+UmV2aXNpb246ICAgICAgMDENCj5UaXRsZTogICAgICAgICBE SVMgTW9kaWZpY2F0aW9ucw0KPkRvY3VtZW50IGRhdGU6IDIwMTktMTEtMjENCj5Hcm91cDogICAg ICAgICByb2xsDQo+UGFnZXM6ICAgICAgICAgMTUNCj5VUkw6DQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcm9sbC1kaXMtbW9kaWZpY2F0aW9ucy0wMS4N Cj50eHQNCj5TdGF0dXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1yb2xsLWRpcy1tb2RpZmljYXRpb25zLw0KPkh0bWxpemVkOg0KPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMtMDENCj5IdG1s aXplZDoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYt cm9sbC1kaXMtbW9kaWZpY2F0aW9ucw0KPkRpZmY6DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtcm9sbC1kaXMtbW9kaWZpY2F0aW9ucy0wMQ0KPg0KPkFic3Ry YWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgYXVnbWVudHMgUkZDNjU1MCB3aXRoIERJUyBmbGFncyBh bmQgb3B0aW9ucyB0aGF0DQo+ICAgYWxsb3cgYSBSUEwgbm9kZSB0byBiZXR0ZXIgY29udHJvbCBo b3cgbmVpZ2hib3IgUlBMIHJvdXRlcnMgcmVzcG9uZA0KPiAgIHRvIGl0cyBzb2xpY2l0YXRpb24g Zm9yIERJT3MuDQo+DQo+DQo+DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGll dGYub3JnPG1haWx0bzpSb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9yb2xsDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_DA5F4B976FD52dominiquebarthelorangecom_ Content-Type: text/html; charset="utf-8" Content-ID: <27BE8A69075CE94688379B3EBF948386@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K SGVsbG8gQWJkdXNzYWxhbSw8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KU29ycnkgdG8gcmVzcG9u ZCBzbyBsYXRlLCB5b3VyIG1haWwgYmVsb3cgYmVjYW1lIGhpZGRlbiB1bmRlciB0aGUgcGlsZS11 cCBhZnRlciBJRVRGMTA2LjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KWW91 J3JlIHJpZ2h0IHRoYXQmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IGZv bnQtc2l6ZTogMTVweDsiPmRyYWZ0LWlldGYtcm9sbC1kaXMtbW9kaWZpY2F0aW9ucy0wMS50eHQg YWRkcyBuZXcgYmVoYXZpb3VyIHRvIDY1NTAsIGFuZCBzbyBpdCBsb29rcyB0aGF0IGl0IHNob3Vs ZCB1cGRhdGUgNjU1MC48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogMTVweDsiPkhv d2V2ZXIsIHdlIGFscmVhZHkga25ldyB3ZSB3YW50ZWQgdG8gZG8gZGlzLW1vZGlmaWNhdGlvbnMg YXQgdGhlIHRpbWUgd2Ugd3JvdGUgNjU1MCwgdGhlcmVmb3JlIHdlIHB1dCBhIHNlbnRlbmNlIGlu IHRoZXJlICZxdW90O3VubGVzcyBhIGZsYWcgbW9kaWZpZXMgdGhpcyBiZWhhdmlvdXImcXVvdDsu PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyI+STwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmk7 IGZvbnQtc2l6ZTogMTVweDsiPiZuYnNwO3dvdWxkIHRoZXJlZm9yZSB0aGluayB0aGF0LCBmb3Jt YWxseSwgNjU1MCBpcyBub3QgdXBkYXRlZCBieSZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxNXB4OyI+ZGlzLW1vZGlmaWNhdGlvbnMuPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyI+SSB3aWxsIG5lZWQgdG8gZG91YmxlIGNoZWNrIHdp dGggb3VyIEFEJ3Mgb24gdGhpcywgdGhvdWdoLjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTVweDsiPlRoYW5rcyBmb3Igc3BvdHRpbmcgdGhpcyBhbmQgbGV0dGlu ZyB1cyBub3chPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4 OyI+QmVzdCByZWdhcmRzLDwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTVweDsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTVweDsiPkRvbWluaXF1ZTwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9u dC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAw aW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNi NWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDog M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EZSZuYnNwOzogPC9zcGFuPlJv bGwgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmciPnJvbGwtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBBYmR1c3NhbGFtIEJhcnl1biAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tIj5hYmR1c3NhbGFtYmFyeXVu QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlLD qXBvbmRyZSDDoCZuYnNwOzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYu b3JnIj5yb2xsQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0 Zi5vcmciPnJvbGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5EYXRlJm5ic3A7OiA8L3NwYW4+TW9uZGF5IDI1IE5vdmVtYmVyIDIwMTkgMDc6NDM8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+w4AmbmJzcDs6IDwvc3Bhbj4mcXVv dDs8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T2JqZXQmbmJzcDs6IDwvc3Bhbj5S ZTogW1JvbGxdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtcm9s bC1kaXMtbW9kaWZpY2F0aW9ucy0wMS50eHQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5IaTwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+SSB0aGluayB0aGlzIGRyYWZ0Jm5ic3A7c2hvdWxkIHVwZGF0ZSB0aGUg UkZDNjU1MCBidXQgdGhlIGRyYWZ0IGRpZCBub3QgbWVudGlvbiB1cGRhdGluZyw8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFCPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2F0dHIiIGRpcj0ibHRyIj5P biBUaHUsIE5vdiAyMSwgMjAxOSBhdCAxMTowMyBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRvbWlu aXF1ZS5iYXJ0aGVsQG9yYW5nZS5jb20iPmRvbWluaXF1ZS5iYXJ0aGVsQG9yYW5nZS5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtwYWRkaW5nLWxlZnQ6MWV4O2JvcmRlci1s ZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRlci1s ZWZ0LXN0eWxlOnNvbGlkIj4NCkhlbGxvIGFsbCw8YnI+DQo8YnI+DQpJbiBsaWdodCBvZiB0aGUg Y3VycmVudCBkaXNjdXNzaW9ucyBvbiBhZGRpbmcgZmxhZ3MgYW5kIGdlbmVyYWxseTxicj4NCmlt cHJvdmluZyB0aGUgYmVoYXZpb3Igb2YgRElTIG1lc3NhZ2VzLCBJJ3ZlIGp1c3QgcmVwdWJsaXNo ZWQgdGhlIG9sZDxicj4NCmRpcy1tb2RpZmljYXRpb25zIGRyYWZ0IHdpdGggSW5mb3JtYXRpb25h bCBzdGF0dXMuPGJyPg0KVGhlIHB1cnBvc2UgaXMgdG8gcHJvdmlkZSB0aGUgV0cgd2l0aCB0aGUg dXNlIGNhc2VzIHRoYXQgd2VyZSBkZXNjcmliZWQgaW48YnI+DQp0aGF0IGRyYWZ0Ljxicj4NCkV4 Y2VwdCBmb3IgdGhlIGlzc3VlIGRhdGUgYW5kIHZlcnNpb24sIHRoZSBkcmFmdCBpcyB1bmNoYW5n ZWQgZnJvbSAtMDAuPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCjxicj4NCkRvbWluaXF1ZTxicj4N Cjxicj4NCkxlIDIxLzExLzE5IDE2OjU3LCDCqyA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9h PiDCuyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KYSDDqWNyaXQg Ojxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWll dGYtcm9sbC1kaXMtbW9kaWZpY2F0aW9ucy0wMS50eHQ8YnI+DQomZ3Q7aGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBEb21pbmlxdWUgQmFydGhlbCBhbmQgcG9zdGVkIHRvIHRoZTxi cj4NCiZndDtJRVRGIHJlcG9zaXRvcnkuPGJyPg0KJmd0Ozxicj4NCiZndDtOYW1lOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZHJhZnQtaWV0Zi1yb2xsLWRpcy1tb2RpZmljYXRp b25zPGJyPg0KJmd0O1JldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7IDAxPGJyPg0KJmd0O1Rp dGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtESVMgTW9kaWZpY2F0aW9uczxi cj4NCiZndDtEb2N1bWVudCBkYXRlOiAyMDE5LTExLTIxPGJyPg0KJmd0O0dyb3VwOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyb2xsPGJyPg0KJmd0O1BhZ2VzOiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxNTxicj4NCiZndDtVUkw6Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMt MDEiIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPmh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMtMDE8L2E+ Ljxicj4NCiZndDt0eHQ8YnI+DQomZ3Q7U3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1yb2xsLWRpcy1tb2RpZmljYXRpb25zLyIgdGFyZ2V0PSJfYmxhbmsiIHJl bD0ibm9yZWZlcnJlciI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1yb2xsLWRpcy1tb2RpZmljYXRpb25zLzwvYT48YnI+DQomZ3Q7SHRtbGl6ZWQ6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMtMDEiIHRhcmdldD0iX2Js YW5rIiByZWw9Im5vcmVmZXJyZXIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMtMDE8L2E+PGJyPg0KJmd0O0h0bWxpemVkOiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtcm9sbC1kaXMtbW9kaWZpY2F0aW9ucyIg dGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnM8L2E+PGJyPg0K Jmd0O0RpZmY6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQom Z3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt cm9sbC1kaXMtbW9kaWZpY2F0aW9ucy0wMSIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJl ciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcm9sbC1kaXMt bW9kaWZpY2F0aW9ucy0wMTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0O0Fic3RyYWN0Ojxicj4NCiZn dDsmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBhdWdtZW50cyBSRkM2NTUwIHdpdGggRElTIGZs YWdzIGFuZCBvcHRpb25zIHRoYXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2FsbG93IGEgUlBMIG5v ZGUgdG8gYmV0dGVyIGNvbnRyb2wgaG93IG5laWdoYm9yIFJQTCByb3V0ZXJzIHJlc3BvbmQ8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwO3RvIGl0cyBzb2xpY2l0YXRpb24gZm9yIERJT3MuPGJyPg0KJmd0 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O1BsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mPGJyPg0KJmd0O3N1Ym1pc3Npb248 YnI+DQomZ3Q7dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiByZWw9 Im5vcmVmZXJyZXIiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCiZndDs8YnI+DQomZ3Q7VGhl IElFVEYgU2VjcmV0YXJpYXQ8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Cjxicj4NCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYzxicj4NCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyPGJyPg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8YnI+DQpPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuPGJyPg0KPGJyPg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+DQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48YnI+DQpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPGJyPg0KVGhhbmsg eW91Ljxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KUm9sbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Um9sbEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlJvbGxAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIiB0YXJnZXQ9Il9ibGFu ayIgcmVsPSJub3JlZmVycmVyIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JvbGw8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9z cGFuPg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_DA5F4B976FD52dominiquebarthelorangecom_-- From nobody Fri Feb 7 02:58:14 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3984120858 for ; Fri, 7 Feb 2020 02:58: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com header.b=pTH4y43C; dkim=pass (2048-bit key) header.d=ariskou.com header.b=hkiXi9+d Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7O81o4Xzksw for ; Fri, 7 Feb 2020 02:58:08 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262C7120241 for ; Fri, 7 Feb 2020 02:58:07 -0800 (PST) Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 9297C99 for ; Fri, 7 Feb 2020 11:58:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1581073085; bh=KaTie9uJZUpHQ29Ci2oiDvX8cQoUA/+qXjxZjUKN4NM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=pTH4y43CsQWFTYAJETlUcUuFBO7Fpf8ERcML7hcuwY9+RrHphcBpdiODKyFFdb1rS mtoWhdlna3tkNHKzSUy2XrOhYBVKxm5mmZuG7H095EU6QgGmELsoeyStKuh0dVGq7k in6eww9FLz4e8mtYa76/KPqF4Cmg7k3/XHjtZHsIx9Lub6RHws278r7++YXeezf8uM BrBnlnp3ZDUvAyvsciK9unBAphosbzSUS8QULCONP48gTsBNEOIV4fNWDcMw0tG6eE iv+XwXfVBQ06x7I3F28mXj63NpSHH17adugTbUUD9tQuOMnaEGipjiAgr+Bk2GX3b9 SwhGmKg8hHI+A== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1581073085; s=20191001-wvim; d=ariskou.com; i=aris@ariskou.com; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Content-Type; l=21822; bh=KaTie9uJZUpHQ29Ci2oiDvX8cQoUA/+qXjxZjUKN4NM=; b=hkiXi9+dFDbrem1jRIwFXo3mmsrmqBVqrDK2BwyHu/MSoFqvZYtniQa8N+bXMXwT EBTj46M94R0oi8RX7Q4wIg50arUOwAXRZx7zftv+7B8vGd5/8zMY1NAjrwFhoL5G3cy vCI8hYMbgPUxgzP5cilglY5LM4BcSHouIasDl9ixM4Ut2oJZ+TvpsEDBOz2gpWvtO1Z yXS3U88ByqeGnfFDklM7gXOAryhmEyn7JoLZAOMFovYzDLP77T/mUqUbrew9Vrb6XIJ ny/D43EYtFQjzSYgBFkcMKtszvyvggOtRsD0TgBTGyraMnag2RSEtwziP1nylzsSYVT vGU9VaqDBw== Received: by smtp.mailfence.com with ESMTPA for ; Fri, 7 Feb 2020 11:57:59 +0100 (CET) Received: by mail-il1-f179.google.com with SMTP id f5so1333203ilq.5 for ; Fri, 07 Feb 2020 02:57:58 -0800 (PST) X-Gm-Message-State: APjAAAU5gOuKphV5VKqfqAqeuEFcAsbop8VaZu8XE+GvjVyl1M2MPbhk tZpqiMguIrK/TNsVSz9Zt18I2SjcavfhyBU1dZ0= X-Google-Smtp-Source: APXvYqw5BpcxV+cjK3qRZVdAELCoEpxNTxTiiibd7AKqDcd0aYTPfdG9sE1nH+4YNVXJ9brMimi/vgDQfvysa+5TafQ= X-Received: by 2002:a92:77ca:: with SMTP id s193mr9033894ilc.42.1581073077401; Fri, 07 Feb 2020 02:57:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Remous-Aris Koutsiamanis Date: Fri, 7 Feb 2020 11:58:01 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: Routing Over Low power and Lossy networks Cc: rahul.ietf@gmail.com, "Georgios Z. Papadopoulos" Content-Type: multipart/alternative; boundary="000000000000247f24059dfa43e9" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] nsa extension comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 10:58:13 -0000 --000000000000247f24059dfa43e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Rahul, again, thanks a lot for the comments and sorry about the delay in addressing these. We have now gone through the comments and we respond inline. On Sat, Dec 7, 2019 at 9:06 AM Rahul Jadhav wrote: > Hello authors, > > I have pushed my PR[1] to the corresponding roll-wg repo. > Thank you so much for the P=CE=A1. We have merged it and have made a few mi= nor typo corrections on top. However, there are other > points which require your attention. Following are my comments: > > o Carrying TLVs in NSA > RFC 6551 explains that an NSA can be used to carry TLVs but it falls shor= t > of > specifying the format for these TLVs. This document assumes the format of > 8-bit > type and 8-bit length. This format is fine but future specifications will > have > to refer to this document if they got to add new TLVs. Thus the generic T= LV > format should be made part of different section and an IANA registry need= s > to > be created for the NSA TLV type. > I'm not sure I fully understood correctly. In RFC6551, page 24, Section "6.2. Routing Metric/Constraint TLVs" it says= : """IANA has created a sub-registry, called "Routing Metric/Constraint TLVs", used for all TLVs carried within Routing Metric/Constraint objects. The Type field is an 8-bit field whose value is comprised between 0 and 255. Value 0 is unassigned. The Length field is an 8-bit field whose value ranges from 0 to 255. The Value field has value ranges depending on the Type; therefore, they are not defined here, since no Type is registered at this time.""" So yes, there is no NSA-specific TLV structure, it is common registry for all the routing metrics and constraints, including the NSA. See https://www.iana.org/assignments/rpl-routing-metric-constraint/rpl-routing-= metric-constraint.xhtml#rmc-tlv As I understand it, RFC6551 contains the reference definition of the TLV strucure (8bit Type, 8bit Length, variable length Value field) and in our draft we basically ask for the creation of a new entry in this sub-registry and specify/define the structure of the Value field only (since the T & V are fixed already). Is this maybe not sufficient? > > o Preference in PS set > The document assumes that the parent addresses in the PS set have been > added in > the decreasing order of preference, without making it explicit. The PS IP= v6 > address(es) field requires an explanation in Section 4. > Thank you very much, we have amended that part of the draft accordingly. Please see if it is clear now (master branch in https://github.com/roll-wg/draft-ietf-roll-nsa-extension). > o DIO length > As per the draft, the DIO needs to carry NSA (Node State and Attributes) > metric > with PS (parent set) TLV. As per my understanding without compression, it > would > be a challenge to carry even two parent addresses in the PS. There has > been a > discussion about compression and as I remember we discussed doing it. > Regardless, I feel we should do it if we want this to be a practical > proposition. > Thank you for this comment. We agree that given the size of the IPv6 addresses, it would be prohibitive to include more than 2 addresses. When we initially pointed out this constraint ourselved, Michael pointed us in the direction of 6LoRH. We implemented a 6LoRH-style compression for this field and it worked well. However, it was becoming complicated, somewhat out-of-scope and since there was no good place to point at for our 6LoRH-style compression (a potentially blocking issue), we discussed the options with the group (see an email thread with subject "[Roll] I-D Action: draft-ietf-roll-nsa-extension-02.txt" June 24 2019 - July 2 2019). With input from Pascal and Dominique we decided to completely drop compression, in favour of a potential separate and more general compression draft for all control packets. We would actually like to contribute to that, but for the time being, a specific compression method for the PS field has been taken out of this draft. > > o Section 3.4 Usage: > "For example, using different methods can be used to vary the transmissio= n > reliability in each hop." > This statement implies that using different CA policy implementation can > "control" the transmission reliability. As I understand, the strict polic= y > is > the best policy (in terms of all performance metrics), the nodes will go > for > other policy only when the strict policy cannot be used given their paren= t > sets. > The above statement implies that nodes may still go for a relaxed policy > when > strict can be used. > Thanks for catching this, but in this case this is intentional. As far as we are concerned a) there is no "best" policy, and b) a new policy might be introduced in the future. The important aspect is that the choice of policy is a local (node) decision and different nodes can select different policies based on whichever criteria make sense for them. For example, depending on the required performance in jitter/delay/reliability that is desired a different policy might be used. An administrator might also configure nodes in a specific way. In any case, we do not want to reduce flexibility in this aspect by defining a spcific hierarchy/preference order on the policies. Maybe it makes sense to clarify this a bit? > > o Configuration parameters > The document specifies configuration parameters such as > a. PARENT_SET_SIZE ... Not defined > Thanks, we hadn't clarified that this is the same as the MRHOF PARENT_SET_SIZE variable. Updated in master. > b. cur_ap_min_path_cost: How can the cur_ap_min_path_cost be equated with > PARENT_SWITCH_THRESHOLD as mentioned in section 3.2.2 > Thank you but we are not very sure we understant the question. This section basically says that in addition to the normal MRHOF cur_min_path_cost variable, we add the cur_ap_min_path_cost variable which contains the the path cost of the current AP. We use the same threshold PARENT_SWITCH_THRESHOLD that MRHOF uses to decide if we need to change AP. Just to be sure, we have now clarified here that PARENT_SWITCH_THRESHOLD is the same value that MRHOF uses. Updated in master. > c. MAX_PATH_COST: No definition for this. > Again, thanks, we hadn't clarified that this comes from MRHOF. We added a clarification and updated in master. > The parameters warrant a rationale and a default value. Also more > importantly, > is it required that different nodes use the same value and if not what > could be > the impact. > The values used and their semantics should now be clear, basically in this section we either reuse existing MRHOF variables with the same MRHOF semantics, or we introduce new variables which have corresponding ones in MRHOF and similar semantics. Please let us know if you think we should define something in more detail, but we would like to avoid too much duplication from MRHOF, if possible. > > o Terminology section > Terminology section should explain Alternative Parent, Parent Set, > Preferred > Grand Parent. > Thank you very much, this is a good idea. We have amended the text with this and updated in master. > > o Section realignment > It is better to explain CA Strict/Medium/Relax policies before explaining > the > CAOF because as a reader one needs to be familiar with these policies > before > understanding the OF. > Thank you for this comment. We had a similar concern as well. We are not sure what is best. As the text is current structured, we introduce the CAOF first, mentioning that different policies are possible and that a selection from the parent set must be made. We then describe the CAOF in terms of differences from/additions to MRHOF. And finally we describe the policies. To my mind, the policies are concrete, but they are also just examples, so someone can devise different ones. In that sense the CAOF is more "fixed" and the policies are more flexible. Thus it makes sense to describe the CAOF first. We are very open to changing the order, but we would like to have some additional feedback that the order is problematic as it stands now. We would like to hear any suggestions from the group on this topic. > Regards, > Rahul > > [1] https://github.com/roll-wg/draft-ietf-roll-nsa-extension/pull/1 > > Thank you very very much for the feedback and the thorough work Rahul. It is very much appreciated! Best, Aris & Georgios --000000000000247f24059dfa43e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Rahul,

again, thanks a= lot for the comments and sorry about the delay in addressing these.
<= div>We have now gone through the comments and we respond inline.
<= div>
On Sat, Dec 7, 2019 at 9:06 AM Rahul Jadhav &= lt;rahul.ietf@gma= il.com> wrote:
Hello authors,

I have pushed my PR[1] to the = corresponding roll-wg repo.=C2=A0

=
Thank you so much for the P=CE=A1. We have merged it and have made a f= ew minor typo corrections on top.

<= /div>
How= ever, there are other
points which require your attention. Following are= my comments:

o Carrying TLVs in NSA
RFC 6551 explains that an NS= A can be used to carry TLVs but it falls short of
specifying the format = for these TLVs. This document assumes the format of 8-bit
type and 8-bit= length. This format is fine but future specifications will have
to refe= r to this document if they got to add new TLVs. Thus the generic TLV
for= mat should be made part of different section and an IANA registry needs to<= br>be created for the NSA TLV type.

I'm not sure I fully understood correctly.
In RFC6551, pag= e 24, Section "6.2.=C2=A0 Routing Metric/Constraint TLVs" it says= :
"""IANA has created a sub-registry, called "Routin= g Metric/Constraint
=C2=A0 =C2=A0TLVs", used for all TLVs carried w= ithin Routing Metric/Constraint
=C2=A0 =C2=A0objects.=C2=A0 The Type fie= ld is an 8-bit field whose value is comprised
=C2=A0 =C2=A0between 0 and= 255.=C2=A0 Value 0 is unassigned.=C2=A0 The Length field is an
=C2=A0 = =C2=A08-bit field whose value ranges from 0 to 255.=C2=A0 The Value field h= as
=C2=A0 =C2=A0value ranges depending on the Type; therefore, they are = not defined
=C2=A0 =C2=A0here, since no Type is registered at this time.= """

So yes, there is no NSA-specific TLV structure, it is common registry for=20 all the routing metrics and constraints, including the NSA.
See https://www.iana.org= /assignments/rpl-routing-metric-constraint/rpl-routing-metric-constraint.xh= tml#rmc-tlv
As I understand it, RFC6551 contains the reference definition of the TLV=20 strucure (8bit Type, 8bit Length, variable length Value field)
and in our draft we basically ask for the creation of a new entry in this=20 sub-registry and specify/define the structure of the Value field only
(s= ince the T & V are fixed already).
Is this maybe not sufficient?
=C2=A0

o Preference in PS set
The docum= ent assumes that the parent addresses in the PS set have been added in
t= he decreasing order of preference, without making it explicit. The PS IPv6<= br>address(es) field requires an explanation in Section 4.

Thank you very much, we have amended that = part of the draft accordingly. Please see if it is clear now (master branch= in https://github.com/roll-wg/draft-ietf-roll-nsa-extension).



o DIO lengthAs per the draft, the DIO needs to carry NSA (Node State and Attributes) = metric
with PS (parent set) TLV. As per my understanding without compre= ssion, it would
be a challenge to carry even two parent addresses in the= PS. There has been a
discussion about compression and as I remember we = discussed doing it.
Regardless, I feel we should do it if we want this t= o be a practical
proposition.

Thank you for this comment.
We agree that given the si= ze of the IPv6 addresses, it would be prohibitive to include more than 2 ad= dresses.
When we initially pointed out this constraint ourselved, Michae= l pointed us in the direction of 6LoRH.
We implemented a 6LoRH-style com= pression for this field and it worked well.
However, it was becoming complicated, somewhat out-of-scope and since there was=20 no good place to point at for our 6LoRH-style compression (a potentially blocking issue), we discussed the options with the group (see an email=20 thread with subject "[Roll] I-D Action: draft-ietf-roll-nsa-extension-= 02.txt" June 24 2019 - July 2 2019).
With input from Pascal and Dominique we decided to completely drop=20 compression, in favour of a potential separate and more general=20 compression draft for all control packets.
We would actually like to=20 contribute to that, but for the time being, a specific compression=20 method for the PS field has been taken out of this draft.
=C2=A0

o Section 3.4 Usage:
"For example, = using different methods can be used to vary the transmission
reliabilit= y in each hop."
This statement implies that using different CA poli= cy implementation can
"control" the transmission reliability.= As I understand, the strict policy is
the best policy (in terms of all = performance metrics), the nodes will go for
other policy only when the s= trict policy cannot be used given their parent sets.
The above statement= implies that nodes may still go for a relaxed policy when
strict can be= used.

Thanks for ca= tching this, but in this case this is intentional.
As far as we are conc= erned a) there is no "best" policy, and b) a new policy might be = introduced in the future.
The important aspect is that the choice of policy is a local (node)=20 decision and different nodes can select different policies based on=20 whichever criteria make sense for them.
For example, depending on the re= quired performance in jitter/delay/reliability that is desired a different = policy might be used.
An administrator might also configure nodes in a s= pecific way.
In any case, we do not want to reduce flexibility in this aspect by=20 defining a spcific hierarchy/preference order on the policies.
Maybe it = makes sense to clarify this a bit?
=C2= =A0

o Configuration parameters
The document specifies configuratio= n parameters such as
a. PARENT_SET_SIZE ... Not defined
<= /blockquote>

Thanks, we hadn't clarified that= this is the same as the MRHOF PARENT_SET_SIZE variable. Updated in master.=
=C2=A0
b. cur_ap_min_path_cost: H= ow can the cur_ap_min_path_cost be equated with
PARENT_SWITCH_THRESHOLD = as mentioned in section 3.2.2

Thank you but we are not very sure we understant the question. This section=20 basically says that in addition to the normal MRHOF cur_min_path_cost=20 variable, we add the cur_ap_min_path_cost variable which contains the=20 the path cost of the current AP.
We use the same threshold PARENT= _SWITCH_THRESHOLD that MRHOF uses to decide if we need to change AP.
Jus= t to be sure, we have now clarified here that PARENT_SWITCH_THRESHOLD is th= e same value that MRHOF uses. Updated in master.
=C2=A0
c. MAX_PATH_COST: No definition for this.

Again, thanks, we hadn't clari= fied that this comes from MRHOF. We added a clarification and updated in ma= ster.
=C2=A0
The parameters warrant a = rationale and a default value. Also more importantly,
is it required tha= t different nodes use the same value and if not what could be
the impact= .

The values used and their semantics should now be clear, basically in this=20 section we either reuse existing MRHOF variables with the same MRHOF=20 semantics, or we introduce new variables which have corresponding ones=20 in MRHOF and similar semantics.
Please let us know if you think we=20 should define something in more detail, but we would like to avoid too=20 much duplication from MRHOF, if possible.
=C2=A0

o Terminology section
Terminology section should expl= ain Alternative Parent, Parent Set, Preferred
Grand Parent.

Thank you very much, this is a g= ood idea. We have amended the text with this and updated in master.
=C2=A0

o Section realignment
It is= better to explain CA Strict/Medium/Relax policies before explaining theCAOF because as a reader one needs to be familiar with these policies befo= re
understanding the OF.

Thank you for this comment. We had a similar concern as well.
We= are not sure what is best.
As the text is current structured, we introduce the CAOF first, mentioning that different policies are possible and that a selection from the=20 parent set must be made.
We then describe the CAOF in terms of differenc= es from/additions to MRHOF.
And finally we describe the policies.
To my mind, the policies are concrete, but they are also just examp= les, so someone can devise different ones.
In that sense the CAOF is mor= e "fixed" and the policies are more flexible. Thus it makes sense= to describe the CAOF first.

We are very open to changing the order, but we would like to have some=20 additional feedback that the order is problematic as it stands now.
We w= ould like to hear any suggestions from the group on this topic.
=C2=A0
Regards,
Rahul


<= /div>
Thank you very very much for the feedback and the tho= rough work Rahul. It is very much appreciated!

Bes= t,
Aris & Georgios
--000000000000247f24059dfa43e9-- From nobody Mon Feb 10 08:04:26 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AEC12009E for ; Mon, 10 Feb 2020 00:33:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rkvRwqV1EN0H for ; Mon, 10 Feb 2020 00:33:00 -0800 (PST) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 DB71D12008C for ; Mon, 10 Feb 2020 00:32:59 -0800 (PST) Received: by mail-lf1-x144.google.com with SMTP id r14so3544167lfm.5 for ; Mon, 10 Feb 2020 00:32:59 -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:content-transfer-encoding; bh=AdlAGt2zqJYAPDVE090qJDHDYKcw153/yd8gBixCJCc=; b=UPRJcJ1XTY7UhQ+jkGZRWiJ7ub5mKs7Dz7kGDnifXGDMZSllQzPvFJPPQQJlPGOx18 jsJ8zKJwihBAl3m9p3EFgZaq8yLXv5pljya6xfb6SQmQmhkitfp1t87pCZjGxocPwsi3 HuivaxgPsuc9aZ02sRr9ufxi4Q8hkijvafMShYoDsUim1d3h/Twx+froQRBkty0oHdbs OELJyc7i6+bSLgmAAkZGURG9KV6CKT/sKRTeU9XwMtkUohY+kqFNEo3BiBKL8/Genvmo wmF8xnV88hy7D9xtSgORXGZc+nvWkqcst1/3OVMrpAOC0Pj0qeGPBviuTyY++Mo/EGr0 jZZQ== 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:content-transfer-encoding; bh=AdlAGt2zqJYAPDVE090qJDHDYKcw153/yd8gBixCJCc=; b=acBAYjEgAP1lZasV16fVzU93Bryfsy8Zw/IoVxQwXKu4qxBtQIEaoa46uj9FYsYHhr YkB0WqW3r4la2qZdl/hsTrtSJ3OnclErqN95GGDaTzXLgI1QCp6I3JVbNRR6lI3QdxG9 eIouyyz7lbnlPyrvRYFufKiaQHHUe2ORh+EDKVJAIxgAHepcuna7NZmxqdfShTEZVyb8 ktNiXD1c7h7LGyRoh/D0IGNx9uqGOYo84oHgxIWxniRojAbAjqdlE0tBRRaCuGgJhD9L zbVu7UnyfR9KzqhenhXeMRdTdP43rvtthqlKF9AoGVUwY3hSbrm95/t+JlvI8racnB3I 2WDQ== X-Gm-Message-State: APjAAAUt5wC8f8Y7fu7eBOK8vsrBY9XvJsgMG6SsUX1sAwUJXWVN1PrD IabEYAqXiY/eZlAKfX8Y6AK+ql43KDFFyskCUb4= X-Google-Smtp-Source: APXvYqw1Z8mbj18wtOCfQAGbifQrlZ17X9XyEfRHtifYeXk4KwQ4UIrd7j+021FxMengq7IxOrTjIrH2gfqHe1qjdLY= X-Received: by 2002:a19:a07:: with SMTP id 7mr175267lfk.66.1581323577953; Mon, 10 Feb 2020 00:32:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rahul Jadhav Date: Mon, 10 Feb 2020 14:02:46 +0530 Message-ID: To: Remous-Aris Koutsiamanis Cc: Routing Over Low power and Lossy networks , "Georgios Z. Papadopoulos" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] nsa extension comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 08:33:02 -0000 Thanks Aris, Georgios for clarifications. Please find my responses inline. >> >> o Carrying TLVs in NSA >> RFC 6551 explains that an NSA can be used to carry TLVs but it falls sho= rt of >> specifying the format for these TLVs. This document assumes the format o= f 8-bit >> type and 8-bit length. This format is fine but future specifications wil= l have >> to refer to this document if they got to add new TLVs. Thus the generic = TLV >> format should be made part of different section and an IANA registry nee= ds to >> be created for the NSA TLV type. > > > I'm not sure I fully understood correctly. > In RFC6551, page 24, Section "6.2. Routing Metric/Constraint TLVs" it sa= ys: > """IANA has created a sub-registry, called "Routing Metric/Constraint > TLVs", used for all TLVs carried within Routing Metric/Constraint > objects. The Type field is an 8-bit field whose value is comprised > between 0 and 255. Value 0 is unassigned. The Length field is an > 8-bit field whose value ranges from 0 to 255. The Value field has > value ranges depending on the Type; therefore, they are not defined > here, since no Type is registered at this time.""" [RJ]: The reason why I was confused is that the "Optional TLVs" are mentioned in NSA section but there is no reference for the TLV format. I now realized that section 2.1 has a para that explains the TLV format which is applicable to all the optional TLVs in 6551. I stand corrected. Thank you. > > So yes, there is no NSA-specific TLV structure, it is common registry for= all the routing metrics and constraints, including the NSA. > See https://www.iana.org/assignments/rpl-routing-metric-constraint/rpl-ro= uting-metric-constraint.xhtml#rmc-tlv > As I understand it, RFC6551 contains the reference definition of the TLV = strucure (8bit Type, 8bit Length, variable length Value field) > and in our draft we basically ask for the creation of a new entry in this= sub-registry and specify/define the structure of the Value field only > (since the T & V are fixed already). > Is this maybe not sufficient? [RJ] This is sufficient, imo. Thanks > >> >> >> o Preference in PS set >> The document assumes that the parent addresses in the PS set have been a= dded in >> the decreasing order of preference, without making it explicit. The PS I= Pv6 >> address(es) field requires an explanation in Section 4. > > > Thank you very much, we have amended that part of the draft accordingly. = Please see if it is clear now (master branch in https://github.com/roll-wg/= draft-ietf-roll-nsa-extension). [RJ] I checked the PR. All ok except one question in the new changes, "The number of p, wearent addresses in the PS IPv6" .... What is "wearent"? > > >> >> o DIO length >> As per the draft, the DIO needs to carry NSA (Node State and Attributes)= metric >> with PS (parent set) TLV. As per my understanding without compression, i= t would >> be a challenge to carry even two parent addresses in the PS. There has b= een a >> discussion about compression and as I remember we discussed doing it. >> Regardless, I feel we should do it if we want this to be a practical >> proposition. > > > > Thank you for this comment. > We agree that given the size of the IPv6 addresses, it would be prohibiti= ve to include more than 2 addresses. > When we initially pointed out this constraint ourselved, Michael pointed = us in the direction of 6LoRH. > We implemented a 6LoRH-style compression for this field and it worked wel= l. > However, it was becoming complicated, somewhat out-of-scope and since the= re was no good place to point at for our 6LoRH-style compression (a potenti= ally blocking issue), we discussed the options with the group (see an email= thread with subject "[Roll] I-D Action: draft-ietf-roll-nsa-extension-02.t= xt" June 24 2019 - July 2 2019). > With input from Pascal and Dominique we decided to completely drop compre= ssion, in favour of a potential separate and more general compression draft= for all control packets. > We would actually like to contribute to that, but for the time being, a s= pecific compression method for the PS field has been taken out of this draf= t. [RJ] Sure, my concern is that it may be infeasible to use this work without compression. I was hoping to use either 6lorh style or P2P-RPL/AODV-RPL style (used for address vector) compression. > >> >> >> o Section 3.4 Usage: >> "For example, using different methods can be used to vary the transmissi= on >> reliability in each hop." >> This statement implies that using different CA policy implementation can >> "control" the transmission reliability. As I understand, the strict poli= cy is >> the best policy (in terms of all performance metrics), the nodes will go= for >> other policy only when the strict policy cannot be used given their pare= nt sets. >> The above statement implies that nodes may still go for a relaxed policy= when >> strict can be used. > > > Thanks for catching this, but in this case this is intentional. > As far as we are concerned a) there is no "best" policy, and b) a new pol= icy might be introduced in the future. > The important aspect is that the choice of policy is a local (node) decis= ion and different nodes can select different policies based on whichever cr= iteria make sense for them. > For example, depending on the required performance in jitter/delay/reliab= ility that is desired a different policy might be used. > An administrator might also configure nodes in a specific way. > In any case, we do not want to reduce flexibility in this aspect by defin= ing a spcific hierarchy/preference order on the policies. > Maybe it makes sense to clarify this a bit? [RJ] It would certainly help to clarify the bit. One question, is there any reason/use-case why any node will not go for strict policy? Why would administrator configure anything other than strict policy? In the above response, it is suggested that to control jitter/delay/reliability. But the strict policy is best for any use-case and for any metric or any group of metrics, isn't it? > >> >> >> o Configuration parameters >> The document specifies configuration parameters such as >> a. PARENT_SET_SIZE ... Not defined > > > Thanks, we hadn't clarified that this is the same as the MRHOF PARENT_SET= _SIZE variable. Updated in master. > >> >> b. cur_ap_min_path_cost: How can the cur_ap_min_path_cost be equated wit= h >> PARENT_SWITCH_THRESHOLD as mentioned in section 3.2.2 > > > Thank you but we are not very sure we understant the question. This secti= on basically says that in addition to the normal MRHOF cur_min_path_cost va= riable, we add the cur_ap_min_path_cost variable which contains the path co= st of the current AP. > We use the same threshold PARENT_SWITCH_THRESHOLD that MRHOF uses to deci= de if we need to change AP. > Just to be sure, we have now clarified here that PARENT_SWITCH_THRESHOLD = is the same value that MRHOF uses. Updated in master. [RJ] ok thanks. My confusion was that cur_ap_min_path_cost is the aggregated cost to that AP from the root. This cost is the link local cost of the node to that AP. Is this correct? > >> >> c. MAX_PATH_COST: No definition for this. > > > Again, thanks, we hadn't clarified that this comes from MRHOF. We added a= clarification and updated in master. > >> >> The parameters warrant a rationale and a default value. Also more import= antly, >> is it required that different nodes use the same value and if not what c= ould be >> the impact. > > > The values used and their semantics should now be clear, basically in thi= s section we either reuse existing MRHOF variables with the same MRHOF sema= ntics, or we introduce new variables which have corresponding ones in MRHOF= and similar semantics. > Please let us know if you think we should define something in more detail= , but we would like to avoid too much duplication from MRHOF, if possible. > >> >> >> o Terminology section >> Terminology section should explain Alternative Parent, Parent Set, Prefe= rred >> Grand Parent. > > > Thank you very much, this is a good idea. We have amended the text with t= his and updated in master. > >> >> >> o Section realignment >> It is better to explain CA Strict/Medium/Relax policies before explainin= g the >> CAOF because as a reader one needs to be familiar with these policies be= fore >> understanding the OF. > > > Thank you for this comment. We had a similar concern as well. > We are not sure what is best. > As the text is current structured, we introduce the CAOF first, mentionin= g that different policies are possible and that a selection from the parent= set must be made. > We then describe the CAOF in terms of differences from/additions to MRHOF= . > And finally we describe the policies. > To my mind, the policies are concrete, but they are also just examples, s= o someone can devise different ones. > In that sense the CAOF is more "fixed" and the policies are more flexible= . Thus it makes sense to describe the CAOF first. > > We are very open to changing the order, but we would like to have some ad= ditional feedback that the order is problematic as it stands now. > We would like to hear any suggestions from the group on this topic. [RJ] Ok, lets wait for feedback. I, for one, would like to see policies explained first and then an OF using them. I find this the only logical way. From nobody Mon Feb 10 08:08:17 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E41120227 for ; Mon, 10 Feb 2020 06:46:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com header.b=nQVVvjl+; dkim=pass (2048-bit key) header.d=ariskou.com header.b=nNqER23z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRJrQEbKNbX6 for ; Mon, 10 Feb 2020 06:46:19 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CFD12022C for ; Mon, 10 Feb 2020 06:46:19 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id B06F011CC for ; Mon, 10 Feb 2020 15:46:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1581345976; bh=RIKkm9yxQY3Ps0ksE0+edVSMTyfDb0VZUaK9lREJBZM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=nQVVvjl+QfdALuTh8gPq7Ixlka2xDR9BqBCNTKqDIt2T8cGsypO7/SCtCLI6jfsYk qcNuANfs81IzqHTkmuf0y3pglu8s7DHZw2E3IBAM1106WGWsEJBYIsKPlDhhIAiDRQ FUQhLO/cJM5NvNSqhYjGpvjFlZQTSj++x45luoY/EWJLcaJ5MXGyBOC82K1QTNmf1e 4xtXQomLhQZbeXdXsdwgx13kPZBp8te6S377iCUPQn4Vhg8NXoR1zEf+3Vy8lH9RyI oYLbWyGjKLqEu5fVDppZcDYAa+O9XAMUGMdPYfDJB+pyJWSz+BhSXpR5OX6P4c++u8 XwfoJ+Dicv62A== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1581345976; s=20191001-wvim; d=ariskou.com; i=aris@ariskou.com; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Content-Type; l=28263; bh=RIKkm9yxQY3Ps0ksE0+edVSMTyfDb0VZUaK9lREJBZM=; b=nNqER23zdsw2T2j1Q7AhIEaaoHhL2vVWk6QzHpEG1E4TzlaN2vUE0KaasuOLqsXm pXxLLAAaoaId+Md+YWI4lyi1EpkIHRolBBQsWIyJXNP9MlSER/nl696QzpOS0Q9x8WO vOGSjoRm5ZNpjBeJCqbXtpDb104E1w+MaWI1tYe15C1+JwI20eQCZ84tb5C9X6p9DQb og8kQVziHfaq3OU2UA6yGwboFDTnEDrMlon3xSwL/9xOd+4GkeLGX7MtylG3lVqK1uo OtEAL17IazS2qmSP7RSIWG2Px3iTtdfbm/3PmWzq10Hm7vsINd9KcBZqo8gIC5659hX O6r4AEXD3Q== Received: by smtp.mailfence.com with ESMTPA for ; Mon, 10 Feb 2020 15:46:04 +0100 (CET) Received: by mail-io1-f52.google.com with SMTP id z16so7791499iod.11 for ; Mon, 10 Feb 2020 06:46:03 -0800 (PST) X-Gm-Message-State: APjAAAViO16gbzTt0AFJS9WZJ4XZ/ZUCpFgcsE1hJnX4nuomm+3N/B9U HuY60tRJWXL8FB0h+fa60juPK404K3xtigLTGNE= X-Google-Smtp-Source: APXvYqyZdEgU6D+V0E8LUdiVtRP85RYs6TVlggENjsfnr5GRc6HxINCVK9TvdpzNuC5VVYykXm+SPgxlxIQFM1m28ys= X-Received: by 2002:a02:a694:: with SMTP id j20mr10573496jam.69.1581345962458; Mon, 10 Feb 2020 06:46:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Remous-Aris Koutsiamanis Date: Mon, 10 Feb 2020 15:46:07 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: Rahul Jadhav Cc: Routing Over Low power and Lossy networks , "Georgios Z. Papadopoulos" Content-Type: multipart/alternative; boundary="0000000000005c0890059e39cc9e" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] nsa extension comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 14:46:23 -0000 --0000000000005c0890059e39cc9e Content-Type: text/plain; charset="UTF-8" Hello Rahul, thanks for the follow up. I think we've resolved most issues. Responding inline. On Mon, Feb 10, 2020 at 9:33 AM Rahul Jadhav wrote: > Thanks Aris, Georgios for clarifications. Please find my responses inline. > > > >> > >> o Carrying TLVs in NSA > >> RFC 6551 explains that an NSA can be used to carry TLVs but it falls > short of > >> specifying the format for these TLVs. This document assumes the format > of 8-bit > >> type and 8-bit length. This format is fine but future specifications > will have > >> to refer to this document if they got to add new TLVs. Thus the generic > TLV > >> format should be made part of different section and an IANA registry > needs to > >> be created for the NSA TLV type. > > > > > > I'm not sure I fully understood correctly. > > In RFC6551, page 24, Section "6.2. Routing Metric/Constraint TLVs" it > says: > > """IANA has created a sub-registry, called "Routing Metric/Constraint > > TLVs", used for all TLVs carried within Routing Metric/Constraint > > objects. The Type field is an 8-bit field whose value is comprised > > between 0 and 255. Value 0 is unassigned. The Length field is an > > 8-bit field whose value ranges from 0 to 255. The Value field has > > value ranges depending on the Type; therefore, they are not defined > > here, since no Type is registered at this time.""" > > [RJ]: The reason why I was confused is that the "Optional TLVs" are > mentioned in NSA section but there is no reference for the TLV format. > I now realized that section 2.1 has a para that explains the TLV > format which is applicable to all the optional TLVs in 6551. I stand > corrected. Thank you. > Great. Thanks as well. > > > > > So yes, there is no NSA-specific TLV structure, it is common registry > for all the routing metrics and constraints, including the NSA. > > See > https://www.iana.org/assignments/rpl-routing-metric-constraint/rpl-routing-metric-constraint.xhtml#rmc-tlv > > As I understand it, RFC6551 contains the reference definition of the TLV > strucure (8bit Type, 8bit Length, variable length Value field) > > and in our draft we basically ask for the creation of a new entry in > this sub-registry and specify/define the structure of the Value field only > > (since the T & V are fixed already). > > Is this maybe not sufficient? > > [RJ] This is sufficient, imo. Thanks > Good we cleared that up. Thanks. > > > > >> > >> > >> o Preference in PS set > >> The document assumes that the parent addresses in the PS set have been > added in > >> the decreasing order of preference, without making it explicit. The PS > IPv6 > >> address(es) field requires an explanation in Section 4. > > > > > > Thank you very much, we have amended that part of the draft accordingly. > Please see if it is clear now (master branch in > https://github.com/roll-wg/draft-ietf-roll-nsa-extension). > > [RJ] I checked the PR. All ok except one question in the new changes, > "The number of p, wearent addresses in the PS IPv6" .... What is "wearent"? > Ah, unfortunately a typo. Fixed it in master, is should have read "The number of parent addresses in the PS IPv6 address(es) field" Thanks for the catch! > > > > > > >> > >> o DIO length > >> As per the draft, the DIO needs to carry NSA (Node State and > Attributes) metric > >> with PS (parent set) TLV. As per my understanding without compression, > it would > >> be a challenge to carry even two parent addresses in the PS. There has > been a > >> discussion about compression and as I remember we discussed doing it. > >> Regardless, I feel we should do it if we want this to be a practical > >> proposition. > > > > > > > > Thank you for this comment. > > We agree that given the size of the IPv6 addresses, it would be > prohibitive to include more than 2 addresses. > > When we initially pointed out this constraint ourselved, Michael pointed > us in the direction of 6LoRH. > > We implemented a 6LoRH-style compression for this field and it worked > well. > > However, it was becoming complicated, somewhat out-of-scope and since > there was no good place to point at for our 6LoRH-style compression (a > potentially blocking issue), we discussed the options with the group (see > an email thread with subject "[Roll] I-D Action: > draft-ietf-roll-nsa-extension-02.txt" June 24 2019 - July 2 2019). > > With input from Pascal and Dominique we decided to completely drop > compression, in favour of a potential separate and more general compression > draft for all control packets. > > We would actually like to contribute to that, but for the time being, a > specific compression method for the PS field has been taken out of this > draft. > > [RJ] Sure, my concern is that it may be infeasible to use this work > without compression. I was hoping to use either 6lorh style or > P2P-RPL/AODV-RPL style (used for address vector) compression. > I agree that compression is necessary but it looks like the consensus is to handle this in a more all-encompassing and separate compression draft. So from the feedback that we received from the WG so far, there doesn't seem that there is something to do here. > > > >> > >> > >> o Section 3.4 Usage: > >> "For example, using different methods can be used to vary the > transmission > >> reliability in each hop." > >> This statement implies that using different CA policy implementation can > >> "control" the transmission reliability. As I understand, the strict > policy is > >> the best policy (in terms of all performance metrics), the nodes will > go for > >> other policy only when the strict policy cannot be used given their > parent sets. > >> The above statement implies that nodes may still go for a relaxed > policy when > >> strict can be used. > > > > > > Thanks for catching this, but in this case this is intentional. > > As far as we are concerned a) there is no "best" policy, and b) a new > policy might be introduced in the future. > > The important aspect is that the choice of policy is a local (node) > decision and different nodes can select different policies based on > whichever criteria make sense for them. > > For example, depending on the required performance in > jitter/delay/reliability that is desired a different policy might be used. > > An administrator might also configure nodes in a specific way. > > In any case, we do not want to reduce flexibility in this aspect by > defining a spcific hierarchy/preference order on the policies. > > Maybe it makes sense to clarify this a bit? > > [RJ] It would certainly help to clarify the bit. One question, is > there any reason/use-case why any node will not go for strict policy? > Why would administrator configure anything other than strict policy? > In the above response, it is suggested that to control > jitter/delay/reliability. But the strict policy is best for any > use-case and for any metric or any group of metrics, isn't it? > Actually, I that that it is not the best in all cases, so we have two examples in mind. 1) Admin chooses relaxed to increase reliability (thus producing some flooding) for specific, extremely important, alert packets. All normal data traffic uses strict, but for the alert packets an exception is made. 2) One might devise a disjoint pattern, where the paths are on purpose non-correlated, to increase path diversity and resilience against whole groups of nodes failing. Of course, you pay with increased jitter. If strict is always the default, you cannot ever replace it with another policy with different characteristics. By the way, nothing in the draft actually restricts an admin from configuring the policies with a preference order of strict > medium > relaxed, it's just that the draft does not enforce any particular such ordering. Does this make more sense? Do you think it would help to include such examples as an appendix in the draft? > > > >> > >> > >> o Configuration parameters > >> The document specifies configuration parameters such as > >> a. PARENT_SET_SIZE ... Not defined > > > > > > Thanks, we hadn't clarified that this is the same as the MRHOF > PARENT_SET_SIZE variable. Updated in master. > > > >> > >> b. cur_ap_min_path_cost: How can the cur_ap_min_path_cost be equated > with > >> PARENT_SWITCH_THRESHOLD as mentioned in section 3.2.2 > > > > > > Thank you but we are not very sure we understant the question. This > section basically says that in addition to the normal MRHOF > cur_min_path_cost variable, we add the cur_ap_min_path_cost variable which > contains the path cost of the current AP. > > We use the same threshold PARENT_SWITCH_THRESHOLD that MRHOF uses to > decide if we need to change AP. > > Just to be sure, we have now clarified here that PARENT_SWITCH_THRESHOLD > is the same value that MRHOF uses. Updated in master. > > [RJ] ok thanks. My confusion was that cur_ap_min_path_cost is the > aggregated cost to that AP from the root. This cost is the link local > cost of the node to that AP. Is this correct? > Actually it *is* the aggregated cost. As in RFC6719 (MRHOF). Section "3.1. Computing the Path Cost", """The path cost of a neighbor represents the cost of the path, in terms of the selected metric, from a node to the root of the Destination-Oriented DAG (DODAG) through that neighbor.""" So similarly to cur_min_path_cost, the new cur_ap_min_path_cost is the cost of the path to the root, but through the AP instead of the preferred parent. Is it clearer now? > > > > >> > >> c. MAX_PATH_COST: No definition for this. > > > > > > Again, thanks, we hadn't clarified that this comes from MRHOF. We added > a clarification and updated in master. > > > >> > >> The parameters warrant a rationale and a default value. Also more > importantly, > >> is it required that different nodes use the same value and if not what > could be > >> the impact. > > > > > > The values used and their semantics should now be clear, basically in > this section we either reuse existing MRHOF variables with the same MRHOF > semantics, or we introduce new variables which have corresponding ones in > MRHOF and similar semantics. > > Please let us know if you think we should define something in more > detail, but we would like to avoid too much duplication from MRHOF, if > possible. > > > >> > >> > >> o Terminology section > >> Terminology section should explain Alternative Parent, Parent Set, > Preferred > >> Grand Parent. > > > > > > Thank you very much, this is a good idea. We have amended the text with > this and updated in master. > > > >> > >> > >> o Section realignment > >> It is better to explain CA Strict/Medium/Relax policies before > explaining the > >> CAOF because as a reader one needs to be familiar with these policies > before > >> understanding the OF. > > > > > > Thank you for this comment. We had a similar concern as well. > > We are not sure what is best. > > As the text is current structured, we introduce the CAOF first, > mentioning that different policies are possible and that a selection from > the parent set must be made. > > We then describe the CAOF in terms of differences from/additions to > MRHOF. > > And finally we describe the policies. > > To my mind, the policies are concrete, but they are also just examples, > so someone can devise different ones. > > In that sense the CAOF is more "fixed" and the policies are more > flexible. Thus it makes sense to describe the CAOF first. > > > > We are very open to changing the order, but we would like to have some > additional feedback that the order is problematic as it stands now. > > We would like to hear any suggestions from the group on this topic. > > [RJ] Ok, lets wait for feedback. I, for one, would like to see > policies explained first and then an OF using them. I find this the > only logical way. > Sounds good, I will initiate a separate thread for this in the WG. Again, thanks a lot for everything. Best, Aris --0000000000005c0890059e39cc9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Rahul,

thanks for the follow up. I think we've resolved most issues.
Responding inline.

On Mon, Feb 10, 2020 at 9:33 AM Rahul Jadhav= <rahul.ietf@gmail.com> w= rote:
Thanks Ari= s, Georgios for clarifications. Please find my responses inline.


>>
>> o Carrying TLVs in NSA
>> RFC 6551 explains that an NSA can be used to carry TLVs but it fal= ls short of
>> specifying the format for these TLVs. This document assumes the fo= rmat of 8-bit
>> type and 8-bit length. This format is fine but future specificatio= ns will have
>> to refer to this document if they got to add new TLVs. Thus the ge= neric TLV
>> format should be made part of different section and an IANA regist= ry needs to
>> be created for the NSA TLV type.
>
>
> I'm not sure I fully understood correctly.
> In RFC6551, page 24, Section "6.2.=C2=A0 Routing Metric/Constrain= t TLVs" it says:
> """IANA has created a sub-registry, called "Routin= g Metric/Constraint
>=C2=A0 =C2=A0 TLVs", used for all TLVs carried within Routing Metr= ic/Constraint
>=C2=A0 =C2=A0 objects.=C2=A0 The Type field is an 8-bit field whose val= ue is comprised
>=C2=A0 =C2=A0 between 0 and 255.=C2=A0 Value 0 is unassigned.=C2=A0 The= Length field is an
>=C2=A0 =C2=A0 8-bit field whose value ranges from 0 to 255.=C2=A0 The V= alue field has
>=C2=A0 =C2=A0 value ranges depending on the Type; therefore, they are n= ot defined
>=C2=A0 =C2=A0 here, since no Type is registered at this time."&quo= t;"

[RJ]: The reason why I was confused is that the "Optional TLVs"= =C2=A0 are
mentioned in NSA section but there is no reference for the TLV format.
I now realized that section 2.1 has a para that explains the TLV
format which is applicable to all the optional TLVs in 6551. I stand
corrected. Thank you.

Great. Thanks as = well.
=C2=A0

>
> So yes, there is no NSA-specific TLV structure, it is common registry = for all the routing metrics and constraints, including the NSA.
> See https://www.iana.org/assignments/rpl-routing-metric-constrai= nt/rpl-routing-metric-constraint.xhtml#rmc-tlv
> As I understand it, RFC6551 contains the reference definition of the T= LV strucure (8bit Type, 8bit Length, variable length Value field)
> and in our draft we basically ask for the creation of a new entry in t= his sub-registry and specify/define the structure of the Value field only > (since the T & V are fixed already).
> Is this maybe not sufficient?

[RJ] This is sufficient, imo. Thanks

Go= od we cleared that up. Thanks.
=C2=A0

>
>>
>>
>> o Preference in PS set
>> The document assumes that the parent addresses in the PS set have = been added in
>> the decreasing order of preference, without making it explicit. Th= e PS IPv6
>> address(es) field requires an explanation in Section 4.
>
>
> Thank you very much, we have amended that part of the draft accordingl= y. Please see if it is clear now (master branch in https://github.com/roll-wg/draft-ietf-roll-nsa-extension).

[RJ] I checked the PR. All ok except one question in the new changes,
"The number of p, wearent addresses in the PS IPv6" .... What is = "wearent"?

Ah, unfortunately = a typo. Fixed it in master, is should have read "The number of parent = addresses in the PS IPv6 address(es) field"
Thanks for the c= atch!
=C2=A0

>
>
>>
>> o DIO length
>> As per the draft, the DIO needs to carry NSA (Node State and Attri= butes) metric
>> with PS (parent set) TLV. As per my understanding without compress= ion, it would
>> be a challenge to carry even two parent addresses in the PS. There= has been a
>> discussion about compression and as I remember we discussed doing = it.
>> Regardless, I feel we should do it if we want this to be a practic= al
>> proposition.
>
>
>
> Thank you for this comment.
> We agree that given the size of the IPv6 addresses, it would be prohib= itive to include more than 2 addresses.
> When we initially pointed out this constraint ourselved, Michael point= ed us in the direction of 6LoRH.
> We implemented a 6LoRH-style compression for this field and it worked = well.
> However, it was becoming complicated, somewhat out-of-scope and since = there was no good place to point at for our 6LoRH-style compression (a pote= ntially blocking issue), we discussed the options with the group (see an em= ail thread with subject "[Roll] I-D Action: draft-ietf-roll-nsa-extens= ion-02.txt" June 24 2019 - July 2 2019).
> With input from Pascal and Dominique we decided to completely drop com= pression, in favour of a potential separate and more general compression dr= aft for all control packets.
> We would actually like to contribute to that, but for the time being, = a specific compression method for the PS field has been taken out of this d= raft.

[RJ] Sure, my concern is that it may be infeasible to use this work
without compression. I was hoping to use either 6lorh style or
P2P-RPL/AODV-RPL style (used for address vector) compression.

I agree that compression is necessary but it looks l= ike the consensus is to handle this in a more all-encompassing and separate= compression draft.
So from the feedback that we received from th= e WG so far, there doesn't seem that there is something to do here.
=

=C2=A0
>
>>
>>
>> o Section 3.4 Usage:
>> "For example, using different methods can be used to vary the= transmission
>> reliability in each hop."
>> This statement implies that using different CA policy implementati= on can
>> "control" the transmission reliability. As I understand,= the strict policy is
>> the best policy (in terms of all performance metrics), the nodes w= ill go for
>> other policy only when the strict policy cannot be used given thei= r parent sets.
>> The above statement implies that nodes may still go for a relaxed = policy when
>> strict can be used.
>
>
> Thanks for catching this, but in this case this is intentional.
> As far as we are concerned a) there is no "best" policy, and= b) a new policy might be introduced in the future.
> The important aspect is that the choice of policy is a local (node) de= cision and different nodes can select different policies based on whichever= criteria make sense for them.
> For example, depending on the required performance in jitter/delay/rel= iability that is desired a different policy might be used.
> An administrator might also configure nodes in a specific way.
> In any case, we do not want to reduce flexibility in this aspect by de= fining a spcific hierarchy/preference order on the policies.
> Maybe it makes sense to clarify this a bit?

[RJ] It would certainly help to clarify the bit. One question, is
there any reason/use-case why any node will not go for strict policy?
Why would administrator configure anything other than strict policy?
In the above response, it is suggested that to control
jitter/delay/reliability.=C2=A0 But the strict policy is best for any
use-case and for any metric or any group of metrics, isn't it?

Actually, I that that it is not the best in all= cases, so we have two examples in mind.
1) Admin chooses relaxed= to increase reliability (thus producing some flooding) for specific, extre= mely important, alert packets. All normal data traffic uses strict, but for= the alert packets an exception is made.
2) One might devise a di= sjoint pattern, where the paths are on purpose non-correlated, to increase = path diversity and resilience against whole groups of nodes failing. Of cou= rse, you pay with increased jitter. If strict is always the default, you ca= nnot ever replace it with another policy with different characteristics.

By the way, nothing in the draft actually restricts = an admin from configuring the policies with a preference order of strict &g= t; medium > relaxed, it's just that the draft does not enforce any p= articular such ordering.

Does this make more sense= ?
Do you think it would help to include such examples as an appen= dix in the draft?


>
>>
>>
>> o Configuration parameters
>> The document specifies configuration parameters such as
>> a. PARENT_SET_SIZE ... Not defined
>
>
> Thanks, we hadn't clarified that this is the same as the MRHOF PAR= ENT_SET_SIZE variable. Updated in master.
>
>>
>> b. cur_ap_min_path_cost: How can the cur_ap_min_path_cost be equat= ed with
>> PARENT_SWITCH_THRESHOLD as mentioned in section 3.2.2
>
>
> Thank you but we are not very sure we understant the question. This se= ction basically says that in addition to the normal MRHOF cur_min_path_cost= variable, we add the cur_ap_min_path_cost variable which contains the path= cost of the current AP.
> We use the same threshold PARENT_SWITCH_THRESHOLD that MRHOF uses to d= ecide if we need to change AP.
> Just to be sure, we have now clarified here that PARENT_SWITCH_THRESHO= LD is the same value that MRHOF uses. Updated in master.

[RJ] ok thanks. My confusion was that cur_ap_min_path_cost is the
aggregated cost to that AP from the root. This cost is the link local
cost of the node to that AP. Is this correct?

Actually it *is* t= he aggregated cost.
As in RFC6719 (MRHO= F). Section "3.1.=C2=A0 Computing the Path Cost",
""= "The path cost of a neighbor represents
the cost of the path, in terms of the selected metric, from a node to
= the root of the Destination-Oriented DAG (DODAG) through that
neighbor.&= quot;""

So similarly to cur_min_path_cost, the new cur_ap_= min_path_cost is the cost of the path to the root, but through the AP inste= ad of the preferred parent.

Is it clearer now?
=C2=A0

>
>>
>> c. MAX_PATH_COST: No definition for this.
>
>
> Again, thanks, we hadn't clarified that this comes from MRHOF. We = added a clarification and updated in master.
>
>>
>> The parameters warrant a rationale and a default value. Also more = importantly,
>> is it required that different nodes use the same value and if not = what could be
>> the impact.
>
>
> The values used and their semantics should now be clear, basically in = this section we either reuse existing MRHOF variables with the same MRHOF s= emantics, or we introduce new variables which have corresponding ones in MR= HOF and similar semantics.
> Please let us know if you think we should define something in more det= ail, but we would like to avoid too much duplication from MRHOF, if possibl= e.
>
>>
>>
>> o Terminology section
>> Terminology section should explain Alternative Parent, Parent Set,= Preferred
>> Grand Parent.
>
>
> Thank you very much, this is a good idea. We have amended the text wit= h this and updated in master.
>
>>
>>
>> o Section realignment
>> It is better to explain CA Strict/Medium/Relax policies before exp= laining the
>> CAOF because as a reader one needs to be familiar with these polic= ies before
>> understanding the OF.
>
>
> Thank you for this comment. We had a similar concern as well.
> We are not sure what is best.
> As the text is current structured, we introduce the CAOF first, mentio= ning that different policies are possible and that a selection from the par= ent set must be made.
> We then describe the CAOF in terms of differences from/additions to MR= HOF.
> And finally we describe the policies.
> To my mind, the policies are concrete, but they are also just examples= , so someone can devise different ones.
> In that sense the CAOF is more "fixed" and the policies are = more flexible. Thus it makes sense to describe the CAOF first.
>
> We are very open to changing the order, but we would like to have some= additional feedback that the order is problematic as it stands now.
> We would like to hear any suggestions from the group on this topic.
[RJ] Ok, lets wait for feedback. I, for one, would like to see
policies explained first and then an OF using them. I find this the
only logical way.

Sounds good, I will i= nitiate a separate thread for this in the WG.

Agai= n, thanks a lot for everything.

Best,
Ar= is

--0000000000005c0890059e39cc9e-- From nobody Mon Feb 10 08:08:54 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF960120232 for ; Mon, 10 Feb 2020 06:56: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com header.b=PQQaIgmi; dkim=pass (2048-bit key) header.d=ariskou.com header.b=m2TV147O Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxASQzMTVLM7 for ; Mon, 10 Feb 2020 06:56:28 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4804120227 for ; Mon, 10 Feb 2020 06:56:27 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 6C847BC for ; Mon, 10 Feb 2020 15:56:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1581346586; bh=YW6FVBai7EdzqFd4gde9Xd2T3d1qLJHORy46Hv11YQc=; h=From:Date:Subject:To:Cc:From; b=PQQaIgmiS6sJCvnoCV/YzRZaVFLLTiiPUThCWBHz+ztJYZhODzOjqp7OtgOwCYqV6 mIb2IvUMlNOOsiFzxLLKJGbhgHjzHI+hGDDuSCsyRHpIVylckFID1qm7qw6aVIwP0t tE2Va+UtbpQ1RpPEe505MHx9YIqYG1bhWgEwjY7xe+BcmizBh1aEVJiiUcuNfDQHKm ZO9cyT5rAxP6NQJ4G7uAHHu7lgKPDTbSLsEaCpsnt4POaUllasfjfyYKFvq6xMiNGH mJ/n8onvBJWlFRP2ooixBGcWj4dzyN2ikoqnvCq07MES8atXRV/zyQ2dJvqj6lqvqf /pwnhHG9Etcrw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1581346586; s=20191001-wvim; d=ariskou.com; i=aris@ariskou.com; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; l=4012; bh=YW6FVBai7EdzqFd4gde9Xd2T3d1qLJHORy46Hv11YQc=; b=m2TV147OPrdkbRpE75o7czjbqwjaaTlQC2c0BZmXj0ZapEqdvSzrpzvVq9cHb6om G25QLDGqQx0ONhUC7xwn1eEnVm5DwjgIb51Xn3lAlllFlP0TubtTvT8uPSWO5l339gO LebJ+ULxxqqJHB7d1szAgMdVW3jw65sO2wbCO9N1Uc/XtLeKmfhiIzXnJvo8C45FHJ2 062NTSQqxnIP69J+mO1GtzPGbSOaqshdEHQMldiKL2633yBQW2lPgbfR/mRFnUjL8q3 WXHwyPWvd7QEn7LWw2Ny1QU4/RguTl3bXeb3RxqtexOwEwE5ur/5xb6fynZ3oLqe4i/ bZ1LTCUnMg== Received: by smtp.mailfence.com with ESMTPA for ; Mon, 10 Feb 2020 15:56:23 +0100 (CET) Received: by mail-il1-f178.google.com with SMTP id v13so446947iln.4 for ; Mon, 10 Feb 2020 06:56:22 -0800 (PST) X-Gm-Message-State: APjAAAXXMRn++eg+LHAEig84nZFXAxhsUCo6YD8gt8DbAgDM3a3oExVJ iip3eOOZSZ4ot/5q1gSF1Q1HlzUbrgpOpIDmS9U= X-Google-Smtp-Source: APXvYqzRWGBE5k6JPBg5fEJsViH08RCTOWzB8SfJgXNPDElrMiKO6rmU7EnkGdWljGJ1P7SyoyOStm6WjbLBrKHyiko= X-Received: by 2002:a92:d3c6:: with SMTP id c6mr1839408ilh.228.1581346575342; Mon, 10 Feb 2020 06:56:15 -0800 (PST) MIME-Version: 1.0 From: Remous-Aris Koutsiamanis Date: Mon, 10 Feb 2020 15:56:24 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: INES ROBLES , dominique barthel , "Pascal Thubert (pthubert)" , roll Cc: "Georgios Z. Papadopoulos" Content-Type: multipart/alternative; boundary="000000000000e3e3b3059e39f073" X-ContactOffice-Account: com:113819248 Archived-At: Subject: [Roll] [draft-ietf-roll-nsa-extension] Section realignment - feedback request X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 14:56:30 -0000 --000000000000e3e3b3059e39f073 Content-Type: text/plain; charset="UTF-8" Dear Ines, Dominique, Pascal, and all, After discussing and amending the draft-ietf-roll-nsa-extension draft with feedback from Rahul, a few points still remain which we would like some additional feedback on. I copy the relevant discussion below: [RJ] Section realignment It is better to explain CA Strict/Medium/Relax policies before explaining the CAOF because as a reader one needs to be familiar with these policies before understanding the OF. [AK] Thank you for this comment. We had a similar concern as well. We are not sure what is best. As the text is current structured, we introduce the CAOF first, mentioning that different policies are possible and that a selection from the parent set must be made. We then describe the CAOF in terms of differences from/additions to MRHOF. And finally we describe the policies. To my mind, the policies are concrete, but they are also just examples, so someone can devise different ones. In that sense the CAOF is more "fixed" and the policies are more flexible. Thus it makes sense to describe the CAOF first. We are very open to changing the order, but we would like to have some additional feedback that the order is problematic as it stands now. We would like to hear any suggestions from the group on this topic. [RJ] Ok, lets wait for feedback. I, for one, would like to see policies explained first and then an OF using them. I find this the only logical way. [RJ] Rahul Jadhav [AR] Aris Koutsiamanis Thank you very much in advance. Best, Aris --000000000000e3e3b3059e39f073 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Ines, Dominique, Pascal, and all,

=
After discussing and amending the draft-ietf-roll-nsa-extension draft with feedback from Rahul, a few points= still remain which we would like some additional feedback on.
=

I copy the relevant discussion below:
<= br>
[RJ] Section realignment
It is better to explain CA= Strict/Medium/Relax policies before explaining the
CAOF because as a re= ader one needs to be familiar with these policies before
understanding t= he OF.


[AK] Thank you for this comment. We had a similar concern= as well.
We are not sure what is best.
As the text is current struct= ured, we introduce the CAOF first, mentioning that different policies are p= ossible and that a selection from the parent set must be made.
We then d= escribe the CAOF in terms of differences from/additions to MRHOF.
And fi= nally we describe the policies.
To my mind, the policies are concrete, b= ut they are also just examples, so someone can devise different ones.
In= that sense the CAOF is more "fixed" and the policies are more fl= exible. Thus it makes sense to describe the CAOF first.

We are very = open to changing the order, but we would like to have some additional feedb= ack that the order is problematic as it stands now.
We would like to hea= r any suggestions from the group on this topic.


[RJ] Ok, lets wa= it for feedback. I, for one, would like to see
policies explained first = and then an OF using them. I find this the
only logical way.


= [RJ] Rahul Jadhav
[AR] Aris Koutsiamanis


Thank you very much in advance.

Best,
Aris
=

--000000000000e3e3b3059e39f073-- From nobody Mon Feb 10 08:09:47 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA72120273; Mon, 10 Feb 2020 07:09:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com header.b=BXxeevj7; dkim=pass (2048-bit key) header.d=ariskou.com header.b=XLEJfYiO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 333DBpoP8nwi; Mon, 10 Feb 2020 07:09:02 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05B912026E; Mon, 10 Feb 2020 07:09:01 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 7D3554ED; Mon, 10 Feb 2020 16:09:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1581347340; bh=T8Ca757ZY7SR6f5yx6/+V3aYz1IWnRLmzYkfMDrVu/Y=; h=References:In-Reply-To:From:Date:Subject:To:From; b=BXxeevj7lMRuOhtMvTFiG7ZzjllaDAtCNxJXFNugT/azVygBylUDjuVOd1joI4zvr 9pobtqTpiEFZoiB2uKscf8anCEu+L51dd8opUOV8aBxmaNlZHOEGSXOLvVJwubdvrz +iYoppEH2qjdMHyHdpxEk0tCnjm/HmvW9ni97Qc0uCFA7xyoouLq1JR1UspN7+QQOQ feSDNO8YdBeVSvYgABmL0Do1TJsFLVZKGuvenN3xxJpkPPAkDvuc9h4mZk98QmU/9s FR65PuDpKoDB6KMcRoYOz05nXKenOfHyVNSm/hy8DSaSJV598a+Aej/7GemX+2bHX4 oxNfNz1PXBtIA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1581347340; s=20191001-wvim; d=ariskou.com; i=aris@ariskou.com; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Content-Type; l=7959; bh=T8Ca757ZY7SR6f5yx6/+V3aYz1IWnRLmzYkfMDrVu/Y=; b=XLEJfYiOTYdkakVahJ3/8hnC6xOJ19/RuE6r5Ik17aEpqvEuC3MfPRA6X/SckHcT 3DSWAqXn1Lh5/QdlYTcQfKEUe840g2jpP+0+C1MSG5XB+bA4XkFmpjqob5pNKtkU04k rS+/DC78sHeA4DF2TEZTc447Rhsot/Bn1gTGhAuNyY9uWEzovcutlEI/vDYR8SIqELV Atm9j+0SWCaVwVKXZOYBpEfqdydTD9m8+fo2PJMnczcQZgd+tR3G2afIUi5JkceYHPO RWEK+pqcZPAQVb8qi90s00ajUSoKRCIO9UJRX5wAlEvVsEjBb7XU7ZEEN4Ijt58up58 FiqvXrbnOQ== Received: by smtp.mailfence.com with ESMTPA ; Mon, 10 Feb 2020 16:08:56 +0100 (CET) Received: by mail-io1-f45.google.com with SMTP id d15so7941390iog.3; Mon, 10 Feb 2020 07:08:55 -0800 (PST) X-Gm-Message-State: APjAAAVjFNN4X5TbQnZmrncqJRSnq0HEUqYNcIAxmBhvuH062tYf8fYN W0w2GHOmgw2TBtOp0zNVw3EBwH6V3xz9q9DpSUM= X-Google-Smtp-Source: APXvYqxeYJWSbpr1HlBdLyMHCYwvn+6go97K7SaDdFAcFYPqYYft5WJGH8CuEiWm6SnrkZ3naWySNAeLGRPippWdahs= X-Received: by 2002:a5e:de42:: with SMTP id e2mr9925334ioq.228.1581347334435; Mon, 10 Feb 2020 07:08:54 -0800 (PST) MIME-Version: 1.0 References: <4422_1572425152_5DB94DC0_4422_62_1_D9DF0C50.6B281%dominique.barthel@orange.com> In-Reply-To: From: Remous-Aris Koutsiamanis Date: Mon, 10 Feb 2020 16:08:57 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: abdussalambaryun@gmail.com, roll-chairs@ietf.org, roll Content-Type: multipart/alternative; boundary="00000000000022b99a059e3a1e6e" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] =?utf-8?q?WGLC_for_=E2=80=8Bdraft-ietf-roll-nsa-extension?= =?utf-8?q?-05?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 15:09:04 -0000 --00000000000022b99a059e3a1e6e Content-Type: text/plain; charset="UTF-8" Hello Abdussalam, Sorry about the late reply. We are not sure if the contents of this draft constitute an update since we are proposing a new Objective Function and a modification of a DIO TLV (RFC 6551). We would like to have some feedback from the WG chairs if possible, but in principle we have no issue with changing the draft in this sense. Best, Aris On Mon, Nov 25, 2019 at 8:00 AM Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > I think this draft should update rfc6550, not mentioned in draft. > > AB > > On Tue, Nov 19, 2019 at 3:21 AM Ines Robles 40googlemail.com@dmarc.ietf.org> wrote: > >> Dear all, >> >> This a WGLC of the draft-ietf-roll-nsa-extension-05. >> >> Please let us know your opinion by 03 december. >> >> Thank you, >> >> Ines, Dominique and Peter >> >> On Wed, Oct 30, 2019 at 10:46 AM > > wrote: >> >>> Dear all, >>> >>> A Working Group Last Call (WGLC) starts today (10/30) until 11/13 for >>> *draft-ietf-roll-nsa-extension-04*. >>> The draft is available here: >>> https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/ >>> Please review this draft to see if you think that it is ready for >>> publication and send comments to the list stating your view. >>> Thank you very much in advance, >>> >>> Ines, Peter and Dominique. >>> >>> _________________________________________________________________________________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00000000000022b99a059e3a1e6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Abdussalam,

Sorry abou= t the late reply.
We are not sure if the contents of this draft c= onstitute an update since we are proposing a new Objective Function and a m= odification of a DIO TLV (RFC 6551).
We would like to have some f= eedback from the WG chairs if possible, but in principle we have no issue w= ith changing the draft in this sense.

Best,
<= div>Aris

On Mon, Nov 25, 2019 at 8:00 AM Abdussalam Baryun &l= t;abdussalambaryun@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">
I think this draft should update rfc6550, not mentione= d in draft.

AB

On Tue, Nov 19, 2019 at 3:= 21 AM Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org> w= rote:
Dear all,

This a WGLC of the d= raft-ietf-roll-nsa-extension-05.

Please let us kno= w your opinion by 03 december.

Thank you,

Ines, Dominique and Peter

On Wed, Oct 30, 2019 at 10:= 46 AM <dominique..barthel@orange.com> wrote:
Dear all,

A Working Group Last Call (WGLC) starts today (10/30) until 11/13 for = draft-ietf-roll-nsa-extension-04.
The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/=C2=A0
Please review this draft to see if you think that it is ready for publ= ication and send comments to the list stating your view.
Thank you very much in advance,

Ines, Peter and Dominique.

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--00000000000022b99a059e3a1e6e-- From nobody Mon Feb 10 08:10:13 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF16120255; Mon, 10 Feb 2020 07:16:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <158134776676.4117.590004513972783436@ietfa.amsl.com> Date: Mon, 10 Feb 2020 07:16:06 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-nsa-extension-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 15:16:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Common Ancestor Objective Function and Parent Set DAG Metric Container Extension Authors : Remous-Aris Koutsiamanis Georgios Papadopoulos Nicolas Montavont Pascal Thubert Filename : draft-ietf-roll-nsa-extension-06.txt Pages : 15 Date : 2020-02-10 Abstract: Implementing Packet Replication and Elimination from/to the RPL root requires the ability to forward copies of packets over different paths via different RPL parents. Selecting the appropriate parents to achieve ultra-low latency and jitter requires information about a node's parents. This document details what information needs to be transmitted and how it is encoded within RPL control packets to enable this functionality. This document also describes Objective Function which take advantage of this information to implement multi- path routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-06 https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-nsa-extension-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 10 08:10:46 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73031120801 for ; Mon, 10 Feb 2020 07:51:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-Mvdg-CNTsw for ; Mon, 10 Feb 2020 07:51:45 -0800 (PST) Received: from zproxy130.enst.fr (zproxy130.enst.fr [137.194.2.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE46D120800 for ; Mon, 10 Feb 2020 07:51:44 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 2D2C61203B3 for ; Mon, 10 Feb 2020 16:51:42 +0100 (CET) Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id mUEItXEfWFH5 for ; Mon, 10 Feb 2020 16:51:41 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 1346D120C0E for ; Mon, 10 Feb 2020 16:51:41 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy130.enst.fr 1346D120C0E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1581349901; bh=/C2jlTlk+WbkjzcsZpFybpnBfrPB3QCfdA/BMjrQ9pw=; h=From:Date:To:Message-Id:Mime-Version; b=GADbL43MUJiJMJILU3wGp6W5GBjR/zDECifHBoexfEWzJBqH0sfAV6AAwjkWyzSAm m2Oc3P//1wMfI3EdrIWqvca1s/Rk0gXaFCgndsI21nWfeZjO1XTpyvVJBEs4iI9E9d /ANY/2sj75oEkJ6qwo7mi+8r/5RKSifJub/RX2Lo= X-Virus-Scanned: amavisd-new at zproxy130.enst.fr Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id ML471Sl165l5 for ; Mon, 10 Feb 2020 16:51:40 +0100 (CET) Received: from [IPv6:2001:660:7301:3728:f013:d674:3790:67da] (unknown [IPv6:2001:660:7301:3728:f013:d674:3790:67da]) by zproxy130.enst.fr (Postfix) with ESMTPSA id DD2871203B3 for ; Mon, 10 Feb 2020 16:51:40 +0100 (CET) From: "Georgios Z. Papadopoulos" Content-Type: multipart/alternative; boundary="Apple-Mail=_58AF5BE0-4C3F-41C5-B39E-C1F9D9DC6D62" Date: Mon, 10 Feb 2020 16:51:40 +0100 References: <158134776694.4117.16175545100765405335.idtracker@ietfa.amsl.com> To: Routing Over Low power and Lossy networks Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Roll] Fwd: New Version Notification for draft-ietf-roll-nsa-extension-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 15:51:47 -0000 --Apple-Mail=_58AF5BE0-4C3F-41C5-B39E-C1F9D9DC6D62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, FYI, we just submitted the 06 version where we addressed the comments = from Rahul. Many thanks Rahul, Georgios and Aris > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-roll-nsa-extension-06.txt > Date: February 10, 2020 at 16:16:06 GMT+1 > To: "Nicolas Montavont" , "Pascal = Thubert" , "Georgios Papadopoulos" = , "Remous-Aris Koutsiamanis" = >=20 >=20 > A new version of I-D, draft-ietf-roll-nsa-extension-06.txt > has been successfully submitted by Remous-Aris Koutsiamanis and posted = to the > IETF repository. >=20 > Name: draft-ietf-roll-nsa-extension > Revision: 06 > Title: Common Ancestor Objective Function and Parent = Set DAG Metric Container Extension > Document date: 2020-02-10 > Group: roll > Pages: 15 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-roll-nsa-extension-06.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-06 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-nsa-extension-06 >=20 > Abstract: > Implementing Packet Replication and Elimination from/to the RPL root > requires the ability to forward copies of packets over different > paths via different RPL parents. Selecting the appropriate parents > to achieve ultra-low latency and jitter requires information about a > node's parents. This document details what information needs to be > transmitted and how it is encoded within RPL control packets to > enable this functionality. This document also describes Objective > Function which take advantage of this information to implement = multi- > path routing. >=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=_58AF5BE0-4C3F-41C5-B39E-C1F9D9DC6D62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear all,

FYI, we just = submitted the 06 version where we addressed the comments from = Rahul.

Many = thanks Rahul,
Georgios and Aris


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-ietf-roll-nsa-extension-06.txt
Date: = February 10, 2020 at 16:16:06 = GMT+1
To: = "Nicolas Montavont" <nicolas.montavont@imt-atlantique.fr>, "Pascal Thubert" = <pthubert@cisco.com>, "Georgios Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr>, "Remous-Aris = Koutsiamanis" <aris@ariskou.com>


A new version = of I-D, draft-ietf-roll-nsa-extension-06.txt
has been = successfully submitted by Remous-Aris Koutsiamanis and posted to the
IETF repository.

Name: = draft-ietf-roll-nsa-extension
Revision: 06
Title:= = Common Ancestor Objective Function and Parent Set DAG Metric = Container Extension
Document date: = 2020-02-10
Group: roll
Pages: 15
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-roll-nsa-extens= ion-06.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/=
Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-06
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-exten= sion
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-nsa-extensi= on-06

Abstract:
=   Implementing Packet Replication and Elimination from/to the = RPL root
  requires the ability to forward = copies of packets over different
  paths via = different RPL parents.  Selecting the appropriate parents
  to achieve ultra-low latency and jitter requires = information about a
  node's parents. =  This document details what information needs to be
=   transmitted and how it is encoded within RPL control packets = to
  enable this functionality.  This = document also describes Objective
  Function = which take advantage of this information to implement multi-
  path routing.




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=_58AF5BE0-4C3F-41C5-B39E-C1F9D9DC6D62-- From nobody Mon Feb 10 19:32:47 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC2C120072 for ; Mon, 10 Feb 2020 19:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 WQxImWkWlaVX for ; Mon, 10 Feb 2020 19:32:43 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 53E2B120052 for ; Mon, 10 Feb 2020 19:32:43 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id x7so9916388ljc.1 for ; Mon, 10 Feb 2020 19:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=K7ozMjd197A9WMSvM7BRGpT6bymTG7E71RZNFL7beXI=; b=rBwB98U4YkfnGTCpO6EIzH4Xw2XIe07cBQIduFtrpUN+bsQ2KlrOl4Sws2czXD/OGz v3iBae0IBCOyN1L7Aot06rzmKFL6EK0+48q0fX7aaNAdH216099qnZ4pyXpEgfnHtY2l CUiO/IHDt+whO/NvYoifbJ5YxH7EhMTMjIdDgtuTZw99mwDxit7jm56WieQupekP6aur BSHDIx5EIzkFl1SkvMNjil7T4YHZDx5dl0y/vE0jwByK5d+cs+TeczL1VwIkSJQjPR0M D5zDgscpJ0o5lUvbPb2cSm3mt2mDcfp8SYzcbqi7BSqmbqwshuhQTHLbdIdiuyZwaPGE tYOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=K7ozMjd197A9WMSvM7BRGpT6bymTG7E71RZNFL7beXI=; b=ecf0ls8ZNuRBJaQ0qbcqN1iMVxy8lL44UBOa2g9MBJPSp8Qm8EymqRht6ddpjU2yRS z1tGqHmA4t1APNcf58uE2FNG2njMTnrjf676FVYkwbbEb+56VaCgfzzGudwvDYJqH6uk dVJMDL77uwMNaLwApY2GhIxoYFr/VQUK/N6jhU0RjLFg+tfP6f4VoihQQ5RkuFhG72+B P2rANLlnTGpCcRfIwnOSRbCIK9J1Fy5XJjXxrDpKl19FWbNTIrZMMrexX3EiHQTTQTTP Iy5lkJOvviPNvOTsag2DimsgBpg/bf4G6v+yYe7f7i2CERgdBq6qRQNg+YshfG/LAZPw 6zTQ== X-Gm-Message-State: APjAAAVUAKz6D6p+TFC29ddPXH54HpQ77Hrlwz29MdVfSr7DoTJvl5gZ mPIFZVpnd6mk0FP+M2aA/VT9FZIDPZiA1FBppsu7wQ== X-Google-Smtp-Source: APXvYqw1qyEaF5bLy1oITKaOUaRtQspiWEELykPaYjvQGtySDhhpC6fJVaoorkBY5P5zCamaHP/LDX9MwbLji9FeJ0o= X-Received: by 2002:a2e:b6ce:: with SMTP id m14mr2631724ljo.99.1581391961457; Mon, 10 Feb 2020 19:32:41 -0800 (PST) MIME-Version: 1.0 From: Rahul Jadhav Date: Tue, 11 Feb 2020 09:02:29 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Roll] NSA PS-set metric/constraint X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 03:32:45 -0000 Hello Authors of NSA extn and all, One more question in the context: The draft adds new routing metrics/constraints (PS set) nested as part of the NSA parent metric. My question is with regards to what happens if this routing metric is used outside of the CAOF. Any metrics/constraints could be used by any OF and thus PS set metric defined by the draft can be used by other OF. RFC 6551 says that if the metric is not understood by the node and if it is a 6LR then it may not process it but it has to propagate it. Unlike other metrics, the PS set metric in this case contains link-local values that cannot be used beyond link-local. As such upon propagation, any downstream 6LR that understands the PS set metric would use the information and get impacted adversely. Should we tie the PS set metric to CAOF specifically in the draft, in which case this problem won't be there? Or we can specify this issue as it is for the readers to understand the problem if the PS set is used outside of the CAOF. Either way works for me. Best, Rahul From nobody Mon Feb 10 21:29:12 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2760120052 for ; Mon, 10 Feb 2020 21:29:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 PwzcdymMsRIg for ; Mon, 10 Feb 2020 21:29:07 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::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 7D697120041 for ; Mon, 10 Feb 2020 21:29:07 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id v19so11656588oic.12 for ; Mon, 10 Feb 2020 21:29:07 -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=r4btQlEg9Cw73pRrRyfSJh27tV3bVYw5dInehzsUjA0=; b=KfmvMupAE4UcJ3T+LhrhaFezm0QQyNkgEsrNKaIaHvDreIIWfHtheELsJzV+fMfefg blNyU+sZlb4hX+BvDKM6F14sPQopTt5lFDhKkMWRV3sbqGiO+BamjJgVEBMoF43z1xIH PPQnUG4IwIjzh69uTL2epQDj+ukKXds+3O7uvnoMxNnus1YQqWjzZ6N1YWkJ7f15WJh+ OGhCLJo1jKPaiOFYF6FOpEZ6Cn+8CLN9UA/xQ1aB3IkrgObV7JmQohCpfqheMy58DLVi hUxwhKUmoC5FfmYHsHLcFZDNUB/l87nGYFcoH/Aed/+l3qBF17oBUS10lBG4vDq8oA9K VpYw== 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=r4btQlEg9Cw73pRrRyfSJh27tV3bVYw5dInehzsUjA0=; b=U21IOeYTHU5/E0i86K9mBjwRDyldjZj6+IoC+aEbJ8Wlj6XRTsb8vOnEXFUBtX06J5 gC+syUs40cybyk4JI9SvxRLOrJgjJ/6D4MfSoXjkI43JqnrpqiwTwlgjKZV+AYAG8wva LxavKysfA8TmoEKvR4SlIyHHT3iMUlxpE6aBS3WfMu50TkrCG1biMtYKKUoociHVe9Sd RJxoHc6QvTM6HjpKAM885QigKy1v2cIVGHnYzu3+LG6StetkWfg6/XuwbBEfkrHD2Nf3 2rbGCC5CeLf1l+bWUWtX+f/MomGbsSB2EAbgul/u5v40HYY892W9KA/9vW8dFoJ4CrK9 5+nQ== X-Gm-Message-State: APjAAAWgYxih9DTM/TGFJlh5BkQNmAvIed2HxaWMaJ4VO+8VnQY72mxq pDI85ANWHvkpt5GMD1kf01AkipkNcHk7a5IChvg= X-Google-Smtp-Source: APXvYqxC6kxNJuWlrcTd2+YMGezLOzp/XFtY6+MPVMcz/w95WmTkcoZZTMkrk3p5a5IRVAv8KSSzJl2eg7ftV3k5jaI= X-Received: by 2002:aca:f587:: with SMTP id t129mr1758075oih.143.1581398946858; Mon, 10 Feb 2020 21:29:06 -0800 (PST) MIME-Version: 1.0 References: <157432667505.28806.8545289298360479311.idtracker@ietfa.amsl.com> <4781_1574326974_5DD652BE_4781_95_8_D9FC72FE.6C3EC%dominique.barthel@orange.com> <21408_1580830289_5E398E51_21408_27_3_DA5F4B97.6FD52%dominique.barthel@orange.com> In-Reply-To: <21408_1580830289_5E398E51_21408_27_3_DA5F4B97.6FD52%dominique.barthel@orange.com> From: Abdussalam Baryun Date: Tue, 11 Feb 2020 07:28:14 +0200 Message-ID: To: dominique.barthel@orange.com Cc: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="00000000000079ca36059e462247" Archived-At: Subject: Re: [Roll] FW: New Version Notification for draft-ietf-roll-dis-modifications-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 05:29:10 -0000 --00000000000079ca36059e462247 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dominique, Ok, however, I think any new RFC needs to mention its update to previous, it's the user right not the IETF. AB On Tue, Feb 4, 2020 at 5:31 PM wrote: > Hello Abdussalam, > > Sorry to respond so late, your mail below became hidden under the pile-up > after IETF106. > You're right that draft-ietf-roll-dis-modifications-01.txt adds new > behaviour to 6550, and so it looks that it should update 6550. > However, we already knew we wanted to do dis-modifications at the time we > wrote 6550, therefore we put a sentence in there "unless a flag modifies > this behaviour". > I would therefore think that, formally, 6550 is not updated by > dis-modifications. > I will need to double check with our AD's on this, though. > Thanks for spotting this and letting us now! > Best regards, > > Dominique > > De : Roll on behalf of Abdussalam Baryun < > abdussalambaryun@gmail.com> > R=C3=A9pondre =C3=A0 : "roll@ietf.org" > Date : Monday 25 November 2019 07:43 > =C3=80 : "roll@ietf.org" > Objet : Re: [Roll] FW: New Version Notification for > draft-ietf-roll-dis-modifications-01.txt > > Hi > > I think this draft should update the RFC6550 but the draft did not mentio= n > updating, > > AB > > On Thu, Nov 21, 2019 at 11:03 AM wrote: > >> Hello all, >> >> In light of the current discussions on adding flags and generally >> improving the behavior of DIS messages, I've just republished the old >> dis-modifications draft with Informational status. >> The purpose is to provide the WG with the use cases that were described = in >> that draft. >> Except for the issue date and version, the draft is unchanged from -00. >> Best regards, >> >> Dominique >> >> Le 21/11/19 16:57, =C2=AB internet-drafts@ietf.org =C2=BB > > >> a =C3=A9crit : >> >> > >> >A new version of I-D, draft-ietf-roll-dis-modifications-01.txt >> >has been successfully submitted by Dominique Barthel and posted to the >> >IETF repository. >> > >> >Name: draft-ietf-roll-dis-modifications >> >Revision: 01 >> >Title: DIS Modifications >> >Document date: 2019-11-21 >> >Group: roll >> >Pages: 15 >> >URL: >> > >> https://www.ietf.org/internet-drafts/draft-ietf-roll-dis-modifications-0= 1 >> . >> >txt >> >Status: >> >https://datatracker.ietf.org/doc/draft-ietf-roll-dis-modifications/ >> >Htmlized: >> >https://tools.ietf.org/html/draft-ietf-roll-dis-modifications-01 >> >Htmlized: >> >https://datatracker.ietf.org/doc/html/draft-ietf-roll-dis-modifications >> >Diff: >> >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-dis-modifications-0= 1 >> > >> >Abstract: >> > This document augments RFC6550 with DIS flags and options that >> > allow a RPL node to better control how neighbor RPL routers respond >> > to its solicitation for DIOs. >> > >> > >> > >> > >> > >> >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 >> > >> >> >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --00000000000079ca36059e462247 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dominique,

Ok, however, I think any = new RFC needs to mention its update to previous, it's the user right no= t the IETF.

AB

On Tue, Feb 4, 2020 at 5:31 PM= <dominique.barthel@oran= ge.com> wrote:
Hello Abdussalam,

Sorry to respond so late, your mail below became hidden under the pile-up a= fter IETF106.
You're right that=C2=A0draft-ietf-roll-dis-modifications-01.txt adds new behaviour to 6550, and= so it looks that it should update 6550.
However, we already knew= we wanted to do dis-modifications at the time we wrote 6550, therefore we = put a sentence in there "unless a flag modifies this behaviour".<= /span>
I=C2=A0would therefore think that, form= ally, 6550 is not updated by=C2=A0dis= -modifications.
I will need to double check with our AD= 's on this, though.
Thanks for spotting this and letting us= now!
Best regards,

Dominique

De=C2=A0: Roll <roll-bounces@ietf.org> on= behalf of Abdussalam Baryun <abdussalambaryun@gmail.com>
R=C3=A9pondre =C3=A0=C2=A0: "<= a href=3D"mailto:roll@ietf.org" target=3D"_blank">roll@ietf.org" &= lt;roll@ietf.org>=
Date=C2=A0: Monday 25 November 2019= 07:43
=C3=80=C2=A0: "roll@ietf.org" <roll@ietf.org>
Objet=C2=A0: Re: [Roll] FW: New Ver= sion Notification for draft-ietf-roll-dis-modifications-01.txt

Hi

I think this draft=C2=A0should update the RFC6550 but the draft did no= t mention updating,

AB

On Thu, Nov 21, 2019 at 11:03 AM <= dominique= .barthel@orange.com> wrote:
Hello all,

In light of the current discussions on adding flags and generally
improving the behavior of DIS messages, I've just republished the old dis-modifications draft with Informational status.
The purpose is to provide the WG with the use cases that were described in<= br> that draft.
Except for the issue date and version, the draft is unchanged from -00.
Best regards,

Dominique

Le 21/11/19 16:57, =C2=AB internet-drafts@ietf.org =C2=BB <internet-drafts@ietf.org> a =C3=A9crit :

>
>A new version of I-D, draft-ietf-roll-dis-modifications-01.txt
>has been successfully submitted by Dominique Barthel and posted to the<= br> >IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-roll-dis-modificatio= ns
>Revision:=C2=A0 =C2=A0 =C2=A0 01
>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DIS Modifications
>Document date: 2019-11-21
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0roll
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015
>URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>https://www.ietf.org/in= ternet-drafts/draft-ietf-roll-dis-modifications-01.
>txt
>Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>https://datatracker.ietf.org/= doc/draft-ietf-roll-dis-modifications/
>Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0
>https://tools.ietf.org/html/draf= t-ietf-roll-dis-modifications-01
>Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0
>https://datatracker.ietf.= org/doc/html/draft-ietf-roll-dis-modifications
>Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>https://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-roll-dis-modifications-01
>
>Abstract:
>=C2=A0 =C2=A0This document augments RFC6550 with DIS flags and options = that
>=C2=A0 =C2=A0allow a RPL node to better control how neighbor RPL router= s respond
>=C2=A0 =C2=A0to its solicitation for DIOs.
>
>=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
>
>
>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
>


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

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

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--00000000000079ca36059e462247-- From nobody Tue Feb 11 02:25:42 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C01F1200B7 for ; Tue, 11 Feb 2020 02:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaRsn25gLmfU for ; Tue, 11 Feb 2020 02:25:38 -0800 (PST) Received: from zproxy130.enst.fr (zproxy130.enst.fr [137.194.2.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A85F1200A3 for ; Tue, 11 Feb 2020 02:25:38 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id DD2331213FA; Tue, 11 Feb 2020 11:25:32 +0100 (CET) Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id O5-3YwgkUzhM; Tue, 11 Feb 2020 11:25:31 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 9D5A0120F6C; Tue, 11 Feb 2020 11:25:31 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy130.enst.fr 9D5A0120F6C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1581416731; bh=qPsynnsdfDva3wK5eX/aIaRkhqbAqZ8tH21TE4c4sE0=; h=Mime-Version:From:Date:Message-Id:To; b=NGk6CelUTzuwsBPmTcQxSgm6ikPTmYS/+oOvmB7V9tOZkgZ3EBRx9TxAnZTX0qCOn S9VXKn/Yu4lhhQz7V6O6yR60cX6i3eg/y8qj/pVv+rp/cUzgVHWsL6YJJB+MeF0kmZ eTU3YWMtteTbZUtUBnkrHm9l5G1isI9ppEHrHGVM= X-Virus-Scanned: amavisd-new at zproxy130.enst.fr Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id WYB04z8XHOBF; Tue, 11 Feb 2020 11:25:31 +0100 (CET) Received: from [IPv6:2001:660:7301:3728:9ce0:1b70:7fe9:1c85] (unknown [IPv6:2001:660:7301:3728:9ce0:1b70:7fe9:1c85]) by zproxy130.enst.fr (Postfix) with ESMTPSA id 76DAE121413; Tue, 11 Feb 2020 11:25:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Georgios Z. Papadopoulos" In-Reply-To: Date: Tue, 11 Feb 2020 11:25:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rahul Jadhav , Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Roll] NSA PS-set metric/constraint X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 10:25:41 -0000 Dear Rahul and all, Once again, thank you for spotting this issue. Great catch!=20 We are happy with any of the following solutions :=20 - We can indeed tie the PS set metric to CAOF specifically in the draft. Furthermore, the policies in CAOF are extensible (we only specify = examples), so potentially another policy could make a different use of = PS as part of CAOF. - We can indeed explain the issue in the draft so that the implementers = decide on their own how to handle it. Additionally, since the whole RPL instance uses the same OF, we would = expect that if an OF which understands the TLV is used, then all the = nodes will know how to process it. So, this issue should not be very common. - Another option would be to add an exception to the "all TLVs need to = be propagated=E2=80=9D rule from RFC 6551 specifically for the PS TLV. The exception would specify that the PS TLV would be dropped if not = understood. Best regards, Georgios and Aris > On Feb 11, 2020, at 04:32, Rahul Jadhav wrote: >=20 > Hello Authors of NSA extn and all, >=20 > One more question in the context: >=20 > The draft adds new routing metrics/constraints (PS set) nested as part > of the NSA parent metric. >=20 > My question is with regards to what happens if this routing metric is > used outside of the CAOF. Any metrics/constraints could be used by any > OF and thus PS set metric defined by the draft can be used by other > OF. >=20 > RFC 6551 says that if the metric is not understood by the node and if > it is a 6LR then it may not process it but it has to propagate it. > Unlike other metrics, the PS set metric in this case contains > link-local values that cannot be used beyond link-local. As such upon > propagation, any downstream 6LR that understands the PS set metric > would use the information and get impacted adversely. >=20 > Should we tie the PS set metric to CAOF specifically in the draft, in > which case this problem won't be there? Or we can specify this issue > as it is for the readers to understand the problem if the PS set is > used outside of the CAOF. Either way works for me. >=20 > Best, > Rahul >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Feb 11 03:03:21 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B60AA1200D5; Tue, 11 Feb 2020 03:03:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <158141899764.20023.9579129113905839403@ietfa.amsl.com> Date: Tue, 11 Feb 2020 03:03:17 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 11:03:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : RPL Capabilities Authors : Rahul Arvind Jadhav Pascal Thubert Michael Richardson Rabi Narayan Sahoo Filename : draft-ietf-roll-capabilities-00.txt Pages : 15 Date : 2020-02-10 Abstract: This draft enables the discovery, advertisement and query of capabilities for RPL nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-capabilities-00 https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 11 20:57:25 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACE31200B4 for ; Tue, 11 Feb 2020 20:57:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 LlKczPBbf_yW for ; Tue, 11 Feb 2020 20:57:21 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 2FD57120089 for ; Tue, 11 Feb 2020 20:57:20 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id l18so621318lfc.1 for ; Tue, 11 Feb 2020 20:57:20 -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; bh=/OjKei+uPDMpNdq+28KwXRbSKF7p8yS1lKwh/51tsPA=; b=guTwMXrAga5Wpz5NUQUFAjnJIwsBmBq9NynUOdSSWGa+Dtan/5G8uCpYCQgPMF7hVa po0zWittQu6oCwjbRhBYrrhG1J+O8igp/rlM1u1QCmDew4A+u+QLnKLckBAYTWC02Sja 7MPdQgtkbIIk2mbLgiFzmC8k7V81EU9jWvpoz4sQcZKR4Dk/B9Xp+OBXCrKxfrZOyKry mxn6Hs3+k6uWMHaLKxPSFRyEsZ/TbbzGo5iX0zXa3TbaqMKxmKm8/9sy1UW0zqWPemOq sdZ3XoZxnbcuInSrml+QKxy5I/uZoA7GyzVX5OUE20Nvu2lJZT/W5S1CRsWaEDCE39BF GGAw== 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; bh=/OjKei+uPDMpNdq+28KwXRbSKF7p8yS1lKwh/51tsPA=; b=MgegapqKnbZMw7/f4X8jb5Nq2oTlCXIyVsCdAS+l9dt7Oe7nlrx6jWUrNijIAbNdwX ObyGGYq21AU0tOSUxnbUMuvcKNoiMaT30xv09D7WQ3gxTjJMihZr1sXxyxMqwcW0b0bs EPl9ZVNB1SOGJhMP4hBiGYNc8ALJdeKTM5N/rJwmKjk9PPA0RP1t6wgNAvYvcPY48TfD TZZIeALE7lywAA49xEplwv3MvrPnWjzkkUZT3e2RUBw2IuLQEG6Sce+yvQ3Veyvu6Dcw cwfGOV2Sgd81xNdOZCyrMrvViQTuJFAKz9l40LOKpmF5uuxT4YLht+4LvJIJHq1u5sac peIg== X-Gm-Message-State: APjAAAXyU7ThKpSytKueAvW4EYpEeIRzGt/wX46pAAuSbIxMnWCdBa8B W+0WMOQdw+QmgAASY1levwJMWx7IAZgOACBAJSIOCgrV X-Google-Smtp-Source: APXvYqzLiB5l2H2h/RGCxY31eaPORJQGENEah0YsBHyD65oGWwQtKRRYbSEYXVBITodPd7PLWlJhDWRv82jyVSND9zE= X-Received: by 2002:a19:c3c2:: with SMTP id t185mr5631933lff.56.1581483439054; Tue, 11 Feb 2020 20:57:19 -0800 (PST) MIME-Version: 1.0 References: <158141899764.20023.9579129113905839403@ietfa.amsl.com> In-Reply-To: <158141899764.20023.9579129113905839403@ietfa.amsl.com> From: Rahul Jadhav Date: Wed, 12 Feb 2020 10:27:07 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-capabilities-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 04:57:23 -0000 Dear All, This has a major update for caps. Also the split up of mopex and caps is now over. Updates to the capabilities draft are: 1. Addition of local/global capabilities 2. Addition of capabilities (nbr-cache info and routing table info) .. use-case could be P-DAO 3. Added Rabi as co-author. Thank you Rabi for the new text/experiments and thoughts on new caps that are added. 4. Removed sections related to mopex. Feedback is greatly appreciated. Thank you. Best, Rahul ---------- Forwarded message --------- From: Date: Tue, 11 Feb 2020 at 16:33 Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-00.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : RPL Capabilities Authors : Rahul Arvind Jadhav Pascal Thubert Michael Richardson Rabi Narayan Sahoo Filename : draft-ietf-roll-capabilities-00.txt Pages : 15 Date : 2020-02-10 Abstract: This draft enables the discovery, advertisement and query of capabilities for RPL nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-capabilities-00 https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Wed Feb 12 08:29:04 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1ADF120119; Wed, 12 Feb 2020 08:28:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <158152493986.17939.9129713670584890749@ietfa.amsl.com> Date: Wed, 12 Feb 2020 08:28:59 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-35.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 16:29:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane Authors : Maria Ines Robles Michael C. Richardson Pascal Thubert Filename : draft-ietf-roll-useofrplinfo-35.txt Pages : 58 Date : 2020-02-12 Abstract: This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC6553 (RPI Option Type), RFC6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC6553 adding a change to the RPI Option Type. Additionally, this document updates RFC6550 defining a flag in the DIO Configuration Option to indicate about this change and updates RFC8138 as well to consider the new Option Type when the RPL Option is decompressed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-35 https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-35 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-35 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 20 01:16:49 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC401200D8 for ; Thu, 20 Feb 2020 01:16:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 uvZ1OanHniUo for ; Thu, 20 Feb 2020 01:16:45 -0800 (PST) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 3BFE81200CD for ; Thu, 20 Feb 2020 01:16:45 -0800 (PST) Received: by mail-vk1-xa30.google.com with SMTP id o187so986209vka.2 for ; Thu, 20 Feb 2020 01:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=t7foaHHxU10TnJc7qsVkGhiRzmwy4pwlNr4Hehn9Mdo=; b=lxzQ2GmkhP8yRNFGLysSb9Bk/a0zgLWArtNcWrcalS/XAuxHdX29qZYY57g+wwF73I xaq7gDI7dw8HvqicANNLFJzNgR8ff6OGu+6miEEVOEeEON4KFqQ5OU3OLhmK6gdNlFm4 CgE+/8GMHUY/4jq+EQbjLU2S4bxh3ddDMv8KIEjoPjXsAx3FYB/zGSYfMgRLMa++0B1e Pyx8D32GSQh588ujOQGSTkBmkuJadLsadVlvWCOnmgpKTWZmeTjfnPuQu6tvk4P6EmuJ YLGB2SN1iOgtFfsTfHmmHdcIFzmrHGtc5vREHUDVJ3OySL79Y9lC8P54/R9g2x++eKXJ 82iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=t7foaHHxU10TnJc7qsVkGhiRzmwy4pwlNr4Hehn9Mdo=; b=TxJtAoOS60SypZM1s3PpCrLlpdVAP9hS54XsnOKKQKu+4QVw08uklL/L+aYVT2xnm1 ri6x1lTQJy05tRoISP+/DQHHicIHug3/zIBr3GfJXdSi7TDGYsoJE0RV3BZ+8VU37oRK fnY7up4300uudfpo9p6djHymohVY2P9mzs3yKVjb9vz58nF6uOpWApSN7LB3RHXlpE1a 1z5kWmX2WF+mWEDcqEYW5UDAqXlag/CnevCnH/leUrFwR6jtqaxUZumiaYhAtTx1MsQV m/vwGWhJpV4ec79ouJVyOq3Q8sACWoIG97N35ssHBLqxLATOwSXqBihPk0AckhmwGwGk K85w== X-Gm-Message-State: APjAAAWM5diEWfQBjHtQU94iHnKDGyhdQfbDV+fgOuT/ifuMmtytnZL7 BEaBlKW15AbJzFBPLeLdtRgVjczK+TW8GvyZ5kMB4O1B X-Google-Smtp-Source: APXvYqxbpkm1HrwBapUKrqcJk21JSR8rVAfPCgWRBJszkCrqpXvYB6JWnluJNBcuyoFbxQ41qhk/bg0fD4WGGu8VUkU= X-Received: by 2002:a1f:94c1:: with SMTP id w184mr13910174vkd.43.1582190203875; Thu, 20 Feb 2020 01:16:43 -0800 (PST) MIME-Version: 1.0 From: Ines Robles Date: Thu, 20 Feb 2020 11:16:08 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000011b54d059efe5d62" Archived-At: Subject: [Roll] WGLC on draft-ietf-roll-turnon-rfc8138-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 09:16:47 -0000 --00000000000011b54d059efe5d62 Content-Type: text/plain; charset="UTF-8" Dear all, This is a Working Group Last call for draft-ietf-roll-turnon-rfc8138-04 Please send your comments by 5th March 2020 Thank you very much in advance, Ines and Dominique. --00000000000011b54d059efe5d62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

This is a Working Group Last = call for=C2=A0draft-ietf-roll-turnon-rfc8138-04

Pl= ease send your comments by 5th March 2020

Thank yo= u very much in advance,

Ines and Dominique.
<= /div> --00000000000011b54d059efe5d62-- From nobody Fri Feb 21 22:30:48 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358E5120123; Fri, 21 Feb 2020 22:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 YAyPmPWX_KsE; Fri, 21 Feb 2020 22:30:14 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A109120128; Fri, 21 Feb 2020 22:30:14 -0800 (PST) Received: from [172.16.42.113] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48PdXB1cH1z107v; Sat, 22 Feb 2020 07:22:02 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 604045322.066431-4ce443627516f3d418b8c75cbd345883 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: <4916CC37-1BA8-4E96-A391-0AC9BB68BF2F@tzi.org> Date: Sat, 22 Feb 2020 07:22:02 +0100 To: 6lo@ietf.org, 6tisch@ietf.org, lp-wan@ietf.org, lwip@ietf.org, roll@ietf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Roll] Constrained Node/Network Cluster @ IETF107: DRAFT AGENDA X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 06:30:18 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF107. Remember that there is still quite some potential for changes. Conflicts that meet the eye: ROLL vs. COSE/TEEP, LPWAN vs. RATS, and LAKE vs. RATS, WPACK vs. ACE. The latter two might be a bigger problem, while the first two are displaying the inevitable split between security vs. other IoT issues, as is MODEL-T vs. CORE and TXAUTH vs. T2TRG. All times are in PDT =3D=3D UTC - 7 hours. Note that North America is = on DST already during the IETF, while Europe will only go there on March 29, so we are in the three-week period of DST confusion (where the US is one hour closer to the EU than the rest of the year). (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, March 20, 2020 0900-1800 T2TRG/W3C WoT Workshop = https://github.com/t2trg/2020-03-vancouver SATURDAY, March 21, 2020 0830-2200 IETF Hackathon - Plaza Ballroom SUNDAY, March 22, 2020 0830-1600 IETF Hackathon - Plaza Ballroom 1700-1900 Welcome Reception - Regency A/B/C/D 1800-2000 Hot RFC Lightning Talks -- Plaza B/C MONDAY, March 23, 2020 1000-1200 Morning Session I Regency D ART dispatch Dispatch WG - Joint with ARTAREA Regency C INT 6man IPv6 Maintenance WG Plaza B/C IRTF pearg Privacy Enhancements and Assessments = Research Group Regency E SEC *** suit Software Updates for Internet of Things = WG 1330-1530 Afternoon Session I Regency C INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Regency D IRTF irtfopen IRTF Open Meeting Georgia A SEC mls Messaging Layer Security WG Georgia B SEC oauth Web Authorization Protocol WG Plaza A SEC *** rats Remote ATtestation ProcedureS WG 1550-1750 Afternoon Session II Regency F ART webtrans WebTransport WG Regency C IRTF maprg Measurement and Analysis for Protocols Regency E OPS anima Autonomic Networking Integrated Model = and Approach WG Plaza A RTG raw Reliable and Available Wireless WG Plaza B/C SEC secdispatch Security Dispatch WG 1810-1910 Afternoon Session III Georgia A RTG *** roll Routing Over Low power and Lossy = networks WG Georgia B SEC *** cose CBOR Object Signing and Encryption WG Plaza B/C SEC tls Transport Layer Security WG Regency C TSV tsvarea Transport Area Open Meeting TUESDAY, March 24, 2020 1000-1200 Morning Session I Georgia A INT add Adaptive DNS Discovery WG Regency D IRTF*** dinrg Decentralized Internet Infrastructure Regency F SEC acme Automated Certificate Management = Environment WG Regency E SEC *** teep Trusted Execution Environment = Provisioning WG Plaza B/C TSV quic QUIC WG 1330-1530 Afternoon Session I Regency C INT masque Multiplexed Application Substrate over = QUIC Encryption BOF Regency D IRTF coinrg Computing in the Network Research Group Georgia B RTG *** roll Routing Over Low power and Lossy = networks WG Georgia A SEC emu EAP Method Update WG Plaza A SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1720 Afternoon Session II Regency F ART *** core Constrained RESTful Environments WG Plaza A IRTF qirg Quantum Internet Proposed Research Group Georgia B SEC oauth Web Authorization Protocol WG Regency C TSV tsvwg Transport Area Working Group WG 1740-1840 Afternoon Session III Plaza B/C INT 6man IPv6 Maintenance WG Georgia A RTG babel Babel routing protocol WG Regency D RTG detnet Deterministic Networking WG Regency E RTG rift Routing In Fat Trees WG Regency C TSV quic QUIC WG WEDNESDAY, March 25, 2020 0830-0945 Side Meetings / Open Time Regency C tdd Technology Deep Dive 1000-1200 Morning Session I Regency F IRTF*** t2trg Thing-to-Thing Georgia B RTG bier Bit Indexed Explicit Replication WG Regency D SEC txauth Transactional Authorization and = Delegation BOF Regency C TSV quic QUIC WG 1330-1500 Afternoon Session I Regency C ART wpack Web Packaging BOF Regency E IRTF panrg Path Aware Networking RG Georgia A SEC *** ace Authentication and Authorization for = Constrained Environments WG 1520-1650 Afternoon Session II Georgia A model-t Internet Threat Model Plaza A ART *** core Constrained RESTful Environments WG Plaza B/C RTG rtgarea Routing Area Open Meeting 1710-1940 IETF Plenary - Regency C/D/E/F THURSDAY, March 26, 2020 1000-1200 Morning Session I Georgia A ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Georgia B INT dnssd Extensions for Scalable DNS Service = Discovery WG - Joint with HOMENET Georgia B INT homenet Home Networking WG - Joint with DNSSD Regency E IRTF icnrg Information-Centric Networking Regency C SEC privacypass privacy-pass BOF Plaza B/C TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session I Regency F OPS v6ops IPv6 Operations WG Regency D SEC saag Security Area Open Meeting Georgia B TSV taps Transport Services WG 1550-1720 Afternoon Session II Regency C ART httpbis HTTP WG Regency F INT intarea Internet Area Working Group WG Regency E IRTF cfrg Crypto Forum Plaza B/C RTG detnet Deterministic Networking WG 1740-1840 Afternoon Session III Regency E ART uta Using TLS in Applications WG Georgia B INT *** drip Drone Remote ID Protocol WG Regency D OPS anima Autonomic Networking Integrated Model = and Approach WG FRIDAY, March 27, 2020 1000-1200 Morning Session I Plaza B/C INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Regency C SEC tls Transport Layer Security WG 1220-1350 Morning Session II Regency D ART httpbis HTTP WG Regency C IRTF coinrg Computing in the Network Research Group Regency F SEC *** lake Lightweight Authenticated Key Exchange = WG Georgia A SEC *** rats Remote ATtestation ProcedureS WG From nobody Mon Feb 24 08:52:41 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0483A0E2E for ; Mon, 24 Feb 2020 08:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 wyYi0mGx_M4r for ; Mon, 24 Feb 2020 08:52:38 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5363A0E2D for ; Mon, 24 Feb 2020 08:52:37 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 48R7Qr3p72z5vbs for ; Mon, 24 Feb 2020 17:52:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582563156; bh=x+blafirgkfTwSjPFtXxX37u3h+WFofMSj+tU1+fEeE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=QqoZzFTDIs7+yc3GjzMFWA/qdwBfQ1OrFMA6jCboeTkM93+IYHa5kAw9R8mJaZCzS XGUIEYWOU2hqtE7X2u7D/TnObE/FXAdLnkBoW/gR7IEKTzcovtsvV0hBGXXWha8Ron V6gLzdck3WOWDgrUDDYCWdlm4Iug1eVWbw8EvT+sElNRDebDLdGDewVky4jM5frBcR u7Fto9U5MucL/GfYqesn1pOeiMtV4uBjW24aT6IXm7OxQQ+UWJt+lTn3k519DNvU5t aRXt/9pD3bSKkcpCv0v6B93GVF02hr8kDCDL0BukAidndi6o0WenGnkYGEORhP6vH0 uTdmX5Yb7Dwsw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 48R7Qr38x1zDq8f for ; Mon, 24 Feb 2020 17:52:36 +0100 (CET) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Mon, 24 Feb 2020 17:52:36 +0100 From: To: Routing Over Low power and Lossy networks Thread-Topic: DIS-modifications use cases; Re: [Roll] FW: New Version Notification for draft-ietf-roll-dis-modifications-01.txt Thread-Index: AQHV6zLQHIdrCLpGkUuqqhGBAYzOMQ== Date: Mon, 24 Feb 2020 16:52:35 +0000 Message-ID: <25671_1582563156_5E53FF54_25671_231_1_DA79B8DE.70E40%dominique.barthel@orange.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-ID: <52CAB63F5CD15D4A86B81B3DAF149E46@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Roll] DIS-modifications use cases; Re: FW: New Version Notification for draft-ietf-roll-dis-modifications-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 16:52:40 -0000 RGVhciBSb2xsZXJzLA0KDQpJbiBwcmVwYXJhdGlvbiBmb3IgdGhlIG1vZGlmaWNhdGlvbiBvZiB0 aGUgRElTIChET0RBRyBJbmZvcm1hdGlvbg0KU29saWNpdGF0aW9uKSwgd2UgYXJlIGNvbGxlY3Rp bmcgdGhlIHVzZSBjYXNlcy4NCldlIHdhbnQgdG8gbWFrZSBzdXJlIHdlIHVuZGVyc3RhbmQgYWxs IHRoZSByZXF1aXJlbWVudHMgYmVmb3JlIGNyYWZ0aW5nIGENCnNvbHV0aW9uLg0KR2Vvcmdpb3Mg aGFzIGtpbmRseSBwcmVwYXJlZCBhIGRvY3VtZW50IG9uIHRoZSBST0xMIEdpdEh1YiByZXBvLg0K U2VlIGEgdGV4dCByZW5kaXRpb24gYXQNCmh0dHBzOi8vZ2l0aHViLmNvbS9yb2xsLXdnL3JvbGwt ZGlzLW1vZGlmaWNhdGlvbnMtdXNlLWNhc2VzL2Jsb2IvbWFzdGVyL2RyYQ0KZnQtcGFwYWRvcG91 bG9zLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMtdXNlLWNhc2VzLnR4dA0KQ3VycmVudGx5LCB0aGUg ZG9jdW1lbnQgaGFzIHR3byB1c2UgY2FzZXM6DQotIGEgbmV3IG5vZGUgam9pbnMgYW4gZXN0YWJs aXNoZWQgUlBMIG5ldHdvcmsuIFRoZSB1c2UgY2FzZSBjYWxscyBmb3IgYQ0KZmFpcmx5IHF1aWNr IGNvbmZpcm1hdGlvbiB0aGF0IHRoZSBub2RlIGhhcyBqb2luZWQgd2l0aCBhIGdvb2QgcXVhbGl0 eQ0KcGF0aC4gSG93ZXZlciwgd2UgZG9uJ3Qgd2FudCB0byByZXNldCB0aGUgVHJpY2tsZSB0aW1l cnMgb2YgYWxsIG5lYXJieQ0Kcm91dGVycyBhbmQgdHJpZ2dlciBicm9hZGNhc3QsIHNpbmNlIHRo ZSB1c2UgY2FzZSBpcyB0aGF0IGp1c3Qgb25lIG5ldw0Kbm9kZSB3YXMgYWRkZWQvcmVwbGFjZWQv cmVib290ZWQuDQotIGFub3RoZXIgdXNlIGNhc2UgaXMgdGhhdCBzZXZlcmFsIG5vZGVzIGpvaW4g YXQgYWJvdXQgdGhlIHNhbWUgdGltZSAoZS5nLg0KZWxlY3RyaWNpdHkgbWV0ZXJzIGFsbCByZWJv b3QgZm9sbG93aW5nIHBvd2VyIG91dGFnZSkuIFdlIHdhbnQgdGhlIERJT3MgdG8NCmJlIHNlbnQg d2l0aCBicm9hZGNhc3Qgc28gdGhhdCBhbGwgam9pbmluZyBub2RlcyBiZW5lZml0IGZyb20gdGhl bS4NClRoZSBkcmFmdCBkcmFmdC10aHViZXJ0LXJvbGwtZWxpZGluZy1kaW8taW5mb3JtYXRpb24t MDMgaGFzIGFub3RoZXINCnJlcXVlc3QgZm9yIG1vZGlmeWluZyB0aGUgRElTLiBXZSdsbCBzb29u IGluY29ycG9yYXRlIGl0IGludG8gdGhlIHVzZQ0KY2FzZXMgZG9jdW1lbnQuDQpJZiB5b3UgaGF2 ZSB5ZXQgYW5vdGhlciBuZWVkIGZvciBtb2RpZmljYXRpb25zIGluIHRoZSBESVMsIHBsZWFzZSB0 ZWxsIHVzDQp3aGF0IHRoZSB1c2UgY2FzZSBpcy4NClRoZSBpbnRlbnQgaXMgdG8gcHVibGlzaCB0 aGUgZHJhZnQgaW4gdGltZSBmb3IgcHJlc2VudGF0aW9uL2Rpc2N1c3Npb24gYXQNClZhbmNvdXZl ci4NClRoYW5rcw0KDQpEb21pbmlxdWUNCg0KTGUgMjEvMTEvMTkgMTc6MDIsIMKrIFJvbGwgb24g YmVoYWxmIG9mIGRvbWluaXF1ZS5iYXJ0aGVsQG9yYW5nZS5jb20gwrsNCjxyb2xsLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIGRvbWluaXF1ZS5iYXJ0aGVsQG9yYW5nZS5jb20+IGEgw6lj cml0IDoNCg0KPkhlbGxvIGFsbCwNCj4NCj5JbiBsaWdodCBvZiB0aGUgY3VycmVudCBkaXNjdXNz aW9ucyBvbiBhZGRpbmcgZmxhZ3MgYW5kIGdlbmVyYWxseQ0KPmltcHJvdmluZyB0aGUgYmVoYXZp b3Igb2YgRElTIG1lc3NhZ2VzLCBJJ3ZlIGp1c3QgcmVwdWJsaXNoZWQgdGhlIG9sZA0KPmRpcy1t b2RpZmljYXRpb25zIGRyYWZ0IHdpdGggSW5mb3JtYXRpb25hbCBzdGF0dXMuDQo+VGhlIHB1cnBv c2UgaXMgdG8gcHJvdmlkZSB0aGUgV0cgd2l0aCB0aGUgdXNlIGNhc2VzIHRoYXQgd2VyZSBkZXNj cmliZWQgaW4NCj50aGF0IGRyYWZ0Lg0KPkV4Y2VwdCBmb3IgdGhlIGlzc3VlIGRhdGUgYW5kIHZl cnNpb24sIHRoZSBkcmFmdCBpcyB1bmNoYW5nZWQgZnJvbSAtMDAuDQo+QmVzdCByZWdhcmRzLA0K Pg0KPkRvbWluaXF1ZQ0KPg0KPkxlIDIxLzExLzE5IDE2OjU3LCDCqyBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgwrsgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj5hIMOpY3JpdCA6DQo+DQo+ Pg0KPj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1yb2xsLWRpcy1tb2RpZmljYXRp b25zLTAxLnR4dA0KPj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERvbWluaXF1 ZSBCYXJ0aGVsIGFuZCBwb3N0ZWQgdG8gdGhlDQo+PklFVEYgcmVwb3NpdG9yeS4NCj4+DQo+Pk5h bWU6CQlkcmFmdC1pZXRmLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMNCj4+UmV2aXNpb246CTAxDQo+ PlRpdGxlOgkJRElTIE1vZGlmaWNhdGlvbnMNCj4+RG9jdW1lbnQgZGF0ZToJMjAxOS0xMS0yMQ0K Pj5Hcm91cDoJCXJvbGwNCj4+UGFnZXM6CQkxNQ0KPj5VUkw6ICAgICAgICAgICAgDQo+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXJvbGwtZGlzLW1vZGlm aWNhdGlvbnMtMDENCj4+Lg0KPj50eHQNCj4+U3RhdHVzOiAgICAgICAgIA0KPj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMv DQo+Pkh0bWxpemVkOiAgICAgICANCj4+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcm9sbC1kaXMtbW9kaWZpY2F0aW9ucy0wMQ0KPj5IdG1saXplZDogICAgICAgDQo+Pmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWRpcy1t b2RpZmljYXRpb25zDQo+PkRpZmY6ICAgICAgICAgICANCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcm9sbC1kaXMtbW9kaWZpY2F0aW9ucy0wMQ0KPj4NCj4+ QWJzdHJhY3Q6DQo+PiAgIFRoaXMgZG9jdW1lbnQgYXVnbWVudHMgUkZDNjU1MCB3aXRoIERJUyBm bGFncyBhbmQgb3B0aW9ucyB0aGF0DQo+PiAgIGFsbG93IGEgUlBMIG5vZGUgdG8gYmV0dGVyIGNv bnRyb2wgaG93IG5laWdoYm9yIFJQTCByb3V0ZXJzIHJlc3BvbmQNCj4+ICAgdG8gaXRzIHNvbGlj aXRhdGlvbiBmb3IgRElPcy4NCj4+DQo+PiAgICAgICAgICAgICAgICAgDQo+PiAgICAgICAgDQo+ Pg0KPj4NCj4+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2YNCj4+c3VibWlzc2lvbg0KPj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4NCj4+VGhl IElFVEYgU2VjcmV0YXJpYXQNCj4+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0K PmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+cGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleg0KPnJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcg0KPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KPmVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwNCj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZQ0KPm91IGZhbHNpZmllLiBNZXJjaS4NCj4N Cj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZA0KPmluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7DQo+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uDQo+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KPmRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4NCj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUNCj5iZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4NCj5UaGFuayB5b3UuDQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Sb2xsIG1haWxpbmcgbGlzdA0KPlJvbGxAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg0KCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Feb 24 21:03:42 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D15B3A09B5 for ; Mon, 24 Feb 2020 21:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 paXyVd9pQzTc for ; Mon, 24 Feb 2020 21:03:38 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 19BA93A09B4 for ; Mon, 24 Feb 2020 21:03:38 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id f24so8662581lfh.3 for ; Mon, 24 Feb 2020 21:03:38 -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; bh=XQfZjzSrWb5N+93u/fSg+j8aue3Q6Cr7NpMv06KXgtY=; b=QHZoNLF/2SkHFTleFdJ3gB2yiTpYtCB/Ld+ygXEQmGC2Ce3pvwYv38DKDQgfmsrTEd 0cWTyXt/Nzy1OQz94imQt8g4oSmki2cuqpvughxUerc74UcEA+VNwQRXrXiT5PIInWZz /r/MkOP8XZ7oOOPvyJ8t8mBqtVlTsXK3HxCjfuiKsq0TndrqC79URWDEcxxtUwn80TVX MOKTZEFDKSTQnQZWyVg+NI4AwVOjNzeqtFTNo4n737Gcp11mbAwfz8wE25iTlEDzQdAf EGiuZKFzoBW9dKYjRTEi3GpuNu79/nKQiBjs0eEBS+6+/lrtJ/QcrUWhzRIsLVBwjVJE 7cug== 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; bh=XQfZjzSrWb5N+93u/fSg+j8aue3Q6Cr7NpMv06KXgtY=; b=k5K/emkBJw8iW8T7odW8vje9YFR+RWjph51K0vSMI2F8mUHinzhjpDVINyIGPDKmgZ ahLI47fpIEY93E4lhDmjgnSiQ9Izf3FCuF/pN2n6LfBfBLdJtIwhL5ZiGXhPpkcaqpCN 0QhxF9LbCBgD/Hj3KjfODCjw0l52jVheQ0GDSzkxpimfEbGPZ2eby3wAz4H50Qbdoyj1 k3MJiYtVIRzWbZj+2x87mwfI0WUmhZ8HNK7Oo+KEku1YZNN2X9409SVd95XqPv0RiMLe 7B5GG6UqmWI+qWD9qvdmv1x+A5jm0nHla7LW+nNpkBTNRAB4mOjqTXKOZ9VCtywpctRr 0kHg== X-Gm-Message-State: APjAAAVRMNuDgsbY6ADiylZYRir2pplKelPZ6P96tzxE6Iy22D39MgKA UY5wyWq4Lby9wGzMQL89w/KLq1NJP29gt0spjzzf0Xtx X-Google-Smtp-Source: APXvYqwhhJZja+PUqYxGuDXQC5zy/3hqSUsPyRwcIz0y1L//iQwBBWhgj2nHd++GWIIHVOXcBuXQJCb45Pakgw8pFiU= X-Received: by 2002:a19:6d13:: with SMTP id i19mr28409965lfc.6.1582607015861; Mon, 24 Feb 2020 21:03:35 -0800 (PST) MIME-Version: 1.0 References: <25979.1576604888@localhost> <9584.1577428097@localhost> In-Reply-To: From: Rahul Jadhav Date: Tue, 25 Feb 2020 10:33:24 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000ffe496059f5f686c" Archived-At: Subject: Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 05:03:41 -0000 --000000000000ffe496059f5f686c Content-Type: text/plain; charset="UTF-8" I would like to summarize this discussion and mention the action points. 1. ND status as part of RPL status: a) What we have right now? Ans: 8-bit ND status to be carried in LSB 6-bit RPL status. Though RPL status is 8-bit as per 6550, the unaware-leaves draft updates this field's two MSBs to carry flags, thus leaving 6-bits for carrying ND status. b) What could be the problem with this? Ans: Stuffing 8-bit status to 6-bit is possible today because the ND status allocations are very few and as of now it looks as if reaching values >=64 might not happen anytime soon. Anyways the problem is how would 6man/6lo know that RPL limits the range of the ND Status. Thus we need 6man/6lo to be informed. c) Action Point? Ans: Limiting ND status code to 64 values needs to be informed to 6man/6lo through an update. 2. RPL status code for DCO (currently 130) RPL Status code of 130 in DCO indicates that the address has moved i.e., somewhere below/downstream in the sub-dodag the target has changed parents. It was discussed that 130 may not be an appropriate value but when I checked again it seems all right. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |E|A| Value | +-+-+-+-+-+-+-+-+ 130 == 1000 0010 The E bit is set indicate rejection and A bit is unset to indicate non-ND value. Thus 130 seems to be the right value. Action Point? No change if this rationale is correct. Am I missing something here? Any comments? Regards, Rahul On Sat, 28 Dec 2019 at 12:36, Rahul Jadhav wrote: > On Fri, 27 Dec 2019 at 11:58, Michael Richardson > wrote: > > > > > > Rahul Jadhav wrote: > > >> > > You mean that we could change the ND status to 6-bits in the > 6lo > > >> WG? > (I would have parsed ND status as being someing 6man takes > care > > >> of) > > >> > > >> Yes, or mandate that the 64 first Status values are reserved for > stuff > > >> that could be carried in RPL > > >> > > > > RJ> Wondering how such a mandate would work. IF we do it this way, > > RJ> future extensions to ND ARO status need to consider whether they > are > > RJ> applicable to RPL and define accordingly. This implies > familiarity in > > RJ> 6lo/6MAN with RPL. > > > > > I prefer the other approach where we restrict the ND ARO status to > > > 64bits itself. Anyways using 128 bits in the future seems > far-fetched > > > (as indicated by Pascal before). But to limit ND ARO status to > 64bits > > > we need to convince the 6lo/6MAN group that "because of RPL" we > need to > > > reduce the size. I am not sure if this is easy to digest! > > > > I thought that we had 6-bits to store 64-values, while ND has 8-bits to > store > > 256 values. Please correct me if I mis-understood. > > > > [RJ] Currently ND has 8bits to store 256 values ... RPL needs to carry > the same 8-bits but currently it has space only for 6-bits in RPL > Status field. But as of now only few values of ND status has been used > and using up 256 values (or for that matter 64 values) seem > far-stretched. > Thus one of the opinions is to limit the ND status to 64-bits and > carry as-is in the RPL status. > --000000000000ffe496059f5f686c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to summarize this discussion and mention the = action points.

1. ND status as part of RPL status:
a) What we hav= e right now?
Ans: 8-bit ND status to be carried in LSB 6-bit RPL status.= Though RPL status is 8-bit as per 6550, the unaware-leaves draft updates t= his field's two MSBs to carry flags, thus leaving 6-bits for carrying N= D status.
b) What could be the problem with this?
Ans: =C2=A0Stuffing= 8-bit status to 6-bit is possible today because the ND status allocations = are very few and as of now it looks as if reaching values >=3D64 might n= ot happen anytime soon. Anyways the problem is how would 6man/6lo know that= RPL limits the range of the ND Status. Thus we need 6man/6lo to be informe= d.
c) Action Point?
Ans: Limiting ND status code to 64 values needs t= o be informed to 6man/6lo through an update.

2. RPL status code for = DCO (currently 130)
RPL Status code of 130 in DCO indicates that the add= ress has moved i.e., somewhere below/downstream in the sub-dodag the target= has changed parents.
It was discussed that 130 may not be an appro= priate value but when I checked again it seems all right.

=C2=A00
=C2=A00 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|E|= A| =C2=A0Value =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+
130 =3D=3D=C2=A01000 0010=C2=A0
The E = bit is set indicate rejection and A bit is unset to indicate non-ND value.<= /span>
Thus 130 seems to be the right value.
Action Poi= nt? No change if this rationale is correct.

Am I m= issing something here? Any comments?

Regards,
Rahul


On Sat, 28 Dec 2019 at 12:36, Rahul Jadhav <rahul.ietf@gmail.com> wrote:
On Fri, 27 Dec 2019 at 11:5= 8, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
>
> Rahul Jadhav <rahul.ietf@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>> > > You mean that we could change th= e ND status to 6-bits in the 6lo
>=C2=A0 =C2=A0 =C2=A0>> WG?=C2=A0 > (I would have parsed ND sta= tus as being someing 6man takes care
>=C2=A0 =C2=A0 =C2=A0>> of)
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Yes, or mandate that the 64 first Status v= alues are reserved for stuff
>=C2=A0 =C2=A0 =C2=A0>> that could be carried in RPL
>=C2=A0 =C2=A0 =C2=A0>>
>
>=C2=A0 =C2=A0 =C2=A0RJ> Wondering how such a mandate would work. IF = we do it this way,
>=C2=A0 =C2=A0 =C2=A0RJ> future extensions to ND ARO status need to c= onsider whether they are
>=C2=A0 =C2=A0 =C2=A0RJ> applicable to RPL and define accordingly. Th= is implies familiarity in
>=C2=A0 =C2=A0 =C2=A0RJ> 6lo/6MAN with RPL.
>
>=C2=A0 =C2=A0 =C2=A0> I prefer the other approach where we restrict = the ND ARO status to
>=C2=A0 =C2=A0 =C2=A0> 64bits itself. Anyways using 128 bits in the f= uture seems far-fetched
>=C2=A0 =C2=A0 =C2=A0> (as indicated by Pascal before). But to limit = ND ARO status to 64bits
>=C2=A0 =C2=A0 =C2=A0> we need to convince the 6lo/6MAN group that &q= uot;because of RPL" we need to
>=C2=A0 =C2=A0 =C2=A0> reduce the size. I am not sure if this is easy= to digest!
>
> I thought that we had 6-bits to store 64-values, while ND has 8-bits t= o store
> 256 values.=C2=A0 Please correct me if I mis-understood.
>

[RJ] Currently ND has 8bits to store 256 values ... RPL needs to carry
the same 8-bits but currently it has space only for 6-bits in RPL
Status field. But as of now only few values of ND status has been used
and using up 256 values (or for that matter 64 values) seem
far-stretched.
Thus one of the opinions is to limit the ND status to 64-bits and
carry as-is in the RPL status.
--000000000000ffe496059f5f686c-- From nobody Mon Feb 24 21:38:45 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989053A0A43 for ; Mon, 24 Feb 2020 21:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RlY411MgQo94 for ; Mon, 24 Feb 2020 21:38:41 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 834693A0A42 for ; Mon, 24 Feb 2020 21:38:41 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id 83so8688608lfh.9 for ; Mon, 24 Feb 2020 21:38:41 -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; bh=UeMofMx0dpSn5k5HhUZu0mhmtGP6iEBCVXbf2ZSuz24=; b=CMu3zpXvJlFOX0vjl3fWw/BzBH/1movIJbx2XSjPcrkUQvFesYcM4pAOKBmGMcLNEU FCu0O2Wypn77olP/QEBaBRNVL4fJZcgsPOvf+eCLhd6PKqqCEO9IlD8ZSzO8Ll/9+P+/ 9t/rtUuCBmEwjBFAUEKKgh+NQOFmxnZvUWNl7y1PCXy4j/2PHitGR5SKoVqpmR1LML69 20z/FMuDmj4DtVRN0sOOwHhKLji4aGZ6sWw4S8DRZQ75v6FT6D53/ye+rPsUyxd4rSZt i8y++mSa/WyMJ7+yCK3ymELh2YZqQiCigDOZ6Jt2LmnXENyLY2vfqr0Q7GpC5q92GJVZ gSeg== 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; bh=UeMofMx0dpSn5k5HhUZu0mhmtGP6iEBCVXbf2ZSuz24=; b=ilynL3D3+wVKADIKnzOxR/b596MiN+VGr71yViOcW98Nv97p4J1qYhNS0d9kl3f1lv OBgBHWm6nApAIhe2i0/Zr/Aagm6lezyyuVKaivs2Pi9YqUpGXYlcMhf4ZQjvDLI+RGRt J9v8b4xTTyF05emC2fvDNu12GQwli3qXZhzOHa9JsSB3ul6K/VKN4M7/1smO/bV0vfT0 5whwYY8M/Lhu4sJnteNyaXCCiaJfGve3Wdu5oUDQRkbFy2jR5y6B01TvF32HWI8FL2AR SRwbxsYfXCilPAOJA56SVk36Yv3r/29vjNfRhh1heysTEdAQkhv942oWsqyD2wQn6Fbq DaEw== X-Gm-Message-State: APjAAAVCW1ce0RhjUN01caoDhRvhTZsnuIIWg7Gl0haZ4ORo38+JLVkq IpU3pMiCxg/NMgV9J8RPwGehuvaonOOBo44YjVnsvg== X-Google-Smtp-Source: APXvYqxEOh0IVsi3rwBSYSke9TqQYeCmrGfBec8Ft63pdwD03BAtdQc0AdrMLfRNy0H63mBqk0Nw8CY9RTj2jk0wVTc= X-Received: by 2002:a05:6512:304d:: with SMTP id b13mr3563632lfb.134.1582609119396; Mon, 24 Feb 2020 21:38:39 -0800 (PST) MIME-Version: 1.0 References: <25671_1582563156_5E53FF54_25671_231_1_DA79B8DE.70E40%dominique.barthel@orange.com> In-Reply-To: <25671_1582563156_5E53FF54_25671_231_1_DA79B8DE.70E40%dominique.barthel@orange.com> From: Rahul Jadhav Date: Tue, 25 Feb 2020 11:08:27 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="00000000000061462a059f5fe6af" Archived-At: Subject: Re: [Roll] DIS-modifications use cases; Re: FW: New Version Notification for draft-ietf-roll-dis-modifications-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 05:38:44 -0000 --00000000000061462a059f5fe6af Content-Type: text/plain; charset="UTF-8" On Mon, 24 Feb 2020 at 22:22, wrote: > Dear Rollers, > > In preparation for the modification of the DIS (DODAG Information > Solicitation), we are collecting the use cases. > We want to make sure we understand all the requirements before crafting a > solution. > Georgios has kindly prepared a document on the ROLL GitHub repo. > See a text rendition at > https://github.com/roll-wg/roll-dis-modifications-use-cases/blob/master/dra > ft-papadopoulos-roll-dis-modifications-use-cases.txt > [RJ] Thanks Georgios. This surely helps. I am assuming that the use-cases text will get merged in the dis-modifications draft. One point mentioned in the use-cases draft is that unicast DIS can request __specific__ metric information from the parent. Currently, the parent sends the complete metric set to the child using unicast DIO. Wondering whether we need this mechanism for sending specific metric info back to the child node. The draft does not give a use-case for this. Anyways, this would be discussed when the drafts get merged and sent to the group. Currently, the document has two use cases: > - a new node joins an established RPL network. The use case calls for a > fairly quick confirmation that the node has joined with a good quality > path. However, we don't want to reset the Trickle timers of all nearby > routers and trigger broadcast, since the use case is that just one new > node was added/replaced/rebooted. > - another use case is that several nodes join at about the same time (e.g. > electricity meters all reboot following power outage). We want the DIOs to > be sent with broadcast so that all joining nodes benefit from them. > The draft draft-thubert-roll-eliding-dio-information-03 has another > request for modifying the DIS. We'll soon incorporate it into the use > cases document. > [RJ] Another use-case is of "adjacency probing". While (I believe) no new primitives need to be added, still the use-case is well-worth mentioning. The RPL-observations draft points to this use-case and you can pick some text from there. --00000000000061462a059f5fe6af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 24 Feb 2020 at 22:22, <dominique.barthel@orange.com> wrote:
De= ar Rollers,

In preparation for the modification of the DIS (DODAG Information
Solicitation), we are collecting the use cases.
We want to make sure we understand all the requirements before crafting a solution.
Georgios has kindly prepared a document on the ROLL GitHub repo.
See a text rendition at
https://github.com/roll-wg/roll-dis-modification= s-use-cases/blob/master/dra
ft-papadopoulos-roll-dis-modifications-use-cases.txt
<= br>
[RJ] Thanks Georgios. This surely helps. I am assuming that t= he use-cases text will get merged in the dis-modifications draft.
One point mentioned in the use-cases draft is that unicast DIS can request= __specific__ metric information from the parent. Currently, the parent sen= ds the complete metric set to the child using unicast DIO. Wondering whethe= r we need this mechanism for sending specific metric info back to the child= node. The draft does not give a use-case for this. Anyways, this would be = discussed when the drafts get merged and sent to the group.

<= /div>
Currently, the document has two use cases:
- a new node joins an established RPL network. The use case calls for a
fairly quick confirmation that the node has joined with a good quality
path. However, we don't want to reset the Trickle timers of all nearby<= br> routers and trigger broadcast, since the use case is that just one new
node was added/replaced/rebooted.
- another use case is that several nodes join at about the same time (e.g.<= br> electricity meters all reboot following power outage). We want the DIOs to<= br> be sent with broadcast so that all joining nodes benefit from them.
The draft draft-thubert-roll-eliding-dio-information-03 has another
request for modifying the DIS. We'll soon incorporate it into the use cases document.

[RJ] Another use-case i= s of "adjacency probing". While (I believe) no new primitives nee= d to be added, still the use-case is well-worth mentioning. The RPL-observa= tions draft points to this use-case and you can pick some text from there.<= /div>
=C2=A0
--00000000000061462a059f5fe6af-- From nobody Mon Feb 24 23:43:53 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852003A0956 for ; Mon, 24 Feb 2020 23:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 rXOOTnbQx0Tq for ; Mon, 24 Feb 2020 23:43:49 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1734F3A0955 for ; Mon, 24 Feb 2020 23:43:49 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 48RWC71gB6z4wlC; Tue, 25 Feb 2020 08:43:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582616627; bh=agBZdoLRvUagrsUnNGSpks7N65ErTg9z+jo2CZUy+PQ=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=JUKexFl3Rp5Tknlj/8RjtjiWvMjH71m6XaB7xecdbQo6h+JB/8oCIhifGJ3lKCFic PdQm02WAOUq35tOgVYC1HFM9lXds7tUI9IFh6hC8NWVBr5vF0YwTWkfDhN03T0hDu1 qW/40Gd5/8g2Q9usSS7X0ttwStGtz3msAHn0X8xM9IzIjETRYn+IlVY0a9/hjQD3a5 ZJxUmBCEB0czA2rXsgxURAY+daJcRUIkXTQ/v9Cll1KNShpMcpIHMkPBtOmDHjI/PN YqpgnEprm/Vhq9o2U/yo+vOfmX04ZtgQAx+Cvxc0RsiOHxSKkjgZioNu/pf7di3j/z BUJmg7dfDkj8g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 48RWC70xCmzFpWV; Tue, 25 Feb 2020 08:43:47 +0100 (CET) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM5D.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Tue, 25 Feb 2020 08:43:46 +0100 From: To: Routing Over Low power and Lossy networks , Rahul Jadhav Thread-Topic: [Roll] DIS-modifications use cases; Re: FW: New Version Notification for draft-ietf-roll-dis-modifications-01.txt Thread-Index: AQHV653d79Tfq7aUPEinOwvclzc02Kgrh2AA Date: Tue, 25 Feb 2020 07:43:46 +0000 Message-ID: <7837_1582616627_5E54D033_7837_172_1_DA7A8E46.70EAF%dominique.barthel@orange.com> References: <25671_1582563156_5E53FF54_25671_231_1_DA79B8DE.70E40%dominique.barthel@orange.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_DA7A8E4670EAFdominiquebarthelorangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] DIS-modifications use cases; Re: FW: New Version Notification for draft-ietf-roll-dis-modifications-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 07:43:52 -0000 --_000_DA7A8E4670EAFdominiquebarthelorangecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUmFodWwsIGFsbCwNCg0KVGhhbmtzLCBSYWh1bCwgIGZvciB5b3VyIGNvbnRyaWJ1dGlv biwgdGhpcyBpcyBoZWxwZnVsIQ0KV0csIG90aGVycyBpZGVhcywgY29tbWVudHM/DQpCZXN0IHJl Z2FyZHMNCg0KRG9taW5pcXVlDQoNCkRlIDogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgUmFodWwgSmFkaGF2IDxy YWh1bC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmFodWwuaWV0ZkBnbWFpbC5jb20+Pg0KUsOpcG9u ZHJlIMOgIDogInJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+IiA8cm9sbEBpZXRm Lm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4+DQpEYXRlIDogVHVlc2RheSAyNSBGZWJydWFyeSAy MDIwIDA2OjM4DQrDgCA6ICJyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPiIgPHJv bGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0KT2JqZXQgOiBSZTogW1JvbGxdIERJ Uy1tb2RpZmljYXRpb25zIHVzZSBjYXNlczsgUmU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtcm9sbC1kaXMtbW9kaWZpY2F0aW9ucy0wMS50eHQNCg0KDQoNCk9u IE1vbiwgMjQgRmViIDIwMjAgYXQgMjI6MjIsIDxkb21pbmlxdWUuYmFydGhlbEBvcmFuZ2UuY29t PG1haWx0bzpkb21pbmlxdWUuYmFydGhlbEBvcmFuZ2UuY29tPj4gd3JvdGU6DQpEZWFyIFJvbGxl cnMsDQoNCkluIHByZXBhcmF0aW9uIGZvciB0aGUgbW9kaWZpY2F0aW9uIG9mIHRoZSBESVMgKERP REFHIEluZm9ybWF0aW9uDQpTb2xpY2l0YXRpb24pLCB3ZSBhcmUgY29sbGVjdGluZyB0aGUgdXNl IGNhc2VzLg0KV2Ugd2FudCB0byBtYWtlIHN1cmUgd2UgdW5kZXJzdGFuZCBhbGwgdGhlIHJlcXVp cmVtZW50cyBiZWZvcmUgY3JhZnRpbmcgYQ0Kc29sdXRpb24uDQpHZW9yZ2lvcyBoYXMga2luZGx5 IHByZXBhcmVkIGEgZG9jdW1lbnQgb24gdGhlIFJPTEwgR2l0SHViIHJlcG8uDQpTZWUgYSB0ZXh0 IHJlbmRpdGlvbiBhdA0KaHR0cHM6Ly9naXRodWIuY29tL3JvbGwtd2cvcm9sbC1kaXMtbW9kaWZp Y2F0aW9ucy11c2UtY2FzZXMvYmxvYi9tYXN0ZXIvZHJhDQpmdC1wYXBhZG9wb3Vsb3Mtcm9sbC1k aXMtbW9kaWZpY2F0aW9ucy11c2UtY2FzZXMudHh0PGh0dHBzOi8vZ2l0aHViLmNvbS9yb2xsLXdn L3JvbGwtZGlzLW1vZGlmaWNhdGlvbnMtdXNlLWNhc2VzL2Jsb2IvbWFzdGVyL2RyYWZ0LXBhcGFk b3BvdWxvcy1yb2xsLWRpcy1tb2RpZmljYXRpb25zLXVzZS1jYXNlcy50eHQ+DQoNCltSSl0gVGhh bmtzIEdlb3JnaW9zLiBUaGlzIHN1cmVseSBoZWxwcy4gSSBhbSBhc3N1bWluZyB0aGF0IHRoZSB1 c2UtY2FzZXMgdGV4dCB3aWxsIGdldCBtZXJnZWQgaW4gdGhlIGRpcy1tb2RpZmljYXRpb25zIGRy YWZ0Lg0KT25lIHBvaW50IG1lbnRpb25lZCBpbiB0aGUgdXNlLWNhc2VzIGRyYWZ0IGlzIHRoYXQg dW5pY2FzdCBESVMgY2FuIHJlcXVlc3QgX19zcGVjaWZpY19fIG1ldHJpYyBpbmZvcm1hdGlvbiBm cm9tIHRoZSBwYXJlbnQuIEN1cnJlbnRseSwgdGhlIHBhcmVudCBzZW5kcyB0aGUgY29tcGxldGUg bWV0cmljIHNldCB0byB0aGUgY2hpbGQgdXNpbmcgdW5pY2FzdCBESU8uIFdvbmRlcmluZyB3aGV0 aGVyIHdlIG5lZWQgdGhpcyBtZWNoYW5pc20gZm9yIHNlbmRpbmcgc3BlY2lmaWMgbWV0cmljIGlu Zm8gYmFjayB0byB0aGUgY2hpbGQgbm9kZS4gVGhlIGRyYWZ0IGRvZXMgbm90IGdpdmUgYSB1c2Ut Y2FzZSBmb3IgdGhpcy4gQW55d2F5cywgdGhpcyB3b3VsZCBiZSBkaXNjdXNzZWQgd2hlbiB0aGUg ZHJhZnRzIGdldCBtZXJnZWQgYW5kIHNlbnQgdG8gdGhlIGdyb3VwLg0KDQpDdXJyZW50bHksIHRo ZSBkb2N1bWVudCBoYXMgdHdvIHVzZSBjYXNlczoNCi0gYSBuZXcgbm9kZSBqb2lucyBhbiBlc3Rh Ymxpc2hlZCBSUEwgbmV0d29yay4gVGhlIHVzZSBjYXNlIGNhbGxzIGZvciBhDQpmYWlybHkgcXVp Y2sgY29uZmlybWF0aW9uIHRoYXQgdGhlIG5vZGUgaGFzIGpvaW5lZCB3aXRoIGEgZ29vZCBxdWFs aXR5DQpwYXRoLiBIb3dldmVyLCB3ZSBkb24ndCB3YW50IHRvIHJlc2V0IHRoZSBUcmlja2xlIHRp bWVycyBvZiBhbGwgbmVhcmJ5DQpyb3V0ZXJzIGFuZCB0cmlnZ2VyIGJyb2FkY2FzdCwgc2luY2Ug dGhlIHVzZSBjYXNlIGlzIHRoYXQganVzdCBvbmUgbmV3DQpub2RlIHdhcyBhZGRlZC9yZXBsYWNl ZC9yZWJvb3RlZC4NCi0gYW5vdGhlciB1c2UgY2FzZSBpcyB0aGF0IHNldmVyYWwgbm9kZXMgam9p biBhdCBhYm91dCB0aGUgc2FtZSB0aW1lIChlLmcuDQplbGVjdHJpY2l0eSBtZXRlcnMgYWxsIHJl Ym9vdCBmb2xsb3dpbmcgcG93ZXIgb3V0YWdlKS4gV2Ugd2FudCB0aGUgRElPcyB0bw0KYmUgc2Vu dCB3aXRoIGJyb2FkY2FzdCBzbyB0aGF0IGFsbCBqb2luaW5nIG5vZGVzIGJlbmVmaXQgZnJvbSB0 aGVtLg0KVGhlIGRyYWZ0IGRyYWZ0LXRodWJlcnQtcm9sbC1lbGlkaW5nLWRpby1pbmZvcm1hdGlv bi0wMyBoYXMgYW5vdGhlcg0KcmVxdWVzdCBmb3IgbW9kaWZ5aW5nIHRoZSBESVMuIFdlJ2xsIHNv b24gaW5jb3Jwb3JhdGUgaXQgaW50byB0aGUgdXNlDQpjYXNlcyBkb2N1bWVudC4NCg0KW1JKXSBB bm90aGVyIHVzZS1jYXNlIGlzIG9mICJhZGphY2VuY3kgcHJvYmluZyIuIFdoaWxlIChJIGJlbGll dmUpIG5vIG5ldyBwcmltaXRpdmVzIG5lZWQgdG8gYmUgYWRkZWQsIHN0aWxsIHRoZSB1c2UtY2Fz ZSBpcyB3ZWxsLXdvcnRoIG1lbnRpb25pbmcuIFRoZSBSUEwtb2JzZXJ2YXRpb25zIGRyYWZ0IHBv aW50cyB0byB0aGlzIHVzZS1jYXNlIGFuZCB5b3UgY2FuIHBpY2sgc29tZSB0ZXh0IGZyb20gdGhl cmUuDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_DA7A8E4670EAFdominiquebarthelorangecom_ Content-Type: text/html; charset="utf-8" Content-ID: <7CAD0702303CEE4CA70C638BCAED8532@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IZWxsbyBSYWh1 bCwgYWxsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLCBSYWh1bCwgJm5i c3A7Zm9yIHlvdXIgY29udHJpYnV0aW9uLCB0aGlzIGlzIGhlbHBmdWwhPC9kaXY+DQo8ZGl2PldH LCBvdGhlcnMgaWRlYXMsIGNvbW1lbnRzPzwvZGl2Pg0KPGRpdj5CZXN0IHJlZ2FyZHM8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRvbWluaXF1ZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFj azsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg UEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBp bjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v bmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRl Jm5ic3A7OiA8L3NwYW4+Um9sbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGwtYm91bmNlc0BpZXRm Lm9yZyI+cm9sbC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFJhaHVsIEph ZGhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhaHVsLmlldGZAZ21haWwuY29tIj5yYWh1bC5pZXRm QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlLD qXBvbmRyZSDDoCZuYnNwOzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYu b3JnIj5yb2xsQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0 Zi5vcmciPnJvbGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5EYXRlJm5ic3A7OiA8L3NwYW4+VHVlc2RheSAyNSBGZWJydWFyeSAyMDIwIDA2OjM4 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPsOAJm5ic3A7OiA8L3NwYW4+JnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciPnJvbGxAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPk9iamV0Jm5ic3A7OiA8L3NwYW4+ UmU6IFtSb2xsXSBESVMtbW9kaWZpY2F0aW9ucyB1c2UgY2FzZXM7IFJlOiBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMtMDEu dHh0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGJyPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIE1vbiwg MjQgRmViIDIwMjAgYXQgMjI6MjIsICZsdDs8YSBocmVmPSJtYWlsdG86ZG9taW5pcXVlLmJhcnRo ZWxAb3JhbmdlLmNvbSI+ZG9taW5pcXVlLmJhcnRoZWxAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwy MDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KRGVhciBSb2xsZXJzLDxicj4NCjxicj4NCkluIHByZXBh cmF0aW9uIGZvciB0aGUgbW9kaWZpY2F0aW9uIG9mIHRoZSBESVMgKERPREFHIEluZm9ybWF0aW9u PGJyPg0KU29saWNpdGF0aW9uKSwgd2UgYXJlIGNvbGxlY3RpbmcgdGhlIHVzZSBjYXNlcy48YnI+ DQpXZSB3YW50IHRvIG1ha2Ugc3VyZSB3ZSB1bmRlcnN0YW5kIGFsbCB0aGUgcmVxdWlyZW1lbnRz IGJlZm9yZSBjcmFmdGluZyBhPGJyPg0Kc29sdXRpb24uPGJyPg0KR2Vvcmdpb3MgaGFzIGtpbmRs eSBwcmVwYXJlZCBhIGRvY3VtZW50IG9uIHRoZSBST0xMIEdpdEh1YiByZXBvLjxicj4NClNlZSBh IHRleHQgcmVuZGl0aW9uIGF0PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3JvbGwt d2cvcm9sbC1kaXMtbW9kaWZpY2F0aW9ucy11c2UtY2FzZXMvYmxvYi9tYXN0ZXIvZHJhZnQtcGFw YWRvcG91bG9zLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMtdXNlLWNhc2VzLnR4dCIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3JvbGwtd2cvcm9sbC1k aXMtbW9kaWZpY2F0aW9ucy11c2UtY2FzZXMvYmxvYi9tYXN0ZXIvZHJhPGJyPg0KZnQtcGFwYWRv cG91bG9zLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMtdXNlLWNhc2VzLnR4dDwvYT48L2Jsb2NrcXVv dGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bUkpdIFRoYW5rcyBHZW9yZ2lvcy4gVGhpcyBz dXJlbHkgaGVscHMuIEkgYW0gYXNzdW1pbmcgdGhhdCB0aGUgdXNlLWNhc2VzIHRleHQgd2lsbCBn ZXQgbWVyZ2VkIGluIHRoZSBkaXMtbW9kaWZpY2F0aW9ucyBkcmFmdC48L2Rpdj4NCjxkaXY+T25l IHBvaW50IG1lbnRpb25lZCBpbiB0aGUgdXNlLWNhc2VzIGRyYWZ0IGlzIHRoYXQgdW5pY2FzdCBE SVMgY2FuIHJlcXVlc3QgX19zcGVjaWZpY19fIG1ldHJpYyBpbmZvcm1hdGlvbiBmcm9tIHRoZSBw YXJlbnQuIEN1cnJlbnRseSwgdGhlIHBhcmVudCBzZW5kcyB0aGUgY29tcGxldGUgbWV0cmljIHNl dCB0byB0aGUgY2hpbGQgdXNpbmcgdW5pY2FzdCBESU8uIFdvbmRlcmluZyB3aGV0aGVyIHdlIG5l ZWQgdGhpcyBtZWNoYW5pc20gZm9yDQogc2VuZGluZyBzcGVjaWZpYyBtZXRyaWMgaW5mbyBiYWNr IHRvIHRoZSBjaGlsZCBub2RlLiBUaGUgZHJhZnQgZG9lcyBub3QgZ2l2ZSBhIHVzZS1jYXNlIGZv ciB0aGlzLiBBbnl3YXlzLCB0aGlzIHdvdWxkIGJlIGRpc2N1c3NlZCB3aGVuIHRoZSBkcmFmdHMg Z2V0IG1lcmdlZCBhbmQgc2VudCB0byB0aGUgZ3JvdXAuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiPg0KQ3VycmVudGx5LCB0aGUgZG9jdW1lbnQgaGFzIHR3byB1c2UgY2FzZXM6PGJy Pg0KLSBhIG5ldyBub2RlIGpvaW5zIGFuIGVzdGFibGlzaGVkIFJQTCBuZXR3b3JrLiBUaGUgdXNl IGNhc2UgY2FsbHMgZm9yIGE8YnI+DQpmYWlybHkgcXVpY2sgY29uZmlybWF0aW9uIHRoYXQgdGhl IG5vZGUgaGFzIGpvaW5lZCB3aXRoIGEgZ29vZCBxdWFsaXR5PGJyPg0KcGF0aC4gSG93ZXZlciwg d2UgZG9uJ3Qgd2FudCB0byByZXNldCB0aGUgVHJpY2tsZSB0aW1lcnMgb2YgYWxsIG5lYXJieTxi cj4NCnJvdXRlcnMgYW5kIHRyaWdnZXIgYnJvYWRjYXN0LCBzaW5jZSB0aGUgdXNlIGNhc2UgaXMg dGhhdCBqdXN0IG9uZSBuZXc8YnI+DQpub2RlIHdhcyBhZGRlZC9yZXBsYWNlZC9yZWJvb3RlZC48 YnI+DQotIGFub3RoZXIgdXNlIGNhc2UgaXMgdGhhdCBzZXZlcmFsIG5vZGVzIGpvaW4gYXQgYWJv dXQgdGhlIHNhbWUgdGltZSAoZS5nLjxicj4NCmVsZWN0cmljaXR5IG1ldGVycyBhbGwgcmVib290 IGZvbGxvd2luZyBwb3dlciBvdXRhZ2UpLiBXZSB3YW50IHRoZSBESU9zIHRvPGJyPg0KYmUgc2Vu dCB3aXRoIGJyb2FkY2FzdCBzbyB0aGF0IGFsbCBqb2luaW5nIG5vZGVzIGJlbmVmaXQgZnJvbSB0 aGVtLjxicj4NClRoZSBkcmFmdCBkcmFmdC10aHViZXJ0LXJvbGwtZWxpZGluZy1kaW8taW5mb3Jt YXRpb24tMDMgaGFzIGFub3RoZXI8YnI+DQpyZXF1ZXN0IGZvciBtb2RpZnlpbmcgdGhlIERJUy4g V2UnbGwgc29vbiBpbmNvcnBvcmF0ZSBpdCBpbnRvIHRoZSB1c2U8YnI+DQpjYXNlcyBkb2N1bWVu dC48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bUkpdIEFub3Ro ZXIgdXNlLWNhc2UgaXMgb2YgJnF1b3Q7YWRqYWNlbmN5IHByb2JpbmcmcXVvdDsuIFdoaWxlIChJ IGJlbGlldmUpIG5vIG5ldyBwcmltaXRpdmVzIG5lZWQgdG8gYmUgYWRkZWQsIHN0aWxsIHRoZSB1 c2UtY2FzZSBpcyB3ZWxsLXdvcnRoIG1lbnRpb25pbmcuIFRoZSBSUEwtb2JzZXJ2YXRpb25zIGRy YWZ0IHBvaW50cyB0byB0aGlzIHVzZS1jYXNlIGFuZCB5b3UgY2FuIHBpY2sgc29tZSB0ZXh0IGZy b20gdGhlcmUuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L3NwYW4+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+ DQo8L2h0bWw+DQo= --_000_DA7A8E4670EAFdominiquebarthelorangecom_-- From nobody Tue Feb 25 01:54:47 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAD13A07B5 for ; Tue, 25 Feb 2020 01:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 ynqttBzFLuZQ for ; Tue, 25 Feb 2020 01:54:43 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92253A07B2 for ; Tue, 25 Feb 2020 01:54:42 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 48RZ6932qsz5wDM; Tue, 25 Feb 2020 10:54:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582624481; bh=CX2KWThDLt4A2nC/XEPpNL77k7oQwSnhwAxmmT2CwfQ=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=MSKc+WCCSe/wW7zaE+wRppwBmIHauEZdncscdKSclJNuQXH/VWH+eDzuq2pQI/iUt WdDhi8WostMnaFDU2rC2x5pVwl3+WZGVevsoB4krgOd0cux5S3e8+bIk518m44+/+x GJr0+aPt2TDVboicIDpQgYnjAOYREGx4tZLm86Ge0wG6TV+h0cMOk+UidrG5aTfDOX zCCe3coV+d0GXETLqM0CAKS8/jh1oZazbNUD5nZ+x9ovf8ww6eIOfTMhfmSvzMoLn7 oSC7u0bEonlYoOMD9ybh//XCkYInKR0jWcY2YAT0tviTQxzgPAMTEM5s/Av+RY9Vol DMi4bActDVSnA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 48RZ691Xpzz1xnY; Tue, 25 Feb 2020 10:54:41 +0100 (CET) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM6E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Tue, 25 Feb 2020 10:54:40 +0100 From: To: Remous-Aris Koutsiamanis , "Georgios Z. Papadopoulos" CC: INES ROBLES , "Pascal Thubert (pthubert)" , roll Thread-Topic: [draft-ietf-roll-nsa-extension] Section realignment - feedback request Thread-Index: AQHV68GYjPtc0tYJpkyeFH2FZXKUbQ== Date: Tue, 25 Feb 2020 09:54:40 +0000 Message-ID: <28535_1582624481_5E54EEE1_28535_131_1_DA7AAA37.70EEF%dominique.barthel@orange.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_DA7AAA3770EEFdominiquebarthelorangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] [draft-ietf-roll-nsa-extension] Section realignment - feedback request X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 09:54:46 -0000 --_000_DA7AAA3770EEFdominiquebarthelorangecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQXJpcywgYWxsLA0KDQpUaGFua3MgZm9yIGFza2luZy4NCkkndmUganVzdCByZXZpZXdl ZCB2ZXJzaW9uIOKAkzA2IG9mIHRoZSBkcmFmdCwgYmVmb3JlIHJlYWRpbmcgdGhlIGRldGFpbHMg b2YgdGhlIGVtYWlsIGJlbG93Lg0KSXQgdHVybnMgb3V0IHRoYXQgSSB3YXMgbm90IHNob2NrZWQg YnkgdGhlIGN1cnJlbnQgb3JkZXJpbmcgb2Ygc2VjdGlvbnMuIFByb2JhYmx5IGJlY2F1c2UgSSdt IGFscmVhZHkgZmFtaWxpYXIgd2l0aCB0aGUgdG9waWMuDQpIb3dldmVyLCBhdCBtaW5pbXVtLCBh IGZvcndhcmQgcmVmZXJlbmNlIHRvIFNlY3Rpb25zIDMuMS0zLjMgd291bGQgYmUgaGlnaGx5IHVz ZWZ1bCB0byBuZXdjb21lcnMgdG8gdGhlIGRyYWZ0LiBQcm9iYWJseSByaWdodCBhZnRlciAiVGhl cmUgYXJlIG11bHRpcGxlIGFsdGVybmF0aXZlIG1ldGhvZHMgb2Ygc2VsZWN0aW5nIHRoZSBBUCBu b2RlLiINClJlYWRpbmcgdGhlIGRldGFpbHMgb2YgdGhlIGVtYWlsIGJlbG93IGFuZCB0aGlua2lu ZyBhYm91dCBpdCwgSSBiZWxpZXZlIHRoYXQgYnJpbmdpbmcgc2VjdGlvbnMgMy4xLTMuNCBmb3J3 YXJkIGluIHRoZSBkb2N1bWVudCwgYmVmb3JlIFNlY3Rpb24gMyAiQ29tbW9uIEFuY2VzdG9yIE9i amVjdGl2ZSBGdW5jdGlvbiIsIGFzIFJhaHVsIHN1Z2dlc3RzLCB3b3VsZCBtYWtlIGV2ZW4gbW9y ZSBzZW5zZS4NCkp1c3QgYmUgY2FyZWZ1bCB0byBjYWxsIHRoZSBDQS1TdHJpY3QsIENBLU1lZGl1 bSBhbmQgQ0EtUmVsYXhlZCB0aGluZ3MgIm1ldGhvZHMiIG9yICJhbGdvcml0aG0iLCBub3QgT0Yu IExlYXZlIHRoZSAiT0YiIHRlcm0gdG8gdGhlIGFjdHVhbCBkZWZpbml0aW9uIChhcyB1cGRhdGVz IHRvIE1SSE9GKSwgYW5kIHJlZmVyIHRvIHRoZSAiYWxnb3JpdGhtcyIgaW4gdGhlIE9GIGRlZmlu aXRpb24uDQpUaGlzIGlzIG15IHBlcnNvbmFsIG9waW5pb24gYXMgYSBtZW1iZXIgb2YgdGhlIFdH Lg0KTW9yZSBjb21tZW50cyBvbiB0aGUgZHJhZnQgdG8gY29tZSBpbiBhIHNlcGFyYXRlIGVtYWls Lg0KQmVzdCByZWdhcmRzLA0KDQpEb21pbmlxdWUNCg0KRGUgOiBSZW1vdXMtQXJpcyBLb3V0c2lh bWFuaXMgPGFyaXNAYXJpc2tvdS5jb208bWFpbHRvOmFyaXNAYXJpc2tvdS5jb20+Pg0KRGF0ZSA6 IE1vbmRheSAxMCBGZWJydWFyeSAyMDIwIDE1OjU2DQrDgCA6ICJtYXJpYWluZXNyb2JsZXNAZ29v Z2xlbWFpbC5jb208bWFpbHRvOm1hcmlhaW5lc3JvYmxlc0Bnb29nbGVtYWlsLmNvbT4iIDxtYXJp YWluZXNyb2JsZXNAZ29vZ2xlbWFpbC5jb208bWFpbHRvOm1hcmlhaW5lc3JvYmxlc0Bnb29nbGVt YWlsLmNvbT4+LCBEb21pbmlxdWUgQmFydGhlbCA8ZG9taW5pcXVlLmJhcnRoZWxAb3JhbmdlLmNv bTxtYWlsdG86ZG9taW5pcXVlLmJhcnRoZWxAb3JhbmdlLmNvbT4+LCBQYXNjYWwgVGh1YmVydCA8 cHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+PiwgInJvbGxAaWV0 Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+IiA8cm9sbEBpZXRmLm9yZzxtYWlsdG86cm9sbEBp ZXRmLm9yZz4+DQpDYyA6ICJHZW9yZ2lvcyBaLiBQYXBhZG9wb3Vsb3MiIDxnZW9yZ2lvcy5wYXBh ZG9wb3Vsb3NAaW10LWF0bGFudGlxdWUuZnI8bWFpbHRvOmdlb3JnaW9zLnBhcGFkb3BvdWxvc0Bp bXQtYXRsYW50aXF1ZS5mcj4+DQpPYmpldCA6IFtkcmFmdC1pZXRmLXJvbGwtbnNhLWV4dGVuc2lv bl0gU2VjdGlvbiByZWFsaWdubWVudCAtIGZlZWRiYWNrIHJlcXVlc3QNCg0KRGVhciBJbmVzLCBE b21pbmlxdWUsIFBhc2NhbCwgYW5kIGFsbCwNCg0KQWZ0ZXIgZGlzY3Vzc2luZyBhbmQgYW1lbmRp bmcgdGhlIGRyYWZ0LWlldGYtcm9sbC1uc2EtZXh0ZW5zaW9uIGRyYWZ0IHdpdGggZmVlZGJhY2sg ZnJvbSBSYWh1bCwgYSBmZXcgcG9pbnRzIHN0aWxsIHJlbWFpbiB3aGljaCB3ZSB3b3VsZCBsaWtl IHNvbWUgYWRkaXRpb25hbCBmZWVkYmFjayBvbi4NCg0KSSBjb3B5IHRoZSByZWxldmFudCBkaXNj dXNzaW9uIGJlbG93Og0KDQpbUkpdIFNlY3Rpb24gcmVhbGlnbm1lbnQNCkl0IGlzIGJldHRlciB0 byBleHBsYWluIENBIFN0cmljdC9NZWRpdW0vUmVsYXggcG9saWNpZXMgYmVmb3JlIGV4cGxhaW5p bmcgdGhlDQpDQU9GIGJlY2F1c2UgYXMgYSByZWFkZXIgb25lIG5lZWRzIHRvIGJlIGZhbWlsaWFy IHdpdGggdGhlc2UgcG9saWNpZXMgYmVmb3JlDQp1bmRlcnN0YW5kaW5nIHRoZSBPRi4NCg0KDQpb QUtdIFRoYW5rIHlvdSBmb3IgdGhpcyBjb21tZW50LiBXZSBoYWQgYSBzaW1pbGFyIGNvbmNlcm4g YXMgd2VsbC4NCldlIGFyZSBub3Qgc3VyZSB3aGF0IGlzIGJlc3QuDQpBcyB0aGUgdGV4dCBpcyBj dXJyZW50IHN0cnVjdHVyZWQsIHdlIGludHJvZHVjZSB0aGUgQ0FPRiBmaXJzdCwgbWVudGlvbmlu ZyB0aGF0IGRpZmZlcmVudCBwb2xpY2llcyBhcmUgcG9zc2libGUgYW5kIHRoYXQgYSBzZWxlY3Rp b24gZnJvbSB0aGUgcGFyZW50IHNldCBtdXN0IGJlIG1hZGUuDQpXZSB0aGVuIGRlc2NyaWJlIHRo ZSBDQU9GIGluIHRlcm1zIG9mIGRpZmZlcmVuY2VzIGZyb20vYWRkaXRpb25zIHRvIE1SSE9GLg0K QW5kIGZpbmFsbHkgd2UgZGVzY3JpYmUgdGhlIHBvbGljaWVzLg0KVG8gbXkgbWluZCwgdGhlIHBv bGljaWVzIGFyZSBjb25jcmV0ZSwgYnV0IHRoZXkgYXJlIGFsc28ganVzdCBleGFtcGxlcywgc28g c29tZW9uZSBjYW4gZGV2aXNlIGRpZmZlcmVudCBvbmVzLg0KSW4gdGhhdCBzZW5zZSB0aGUgQ0FP RiBpcyBtb3JlICJmaXhlZCIgYW5kIHRoZSBwb2xpY2llcyBhcmUgbW9yZSBmbGV4aWJsZS4gVGh1 cyBpdCBtYWtlcyBzZW5zZSB0byBkZXNjcmliZSB0aGUgQ0FPRiBmaXJzdC4NCg0KV2UgYXJlIHZl cnkgb3BlbiB0byBjaGFuZ2luZyB0aGUgb3JkZXIsIGJ1dCB3ZSB3b3VsZCBsaWtlIHRvIGhhdmUg c29tZSBhZGRpdGlvbmFsIGZlZWRiYWNrIHRoYXQgdGhlIG9yZGVyIGlzIHByb2JsZW1hdGljIGFz IGl0IHN0YW5kcyBub3cuDQpXZSB3b3VsZCBsaWtlIHRvIGhlYXIgYW55IHN1Z2dlc3Rpb25zIGZy b20gdGhlIGdyb3VwIG9uIHRoaXMgdG9waWMuDQoNCg0KW1JKXSBPaywgbGV0cyB3YWl0IGZvciBm ZWVkYmFjay4gSSwgZm9yIG9uZSwgd291bGQgbGlrZSB0byBzZWUNCnBvbGljaWVzIGV4cGxhaW5l ZCBmaXJzdCBhbmQgdGhlbiBhbiBPRiB1c2luZyB0aGVtLiBJIGZpbmQgdGhpcyB0aGUNCm9ubHkg bG9naWNhbCB3YXkuDQoNCg0KW1JKXSBSYWh1bCBKYWRoYXYNCltBUl0gQXJpcyBLb3V0c2lhbWFu aXMNCg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGluIGFkdmFuY2UuDQoNCkJlc3QsDQpBcmlzDQoN Cg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_DA7AAA3770EEFdominiquebarthelorangecom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IZWxsbyBBcmlz LCBhbGwsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MgZm9yIGFza2luZy48 L2Rpdj4NCjxkaXY+SSd2ZSBqdXN0IHJldmlld2VkIHZlcnNpb24g4oCTMDYgb2YgdGhlIGRyYWZ0 LCBiZWZvcmUgcmVhZGluZyB0aGUgZGV0YWlscyBvZiB0aGUgZW1haWwgYmVsb3cuPC9kaXY+DQo8 ZGl2Pkl0IHR1cm5zIG91dCB0aGF0IEkgd2FzIG5vdCBzaG9ja2VkIGJ5IHRoZSBjdXJyZW50IG9y ZGVyaW5nIG9mIHNlY3Rpb25zLiBQcm9iYWJseSBiZWNhdXNlIEknbSBhbHJlYWR5IGZhbWlsaWFy IHdpdGggdGhlIHRvcGljLjwvZGl2Pg0KPGRpdj5Ib3dldmVyLCBhdCBtaW5pbXVtLCBhIGZvcndh cmQgcmVmZXJlbmNlIHRvIFNlY3Rpb25zIDMuMS0zLjMgd291bGQgYmUgaGlnaGx5IHVzZWZ1bCB0 byBuZXdjb21lcnMgdG8gdGhlIGRyYWZ0LiBQcm9iYWJseSByaWdodCBhZnRlciAmcXVvdDtUaGVy ZSBhcmUgbXVsdGlwbGUgYWx0ZXJuYXRpdmUgbWV0aG9kcyBvZiBzZWxlY3RpbmcgdGhlIEFQIG5v ZGUuJnF1b3Q7PC9kaXY+DQo8ZGl2PlJlYWRpbmcgdGhlIGRldGFpbHMgb2YgdGhlIGVtYWlsIGJl bG93IGFuZCB0aGlua2luZyBhYm91dCBpdCwgSSBiZWxpZXZlIHRoYXQgYnJpbmdpbmcgc2VjdGlv bnMgMy4xLTMuNCBmb3J3YXJkIGluIHRoZSBkb2N1bWVudCwgYmVmb3JlIFNlY3Rpb24gMyAmcXVv dDtDb21tb24gQW5jZXN0b3IgT2JqZWN0aXZlIEZ1bmN0aW9uJnF1b3Q7LCBhcyBSYWh1bCBzdWdn ZXN0cywgd291bGQgbWFrZSBldmVuIG1vcmUgc2Vuc2UuPC9kaXY+DQo8ZGl2Pkp1c3QgYmUgY2Fy ZWZ1bCB0byBjYWxsIHRoZSBDQS1TdHJpY3QsIENBLU1lZGl1bSBhbmQgQ0EtUmVsYXhlZCB0aGlu Z3MgJnF1b3Q7bWV0aG9kcyZxdW90OyBvciAmcXVvdDthbGdvcml0aG0mcXVvdDssIG5vdCBPRi4g TGVhdmUgdGhlICZxdW90O09GJnF1b3Q7IHRlcm0gdG8gdGhlIGFjdHVhbCBkZWZpbml0aW9uIChh cyB1cGRhdGVzIHRvIE1SSE9GKSwgYW5kIHJlZmVyIHRvIHRoZSAmcXVvdDthbGdvcml0aG1zJnF1 b3Q7IGluIHRoZSBPRiBkZWZpbml0aW9uLjwvZGl2Pg0KPGRpdj5UaGlzIGlzIG15IHBlcnNvbmFs IG9waW5pb24gYXMgYSBtZW1iZXIgb2YgdGhlIFdHLjwvZGl2Pg0KPGRpdj5Nb3JlIGNvbW1lbnRz IG9uIHRoZSBkcmFmdCB0byBjb21lIGluIGEgc2VwYXJhdGUgZW1haWwuPC9kaXY+DQo8ZGl2PkJl c3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRvbWluaXF1ZSZuYnNw OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4 dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJP UkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZU OiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7 IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRlJm5ic3A7OiA8L3NwYW4+UmVtb3VzLUFyaXMgS291dHNp YW1hbmlzICZsdDs8YSBocmVmPSJtYWlsdG86YXJpc0Bhcmlza291LmNvbSI+YXJpc0Bhcmlza291 LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGUmbmJz cDs6IDwvc3Bhbj5Nb25kYXkgMTAgRmVicnVhcnkgMjAyMCAxNTo1Njxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj7DgCZuYnNwOzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0 bzptYXJpYWluZXNyb2JsZXNAZ29vZ2xlbWFpbC5jb20iPm1hcmlhaW5lc3JvYmxlc0Bnb29nbGVt YWlsLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJpYWluZXNyb2JsZXNAZ29v Z2xlbWFpbC5jb20iPm1hcmlhaW5lc3JvYmxlc0Bnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7LCBEb21p bmlxdWUgQmFydGhlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRvbWluaXF1ZS5iYXJ0aGVsQG9yYW5n ZS5jb20iPmRvbWluaXF1ZS5iYXJ0aGVsQG9yYW5nZS5jb208L2E+Jmd0OywNCiBQYXNjYWwgVGh1 YmVydCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSI+cHRodWJlcnRAY2lz Y28uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xs QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciPnJv bGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5D YyZuYnNwOzogPC9zcGFuPiZxdW90O0dlb3JnaW9zIFouIFBhcGFkb3BvdWxvcyZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmdlb3JnaW9zLnBhcGFkb3BvdWxvc0BpbXQtYXRsYW50aXF1ZS5mciI+ Z2Vvcmdpb3MucGFwYWRvcG91bG9zQGltdC1hdGxhbnRpcXVlLmZyPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T2JqZXQmbmJzcDs6IDwvc3Bhbj5bZHJhZnQtaWV0 Zi1yb2xsLW5zYS1leHRlbnNpb25dIFNlY3Rpb24gcmVhbGlnbm1lbnQgLSBmZWVkYmFjayByZXF1 ZXN0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXY+RGVhciBJbmVzLCBEb21pbmlxdWUsIFBhc2NhbCwgYW5kIGFsbCw8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFmdGVyIGRpc2N1c3NpbmcgYW5kIGFtZW5kaW5n IHRoZSA8c3BhbiBjbGFzcz0iZ21haWwtZmlsZW5hbWUiPmRyYWZ0LWlldGYtcm9sbC1uc2EtZXh0 ZW5zaW9uIGRyYWZ0IHdpdGggZmVlZGJhY2sgZnJvbSBSYWh1bCwgYSBmZXcgcG9pbnRzIHN0aWxs IHJlbWFpbiB3aGljaCB3ZSB3b3VsZCBsaWtlIHNvbWUgYWRkaXRpb25hbCBmZWVkYmFjayBvbi48 L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbC1maWxlbmFtZSI+PGJyPg0KPC9z cGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iZ21haWwtZmlsZW5hbWUiPkkgY29weSB0aGUg cmVsZXZhbnQgZGlzY3Vzc2lvbiBiZWxvdzo8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNz PSJnbWFpbC1maWxlbmFtZSI+PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iZ21haWwt ZmlsZW5hbWUiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+W1JKXSBTZWN0aW9uIHJlYWxpZ25t ZW50PGJyPg0KSXQgaXMgYmV0dGVyIHRvIGV4cGxhaW4gQ0EgU3RyaWN0L01lZGl1bS9SZWxheCBw b2xpY2llcyBiZWZvcmUgZXhwbGFpbmluZyB0aGU8YnI+DQpDQU9GIGJlY2F1c2UgYXMgYSByZWFk ZXIgb25lIG5lZWRzIHRvIGJlIGZhbWlsaWFyIHdpdGggdGhlc2UgcG9saWNpZXMgYmVmb3JlPGJy Pg0KdW5kZXJzdGFuZGluZyB0aGUgT0YuPGJyPg0KPGJyPg0KPGJyPg0KW0FLXSBUaGFuayB5b3Ug Zm9yIHRoaXMgY29tbWVudC4gV2UgaGFkIGEgc2ltaWxhciBjb25jZXJuIGFzIHdlbGwuPGJyPg0K V2UgYXJlIG5vdCBzdXJlIHdoYXQgaXMgYmVzdC48YnI+DQpBcyB0aGUgdGV4dCBpcyBjdXJyZW50 IHN0cnVjdHVyZWQsIHdlIGludHJvZHVjZSB0aGUgQ0FPRiBmaXJzdCwgbWVudGlvbmluZyB0aGF0 IGRpZmZlcmVudCBwb2xpY2llcyBhcmUgcG9zc2libGUgYW5kIHRoYXQgYSBzZWxlY3Rpb24gZnJv bSB0aGUgcGFyZW50IHNldCBtdXN0IGJlIG1hZGUuPGJyPg0KV2UgdGhlbiBkZXNjcmliZSB0aGUg Q0FPRiBpbiB0ZXJtcyBvZiBkaWZmZXJlbmNlcyBmcm9tL2FkZGl0aW9ucyB0byBNUkhPRi48YnI+ DQpBbmQgZmluYWxseSB3ZSBkZXNjcmliZSB0aGUgcG9saWNpZXMuPGJyPg0KVG8gbXkgbWluZCwg dGhlIHBvbGljaWVzIGFyZSBjb25jcmV0ZSwgYnV0IHRoZXkgYXJlIGFsc28ganVzdCBleGFtcGxl cywgc28gc29tZW9uZSBjYW4gZGV2aXNlIGRpZmZlcmVudCBvbmVzLjxicj4NCkluIHRoYXQgc2Vu c2UgdGhlIENBT0YgaXMgbW9yZSAmcXVvdDtmaXhlZCZxdW90OyBhbmQgdGhlIHBvbGljaWVzIGFy ZSBtb3JlIGZsZXhpYmxlLiBUaHVzIGl0IG1ha2VzIHNlbnNlIHRvIGRlc2NyaWJlIHRoZSBDQU9G IGZpcnN0Ljxicj4NCjxicj4NCldlIGFyZSB2ZXJ5IG9wZW4gdG8gY2hhbmdpbmcgdGhlIG9yZGVy LCBidXQgd2Ugd291bGQgbGlrZSB0byBoYXZlIHNvbWUgYWRkaXRpb25hbCBmZWVkYmFjayB0aGF0 IHRoZSBvcmRlciBpcyBwcm9ibGVtYXRpYyBhcyBpdCBzdGFuZHMgbm93Ljxicj4NCldlIHdvdWxk IGxpa2UgdG8gaGVhciBhbnkgc3VnZ2VzdGlvbnMgZnJvbSB0aGUgZ3JvdXAgb24gdGhpcyB0b3Bp Yy48YnI+DQo8YnI+DQo8YnI+DQpbUkpdIE9rLCBsZXRzIHdhaXQgZm9yIGZlZWRiYWNrLiBJLCBm b3Igb25lLCB3b3VsZCBsaWtlIHRvIHNlZTxicj4NCnBvbGljaWVzIGV4cGxhaW5lZCBmaXJzdCBh bmQgdGhlbiBhbiBPRiB1c2luZyB0aGVtLiBJIGZpbmQgdGhpcyB0aGU8YnI+DQpvbmx5IGxvZ2lj YWwgd2F5Ljxicj4NCjxicj4NCjxicj4NCltSSl0gUmFodWwgSmFkaGF2PGJyPg0KW0FSXSBBcmlz IEtvdXRzaWFtYW5pczwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlRoYW5rIHlvdSB2ZXJ5IG11Y2ggaW4gYWR2YW5jZS48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkJlc3QsPC9kaXY+DQo8ZGl2PkFyaXM8YnI+DQo8L2Rpdj4NCjxkaXY+PHNw YW4gY2xhc3M9ImdtYWlsLWZpbGVuYW1lIj48L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNz PSJnbWFpbC1maWxlbmFtZSI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0i Z21haWwtZmlsZW5hbWUiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvc3Bhbj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRt bD4NCg== --_000_DA7AAA3770EEFdominiquebarthelorangecom_-- From nobody Tue Feb 25 08:18:46 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155C13A0FAC for ; Tue, 25 Feb 2020 08:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com header.b=XiT0vuLU; dkim=pass (2048-bit key) header.d=ariskou.com header.b=Rqg3CFrH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5L6WQse321A for ; Tue, 25 Feb 2020 08:18:39 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE193A0FA2 for ; Tue, 25 Feb 2020 08:18:38 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 7AD732D09 for ; Tue, 25 Feb 2020 17:18:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1582647516; bh=xG2amIAmfOTFmlXZ70DwIWvPz9Gny79d5/uIzaSQkTQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XiT0vuLUASJ+5lPHh7xB9vuyI0ApmVZjCaof14pfV8GF2dFxxPIOlxlyNU4vyScwo GP75TRWUmKZphgZAfgLLWMG1Wb0pRwoT2BT17gW87F5I7Mayqpk+TrNAHhOJimCTmv 1DxPbM3tMzXz02PvF7PWzi/NudKrM4sILt6r03MoJvpMk7WDOSefl+3KmOAsRoaEkF LwwokjK3sKwcNjHPqL0NWj9vyQpR0A2ajteKeSSGOTlJJ+SAoFAy2Dcy+hQYuTaxUy t+/wSLhmaWGqo/l1no1YgSAZG9Q9EjNPau4/HNusBjmd+I9PB51WW4Qhbh88r89NsO EEdMHlWemm3nA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1582647516; s=20191001-wvim; d=ariskou.com; i=aris@ariskou.com; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Content-Type; l=12650; bh=xG2amIAmfOTFmlXZ70DwIWvPz9Gny79d5/uIzaSQkTQ=; b=Rqg3CFrHDmUGVoC7cDsCw2QA0Oe3kh0j2VefzaUpx3BC3/ffh/9S7oCpd73igNdd IWxVQWeAJXbRVE4xPjy8PGl7kC+fGFnH13cwcbDI0NXn62OCU/1FdEAB6OgxcQzoxVO Zx2BMZExFd2WMxqqiNcAYy16InHvCWSETIuNCOEWYbTNAzGQKFbot7A/gHE7gKUAerA biu/zQRwGUeyahCnVVojhdWZLTosJdBinEacBzWONETpdnTK7ova76hnwnhuiBuiKyF 8fcjF0zQipzavZZ+j0CgczDfjkOJFjtQ0ngJfK6eULnIHK96s6SMu75ljuqw8qhtIg2 C328O1T52w== Received: by smtp.mailfence.com with ESMTPA for ; Tue, 25 Feb 2020 17:18:29 +0100 (CET) Received: by mail-io1-f54.google.com with SMTP id z16so2993027iod.11 for ; Tue, 25 Feb 2020 08:18:28 -0800 (PST) X-Gm-Message-State: APjAAAXR22D8KwM2+dwzhgUNCGnqic7nOnRnuMJ8jyR2AS0g2jCbYErq SZYNZm7na7mzsxnUXrpPygzdABK0Zzv1I61CBPE= X-Google-Smtp-Source: APXvYqxXsF9oetWgHm0xRf3yprMdSkJ9F55ABeOL3GR4dl/jb7LO4vV4i2qONJUVuu13sxfcMib6fbbkDvyMYyx1mto= X-Received: by 2002:a5d:840a:: with SMTP id i10mr57309974ion.225.1582647503567; Tue, 25 Feb 2020 08:18:23 -0800 (PST) MIME-Version: 1.0 References: <28535_1582624481_5E54EEE1_28535_131_1_DA7AAA37.70EEF%dominique.barthel@orange.com> In-Reply-To: <28535_1582624481_5E54EEE1_28535_131_1_DA7AAA37.70EEF%dominique.barthel@orange.com> From: Remous-Aris Koutsiamanis Date: Tue, 25 Feb 2020 17:18:33 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: dominique barthel , Rahul Jadhav Cc: "Georgios Z. Papadopoulos" , INES ROBLES , "Pascal Thubert (pthubert)" , roll Content-Type: multipart/alternative; boundary="0000000000004148c3059f68d6dd" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] [draft-ietf-roll-nsa-extension] Section realignment - feedback request X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 16:18:43 -0000 --0000000000004148c3059f68d6dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Dominique and Rahul, thank you both very much for the review and comments. I am glad that there is consensus and both of you agree that the section order should be reversed. I had no real problem with either order but after reading it many times maybe I have been desensitized a bit. So I will make the change, no problem. Also, since Dominique plans to send more comments, I think I will wait for those as well so that I can do all the fixes/changes together, hopefully before the next cutoff date. Again, thanks a lot for the help. Best, Aris On Tue, Feb 25, 2020 at 10:55 AM wrote: > Hello Aris, all, > > Thanks for asking. > I've just reviewed version =E2=80=9306 of the draft, before reading the d= etails of > the email below. > It turns out that I was not shocked by the current ordering of sections. > Probably because I'm already familiar with the topic. > However, at minimum, a forward reference to Sections 3.1-3.3 would be > highly useful to newcomers to the draft. Probably right after "There are > multiple alternative methods of selecting the AP node." > Reading the details of the email below and thinking about it, I believe > that bringing sections 3.1-3.4 forward in the document, before Section 3 > "Common Ancestor Objective Function", as Rahul suggests, would make even > more sense. > Just be careful to call the CA-Strict, CA-Medium and CA-Relaxed things > "methods" or "algorithm", not OF. Leave the "OF" term to the actual > definition (as updates to MRHOF), and refer to the "algorithms" in the OF > definition. > This is my personal opinion as a member of the WG. > More comments on the draft to come in a separate email. > Best regards, > > Dominique > > De : Remous-Aris Koutsiamanis > Date : Monday 10 February 2020 15:56 > =C3=80 : "mariainesrobles@googlemail.com" , > Dominique Barthel , Pascal Thubert < > pthubert@cisco.com>, "roll@ietf.org" > Cc : "Georgios Z. Papadopoulos" > Objet : [draft-ietf-roll-nsa-extension] Section realignment - feedback > request > > Dear Ines, Dominique, Pascal, and all, > > After discussing and amending the draft-ietf-roll-nsa-extension draft > with feedback from Rahul, a few points still remain which we would like > some additional feedback on. > > I copy the relevant discussion below: > > [RJ] Section realignment > It is better to explain CA Strict/Medium/Relax policies before explaining > the > CAOF because as a reader one needs to be familiar with these policies > before > understanding the OF. > > > [AK] Thank you for this comment. We had a similar concern as well. > We are not sure what is best. > As the text is current structured, we introduce the CAOF first, mentionin= g > that different policies are possible and that a selection from the parent > set must be made. > We then describe the CAOF in terms of differences from/additions to MRHOF= . > And finally we describe the policies. > To my mind, the policies are concrete, but they are also just examples, s= o > someone can devise different ones. > In that sense the CAOF is more "fixed" and the policies are more flexible= . > Thus it makes sense to describe the CAOF first. > > We are very open to changing the order, but we would like to have some > additional feedback that the order is problematic as it stands now. > We would like to hear any suggestions from the group on this topic. > > > [RJ] Ok, lets wait for feedback. I, for one, would like to see > policies explained first and then an OF using them. I find this the > only logical way. > > > [RJ] Rahul Jadhav > [AR] Aris Koutsiamanis > > > Thank you very much in advance. > > Best, > Aris > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --0000000000004148c3059f68d6dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dominique and Rahul,

thank you both very much for the review and comments.

I am glad that there is consensus and both of you agree t= hat the section order should be reversed.
I had no real problem w= ith either order but after reading it many times maybe I have been desensit= ized a bit.

So I will make the change, no problem.=

Also, since=C2=A0Dominique plans to send more= comments, I think I will wait for those as well so that I can do all the f= ixes/changes together, hopefully before the next cutoff date.

Again, thanks a lot for the help.

= Best,
Aris


On Tue, Feb 25, 2020 at 10:55 = AM <dominique.barthel@or= ange.com> wrote:
Hello Aris, all,

Thanks for asking.
I've just reviewed version =E2=80=9306 of the draft, before readin= g the details of the email below.
It turns out that I was not shocked by the current ordering of section= s. Probably because I'm already familiar with the topic.
However, at minimum, a forward reference to Sections 3.1-3.3 would be = highly useful to newcomers to the draft. Probably right after "There a= re multiple alternative methods of selecting the AP node."
Reading the details of the email below and thinking about it, I believ= e that bringing sections 3.1-3.4 forward in the document, before Section 3 = "Common Ancestor Objective Function", as Rahul suggests, would ma= ke even more sense.
Just be careful to call the CA-Strict, CA-Medium and CA-Relaxed things= "methods" or "algorithm", not OF. Leave the "OF&q= uot; term to the actual definition (as updates to MRHOF), and refer to the = "algorithms" in the OF definition.
This is my personal opinion as a member of the WG.
More comments on the draft to come in a separate email.
Best regards,

Dominique=C2=A0

De=C2=A0: Remous-Aris Koutsiamanis = <aris@ariskou.com<= /a>>
Date=C2=A0: Monday 10 February 2020= 15:56
=C3=80=C2=A0: "mariainesrobles@google= mail.com" <mariainesrobles@googlemail.com>, Dominique Barthel &= lt;domini= que.barthel@orange.com>, Pascal Thubert <pthubert@cisco.com>, "roll@ietf.org" <roll@ietf.org>
Cc=C2=A0: "Georgios Z. Papadop= oulos" <georgios.papadopoulos@imt-atlantique.fr>
Objet=C2=A0: [draft-ietf-roll-nsa-e= xtension] Section realignment - feedback request

Dear Ines, Dominique, Pascal, and all,

After discussing and amending the draft-ietf-roll-nsa-extension = draft with feedback from Rahul, a few points still remain which we would li= ke some additional feedback on.

I copy the relevant discussion below:

[RJ] Section realignment
It is better to explain CA Strict/Medium/Relax policies before explaining t= he
CAOF because as a reader one needs to be familiar with these policies befor= e
understanding the OF.


[AK] Thank you for this comment. We had a similar concern as well.
We are not sure what is best.
As the text is current structured, we introduce the CAOF first, mentioning = that different policies are possible and that a selection from the parent s= et must be made.
We then describe the CAOF in terms of differences from/additions to MRHOF.<= br> And finally we describe the policies.
To my mind, the policies are concrete, but they are also just examples, so = someone can devise different ones.
In that sense the CAOF is more "fixed" and the policies are more = flexible. Thus it makes sense to describe the CAOF first.

We are very open to changing the order, but we would like to have some addi= tional feedback that the order is problematic as it stands now.
We would like to hear any suggestions from the group on this topic.


[RJ] Ok, lets wait for feedback. I, for one, would like to see
policies explained first and then an OF using them. I find this the
only logical way.


[RJ] Rahul Jadhav
[AR] Aris Koutsiamanis


Thank you very much in advance.

Best,
Aris


 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--0000000000004148c3059f68d6dd-- From nobody Wed Feb 26 03:02:43 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2F3A0771 for ; Wed, 26 Feb 2020 03:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 3vV0p-rGJrS0 for ; Wed, 26 Feb 2020 03:02:39 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5893A0770 for ; Wed, 26 Feb 2020 03:02:39 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 48SCZ54n0xz1ySS; Wed, 26 Feb 2020 12:02:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582714957; bh=L6DakGDpv5F+Y3arkV80cUTUxkCiGYTSs9xNWWdaSSQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=aj50HUQWHHM4BBoBbLZCja3qOTKp57qmb2DPN3ZCBPMTWGQJjCSbExIrtxYN646zt 8qfjKI4cYJ7qqcTZALPgp68FLqtVUrw0v0PikoAT0CcH1x0qKLT460iECh4nZAxuWU D7NGnroUOom66g+ASCXolZJa7pssZThrNba2tJZji5Ja3cWbbseLe6tCkYKTlA8s1Q tvmy5lrdjfXKgNDhFTrNjOxa6OX/8C9e8YkVWIX2brjAEECO8CPTadvf1tPMC5fGSt 9+QflFmUxk30rRc+PQVC759VACJ2L+k6St9MKtq0sHeBoQ5W79053XLgBf+zQT5quU NvFByVjXsmC6g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 48SCZ5409Rz1xpY; Wed, 26 Feb 2020 12:02:37 +0100 (CET) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([fe80::81c9:5f:b9c5:1241%21]) with mapi id 14.03.0468.000; Wed, 26 Feb 2020 12:02:37 +0100 From: To: Routing Over Low power and Lossy networks , "Georgios Z. Papadopoulos" , "Remous-Aris Koutsiamanis" Thread-Topic: [Roll] NSA PS-set metric/constraint Thread-Index: AQHV4Ivxjv+kUNuhZ06uTfBtagn0rg== Date: Wed, 26 Feb 2020 11:02:37 +0000 Message-ID: <28813_1582714957_5E56504D_28813_497_1_DA7C05D5.71025%dominique.barthel@orange.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-ID: <4CB81F6BFED16448A2243A17F56E09A7@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] NSA PS-set metric/constraint X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 11:02:43 -0000 SGVsbG8gYWxsLA0KDQpUaGUgZGlzY3Vzc2lvbiBiZWxvdyBwcm9tcHRzIG1lIHRvIHF1ZXN0aW9u IHRoZSB3YXkgdGhlIFBhcmVudCBTZXQgKFBTKQ0KYXBwZWFycyBpbiB0aGUgRG9kYWcgTWV0cmlj IENvbnRhaW5lciAoRE1DKS4gU29ycnkgaWYgdGhpcyBjb21lcyB1cCBsYXRlDQppbiB0aGUgcHJv Y2Vzcy4NCg0KVGhlIE5TQSBvYmplY3QgY2FycnlpbmcgdGhlIFBTIFRMViBpcyBjdXJyZW50bHkg c3BlY2lmaWVkIHRvIGJlIENvbnRyYWludC4NClRoaXMgc2hvd3MgdXAgb25seSBvbmNlIGluIHRo ZSB0ZXh0IChwYWdlIDExKS4NClRoZXJlIGFyZSBzb21lIGlzc3VlcyBhc3NvY2lhdGVkIHdpdGgg dGhlIFBTIGJlaW5nIHBhcnQgb2YgYSBjb25zdHJhaW50Og0KUkZDNjU1MSBzYXlzDQoiSW4gdGhl IHByZXNlbmNlIG9mIGEgY29uc3RyYWludCwgYSBub2RlIE1VU1QgaW5jbHVkZSBhIG1ldHJpYyBv ZiB0aGUNCnNhbWUgdHlwZS4gIFRoYXQgbWV0cmljIGlzIHVzZWQgdG8gY2hlY2sgd2hldGhlciBv ciBub3QgdGhlICAgY29uc3RyYWludA0KaXMgbWV0LiAgSW4gYWxsIGNhc2VzLCBhIG5vZGUgTVVT VCBub3QgY2hhbmdlIHRoZSBjb250ZW50ICAgb2YgdGhlDQpjb25zdHJhaW50LiINClRoZSBiZWhh dmlvdXIgcHJvcG9zZWQgaW4gdGhpcyBkcmFmdCB3b3VsZCBoYXZlIHRvIGNyZWF0ZSBhbiBleGNl cHRpb24gZm9yDQphbGwgb2YgdGhlIGFib3ZlLg0KDQpBbHRlcm5hdGUgcHJvcG9zYWw6DQpDb3Vs ZCB0aGUgUFMgYmUgcGFydCBvZiBhbiBOU0EgTWV0cmljPyBBZnRlciBhbGwsIGl0IGlzIHVzZWQg dG8gaGVscA0Kc2VsZWN0IHdoaWNoIHBhcmVudChzKSBhcmUgYmVzdCBzdWl0ZWQgZm9yIHVwd2Fy ZCByb3V0aW5nLCBub3QgdG8gcHJ1bmUNCmRvd25saW5rIHByb3BhZ2F0aW9uIG9mIHRoZSBESU8g YWxvbmcgYSBwYXRoIHRoYXQgZXhjZWVkIHNvbWUgbWV0cmljDQp2YWx1ZS4gQz0wLCBSPTEsIFA9 MSBjb21lcyB0byBtaW5kIGZvciB0aGlzIG1ldHJpYy4NCkkgdW5kZXJzdGFuZCB0aGF0IHlvdSBh cmUgdHJ5aW5nIHRvIGNyZWF0ZSBhIENBIE9GIHRoYXQgbWltaWNrcyBhcyBtdWNoIG9mDQp0aGUg TVJIT0YgYXMgcG9zc2libGUsIGFuZCBNUkhPRiBzYXlzIGl0IGRvZXNuJ3QgdXNlIERNQ3MuIFNv IHlvdSB3b3VsZA0KaGF2ZSB0byBzcGVjaWZ5IHRoYXQgdGhlIENBIE9GIGlzIGRpZmZlcmVudCBp biB0aGF0IGl0IGhhcyB0byBsb29rIGF0IHRoZQ0KTlNBIE1ldHJpYyBzdWItb2JqZWN0IGluc2lk ZSB0aGUgRE1DIG9iamVjdC4gQnV0IGluIHRoZSBjdXJyZW50IHNpdHVhdGlvbiwNCnlvdSBhbHJl YWR5IGhhdmUgdG8gc3BlY2lmeSB0aGF0IHRoZSBDQSBPRiBoYXMgdG8gbG9vayBhdCB0aGUgTlNB DQpDb25zdHJhaW50IHN1Yi1vYmplY3QgaW5zaWRlIHRoZSBETUMgb2JqZWN0LiBXaXRoIGEgbWV0 cmljLCB5b3UgY291bGQgdXNlDQp0aGUgUHJlYy4gZmllbGQgdG8gaGlnaGxpZ2h0IHRoZSBmYWN0 IHRoYXQgdGhlIFBTIFRMViBzIGEgc2Vjb25kYXJ5DQptZXRyaWMsIGJleW9uZCB0aGUgaW1wbGll ZCBFVFggb2YgTVJIT0YuIE9yIHlvdSBjb3VsZCBzZW5kIHRoZSBFVFggTWV0cmljDQpzdWItb2Jq ZWN0IGV4cGxpY2l0ZWx5LCBhdCB0aGUgZXhwZW5zZSBvZiBhIGZldyBleHRyYSBieXRlcywgYW5k IHN0YXRlDQp0aGF0IHRoZSBDQSBPRiBzaW1wbHkgdXNlcyBETUNzLg0KDQpUaG91Z2h0cz8NCg0K RG9taW5pcXVlDQoNCkxlIDExLzAyLzIwIDExOjI1LCDCqyBSb2xsIG9uIGJlaGFsZiBvZiBHZW9y Z2lvcyBaLiBQYXBhZG9wb3Vsb3MgwrsNCjxyb2xsLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mDQpnZW9yZ2lvcy5wYXBhZG9wb3Vsb3NAaW10LWF0bGFudGlxdWUuZnI+IGEgw6ljcml0IDoN Cg0KPkRlYXIgUmFodWwgYW5kIGFsbCwNCj4NCj5PbmNlIGFnYWluLCB0aGFuayB5b3UgZm9yIHNw b3R0aW5nIHRoaXMgaXNzdWUuIEdyZWF0IGNhdGNoIQ0KPldlIGFyZSBoYXBweSB3aXRoIGFueSBv ZiB0aGUgZm9sbG93aW5nIHNvbHV0aW9ucyA6DQo+DQo+LSBXZSBjYW4gaW5kZWVkIHRpZSB0aGUg UFMgc2V0IG1ldHJpYyB0byBDQU9GIHNwZWNpZmljYWxseSBpbiB0aGUgZHJhZnQuDQo+RnVydGhl cm1vcmUsIHRoZSBwb2xpY2llcyBpbiBDQU9GIGFyZSBleHRlbnNpYmxlICh3ZSBvbmx5IHNwZWNp ZnkNCj5leGFtcGxlcyksIHNvIHBvdGVudGlhbGx5IGFub3RoZXIgcG9saWN5IGNvdWxkIG1ha2Ug YSBkaWZmZXJlbnQgdXNlIG9mIFBTDQo+YXMgcGFydCBvZiBDQU9GLg0KPg0KPi0gV2UgY2FuIGlu ZGVlZCBleHBsYWluIHRoZSBpc3N1ZSBpbiB0aGUgZHJhZnQgc28gdGhhdCB0aGUgaW1wbGVtZW50 ZXJzDQo+ZGVjaWRlIG9uIHRoZWlyIG93biBob3cgdG8gaGFuZGxlIGl0Lg0KPkFkZGl0aW9uYWxs eSwgc2luY2UgdGhlIHdob2xlIFJQTCBpbnN0YW5jZSB1c2VzIHRoZSBzYW1lIE9GLCB3ZSB3b3Vs ZA0KPmV4cGVjdCB0aGF0IGlmIGFuIE9GIHdoaWNoIHVuZGVyc3RhbmRzIHRoZSBUTFYgaXMgdXNl ZCwgdGhlbiBhbGwgdGhlDQo+bm9kZXMgd2lsbCBrbm93IGhvdyB0byBwcm9jZXNzIGl0Lg0KPlNv LCB0aGlzIGlzc3VlIHNob3VsZCBub3QgYmUgdmVyeSBjb21tb24uDQo+DQo+LSBBbm90aGVyIG9w dGlvbiB3b3VsZCBiZSB0byBhZGQgYW4gZXhjZXB0aW9uIHRvIHRoZSAiYWxsIFRMVnMgbmVlZCB0 byBiZQ0KPnByb3BhZ2F0ZWTigJ0gcnVsZSBmcm9tIFJGQyA2NTUxIHNwZWNpZmljYWxseSBmb3Ig dGhlIFBTIFRMVi4NCj5UaGUgZXhjZXB0aW9uIHdvdWxkIHNwZWNpZnkgdGhhdCB0aGUgUFMgVExW IHdvdWxkIGJlIGRyb3BwZWQgaWYgbm90DQo+dW5kZXJzdG9vZC4NCj4NCj4NCj5CZXN0IHJlZ2Fy ZHMsDQo+R2Vvcmdpb3MgYW5kIEFyaXMNCj4NCj4NCj4+IE9uIEZlYiAxMSwgMjAyMCwgYXQgMDQ6 MzIsIFJhaHVsIEphZGhhdiA8cmFodWwuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPj4gDQo+PiBI ZWxsbyBBdXRob3JzIG9mIE5TQSBleHRuIGFuZCBhbGwsDQo+PiANCj4+IE9uZSBtb3JlIHF1ZXN0 aW9uIGluIHRoZSBjb250ZXh0Og0KPj4gDQo+PiBUaGUgZHJhZnQgYWRkcyBuZXcgcm91dGluZyBt ZXRyaWNzL2NvbnN0cmFpbnRzIChQUyBzZXQpIG5lc3RlZCBhcyBwYXJ0DQo+PiBvZiB0aGUgTlNB IHBhcmVudCBtZXRyaWMuDQo+PiANCj4+IE15IHF1ZXN0aW9uIGlzIHdpdGggcmVnYXJkcyB0byB3 aGF0IGhhcHBlbnMgaWYgdGhpcyByb3V0aW5nIG1ldHJpYyBpcw0KPj4gdXNlZCBvdXRzaWRlIG9m IHRoZSBDQU9GLiBBbnkgbWV0cmljcy9jb25zdHJhaW50cyBjb3VsZCBiZSB1c2VkIGJ5IGFueQ0K Pj4gT0YgYW5kIHRodXMgUFMgc2V0IG1ldHJpYyBkZWZpbmVkIGJ5IHRoZSBkcmFmdCBjYW4gYmUg dXNlZCBieSBvdGhlcg0KPj4gT0YuDQo+PiANCj4+IFJGQyA2NTUxIHNheXMgdGhhdCBpZiB0aGUg bWV0cmljIGlzIG5vdCB1bmRlcnN0b29kIGJ5IHRoZSBub2RlIGFuZCBpZg0KPj4gaXQgaXMgYSA2 TFIgdGhlbiBpdCBtYXkgbm90IHByb2Nlc3MgaXQgYnV0IGl0IGhhcyB0byBwcm9wYWdhdGUgaXQu DQo+PiBVbmxpa2Ugb3RoZXIgbWV0cmljcywgdGhlIFBTIHNldCBtZXRyaWMgaW4gdGhpcyBjYXNl IGNvbnRhaW5zDQo+PiBsaW5rLWxvY2FsIHZhbHVlcyB0aGF0IGNhbm5vdCBiZSB1c2VkIGJleW9u ZCBsaW5rLWxvY2FsLiBBcyBzdWNoIHVwb24NCj4+IHByb3BhZ2F0aW9uLCBhbnkgZG93bnN0cmVh bSA2TFIgdGhhdCB1bmRlcnN0YW5kcyB0aGUgUFMgc2V0IG1ldHJpYw0KPj4gd291bGQgdXNlIHRo ZSBpbmZvcm1hdGlvbiBhbmQgZ2V0IGltcGFjdGVkIGFkdmVyc2VseS4NCj4+IA0KPj4gU2hvdWxk IHdlIHRpZSB0aGUgUFMgc2V0IG1ldHJpYyB0byBDQU9GIHNwZWNpZmljYWxseSBpbiB0aGUgZHJh ZnQsIGluDQo+PiB3aGljaCBjYXNlIHRoaXMgcHJvYmxlbSB3b24ndCBiZSB0aGVyZT8gT3Igd2Ug Y2FuIHNwZWNpZnkgdGhpcyBpc3N1ZQ0KPj4gYXMgaXQgaXMgZm9yIHRoZSByZWFkZXJzIHRvIHVu ZGVyc3RhbmQgdGhlIHByb2JsZW0gaWYgdGhlIFBTIHNldCBpcw0KPj4gdXNlZCBvdXRzaWRlIG9m IHRoZSBDQU9GLiBFaXRoZXIgd2F5IHdvcmtzIGZvciBtZS4NCj4+IA0KPj4gQmVzdCwNCj4+IFJh aHVsDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBSb2xsIG1haWxpbmcgbGlzdA0KPj4gUm9sbEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Sb2xsIG1haWxpbmcgbGlzdA0KPlJvbGxA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg0K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Feb 26 03:15:25 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062413A07D8 for ; Wed, 26 Feb 2020 03:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 PsEtLTucAjiq for ; Wed, 26 Feb 2020 03:15:19 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4868F3A07DC for ; Wed, 26 Feb 2020 03:15:19 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 48SCrj3z4dz2y3L; Wed, 26 Feb 2020 12:15:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582715717; bh=HQN+2nhtW5M/EEHe6Nb8C0THCpmrTx2EQKA8OH8g/6E=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=hvtpT5y3XHgd+xM84IiM3g6/Kogfvp6xQteTqeDzszFXHesvbzwtAYvfnNZL8COds Ec0HCFJ5/SVYY7d8qBazcqWRcL5aUkHQfQwoW8TFmXvyYb+WGcHF5Kv/MO/m9625cQ sRXU8R3SROFdKhS+UtUrldBu+8wHsOL4hUlc1Pb+m3uL5b7tVpb1qG3dQXonWGYZI5 lDlSoMsvyYPwiRQDMJuC+RF3GpfRVe21DIK35+BiNsyrq4wnGOpXIAyXgJGheZQC9K K6cNAjhoUVk/5SvhrLASt2cdqDQz6Roz/GsRJSLvWvdOowDGxCsaFbYylvl8ZLVAbM qwdwD2uYXIzOg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 48SCrj2Y7dz5vNB; Wed, 26 Feb 2020 12:15:17 +0100 (CET) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM5C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 26 Feb 2020 12:15:17 +0100 From: To: Routing Over Low power and Lossy networks , "Georgios Z. Papadopoulos" , "Remous-Aris Koutsiamanis" Thread-Topic: [Roll] Fwd: New Version Notification for draft-ietf-roll-nsa-extension-06.txt Thread-Index: AQHV7JYF8Wj72BihnEKZ4vuwzHbXvw== Date: Wed, 26 Feb 2020 11:15:16 +0000 Message-ID: <25766_1582715717_5E565345_25766_121_1_DA7C0EE9.71074%dominique.barthel@orange.com> References: <158134776694.4117.16175545100765405335.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_DA7C0EE971074dominiquebarthelorangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-nsa-extension-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 11:15:24 -0000 --_000_DA7C0EE971074dominiquebarthelorangecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpBbm90aGVyIGNvbW1lbnQgYWJvdXQgdGhpcyBkcmFmdC4gVGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gY3VycmVudGx5IHNheXMNCiIgVGhlIHN0cnVjdHVy ZSBvZiB0aGUgRElPIGNvbnRyb2wgbWVzc2FnZSBpcyBleHRlbmRlZCwgd2l0aGluIHRoZSBwcmUt DQogICBkZWZpbmVkIERJTyBvcHRpb25zLiAgVGhlcmVmb3JlLCB0aGUgc2VjdXJpdHkgbWVjaGFu aXNtcyBkZWZpbmVkIGluDQogICBSUEwgW1JGQzY1NTBdIGFwcGx5IHRvIHRoaXMgcHJvcG9zZWQg ZXh0ZW5zaW9uLiINCkkgZG9uJ3QgdGhpbmsgdGhpcyBhZGRyZXNzZXMgdGhlIHB1cnBvc2Ugb2Yg YSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KDQpJIHRoaW5rIGl0IHNob3VsZCB0 YWxrIGFib3V0IHRoZSBwb3RlbnRpYWwgc2VjdXJpdHkgaXNzdWVzIGludHJvZHVjZWQgYnkgdGhl IGRyYWZ0LCBhbmQgd2h5IHRoZXkgYXJlIG5vdCByZWFsIGNvbmNlcm5zLg0KSSBndWVzcyB0aGF0 LCB3aGF0IHRoaXMgZHJhZnQgY2hhbmdlcyBjb21wYXJlZCB0byBSRkM2NTUwLTY1NTEsIGlzIHRo ZSBzZW5kaW5nIG9mIHRoZSBQYXJlbnQgU2V0IG9mIGEgbm9kZSBpbiBpdHMgRElPLiBGcm9tIHRo ZXJlOg0KLSBUaGlzIGNvdWxkIHJlc3VsdCBpbiBhIHByaXZhY3kgaXNzdWUuIFllcywgYnV0IHRo ZSBQYXJlbnQgU2V0IGlzIG5vdCBwcm9wYWdhdGVkIGZ1cnRoZXIgZG93biB0aGUgRE9EQUcsIHNv IHRoaXMgZGlzY2xvc3VyZSBkb2VzIG5vdCByZWFjaCBmYXIgYmV5b25kIHRoZSBwcm9wYWdhdGlv biByYW5nZSBvZiB0aGUgcmFkaW9zIG9mIHRoZSBQYXJlbnRzLiBTbyBubyB0cmFja2luZyBvZiBu b2RlcyBieSB0aGVpciBJUHY2IGFkZHJlc3MgcG9zc2libGUgZnJvbSByZW1vdGUgKGEgbGVhc3Qg bm8gbW9yZSB0aGFuIGluIHRoZSBjdXJyZW50IHNpdHVhdGlvbikuDQotIFRoaXMgY291bGQgcmVz dWx0IGluIGludHJvZHVjaW5nIGEgdnVsbmVyYWJpbGl0eTogY291bGQgYW4gYXR0YWNrZXIgZXhw bG9pdCB0aGUga25vd2xlZGdlIGdhaW5lZCBmcm9tIGxlYXJuaW5nIHRoZSBQUz8g4oCmDQoNCkJl c3QgcmVnYXJkcw0KRG9taW5pcXVlDQoNCkRlIDogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgIkdlb3JnaW9zIFou IFBhcGFkb3BvdWxvcyIgPGdlb3JnaW9zLnBhcGFkb3BvdWxvc0BpbXQtYXRsYW50aXF1ZS5mcjxt YWlsdG86Z2Vvcmdpb3MucGFwYWRvcG91bG9zQGltdC1hdGxhbnRpcXVlLmZyPj4NClLDqXBvbmRy ZSDDoCA6ICJyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPiIgPHJvbGxAaWV0Zi5v cmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0KRGF0ZSA6IE1vbmRheSAxMCBGZWJydWFyeSAyMDIw IDE2OjUxDQrDgCA6ICJyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPiIgPHJvbGxA aWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0KT2JqZXQgOiBbUm9sbF0gRndkOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtcm9sbC1uc2EtZXh0ZW5zaW9uLTA2 LnR4dA0KDQpEZWFyIGFsbCwNCg0KRllJLCB3ZSBqdXN0IHN1Ym1pdHRlZCB0aGUgMDYgdmVyc2lv biB3aGVyZSB3ZSBhZGRyZXNzZWQgdGhlIGNvbW1lbnRzIGZyb20gUmFodWwuDQoNCk1hbnkgdGhh bmtzIFJhaHVsLA0KR2Vvcmdpb3MgYW5kIEFyaXMNCg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2Fn ZToNCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWlldGYtcm9sbC1uc2EtZXh0ZW5zaW9uLTA2LnR4dA0KRGF0ZTogRmVicnVhcnkgMTAsIDIwMjAg YXQgMTY6MTY6MDYgR01UKzENClRvOiAiTmljb2xhcyBNb250YXZvbnQiIDxuaWNvbGFzLm1vbnRh dm9udEBpbXQtYXRsYW50aXF1ZS5mcjxtYWlsdG86bmljb2xhcy5tb250YXZvbnRAaW10LWF0bGFu dGlxdWUuZnI+PiwgIlBhc2NhbCBUaHViZXJ0IiA8cHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpw dGh1YmVydEBjaXNjby5jb20+PiwgIkdlb3JnaW9zIFBhcGFkb3BvdWxvcyIgPGdlb3JnaW9zLnBh cGFkb3BvdWxvc0BpbXQtYXRsYW50aXF1ZS5mcjxtYWlsdG86Z2Vvcmdpb3MucGFwYWRvcG91bG9z QGltdC1hdGxhbnRpcXVlLmZyPj4sICJSZW1vdXMtQXJpcyBLb3V0c2lhbWFuaXMiIDxhcmlzQGFy aXNrb3UuY29tPG1haWx0bzphcmlzQGFyaXNrb3UuY29tPj4NCg0KDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtaWV0Zi1yb2xsLW5zYS1leHRlbnNpb24tMDYudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJlbW91cy1BcmlzIEtvdXRzaWFtYW5pcyBhbmQgcG9zdGVk IHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1pZXRmLXJvbGwtbnNhLWV4 dGVuc2lvbg0KUmV2aXNpb246IDA2DQpUaXRsZTogQ29tbW9uIEFuY2VzdG9yIE9iamVjdGl2ZSBG dW5jdGlvbiBhbmQgUGFyZW50IFNldCBEQUcgTWV0cmljIENvbnRhaW5lciBFeHRlbnNpb24NCkRv Y3VtZW50IGRhdGU6IDIwMjAtMDItMTANCkdyb3VwOiByb2xsDQpQYWdlczogMTUNClVSTDogICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1y b2xsLW5zYS1leHRlbnNpb24tMDYudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLW5zYS1leHRlbnNpb24vDQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC1uc2Et ZXh0ZW5zaW9uLTA2DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLXJvbGwtbnNhLWV4dGVuc2lvbg0KRGlmZjogICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJvbGwtbnNhLWV4 dGVuc2lvbi0wNg0KDQpBYnN0cmFjdDoNCiAgSW1wbGVtZW50aW5nIFBhY2tldCBSZXBsaWNhdGlv biBhbmQgRWxpbWluYXRpb24gZnJvbS90byB0aGUgUlBMIHJvb3QNCiAgcmVxdWlyZXMgdGhlIGFi aWxpdHkgdG8gZm9yd2FyZCBjb3BpZXMgb2YgcGFja2V0cyBvdmVyIGRpZmZlcmVudA0KICBwYXRo cyB2aWEgZGlmZmVyZW50IFJQTCBwYXJlbnRzLiAgU2VsZWN0aW5nIHRoZSBhcHByb3ByaWF0ZSBw YXJlbnRzDQogIHRvIGFjaGlldmUgdWx0cmEtbG93IGxhdGVuY3kgYW5kIGppdHRlciByZXF1aXJl cyBpbmZvcm1hdGlvbiBhYm91dCBhDQogIG5vZGUncyBwYXJlbnRzLiAgVGhpcyBkb2N1bWVudCBk ZXRhaWxzIHdoYXQgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUNCiAgdHJhbnNtaXR0ZWQgYW5kIGhv dyBpdCBpcyBlbmNvZGVkIHdpdGhpbiBSUEwgY29udHJvbCBwYWNrZXRzIHRvDQogIGVuYWJsZSB0 aGlzIGZ1bmN0aW9uYWxpdHkuICBUaGlzIGRvY3VtZW50IGFsc28gZGVzY3JpYmVzIE9iamVjdGl2 ZQ0KICBGdW5jdGlvbiB3aGljaCB0YWtlIGFkdmFudGFnZSBvZiB0aGlzIGluZm9ybWF0aW9uIHRv IGltcGxlbWVudCBtdWx0aS0NCiAgcGF0aCByb3V0aW5nLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_DA7C0EE971074dominiquebarthelorangecom_ Content-Type: text/html; charset="utf-8" Content-ID: <23EB154176A5CD4FB8B3377988E66E6D@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IZWxsbyBhbGws PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Bbm90aGVyIGNvbW1lbnQgYWJvdXQgdGhp cyBkcmFmdC4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gY3VycmVudGx5IHNh eXM8L2Rpdj4NCjxkaXY+JnF1b3Q7IFRoZSBzdHJ1Y3R1cmUgb2YgdGhlIERJTyBjb250cm9sIG1l c3NhZ2UgaXMgZXh0ZW5kZWQsIHdpdGhpbiB0aGUgcHJlLTwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5i c3A7ZGVmaW5lZCBESU8gb3B0aW9ucy4gJm5ic3A7VGhlcmVmb3JlLCB0aGUgc2VjdXJpdHkgbWVj aGFuaXNtcyBkZWZpbmVkIGluPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtSUEwgW1JGQzY1NTBd IGFwcGx5IHRvIHRoaXMgcHJvcG9zZWQgZXh0ZW5zaW9uLiZxdW90OzwvZGl2Pg0KPGRpdj5JIGRv bid0IHRoaW5rIHRoaXMgYWRkcmVzc2VzIHRoZSBwdXJwb3NlIG9mIGEgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdGhpbmsg aXQgc2hvdWxkIHRhbGsgYWJvdXQgdGhlIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZXMgaW50cm9k dWNlZCBieSB0aGUgZHJhZnQsIGFuZCB3aHkgdGhleSBhcmUgbm90IHJlYWwgY29uY2VybnMuPC9k aXY+DQo8ZGl2PkkgZ3Vlc3MgdGhhdCwgd2hhdCB0aGlzIGRyYWZ0IGNoYW5nZXMgY29tcGFyZWQg dG8gUkZDNjU1MC02NTUxLCBpcyB0aGUgc2VuZGluZyBvZiB0aGUgUGFyZW50IFNldCBvZiBhIG5v ZGUgaW4gaXRzIERJTy4gRnJvbSB0aGVyZTo8L2Rpdj4NCjxkaXY+LSBUaGlzIGNvdWxkIHJlc3Vs dCBpbiBhIHByaXZhY3kgaXNzdWUuIFllcywgYnV0IHRoZSBQYXJlbnQgU2V0IGlzIG5vdCBwcm9w YWdhdGVkIGZ1cnRoZXIgZG93biB0aGUgRE9EQUcsIHNvIHRoaXMgZGlzY2xvc3VyZSBkb2VzIG5v dCByZWFjaCBmYXIgYmV5b25kIHRoZSBwcm9wYWdhdGlvbiByYW5nZSBvZiB0aGUgcmFkaW9zIG9m IHRoZSBQYXJlbnRzLiBTbyBubyB0cmFja2luZyBvZiBub2RlcyBieSB0aGVpciBJUHY2IGFkZHJl c3MgcG9zc2libGUNCiBmcm9tIHJlbW90ZSAoYSBsZWFzdCBubyBtb3JlIHRoYW4gaW4gdGhlIGN1 cnJlbnQgc2l0dWF0aW9uKS48L2Rpdj4NCjxkaXY+LSBUaGlzIGNvdWxkIHJlc3VsdCBpbiBpbnRy b2R1Y2luZyBhIHZ1bG5lcmFiaWxpdHk6IGNvdWxkIGFuIGF0dGFja2VyIGV4cGxvaXQgdGhlIGtu b3dsZWRnZSBnYWluZWQgZnJvbSBsZWFybmluZyB0aGUgUFM/IOKApjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzPC9kaXY+DQo8ZGl2PkRvbWluaXF1ZTwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkRlJm5ic3A7OiA8L3NwYW4+Um9sbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJv bGwtYm91bmNlc0BpZXRmLm9yZyI+cm9sbC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVo YWxmIG9mICZxdW90O0dlb3JnaW9zIFouIFBhcGFkb3BvdWxvcyZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmdlb3JnaW9zLnBhcGFkb3BvdWxvc0BpbXQtYXRsYW50aXF1ZS5mciI+Z2Vvcmdpb3Mu cGFwYWRvcG91bG9zQGltdC1hdGxhbnRpcXVlLmZyPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+UsOpcG9uZHJlIMOgJm5ic3A7OiA8L3NwYW4+JnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciPnJvbGxAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGUmbmJzcDs6IDwvc3Bhbj5Nb25kYXkgMTAg RmVicnVhcnkgMjAyMCAxNjo1MTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj7D gCZuYnNwOzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xs QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciPnJv bGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5P YmpldCZuYnNwOzogPC9zcGFuPltSb2xsXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaWV0Zi1yb2xsLW5zYS1leHRlbnNpb24tMDYudHh0PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkRlYXIgYWxsLCA8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkZZSSwgd2UganVz dCBzdWJtaXR0ZWQgdGhlIDA2IHZlcnNpb24gd2hlcmUgd2UgYWRkcmVzc2VkIHRoZSBjb21tZW50 cyBmcm9tIFJhaHVsLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+TWFueSB0aGFua3MgUmFodWwsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdl b3JnaW9zIGFuZCBBcmlzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PC9kaXY+DQo8YnIgY2xhc3M9 IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4 OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4 OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZv bnQsICdIZWx2ZXRpY2EgTmV1ZScsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigw LCAwLCAwKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZyb206DQo8L2I+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgJ0hlbHZldGljYSBOZXVlJywg SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyIgY2xhc3M9IiI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjxi ciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsg bWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250 LCAnSGVsdmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5TdWJqZWN0Og0KPC9iPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsICdIZWx2ZXRpY2EgTmV1ZScs IEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPk5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLW5zYS1leHRlbnNpb24tMDYudHh0PC9i PjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBw eDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1m b250LCAnSGVsdmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MCwgMCwgMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5EYXRlOg0KPC9iPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsICdIZWx2ZXRpY2EgTmV1ZScs IEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZlYnJ1YXJ5IDEwLCAyMDIwIGF0IDE2 OjE2OjA2IEdNVCYjNDM7MTxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsg bWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAt d2Via2l0LXN5c3RlbS1mb250LCAnSGVsdmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5UbzoNCjwvYj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCAnSGVs dmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mcXVvdDtOaWNv bGFzIE1vbnRhdm9udCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pY29sYXMubW9udGF2b250 QGltdC1hdGxhbnRpcXVlLmZyIiBjbGFzcz0iIj5uaWNvbGFzLm1vbnRhdm9udEBpbXQtYXRsYW50 aXF1ZS5mcjwvYT4mZ3Q7LCAmcXVvdDtQYXNjYWwgVGh1YmVydCZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSIgY2xhc3M9IiI+cHRodWJlcnRAY2lzY28uY29tPC9h PiZndDssDQogJnF1b3Q7R2Vvcmdpb3MgUGFwYWRvcG91bG9zJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86Z2Vvcmdpb3MucGFwYWRvcG91bG9zQGltdC1hdGxhbnRpcXVlLmZyIiBjbGFzcz0iIj5n ZW9yZ2lvcy5wYXBhZG9wb3Vsb3NAaW10LWF0bGFudGlxdWUuZnI8L2E+Jmd0OywgJnF1b3Q7UmVt b3VzLUFyaXMgS291dHNpYW1hbmlzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YXJpc0Bhcmlz a291LmNvbSIgY2xhc3M9IiI+YXJpc0Bhcmlza291LmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0K PC9zcGFuPjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtcm9sbC1u c2EtZXh0ZW5zaW9uLTA2LnR4dDxiciBjbGFzcz0iIj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgUmVtb3VzLUFyaXMgS291dHNpYW1hbmlzIGFuZCBwb3N0ZWQgdG8gdGhlPGJy IGNsYXNzPSIiPg0KSUVURiByZXBvc2l0b3J5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Ck5hbWU6PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl Ij4gPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNl OnByZSI+PC9zcGFuPmRyYWZ0LWlldGYtcm9sbC1uc2EtZXh0ZW5zaW9uPGJyIGNsYXNzPSIiPg0K UmV2aXNpb246PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj4gPC9zcGFuPjA2PGJyIGNsYXNzPSIiPg0KVGl0bGU6PHNwYW4gY2xhc3M9IkFwcGxlLXRh Yi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4gPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBs ZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkNvbW1vbiBBbmNlc3Rv ciBPYmplY3RpdmUgRnVuY3Rpb24gYW5kIFBhcmVudCBTZXQgREFHIE1ldHJpYyBDb250YWluZXIg RXh0ZW5zaW9uPGJyIGNsYXNzPSIiPg0KRG9jdW1lbnQgZGF0ZTo8c3BhbiBjbGFzcz0iQXBwbGUt dGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+MjAyMC0wMi0xMDxiciBj bGFzcz0iIj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRl LXNwYWNlOnByZSI+IDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5yb2xsPGJyIGNsYXNzPSIiPg0KUGFnZXM6PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4gPC9zcGFuPjxzcGFu IGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPjE1 PGJyIGNsYXNzPSIiPg0KVVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1yb2xsLW5zYS1leHRlbnNpb24tMDYudHh0IiBj bGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1y b2xsLW5zYS1leHRlbnNpb24tMDYudHh0PC9hPjxiciBjbGFzcz0iIj4NClN0YXR1czogJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLW5zYS1leHRlbnNpb24v IiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJv bGwtbnNhLWV4dGVuc2lvbi88L2E+PGJyIGNsYXNzPSIiPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXJvbGwtbnNhLWV4dGVuc2lvbi0wNiIgY2xhc3M9IiI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC1uc2EtZXh0ZW5zaW9uLTA2PC9hPjxi ciBjbGFzcz0iIj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtcm9sbC1uc2EtZXh0ZW5zaW9uIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtcm9sbC1uc2EtZXh0ZW5zaW9uPC9hPjxiciBjbGFzcz0i Ij4NCkRpZmY6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLXJvbGwtbnNhLWV4dGVuc2lvbi0wNiIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcm9sbC1uc2EtZXh0ZW5zaW9uLTA2PC9hPjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwO0ltcGxlbWVudGluZyBQYWNrZXQgUmVwbGljYXRpb24gYW5kIEVsaW1pbmF0aW9uIGZy b20vdG8gdGhlIFJQTCByb290PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7cmVxdWlyZXMgdGhl IGFiaWxpdHkgdG8gZm9yd2FyZCBjb3BpZXMgb2YgcGFja2V0cyBvdmVyIGRpZmZlcmVudDxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwO3BhdGhzIHZpYSBkaWZmZXJlbnQgUlBMIHBhcmVudHMuICZu YnNwO1NlbGVjdGluZyB0aGUgYXBwcm9wcmlhdGUgcGFyZW50czxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwO3RvIGFjaGlldmUgdWx0cmEtbG93IGxhdGVuY3kgYW5kIGppdHRlciByZXF1aXJlcyBp bmZvcm1hdGlvbiBhYm91dCBhPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7bm9kZSdzIHBhcmVu dHMuICZuYnNwO1RoaXMgZG9jdW1lbnQgZGV0YWlscyB3aGF0IGluZm9ybWF0aW9uIG5lZWRzIHRv IGJlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7dHJhbnNtaXR0ZWQgYW5kIGhvdyBpdCBpcyBl bmNvZGVkIHdpdGhpbiBSUEwgY29udHJvbCBwYWNrZXRzIHRvPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7ZW5hYmxlIHRoaXMgZnVuY3Rpb25hbGl0eS4gJm5ic3A7VGhpcyBkb2N1bWVudCBhbHNv IGRlc2NyaWJlcyBPYmplY3RpdmU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtGdW5jdGlvbiB3 aGljaCB0YWtlIGFkdmFudGFnZSBvZiB0aGlzIGluZm9ybWF0aW9uIHRvIGltcGxlbWVudCBtdWx0 aS08YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtwYXRoIHJvdXRpbmcuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnIiBjbGFzcz0iIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48 L2JvZHk+DQo8L2h0bWw+DQo= --_000_DA7C0EE971074dominiquebarthelorangecom_-- From nobody Wed Feb 26 05:56:12 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7693A05A4; Wed, 26 Feb 2020 05:56:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <158272536546.17855.2618224481014089057@ietfa.amsl.com> Date: Wed, 26 Feb 2020 05:56:05 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-36.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 13:56:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Using RPI option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane Authors : Maria Ines Robles Michael C. Richardson Pascal Thubert Filename : draft-ietf-roll-useofrplinfo-36.txt Pages : 58 Date : 2020-02-26 Abstract: This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC6553 (RPI option Type), RFC6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC6553 adding a change to the RPI option Type. Additionally, this document updates RFC6550 defining a flag in the DIO Configuration option to indicate about this change and updates RFC8138 as well to consider the new Option Type when the RPL Option is decompressed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-36 https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-36 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-36 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 28 14:37:48 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D11853A1F9F; Fri, 28 Feb 2020 14:35:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: aretana.ietf@gmail.com, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292931483.19931.9038155485765852344@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:14 -0800 Archived-At: Subject: [Roll] roll - Requested sessions have been scheduled for IETF 107 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:20 -0000 Dear Dominique Barthel, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. roll Session 1 (1:00 requested) Monday, 23 March 2020, Afternoon Session III 1810-1910 Room Name: Plaza A size: 100 --------------------------------------------- roll Session 2 (2:00 requested) Tuesday, 24 March 2020, Afternoon Session I 1330-1530 Room Name: Georgia A size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/roll.ics Request Information: --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Dominique Barthel Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: anima manet 6tisch core ace lpwan Technology Overlap: rtgarea 6lo 6man lwig cbor t2trg Key Participant Conflict: rtgwg intarea People who must be present: Michael Richardson Dominique Barthel Alvaro Retana Ines Robles Resources Requested: Special Requests: One of the WG chairs will be leaving on Thursday during the day, could we please have both sessions by Wednesday night. --------------------------------------------------------- From nobody Fri Feb 28 15:30:35 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E043A1F4E; Fri, 28 Feb 2020 15:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3aX8x_pfqQv0; Fri, 28 Feb 2020 15:30:14 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3BE3A07D0; Fri, 28 Feb 2020 15:30:13 -0800 (PST) Received: from [172.16.42.113] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48Tlk33DdDz1802; Sat, 29 Feb 2020 00:14:51 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 604624491.173988-8e58a591363de0339278de6e98b094dd Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: Date: Sat, 29 Feb 2020 00:14:51 +0100 To: 6lo@ietf.org, 6tisch@ietf.org, lp-wan@ietf.org, lwip@ietf.org, roll@ietf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Roll] Constrained Node/Network Cluster @ IETF107: FINAL AGENDA X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 23:30:18 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF107. Remember that, occasionally, futher agenda changes do happen. Not much change from the DRAFT AGENDA. SUIT has moved to Friday, now on top of 6lo. The other security/not-so-much-security conflicts in the IoT space remain or have just been rearranged: ROLL vs. COSE/TEEP, LPWAN vs. SAAG, and LAKE vs. RATS, WPACK vs. ACE; as are MODEL-T vs. CORE and TXAUTH vs. T2TRG. (A lot of the rooms have changed.) All times are in PDT =3D=3D UTC - 7 hours. Note that North America is = on DST already during the IETF, while Europe will only go there on March 29, so we are in the three-week period of DST confusion (where the US is one hour closer to the EU than the rest of the year). (Pure UTC times at https://datatracker.ietf.org/meeting/agenda-utc are useful for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, March 20, 2020 0900-1800 T2TRG/W3C WoT Workshop = https://github.com/t2trg/2020-03-vancouver SATURDAY, March 21, 2020 0830-2200 IETF Hackathon - Plaza Ballroom SUNDAY, March 22, 2020 0830-1600 IETF Hackathon - Plaza Ballroom 1700-1900 Welcome Reception - Regency A/B/C/D 1800-2000 Hot RFC Lightning Talks -- Plaza B/C MONDAY, March 23, 2020 1000-1200 Morning Session I Regency D ART dispatch Dispatch WG - Joint with ARTAREA Regency C INT 6man IPv6 Maintenance WG Plaza B/C IRTF pearg Privacy Enhancements and Assessments = Research Group 1330-1530 Afternoon Session I Regency C ART webtrans WebTransport WG Regency D IRTF maprg Measurement and Analysis for Protocols Georgia B SEC mls Messaging Layer Security WG Regency E SEC oauth Web Authorization Protocol WG Plaza A SEC *** rats Remote ATtestation ProcedureS WG 1550-1750 Afternoon Session II Regency F INT add Adaptive DNS Discovery WG Regency C IRTF irtfopen IRTF Open Meeting Regency E OPS anima Autonomic Networking Integrated Model = and Approach WG Plaza A RTG raw Reliable and Available Wireless WG Plaza B/C SEC secdispatch Security Dispatch WG 1810-1910 Afternoon Session III Plaza A RTG *** roll Routing Over Low power and Lossy = networks WG Georgia B SEC *** cose CBOR Object Signing and Encryption WG Plaza B/C SEC tls Transport Layer Security WG Regency C TSV tsvarea Transport Area Open Meeting TUESDAY, March 24, 2020 0830-0945 Side Meetings / Open Time Regency C tdd Technology Deep Dive 1000-1200 Morning Session I Regency D IRTF*** dinrg Decentralized Internet Infrastructure Regency F SEC acme Automated Certificate Management = Environment WG Regency E SEC *** teep Trusted Execution Environment = Provisioning WG Plaza B/C TSV quic QUIC WG 1330-1530 Afternoon Session I Regency C INT masque Multiplexed Application Substrate over = QUIC Encryption BOF Regency D IRTF coinrg Computing in the Network Research Group Georgia A RTG *** roll Routing Over Low power and Lossy = networks WG Regency E SEC emu EAP Method Update WG Georgia B SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1720 Afternoon Session II Regency F ART *** core Constrained RESTful Environments WG Plaza A IRTF qirg Quantum Internet Proposed Research Group Georgia B SEC oauth Web Authorization Protocol WG Regency C TSV tsvwg Transport Area Working Group WG 1740-1840 Afternoon Session III Regency C INT 6man IPv6 Maintenance WG Georgia B INT *** drip Drone Remote ID Protocol WG Georgia A RTG babel Babel routing protocol WG Regency D RTG detnet Deterministic Networking WG Regency E RTG rift Routing In Fat Trees WG Plaza B/C TSV quic QUIC WG WEDNESDAY, March 25, 2020 1000-1200 Morning Session I Georgia B IRTF*** t2trg Thing-to-Thing Georgia A RTG bier Bit Indexed Explicit Replication WG Regency D SEC txauth Transactional Authorization and = Delegation BOF Plaza B/C TSV quic QUIC WG 1330-1500 Afternoon Session I Regency C ART wpack Web Packaging BOF Regency E IRTF panrg Path Aware Networking RG Georgia A SEC *** ace Authentication and Authorization for = Constrained Environments WG 1520-1650 Afternoon Session II Plaza A ART *** core Constrained RESTful Environments WG Georgia A IAB model-t Internet Threat Model Plaza B/C RTG rtgarea Routing Area Open Meeting 1710-1940 IETF Plenary - Regency C/D/E/F THURSDAY, March 26, 2020 1000-1200 Morning Session I Georgia A ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Georgia B INT dnssd Extensions for Scalable DNS Service = Discovery WG - Joint with HOMENET Georgia B INT homenet Home Networking WG - Joint with DNSSD Regency E IRTF icnrg Information-Centric Networking Regency C SEC privacypass privacy-pass BOF Plaza B/C TSV taps Transport Services WG 1330-1530 Afternoon Session I Regency E INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Regency F OPS v6ops IPv6 Operations WG Regency D SEC saag Security Area Open Meeting 1550-1720 Afternoon Session II Regency C ART httpbis HTTP WG Regency E INT intarea Internet Area Working Group WG Regency D IRTF cfrg Crypto Forum Plaza B/C RTG detnet Deterministic Networking WG 1740-1840 Afternoon Session III Plaza A ART uta Using TLS in Applications WG Regency D OPS anima Autonomic Networking Integrated Model = and Approach WG FRIDAY, March 27, 2020 1000-1200 Morning Session I Regency F INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Regency E SEC *** suit Software Updates for Internet of Things = WG Regency C SEC tls Transport Layer Security WG Plaza B/C TSV tsvwg Transport Area Working Group WG 1220-1350 Morning Session II Regency D ART httpbis HTTP WG Regency C IRTF coinrg Computing in the Network Research Group Regency F SEC *** lake Lightweight Authenticated Key Exchange = WG Plaza A SEC *** rats Remote ATtestation ProcedureS WG From nobody Fri Feb 28 15:52:08 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA823A041A for ; Fri, 28 Feb 2020 15:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com header.b=FnGJHDFt; dkim=pass (2048-bit key) header.d=ariskou.com header.b=DWTk29Rt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTwj_ks97VRw for ; Fri, 28 Feb 2020 15:52:02 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F853A0408 for ; Fri, 28 Feb 2020 15:52:01 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id DD0EF1B72 for ; Sat, 29 Feb 2020 00:51:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1582933919; bh=iZaD2KpshyW7H+70dUOFmDAM/B5JMGIQv8pNdZA48xA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FnGJHDFtbIkfchTGObQoQxlg9zJd2c6euoW0t9bVdT3inArVQS4Qnas8DRB2TrpOq 0kLHdoSdy9jZ3AxI7Kj2XWEn89z+YIJaziXav/1oY6Dd/FMV23/AHaVNSbpAYksZj1 G5oTuIaa/N/UtcTNl/UxaQ+I2MBZdZrJ2Sd5Ogf071Ky+aGOLZTn0e1Ge8jY+d7b2o 1ZjdopmeM45QA0apzMsmGXwSDdafL7U+gxCt54HlMyZOTXmLiAN2B9G2QOIiNUT+iL +6MPcIxeCjL/nBTVfp4OgRLzWMPKsJuaPNZwjG+Si8GZBazvm2pFvhUKudcFMGqu7s zvaVm+w8qtfzQ== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1582933919; s=20191001-wvim; d=ariskou.com; i=aris@ariskou.com; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Content-Type; l=21522; bh=iZaD2KpshyW7H+70dUOFmDAM/B5JMGIQv8pNdZA48xA=; b=DWTk29RtIcXVS3eqtfncsas94T9h0xNF2WpE1tdR7UlmyGusJnm8vqFlBOQhMDlK JajI41uYiW0D2cIcCl0ASZWH6oDXqB1pZX86WwWSdp5i5qBFYpVmSPpJK/MRBMV2aZa SspS8ErcnF5BI/gcmTX1cit9R9JmKBwmLywMnXjpg6Nuz2Ws+HZdOBZBIAYcZQfgv9W yWR5KQEBr9xt3KiZQEkDDXvAOkkQ6HaXryUvKfpsihIGdIJKUtCb048HEoP9lDx+Hg3 jQiv68LLQmS6EMnMGVdfbTBCtElNiZH+wFRfrGSQQX0g7sKb22fbGCTKDl/hFsx/UAE fd2HBCiUHg== Received: by smtp.mailfence.com with ESMTPA for ; Sat, 29 Feb 2020 00:51:54 +0100 (CET) Received: by mail-il1-f172.google.com with SMTP id a6so4333878ilc.4 for ; Fri, 28 Feb 2020 15:51:53 -0800 (PST) X-Gm-Message-State: APjAAAXJnyl2v4NktmndHdxsUYE8KAWBNrGS4uWjN3UbUFrgbppzHlx8 +kvjAaLB2DX+2j7FXXrdADW3ZAA1FL6K/UkOabg= X-Google-Smtp-Source: APXvYqzP9mGq46rh4f03i31G6MBXeTvH4zU60/AM3e9YmIYfD60Rg7Rhd9NXOxPQziF9B8PEXxioPr5MT1o1ftxoy5Q= X-Received: by 2002:a05:6e02:c8d:: with SMTP id b13mr6961519ile.42.1582933909240; Fri, 28 Feb 2020 15:51:49 -0800 (PST) MIME-Version: 1.0 References: <28813_1582714957_5E56504D_28813_497_1_DA7C05D5.71025%dominique.barthel@orange.com> In-Reply-To: <28813_1582714957_5E56504D_28813_497_1_DA7C05D5.71025%dominique.barthel@orange.com> From: Remous-Aris Koutsiamanis Date: Sat, 29 Feb 2020 00:51:56 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: dominique barthel Cc: Routing Over Low power and Lossy networks , "Georgios Z. Papadopoulos" , Rahul Jadhav Content-Type: multipart/alternative; boundary="0000000000005d00a8059fab85b2" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] NSA PS-set metric/constraint X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 23:52:05 -0000 --0000000000005d00a8059fab85b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Dominique, thank you very very much for this. Comments inline. On Wed, Feb 26, 2020 at 12:02 PM wrote: > Hello all, > > The discussion below prompts me to question the way the Parent Set (PS) > appears in the Dodag Metric Container (DMC). Sorry if this comes up late > in the process. > Oh, better now than later :) > The NSA object carrying the PS TLV is currently specified to be Contraint= . > This shows up only once in the text (page 11). > There are some issues associated with the PS being part of a constraint: > RFC6551 says > "In the presence of a constraint, a node MUST include a metric of the > same type. That metric is used to check whether or not the constraint > is met. In all cases, a node MUST not change the content of the > constraint." > The behaviour proposed in this draft would have to create an exception fo= r > all of the above. > You are, of course, absolutely right. It is interesting that when we started this work (draft-pkm-roll-nsa-extension-00 / April 2018) we initially specified a metric instead of a constraint, but in the immediately next version (draft-koutsiamanis-roll-nsa-extension-01 / July 2018) we switched to the constraint specification. I absolutely agree that making an exception to this is undesirable. >From the very first moment we wanted to avoid changing as few things as possible to keep things simple and predictable. > Alternate proposal: > Could the PS be part of an NSA Metric? After all, it is used to help > select which parent(s) are best suited for upward routing, not to prune > downlink propagation of the DIO along a path that exceed some metric > value. C=3D0, R=3D1, P=3D1 comes to mind for this metric. > So I read a bit more about this. So C=3D0 means "use as a routing metric", = OK. R=3D1 means "use as a recorded metric", i.e. not aggregated, because aggregated makes no sense, OK. Now, P=3D1 means that one or more of the nodes on the path did not record t= he metric. So, it's less a "command" and more a report of previous behaviour. My question is: it seems impossible that *all* the parent sets can be recorded along the path due to size, so each node *replaces* the received parent set with it's own. We can specify this with text of course, but I have not seen another existing metric that behaves like this. On the other hand, the NSA metric object is not used a lot, and if it makes sense for any metric to be replaced rather then appended to a list of metrics, that metric would be NSA. I am not sure about that P=3D1 part though and how it relates to replacing the existing metrics. If I understand this correctly, a node reporting it's own parent set in the NSA will set P=3D1 basically to let the receiving nodes know that they shou= ld not expect to find inside all the metric along the whole path, but only a part of it, and in our case from just the sending node. Am I getting this right? > I understand that you are trying to create a CA OF that mimicks as much o= f > the MRHOF as possible, and MRHOF says it doesn't use DMCs. Actually, MRHOF does use DMCs, but only additive ones: page 3: "Because MRHOF seeks to minimize path costs as described by metrics, it can only be used with additive metrics. MRHOF does not support metrics that are not additive." "For example, the use of MRHOF with the latency metric allows RPL to find stable minimum-latency paths from the nodes to a root in the Directed Acyclic Graph (DAG) instance [RFC6550]." > So you would > have to specify that the CA OF is different in that it has to look at the > NSA Metric sub-object inside the DMC object. But in the current situation= , > you already have to specify that the CA OF has to look at the NSA > Constraint sub-object inside the DMC object. No problem here. > With a metric, you could use > the Prec. field to highlight the fact that the PS TLV s a secondary > metric, beyond the implied ETX of MRHOF. There is only minor issue. The fact is that the information in the parent set is used a filter to filter out the nodes that do not comply with the Common Ancestor policy selected. So, the PS / NSA metric would actually need to have *higher* precedence (lower prec) than the other metric used (e.g. ETX). However, this should be simple to explain. > Or you could send the ETX Metric > sub-object explicitely, at the expense of a few extra bytes, and state > that the CA OF simply uses DMCs. > This is needed, but just so that we can specify prec >0 for the ETX metric. > Thoughts? > > Dominique > Again, thank you so much. This was something which we definitely should have handled. Please let me know if this solution is OK, and I will update the draft ASAP to make the March 9th cut-off date. Best, Aris > > Le 11/02/20 11:25, =C2=AB Roll on behalf of Georgios Z. Papadopoulos =C2= =BB > georgios.papadopoulos@imt-atlantique.fr> a =C3=A9crit : > > >Dear Rahul and all, > > > >Once again, thank you for spotting this issue. Great catch! > >We are happy with any of the following solutions : > > > >- We can indeed tie the PS set metric to CAOF specifically in the draft. > >Furthermore, the policies in CAOF are extensible (we only specify > >examples), so potentially another policy could make a different use of P= S > >as part of CAOF. > > > >- We can indeed explain the issue in the draft so that the implementers > >decide on their own how to handle it. > >Additionally, since the whole RPL instance uses the same OF, we would > >expect that if an OF which understands the TLV is used, then all the > >nodes will know how to process it. > >So, this issue should not be very common. > > > >- Another option would be to add an exception to the "all TLVs need to b= e > >propagated=E2=80=9D rule from RFC 6551 specifically for the PS TLV. > >The exception would specify that the PS TLV would be dropped if not > >understood. > > > > > >Best regards, > >Georgios and Aris > > > > > >> On Feb 11, 2020, at 04:32, Rahul Jadhav wrote: > >> > >> Hello Authors of NSA extn and all, > >> > >> One more question in the context: > >> > >> The draft adds new routing metrics/constraints (PS set) nested as part > >> of the NSA parent metric. > >> > >> My question is with regards to what happens if this routing metric is > >> used outside of the CAOF. Any metrics/constraints could be used by any > >> OF and thus PS set metric defined by the draft can be used by other > >> OF. > >> > >> RFC 6551 says that if the metric is not understood by the node and if > >> it is a 6LR then it may not process it but it has to propagate it. > >> Unlike other metrics, the PS set metric in this case contains > >> link-local values that cannot be used beyond link-local. As such upon > >> propagation, any downstream 6LR that understands the PS set metric > >> would use the information and get impacted adversely. > >> > >> Should we tie the PS set metric to CAOF specifically in the draft, in > >> which case this problem won't be there? Or we can specify this issue > >> as it is for the readers to understand the problem if the PS set is > >> used outside of the CAOF. Either way works for me. > >> > >> Best, > >> Rahul > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > --0000000000005d00a8059fab85b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dominique,

thank you very very much for this. Comments inline.

On Wed, Feb 26, 2020 at 12:02 PM <dominique.barthel@orange.com> wrote:
Hello all,

The discussion below prompts me to question the way the Parent Set (PS)
appears in the Dodag Metric Container (DMC). Sorry if this comes up late in the process.

Oh, better now than lat= er :)
=C2=A0
The NSA object carrying the PS TLV is currently specified to be Contraint.<= br> This shows up only once in the text (page 11).
There are some issues associated with the PS being part of a constraint: RFC6551 says
"In the presence of a constraint, a node MUST include a metric of the<= br> same type.=C2=A0 That metric is used to check whether or not the=C2=A0 =C2= =A0constraint
is met.=C2=A0 In all cases, a node MUST not change the content=C2=A0 =C2=A0= of the
constraint."
The behaviour proposed in this draft would have to create an exception for<= br> all of the above.

You are, of cour= se, absolutely right.

It is interesting that when = we started this work (draft-pkm-roll-nsa-extension-00 / April 2018) we init= ially specified a metric instead of a constraint, but in the immediately ne= xt version (draft-koutsiamanis-roll-nsa-extension-01 / July 2018) we switch= ed to the constraint specification.
I absolutely agree that= making an exception to this is undesirable.
From the very first = moment we wanted to avoid changing as few things as possible to keep things= simple and predictable.
=C2=A0
Alternate proposal:
Could the PS be part of an NSA Metric? After all, it is used to help
select which parent(s) are best suited for upward routing, not to prune
downlink propagation of the DIO along a path that exceed some metric
value. C=3D0, R=3D1, P=3D1 comes to mind for this metric.
<= div>
So I read a bit more about this. So C=3D0 means "us= e as a routing metric", OK.
R=3D1 means "use as a recor= ded metric", i.e. not aggregated, because aggregated makes no sense, O= K.
Now, P=3D1 means that one or more of the nodes on the path= did not record the metric. So, it's less a "command" and mor= e a report of previous behaviour.

My question is: = it seems impossible that *all* the parent sets can be recorded along the pa= th due to size, so each node *replaces* the received parent set with it'= ;s own.

We can specify this with text of course, b= ut I have not seen another existing metric that behaves like this.
On the other hand, the NSA metric object is not used a lot, and if i= t makes sense for any metric to be replaced rather then appended to a list = of metrics, that metric would be NSA.

I am not sur= e about that P=3D1 part though and how it relates to replacing the existing= metrics.
If I understand this correctly, a node repor= ting it's own parent set in the NSA will set P=3D1 basically to let the= receiving nodes know that they should not expect to find inside all the me= tric along the whole path, but only a part of it, and in our case from just= the sending node.

Am I getting this right?

=C2=A0
I understand that you are trying to create a CA OF that mimicks as much of<= br> the MRHOF as possible, and MRHOF says it doesn't use DMCs.

Actually, MRHOF does use DMCs, but only additive ones:=

page 3:
=C2=A0=C2=A0 "Because MRHOF= seeks to minimize path costs as described by metrics,
=C2=A0 =C2=A0it c= an only be used with additive metrics.=C2=A0 MRHOF does not support
=C2= =A0 =C2=A0metrics that are not additive."

=C2=A0 "For exam= ple, the use of MRHOF with the latency
=C2=A0 =C2=A0metric allows RPL to= find stable minimum-latency paths from the nodes
=C2=A0 =C2=A0to a root= in the Directed Acyclic Graph (DAG) instance [RFC6550]."
=C2=A0
So you would
have to specify that the CA OF is different in that it has to look at the NSA Metric sub-object inside the DMC object. But in the current situation,<= br> you already have to specify that the CA OF has to look at the NSA
Constraint sub-object inside the DMC object.

No problem here.
=C2=A0
With a metric, you could use
the Prec. field to highlight the fact that the PS TLV s a secondary
metric, beyond the implied ETX of MRHOF.

T= here is only minor issue. The fact is that the information in the parent se= t is used a filter to filter out the nodes that do not comply with the Comm= on Ancestor policy selected.
So, the PS / NSA metric would actual= ly need to have *higher* precedence (lower prec) than the other metric used= (e.g. ETX).
However, this should be simple to explain.
=
=C2=A0
Or you c= ould send the ETX Metric
sub-object explicitely, at the expense of a few extra bytes, and state
that the CA OF simply uses DMCs.

This i= s needed, but just so that we can specify prec >0 for the ETX metric.
=C2=A0
Thoughts?

Dominique

Again, thank you so much.
This was something which we definitely should have handled.

Please let me know if this solution is OK, and I will upda= te the draft ASAP to make the March 9th cut-off date.

<= div>Best,
Aris

=C2=A0

Le 11/02/20 11:25, =C2=AB Roll on behalf of Georgios Z. Papadopoulos =C2=BB=
<roll-bounces= @ietf.org on behalf of
georgios.papadopoulos@imt-atlantique.fr> a =C3=A9crit :

>Dear Rahul and all,
>
>Once again, thank you for spotting this issue. Great catch!
>We are happy with any of the following solutions :
>
>- We can indeed tie the PS set metric to CAOF specifically in the draft= .
>Furthermore, the policies in CAOF are extensible (we only specify
>examples), so potentially another policy could make a different use of = PS
>as part of CAOF.
>
>- We can indeed explain the issue in the draft so that the implementers=
>decide on their own how to handle it.
>Additionally, since the whole RPL instance uses the same OF, we would >expect that if an OF which understands the TLV is used, then all the >nodes will know how to process it.
>So, this issue should not be very common.
>
>- Another option would be to add an exception to the "all TLVs nee= d to be
>propagated=E2=80=9D rule from RFC 6551 specifically for the PS TLV.
>The exception would specify that the PS TLV would be dropped if not
>understood.
>
>
>Best regards,
>Georgios and Aris
>
>
>> On Feb 11, 2020, at 04:32, Rahul Jadhav <rahul.ietf@gmail.com> wrote:
>>
>> Hello Authors of NSA extn and all,
>>
>> One more question in the context:
>>
>> The draft adds new routing metrics/constraints (PS set) nested as = part
>> of the NSA parent metric.
>>
>> My question is with regards to what happens if this routing metric= is
>> used outside of the CAOF. Any metrics/constraints could be used by= any
>> OF and thus PS set metric defined by the draft can be used by othe= r
>> OF.
>>
>> RFC 6551 says that if the metric is not understood by the node and= if
>> it is a 6LR then it may not process it but it has to propagate it.=
>> Unlike other metrics, the PS set metric in this case contains
>> link-local values that cannot be used beyond link-local. As such u= pon
>> propagation, any downstream 6LR that understands the PS set metric=
>> would use the information and get impacted adversely.
>>
>> Should we tie the PS set metric to CAOF specifically in the draft,= in
>> which case this problem won't be there? Or we can specify this= issue
>> as it is for the readers to understand the problem if the PS set i= s
>> used outside of the CAOF. Either way works for me.
>>
>> Best,
>> Rahul
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll >
>_______________________________________________
>Roll mailing list
>Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

--0000000000005d00a8059fab85b2-- From nobody Fri Feb 28 16:05:48 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FA03A074E for ; Fri, 28 Feb 2020 16:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com header.b=eBgFojta; dkim=pass (2048-bit key) header.d=ariskou.com header.b=rJGX9wMa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zncPXW7N0kR6 for ; Fri, 28 Feb 2020 16:05:43 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F713A0764 for ; Fri, 28 Feb 2020 16:05:42 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 2A092576 for ; Sat, 29 Feb 2020 01:05:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1582934740; bh=52nXIxJqoPSa73urUbXC1KjP3DxhN2eyI4Ks7RBEijc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=eBgFojtaj7Kt7G6X1bOHy2UKcyRX8x8YbXQkJho00Ev4e+NZsL6yoD+SJ3R5SSyXJ NhnGeGb9K9hiaa8fhvIcGcs15miUWfXJjF2rnudR7QlV9NvSakjxn+XxmR2pDC+1OW 3dOXPTrbna2zx87eXTcxLozSQhZzbXgmD5LEAWiR+HHVnJehwVcsAGEDBmJUkCsA7Z DyHhy2XQfv5otm+NFh7UQJ6WB0LDZMmrftUYLVHuX1uKMWT1CJ74Zt7YRqRGn+vuEJ NTMYsPUs2cDYvdJdwM/+z4cusKenbNba9WPXYu1gtTkTjlnIhhwx+Nonp66EboVmcL lWnqCuBg/vnog== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1582934740; s=20191001-wvim; d=ariskou.com; i=aris@ariskou.com; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Content-Type; l=19693; bh=52nXIxJqoPSa73urUbXC1KjP3DxhN2eyI4Ks7RBEijc=; b=rJGX9wMacSUm9vhTrpW6CfTPrEDkJ8mvOgjl8u064Jj/8JN2SxukBATksrDXZHuj nDdvvjUSm7N1F6wYDKjac+xOciY4cWWtibsvmYaFZPoF+D6iU/ktCGTftYZ/Y9Oq3r6 5q/lLRPGQuI52/UEktp1mFQhxB5ZqkF2R5HHOhWXLJ2iz6n2PxVj5cIbLaAFazKf7gQ aQ69+xBdjaG1Ic3TvSG8vgT1yR1cb4T7NjowGBDjrxfbLOGMZcr3OHtT4gXcvJHhDUh VtWYiKv0GTF/9RwFOSfdAtUTJtoCfC1rqdNvsEQREGfAxHcPWaMxZhCSWHikArAKnKt YL+8dl6xTA== Received: by smtp.mailfence.com with ESMTPA for ; Sat, 29 Feb 2020 01:05:34 +0100 (CET) Received: by mail-io1-f46.google.com with SMTP id z1so5434720iom.9 for ; Fri, 28 Feb 2020 16:05:33 -0800 (PST) X-Gm-Message-State: APjAAAU5v5/NgzvVn2oSZOf7HvK4Sm633A8cUVVSXpv9uOmU1iLSz749 D8TuEJ0SuX+0nwgKqHIO9lUjeiIoJknFoT/21zE= X-Google-Smtp-Source: APXvYqytuk8fzhZpginqkvG8oOE5xGhj8fZoROLgTOkxYxpxppPsQdiJHkSj8eRRyQdwDsYvu+iSukmHvXi+wH5YWlI= X-Received: by 2002:a5d:860a:: with SMTP id f10mr5741457iol.259.1582934729243; Fri, 28 Feb 2020 16:05:29 -0800 (PST) MIME-Version: 1.0 References: <158134776694.4117.16175545100765405335.idtracker@ietfa.amsl.com> <25766_1582715717_5E565345_25766_121_1_DA7C0EE9.71074%dominique.barthel@orange.com> In-Reply-To: <25766_1582715717_5E565345_25766_121_1_DA7C0EE9.71074%dominique.barthel@orange.com> From: Remous-Aris Koutsiamanis Date: Sat, 29 Feb 2020 01:05:35 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: dominique barthel Cc: Routing Over Low power and Lossy networks , "Georgios Z. Papadopoulos" Content-Type: multipart/alternative; boundary="0000000000003d41cb059fabb65c" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-nsa-extension-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 00:05:47 -0000 --0000000000003d41cb059fabb65c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Dominique, thank you very much for the thorough review. Comments inline. On Wed, Feb 26, 2020 at 12:15 PM wrote: > Hello all, > > Another comment about this draft. The Security Considerations section > currently says > " The structure of the DIO control message is extended, within the pre- > defined DIO options. Therefore, the security mechanisms defined in > RPL [RFC6550] apply to this proposed extension." > I don't think this addresses the purpose of a Security Considerations > section. > OK, maybe I misunderstood what exactly I should have elaborated on. I think it should talk about the potential security issues introduced by > the draft, and why they are not real concerns. > I thought that no real extra concerns are present, but as you propose, maybe some more details would be helpful. > I guess that, what this draft changes compared to RFC6550-6551, is the > sending of the Parent Set of a node in its DIO. From there: > - This could result in a privacy issue. Yes, but the Parent Set is not > propagated further down the DODAG, so this disclosure does not reach far > beyond the propagation range of the radios of the Parents. So no tracking > of nodes by their IPv6 address possible from remote (a least no more than > in the current situation). > This is definitely present, I will add this issue, despite it not being especially problematic. Just to be complete. > - This could result in introducing a vulnerability: could an attacker > exploit the knowledge gained from learning the PS? =E2=80=A6 > Well, maybe with an assumption of a malicious node being able to decode the DIO, i.e. having the correct enc/decryption keys. 1. A malicious node that can read the DIO can "see" further than it's own neighbourhood by one hop, learning the addresses of it's two hop neighbors. So as mentioned, this is a privacy / network discovery issue. 2. A node that can send DIOs can use the parent set to convince neighbours to route through itself, instead of the normal preferred parent they would use. However, with other OFs this is already possible by reporting a fake rank value of 0 in the DIO, thus appearing as the DODAG root. As far as I can tell, if a malicious node manages to participate in the RPL network (i.e. decode/encode the RPL control packet) it is game over and it can definitely severely affect the operation of the whole network, just by reporting a fake rank. However, maybe this is not true; I'm not really an very familiar with the security of RPL. I don't see any other opportunities for security issues. I will add these two to the draft unless you have something additional. > Best regards > Dominique > Thank you very much Dominique for the help. Best, Aris > > De : Roll on behalf of "Georgios Z. Papadopoulos" > > R=C3=A9pondre =C3=A0 : "roll@ietf.org" > Date : Monday 10 February 2020 16:51 > =C3=80 : "roll@ietf.org" > Objet : [Roll] Fwd: New Version Notification for > draft-ietf-roll-nsa-extension-06.txt > > Dear all, > > FYI, we just submitted the 06 version where we addressed the comments fro= m > Rahul. > > Many thanks Rahul, > Georgios and Aris > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-ietf-roll-nsa-extension-06.txt* > *Date: *February 10, 2020 at 16:16:06 GMT+1 > *To: *"Nicolas Montavont" , "Pascal > Thubert" , "Georgios Papadopoulos" < > georgios.papadopoulos@imt-atlantique.fr>, "Remous-Aris Koutsiamanis" < > aris@ariskou.com> > > > A new version of I-D, draft-ietf-roll-nsa-extension-06.txt > has been successfully submitted by Remous-Aris Koutsiamanis and posted to > the > IETF repository. > > Name: draft-ietf-roll-nsa-extension > Revision: 06 > Title: Common Ancestor Objective Function and Parent Set DAG Metric > Container Extension > Document date: 2020-02-10 > Group: roll > Pages: 15 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-roll-nsa-extension-06.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/ > Htmlized: > https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-06 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-nsa-extension-06 > > Abstract: > Implementing Packet Replication and Elimination from/to the RPL root > requires the ability to forward copies of packets over different > paths via different RPL parents. Selecting the appropriate parents > to achieve ultra-low latency and jitter requires information about a > node's parents. This document details what information needs to be > transmitted and how it is encoded within RPL control packets to > enable this functionality. This document also describes Objective > Function which take advantage of this information to implement multi- > path routing. > > > > > 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 > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --0000000000003d41cb059fabb65c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dominique,

thank you very much for the thorough review.
Comments inlin= e.

On Wed, Feb 26, 2020 at 12:15 PM <dominique.barthel@orange.com> wrote:
=
Hello all,

Another comment about this draft. The Security Considerations section = currently says
" The structure of the DIO control message is extended, within th= e pre-
=C2=A0 =C2=A0defined DIO options.=C2=A0 Therefore, the security mechan= isms defined in
=C2=A0 =C2=A0RPL [RFC6550] apply to this proposed extension."
I don't think this addresses the purpose of a Security Considerati= ons section.

OK, maybe I misund= erstood what exactly I should have elaborated on.

=
I think it should talk about the potential security issues introduced = by the draft, and why they are not real concerns.
<= div>
I thought that no real extra concerns are present, but a= s you propose, maybe some more details would be helpful.
=C2= =A0
I guess that, what this draft changes compared to RFC6550-6551, is the= sending of the Parent Set of a node in its DIO. From there:
- This could result in a privacy issue. Yes, but the Parent Set is not= propagated further down the DODAG, so this disclosure does not reach far b= eyond the propagation range of the radios of the Parents. So no tracking of= nodes by their IPv6 address possible from remote (a least no more than in the current situation).

This is definitely present, I will add this = issue, despite it not being especially problematic. Just to be complete.
=C2=A0
<= div style=3D"color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif= ">
- This could result in introducing a vulnerability: could an attacker = exploit the knowledge gained from learning the PS? =E2=80=A6

Well, maybe with an assumption of = a malicious node being able to decode the DIO, i.e. having the correct enc/= decryption keys.
1. A malicious node that can read the DIO ca= n "see" further than it's own neighbourhood by one hop, learn= ing the addresses of it's two hop neighbors. So as mentioned, this is a= privacy / network discovery issue.
2. A node that can send D= IOs can use the parent set to convince neighbours to route through itself, = instead of the normal preferred parent they would use. However, with other = OFs this is already possible by reporting a fake rank value of 0 in the DIO= , thus appearing as the DODAG root.

As far as I ca= n tell, if a malicious node manages to participate in the RPL network (i.e.= decode/encode the RPL control packet) it is game over and it can definitel= y severely affect the operation of the whole network, just by reporting a f= ake rank.
However, maybe this is not true; I'm not really an = very familiar with the security of RPL.

I don&= #39;t see any other opportunities for security issues.
I will add= these two to the draft unless you have something additional.
=C2=A0
Best regards
Dominique

Thank you very m= uch Dominique for the help.

Best,
Aris
=C2=A0
=

De=C2=A0: Roll <roll-bounces@ietf.org> on= behalf of "Georgios Z. Papadopoulos" <georgios.papadopoulos= @imt-atlantique.fr>
R=C3=A9pondre =C3=A0=C2=A0: "<= a href=3D"mailto:roll@ietf.org" target=3D"_blank">roll@ietf.org" &= lt;roll@ietf.org>=
Date=C2=A0: Monday 10 February 2020= 16:51
=C3=80=C2=A0: "roll@ietf.org" <roll@ietf.org>
Objet=C2=A0: [Roll] Fwd: New Versio= n Notification for draft-ietf-roll-nsa-extension-06.txt

Dear all,

FYI, we just submitted the 06 version where we addressed the comments = from Rahul.

Many thanks Rahul,
Georgios and Aris


Begin forwarded message:

Subject: New Version Notification for draft-ietf-= roll-nsa-extension-06.txt
Date: February 10, 2020 at 16:16:06 GMT+1
To: "Nicolas Montavont" <nicolas.m= ontavont@imt-atlantique.fr>, "Pascal Thubert" <pthubert@cisco.com>= , "Georgios Papadopoulos" <georgios.papadopoulos@imt-atlantiq= ue.fr>, "Remous-Aris Koutsiamanis" <aris@ariskou.com>


A new version of I-D, draft-ietf-roll-nsa-extension-06.txt
has been successfully submitted by Remous-Aris Koutsiamanis and posted to t= he
IETF repository.

Name: draft-ietf-roll-nsa-extension
Revision: 06
Title: Common Ancestor Objective Function and Parent Set DAG M= etric Container Extension
Document date: 2020-02-10
Group: roll
Pages: 15
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-ietf-ro= ll-nsa-extension-06.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools= .ietf.org/html/draft-ietf-roll-nsa-extension-06
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https:= //datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-nsa-ex= tension-06

Abstract:
=C2=A0=C2=A0Implementing Packet Replication and Elimination from/to the RPL= root
=C2=A0=C2=A0requires the ability to forward copies of packets over differen= t
=C2=A0=C2=A0paths via different RPL parents.=C2=A0 Selecting the appropriat= e parents
=C2=A0=C2=A0to achieve ultra-low latency and jitter requires information ab= out a
=C2=A0=C2=A0node's parents.=C2=A0 This document details what informatio= n needs to be
=C2=A0=C2=A0transmitted and how it is encoded within RPL control packets to=
=C2=A0=C2=A0enable this functionality.=C2=A0 This document also describes O= bjective
=C2=A0=C2=A0Function which take advantage of this information to implement = multi-
=C2=A0=C2=A0path routing.




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

The IETF Secretariat


 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--0000000000003d41cb059fabb65c--