From nobody Sun Jun 2 17:33:05 2019 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 2AAD11200CE; Sun, 2 Jun 2019 17:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mLEcdUhIBmRX; Sun, 2 Jun 2019 17:32:54 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B5E12006E; Sun, 2 Jun 2019 17:32:54 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id ABAAF91828C580194568; Mon, 3 Jun 2019 01:32:52 +0100 (IST) Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 3 Jun 2019 01:32:52 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.73]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Mon, 3 Jun 2019 06:02:41 +0530 From: Rahul Arvind Jadhav To: Shwetha Bhandari , "Iot-dir@ietf.org" CC: "draft-ietf-roll-efficient-npdao.all@ietf.org" , "roll@ietf.org" , "ietf@ietf.org" Thread-Topic: Iotdir last call review of draft-ietf-roll-efficient-npdao-11 Thread-Index: AQHVF5YyqP7iHPDHqk+8A09vX16ZM6aJEQBw Date: Mon, 3 Jun 2019 00:32:40 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DED5B5B@BLREML503-MBX.china.huawei.com> References: <155929617874.6498.10870273861977185604@ietfa.amsl.com> In-Reply-To: <155929617874.6498.10870273861977185604@ietfa.amsl.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Iotdir last call review of draft-ietf-roll-efficient-npdao-11 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, 03 Jun 2019 00:32:58 -0000 VGhhbmsgeW91IFNod2V0aGEgZm9yIHlvdXIgcmV2aWV3IGFuZCBwbGVhc2UgZmluZCBteSByZXNw b25zZXMgaW5saW5lLg0KDQpSZWdhcmRzLA0KUmFodWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBTaHdldGhhIEJoYW5kYXJpIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRv Om5vcmVwbHlAaWV0Zi5vcmddDQo+IFNlbnQ6IDMxIE1heSAyMDE5IDE3OjUwDQo+IFRvOiBJb3Qt ZGlyQGlldGYub3JnDQo+IENjOiBkcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvLmFsbEBp ZXRmLm9yZzsgcm9sbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBJb3RkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvLTExDQo+ IA0KPiBSZXZpZXdlcjogU2h3ZXRoYSBCaGFuZGFyaQ0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3 aXRoIElzc3Vlcw0KPiANCj4gSSBhbSBhbiBhc3NpZ25lZCBJT1QgZGlyZWN0b3JhdGUgcmV2aWV3 ZXIgZm9yIDxkcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvDQo+ID4uIFRoZXNlIGNvbW1l bnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBJbnRlcm5l dA0KPiA+QXJlYQ0KPiBEaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIHNoZXBoZXJkKHMp IHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cw0KPiBqdXN0IGxpa2UgdGhleSB3b3VsZCB0cmVh dCBjb21tZW50cyBmcm9tIGFueSBvdGhlciBJRVRGIGNvbnRyaWJ1dG9ycyBhbmQNCj4gcmVzb2x2 ZSB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IGhhdmUg YmVlbg0KPiByZWNlaXZlZC4gRm9yIG1vcmUgZGV0YWlscyBvbiB0aGUgSU9UIERpcmVjdG9yYXRl LCBzZWUNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91cC9pb3RkaXIvYWJvdXQv DQo+IA0KPiBGb2xsb3dpbmcgc2VjdGlvbnMvdGV4dCBuZWVkIGNsYXJpZmljYXRpb24gYXMgcmVx dWVzdGVkIGJlbG93Og0KPiANCj4gPiAyLjIuICBJbnZhbGlkYXRlIHJvdXRlcyBvZiBkZXBlbmRl bnQgbm9kZXMNCj4gDQo+IEkgYW0gYSBiaXQgY29uZnVzZWQgYWJvdXQgd2hhdCB0aGlzIHNlY3Rp b24gaW1wbGllcy4gIEluIHRoZSBzdG9yaW5nIG1vZGUsIFJJQg0KPiB0aGF0IHJlc3VsdHMgaW4g dGhlIDZMUnMgd2l0aCB0aGUgREFPIHJlY2VpdmVkIHdpbGwgcmVzdWx0IGluIHRoZSBpZGVudGlm eWluZw0KPiBkZXBlbmRlbnQgbm9kZXMuIFNlZSBFLmcgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzY1NTAjYXBwZW5kaXgtDQo+IEEuMi4yIGFuZCBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjU1MCNhcHBlbmRpeC1BLjIuMy4gV2l0aCB0aGlzIGENCj4gTlBEQU8gcmVjZWl2 ZWQgZnJvbSBhIG5vZGUgdGhhdCBpcyB0aGUgbmV4dCBob3AgZm9yIGl0cyBkZXBlbmRlbnQgbm9k ZXMNCj4gc2hvdWxkIHJlc3VsdCBpbiB0aGUgcGFyZW50IGNsZWFuIHVwIHJvdXRlcyB0byB0aGUg ZGVwZW5kZW50IG5vZGVzIGFzIHdlbGwNCj4gYXMgZ2VuZXJhdGUgREFPIHRvIHJlZmxlY3QgdGhl IHVwZGF0ZWQgUklCLiBJZiB0aGlzIGlzIGNvcnJlY3QgdGhlbiB3aHkgd291bGQNCj4gaW52YWxp ZGF0aW5nIHJvdXRlcyBvZiBkZXBlbmRlbnQgbm9kZXMgYmUgYW4gaXNzdWUgd2l0aCBleGlzdGlu ZyBSUEwgKw0KPiBOUERBTyBtZWNoYW5pc20/DQoNCltSSl0gWWVzLCB0aGlzIGlzIGNvcnJlY3Qg dG8gdGhlIHBvaW50IHRoYXQgX2lmXyBOUERBTyBpcyByZWNlaXZlZCBmcm9tIHRoZSAoc3ViKWNo aWxkIG5vZGUgdGhlbiBpdCB3aWxsIHJlc3VsdCBpbiB0aGUgc3Vic2VxdWVudCBjbGVhbnVwIG9m IGl0cyBwYXRoLiANClRoZSBwcm9ibGVtIHdpdGggc3RvcmluZyBNT1AgaXMgdGhhdCB0aGVyZSBp cyBhYnNvbHV0ZWx5IG5vIHdheSBmb3IgYSBzdWItY2hpbGQgbm9kZSB0byB0cmlnZ2VyIHRoaXMg TlBEQU8gKHNpbmNlIGl0cyBwYXJlbnQgYWRqYWNlbmNpZXMgbWF5IG5vdCBoYXZlIGNoYW5nZWQp LiBXaGF0IERDTyBhY2hpZXZlcyBpcyBpbmRlcGVuZGVuY2UgZnJvbSB0aGlzIHRyaWdnZXIgb2Yg TlBEQU8gYnkgdHJpZ2dlcmluZyBEQ08gZnJvbSBhbmNlc3RvciBvbiB0aGUgYmFzaXMgb2YgcmVn dWxhciBEQU8gKHdoZW5ldmVyIGl0IGZsb3dzKSBmcm9tIHRoZSAoc3ViKWNoaWxkIG5vZGUuIFRo dXMgZXZlbiBpZiAoc3ViKWNoaWxkJ3MgcGFyZW50IGFkamFjZW5jaWVzIGhhdmUgbm90IGNoYW5n ZWQgdGhlIGFuY2VzdG9yIGtub3dzIHRoYXQgcGF0aHMgZm9yIHRoYXQgKHN1YiljaGlsZCBub2Rl IGhhcyBjaGFuZ2VkLg0KDQogSU1ITyBSb3V0ZSBpbnZhbGlkYXRpb24gYW5kIFJJQiBtYWludGVu YW5jZSBiYXNlZCBvbg0KPiBSUEwgbWVzc2FnaW5nIGlzIGFuIGltcGxlbWVudGF0aW9uIGRlY2lz aW9uIHRoYXQgUlBMIGRvZXNudCBoYXZlIHRvIHNwZWNpZnkuDQo+IA0KPiA+ICJEZXBlbmRlbnQg bm9kZXMgcm91dGUgaW52YWxpZGF0aW9uIG9uIHBhcmVudCBzd2l0Y2hpbmciDQo+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvLTExI3Nl Y3Rpb24tMy4yDQo+IEJhc2VkIG9uIHJlc3BvbnNlIHRvIHRoZSBhYm92ZSB0aGlzIHJlcXVpcmVt ZW50IG1heSBub3QgcmVhbGx5IGJlIGNhbGxlZA0KPiBvdXQgaGVyZT8NCj4gDQo+ID40LjYuMS4g IERlcGVuZGVudCBOb2RlcyBpbnZhbGlkYXRpb24NCj4gRm9yIHRoZSBzYW1lIHJlYXNvbnMgYXMg YWJvdmUgaXQgaXMgY29uZnVzaW5nIHdoeSB0aGlzIGNvbnNpZGVyYXRpb24gaXMNCj4gbmVlZGVk Lg0KPiANCj4gPk5QREFPIGFuZCBEQ08gaW4gdGhlIHNhbWUgbmV0d29yaw0KPiBJbiBhIG5ldHdv cmsgdGhhdCBoYXMgbWl4IG9mIG5vZGVzIHdpdGggRENPIGltcGxlbWVudGF0aW9uIGhvdyB3aWxs IGEgbm9kZQ0KPiBpcyB1cGRhdGVkIHdpdGggRENPIGltcGxlbWVudGF0aW9uIGRlY2lkZSBvbiBy ZWNvbW1lbmRlZCBvcHRpb24gMj8gVGhlDQo+IGNob2ljZSBvZiBwaWNraW5nIG9wdGlvbiAyIGxh cmdlbHkgZGVwZW5kcyBvbiBjYXBhYmlsaXR5IG9mIHRoZSB1cHN0cmVhbQ0KPiBub2RlcyAgcmF0 aGVyIHRoYW4gdGhlIG5vZGUgdGhhdCB3YW50cyB0byBpbnZhbGlkYXRlIGEgcHJlZml4IHRvIGl0 c2VsZi4gSXMgdGhlcmUNCj4gYSB3YXkgdG8gZGlzY292ZXIgY2FwYWJpbGl0eSBvZiB0aGUgdXBz dHJlYW0gbm9kZXMgaW4gb2xkIGFuZCBuZXcgcGF0aCB0bw0KPiBzZWUgaWYgRENPIGlzIGltcGxl bWVudGVkIGJlZm9yZSB0aGF0IGNob2ljZSBjYW4gYmUgbWFkZT8NCj4gDQoNCltSSl0gVGhlcmUg aXMgY3VycmVudGx5IG5vIHdheSBmb3IgZG93bnN0cmVhbSBub2RlcyB0byBrbm93IHdoZXRoZXIg dGhlIHVwc3RyZWFtIG5vZGVzIGVuLXJvdXRlIHN1cHBvcnQgRENPLiBOb3RlIHRoYXQgaWYgRENP IGlzIG5vdCBpbXBsZW1lbnRlZCBpbiBhbmNlc3RvciBub2RlIHRoZW4gdGhlIGludmFsaWRhdGlv biBvZiB0aGUgcHJldmlvdXMgcGF0aCB3b24ndCBoYXBwZW4gKHdoaWNoIG1lYW5zIGNsZWFudXAg b25seSBvbiByb3V0ZS1saWZldGltZSBleHBpcnkpLiBBbHNvIG5vdGUgdGhhdCBjdXJyZW50IE5Q REFPIGFsc28gZGVwZW5kcyBvbiB0aGUgbm9kZSdzIGNvbm5lY3Rpdml0eSB0byBpdHMgcHJldmlv dXMgcGFyZW50IGJlZW4gaW50YWN0LiBUaHVzIGlmIE5QREFPIHRoYXQgd291bGQgaGF2ZSBiZWVu IGdlbmVyYXRlZCAob24gbG9zcyBvZiBjb25uZWN0aXZpdHkpIHdvdWxkIHN0aWxsIG5vdCBoYXZl IHdvcmtlZCBhbnl3YXlzICh3aGljaCBtZWFucyBjbGVhbnVwIG9uIHJvdXRlLWxpZmV0aW1lIGV4 cGlyeSkuIE5vdGUgdGhhdCBuZXR3b3JrIHdpdGggcGFydGlhbCBub2RlcyBzdXBwb3J0aW5nIERD T3MgaXMgbm90IGZhdGFsIGF0IGFsbC4gVGhlIG9ubHkgcG9pbnQgaXMgcm91dGUgY2xlYW51cCBt YXkgYmUgc3ViLW9wdGltYWwgdGlsbCB0aGUgcG9pbnQgdGhlIG5ldHdvcmsgaXMgY29tcGxldGVs eSB1cGdyYWRlZC4NCg0K From nobody Mon Jun 3 04:30:10 2019 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 36F371201ED; Mon, 3 Jun 2019 04:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=d0qhEpK9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Nq9DES9F Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olT9jhH_33nc; Mon, 3 Jun 2019 04:29:53 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B4B12008D; Mon, 3 Jun 2019 04:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5300; q=dns/txt; s=iport; t=1559561393; x=1560770993; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UkRjgWO4GJcoZmpig3JZ5DRezCnWPws1W5VNjXMCsrs=; b=d0qhEpK9i+WVqBABs3ez1YuTdLl4byhrjKUVthxLUzC8nORActTCKGD5 SP/m9MGM4OMUJ3G0CyFDWGD59ZtYiFIqsj0JHoMJhR0b0/jZFje8gvhV4 7DVR+zutSsBgXWaSPsUT/Zx0Fq0znS4/jb51zdgc3Y2PZDAtsfAieBBCE Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A8j9ApRKiENsL9cCI5NmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAAC2A/Vc/4MNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT1QA2pVIAQLKIQUg0cDhFKKIIJXly+BLoEkA1QJAQEBDAE?= =?us-ascii?q?BIwoCAQGEQAIXgngjNAkOAQMBAQQBAQIBBG0cDIVKAQEBAQIBEhERDAEBNwE?= =?us-ascii?q?ECwIBCBoCJgICAjAVEAIEAQ0NGoMBgWoDDg8BAgyeGAKBOIhfcYExgnkBAQW?= =?us-ascii?q?EehiCDwMGgQwoAYtZF4FAP4ERRoFOfj6CYQEBAgGBUQ+DCDKCJo4ammMJAoI?= =?us-ascii?q?Nhj+NDpZujQCHC48TAgQCBAUCDgEBBYFPOIFYcBWDJ4IPg3CFFIU/cgEBgSe?= =?us-ascii?q?NXIJQAQE?= X-IronPort-AV: E=Sophos;i="5.60,546,1549929600"; d="scan'208";a="281398789" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jun 2019 11:29:51 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x53BTpBB029913 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Jun 2019 11:29:51 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 3 Jun 2019 06:29:50 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 3 Jun 2019 07:29:49 -0400 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 3 Jun 2019 06:29:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UkRjgWO4GJcoZmpig3JZ5DRezCnWPws1W5VNjXMCsrs=; b=Nq9DES9F4C+tKvmJc0AT+bOqsJyXTK/AR8XGu/z+JVl5Yx8nmgOIn8Qwd+lPLCqZl5inRSfvi60GLmU45IfPy7aQk5Do//ZGqkt+BpiGC38VOD7aD8mZyzj2wTAtUPugOgJKszRydayY7qTjNh9c6xu6Md7Xogv+K+W5xvRWQQ0= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4015.namprd11.prod.outlook.com (10.255.181.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.18; Mon, 3 Jun 2019 11:29:47 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc%7]) with mapi id 15.20.1943.018; Mon, 3 Jun 2019 11:29:47 +0000 From: "Pascal Thubert (pthubert)" To: Rahul Arvind Jadhav , "Shwetha Bhandari (shwethab)" , "Iot-dir@ietf.org" CC: "draft-ietf-roll-efficient-npdao.all@ietf.org" , "roll@ietf.org" , "ietf@ietf.org" Thread-Topic: Iotdir last call review of draft-ietf-roll-efficient-npdao-11 Thread-Index: AQHVF5Yt8kSZaDqTQEuYDJYXBjjgGKaJGIcAgAC0+8A= Date: Mon, 3 Jun 2019 11:29:35 +0000 Deferred-Delivery: Mon, 3 Jun 2019 11:28:42 +0000 Message-ID: References: <155929617874.6498.10870273861977185604@ietfa.amsl.com> <982B626E107E334DBE601D979F31785C5DED5B5B@BLREML503-MBX.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DED5B5B@BLREML503-MBX.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1005::1c2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 38c76244-6f41-4a5a-9841-08d6e816c8e0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB4015; x-ms-traffictypediagnostic: MN2PR11MB4015: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0057EE387C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(376002)(136003)(366004)(189003)(199004)(53936002)(186003)(52536014)(64756008)(99286004)(14444005)(256004)(66446008)(66556008)(9686003)(66476007)(73956011)(476003)(76116006)(6306002)(14454004)(71200400001)(74316002)(305945005)(66946007)(446003)(7736002)(55016002)(6436002)(5660300002)(11346002)(33656002)(71190400001)(6246003)(66574012)(4326008)(229853002)(966005)(86362001)(6116002)(46003)(2501003)(68736007)(54906003)(110136005)(8676002)(81166006)(6666004)(486006)(6506007)(2906002)(478600001)(7696005)(81156014)(76176011)(102836004)(25786009)(316002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4015; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 36Xv33PaiQsIJRZf9FXGUJv7ATFRDFHakxxTNvN4Y0AYdI2sWyRd4ZgYfmf2DF3gGm1kTwWM5sijuBE3UO27vGevyhcGbxn42BW0xyG0KZ25hNhXQZORdbdQu0ANnEH1hBWMMHub+gZXJc+IElpAA7noUbd1vdZ1vI6PgsZUxC2+vYUU4Fxn4hKHeLxQqB8nunSUEomkGbST6XISo+5s+qYDhjjKt6d+ufBclWEntaLINNioD4hpK1GWAR3UGs8AcOy5Cc2ZzPuzw7yGHd6M150f18r4yGhZJQ1fyldXXvD/+swM0qNON2ey/d995SxtzTocjHXPSZQLpzYhJwLSnvhR3ndFLTxFqKw4hRoqa+hJtbrZ9mpnpRXcrpIvVIeh+HbIgTgLwks5wF5D7J5Ddv2+bPKh2egyds1mJ3fzIdk= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 38c76244-6f41-4a5a-9841-08d6e816c8e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2019 11:29:47.4541 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4015 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Roll] Iotdir last call review of draft-ietf-roll-efficient-npdao-11 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, 03 Jun 2019 11:29:55 -0000 TXkgMiBjZW50cw0KDQo+IA0KPiA+DQo+ID4gRm9sbG93aW5nIHNlY3Rpb25zL3RleHQgbmVlZCBj bGFyaWZpY2F0aW9uIGFzIHJlcXVlc3RlZCBiZWxvdzoNCj4gPg0KPiA+ID4gMi4yLiAgSW52YWxp ZGF0ZSByb3V0ZXMgb2YgZGVwZW5kZW50IG5vZGVzDQo+ID4NCj4gPiBJIGFtIGEgYml0IGNvbmZ1 c2VkIGFib3V0IHdoYXQgdGhpcyBzZWN0aW9uIGltcGxpZXMuICBJbiB0aGUgc3RvcmluZw0KPiA+ IG1vZGUsIFJJQiB0aGF0IHJlc3VsdHMgaW4gdGhlIDZMUnMgd2l0aCB0aGUgREFPIHJlY2VpdmVk IHdpbGwgcmVzdWx0DQo+ID4gaW4gdGhlIGlkZW50aWZ5aW5nIGRlcGVuZGVudCBub2Rlcy4gU2Vl IEUuZw0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTUwI2FwcGVuZGl4LQ0K PiA+IEEuMi4yIGFuZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU1MCNhcHBlbmRp eC1BLjIuMy4gV2l0aA0KPiA+IHRoaXMgYSBOUERBTyByZWNlaXZlZCBmcm9tIGEgbm9kZSB0aGF0 IGlzIHRoZSBuZXh0IGhvcCBmb3IgaXRzDQo+ID4gZGVwZW5kZW50IG5vZGVzIHNob3VsZCByZXN1 bHQgaW4gdGhlIHBhcmVudCBjbGVhbiB1cCByb3V0ZXMgdG8gdGhlDQo+ID4gZGVwZW5kZW50IG5v ZGVzIGFzIHdlbGwgYXMgZ2VuZXJhdGUgREFPIHRvIHJlZmxlY3QgdGhlIHVwZGF0ZWQgUklCLiBJ Zg0KPiA+IHRoaXMgaXMgY29ycmVjdCB0aGVuIHdoeSB3b3VsZCBpbnZhbGlkYXRpbmcgcm91dGVz IG9mIGRlcGVuZGVudCBub2Rlcw0KPiA+IGJlIGFuIGlzc3VlIHdpdGggZXhpc3RpbmcgUlBMICsg TlBEQU8gbWVjaGFuaXNtPw0KPiANCj4gW1JKXSBZZXMsIHRoaXMgaXMgY29ycmVjdCB0byB0aGUg cG9pbnQgdGhhdCBfaWZfIE5QREFPIGlzIHJlY2VpdmVkIGZyb20gdGhlDQo+IChzdWIpY2hpbGQg bm9kZSB0aGVuIGl0IHdpbGwgcmVzdWx0IGluIHRoZSBzdWJzZXF1ZW50IGNsZWFudXAgb2YgaXRz IHBhdGguDQo+IFRoZSBwcm9ibGVtIHdpdGggc3RvcmluZyBNT1AgaXMgdGhhdCB0aGVyZSBpcyBh YnNvbHV0ZWx5IG5vIHdheSBmb3IgYSBzdWItY2hpbGQNCj4gbm9kZSB0byB0cmlnZ2VyIHRoaXMg TlBEQU8gKHNpbmNlIGl0cyBwYXJlbnQgYWRqYWNlbmNpZXMgbWF5IG5vdCBoYXZlDQo+IGNoYW5n ZWQpLiBXaGF0IERDTyBhY2hpZXZlcyBpcyBpbmRlcGVuZGVuY2UgZnJvbSB0aGlzIHRyaWdnZXIg b2YgTlBEQU8gYnkNCj4gdHJpZ2dlcmluZyBEQ08gZnJvbSBhbmNlc3RvciBvbiB0aGUgYmFzaXMg b2YgcmVndWxhciBEQU8gKHdoZW5ldmVyIGl0IGZsb3dzKQ0KPiBmcm9tIHRoZSAoc3ViKWNoaWxk IG5vZGUuIFRodXMgZXZlbiBpZiAoc3ViKWNoaWxkJ3MgcGFyZW50IGFkamFjZW5jaWVzIGhhdmUg bm90DQo+IGNoYW5nZWQgdGhlIGFuY2VzdG9yIGtub3dzIHRoYXQgcGF0aHMgZm9yIHRoYXQgKHN1 YiljaGlsZCBub2RlIGhhcyBjaGFuZ2VkLg0KPiANCg0KUFQgPiBUaGUgRENPIGhhcyBhIG51bWJl ciBvZiBhZHZhbnRhZ2VzLiBJbiBwYXJ0aWN1bGFyIGl0IG9ubHkga2lsbHMgdGhlIG9sZCByb3V0 ZSB3aGVuIHRoZSBuZXcgcm91dGUgaXMgYXZhaWxhYmxlLCBhbmQgaXQgZm9sbG93cyB0aGUgdHJh ZmZpYyBvbiB0aGUgd2F5IGRvd24gdG8gaXQgZG9lcyBub3Qga2lsbCBpdCBhcyB0aGUgY3Jvc3Mg bGlrZSBhIGxlZ2FjeSBOUERBTyB3b3VsZC4NCg0KPiAgSU1ITyBSb3V0ZSBpbnZhbGlkYXRpb24g YW5kIFJJQiBtYWludGVuYW5jZSBiYXNlZCBvbg0KPiA+IFJQTCBtZXNzYWdpbmcgaXMgYW4gaW1w bGVtZW50YXRpb24gZGVjaXNpb24gdGhhdCBSUEwgZG9lc250IGhhdmUgdG8NCj4gc3BlY2lmeS4N Cj4gPg0KPiA+ID4gIkRlcGVuZGVudCBub2RlcyByb3V0ZSBpbnZhbGlkYXRpb24gb24gcGFyZW50 IHN3aXRjaGluZyINCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1y b2xsLWVmZmljaWVudC1ucGRhby0xMSNzZWN0aW9uDQo+ID4gLTMuMiBCYXNlZCBvbiByZXNwb25z ZSB0byB0aGUgYWJvdmUgdGhpcyByZXF1aXJlbWVudCBtYXkgbm90IHJlYWxseSBiZQ0KPiA+IGNh bGxlZCBvdXQgaGVyZT8NCj4gPg0KPiA+ID40LjYuMS4gIERlcGVuZGVudCBOb2RlcyBpbnZhbGlk YXRpb24NCj4gPiBGb3IgdGhlIHNhbWUgcmVhc29ucyBhcyBhYm92ZSBpdCBpcyBjb25mdXNpbmcg d2h5IHRoaXMgY29uc2lkZXJhdGlvbg0KPiA+IGlzIG5lZWRlZC4NCj4gPg0KPiA+ID5OUERBTyBh bmQgRENPIGluIHRoZSBzYW1lIG5ldHdvcmsNCj4gPiBJbiBhIG5ldHdvcmsgdGhhdCBoYXMgbWl4 IG9mIG5vZGVzIHdpdGggRENPIGltcGxlbWVudGF0aW9uIGhvdyB3aWxsIGENCj4gPiBub2RlIGlz IHVwZGF0ZWQgd2l0aCBEQ08gaW1wbGVtZW50YXRpb24gZGVjaWRlIG9uIHJlY29tbWVuZGVkIG9w dGlvbg0KPiA+IDI/IFRoZSBjaG9pY2Ugb2YgcGlja2luZyBvcHRpb24gMiBsYXJnZWx5IGRlcGVu ZHMgb24gY2FwYWJpbGl0eSBvZiB0aGUNCj4gPiB1cHN0cmVhbSBub2RlcyAgcmF0aGVyIHRoYW4g dGhlIG5vZGUgdGhhdCB3YW50cyB0byBpbnZhbGlkYXRlIGEgcHJlZml4DQo+ID4gdG8gaXRzZWxm LiBJcyB0aGVyZSBhIHdheSB0byBkaXNjb3ZlciBjYXBhYmlsaXR5IG9mIHRoZSB1cHN0cmVhbSBu b2Rlcw0KPiA+IGluIG9sZCBhbmQgbmV3IHBhdGggdG8gc2VlIGlmIERDTyBpcyBpbXBsZW1lbnRl ZCBiZWZvcmUgdGhhdCBjaG9pY2UgY2FuIGJlDQo+IG1hZGU/DQo+ID4NCj4gDQo+IFtSSl0gVGhl cmUgaXMgY3VycmVudGx5IG5vIHdheSBmb3IgZG93bnN0cmVhbSBub2RlcyB0byBrbm93IHdoZXRo ZXIgdGhlDQo+IHVwc3RyZWFtIG5vZGVzIGVuLXJvdXRlIHN1cHBvcnQgRENPLiBOb3RlIHRoYXQg aWYgRENPIGlzIG5vdCBpbXBsZW1lbnRlZCBpbg0KPiBhbmNlc3RvciBub2RlIHRoZW4gdGhlIGlu dmFsaWRhdGlvbiBvZiB0aGUgcHJldmlvdXMgcGF0aCB3b24ndCBoYXBwZW4gKHdoaWNoDQo+IG1l YW5zIGNsZWFudXAgb25seSBvbiByb3V0ZS1saWZldGltZSBleHBpcnkpLiBBbHNvIG5vdGUgdGhh dCBjdXJyZW50IE5QREFPDQo+IGFsc28gZGVwZW5kcyBvbiB0aGUgbm9kZSdzIGNvbm5lY3Rpdml0 eSB0byBpdHMgcHJldmlvdXMgcGFyZW50IGJlZW4gaW50YWN0Lg0KPiBUaHVzIGlmIE5QREFPIHRo YXQgd291bGQgaGF2ZSBiZWVuIGdlbmVyYXRlZCAob24gbG9zcyBvZiBjb25uZWN0aXZpdHkpIHdv dWxkDQo+IHN0aWxsIG5vdCBoYXZlIHdvcmtlZCBhbnl3YXlzICh3aGljaCBtZWFucyBjbGVhbnVw IG9uIHJvdXRlLWxpZmV0aW1lIGV4cGlyeSkuDQo+IE5vdGUgdGhhdCBuZXR3b3JrIHdpdGggcGFy dGlhbCBub2RlcyBzdXBwb3J0aW5nIERDT3MgaXMgbm90IGZhdGFsIGF0IGFsbC4gVGhlDQo+IG9u bHkgcG9pbnQgaXMgcm91dGUgY2xlYW51cCBtYXkgYmUgc3ViLW9wdGltYWwgdGlsbCB0aGUgcG9p bnQgdGhlIG5ldHdvcmsgaXMNCj4gY29tcGxldGVseSB1cGdyYWRlZC4NCg0KUFQgPiBXaGVuIGJv dGggbWV0aG9kcyBhcmUgYWN0aXZlIGF0IHRoZSBzYW1lIHRpbWUgdGhlIGJyb2tlbiBwYXRoIGlz IGNsZWFuZWQgZnJvbSBib3RoIGVuZHMgdGlsbCB0aGUgbm9kZSB3aGVyZSB0aGUgY29udHJvbCBt ZXNzYWdlcyBtZWV0Lg0KUFQgPiBJdCBtaWdodCBiZSB0aGF0IHRoZSBrbm93bGVkZ2UgdGhhdCB0 aGUgbm9kZSBsZWZ0IHRoZSBET0RBRyBjb21lcyBmcm9tIHRoZSBvdXRzaWRlIHRvIHRoZSByb290 LCBlLmcuIGEgcm91dGluZyBwcm90b2NvbCBvciBhIGJhY2tib25lIHJvdXRlci4gDQpQVD4gSW4g dGhhdCBjYXNlIG9ubHkgdGhlIHJvb3QgY2FuIGNsZWFuIHVwLCBhbmQgRENPIGlzIHRoZSB3YXkg dG8gZG8gaXQuDQoNCkFsbCB0aGUgYmVzdCwNCg0KUGFzY2FsDQoNCg0KDQoNCg0KDQoNCg== From nobody Mon Jun 3 08:54:08 2019 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 D375A1203DB for ; Mon, 3 Jun 2019 08:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 7E4RzHgv4k7S for ; Mon, 3 Jun 2019 08:54:04 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 D8D6A1203D9 for ; Mon, 3 Jun 2019 08:54:03 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id i21so8567055ita.5 for ; Mon, 03 Jun 2019 08:54:03 -0700 (PDT) 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=CuFVqsxnkcFQrVH5hLz0JL4jjnQ4EkIQqry9ldsK0+Q=; b=KJ78o8f9L4ywt0DI0e5jv1Btx8oTMHTI5AwimZoMYTlr2HiQM3QWwWzCiG0BmKPrlz xARGrNhKiSlOy3zEtPcWIGDKSTjSNBmkWRXn2lq6hQEVLa6VwGbQsmfLvBvBnJcqA5PC 9wWmFNUBs7wPtJC0cQAVVUGjxyO2TC7HJuCmabtYZKFRUPSLoJxP+9fD6xwBHemOjSTt eq3v46PW8bKRSgPfKLnqP+t0o0nQ/hba92ur3hpvLkURMwASVTs9QeYHWSqt9gi4IMtl tsy/stQbpgUH1PWLEQzHtHwtuhu/tw5jG8UNxsDzE9sCI/pRSmJZkLTc1mP+i26kgM8W /TGA== 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=CuFVqsxnkcFQrVH5hLz0JL4jjnQ4EkIQqry9ldsK0+Q=; b=IOxhMl+v+FN5n5BfZgV4XfPOiZi0Dm4Wt1l7/ndeHmzeRMqCyN0/WSjv+F4hp545OW rDFS/UN40LkeLG1/m6vccJxoJ5ZRqqYsD/X98mv3On5Kv93DQ7YZHJaTCvxciFgmegqS obyH2DaZKLkeCj6KbmrYyXGKLnsqkI9QLWaK714WLm+7Fe1wMcW7fSTwp0Dhj0GLXDkW OPk75KkL4OpN7yLBeVS3ifOA1emYmNsy/J1FpvLXyML2JPOZchUUct5+ZK2wqaJccKC8 w399jeKO3Q3xwOaa4fpRvolYtP7gUKDFu1a1qVCl2LpMxmAB8Yr8lAFLI7SkskBDlmU5 KYGw== X-Gm-Message-State: APjAAAWXiJm3UnNmCdA+FKTetEJTZlIaU5gDAfpdWLNC6+5Id7ogyca9 kEHhMgFpMFSegKVIj6Qcb6DcQmWUm3CkhqdloC2pMWjd X-Google-Smtp-Source: APXvYqy/1/rhH4TJU3HR9IBjbx5Z8jF1lkwnGAfLDUQBECZaFZbzsho/q+2WNqLOfTixBk3N7VuXKiOR2ynId4N6YWI= X-Received: by 2002:a24:61d7:: with SMTP id s206mr17238733itc.133.1559577242647; Mon, 03 Jun 2019 08:54:02 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Mon, 3 Jun 2019 18:53:51 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="0000000000008c4219058a6d5ff6" Archived-At: Subject: [Roll] One week call for comments for draft-ietf-roll-efficient-npdao-11 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, 03 Jun 2019 15:54:06 -0000 --0000000000008c4219058a6d5ff6 Content-Type: text/plain; charset="UTF-8" Dear all, draft-ietf-roll-efficient-npdao has a new version (version 11) including changes such as: - New section to allow unsolicited DCO - IANA modifications - Security considerations updated. Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-efficient-npdao-11.txt Thus, we rise a one-week-last-call for this draft, from 03-June-2019 to 10-June-2019. Please let us know your comments/opinions/suggestions, Thank you very much, Ines and Peter. --0000000000008c4219058a6d5ff6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

draft-ietf-roll-efficient-npd= ao has a new version (version 11) including changes such as:
=
- New section to allow unsolicited DCO

<= div>- IANA modifications

- Security considerations= updated.

=

Thus, we rise a one-week-last-call for this draft, from= 03-June-2019 to 10-June-2019.

Please let us know = your comments/opinions/suggestions,

Thank you very= much,

Ines and Peter.

--0000000000008c4219058a6d5ff6-- From nobody Mon Jun 3 17:22:21 2019 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 F15BC12006A; Mon, 3 Jun 2019 17:22:19 -0700 (PDT) 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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <155960773994.24683.8766844589930649430@ietfa.amsl.com> Date: Mon, 03 Jun 2019 17:22:19 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-efficient-npdao-12.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, 04 Jun 2019 00:22:20 -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 : Efficient Route Invalidation Authors : Rahul Arvind Jadhav Pascal Thubert Rabi Narayan Sahoo Zhen Cao Filename : draft-ietf-roll-efficient-npdao-12.txt Pages : 22 Date : 2019-06-03 Abstract: This document describes the problems associated with No-Path Destination Advertisement Object (NPDAO) messaging used in Routing Protocol for Low power and lossy networks (RPL) for route invalidation and signaling changes to improve route invalidation efficiency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-efficient-npdao-12 https://datatracker.ietf.org/doc/html/draft-ietf-roll-efficient-npdao-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-efficient-npdao-12 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 Jun 4 06:25:39 2019 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 E452A120059 for ; Tue, 4 Jun 2019 06:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 bzZ1TvEenKyT for ; Tue, 4 Jun 2019 06:25:33 -0700 (PDT) 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 4552D12001E for ; Tue, 4 Jun 2019 06:25:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id DA691120444; Tue, 4 Jun 2019 15:25:31 +0200 (CEST) Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id LdRi2Tkzkwg8; Tue, 4 Jun 2019 15:25:30 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id D80D9120605; Tue, 4 Jun 2019 15:25:29 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy130.enst.fr D80D9120605 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1559654729; bh=F4z91ytp+8c+O9rIf9PKHpyTUBxW+ObZs6+C5Gg8/U0=; h=From:Date:Message-Id:To:Mime-Version; b=pVh0AEiyl91nCP0I+d5weuU/yDp+WCk8DpUGWo6u0UuNmDJe+2/KbpjrcsDRO9fYI vgJXaWeVyPIaY5yaJEgWm26IwpAIMWIePMh2z63y9tcN5vSoHUaA8AwC5NJ1FfL7HF kK4yjkgnuUNDw5XTqHrJzMvkL9m4ZiiGTbdngQRo= 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 nmQY7S51QLPn; Tue, 4 Jun 2019 15:25:29 +0200 (CEST) Received: from [IPv6:2001:660:7301:3728:c18d:986f:90d5:969b] (unknown [IPv6:2001:660:7301:3728:c18d:986f:90d5:969b]) by zproxy130.enst.fr (Postfix) with ESMTPSA id 888C7120527; Tue, 4 Jun 2019 15:25:29 +0200 (CEST) From: "Georgios Z. Papadopoulos" Content-Type: multipart/alternative; boundary="Apple-Mail=_D428C2B3-C5D9-45C7-B521-F1C396E7C1EA" Date: Tue, 4 Jun 2019 15:26:58 +0200 Message-Id: <5BC4C696-7FAF-4DA5-95E4-66E3DA512743@imt-atlantique.fr> To: Routing Over Low power and Lossy networks Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Roll] Review [raft-rahul-roll-mop-ext-00] 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 Jun 2019 13:25:37 -0000 --Apple-Mail=_D428C2B3-C5D9-45C7-B521-F1C396E7C1EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Rahul and co-authors,=20 As promised during the last IETF meeting in Prague, here is my review. Bellow is the draft contents with my annotations, starting with = =E2=80=9C[GP]". Cheers, Georgios =E2=80=94 =E2=80=94 =E2=80=94 ROLL R. Jadhav, Ed. Internet-Draft Huawei Tech Intended status: Standards Track P. Thubert Expires: August 15, 2019 Cisco February 11, 2019 RPL Mode of Operation extension draft-rahul-roll-mop-ext-00 Abstract RPL allows different mode of operations which allows nodes to have a consensus on the basic primitives that must be supported to join the network. The MOP field in RFC6550 is of 3 bits and is fast depleting. This document extends the MOP field specification and adds a notion of capabilities using which the nodes can further advertise their support for, possibly optional, capabilities. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 15, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Jadhav & Thubert Expires August 15, 2019 [Page 1] =0C Internet-Draft MOP extension February 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language and Terminology . . . . . . . . . . 2 2. Requirements for this document . . . . . . . . . . . . . . . 3 3. Extended MOP Control Message Option . . . . . . . . . . . . . 3 3.1. Final MOP . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Capability Control Message Option . . . . . . . . . . . . 5 4.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5 5. Implementations Consideration . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Capability Handshake Example . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction RPL [RFC6550] specifies a proactive distance-vector based routing scheme. The protocol creates a DAG-like structure which operates with a given "Mode of Operation" (MOP) determining the minimal and mandatory set of primitives to be supported by all the participating nodes. MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is specific to the RPL Instance. The receipient of the DIO message can join the specified network as a router only when it can support the primitives as required by the mode of operation value. For example, in case of MOP=3D3 (Storing MOP with multicast support) the nodes can join the network as routers only when they can handle the DAO advertisements from the peers and manage routing tables. 1.1. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. MOP: Mode of Operation. Identifies the mode of operation of the RPL Instance as administratively provisioned at and distributed by the DODAG root. Jadhav & Thubert Expires August 15, 2019 [Page 2] =0C Internet-Draft MOP extension February 2019 DAO: DODAG Advertisement Object. An RPL message used to advertise the target information in order to establish routing adjacencies. DIO: DODAG Information Object. An RPL message initiated by the root and is used to advertise the network configuration information. Current parent: Parent 6LR node before switching to the new path. NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. MOPex: MOP extension as defined in this document. This document uses terminology described in [RFC6550]. For the sake of readability all the known relevant terms are repeated in this section. 2. Requirements for this document Following are the requirements considered for this documents: REQ1: MOP extension. Current MOP of 3-bit is fast depleting. An MOP extension needs to extend the possibility of adding new MOPs in the future. REQ2: Optional capabilities handshake. Capabilities are features, possibly optional, which could be handshaked between the nodes and the root within an RPL Instance. [GP] Maybe few words (to give minimum background) earlier in the = Introduction about the "capabilities handshake=E2=80=9D? Otherwise it = appears too unexpectedly. REQ3: Backwards compatibility. The new options and new fields in the DIO message should be backward compatible i.e. if there are nodes which support old MOPs they could still operate in their own instances. REQ4: Capabilities handshake could be optionally added with existing MOPs. Capabilities been optional in nature could be put to use with existing MOPs. Capabilities and MOP-extension is mutually independent i.e. a DIO can have a capabilities option, MOP-extension option or both in the same message. [GP] Structurally, I would push REQ4 before REQ3. Since both REQ2 and 4 = are related with Capabilities handshake. 3. Extended MOP Control Message Option [GP] A structural comment here, I do not see a Subsection 3.2 and so on, = then I do not see why there should be 3.1. This document reserves existing MOP value 7 to be used as an extender. [GP] To make it clear, the value 7 did not represent something till = today? DIO messages with MOP value of 7 MUST refer to the Extended MOP (MOPex) option in the DIO message. If the MOPex option is absent in the DIO whose MOP is 7, then the DIO message MUST be silently discarded. [GP] with the current implementation if this value is 7, what would be = the case? It will be silently discarded as well? Jadhav & Thubert Expires August 15, 2019 [Page 3] =0C Internet-Draft MOP extension February 2019 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D TODO | Extended-MOP-value = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Extended MOP Option [GP] Is it possible to have this Extended MOP option Figure within the = actual DIO message? 3.1. Final MOP An implementation supporting this document MUST calculate the final MOP value as the sum of base MOP (as supported in Section 6.3.1. of [RFC6550]) plus the MOPex value. Thus if the MOPex value is 0, it means the final MOP is 7 since the base MOP in this case will be set to 7. +----------+-------+-----------+ | Base MOP | MOPex | Final MOP | +----------+-------+-----------+ | 0 | NA | 0 | | 1 | NA | 1 | | : | : | : | | 6 | NA | 6 | | 7 | 0 | 7 | | 7 | 1 | 8 | | 7 | 2 | 9 | | : | : | : | +----------+-------+-----------+ Table 1: Final MOP calculation 4. Capabilities Currently RPL specification does not have a mechanism whereby a node can signal the set of features that are available on its end. Such a mechanism could help the root to advertise its capabilities and in response also determine some advanced information about the capabilities of the joining nodes. The Mode of Operation field in RPL mandates the operational requirement and does not allow loose coupling of additional capabilities. This document defines Capabilities as additional features which could be supported by the nodes and handshaked as part of RPL signaling. Capabilities are embedded as RPL control message option as defined Section 6.7 of [RFC6550] in the base messages of DIO, DAO and DAO-ACK signaling. Jadhav & Thubert Expires August 15, 2019 [Page 4] =0C Internet-Draft MOP extension February 2019 4.1. Capability Control Message Option [GP] Is there room both for MOPex and for Capability options? Or it will = either be one or the other one? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D TODO | Capabilities Flags = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Capabilities Option There are no capability flags defined by this document. 4.2. Capabilities Handshake The root node could advertise the set of capabilities it supports in the DIO message. A node could take advantage of the knowledge that the root supports a particular capability. Similarly a node could advertise its capabilities in the DAO message using the capability control message option defined in this document. Capabilities advertised by non-root nodes are strictly a subset of the capabilities advertised by the root. In storing MOP, the DAO message from the 6LR could contain multiple target options. The targets of the capabilities option are indicated by one or more Target options that precede the Capabilties Option. This handling is similar to the Transit Information Option as supported in Section 6.7.8. of [RFC6550]. 5. Implementations Consideration The MOP-extension could cause 3-byte increase in memory in the RPL- Instance. The MOP field in the RPL-Instance needs to be upgraded to a 32 bit integer. [RFC6550], it was possible to discard an unsupported DIO-MOP just by inspecting the base message. With this document, the MOPex is a different control message option and thus the discarding of the DIO message could happen after inspecting the message options. A node in storing MOP could independently construct a DAO message with target options containing its child/sub-childs. Thus with capabilities it needs to reconstruct the capabilities field as well. This may result in increase in the memory requirement on per routing- entry basis. Jadhav & Thubert Expires August 15, 2019 [Page 5] =0C Internet-Draft MOP extension February 2019 6. Acknowledgements Thanks 7. IANA Considerations IANA is requested to allocate MOP field value 0x7 in the DIO base object defined in RPL [RFC6550] section 6.3.1 for MOP extension. TODO 8. Security Considerations The options defined in this document are carried in the base message objects as defined in [RFC6550]. The RPL control message options are protected by the same security mechanisms that protect the base messages. Capabilities flag can reveal that the node has been upgraded or is running a old feature set. This document assumes that the base messages that carry these options are protected by RPL security mechanisms and thus are not visible to a malicious node. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . Appendix A. Capability Handshake Example Jadhav & Thubert Expires August 15, 2019 [Page 6] =0C Internet-Draft MOP extension February 2019 Root 6LR 6LN | | | | DIO(CS1) | | |------------>| DIO(CS1) | | |----------->| | | | | | DAO(CS2) | | |<-----------| | DAO(CS2) | | |<------------| | | | | CS: Capabilities Set CS1: Capabilities set advertised by root CS2: Capabilities set advertised by node. CS2 is a subset of = CS1. Figure 3: Capabilities Option Authors' Addresses Rahul Arvind Jadhav (editor) Huawei Tech Kundalahalli Village, Whitefield, Bangalore, Karnataka 560037 India Phone: +91-080-49160700 Email: rahul.ietf@gmail.com Pascal Thubert Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis 06254 France Phone: +33 497 23 26 34 Email: pthubert@cisco.com Jadhav & Thubert Expires August 15, 2019 [Page 7] ____________________________________ Georgios Z. Papadopoulos, Ph.D. Associate Professor, IMT Atlantique, Rennes web: www.georgiospapadopoulos.com = twitter: @gzpapadopoulos = tel: +33 (0)2 99 12 70 04 ____________________________________ --Apple-Mail=_D428C2B3-C5D9-45C7-B521-F1C396E7C1EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Rahul and co-authors, 

As promised during the last IETF meeting in Prague, here is = my review.
Bellow is the draft contents with my = annotations, starting with =E2=80=9C[GP]".

Cheers,
Georgios

=E2= =80=94 =E2=80=94 =E2=80=94





ROLL                                                      R. Jadhav, Ed.
Internet-Draft                                               Huawei Tech
Intended status: Standards Track                              P. Thubert
Expires: August 15, 2019                                           Cisco
                                                       February 11, 2019


                    RPL Mode of Operation extension
                      draft-rahul-roll-mop-ext-00

Abstract

   RPL allows different mode of operations which allows nodes to have a
   consensus on the basic primitives that must be supported to join the
   network.  The MOP field in RFC6550 is of 3 bits and is fast
   depleting.  This document extends the MOP field specification and
   adds a notion of capabilities using which the nodes can further
   advertise their support for, possibly optional, capabilities.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.
   =
Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 15, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the =
date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Jadhav & Thubert         Expires August 15, 2019                =
[Page 1]
=0C
Internet-Draft                MOP extension                February 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language and Terminology . . . . . . . . . .   2
   2.  Requirements for this document  . . . . . . . . . . . . . . .   3
   3.  Extended MOP Control Message Option . . . . . . . . . . . . .   3
     3.1.  Final MOP . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Capability Control Message Option . . . . . . . . . . . .   5
     4.2.  Capabilities Handshake  . . . . . . . . . . . . . . . . .   5
   5.  Implementations Consideration . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Capability Handshake Example . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   RPL [RFC6550] specifies a proactive distance-vector based routing
   scheme.  The protocol creates a DAG-like structure which operates
   with a given "Mode of Operation" (MOP) determining the minimal and
   mandatory set of primitives to be supported by all the participating
   nodes.

   MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is
   specific to the RPL Instance.  The receipient of the DIO message can
   join the specified network as a router only when it can support the
   primitives as required by the mode of operation value.  For example,
   in case of MOP=3D3 (Storing MOP with multicast support) the nodes can
   join the network as routers only when they can handle the DAO
   advertisements from the peers and manage routing tables.

1.1.  Requirements Language and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   MOP: Mode of Operation.  Identifies the mode of operation of the RPL
   Instance as administratively provisioned at and distributed by the
   DODAG root.



Jadhav & Thubert         Expires August 15, 2019                =
[Page 2]
=0C
Internet-Draft                MOP extension                February 2019


   DAO: DODAG Advertisement Object.  An RPL message used to advertise
   the target information in order to establish routing adjacencies.

   DIO: DODAG Information Object.  An RPL message initiated by the root
   and is used to advertise the network configuration information.

   Current parent: Parent 6LR node before switching to the new path.

   NPDAO: No-Path DAO.  A DAO message which has target with lifetime 0.

   MOPex: MOP extension as defined in this document.

   This document uses terminology described in [RFC6550].  For the sake
   of readability all the known relevant terms are repeated in this
   section.

2.  Requirements for this document

   Following are the requirements considered for this documents:

   REQ1:  MOP extension.  Current MOP of 3-bit is fast depleting.  An
          MOP extension needs to extend the possibility of adding new
          MOPs in the future.

   REQ2:  Optional capabilities handshake.  Capabilities are features,
          possibly optional, which could be handshaked between the nodes
          and the root within an RPL Instance.
[GP] Maybe few words (to give minimum background) earlier in the =
Introduction about the "capabilities handshake=E2=80=9D? Otherwise it =
appears too unexpectedly.

   REQ3:  Backwards compatibility.  The new options and new fields in
          the DIO message should be backward compatible i.e. if there
          are nodes which support old MOPs they could still operate in
          their own instances.

   REQ4:  Capabilities handshake could be optionally added with existing
          MOPs.  Capabilities been optional in nature could be put to
          use with existing MOPs.  Capabilities and MOP-extension is
          mutually independent i.e. a DIO can have a capabilities
          option, MOP-extension option or both in the same =
message.
[GP] Structurally, I would =
push REQ4 before REQ3. Since both REQ2 and 4 are related with =
Capabilities handshake.

3.  Extended MOP Control Message Option
[GP] A structural comment here, I do not see a =
Subsection 3.2 and so on, then I do not see why there should be 3.1.

   This document reserves existing MOP value 7 to be used as an
   extender.
[GP] To make it clear, the =
value 7 did not represent something till today?
   DIO messages with MOP value of 7 MUST refer to =
the
   Extended MOP (MOPex) option in the DIO message.  If the MOPex option
   is absent in the DIO whose MOP is 7, then the DIO message MUST be
   silently discarded.
[GP] with the current implementation if this value =
is 7, what would be the case? It will be silently discarded as well?




Jadhav & Thubert         Expires August 15, 2019                =
[Page 3]
=0C
Internet-Draft                MOP extension                February 2019


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D TODO |           Extended-MOP-value                  =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: Extended MOP Option
[GP] Is it possible to have this Extended MOP =
option Figure within the actual DIO message?

3.1.  Final MOP

   An implementation supporting this document MUST calculate the final
   MOP value as the sum of base MOP (as supported in Section 6.3.1. of
   [RFC6550]) plus the MOPex value.  Thus if the MOPex value is 0, it
   means the final MOP is 7 since the base MOP in this case will be set
   to 7.

                     +----------+-------+-----------+
                     | Base MOP | MOPex | Final MOP |
                     +----------+-------+-----------+
                     |    0     |   NA  |     0     |
                     |    1     |   NA  |     1     |
                     |    :     |   :   |     :     |
                     |    6     |   NA  |     6     |
                     |    7     |   0   |     7     |
                     |    7     |   1   |     8     |
                     |    7     |   2   |     9     |
                     |    :     |   :   |     :     |
                     +----------+-------+-----------+

                      Table 1: Final MOP calculation

4.  Capabilities

   Currently RPL specification does not have a mechanism whereby a node
   can signal the set of features that are available on its end.  Such a
   mechanism could help the root to advertise its capabilities and in
   response also determine some advanced information about the
   capabilities of the joining nodes.  The Mode of Operation field in
   RPL mandates the operational requirement and does not allow loose
   coupling of additional capabilities.  This document defines
   Capabilities as additional features which could be supported by the
   nodes and handshaked as part of RPL signaling.  Capabilities are
   embedded as RPL control message option as defined Section 6.7 of
   [RFC6550] in the base messages of DIO, DAO and DAO-ACK signaling.







Jadhav & Thubert         Expires August 15, 2019                =
[Page 4]
=0C
Internet-Draft                MOP extension                February 2019


4.1.  Capability Control Message Option
[GP] Is there room both for MOPex and for =
Capability options? Or it will either be one or the other one?

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D TODO |           Capabilities Flags                  =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2: Capabilities Option

   There are no capability flags defined by this document.

4.2.  Capabilities Handshake

   The root node could advertise the set of capabilities it supports in
   the DIO message.  A node could take advantage of the knowledge that
   the root supports a particular capability.  Similarly a node could
   advertise its capabilities in the DAO message using the capability
   control message option defined in this document.  Capabilities
   advertised by non-root nodes are strictly a subset of the
   capabilities advertised by the root.

   In storing MOP, the DAO message from the 6LR could contain multiple
   target options.  The targets of the capabilities option are indicated
   by one or more Target options that precede the Capabilties Option.
   This handling is similar to the Transit Information Option as
   supported in Section 6.7.8. of [RFC6550].

5.  Implementations Consideration

   The MOP-extension could cause 3-byte increase in memory in the RPL-
   Instance.  The MOP field in the RPL-Instance needs to be upgraded to
   a 32 bit integer.

   [RFC6550], it was possible to discard an unsupported DIO-MOP just by
   inspecting the base message.  With this document, the MOPex is a
   different control message option and thus the discarding of the DIO
   message could happen after inspecting the message options.

   A node in storing MOP could independently construct a DAO message
   with target options containing its child/sub-childs.  Thus with
   capabilities it needs to reconstruct the capabilities field as well.
   This may result in increase in the memory requirement on per routing-
   entry basis.







Jadhav & Thubert         Expires August 15, 2019                =
[Page 5]
=0C
Internet-Draft                MOP extension                February 2019


6.  Acknowledgements

   Thanks

7.  IANA Considerations

   IANA is requested to allocate MOP field value 0x7 in the DIO base
   object defined in RPL [RFC6550] section 6.3.1 for MOP extension.

   TODO

8.  Security Considerations

   The options defined in this document are carried in the base message
   objects as defined in [RFC6550].  The RPL control message options are
   protected by the same security mechanisms that protect the base
   messages.

   Capabilities flag can reveal that the node has been upgraded or is
   running a old feature set.  This document assumes that the base
   messages that carry these options are protected by RPL security
   mechanisms and thus are not visible to a malicious node.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

9.2.  Informative References

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

Appendix A.  Capability Handshake Example









Jadhav & Thubert         Expires August 15, 2019                =
[Page 6]
=0C
Internet-Draft                MOP extension                February 2019


       Root          6LR          6LN
        |             |            |
        |   DIO(CS1)  |            |
        |------------>|  DIO(CS1)  |
        |             |----------->|
        |             |            |
        |             |   DAO(CS2) |
        |             |<-----------|
        |   DAO(CS2)  |            |
        |<------------|            |
        |             |            |
        CS: Capabilities Set
        CS1: Capabilities set advertised by root
        CS2: Capabilities set advertised by node. CS2 is a subset of =
CS1.

                       Figure 3: Capabilities Option

Authors' Addresses

   Rahul Arvind Jadhav (editor)
   Huawei Tech
   Kundalahalli Village, Whitefield,
   Bangalore, Karnataka  560037
   India

   Phone: +91-080-49160700
   Email: rahul.ietf@gmail.com


   Pascal Thubert
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   MOUGINS - Sophia Antipolis  06254
   France

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com













Jadhav & Thubert         Expires August 15, 2019                =
[Page 7]



____________________________________

Georgios Z. = Papadopoulos, Ph.D.
Associate Professor, IMT = Atlantique, Rennes

web:   www.georgiospapadopoulos.com
twitter:  @gzpapadopoulos
tel: = +33 (0)2 99 12 70 04
____________________________________

= --Apple-Mail=_D428C2B3-C5D9-45C7-B521-F1C396E7C1EA-- From nobody Tue Jun 4 17:53:43 2019 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 F033C120112 for ; Tue, 4 Jun 2019 17:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IytVwx__TmGp for ; Tue, 4 Jun 2019 17:53:39 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773261200FB for ; Tue, 4 Jun 2019 17:53:39 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C9D882F9F1411E363F8B for ; Wed, 5 Jun 2019 01:53:37 +0100 (IST) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 5 Jun 2019 01:53:36 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.73]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0439.000; Wed, 5 Jun 2019 06:23:28 +0530 From: Rahul Arvind Jadhav To: "Georgios Z. Papadopoulos" , Routing Over Low power and Lossy networks Thread-Topic: Review [raft-rahul-roll-mop-ext-00] Thread-Index: AQHVGtkLRDNOya1frkKW9j05u1UiIKaMMS6g Date: Wed, 5 Jun 2019 00:53:27 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DEDE962@BLREML503-MBX.china.huawei.com> References: <5BC4C696-7FAF-4DA5-95E4-66E3DA512743@imt-atlantique.fr> In-Reply-To: <5BC4C696-7FAF-4DA5-95E4-66E3DA512743@imt-atlantique.fr> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DEDE962BLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Review [raft-rahul-roll-mop-ext-00] 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, 05 Jun 2019 00:53:42 -0000 --_000_982B626E107E334DBE601D979F31785C5DEDE962BLREML503MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IEdlb3JnaW9zIGZvciB0aGUgcmV2aWV3IGFuZCBmZWVkYmFjay4NClBsZWFzZSBm aW5kIG15IHJlc3BvbnNlcyBpbmxpbmUuDQoNClJlZ2FyZHMsDQpSYWh1bA0KDQoNCiAgIFJFUTI6 ICBPcHRpb25hbCBjYXBhYmlsaXRpZXMgaGFuZHNoYWtlLiAgQ2FwYWJpbGl0aWVzIGFyZSBmZWF0 dXJlcywNCg0KICAgICAgICAgIHBvc3NpYmx5IG9wdGlvbmFsLCB3aGljaCBjb3VsZCBiZSBoYW5k c2hha2VkIGJldHdlZW4gdGhlIG5vZGVzDQoNCiAgICAgICAgICBhbmQgdGhlIHJvb3Qgd2l0aGlu IGFuIFJQTCBJbnN0YW5jZS4NCg0KW0dQXSBNYXliZSBmZXcgd29yZHMgKHRvIGdpdmUgbWluaW11 bSBiYWNrZ3JvdW5kKSBlYXJsaWVyIGluIHRoZSBJbnRyb2R1Y3Rpb24gYWJvdXQgdGhlICJjYXBh YmlsaXRpZXMgaGFuZHNoYWtl4oCdPyBPdGhlcndpc2UgaXQgYXBwZWFycyB0b28gdW5leHBlY3Rl ZGx5Lg0KDQpbUkpdIFllcy4gU2hvdWxkIGhhdmUgaW50cm9kdWNlZCBjYXBhYmlsaXRpZXMgaW4g SW50cm9kdWN0aW9uIHNlY3Rpb24uIFdpbGwgZG8uDQoNCg0KDQogICBSRVEzOiAgQmFja3dhcmRz IGNvbXBhdGliaWxpdHkuICBUaGUgbmV3IG9wdGlvbnMgYW5kIG5ldyBmaWVsZHMgaW4NCg0KICAg ICAgICAgIHRoZSBESU8gbWVzc2FnZSBzaG91bGQgYmUgYmFja3dhcmQgY29tcGF0aWJsZSBpLmUu IGlmIHRoZXJlDQoNCiAgICAgICAgICBhcmUgbm9kZXMgd2hpY2ggc3VwcG9ydCBvbGQgTU9QcyB0 aGV5IGNvdWxkIHN0aWxsIG9wZXJhdGUgaW4NCg0KICAgICAgICAgIHRoZWlyIG93biBpbnN0YW5j ZXMuDQoNCg0KDQogICBSRVE0OiAgQ2FwYWJpbGl0aWVzIGhhbmRzaGFrZSBjb3VsZCBiZSBvcHRp b25hbGx5IGFkZGVkIHdpdGggZXhpc3RpbmcNCg0KICAgICAgICAgIE1PUHMuICBDYXBhYmlsaXRp ZXMgYmVlbiBvcHRpb25hbCBpbiBuYXR1cmUgY291bGQgYmUgcHV0IHRvDQoNCiAgICAgICAgICB1 c2Ugd2l0aCBleGlzdGluZyBNT1BzLiAgQ2FwYWJpbGl0aWVzIGFuZCBNT1AtZXh0ZW5zaW9uIGlz DQoNCiAgICAgICAgICBtdXR1YWxseSBpbmRlcGVuZGVudCBpLmUuIGEgRElPIGNhbiBoYXZlIGEg Y2FwYWJpbGl0aWVzDQoNCiAgICAgICAgICBvcHRpb24sIE1PUC1leHRlbnNpb24gb3B0aW9uIG9y IGJvdGggaW4gdGhlIHNhbWUgbWVzc2FnZS4NCg0KW0dQXSBTdHJ1Y3R1cmFsbHksIEkgd291bGQg cHVzaCBSRVE0IGJlZm9yZSBSRVEzLiBTaW5jZSBib3RoIFJFUTIgYW5kIDQgYXJlIHJlbGF0ZWQg d2l0aCBDYXBhYmlsaXRpZXMgaGFuZHNoYWtlLg0KDQpbUkpdIE9yIEkgY291bGQgc3dhcCBSRVEz IGFuZCBSRVEyIHdoaWNoIHdpbGwgbWFrZSByZWxhdGVkIHJlcXVpcmVtZW50cyBjbHViIHRvZ2V0 aGVyPyBCdXQgeWVzLCBJIGdldCB0aGUgcG9pbnQgb2Ygc3RydWN0dXJpbmcgdGhpbmdzIHRvZ2V0 aGVyIGFuZCB3aWxsIHVwZGF0ZSBpbiBuZXh0IHZlci4NCg0KDQoNCjMuICBFeHRlbmRlZCBNT1Ag Q29udHJvbCBNZXNzYWdlIE9wdGlvbg0KDQpbR1BdIEEgc3RydWN0dXJhbCBjb21tZW50IGhlcmUs IEkgZG8gbm90IHNlZSBhIFN1YnNlY3Rpb24gMy4yIGFuZCBzbyBvbiwgdGhlbiBJIGRvIG5vdCBz ZWUgd2h5IHRoZXJlIHNob3VsZCBiZSAzLjEuDQoNCltSSl0gV2lsbCBzdHJ1Y3R1cmUgdGhpcyBw cm9wZXJseS4gU2hvdWxkIGFkZCBhIHNlcGFyYXRlIOKAmEV4dGVuZGVkLU1PUCBCYXNlIFJ1bGVz 4oCZIHNlY3Rpb24gKHdoaWNoIHdpbGwgYmUgU2VjdGlvbiAzLjIpLg0KDQoNCg0KICAgVGhpcyBk b2N1bWVudCByZXNlcnZlcyBleGlzdGluZyBNT1AgdmFsdWUgNyB0byBiZSB1c2VkIGFzIGFuDQoN CiAgIGV4dGVuZGVyLg0KDQpbR1BdIFRvIG1ha2UgaXQgY2xlYXIsIHRoZSB2YWx1ZSA3IGRpZCBu b3QgcmVwcmVzZW50IHNvbWV0aGluZyB0aWxsIHRvZGF5Pw0KDQogICBESU8gbWVzc2FnZXMgd2l0 aCBNT1AgdmFsdWUgb2YgNyBNVVNUIHJlZmVyIHRvIHRoZQ0KDQogICBFeHRlbmRlZCBNT1AgKE1P UGV4KSBvcHRpb24gaW4gdGhlIERJTyBtZXNzYWdlLiAgSWYgdGhlIE1PUGV4IG9wdGlvbg0KDQog ICBpcyBhYnNlbnQgaW4gdGhlIERJTyB3aG9zZSBNT1AgaXMgNywgdGhlbiB0aGUgRElPIG1lc3Nh Z2UgTVVTVCBiZQ0KDQogICBzaWxlbnRseSBkaXNjYXJkZWQuDQoNCltSSl0gTU9QPTcgZG9lcyBu b3QgcmVwcmVzZW50IGFueXRoaW5nIHRvZGF5LiBXZSBoYXZlIGFkZGVkIElBTkEgY29uc2lkZXJh dGlvbiB0byByZXNlcnZlIE1PUD03LiBUaGlzIHJlbWluZHMgbWUsIEkgbmVlZCB0byBhZGQgRXh0 ZW5kZWQtTU9QLVZhbHVlIGFuZCBDYXBhYmlsaXRpZXMgZmxhZyByZWdpc3RyeSBpbiB0aGUgSUFO QSBjb25zaWRlcmF0aW9uLg0KDQoNCltHUF0gd2l0aCB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlv biBpZiB0aGlzIHZhbHVlIGlzIDcsIHdoYXQgd291bGQgYmUgdGhlIGNhc2U/IEl0IHdpbGwgYmUg c2lsZW50bHkgZGlzY2FyZGVkIGFzIHdlbGw/DQoNCltSSl0gVGhhbmtzIGZvciByYWlzaW5nIHRo aXMuIEkgdHJpZWQgdG8gY2hlY2sgd2hhdCBoYXBwZW5zIGFzIHBlciA2NTUwLiBBcyBwZXIgNjU1 MCBTZWN0aW9uIDYuMy4xLCB0aGUgbm9kZSBjYW4gc3RpbGwgam9pbiB0aGUgbmV0d29yayB3aXRo IHVua25vd24gTU9QIGFzIGEgbGVhZiBub2RlLiBUaGlzIG1pZ2h0IGhhdmUgaW1wbGljYXRpb25z IGFuZCBtYXkgbmVlZCBoYW5kbGluZy4NCg0KDQoNCiAgICAgICAgMCAgICAgICAgICAgICAgICAg ICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KDQogICAgICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQ0KDQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICAgIHwgICBUeXBlID0gVE9ETyB8ICAgICAg ICAgICBFeHRlbmRlZC1NT1AtdmFsdWUgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogRXh0ZW5kZWQgTU9Q IE9wdGlvbg0KDQpbR1BdIElzIGl0IHBvc3NpYmxlIHRvIGhhdmUgdGhpcyBFeHRlbmRlZCBNT1Ag b3B0aW9uIEZpZ3VyZSB3aXRoaW4gdGhlIGFjdHVhbCBESU8gbWVzc2FnZT8NCg0KW1JKXSBUaGVy ZSBhcmUgNyBiaXRzIGluIFJlc2VydmVkIGZpZWxkIGluIERJTyBiYXNlIG1lc3NhZ2UuIEJ1dCBJ 4oCZbSBub3Qgc3VyZSBpZiB3ZSBjYW4gdXNlIHRob3NlIGJpdHMgc2luY2Ugb3RoZXJ3aXNlIHRo ZXJlIHdvbuKAmXQgYmUgYW55IFJlc2VydmVkIHNwYWNlIGxlZnQgZm9yIGZ1dHVyZSBwbGF5Lg0K DQoNCg0KDQoNCjQuMS4gIENhcGFiaWxpdHkgQ29udHJvbCBNZXNzYWdlIE9wdGlvbg0KDQpbR1Bd IElzIHRoZXJlIHJvb20gYm90aCBmb3IgTU9QZXggYW5kIGZvciBDYXBhYmlsaXR5IG9wdGlvbnM/ IE9yIGl0IHdpbGwgZWl0aGVyIGJlIG9uZSBvciB0aGUgb3RoZXIgb25lPw0KDQpbUkpdIFRoZSBk cmFmdCBhbGxvd3MgZWl0aGVyIG9yIGJvdGggb3B0aW9ucy4gV2lsbCBtYWtlIHRoaXMgZXhwbGlj aXQgaW4gbmV4dCB2ZXIuDQoNCg== --_000_982B626E107E334DBE601D979F31785C5DEDE962BLREML503MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBw bGUtdGFiLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5h bWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlRoYW5rIHlvdSBHZW9yZ2lvcyBmb3IgdGhlIHJldmlldyBhbmQgZmVlZGJhY2suPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlBsZWFzZSBmaW5kIG15IHJlc3BvbnNlcyBpbmxpbmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5SYWh1bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFJFUTI6Jm5i c3A7IE9wdGlvbmFsIGNhcGFiaWxpdGllcyBoYW5kc2hha2UuJm5ic3A7IENhcGFiaWxpdGllcyBh cmUgZmVhdHVyZXMsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvc3NpYmx5IG9wdGlvbmFsLCB3aGlj aCBjb3VsZCBiZSBoYW5kc2hha2VkIGJldHdlZW4gdGhlIG5vZGVzPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGFuZCB0aGUgcm9vdCB3aXRoaW4gYW4gUlBMIEluc3RhbmNlLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJvcnBoYW5zOiAyO3dpZG93czogMjtmb250LXZhcmlhbnQtbGlnYXR1cmVz OiBub3JtYWw7b3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5bR1BdJm5ic3A7TWF5YmUgZmV3 IHdvcmRzICh0byBnaXZlIG1pbmltdW0gYmFja2dyb3VuZCkgZWFybGllciBpbiB0aGUgSW50cm9k dWN0aW9uIGFib3V0IHRoZSAmcXVvdDtjYXBhYmlsaXRpZXMgaGFuZHNoYWtl4oCdPyBPdGhlcndp c2UgaXQgYXBwZWFycyB0b28mbmJzcDt1bmV4cGVjdGVkbHkuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPltSSl0gWWVzLiBTaG91bGQgaGF2ZSBpbnRyb2R1Y2VkIGNhcGFiaWxpdGllcyBp biBJbnRyb2R1Y3Rpb24gc2VjdGlvbi4gV2lsbCBkby48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO29ycGhhbnM6IDI7d2lkb3dzOiAy O292ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBSRVEzOiZuYnNwOyBCYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4mbmJzcDsg VGhlIG5ldyBvcHRpb25zIGFuZCBuZXcgZmllbGRzIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo ZSBESU8gbWVzc2FnZSBzaG91bGQgYmUgYmFja3dhcmQgY29tcGF0aWJsZSBpLmUuIGlmIHRoZXJl PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSBub2RlcyB3aGljaCBzdXBwb3J0IG9sZCBNT1BzIHRo ZXkgY291bGQgc3RpbGwgb3BlcmF0ZSBpbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGVpciBvd24g aW5zdGFuY2VzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBSRVE0OiZuYnNwOyBDYXBhYmlsaXRpZXMgaGFuZHNoYWtlIGNv dWxkIGJlIG9wdGlvbmFsbHkgYWRkZWQgd2l0aCBleGlzdGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBNT1BzLiZuYnNwOyBDYXBhYmlsaXRpZXMgYmVlbiBvcHRpb25hbCBpbiBuYXR1cmUgY291bGQg YmUgcHV0IHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZSB3aXRoIGV4aXN0aW5nIE1PUHMuJm5i c3A7IENhcGFiaWxpdGllcyBhbmQgTU9QLWV4dGVuc2lvbiBpczxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBtdXR1YWxseSBpbmRlcGVuZGVudCBpLmUuIGEgRElPIGNhbiBoYXZlIGEgY2FwYWJpbGl0aWVz PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wdGlvbiwgTU9QLWV4dGVuc2lvbiBvcHRpb24gb3IgYm90 aCBpbiB0aGUgc2FtZSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250 LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7b3JwaGFuczogMjt3aWRvd3M6IDI7b3ZlcmZsb3ct d3JhcDogYnJlYWstd29yZCI+W0dQXSBTdHJ1Y3R1cmFsbHksIEkgd291bGQgcHVzaCBSRVE0IGJl Zm9yZSBSRVEzLiBTaW5jZSBib3RoIFJFUTIgYW5kIDQgYXJlIHJlbGF0ZWQgd2l0aCBDYXBhYmls aXRpZXMgaGFuZHNoYWtlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPltSSl0gT3IgSSBjb3VsZCBz d2FwIFJFUTMgYW5kIFJFUTIgd2hpY2ggd2lsbCBtYWtlIHJlbGF0ZWQgcmVxdWlyZW1lbnRzIGNs dWIgdG9nZXRoZXI/IEJ1dCB5ZXMsIEkgZ2V0IHRoZSBwb2ludCBvZiBzdHJ1Y3R1cmluZyB0aGlu Z3MgdG9nZXRoZXIgYW5kIHdpbGwgdXBkYXRlIGluIG5leHQgdmVyLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjMuJm5ic3A7IEV4dGVuZGVkIE1P UCBDb250cm9sIE1lc3NhZ2UgT3B0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZv bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtvcnBoYW5zOiAyO3dpZG93czogMjtvdmVyZmxv dy13cmFwOiBicmVhay13b3JkIj5bR1BdIEEgc3RydWN0dXJhbCBjb21tZW50IGhlcmUsIEkgZG8g bm90IHNlZSBhIFN1YnNlY3Rpb24gMy4yIGFuZCBzbyBvbiwgdGhlbiBJIGRvIG5vdCBzZWUgd2h5 IHRoZXJlIHNob3VsZCBiZSAzLjEuPG86cD48L286cD48L3ByZT4NCjxwcmU+W1JKXSBXaWxsIHN0 cnVjdHVyZSB0aGlzIHByb3Blcmx5LiBTaG91bGQgYWRkIGEgc2VwYXJhdGUg4oCYRXh0ZW5kZWQt TU9QIEJhc2UgUnVsZXPigJkgc2VjdGlvbiAod2hpY2ggd2lsbCBiZSBTZWN0aW9uIDMuMikuPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IFRoaXMgZG9jdW1lbnQgcmVzZXJ2ZXMgZXhpc3RpbmcgTU9QIHZhbHVlIDcgdG8gYmUg dXNlZCBhcyBhbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBleHRlbmRlci48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9y bWFsO29ycGhhbnM6IDI7d2lkb3dzOiAyO292ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQiPltHUF0g VG8gbWFrZSBpdCBjbGVhciwgdGhlIHZhbHVlIDcgZGlkIG5vdCByZXByZXNlbnQgc29tZXRoaW5n IHRpbGwgdG9kYXk/PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1s aWdhdHVyZXM6IG5vcm1hbDtvcnBoYW5zOiAyO3dpZG93czogMjtvdmVyZmxvdy13cmFwOiBicmVh ay13b3JkIj4mbmJzcDsmbmJzcDsgRElPIG1lc3NhZ2VzIHdpdGggTU9QIHZhbHVlIG9mIDcgTVVT VCByZWZlciB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgRXh0ZW5k ZWQgTU9QIChNT1BleCkgb3B0aW9uIGluIHRoZSBESU8gbWVzc2FnZS4mbmJzcDsgSWYgdGhlIE1P UGV4IG9wdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpcyBhYnNlbnQg aW4gdGhlIERJTyB3aG9zZSBNT1AgaXMgNywgdGhlbiB0aGUgRElPIG1lc3NhZ2UgTVVTVCBiZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzaWxlbnRseSBkaXNjYXJkZWQuPG86 cD48L286cD48L3ByZT4NCjxwcmU+W1JKXSBNT1A9NyBkb2VzIG5vdCByZXByZXNlbnQgYW55dGhp bmcgdG9kYXkuIFdlIGhhdmUgYWRkZWQgSUFOQSBjb25zaWRlcmF0aW9uIHRvIHJlc2VydmUgTU9Q PTcuIFRoaXMgcmVtaW5kcyBtZSwgSSBuZWVkIHRvIGFkZCBFeHRlbmRlZC1NT1AtVmFsdWUgYW5k IENhcGFiaWxpdGllcyBmbGFnIHJlZ2lzdHJ5IGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb24uPGJy Pjxicj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJl czogbm9ybWFsO29ycGhhbnM6IDI7d2lkb3dzOiAyO292ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQi PltHUF0gd2l0aCB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBpZiB0aGlzIHZhbHVlIGlzIDcs IHdoYXQgd291bGQgYmUgdGhlIGNhc2U/IEl0IHdpbGwgYmUgc2lsZW50bHkgZGlzY2FyZGVkIGFz IHdlbGw/PG86cD48L286cD48L3ByZT4NCjxwcmU+W1JKXSBUaGFua3MgZm9yIHJhaXNpbmcgdGhp cy4gSSB0cmllZCB0byBjaGVjayB3aGF0IGhhcHBlbnMgYXMgcGVyIDY1NTAuIEFzIHBlciA2NTUw IFNlY3Rpb24gNi4zLjEsIHRoZSBub2RlIGNhbiBzdGlsbCBqb2luIHRoZSBuZXR3b3JrIHdpdGgg dW5rbm93biBNT1AgYXMgYSBsZWFmIG5vZGUuIFRoaXMgbWlnaHQgaGF2ZSBpbXBsaWNhdGlvbnMg YW5kIG1heSBuZWVkIGhhbmRsaW5nLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 IFR5cGUgPSBUT0RPIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgRXh0ZW5kZWQtTU9QLXZhbHVlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgRmlndXJlIDE6IEV4dGVuZGVkIE1PUCBPcHRpb248bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO29ycGhhbnM6 IDI7d2lkb3dzOiAyO292ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQiPltHUF0gSXMgaXQgcG9zc2li bGUgdG8gaGF2ZSB0aGlzIEV4dGVuZGVkIE1PUCBvcHRpb24gRmlndXJlIHdpdGhpbiB0aGUgYWN0 dWFsIERJTyBtZXNzYWdlPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPltSSl0gVGhlcmUgYXJlIDcg Yml0cyBpbiBSZXNlcnZlZCBmaWVsZCBpbiBESU8gYmFzZSBtZXNzYWdlLiBCdXQgSeKAmW0gbm90 IHN1cmUgaWYgd2UgY2FuIHVzZSB0aG9zZSBiaXRzIHNpbmNlIG90aGVyd2lzZSB0aGVyZSB3b27i gJl0IGJlIGFueSBSZXNlcnZlZCBzcGFjZSBsZWZ0IGZvciBmdXR1cmUgcGxheS48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT40LjEuJm5ic3A7IENhcGFiaWxpdHkgQ29udHJvbCBNZXNzYWdlIE9w dGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVz OiBub3JtYWw7b3JwaGFuczogMjt3aWRvd3M6IDI7b3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZCI+ W0dQXSBJcyB0aGVyZSByb29tIGJvdGggZm9yIE1PUGV4IGFuZCBmb3IgQ2FwYWJpbGl0eSBvcHRp b25zPyBPciBpdCB3aWxsIGVpdGhlciBiZSBvbmUgb3IgdGhlIG90aGVyIG9uZT88bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5bUkpdIFRoZSBkcmFmdCBhbGxvd3MgZWl0aGVyIG9yIGJvdGggb3B0aW9u cy4gV2lsbCBtYWtlIHRoaXMgZXhwbGljaXQgaW4gbmV4dCB2ZXIuPG86cD48L286cD48L3ByZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_982B626E107E334DBE601D979F31785C5DEDE962BLREML503MBXchi_-- From nobody Wed Jun 5 01:26:03 2019 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 37B74120627; Wed, 5 Jun 2019 01:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 O_9yDLjBrJrL; Wed, 5 Jun 2019 01:25:52 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE6F12061F; Wed, 5 Jun 2019 01:25:52 -0700 (PDT) Received: from [130.209.157.48] (port=50954 helo=glaroam2-132-123.wireless.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hYREw-0002gn-Te; Wed, 05 Jun 2019 09:25:51 +0100 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6EC53BEF-8702-45E8-A425-5E8B499E7688" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 5 Jun 2019 09:25:40 +0100 In-Reply-To: Cc: tsv-art@ietf.org, roll , ietf , draft-ietf-roll-useofrplinfo.all@ietf.org To: Ines Robles References: <155497956717.12785.2838340405405604916@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [Roll] Tsvart last call review of draft-ietf-roll-useofrplinfo-25 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, 05 Jun 2019 08:25:54 -0000 --Apple-Mail=_6EC53BEF-8702-45E8-A425-5E8B499E7688 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, that addresses my concern. Colin > On 17 May 2019, at 10:34, Ines Robles = wrote: >=20 > Hi Colin, >=20 > Thank you for your review and comments. We have added a new paragraph = which addresses your concern. >=20 > New Text: "Since some of the uses cases here described, use = IPv6-in-IPv6 encapsulation. It MUST take in consideration, when = encapsulation is applied, the RFC6040 [RFC6040], which defines how the = explicit congestion notification (ECN) field of the IP header should be = constructed on entry to and exit from any IPV6-in-IPV6 tunnel. = Additionally, it is recommended the reading of = [I-D.ietf-intarea-tunnels]." >=20 > Best, >=20 > Ines >=20 > On Thu, Apr 11, 2019 at 1:46 PM Colin Perkins via Datatracker = > wrote: > Reviewer: Colin Perkins > Review result: Ready with Nits >=20 > This document has been reviewed as part of the transport area review = team's > ongoing effort to review key IETF documents. These comments were = written > primarily for the transport area directors, but are copied to the = document's > authors and WG to allow them to address any issues raised and also to = the IETF > discussion list for information. >=20 > When done at the time of IETF Last Call, the authors should consider = this > review as part of the last-call comments they receive. Please always = CC > tsv-art@ietf.org if you reply to or forward = this review. >=20 > The draft updates RFC 6553 to use a different IPv6 hop-by-hop option = type for > RPL packets, to avoid some issues discovered through deployment = experience. > This looks to require a flag day cutover, and hence has some potential > interoperability concerns, but introduces no transport concern. The = draft also > describes a number of clarifications around when to use the RPL = hop-by-hop > option header and when to use IP-in-IP tunnelling, described based on = a set of > use case examples. >=20 > There do not look to be any new transport-related concerns with this = draft. >=20 > The draft does not mention ECN when using IPv6-in-IPv6 tunneling. It = is perhaps > implied, but a reference to RFC 6040 would be helpful to clarify how = ECN bits > are copied between inner and outer headers when encapsulating and = decapsulating > packets from an IPv6-in-IPv6 tunnel. ECN is seeing increasing use in = transport > protocols, so correctly propagating this information is important. >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_6EC53BEF-8702-45E8-A425-5E8B499E7688 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Thanks, that addresses my concern.
Colin


On 17 May 2019, at 10:34, Ines Robles <mariainesrobles@googlemail.com> wrote:

Hi Colin,

Thank you for your review and comments. We have added a new paragraph which addresses your concern.

New Text: "Since some of the uses cases here described, use IPv6-in-IPv6 encapsulation. It MUST take in consideration, when encapsulation is applied, the RFC6040 [RFC6040], which defines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IPV6-in-IPV6 tunnel. Additionally, it is recommended the reading of [I-D.ietf-intarea-tunnels]."

Best,

Ines

On Thu, Apr 11, 2019 at 1:46 PM Colin Perkins via Datatracker <noreply@ietf.org> wrote:
Reviewer: Colin Perkins
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

The draft updates RFC 6553 to use a different IPv6 hop-by-hop option type for
RPL packets, to avoid some issues discovered through deployment experience.
This looks to require a flag day cutover, and hence has some potential
interoperability concerns, but introduces no transport concern. The draft also
describes a number of clarifications around when to use the RPL hop-by-hop
option header and when to use IP-in-IP tunnelling, described based on a set of
use case examples.

There do not look to be any new transport-related concerns with this draft.

The draft does not mention ECN when using IPv6-in-IPv6 tunneling. It is perhaps
implied, but a reference to RFC 6040 would be helpful to clarify how ECN bits
are copied between inner and outer headers when encapsulating and decapsulating
packets from an IPv6-in-IPv6 tunnel. ECN is seeing increasing use in transport
protocols, so correctly propagating this information is important.





-- 
Colin Perkins
https://csperkins.org/




--Apple-Mail=_6EC53BEF-8702-45E8-A425-5E8B499E7688-- From nobody Thu Jun 6 03:13:26 2019 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 4C471120275 for ; Thu, 6 Jun 2019 03:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Fn_BS9UztQRG for ; Thu, 6 Jun 2019 03:13:15 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 CC6F2120158 for ; Thu, 6 Jun 2019 03:13:11 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id k20so1337187ios.10 for ; Thu, 06 Jun 2019 03:13:11 -0700 (PDT) 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=dJTAtF75obayB34fNSs4mS5NXDWyFTwzv1YpXKpr2h8=; b=oGTEJ5UGNhFZhzUkfqokkaEeIlMlsuY8ozb/X3VSzpTGfR27lZeCOzpMXfD92fOMQh +GKqrZ3nTsm4TvHmLvDtt3hYrWDNw/P+TH0NzGHitHisAwM6CrlBGZIAC7pAYunwh82P i1/Ovo2n1uXgYGVvo7nCCPPdcg53m/JHU/ZuQLBc/M1p20hBxvzufSjA+WGO0M4DRpiL DDRRW/VVnAVeWRGD42E0MeLWHpV8tRNcFIfHjIZmd8eZPOMf+5CrqbysQnmtfeTelR6U tDBOx65aPdLWqoOqbgID0eflo2b9gRmtjFBJ/Awn1yIiMN8aD8rCb2JxyDNpsTupF03E ZPqQ== 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=dJTAtF75obayB34fNSs4mS5NXDWyFTwzv1YpXKpr2h8=; b=cUD7JbCqXLwxOgGSJB4tNIdDvbgrW7tjRatL/R4IONMbtYQ7YGuDt2c72XoYd7U2sX 1SRU7NDtGfOZ1DNUH5RneUkxeTXjuBZNnUn4Dc/StTYHkkDDnCeCUhyAlZxEO0odNCt1 ShrqbQ+5IzbVHJcK5us9d/B+Zw8t+CVV0dB3paRGALMJJcAs+6vxMJIswbmP9uT1qNsF DdJvrXzVYjGEza7ICpLwgnx5hGzaVXQZCBhrf8xsWO63FBAFx+OXbsx79jRs/2G5VNBg xPGufIb3sAa9AGIAykaREEwWs36zZlJGNYsst9DtCkWkx1Byd38La+hGRUZtUx0ONB4D x4yQ== X-Gm-Message-State: APjAAAUKDbKfOWAriq4sDf3Aq7hNAt6EUxTW+uau3UgsM0qqvEoitPAk UoarRZ6tX0n23tT4TDaolOPdpsQBSqgalqd2LDvQP0am X-Google-Smtp-Source: APXvYqy02g04tlu1v9hGLdxESe4oWFgdk3zyCBHV+iJp3TQ2Iwg7vbRymcqZGKi+DyPOJDm1Sc3cbcwgjCeCcAFFDDk= X-Received: by 2002:a5d:9f4a:: with SMTP id u10mr5374690iot.243.1559815990535; Thu, 06 Jun 2019 03:13:10 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Thu, 6 Jun 2019 13:12:59 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000007e9d6058aa4f672" Archived-At: Subject: [Roll] Call for reviews for draft-ietf-roll-nsa-extension 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, 06 Jun 2019 10:13:24 -0000 --00000000000007e9d6058aa4f672 Content-Type: text/plain; charset="UTF-8" Dear all, We would like to have reviews for draft-ietf-roll-nsa-extension-01. Please let us know if you want to review it. Thank you very much, Ines and Peter --00000000000007e9d6058aa4f672 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

We would like to have reviews= for=C2=A0draft-ietf-roll-nsa-extension-01.

Please= let us know if you want to review it.=C2=A0

T= hank you very much,

Ines and Peter
--00000000000007e9d6058aa4f672-- From nobody Thu Jun 6 03:14:36 2019 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 6394A120115 for ; Thu, 6 Jun 2019 03:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 aeueNLeq0WSt for ; Thu, 6 Jun 2019 03:14:33 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 153A21200D7 for ; Thu, 6 Jun 2019 03:14:33 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id e3so1330864ioc.12 for ; Thu, 06 Jun 2019 03:14:33 -0700 (PDT) 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=O5WY1F2QaCJohrPen88wgbXVt/a0lUhqxvgtgPyQa8w=; b=CxsoWKD6S6MO2sW/DoGtcY3gUi3WPfmblA2+AX0u7tbdFv4Ve7hhL1d893T65M8uWL +WjNSl69PQCJmQ3KPzAIXN2+ibMxvAECGZVc57befZhvAVX9b43d3c8raqcHEbiN9KIZ s24VRn2d4m43H4yl3lfYLhP7iNz11BuPayZAhZgrizzy6DohzeUDcdY+qNWzpyOBlOzv PctPkX8BgkHY9wlXxl79QvfeJyZI8FRem3ykgtk56/SHYT/1SHoVVBsdEnoaCHjr8ceZ F/W4QPWkjWKbjjbV3X7IT5VwnzkBuCyB2sBafYgDUMNwDSZM9FJo+HwTz0KMEjyNWR4A 5vKg== 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=O5WY1F2QaCJohrPen88wgbXVt/a0lUhqxvgtgPyQa8w=; b=eW4NbC3+wP7ahmURdnFyU9Crf4Olfhbx3QoBgk66NhhHlE0IT9Pzdqx47wzAya9tNg geGWxJBCYSIU0wBFLSGJ3cTgoZoDFIeV7pwHZ5q7Iz2E4gdmW6YGHtAhtzjDUH2bfhgE 1Vnw8CGSKq3GhwoU/3QtwiWLTbw3ybpuWbsGsiwiqDa2oI2qb8W2JOBOzEneltmjrcnQ 0eCjRm1z/FQsyw0fhlsT2yUZBAOvKE7ncvcTD/vxa2a0l7ZLGsejBk3n2Onhnd06fZ21 Y24RtgEfz/g5YTeM10J1N8L6AkgbEuygHlsCNjBZB9JlEgn67XwQtba4R1H8MXi1tbBQ +BvQ== X-Gm-Message-State: APjAAAVgpYTZGyJ04u0Qim9X5s7aKS3qOEYfDvig/lPbM/0C1GSoSlNy WLfj+Vfu6MpxIrK4G0tdKnTx5yegem23ii0H45nd6j0+ X-Google-Smtp-Source: APXvYqyxyCP7wG3L5bXxz1g0CbrZqozPEB7LGh3nm+YUJMmA+b1VC5WB3dr2aNqJr0IDtMBjzjFCGoU56gTmoWIjEjw= X-Received: by 2002:a5d:9a11:: with SMTP id s17mr31160512iol.267.1559816072064; Thu, 06 Jun 2019 03:14:32 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Thu, 6 Jun 2019 13:14:21 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000e3f5fe058aa4fabc" Archived-At: Subject: [Roll] Call for reviews for draft-koutsiamanis-roll-traffic-aware-of-00 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, 06 Jun 2019 10:14:34 -0000 --000000000000e3f5fe058aa4fabc Content-Type: text/plain; charset="UTF-8" Dear all, We would like to have reviews for draft-koutsiamanis-roll-traffic-aware-of-00. Please let us know if you want to review it Thank you very much, Ines and Peter --000000000000e3f5fe058aa4fabc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

We would like to have reviews= for=C2=A0draft-koutsiamanis-roll-traffic-aware-of-00.

=
Please let us know if you want to review it

Thank you very much,

Ines and Peter
--000000000000e3f5fe058aa4fabc-- From nobody Thu Jun 6 05:24:26 2019 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 C26E11200F9 for ; Thu, 6 Jun 2019 05:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 iZoY0Z_-2pVI for ; Thu, 6 Jun 2019 05:24:21 -0700 (PDT) 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 6A46812004B for ; Thu, 6 Jun 2019 05:24:21 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 6900A120BEE; Thu, 6 Jun 2019 14:24:19 +0200 (CEST) Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id zzA2hH85Dprt; Thu, 6 Jun 2019 14:24:18 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 37FBB1204A3; Thu, 6 Jun 2019 14:24:18 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy130.enst.fr 37FBB1204A3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1559823858; bh=mcgCymYopNjgF71FSuPkSVHB7qtvjtxDLKfKyWkuNvc=; h=Mime-Version:From:Date:Message-Id:To; b=PJmPFXUf2N5dwd4Mwx4Pgj6VyVUeUr99/GMM0c8/pM8B0CjO2nqo50bK+qY2wIAMP iUzEH98Z3XWeItr33IxoSqMEh/X49XFDMMWaRvgT3SkC6yJ/IspU0GDp47tnW98/pD 7V6D9s2ghFDiNrdkJdPBHL1ibfYtZMzPJG85OU5o= 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 VwMVn5-CeJfU; Thu, 6 Jun 2019 14:24:17 +0200 (CEST) Received: from [IPv6:2001:660:7301:3728:6173:fa34:3be6:cf63] (unknown [IPv6:2001:660:7301:3728:6173:fa34:3be6:cf63]) by zproxy130.enst.fr (Postfix) with ESMTPSA id B9AF8120433; Thu, 6 Jun 2019 14:24:17 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2A9FD5D1-3B31-4A91-96C1-B3D78F447DEA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Georgios Z. Papadopoulos In-Reply-To: <982B626E107E334DBE601D979F31785C5DEDE962@BLREML503-MBX.china.huawei.com> Date: Thu, 6 Jun 2019 14:25:52 +0200 Cc: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" Message-Id: <6DB458C3-6242-447A-A97A-B465DD1D7805@imt-atlantique.fr> References: <5BC4C696-7FAF-4DA5-95E4-66E3DA512743@imt-atlantique.fr> <982B626E107E334DBE601D979F31785C5DEDE962@BLREML503-MBX.china.huawei.com> To: Rahul Arvind Jadhav X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Roll] Review [raft-rahul-roll-mop-ext-00] 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, 06 Jun 2019 12:24:24 -0000 --Apple-Mail=_2A9FD5D1-3B31-4A91-96C1-B3D78F447DEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rahul, Please find my responses inline: Best, Georgios > On Jun 5, 2019, at 02:53, Rahul Arvind Jadhav = wrote: >=20 > Thank you Georgios for the review and feedback. > Please find my responses inline. > =20 > Regards, > Rahul > =20 > REQ2: Optional capabilities handshake. Capabilities are features, > possibly optional, which could be handshaked between the = nodes > and the root within an RPL Instance. > [GP] Maybe few words (to give minimum background) earlier in the = Introduction about the "capabilities handshake=E2=80=9D? Otherwise it = appears too unexpectedly. > [RJ] Yes. Should have introduced capabilities in Introduction section. = Will do. [GP] Great. =20 > REQ3: Backwards compatibility. The new options and new fields in > the DIO message should be backward compatible i.e. if there > are nodes which support old MOPs they could still operate in > their own instances. > =20 > REQ4: Capabilities handshake could be optionally added with = existing > MOPs. Capabilities been optional in nature could be put to > use with existing MOPs. Capabilities and MOP-extension is > mutually independent i.e. a DIO can have a capabilities > option, MOP-extension option or both in the same message. > [GP] Structurally, I would push REQ4 before REQ3. Since both REQ2 and = 4 are related with Capabilities handshake. > [RJ] Or I could swap REQ3 and REQ2 which will make related = requirements club together? But yes, I get the point of structuring = things together and will update in next ver. [GP] Yes, it also make sense. > 3. Extended MOP Control Message Option > [GP] A structural comment here, I do not see a Subsection 3.2 and so = on, then I do not see why there should be 3.1. > [RJ] Will structure this properly. Should add a separate = =E2=80=98Extended-MOP Base Rules=E2=80=99 section (which will be Section = 3.2). [GP] Great. =20 > This document reserves existing MOP value 7 to be used as an > extender. > [GP] To make it clear, the value 7 did not represent something till = today? > DIO messages with MOP value of 7 MUST refer to the > Extended MOP (MOPex) option in the DIO message. If the MOPex = option > is absent in the DIO whose MOP is 7, then the DIO message MUST be > silently discarded. > [RJ] MOP=3D7 does not represent anything today. We have added IANA = consideration to reserve MOP=3D7. This reminds me, I need to add = Extended-MOP-Value and Capabilities flag registry in the IANA = consideration. [GP] I see, good. > [GP] with the current implementation if this value is 7, what would be = the case? It will be silently discarded as well? > [RJ] Thanks for raising this. I tried to check what happens as per = 6550. As per 6550 Section 6.3.1, the node can still join the network = with unknown MOP as a leaf node. This might have implications and may = need handling. [GP] Keep us posted if you have some news on it, please. > =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D TODO | Extended-MOP-value = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Figure 1: Extended MOP Option > [GP] Is it possible to have this Extended MOP option Figure within the = actual DIO message? > [RJ] There are 7 bits in Reserved field in DIO base message. But I=E2=80= =99m not sure if we can use those bits since otherwise there won=E2=80=99t= be any Reserved space left for future play. [GP] I see.=20 >=20 > =20 > 4.1. Capability Control Message Option > [GP] Is there room both for MOPex and for Capability options? Or it = will either be one or the other one? > [RJ] The draft allows either or both options. Will make this explicit = in next ver. [GP] Good. --Apple-Mail=_2A9FD5D1-3B31-4A91-96C1-B3D78F447DEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Rahul,

Please find my responses = inline:

Best,
Georgios

On Jun 5, 2019, at 02:53, Rahul Arvind Jadhav <rahul.jadhav@huawei.com> wrote:

Thank you Georgios for the review and = feedback.
Please find my = responses inline.
 
Regards,
Rahul
 
   REQ2:  =
Optional capabilities handshake.  Capabilities are features,
          =
possibly optional, which could be handshaked between the nodes
          and =
the root within an RPL Instance.
[GP] Maybe few words (to give =
minimum background) earlier in the Introduction about the "capabilities =
handshake=E2=80=9D? Otherwise it appears too unexpectedly.
[RJ] Yes. =
Should have introduced capabilities in Introduction section. Will =
do.

[GP] Great.
 
   REQ3:  Backwards compatibility.  The =
new options and new fields in
          the =
DIO message should be backward compatible i.e. if there
          are =
nodes which support old MOPs they could still operate in
          their =
own instances.
 
   =
REQ4:  Capabilities handshake could be optionally added with =
existing
          =
MOPs.  Capabilities been optional in nature could be put to
          use =
with existing MOPs.  Capabilities and MOP-extension is
          =
mutually independent i.e. a DIO can have a capabilities
          =
option, MOP-extension option or both in the same message.
[GP]=
 Structurally, I would push REQ4 before REQ3. Since both REQ2 and 4 are =
related with Capabilities handshake.
[RJ] Or I could swap REQ3 and REQ2 which will =
make related requirements club together? But yes, I get the point of =
structuring things together and will update in next =
ver.

[GP] = Yes, it also make sense.

3.  Extended MOP Control Message =
Option
[GP] A structural comment here, I do not see a =
Subsection 3.2 and so on, then I do not see why there should be 3.1.
[RJ] Will =
structure this properly. Should add a separate =E2=80=98Extended-MOP =
Base Rules=E2=80=99 section (which will be Section =
3.2).

[GP] = Great.
 
   This document reserves existing MOP value 7 to =
be used as an
   extender.
[GP] To make it clear, the value =
7 did not represent something till today?
   DIO messages with =
MOP value of 7 MUST refer to the
   Extended MOP (MOPex) option in =
the DIO message.  If the MOPex option
   is absent in the DIO whose MOP = is 7, then the DIO message MUST be
   silently discarded.
[RJ] MOP=3D7 =
does not represent anything today. We have added IANA consideration to =
reserve MOP=3D7. This reminds me, I need to add Extended-MOP-Value and =
Capabilities flag registry in the IANA consideration.

[GP] I see, good.

[GP] with the current =
implementation if this value is 7, what would be the case? It will be =
silently discarded as well?
[RJ] Thanks for raising this. I tried to =
check what happens as per 6550. As per 6550 Section 6.3.1, the node can =
still join the network with unknown MOP as a leaf node. This might have =
implications and may need =
handling.

[GP] Keep us posted if you have some news on it, = please.

 
        =
0            &=
nbsp;      =
1            &=
nbsp;      =
2            &=
nbsp;      3
        0 =
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D =
TODO |           =
Extended-MOP-value         &n=
bsp;        |
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
          &nb=
sp;            =
Figure 1: Extended MOP Option
[GP] Is it possible to have this =
Extended MOP option Figure within the actual DIO message?
[RJ] There are =
7 bits in Reserved field in DIO base message. But I=E2=80=99m not sure =
if we can use those bits since otherwise there won=E2=80=99t be any =
Reserved space left for future =
play.

[GP] I see. 


 
4.1.  =
Capability Control Message Option
[GP] Is there room both for MOPex =
and for Capability options? Or it will either be one or the other =
one?
[RJ] The draft =
allows either or both options. Will make this explicit in next =
ver.

[GP] = Good.

= --Apple-Mail=_2A9FD5D1-3B31-4A91-96C1-B3D78F447DEA-- From nobody Sun Jun 9 00:28:40 2019 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 28999120136 for ; Sun, 9 Jun 2019 00:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqooijsTaSvU for ; Sun, 9 Jun 2019 00:28:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0105C12006F for ; Sun, 9 Jun 2019 00:28:35 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id CE7C3FBD99DE997097E7 for ; Sun, 9 Jun 2019 08:28:32 +0100 (IST) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 9 Jun 2019 08:28:32 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.73]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0439.000; Sun, 9 Jun 2019 12:58:22 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: Review [draft-rahul-roll-mop-ext-00] Thread-Index: AdUelMxEB2foem1jRVmASImk3Dr2Hg== Date: Sun, 9 Jun 2019 07:28:22 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DEE21F7@BLREML503-MBX.china.huawei.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DEE21F7BLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Review [draft-rahul-roll-mop-ext-00] 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: Sun, 09 Jun 2019 07:28:38 -0000 --_000_982B626E107E334DBE601D979F31785C5DEE21F7BLREML503MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWxsLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIChodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFodWwtcm9sbC1tb3AtZXh0LTAxKSBiYXNlZCBvbiBm ZWVkYmFjayBmcm9tIEdlb3JnaW9zLiBUaGFua3MgR2Vvcmdpb3MuDQoNClVwZGF0ZXMgaW5jbHVk ZToNCg0KMS4gICAgICAgQSBuZXcgc2VjdGlvbiBkZXNjcmliaW5nIOKAnEhhbmRsaW5nIE1PUGV4 4oCdLiBJdCBpcyBub3cgcG9zc2libGUgdG8gbm90IGhhdmUgTU9QZXggb3B0aW9uIHdpdGggYmFz ZSBNT1AgPSA3LiBJZiBNT1BleCBpcyBub3QgcHJlc2VudCBhbmQgYmFzZSBNT1AgaXMgNywgdGhh biBmaW5hbCBNT1AgaXMgNyAoaS5lLiBNT1BleCBpcyBhc3N1bWVkIHRvIGJlIDApLiBUaGlzIGF2 b2lkcyBoYXZpbmcgdG8gc2VuZCBNT1BleCBpbiBjYXNlIG9mIE1PUD03Lg0KDQoyLiAgICAgICBS ZXN0cnVjdHVyaW5nIG9mIGZldyBzZWN0aW9ucw0KDQozLiAgICAgICBVcGRhdGVkIElBTkEgY29u c2lkZXJhdGlvbnMgKG5ldyByZWdpc3RyaWVzIGFkZGVkIGZvciBNT1BleCBhbmQgQ2FwYWJpbGl0 aWVzKS4NCg0KUmVnYXJkcywNClJhaHVsDQoNCg0KRnJvbTogR2Vvcmdpb3MgWi5QYXBhZG9wb3Vs b3MgW21haWx0bzpnZW9yZ2lvcy5wYXBhZG9wb3Vsb3NAaW10LWF0bGFudGlxdWUuZnJdDQpTZW50 OiAwNiBKdW5lIDIwMTkgMjA6MjYNClRvOiBSYWh1bCBBcnZpbmQgSmFkaGF2IDxyYWh1bC5qYWRo YXZAaHVhd2VpLmNvbT4NCkNjOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3 b3JrcyA8cm9sbEBpZXRmLm9yZz47IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0 QGNpc2NvLmNvbT4NClN1YmplY3Q6IFJlOiBSZXZpZXcgW3JhZnQtcmFodWwtcm9sbC1tb3AtZXh0 LTAwXQ0KDQpIaSBSYWh1bCwNCg0KUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIGlubGluZToNCg0K QmVzdCwNCkdlb3JnaW9zDQoNCk9uIEp1biA1LCAyMDE5LCBhdCAwMjo1MywgUmFodWwgQXJ2aW5k IEphZGhhdiA8cmFodWwuamFkaGF2QGh1YXdlaS5jb208bWFpbHRvOnJhaHVsLmphZGhhdkBodWF3 ZWkuY29tPj4gd3JvdGU6DQoNClRoYW5rIHlvdSBHZW9yZ2lvcyBmb3IgdGhlIHJldmlldyBhbmQg ZmVlZGJhY2suDQpQbGVhc2UgZmluZCBteSByZXNwb25zZXMgaW5saW5lLg0KDQpSZWdhcmRzLA0K UmFodWwNCg0KDQogICBSRVEyOiAgT3B0aW9uYWwgY2FwYWJpbGl0aWVzIGhhbmRzaGFrZS4gIENh cGFiaWxpdGllcyBhcmUgZmVhdHVyZXMsDQoNCiAgICAgICAgICBwb3NzaWJseSBvcHRpb25hbCwg d2hpY2ggY291bGQgYmUgaGFuZHNoYWtlZCBiZXR3ZWVuIHRoZSBub2Rlcw0KDQogICAgICAgICAg YW5kIHRoZSByb290IHdpdGhpbiBhbiBSUEwgSW5zdGFuY2UuDQoNCltHUF0gTWF5YmUgZmV3IHdv cmRzICh0byBnaXZlIG1pbmltdW0gYmFja2dyb3VuZCkgZWFybGllciBpbiB0aGUgSW50cm9kdWN0 aW9uIGFib3V0IHRoZSAiY2FwYWJpbGl0aWVzIGhhbmRzaGFrZeKAnT8gT3RoZXJ3aXNlIGl0IGFw cGVhcnMgdG9vIHVuZXhwZWN0ZWRseS4NCg0KW1JKXSBZZXMuIFNob3VsZCBoYXZlIGludHJvZHVj ZWQgY2FwYWJpbGl0aWVzIGluIEludHJvZHVjdGlvbiBzZWN0aW9uLiBXaWxsIGRvLg0KDQpbR1Bd IEdyZWF0Lg0KDQoNCg0KICAgUkVRMzogIEJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LiAgVGhlIG5l dyBvcHRpb25zIGFuZCBuZXcgZmllbGRzIGluDQoNCiAgICAgICAgICB0aGUgRElPIG1lc3NhZ2Ug c2hvdWxkIGJlIGJhY2t3YXJkIGNvbXBhdGlibGUgaS5lLiBpZiB0aGVyZQ0KDQogICAgICAgICAg YXJlIG5vZGVzIHdoaWNoIHN1cHBvcnQgb2xkIE1PUHMgdGhleSBjb3VsZCBzdGlsbCBvcGVyYXRl IGluDQoNCiAgICAgICAgICB0aGVpciBvd24gaW5zdGFuY2VzLg0KDQoNCg0KICAgUkVRNDogIENh cGFiaWxpdGllcyBoYW5kc2hha2UgY291bGQgYmUgb3B0aW9uYWxseSBhZGRlZCB3aXRoIGV4aXN0 aW5nDQoNCiAgICAgICAgICBNT1BzLiAgQ2FwYWJpbGl0aWVzIGJlZW4gb3B0aW9uYWwgaW4gbmF0 dXJlIGNvdWxkIGJlIHB1dCB0bw0KDQogICAgICAgICAgdXNlIHdpdGggZXhpc3RpbmcgTU9Qcy4g IENhcGFiaWxpdGllcyBhbmQgTU9QLWV4dGVuc2lvbiBpcw0KDQogICAgICAgICAgbXV0dWFsbHkg aW5kZXBlbmRlbnQgaS5lLiBhIERJTyBjYW4gaGF2ZSBhIGNhcGFiaWxpdGllcw0KDQogICAgICAg ICAgb3B0aW9uLCBNT1AtZXh0ZW5zaW9uIG9wdGlvbiBvciBib3RoIGluIHRoZSBzYW1lIG1lc3Nh Z2UuDQoNCltHUF0gU3RydWN0dXJhbGx5LCBJIHdvdWxkIHB1c2ggUkVRNCBiZWZvcmUgUkVRMy4g U2luY2UgYm90aCBSRVEyIGFuZCA0IGFyZSByZWxhdGVkIHdpdGggQ2FwYWJpbGl0aWVzIGhhbmRz aGFrZS4NCg0KW1JKXSBPciBJIGNvdWxkIHN3YXAgUkVRMyBhbmQgUkVRMiB3aGljaCB3aWxsIG1h a2UgcmVsYXRlZCByZXF1aXJlbWVudHMgY2x1YiB0b2dldGhlcj8gQnV0IHllcywgSSBnZXQgdGhl IHBvaW50IG9mIHN0cnVjdHVyaW5nIHRoaW5ncyB0b2dldGhlciBhbmQgd2lsbCB1cGRhdGUgaW4g bmV4dCB2ZXIuDQoNCltHUF0gWWVzLCBpdCBhbHNvIG1ha2Ugc2Vuc2UuDQoNCg0KMy4gIEV4dGVu ZGVkIE1PUCBDb250cm9sIE1lc3NhZ2UgT3B0aW9uDQoNCltHUF0gQSBzdHJ1Y3R1cmFsIGNvbW1l bnQgaGVyZSwgSSBkbyBub3Qgc2VlIGEgU3Vic2VjdGlvbiAzLjIgYW5kIHNvIG9uLCB0aGVuIEkg ZG8gbm90IHNlZSB3aHkgdGhlcmUgc2hvdWxkIGJlIDMuMS4NCg0KW1JKXSBXaWxsIHN0cnVjdHVy ZSB0aGlzIHByb3Blcmx5LiBTaG91bGQgYWRkIGEgc2VwYXJhdGUg4oCYRXh0ZW5kZWQtTU9QIEJh c2UgUnVsZXPigJkgc2VjdGlvbiAod2hpY2ggd2lsbCBiZSBTZWN0aW9uIDMuMikuDQoNCltHUF0g R3JlYXQuDQoNCg0KDQogICBUaGlzIGRvY3VtZW50IHJlc2VydmVzIGV4aXN0aW5nIE1PUCB2YWx1 ZSA3IHRvIGJlIHVzZWQgYXMgYW4NCg0KICAgZXh0ZW5kZXIuDQoNCltHUF0gVG8gbWFrZSBpdCBj bGVhciwgdGhlIHZhbHVlIDcgZGlkIG5vdCByZXByZXNlbnQgc29tZXRoaW5nIHRpbGwgdG9kYXk/ DQoNCiAgIERJTyBtZXNzYWdlcyB3aXRoIE1PUCB2YWx1ZSBvZiA3IE1VU1QgcmVmZXIgdG8gdGhl DQoNCiAgIEV4dGVuZGVkIE1PUCAoTU9QZXgpIG9wdGlvbiBpbiB0aGUgRElPIG1lc3NhZ2UuICBJ ZiB0aGUgTU9QZXggb3B0aW9uDQoNCiAgIGlzIGFic2VudCBpbiB0aGUgRElPIHdob3NlIE1PUCBp cyA3LCB0aGVuIHRoZSBESU8gbWVzc2FnZSBNVVNUIGJlDQoNCiAgIHNpbGVudGx5IGRpc2NhcmRl ZC4NCg0KW1JKXSBNT1A9NyBkb2VzIG5vdCByZXByZXNlbnQgYW55dGhpbmcgdG9kYXkuIFdlIGhh dmUgYWRkZWQgSUFOQSBjb25zaWRlcmF0aW9uIHRvIHJlc2VydmUgTU9QPTcuIFRoaXMgcmVtaW5k cyBtZSwgSSBuZWVkIHRvIGFkZCBFeHRlbmRlZC1NT1AtVmFsdWUgYW5kIENhcGFiaWxpdGllcyBm bGFnIHJlZ2lzdHJ5IGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb24uDQoNCltHUF0gSSBzZWUsIGdv b2QuDQoNCg0KDQpbR1BdIHdpdGggdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gaWYgdGhpcyB2 YWx1ZSBpcyA3LCB3aGF0IHdvdWxkIGJlIHRoZSBjYXNlPyBJdCB3aWxsIGJlIHNpbGVudGx5IGRp c2NhcmRlZCBhcyB3ZWxsPw0KDQpbUkpdIFRoYW5rcyBmb3IgcmFpc2luZyB0aGlzLiBJIHRyaWVk IHRvIGNoZWNrIHdoYXQgaGFwcGVucyBhcyBwZXIgNjU1MC4gQXMgcGVyIDY1NTAgU2VjdGlvbiA2 LjMuMSwgdGhlIG5vZGUgY2FuIHN0aWxsIGpvaW4gdGhlIG5ldHdvcmsgd2l0aCB1bmtub3duIE1P UCBhcyBhIGxlYWYgbm9kZS4gVGhpcyBtaWdodCBoYXZlIGltcGxpY2F0aW9ucyBhbmQgbWF5IG5l ZWQgaGFuZGxpbmcuDQoNCltHUF0gS2VlcCB1cyBwb3N0ZWQgaWYgeW91IGhhdmUgc29tZSBuZXdz IG9uIGl0LCBwbGVhc2UuDQoNCg0KDQoNCg0KICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEg ICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQoNCiAgICAgICAgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx DQoNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICAgfCAgIFR5cGUgPSBUT0RPIHwgICAgICAgICAg IEV4dGVuZGVkLU1PUC12YWx1ZSAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBFeHRlbmRlZCBNT1AgT3B0 aW9uDQoNCltHUF0gSXMgaXQgcG9zc2libGUgdG8gaGF2ZSB0aGlzIEV4dGVuZGVkIE1PUCBvcHRp b24gRmlndXJlIHdpdGhpbiB0aGUgYWN0dWFsIERJTyBtZXNzYWdlPw0KDQpbUkpdIFRoZXJlIGFy ZSA3IGJpdHMgaW4gUmVzZXJ2ZWQgZmllbGQgaW4gRElPIGJhc2UgbWVzc2FnZS4gQnV0IEnigJlt IG5vdCBzdXJlIGlmIHdlIGNhbiB1c2UgdGhvc2UgYml0cyBzaW5jZSBvdGhlcndpc2UgdGhlcmUg d29u4oCZdCBiZSBhbnkgUmVzZXJ2ZWQgc3BhY2UgbGVmdCBmb3IgZnV0dXJlIHBsYXkuDQoNCltH UF0gSSBzZWUuDQoNCg0KDQoNCg0KDQo0LjEuICBDYXBhYmlsaXR5IENvbnRyb2wgTWVzc2FnZSBP cHRpb24NCg0KW0dQXSBJcyB0aGVyZSByb29tIGJvdGggZm9yIE1PUGV4IGFuZCBmb3IgQ2FwYWJp bGl0eSBvcHRpb25zPyBPciBpdCB3aWxsIGVpdGhlciBiZSBvbmUgb3IgdGhlIG90aGVyIG9uZT8N Cg0KW1JKXSBUaGUgZHJhZnQgYWxsb3dzIGVpdGhlciBvciBib3RoIG9wdGlvbnMuIFdpbGwgbWFr ZSB0aGlzIGV4cGxpY2l0IGluIG5leHQgdmVyLg0KDQpbR1BdIEdvb2QuDQoNCg== --_000_982B626E107E334DBE601D979F31785C5DEE21F7BLREML503MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTow Y207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM2NjIyMjk5 OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4ODMy Mjc2NDAgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5IZWxsbyBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5XZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uICg8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFodWwtcm9sbC1tb3AtZXh0LTAx Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFodWwtcm9sbC1tb3AtZXh0LTAx PC9hPikNCiBiYXNlZCBvbiBmZWVkYmFjayBmcm9tIEdlb3JnaW9zLiBUaGFua3MgR2Vvcmdpb3Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5VcGRhdGVzIGluY2x1 ZGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5BIG5ldyBzZWN0aW9uIGRlc2NyaWJpbmcg4oCcSGFuZGxpbmcgTU9QZXjigJ0uIEl0IGlzIG5v dyBwb3NzaWJsZSB0byBub3QgaGF2ZSBNT1BleCBvcHRpb24gd2l0aCBiYXNlIE1PUCA9IDcuIElm IE1PUGV4IGlzIG5vdCBwcmVzZW50IGFuZCBiYXNlIE1PUCBpcyA3LA0KIHRoYW4gZmluYWwgTU9Q IGlzIDcgKGkuZS4gTU9QZXggaXMgYXNzdW1lZCB0byBiZSAwKS4gVGhpcyBhdm9pZHMgaGF2aW5n IHRvIHNlbmQgTU9QZXggaW4gY2FzZSBvZiBNT1A9Ny48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlc3RydWN0dXJpbmcgb2YgZmV3IHNlY3Rp b25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5VcGRhdGVkIElBTkEgY29uc2lkZXJhdGlvbnMgKG5ldyByZWdpc3RyaWVzIGFkZGVkIGZvciBN T1BleCBhbmQgQ2FwYWJpbGl0aWVzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJhaHVsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IEdlb3JnaW9zIFouUGFwYWRvcG91bG9zIFttYWlsdG86Z2Vv cmdpb3MucGFwYWRvcG91bG9zQGltdC1hdGxhbnRpcXVlLmZyXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IDA2IEp1bmUgMjAxOSAyMDoyNjxicj4NCjxiPlRvOjwvYj4gUmFodWwgQXJ2aW5kIEphZGhhdiAm bHQ7cmFodWwuamFkaGF2QGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBSb3V0aW5nIE92 ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7cm9sbEBpZXRmLm9yZyZndDs7IFBh c2NhbCBUaHViZXJ0IChwdGh1YmVydCkgJmx0O3B0aHViZXJ0QGNpc2NvLmNvbSZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFJldmlldyBbcmFmdC1yYWh1bC1yb2xsLW1vcC1leHQtMDBdIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBS YWh1bCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIGlubGluZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdlb3JnaW9zPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1biA1LCAyMDE5LCBhdCAwMjo1 MywgUmFodWwgQXJ2aW5kIEphZGhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhaHVsLmphZGhhdkBo dWF3ZWkuY29tIj5yYWh1bC5qYWRoYXZAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSBHZW9yZ2lvcyBmb3IgdGhlIHJldmlldyBhbmQgZmVlZGJh Y2suPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBmaW5kIG15IHJlc3Bv bnNlcyBpbmxpbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5SYWh1bDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgUkVRMjombmJzcDsgT3B0aW9uYWwgY2FwYWJpbGl0 aWVzIGhhbmRzaGFrZS4mbmJzcDsgQ2FwYWJpbGl0aWVzIGFyZSBmZWF0dXJlcyw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcG9zc2libHkgb3B0aW9uYWwsIHdoaWNoIGNvdWxkIGJlIGhhbmRzaGFrZWQg YmV0d2VlbiB0aGUgbm9kZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIHRoZSByb290IHdpdGhp biBhbiBSUEwgSW5zdGFuY2UuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im9ycGhhbnM6 IDI7d2lkb3dzOiAyO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtvdmVyZmxvdy13cmFw OiBicmVhay13b3JkIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPltHUF0mbmJzcDtNYXliZSBmZXcgd29yZHMgKHRvIGdpdmUgbWluaW11 bSBiYWNrZ3JvdW5kKSBlYXJsaWVyIGluIHRoZSBJbnRyb2R1Y3Rpb24gYWJvdXQgdGhlICZxdW90 O2NhcGFiaWxpdGllcyBoYW5kc2hha2XigJ0/IE90aGVyd2lzZSBpdCBhcHBlYXJzIHRvbyZuYnNw O3VuZXhwZWN0ZWRseS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+W1JKXSBZZXMuIFNo b3VsZCBoYXZlIGludHJvZHVjZWQgY2FwYWJpbGl0aWVzIGluIEludHJvZHVjdGlvbiBzZWN0aW9u LiBXaWxsIGRvLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltHUF0gR3JlYXQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFJFUTM6Jm5ic3A7IEJhY2t3YXJkcyBjb21w YXRpYmlsaXR5LiZuYnNwOyBUaGUgbmV3IG9wdGlvbnMgYW5kIG5ldyBmaWVsZHMgaW48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhlIERJTyBtZXNzYWdlIHNob3VsZCBiZSBiYWNrd2FyZCBjb21wYXRp YmxlIGkuZS4gaWYgdGhlcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJlIG5vZGVzIHdoaWNoIHN1 cHBvcnQgb2xkIE1PUHMgdGhleSBjb3VsZCBzdGlsbCBvcGVyYXRlIGluPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRoZWlyIG93biBpbnN0YW5jZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFJFUTQ6Jm5ic3A7IENhcGFiaWxp dGllcyBoYW5kc2hha2UgY291bGQgYmUgb3B0aW9uYWxseSBhZGRlZCB3aXRoIGV4aXN0aW5nPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1PUHMuJm5ic3A7IENhcGFiaWxpdGllcyBiZWVuIG9wdGlvbmFs IGluIG5hdHVyZSBjb3VsZCBiZSBwdXQgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNlIHdpdGgg ZXhpc3RpbmcgTU9Qcy4mbmJzcDsgQ2FwYWJpbGl0aWVzIGFuZCBNT1AtZXh0ZW5zaW9uIGlzPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11dHVhbGx5IGluZGVwZW5kZW50IGkuZS4gYSBESU8gY2FuIGhh dmUgYSBjYXBhYmlsaXRpZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3B0aW9uLCBNT1AtZXh0ZW5z aW9uIG9wdGlvbiBvciBib3RoIGluIHRoZSBzYW1lIG1lc3NhZ2UuPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtvcnBoYW5zOiAyO3dp ZG93czogMjtvdmVyZmxvdy13cmFwOiBicmVhay13b3JkIj5bR1BdIFN0cnVjdHVyYWxseSwgSSB3 b3VsZCBwdXNoIFJFUTQgYmVmb3JlIFJFUTMuIFNpbmNlIGJvdGggUkVRMiBhbmQgNCBhcmUgcmVs YXRlZCB3aXRoIENhcGFiaWxpdGllcyBoYW5kc2hha2UuPG86cD48L286cD48L3ByZT4NCjxwcmU+ W1JKXSBPciBJIGNvdWxkIHN3YXAgUkVRMyBhbmQgUkVRMiB3aGljaCB3aWxsIG1ha2UgcmVsYXRl ZCByZXF1aXJlbWVudHMgY2x1YiB0b2dldGhlcj8gQnV0IHllcywgSSBnZXQgdGhlIHBvaW50IG9m IHN0cnVjdHVyaW5nIHRoaW5ncyB0b2dldGhlciBhbmQgd2lsbCB1cGRhdGUgaW4gbmV4dCB2ZXIu PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPltHUF0gWWVzLCBpdCBhbHNvIG1ha2Ugc2Vuc2UuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 cHJlPjMuJm5ic3A7IEV4dGVuZGVkIE1PUCBDb250cm9sIE1lc3NhZ2UgT3B0aW9uPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtvcnBo YW5zOiAyO3dpZG93czogMjtvdmVyZmxvdy13cmFwOiBicmVhay13b3JkIj5bR1BdIEEgc3RydWN0 dXJhbCBjb21tZW50IGhlcmUsIEkgZG8gbm90IHNlZSBhIFN1YnNlY3Rpb24gMy4yIGFuZCBzbyBv biwgdGhlbiBJIGRvIG5vdCBzZWUgd2h5IHRoZXJlIHNob3VsZCBiZSAzLjEuPG86cD48L286cD48 L3ByZT4NCjxwcmU+W1JKXSBXaWxsIHN0cnVjdHVyZSB0aGlzIHByb3Blcmx5LiBTaG91bGQgYWRk IGEgc2VwYXJhdGUg4oCYRXh0ZW5kZWQtTU9QIEJhc2UgUnVsZXPigJkgc2VjdGlvbiAod2hpY2gg d2lsbCBiZSBTZWN0aW9uIDMuMikuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltHUF0gR3JlYXQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgcmVzZXJ2ZXMg ZXhpc3RpbmcgTU9QIHZhbHVlIDcgdG8gYmUgdXNlZCBhcyBhbjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBleHRlbmRlci48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO29ycGhhbnM6IDI7d2lkb3dzOiAyO292ZXJm bG93LXdyYXA6IGJyZWFrLXdvcmQiPltHUF0gVG8gbWFrZSBpdCBjbGVhciwgdGhlIHZhbHVlIDcg ZGlkIG5vdCByZXByZXNlbnQgc29tZXRoaW5nIHRpbGwgdG9kYXk/PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtvcnBoYW5zOiAyO3dp ZG93czogMjtvdmVyZmxvdy13cmFwOiBicmVhay13b3JkIj4mbmJzcDsmbmJzcDsgRElPIG1lc3Nh Z2VzIHdpdGggTU9QIHZhbHVlIG9mIDcgTVVTVCByZWZlciB0byB0aGU8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgRXh0ZW5kZWQgTU9QIChNT1BleCkgb3B0aW9uIGluIHRoZSBE SU8gbWVzc2FnZS4mbmJzcDsgSWYgdGhlIE1PUGV4IG9wdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBpcyBhYnNlbnQgaW4gdGhlIERJTyB3aG9zZSBNT1AgaXMgNywgdGhl biB0aGUgRElPIG1lc3NhZ2UgTVVTVCBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBzaWxlbnRseSBkaXNjYXJkZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+W1JKXSBNT1A9 NyBkb2VzIG5vdCByZXByZXNlbnQgYW55dGhpbmcgdG9kYXkuIFdlIGhhdmUgYWRkZWQgSUFOQSBj b25zaWRlcmF0aW9uIHRvIHJlc2VydmUgTU9QPTcuIFRoaXMgcmVtaW5kcyBtZSwgSSBuZWVkIHRv IGFkZCBFeHRlbmRlZC1NT1AtVmFsdWUgYW5kIENhcGFiaWxpdGllcyBmbGFnIHJlZ2lzdHJ5IGlu IHRoZSBJQU5BIGNvbnNpZGVyYXRpb24uPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bR1BdIEkgc2Vl LCBnb29kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8cHJlPltHUF0gd2l0aCB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBpZiB0aGlzIHZhbHVl IGlzIDcsIHdoYXQgd291bGQgYmUgdGhlIGNhc2U/IEl0IHdpbGwgYmUgc2lsZW50bHkgZGlzY2Fy ZGVkIGFzIHdlbGw/PG86cD48L286cD48L3ByZT4NCjxwcmU+W1JKXSBUaGFua3MgZm9yIHJhaXNp bmcgdGhpcy4gSSB0cmllZCB0byBjaGVjayB3aGF0IGhhcHBlbnMgYXMgcGVyIDY1NTAuIEFzIHBl ciA2NTUwIFNlY3Rpb24gNi4zLjEsIHRoZSBub2RlIGNhbiBzdGlsbCBqb2luIHRoZSBuZXR3b3Jr IHdpdGggdW5rbm93biBNT1AgYXMgYSBsZWFmIG5vZGUuIFRoaXMgbWlnaHQgaGF2ZSBpbXBsaWNh dGlvbnMgYW5kIG1heSBuZWVkIGhhbmRsaW5nLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0dQXSBL ZWVwIHVzIHBvc3RlZCBpZiB5b3UgaGF2ZSBzb21lIG5ld3Mgb24gaXQsIHBsZWFzZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyBUeXBlID0gVE9ETyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4dGVuZGVkLU1PUC12YWx1ZSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3VyZSAxOiBFeHRlbmRlZCBNT1AgT3B0aW9uPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtvcnBo YW5zOiAyO3dpZG93czogMjtvdmVyZmxvdy13cmFwOiBicmVhay13b3JkIj5bR1BdIElzIGl0IHBv c3NpYmxlIHRvIGhhdmUgdGhpcyBFeHRlbmRlZCBNT1Agb3B0aW9uIEZpZ3VyZSB3aXRoaW4gdGhl IGFjdHVhbCBESU8gbWVzc2FnZT88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5bUkpdIFRoZXJlIGFy ZSA3IGJpdHMgaW4gUmVzZXJ2ZWQgZmllbGQgaW4gRElPIGJhc2UgbWVzc2FnZS4gQnV0IEnigJlt IG5vdCBzdXJlIGlmIHdlIGNhbiB1c2UgdGhvc2UgYml0cyBzaW5jZSBvdGhlcndpc2UgdGhlcmUg d29u4oCZdCBiZSBhbnkgUmVzZXJ2ZWQgc3BhY2UgbGVmdCBmb3IgZnV0dXJlIHBsYXkuPG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5bR1BdIEkgc2VlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8cHJlPjxicj48YnI+PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+NC4xLiZuYnNw OyBDYXBhYmlsaXR5IENvbnRyb2wgTWVzc2FnZSBPcHRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO29ycGhhbnM6IDI7d2lkb3dz OiAyO292ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQiPltHUF0gSXMgdGhlcmUgcm9vbSBib3RoIGZv ciBNT1BleCBhbmQgZm9yIENhcGFiaWxpdHkgb3B0aW9ucz8gT3IgaXQgd2lsbCBlaXRoZXIgYmUg b25lIG9yIHRoZSBvdGhlciBvbmU/PG86cD48L286cD48L3ByZT4NCjxwcmU+W1JKXSBUaGUgZHJh ZnQgYWxsb3dzIGVpdGhlciBvciBib3RoIG9wdGlvbnMuIFdpbGwgbWFrZSB0aGlzIGV4cGxpY2l0 IGluIG5leHQgdmVyLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bR1BdIEdvb2QuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_982B626E107E334DBE601D979F31785C5DEE21F7BLREML503MBXchi_-- From nobody Sun Jun 16 16:09:58 2019 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 5461512010C for ; Sun, 16 Jun 2019 16:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 RHO_tio5jx16 for ; Sun, 16 Jun 2019 16:09:53 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 A840F120099 for ; Sun, 16 Jun 2019 16:09:53 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id e189so5690111oib.11 for ; Sun, 16 Jun 2019 16:09:53 -0700 (PDT) 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=2z3BzjeMsa/b9ko2Gw8hZ4qznizfEn7p2LvBQ/fqNFA=; b=CdXB1vcz9mMZ83E6jNdiieBidmmuqxeyNT+YBmgD/eSMIbx50Y0kQDVXV9N+/7ufyX W+7qLEOdHo2ktlG/rZZjBRf2rWJKkdbvg+cTMp1rsaw5zRNHBKDzNNuzFefMZsX2HdHa FaYOXjle738efrZFCeFZR4gM8CcR5LqFxHhw4e9y5+Y4/JKmqiJRum1KUI7DO88rry/y snjmYTguDcNdcqyw8wORota1HA7aK4KY6JE1Yu6VFJbj45ze9gZ9QC2+ZSak61AuOH4c ao2DPArjpv5t39img3Wrcl33/vU+jvK66lRs9DLUAepSTvkse8I3OhYJXD39rxQEI3wc 0MfA== 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=2z3BzjeMsa/b9ko2Gw8hZ4qznizfEn7p2LvBQ/fqNFA=; b=iq9e08AEo3zJAguAB6smfwLJbhpXyWHPCxHS8NfLbduWZr2MsQaMRqV6d91182HvZr dJ5I4yFnYmiiS2jR6Uc1TihX51D3nKyMi4dE3/eeSBn7Na1CxaQOTeOdNfI1mPKDVZ02 IIvD1TB69+EQcJhakNV5huXxN4AK7f/UFrK1JsvjhSfvFBgarpUwEYW99cqMOc2mHRak xg67ouNpU4jpdm79jLB9T/LNSMNwNrfhZDlp4IjomK360nMCR4VT0k/Q6O40Ns9wEZfY iGmvLq9wSGcBdP8byxLH6Z3W9+AMSuFqkccq8n7WhlC2oBXnMVIJiHLzSdEUVXMfOaGx Je6Q== X-Gm-Message-State: APjAAAVlDT9d/agNi6VldAEDoB1s/HuQY2TMDD+WfuoaUfHqYgVB9M+o 8HroixggqA+Pq7MV1GKAP8t1cagrfBN0kKom9Gd8tw== X-Google-Smtp-Source: APXvYqxomvTXwTvsZtPIfDCTY7BYLVaQvxacqwz2fZFwKj4unYxmySweVqUVWIWy+KmpJR3npTAPg9CEqIrYL+kQdX0= X-Received: by 2002:aca:5612:: with SMTP id k18mr9094210oib.12.1560726592778; Sun, 16 Jun 2019 16:09:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Abdussalam Baryun Date: Mon, 17 Jun 2019 01:09:35 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="0000000000002778b6058b78fa23" Archived-At: Subject: Re: [Roll] Call for reviews for draft-ietf-roll-nsa-extension 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: Sun, 16 Jun 2019 23:09:56 -0000 --0000000000002778b6058b78fa23 Content-Type: text/plain; charset="UTF-8" Hi Ines and Peter, IMHO the draft is not clear in its use-case, I think it must include rfc8578 to clarify its usecase, and using references of architectures does not help us understand but makes it more difficult. AB On Thu, Jun 6, 2019 at 12:13 PM Ines Robles wrote: > Dear all, > > We would like to have reviews for draft-ietf-roll-nsa-extension-01. > > Please let us know if you want to review it. > > Thank you very much, > > Ines and Peter > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0000000000002778b6058b78fa23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ines and Peter,

IMHO the = draft is not clear in its use-case, I think it must include rfc8578 to clar= ify its usecase, and using references of architectures does not help us und= erstand but makes it more difficult.

AB



On Thu, Jun 6, 2019 at 12:13 PM Ines Robles <= ;mariainesrobles=3D40goo= glemail.com@dmarc.ietf.org> wrote:
Dear all,

We would like to have reviews for=C2= =A0draft-ietf-roll-nsa-extension-01.

Please let us= know if you want to review it.=C2=A0

Thank yo= u very much,

Ines and Peter
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--0000000000002778b6058b78fa23-- From nobody Wed Jun 19 02:02:14 2019 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 64C451203ED; Wed, 19 Jun 2019 02:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=aMB3tZRj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zOKLLiat Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2a7_FAckja7; Wed, 19 Jun 2019 02:01:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D9712002F; Wed, 19 Jun 2019 02:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6800; q=dns/txt; s=iport; t=1560934908; x=1562144508; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=KwzUy7227Bn1VL0d90mjkqk2Ib67V2jT1qAAeeslWVY=; b=aMB3tZRj2ZQSXGmp9hF6Wf4eU3OEoihbuoNmROih+phaIG6HZSJ715Yv r0OnJxXmFAtjjsPpI83iuHMC87mq+FfnwFj2FIL+AAm5v0h19U9FK7PFA Fmr4uRmS8uFYcZPiltI4cEVc22Bc7W/XHtCLXfwRkb1J9onMRs9mXcZi/ c=; IronPort-PHdr: =?us-ascii?q?9a23=3AJBnRnhwA2SUKd3rXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZueCVL2MP7jZQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAAB0+Qld/5pdJa1mHQEBBQEHBQG?= =?us-ascii?q?BUQgBCwGBPVADalUgBAsoCoQMg0cDhFKKDYJXlzaBLoEkA1QJAQEBDAEBGA0?= =?us-ascii?q?IAgEBhEACF4I7IzQJDgEDAQEEAQECAQRtHAyFSgEBAQEDAQEQEREMAQEsCwE?= =?us-ascii?q?LBgEIEQQBAQMCIwMCBCULFAEICgQBDQUigwABgWoDHQEOnR4CgTiIX3GBMYJ?= =?us-ascii?q?5AQEFhQMYghADBoEMKAGLXReBQD+BEScfgkw+gmEBAQIBgVENgwoygiaLYYJ?= =?us-ascii?q?fjT6NBGQJAoIQhkiJI4NoG4InhwaOB40dhySPQwIEAgQFAg4BAQWBUDiBWHA?= =?us-ascii?q?VOyoBgg0BM4IPg3CFFIU/cgEBgSeLKYEvAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.63,392,1557187200"; d="scan'208";a="490298522" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Jun 2019 09:01:46 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5J91kAj018229 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Jun 2019 09:01:46 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 04:01:45 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 04:01:44 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 19 Jun 2019 05:01:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KwzUy7227Bn1VL0d90mjkqk2Ib67V2jT1qAAeeslWVY=; b=zOKLLiatFWh7UjcuILG7hRY8pIKzkODEhqCSnwEvGG21jeBGACMbugBA4yJc3NTAjG8XZ6bv8Vi5mnfDK0o/EHwPwXXpqfkl9bzTeJT+bo4yzrI9chF+XhtMZUJZ8rb+VyDgBuCgT69dY+or99JqfuJRUGDdWp1rMjqBk7UvzGk= Received: from CY4PR11MB0054.namprd11.prod.outlook.com (10.171.254.155) by CY4PR11MB1367.namprd11.prod.outlook.com (10.173.16.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Wed, 19 Jun 2019 09:01:43 +0000 Received: from CY4PR11MB0054.namprd11.prod.outlook.com ([fe80::f9ff:4267:2991:868d]) by CY4PR11MB0054.namprd11.prod.outlook.com ([fe80::f9ff:4267:2991:868d%6]) with mapi id 15.20.1987.014; Wed, 19 Jun 2019 09:01:43 +0000 From: "Shwetha Bhandari (shwethab)" To: Rahul Arvind Jadhav , "Iot-dir@ietf.org" CC: "draft-ietf-roll-efficient-npdao.all@ietf.org" , "roll@ietf.org" , "ietf@ietf.org" Thread-Topic: [IoT-DIR] Iotdir last call review of draft-ietf-roll-efficient-npdao-11 Thread-Index: AQHVJn2d/4lh1kp3ZUyt8Mdhf4AsyQ== Date: Wed, 19 Jun 2019 09:01:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=shwethab@cisco.com; x-originating-ip: [72.163.220.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74407e10-0e67-4246-b05a-08d6f494bfda x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR11MB1367; x-ms-traffictypediagnostic: CY4PR11MB1367: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0073BFEF03 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(39860400002)(376002)(136003)(51914003)(199004)(189003)(13464003)(7736002)(2906002)(14444005)(66476007)(58126008)(26005)(8676002)(186003)(8936002)(86362001)(91956017)(2616005)(81166006)(305945005)(71200400001)(6486002)(54906003)(76116006)(68736007)(53546011)(6436002)(229853002)(476003)(99286004)(66066001)(6506007)(102836004)(71190400001)(316002)(5660300002)(110136005)(36756003)(81156014)(33656002)(66946007)(478600001)(4326008)(6512007)(66574012)(66446008)(14454004)(486006)(73956011)(6306002)(25786009)(64756008)(6116002)(53936002)(6246003)(66556008)(2501003)(256004)(3846002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1367; H:CY4PR11MB0054.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IeqQh4FG11vAwTVGvtYyC7TEnJeTzyAs1ukF//1tnTc6OIN0xjBtbZWpYOJSNAJ04CPPh1ALHwA5fy/DPwJutYFBjaMw8W18kJylbGnWF+RV+sxHGtUW1fp9LOa4rcPPW6GolrBJ1ulZnQ2YUu/hGqzBy8Z+8AKykq/bzbUiOBNs2hVKhKJ/hJGSP45rRApFbcIN1IHKWJldYnCNwlfiAEKsRJWoUjUwRJTsCI7wi6NO3BCoZh4Ns9npThYyzwT+xqCanS6leOWP6Gl4laS1ZdAU2+16pEvTV8oNW9PXCky6ZDDDwSA42aAeakOm0EpgWboRodKD8dbzMMIa4f59hw4D/Wjx/8DTfsc9Inb+fM3dtRtrq7Evl0TGTd3MpjQXY+B1SsD+bkRAuuVot7pedqViQ0RsZWWHU0aP0P8KOqM= Content-Type: text/plain; charset="utf-8" Content-ID: <1AEBB217A4C1E845935F4038CD3F127E@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 74407e10-0e67-4246-b05a-08d6f494bfda X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2019 09:01:42.9431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: shwethab@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1367 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Roll] [IoT-DIR] Iotdir last call review of draft-ietf-roll-efficient-npdao-11 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, 19 Jun 2019 09:01:52 -0000 SGkgUmFodWwsDQoNClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLg0KDQpJIHNlZSB0aGUgdXNlZnVs bmVzcyBvZiB0aGUgZHJhZnQgdG8gbWVldCBSZXEjMTogUmVtb3ZlIG1lc3NhZ2luZyBkZXBlbmRl bmN5IG9uIGxpbmsgdG8gdGhlIHByZXZpb3VzIHBhcmVudC4NCkZyb20gd2hhdCB5b3UgZXhwbGFp biBpdCBpcyBoYXJkIHRvIG1lZXQgICJSZXEjMzogUm91dGUgaW52YWxpZGF0aW9uIHNob3VsZCBu b3QgaW1wYWN0IGRhdGEgdHJhZmZpYyIgYXMgbG9uZyBhcyBib3RoIG1ldGhvZHMgb2YgY2xlYW4g dXAgZXhpc3QuIEkgaGF2ZSBubyBmdXJ0aGVyIGNvbW1lbnRzLg0KDQpUaGFua3MsDQpTaHdldGhh DQoNCu+7v09uIDYvMTMvMTksIDEwOjA4IFBNLCAiSW9ULURJUiBvbiBiZWhhbGYgb2YgUmFodWwg QXJ2aW5kIEphZGhhdiIgPGlvdC1kaXItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcmFo dWwuamFkaGF2QGh1YXdlaS5jb20+IHdyb3RlOg0KDQogICAgVGhhbmsgeW91IFNod2V0aGEgZm9y IHlvdXIgcmV2aWV3IGFuZCBwbGVhc2UgZmluZCBteSByZXNwb25zZXMgaW5saW5lLg0KICAgIA0K ICAgIFJlZ2FyZHMsDQogICAgUmFodWwNCiAgICANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQogICAgPiBGcm9tOiBTaHdldGhhIEJoYW5kYXJpIHZpYSBEYXRhdHJhY2tlciBbbWFp bHRvOm5vcmVwbHlAaWV0Zi5vcmddDQogICAgPiBTZW50OiAzMSBNYXkgMjAxOSAxNzo1MA0KICAg ID4gVG86IElvdC1kaXJAaWV0Zi5vcmcNCiAgICA+IENjOiBkcmFmdC1pZXRmLXJvbGwtZWZmaWNp ZW50LW5wZGFvLmFsbEBpZXRmLm9yZzsgcm9sbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZw0KICAg ID4gU3ViamVjdDogSW90ZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1yb2xsLWVm ZmljaWVudC1ucGRhby0xMQ0KICAgID4gDQogICAgPiBSZXZpZXdlcjogU2h3ZXRoYSBCaGFuZGFy aQ0KICAgID4gUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBJc3N1ZXMNCiAgICA+IA0KICAgID4g SSBhbSBhbiBhc3NpZ25lZCBJT1QgZGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIDxkcmFmdC1pZXRm LXJvbGwtZWZmaWNpZW50LW5wZGFvDQogICAgPiA+LiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0 ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgSW50ZXJuZXQNCiAgICA+ID5BcmVh DQogICAgPiBEaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIHNoZXBoZXJkKHMpIHNob3Vs ZCB0cmVhdCB0aGVzZSBjb21tZW50cw0KICAgID4ganVzdCBsaWtlIHRoZXkgd291bGQgdHJlYXQg Y29tbWVudHMgZnJvbSBhbnkgb3RoZXIgSUVURiBjb250cmlidXRvcnMgYW5kDQogICAgPiByZXNv bHZlIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgaGF2 ZSBiZWVuDQogICAgPiByZWNlaXZlZC4gRm9yIG1vcmUgZGV0YWlscyBvbiB0aGUgSU9UIERpcmVj dG9yYXRlLCBzZWUNCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZ3JvdXAvaW90 ZGlyL2Fib3V0Lw0KICAgID4gDQogICAgPiBGb2xsb3dpbmcgc2VjdGlvbnMvdGV4dCBuZWVkIGNs YXJpZmljYXRpb24gYXMgcmVxdWVzdGVkIGJlbG93Og0KICAgID4gDQogICAgPiA+IDIuMi4gIElu dmFsaWRhdGUgcm91dGVzIG9mIGRlcGVuZGVudCBub2Rlcw0KICAgID4gDQogICAgPiBJIGFtIGEg Yml0IGNvbmZ1c2VkIGFib3V0IHdoYXQgdGhpcyBzZWN0aW9uIGltcGxpZXMuICBJbiB0aGUgc3Rv cmluZyBtb2RlLCBSSUINCiAgICA+IHRoYXQgcmVzdWx0cyBpbiB0aGUgNkxScyB3aXRoIHRoZSBE QU8gcmVjZWl2ZWQgd2lsbCByZXN1bHQgaW4gdGhlIGlkZW50aWZ5aW5nDQogICAgPiBkZXBlbmRl bnQgbm9kZXMuIFNlZSBFLmcgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1NTAjYXBw ZW5kaXgtDQogICAgPiBBLjIuMiBhbmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1 NTAjYXBwZW5kaXgtQS4yLjMuIFdpdGggdGhpcyBhDQogICAgPiBOUERBTyByZWNlaXZlZCBmcm9t IGEgbm9kZSB0aGF0IGlzIHRoZSBuZXh0IGhvcCBmb3IgaXRzIGRlcGVuZGVudCBub2Rlcw0KICAg ID4gc2hvdWxkIHJlc3VsdCBpbiB0aGUgcGFyZW50IGNsZWFuIHVwIHJvdXRlcyB0byB0aGUgZGVw ZW5kZW50IG5vZGVzIGFzIHdlbGwNCiAgICA+IGFzIGdlbmVyYXRlIERBTyB0byByZWZsZWN0IHRo ZSB1cGRhdGVkIFJJQi4gSWYgdGhpcyBpcyBjb3JyZWN0IHRoZW4gd2h5IHdvdWxkDQogICAgPiBp bnZhbGlkYXRpbmcgcm91dGVzIG9mIGRlcGVuZGVudCBub2RlcyBiZSBhbiBpc3N1ZSB3aXRoIGV4 aXN0aW5nIFJQTCArDQogICAgPiBOUERBTyBtZWNoYW5pc20/DQogICAgDQogICAgW1JKXSBZZXMs IHRoaXMgaXMgY29ycmVjdCB0byB0aGUgcG9pbnQgdGhhdCBfaWZfIE5QREFPIGlzIHJlY2VpdmVk IGZyb20gdGhlIChzdWIpY2hpbGQgbm9kZSB0aGVuIGl0IHdpbGwgcmVzdWx0IGluIHRoZSBzdWJz ZXF1ZW50IGNsZWFudXAgb2YgaXRzIHBhdGguIA0KICAgIFRoZSBwcm9ibGVtIHdpdGggc3Rvcmlu ZyBNT1AgaXMgdGhhdCB0aGVyZSBpcyBhYnNvbHV0ZWx5IG5vIHdheSBmb3IgYSBzdWItY2hpbGQg bm9kZSB0byB0cmlnZ2VyIHRoaXMgTlBEQU8gKHNpbmNlIGl0cyBwYXJlbnQgYWRqYWNlbmNpZXMg bWF5IG5vdCBoYXZlIGNoYW5nZWQpLiBXaGF0IERDTyBhY2hpZXZlcyBpcyBpbmRlcGVuZGVuY2Ug ZnJvbSB0aGlzIHRyaWdnZXIgb2YgTlBEQU8gYnkgdHJpZ2dlcmluZyBEQ08gZnJvbSBhbmNlc3Rv ciBvbiB0aGUgYmFzaXMgb2YgcmVndWxhciBEQU8gKHdoZW5ldmVyIGl0IGZsb3dzKSBmcm9tIHRo ZSAoc3ViKWNoaWxkIG5vZGUuIFRodXMgZXZlbiBpZiAoc3ViKWNoaWxkJ3MgcGFyZW50IGFkamFj ZW5jaWVzIGhhdmUgbm90IGNoYW5nZWQgdGhlIGFuY2VzdG9yIGtub3dzIHRoYXQgcGF0aHMgZm9y IHRoYXQgKHN1YiljaGlsZCBub2RlIGhhcyBjaGFuZ2VkLg0KICAgIA0KICAgICBJTUhPIFJvdXRl IGludmFsaWRhdGlvbiBhbmQgUklCIG1haW50ZW5hbmNlIGJhc2VkIG9uDQogICAgPiBSUEwgbWVz c2FnaW5nIGlzIGFuIGltcGxlbWVudGF0aW9uIGRlY2lzaW9uIHRoYXQgUlBMIGRvZXNudCBoYXZl IHRvIHNwZWNpZnkuDQogICAgPiANCiAgICA+ID4gIkRlcGVuZGVudCBub2RlcyByb3V0ZSBpbnZh bGlkYXRpb24gb24gcGFyZW50IHN3aXRjaGluZyINCiAgICA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvLTExI3NlY3Rpb24tMy4yDQog ICAgPiBCYXNlZCBvbiByZXNwb25zZSB0byB0aGUgYWJvdmUgdGhpcyByZXF1aXJlbWVudCBtYXkg bm90IHJlYWxseSBiZSBjYWxsZWQNCiAgICA+IG91dCBoZXJlPw0KICAgID4gDQogICAgPiA+NC42 LjEuICBEZXBlbmRlbnQgTm9kZXMgaW52YWxpZGF0aW9uDQogICAgPiBGb3IgdGhlIHNhbWUgcmVh c29ucyBhcyBhYm92ZSBpdCBpcyBjb25mdXNpbmcgd2h5IHRoaXMgY29uc2lkZXJhdGlvbiBpcw0K ICAgID4gbmVlZGVkLg0KICAgID4gDQogICAgPiA+TlBEQU8gYW5kIERDTyBpbiB0aGUgc2FtZSBu ZXR3b3JrDQogICAgPiBJbiBhIG5ldHdvcmsgdGhhdCBoYXMgbWl4IG9mIG5vZGVzIHdpdGggRENP IGltcGxlbWVudGF0aW9uIGhvdyB3aWxsIGEgbm9kZQ0KICAgID4gaXMgdXBkYXRlZCB3aXRoIERD TyBpbXBsZW1lbnRhdGlvbiBkZWNpZGUgb24gcmVjb21tZW5kZWQgb3B0aW9uIDI/IFRoZQ0KICAg ID4gY2hvaWNlIG9mIHBpY2tpbmcgb3B0aW9uIDIgbGFyZ2VseSBkZXBlbmRzIG9uIGNhcGFiaWxp dHkgb2YgdGhlIHVwc3RyZWFtDQogICAgPiBub2RlcyAgcmF0aGVyIHRoYW4gdGhlIG5vZGUgdGhh dCB3YW50cyB0byBpbnZhbGlkYXRlIGEgcHJlZml4IHRvIGl0c2VsZi4gSXMgdGhlcmUNCiAgICA+ IGEgd2F5IHRvIGRpc2NvdmVyIGNhcGFiaWxpdHkgb2YgdGhlIHVwc3RyZWFtIG5vZGVzIGluIG9s ZCBhbmQgbmV3IHBhdGggdG8NCiAgICA+IHNlZSBpZiBEQ08gaXMgaW1wbGVtZW50ZWQgYmVmb3Jl IHRoYXQgY2hvaWNlIGNhbiBiZSBtYWRlPw0KICAgID4gDQogICAgDQogICAgW1JKXSBUaGVyZSBp cyBjdXJyZW50bHkgbm8gd2F5IGZvciBkb3duc3RyZWFtIG5vZGVzIHRvIGtub3cgd2hldGhlciB0 aGUgdXBzdHJlYW0gbm9kZXMgZW4tcm91dGUgc3VwcG9ydCBEQ08uIE5vdGUgdGhhdCBpZiBEQ08g aXMgbm90IGltcGxlbWVudGVkIGluIGFuY2VzdG9yIG5vZGUgdGhlbiB0aGUgaW52YWxpZGF0aW9u IG9mIHRoZSBwcmV2aW91cyBwYXRoIHdvbid0IGhhcHBlbiAod2hpY2ggbWVhbnMgY2xlYW51cCBv bmx5IG9uIHJvdXRlLWxpZmV0aW1lIGV4cGlyeSkuIEFsc28gbm90ZSB0aGF0IGN1cnJlbnQgTlBE QU8gYWxzbyBkZXBlbmRzIG9uIHRoZSBub2RlJ3MgY29ubmVjdGl2aXR5IHRvIGl0cyBwcmV2aW91 cyBwYXJlbnQgYmVlbiBpbnRhY3QuIFRodXMgaWYgTlBEQU8gdGhhdCB3b3VsZCBoYXZlIGJlZW4g Z2VuZXJhdGVkIChvbiBsb3NzIG9mIGNvbm5lY3Rpdml0eSkgd291bGQgc3RpbGwgbm90IGhhdmUg d29ya2VkIGFueXdheXMgKHdoaWNoIG1lYW5zIGNsZWFudXAgb24gcm91dGUtbGlmZXRpbWUgZXhw aXJ5KS4gTm90ZSB0aGF0IG5ldHdvcmsgd2l0aCBwYXJ0aWFsIG5vZGVzIHN1cHBvcnRpbmcgRENP cyBpcyBub3QgZmF0YWwgYXQgYWxsLiBUaGUgb25seSBwb2ludCBpcyByb3V0ZSBjbGVhbnVwIG1h eSBiZSBzdWItb3B0aW1hbCB0aWxsIHRoZSBwb2ludCB0aGUgbmV0d29yayBpcyBjb21wbGV0ZWx5 IHVwZ3JhZGVkLg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgSW9ULURJUiBtYWlsaW5nIGxpc3QNCiAgICBJb1QtRElSQGlldGYu b3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb3QtZGlyDQog ICAgDQoNCg== From nobody Wed Jun 19 08:11:42 2019 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 4E6731200E0 for ; Wed, 19 Jun 2019 08:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5F-38bMAthRZ for ; Wed, 19 Jun 2019 08:11:36 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.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 0D9A6120198 for ; Wed, 19 Jun 2019 08:11:35 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 45TT1d1khFz8spl; Wed, 19 Jun 2019 17:11:33 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 45TT1d0khfz3wb4; Wed, 19 Jun 2019 17:11:33 +0200 (CEST) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([fe80::f04d:ad3c:61de:a175%21]) with mapi id 14.03.0439.000; Wed, 19 Jun 2019 17:11:32 +0200 From: To: Routing Over Low power and Lossy networks CC: "mariainesrobles@googlemail.com" , "Georgios Z. Papadopoulos" Thread-Topic: [Roll] Call for reviews for draft-ietf-roll-nsa-extension Thread-Index: AQHVJrFGUxOXza9/Qkay5Yz8kfayDw== Date: Wed, 19 Jun 2019 15:11:32 +0000 Message-ID: <8671_1560957093_5D0A50A5_8671_291_1_D930160F.6253D%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.247] Content-Type: multipart/alternative; boundary="_000_D930160F6253Ddominiquebarthelorangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Call for reviews for draft-ietf-roll-nsa-extension 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, 19 Jun 2019 15:11:40 -0000 --_000_D930160F6253Ddominiquebarthelorangecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpIZXJlIGlzIG15IHJldmlldyBvZiBkcmFmdC1pZXRmLXJvbGwtbnNhLWV4 dGVuc2lvbi0wMi4NCkkgZm91bmQgaXQgd2VsbCB3cml0dGVuLCB3aXRoIHRoZSBhcHByb3ByaWF0 ZSBhbW91bnQgb2YgaW50cm9kdWN0b3J5IG1hdGVyaWFsIGFuZCByZWZlcmVuY2VzLg0KSSBvbmx5 IGhhdmUgYSBmZXcgY29tbWVudHMsIGFzIHdlbGwgYXMsIHRoaXMgYmVpbmcgbWUsIGEgbGlzdCBv ZiBlZGl0b3JpYWwgbml0cy4gU2VlIGJlbG93Lg0KQmVzdCByZWdhcmRzDQoNCkRvbWluaXF1ZQ0K DQo9PQ0KDQpDb21tZW50cw0KDQogICogICBzZWN0aW9uIDMuNDogSSBiZWxpZXZlIE9QVElPTkFM IGFuZCBNQVkgc2hvdWxkIGJlIGxvd2VyY2FzZSBoZXJlLCBzaW5jZSB0aGlzIGRyYWZ0IG9ubHkg c3BlY2lmaWVzIHRoZSBETUMgZXh0ZW5zaW9uLCBub3QgdGhlIE9iamVjdGl2ZSBGdW5jdGlvbi4N CiAgKiAgIHNlY3Rpb25zIDQuMS4xIGFuZCA0LjEuMjogdGhlIERNQyBoZWFkZXIgZmllbGRzIGFy ZSBkZWZpbmVkIGluIFJGQzY1NTEsIG5vdCA2NTUwLg0KICAqICAgc2VjdGlvbiA0LjEuMTogaW4g UkZDNjU1MSwgdGhlIFByZWMgZmllbGQgaXMgbWVhbnQgdG8gYmUgdXNlZCBmb3IgbWV0cmljcywg bm90IGZvciBjb25zdHJhaW50cy4gVGhlcmVmb3JlLCBpdCBpcyB1bnVzZWQgZm9yIHRoaXMgTlNB IGV4dGVuc2lvbiwgd2hpY2ggaXMgYSBjb25zdHJhaW50LiBVbmZvcnR1bmF0ZWx5LCBSRkM2NTUx IGZvcmdvdCB0byBzcGVjaWZ5IGEgZGVmYXVsdCB2YWx1ZS4gSXMgdGhpcyB0aGUgcmVhc29uIHdo eSB5b3Ugc2F5IOKAnHVzZWQgYWNjb3JkaW5nIHRvIFJGQ+KApuKAnT8gSSBzdWdnZXN0IHlvdSB1 c2UgdGhlIHNhbWUgdGV4dCBmb3IgdGhlIFByZWMgYW5kIEEgZmllbGRzLiBJdCBjb3VsZCBiZSBx dW90aW5nIHRoZSB0ZXh0IGZyb20gUkZDNjU1MSwgb2YgcmVmZXJyaW5nIHRoZSByZWFkZXIgdG8g aXQsIG9yIHNheSBub3RoaW5nLg0KICAqICAgc2VjdGlvbiA0LjEuMjog4oCcRm9yIGNsYXJpdHkg cmVhc29ucywgdGhlIHVzYWdlIG9mIHRoZSBQUyBwbGFjZXMgbm8gYWRkaXRpb25hbCByZXN0cmlj dGlvbnMgb24gdGhlIE5TQSBmbGFncyAo4oCZQeKAmSBhbmQg4oCZT+KAmSksIHdoaWNoIGNhbiBi ZSB1c2VkIGFzIG5vcm1hbGx5IGRlZmluZWQgaW4gW1JGQzY1NTBd4oCdLiBUaGUgY2xhcml0eSBy ZWFzb25zIGVzY2FwZWQgbWUsIGFzIHdlbGwgYXMgdGhlIGFkZGl0aW9uYWwgcmVzdHJpY3Rpb25z IHRoYXQgY291bGQgaGF2ZSBiZWVuIHBsYWNlZCBidXQgd2hpY2ggaGF2ZSBub3QhIEFueXdheSwg UkZDNjU1MSBzdGF0ZXMgdGhhdCB0aGUgQSBGaWVsZCBpcyBub3QgdXNlZCB3aXRoIGNvbnN0cmFp bnRzLiBPdmVyYWxsLCBJIHRoaW5rIHRoaXMgd2hvbGUgc3Vic2VjdGlvbiBjb3VsZCBnbyBhd2F5 IHNpbmNlIGl0IHNwZWNpZmllcyBub3RoaW5nLCBzYXlzIHRoYXQgaXQgZG9lcyBub3Qgc3BlY2lm eSBhbnl0aGluZyBidXQgZG9lcyBub3Qgc2F5IHdoeSBpdCBzYXlzIGl0LiA7LSkNCiAgKiAgIFNl Y3Rpb24gNC4yOiAiVGhlcmVmb3JlLCB0aGUgUFMgSVB2NiBhZGRyZXNzKGVzKSBmaWVsZCBTSE9V TEQgYmUgY29tcHJlc3NlZCB1c2luZyB0aGUgY29tcHJlc3Npb24gbWV0aG9kIGZvciBTb3VyY2Ug Um91dGluZyBIZWFkZXIgNkxvUkggKFNSSC02TG9SSCkiLiBJIHVuZGVyc3RhbmQgdGhhdCBhIHNp bWlsYXIgY29tcHJlc3Npb24gbWVjaGFuaXNtIGNvdWxkIGJlIHVzZWQuIEhvd2V2ZXIsIHRoaXMg cmVxdWlyZXMgZGVmaW5pbmcgYSBwcm90b2NvbCBlbGVtZW50IHRoYXQgZG9lcyBub3QgZXhpc3Qg dG9kYXksIHVubGVzcyBJIG1pc3NlZCBzb21ldGhpbmcuIFRoZXJlZm9yZSwgdGhlIG5vcm1hdGl2 ZSBTSE9VTEQgaXMgaXJyZWxldmFudC4gSSBndWVzcyB0aGlzIHNlY3Rpb24gaXMgbWVyZWx5IHN1 Z2dlc3RpbmcgZnV0dXJlIHdvcmsuDQogICogICBBcHBlbmRpeCBBOiBkb2VzIHRoZSBleHBlcmlt ZW50YWwgaW1wbGVtZW50YXRpb24gZG8gY29tcHJlc3Npb24/IElmIHNvLCBmb3IgaW5mb3JtYXRp b24sIHdoYXQncyB0aGUgRElPIHNpemU/DQoNCk5pdHMNCg0KICAqICAgc2VjdGlvbiAyOiBtaXNz aW5nIGNvbG9ucyBhZnRlciB0aGUgdHdvIHRlcm1zIGJlaW5nIGRlZmluZWQuDQogICogICBzZWN0 aW9uIDM6IOKAnGluY2x1ZGVkIGluIG9wZXJhdGlvbuKAnSDigJQ+IOKAnGluY2x1ZGVkIGluIHRo ZSBvcGVyYXRpb27igJ0NCiAgKiAgIHNlY3Rpb24gMzogYWx0ZXJuYXRpdmUgcGFyZW50IOKAlD4g QVANCiAgKiAgIHNlY3Rpb24gMzogYWx0ZXJhbnRpdmUg4oCUPiBhbHRlcm5hdGl2ZQ0KICAqICAg c2VjdGlvbiAzLjE6IOKAnHRoZSBzb3VyY2Ugbm9kZSBTIG11c3Qga25vdyBpdHMgZ3JhbmRwYXJl bnQgc2V0cyBib3RoIHRocm91Z2ggbm9kZXMgQSwgQiwgQywgYW5kIEQu4oCdIOKAlD4g4oCcYm90 aOKAnSBpcyBhbmFkZXF1YXRlIGFuZCBjYW4gYmUgcmVtb3ZlZCBhbHRvZ2V0aGVyLg0KICAqICAg c2VjdGlvbiAzLjI6IOKAnFRoZXJlZm9yZSwgbm9kZSBTIGNhbiBkZWNpZGUgdG8gdXNlIG5vZGUg QiBvciBEIGFzIGl0cyBBUCBub2RlLCBzaW5jZSBnaXZlbiB0aGF0IFBQKFBQKFMpKSA9IFksIGZv ciBub2RlIEIgUFMoQikgPSB7VywgWCwgWX0gYW5kIGZvciBub2RlIEQgUEQoRCkgPSB7WSwgWn0u 4oCdLiBJbnZhbGlkIGdyYW1tYXRpY2FsIGNvbnN0cnVjdC4gQnJlYWtpbmcgdGhpcyBjb21wbGV4 IHNlbnRlbmNlIGludG8gdHdvIHNpbXBsZXIgb25lcyBtaWdodCBoZWxwLg0KICAqICAgc2VjdGlv biAzLjM6IOKAnHRoZSBub2RlIHdpbGwgY2hlY2sgaWYgaXRzIHRoZSBQYXJlbnQgU2V0IChQUykg b2YgaXRzIFByZWZlcnJlZCBQYXJlbnQgKFBQKSwgaGFzIGEgY29tbW9uIG5vZGUgd2l0aCB0aGUg UFMgb2YgdGhlIHBvdGVudGlhbCBBUC7igJ0g4oCUPiDigJx0aGUgbm9kZSB3aWxsIGNoZWNrIGlm IHRoZSBQYXJlbnQgU2V0IChQUykgb2YgaXRzIFByZWZlcnJlZCBQYXJlbnQgKFBQKSBoYXMgYSBu b2RlIGluIGNvbW1vbiB3aXRoIHRoZSBQUyBvZiB0aGUgcG90ZW50aWFsIEFQLuKAnQ0KICAqICAg c2VjdGlvbiA0LCA2TG9SSCB0eXBlOiBpcyDigJxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjODEzOCNzZWN0aW9uLTUuMeKAnSBhbiBlZGl0aW5nIG1pc3Rha2U/DQogICogICBzZWN0aW9u IDQuMTog4oCcc2luY2UgaXQgY2FuIGhlbHAgdGhlIGFsdGVybmF0aXZlIHBhdGggZnJvbSBzaWdu aWZpY2FudGx5IGRldmlhdGluZyBmcm9tIHRoZSBwcmVmZXJyZWQgcGF0aC7igJ0g4oCUPiDigJxz aW5jZSBpdCBjYW4gaGVscCB0aGUgYWx0ZXJuYXRpdmUgcGF0aCB0byBub3Qgc2lnbmlmaWNhbnRs eSBkZXZpYXRlIGZyb20gdGhlIHByZWZlcnJlZCBwYXRoLuKAnQ0KICAqICAgc2VjdGlvbiA0LjEu MTog4oCcR2l2ZW4gdGhlIGludGVuZGVkIHVzYWdlLCB3aGVuIHVzaW5nIHRoZSBQUywgdGhlIE5T QSBvYmplY3QgaXQgaXMgY29udGFpbmVkIGluIE1VU1QgYmUgdXNlZCBhcyBhIGNvbnN0cmFpbnQg aW4gdGhlIERBRyBNZXRyaWMgQ29udGFpbmVyLuKAnS4gQ29tcGxleCBzZW50ZW5jZS4gQ29uc2lk ZXIgcmVwaHJhc2luZywgb3Igc2ltcGx5IHJlbW92ZSBpdCBhbHRvZ2V0aGVyLg0KICAqICAgU2Vj dGlvbiA1OiDigJxob3dldmVyIGl04oCZcyB1c2XigJ0g4oCUPiDigJxob3dldmVyIGl0cyB1c2Xi gJ0NCiAgKiAgIEFwcGVuZGl4IEE6IOKAnGltbWVkaWF0ZWxseeKAnSDigJQ+IOKAnGltbWVkaWF0 ZWx54oCdLiAoc2V2ZXJhbCBvY2N1cmVuY2VzKS4NCiAgKiAgIEFwcGVuZGl4IEE6IOKAnExpbmtz IGFyZSByZXNldCB1bmlmb3JtbHkgcmFuZG9tbHkgYmV0d2VlbiA3MCUgYW5kIDEwMCUgZXZlcnkg NjAgc2Vjb25kc+KAnS4gSSBndWVzcyB5b3UgbWVhbiDigJxFdmVyeSA2MCBzLCBhIG5ldyBQYWNr ZXQgRGVsaXZlcnkgUmF0ZSBpcyByYW5kb21seSBkcmF3biBmb3IgZWFjaCBsaW5rLCB3aXRoIGEg dW5pZm9ybSBkaXN0cmlidXRpb24gc3Bhbm5pbmcgdGhlIDcwJSB0byAxMDAlIGludGVydmFs4oCd Lg0KDQoNCkRlIDogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpyb2xsLWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSW5lcyBSb2JsZXMgPG1hcmlhaW5lc3JvYmxlcz00 MGdvb2dsZW1haWwuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzptYXJpYWluZXNyb2JsZXM9NDBn b29nbGVtYWlsLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpSw6lwb25kcmUgw6AgOiAicm9sbEBpZXRm Lm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4iIDxyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGll dGYub3JnPj4NCkRhdGUgOiBUaHVyc2RheSA2IEp1bmUgMjAxOSAxMjoxMg0Kw4AgOiAicm9sbEBp ZXRmLm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4iIDxyb2xsQGlldGYub3JnPG1haWx0bzpyb2xs QGlldGYub3JnPj4NCk9iamV0IDogW1JvbGxdIENhbGwgZm9yIHJldmlld3MgZm9yIGRyYWZ0LWll dGYtcm9sbC1uc2EtZXh0ZW5zaW9uDQoNCkRlYXIgYWxsLA0KDQpXZSB3b3VsZCBsaWtlIHRvIGhh dmUgcmV2aWV3cyBmb3IgZHJhZnQtaWV0Zi1yb2xsLW5zYS1leHRlbnNpb24tMDEuDQoNClBsZWFz ZSBsZXQgdXMga25vdyBpZiB5b3Ugd2FudCB0byByZXZpZXcgaXQuDQoNClRoYW5rIHlvdSB2ZXJ5 IG11Y2gsDQoNCkluZXMgYW5kIFBldGVyDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_D930160F6253Ddominiquebarthelorangecom_ Content-Type: text/html; charset="utf-8" Content-ID: <7115F0208C0B214FBAA7AFE4103B0D48@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjx0aXRsZT5kcmFmdC1pZXRmLXJvbGwtbnNhLWV4 dGVuc2lvbi0wMSAtIFJQTCBEQUcgTWV0cmljIENvbnRhaW5lciBOb2RlIFN0YXRlIGFuZCBBdHRy aWJ1dGUgb2JqZWN0IHR5cGUgZXh0ZW5zaW9uPC90aXRsZT4NCjwvaGVhZD4NCjxib2R5IHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KSGVsbG8gYWxsLDwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpIZXJlIGlzIG15IHJl dmlldyBvZiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgZm9udC1zaXpl OiAxNXB4OyI+ZHJhZnQtaWV0Zi1yb2xsLW5zYS1leHRlbnNpb24tMDIuPC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KSSBmb3VuZCBpdCB3ZWxsIHdyaXR0ZW4sIHdp dGggdGhlIGFwcHJvcHJpYXRlIGFtb3VudCBvZiBpbnRyb2R1Y3RvcnkgbWF0ZXJpYWwgYW5kIHJl ZmVyZW5jZXMuPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpJIG9ubHkgaGF2 ZSBhIGZldyBjb21tZW50cywgYXMgd2VsbCBhcywgdGhpcyBiZWluZyBtZSwgYSBsaXN0IG9mIGVk aXRvcmlhbCBuaXRzLiBTZWUgYmVsb3cuPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyI+DQpCZXN0IHJlZ2FyZHM8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KRG9taW5pcXVlPC9kaXY+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij4NCj09PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ DQo8YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+Q29tbWVudHM8L2ZvbnQ+PC9kaXY+DQo8dWw+DQo8bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxz YW5zLXNlcmlmIj5zZWN0aW9uIDMuNDogSSBiZWxpZXZlIE9QVElPTkFMIGFuZCBNQVkgc2hvdWxk IGJlIGxvd2VyY2FzZSBoZXJlLCBzaW5jZSB0aGlzIGRyYWZ0IG9ubHkgc3BlY2lmaWVzIHRoZSBE TUMgZXh0ZW5zaW9uLCBub3QgdGhlIE9iamVjdGl2ZSBGdW5jdGlvbi4mbmJzcDs8L2ZvbnQ+PC9s aT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5zZWN0aW9ucyA0LjEuMSBhbmQg NC4xLjI6IHRoZSBETUMgaGVhZGVyIGZpZWxkcyBhcmUgZGVmaW5lZCBpbiBSRkM2NTUxLCBub3Qg NjU1MC48L2ZvbnQ+PC9saT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5zZWN0 aW9uIDQuMS4xOiBpbiBSRkM2NTUxLCB0aGUgUHJlYyBmaWVsZCBpcyBtZWFudCB0byBiZSB1c2Vk IGZvciBtZXRyaWNzLCBub3QgZm9yIGNvbnN0cmFpbnRzLiBUaGVyZWZvcmUsIGl0IGlzIHVudXNl ZCBmb3IgdGhpcyBOU0EgZXh0ZW5zaW9uLCB3aGljaCBpcyBhIGNvbnN0cmFpbnQuIFVuZm9ydHVu YXRlbHksIFJGQzY1NTEgZm9yZ290IHRvIHNwZWNpZnkgYSBkZWZhdWx0IHZhbHVlLg0KIElzIHRo aXMgdGhlIHJlYXNvbiB3aHkgeW91IHNheSDigJx1c2VkIGFjY29yZGluZyB0byBSRkPigKbigJ0/ IEkgc3VnZ2VzdCB5b3UgdXNlIHRoZSBzYW1lIHRleHQgZm9yIHRoZSBQcmVjIGFuZCBBIGZpZWxk cy4gSXQgY291bGQgYmUgcXVvdGluZyB0aGUgdGV4dCBmcm9tIFJGQzY1NTEsIG9mIHJlZmVycmlu ZyB0aGUgcmVhZGVyIHRvIGl0LCBvciBzYXkgbm90aGluZy48L2ZvbnQ+PC9saT48bGk+PGZvbnQg ZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5zZWN0aW9uIDQuMS4yOiDigJxGb3IgY2xhcml0eSBy ZWFzb25zLCB0aGUgdXNhZ2Ugb2YgdGhlIFBTIHBsYWNlcyBubyBhZGRpdGlvbmFsIHJlc3RyaWN0 aW9ucyBvbiB0aGUgTlNBIGZsYWdzICjigJlB4oCZIGFuZCDigJlP4oCZKSwgd2hpY2ggY2FuIGJl IHVzZWQgYXMgbm9ybWFsbHkgZGVmaW5lZCBpbiBbUkZDNjU1MF3igJ0uIFRoZSBjbGFyaXR5IHJl YXNvbnMgZXNjYXBlZCBtZSwgYXMgd2VsbCBhcyB0aGUNCiBhZGRpdGlvbmFsIHJlc3RyaWN0aW9u cyB0aGF0IGNvdWxkIGhhdmUgYmVlbiBwbGFjZWQgYnV0IHdoaWNoIGhhdmUgbm90ISBBbnl3YXks IFJGQzY1NTEgc3RhdGVzIHRoYXQgdGhlIEEgRmllbGQgaXMgbm90IHVzZWQgd2l0aCBjb25zdHJh aW50cy4gT3ZlcmFsbCwgSSB0aGluayB0aGlzIHdob2xlIHN1YnNlY3Rpb24gY291bGQgZ28gYXdh eSBzaW5jZSBpdCBzcGVjaWZpZXMgbm90aGluZywgc2F5cyB0aGF0IGl0IGRvZXMgbm90IHNwZWNp ZnkgYW55dGhpbmcNCiBidXQgZG9lcyBub3Qgc2F5IHdoeSBpdCBzYXlzIGl0LiA7LSk8L2ZvbnQ+ PC9saT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5TZWN0aW9uIDQuMjogJnF1 b3Q7PC9mb250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi PlRoZXJlZm9yZSwgdGhlIFBTJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPklQdjYgYWRkcmVzcyhlcykgZmllbGQgU0hPVUxEIGJlIGNv bXByZXNzZWQgdXNpbmcgdGhlIGNvbXByZXNzaW9uJm5ic3A7PC9zcGFuPjxmb250IGZhY2U9IkNh bGlicmksc2Fucy1zZXJpZiI+bWV0aG9kDQogZm9yIFNvdXJjZSBSb3V0aW5nIEhlYWRlciA2TG9S SCAoU1JILTZMb1JIKSZxdW90Oy4mbmJzcDtJIHVuZGVyc3RhbmQgdGhhdCBhIHNpbWlsYXIgY29t cHJlc3Npb24gbWVjaGFuaXNtIGNvdWxkIGJlIHVzZWQuIEhvd2V2ZXIsIHRoaXMgcmVxdWlyZXMg ZGVmaW5pbmcgYSBwcm90b2NvbCBlbGVtZW50IHRoYXQgZG9lcyBub3QgZXhpc3QgdG9kYXksIHVu bGVzcyZuYnNwO0kgbWlzc2VkIHNvbWV0aGluZy4gVGhlcmVmb3JlLCB0aGUgbm9ybWF0aXZlIFNI T1VMRCBpcyBpcnJlbGV2YW50LiZuYnNwO0kNCiBndWVzcyB0aGlzIHNlY3Rpb24gaXMgbWVyZWx5 IHN1Z2dlc3RpbmcgZnV0dXJlIHdvcmsuJm5ic3A7PC9mb250PjwvbGk+PGxpPjxmb250IGZhY2U9 IkNhbGlicmksc2Fucy1zZXJpZiI+QXBwZW5kaXggQTogZG9lcyB0aGUgZXhwZXJpbWVudGFsIGlt cGxlbWVudGF0aW9uIGRvIGNvbXByZXNzaW9uPyBJZiBzbywgZm9yIGluZm9ybWF0aW9uLCB3aGF0 J3MgdGhlIERJTyBzaXplPzwvZm9udD48L2xpPjwvdWw+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpLHNhbnMtc2VyaWYiPk5pdHM8L2ZvbnQ+PC9kaXY+DQo8dWw+DQo8bGk+PGZvbnQgZmFjZT0i Q2FsaWJyaSxzYW5zLXNlcmlmIj5zZWN0aW9uIDI6IG1pc3NpbmcgY29sb25zIGFmdGVyIHRoZSB0 d28gdGVybXMgYmVpbmcgZGVmaW5lZC48L2ZvbnQ+PC9saT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJy aSxzYW5zLXNlcmlmIj5zZWN0aW9uIDM6IOKAnGluY2x1ZGVkIGluIG9wZXJhdGlvbuKAnSZuYnNw O+KAlCZndDsg4oCcaW5jbHVkZWQgaW4gdGhlIG9wZXJhdGlvbuKAnTwvZm9udD48L2xpPjxsaT48 Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPnNlY3Rpb24gMzogYWx0ZXJuYXRpdmUgcGFy ZW50IOKAlCZndDsgQVA8L2ZvbnQ+PC9saT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNl cmlmIj5zZWN0aW9uIDM6IGFsdGVyYW50aXZlIOKAlCZndDsgYWx0ZXJuYXRpdmU8L2ZvbnQ+PC9s aT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5zZWN0aW9uIDMuMTog4oCcdGhl IHNvdXJjZSBub2RlIFMgbXVzdCBrbm93IGl0cyBncmFuZHBhcmVudCBzZXRzIGJvdGggdGhyb3Vn aCBub2RlcyBBLCBCLCBDLCBhbmQgRC7igJ0g4oCUJmd0OyDigJxib3Ro4oCdIGlzIGFuYWRlcXVh dGUgYW5kIGNhbiBiZSByZW1vdmVkIGFsdG9nZXRoZXIuPC9mb250PjwvbGk+PGxpPjxmb250IGZh Y2U9IkNhbGlicmksc2Fucy1zZXJpZiI+c2VjdGlvbiAzLjI6IOKAnFRoZXJlZm9yZSwgbm9kZSBT IGNhbiBkZWNpZGUgdG8gdXNlIG5vZGUgQiBvciBEIGFzIGl0cyBBUCBub2RlLCBzaW5jZSBnaXZl biB0aGF0IFBQKFBQKFMpKSA9IFksIGZvciBub2RlIEIgUFMoQikgPSB7VywgWCwgWX0gYW5kIGZv ciBub2RlIEQgUEQoRCkgPSB7WSwgWn0u4oCdLiBJbnZhbGlkIGdyYW1tYXRpY2FsIGNvbnN0cnVj dC4gQnJlYWtpbmcgdGhpcyBjb21wbGV4DQogc2VudGVuY2UgaW50byB0d28gc2ltcGxlciBvbmVz IG1pZ2h0IGhlbHAuPC9mb250PjwvbGk+PGxpPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+c2VjdGlvbiAzLjM6IOKAnHRoZSBub2RlIHdpbGwgY2hlY2sgaWYgaXRzIHRoZSBQYXJlbnQg U2V0IChQUykgb2YgaXRzIFByZWZlcnJlZCBQYXJlbnQgKFBQKSwgaGFzIGEgY29tbW9uIG5vZGUg d2l0aCB0aGUgUFMgb2YgdGhlIHBvdGVudGlhbCBBUC7igJ0g4oCUJmd0OyDigJx0aGUgbm9kZSB3 aWxsIGNoZWNrIGlmIHRoZSBQYXJlbnQgU2V0IChQUykgb2YgaXRzIFByZWZlcnJlZCBQYXJlbnQg KFBQKSBoYXMNCiBhIG5vZGUgaW4gY29tbW9uIHdpdGggdGhlIFBTIG9mIHRoZSBwb3RlbnRpYWwg QVAu4oCdPC9mb250PjwvbGk+PGxpPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+c2Vj dGlvbiA0LCA2TG9SSCB0eXBlOiBpcyDigJxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj ODEzOCNzZWN0aW9uLTUuMeKAnSBhbiBlZGl0aW5nIG1pc3Rha2U/PC9mb250PjwvbGk+PGxpPjxm b250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+c2VjdGlvbiA0LjE6IOKAnHNpbmNlIGl0IGNh biBoZWxwIHRoZSBhbHRlcm5hdGl2ZSBwYXRoIGZyb20gc2lnbmlmaWNhbnRseSBkZXZpYXRpbmcg ZnJvbSB0aGUgcHJlZmVycmVkIHBhdGgu4oCdIOKAlCZndDsg4oCcc2luY2UgaXQgY2FuIGhlbHAg dGhlIGFsdGVybmF0aXZlIHBhdGggdG8gbm90IHNpZ25pZmljYW50bHkgZGV2aWF0ZSBmcm9tIHRo ZSBwcmVmZXJyZWQgcGF0aC7igJ08L2ZvbnQ+PC9saT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxz YW5zLXNlcmlmIj5zZWN0aW9uIDQuMS4xOiDigJxHaXZlbiB0aGUgaW50ZW5kZWQgdXNhZ2UsIHdo ZW4gdXNpbmcgdGhlIFBTLCB0aGUgTlNBIG9iamVjdCBpdCBpcyBjb250YWluZWQgaW4gTVVTVCBi ZSB1c2VkIGFzIGEgY29uc3RyYWludCBpbiB0aGUgREFHIE1ldHJpYyBDb250YWluZXIu4oCdLiBD b21wbGV4IHNlbnRlbmNlLiBDb25zaWRlciByZXBocmFzaW5nLCBvciBzaW1wbHkgcmVtb3ZlIGl0 IGFsdG9nZXRoZXIuPC9mb250PjwvbGk+PGxpPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+U2VjdGlvbiA1OiDigJxob3dldmVyIGl04oCZcyB1c2XigJ0g4oCUJmd0OyDigJxob3dldmVy IGl0cyB1c2XigJ08L2ZvbnQ+PC9saT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij5BcHBlbmRpeCBBOiDigJxpbW1lZGlhdGVsbHnigJ0g4oCUJmd0OyDigJxpbW1lZGlhdGVseeKA nS4gKHNldmVyYWwgb2NjdXJlbmNlcykuPC9mb250PjwvbGk+PGxpPjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+QXBwZW5kaXggQTog4oCcTGlua3MgYXJlIHJlc2V0IHVuaWZvcm1seSBy YW5kb21seSBiZXR3ZWVuIDcwJSBhbmQgMTAwJSBldmVyeSA2MCBzZWNvbmRz4oCdLiBJIGd1ZXNz IHlvdSBtZWFuIOKAnEV2ZXJ5IDYwIHMsIGEgbmV3IFBhY2tldCBEZWxpdmVyeSBSYXRlIGlzIHJh bmRvbWx5IGRyYXduIGZvciBlYWNoIGxpbmssIHdpdGggYSB1bmlmb3JtIGRpc3RyaWJ1dGlvbiBz cGFubmluZyB0aGUgNzAlDQogdG8gMTAwJSBpbnRlcnZhbOKAnS48L2ZvbnQ+PC9saT48L3VsPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogMTVweDsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6 YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5v bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hU OiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1 bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EZSZuYnNwOzogPC9zcGFuPlJvbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsLWJvdW5jZXNA aWV0Zi5vcmciPnJvbGwtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBJbmVz IFJvYmxlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmlhaW5lc3JvYmxlcz00MGdvb2dsZW1haWwu Y29tQGRtYXJjLmlldGYub3JnIj5tYXJpYWluZXNyb2JsZXM9NDBnb29nbGVtYWlsLmNvbUBkbWFy Yy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlLD qXBvbmRyZSDDoCZuYnNwOzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYu b3JnIj5yb2xsQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0 Zi5vcmciPnJvbGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5EYXRlJm5ic3A7OiA8L3NwYW4+VGh1cnNkYXkgNiBKdW5lIDIwMTkgMTI6MTI8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+w4AmbmJzcDs6IDwvc3Bhbj4mcXVvdDs8 YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T2JqZXQmbmJzcDs6IDwvc3Bhbj5bUm9s bF0gQ2FsbCBmb3IgcmV2aWV3cyBmb3IgZHJhZnQtaWV0Zi1yb2xsLW5zYS1leHRlbnNpb248YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIi PkRlYXIgYWxsLA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2Ugd291bGQgbGlrZSB0byBoYXZl IHJldmlld3MgZm9yJm5ic3A7ZHJhZnQtaWV0Zi1yb2xsLW5zYS1leHRlbnNpb24tMDEuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IHdhbnQg dG8gcmV2aWV3IGl0LiZuYnNwOzxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ VGhhbmsgeW91IHZlcnkgbXVjaCw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluZXMg YW5kIFBldGVyPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8UFJFPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_D930160F6253Ddominiquebarthelorangecom_-- From nobody Thu Jun 20 02:37:22 2019 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 06E061200F7 for ; Thu, 20 Jun 2019 02:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 TNQpf-noaHxW for ; Thu, 20 Jun 2019 02:37:17 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [IPv6:2001:660:330f:2::c1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5652F1202A7 for ; Thu, 20 Jun 2019 02:37:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id E81CE801E8; Thu, 20 Jun 2019 11:37:15 +0200 (CEST) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id 3Zmhi8XmUtgx; Thu, 20 Jun 2019 11:37:15 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 0CAAA80D0F; Thu, 20 Jun 2019 11:37:15 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr 0CAAA80D0F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1561023435; bh=UIK+VAtcTz5GNRhmWOK5QNSWZ0vO+OhqwypZBTdUcTY=; h=Mime-Version:From:Date:Message-Id:To; b=gnMAah0LWkUbrCbDE3+80Q0eGqRH884hlQmVr3idCql6ueeTrkn8XRPovZyeKH+Ek jvRZ3eJ113CjR2QaVlUuCm+3vtO5wZS4qt+YVa0uwZGEIvilv/aViXvZ2YYXl5xn4V RmnP4pXEq1msMhLwsyFpsLLS72x+XBoUgWQTJ8Bk= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id nMlZ5O3HmChE; Thu, 20 Jun 2019 11:37:14 +0200 (CEST) Received: from [192.168.1.44] (91-165-195-92.subs.proxad.net [91.165.195.92]) by zproxy120.enst.fr (Postfix) with ESMTPSA id BE976801E8; Thu, 20 Jun 2019 11:37:14 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BD905274-5380-4F94-9A41-7712AF50B765" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Georgios Z. Papadopoulos" In-Reply-To: <8671_1560957093_5D0A50A5_8671_291_1_D930160F.6253D%dominique.barthel@orange.com> Date: Thu, 20 Jun 2019 11:39:32 +0200 Cc: Routing Over Low power and Lossy networks , "mariainesrobles@googlemail.com" Message-Id: <78B8ABCB-14CE-4999-9D32-E90E72099143@imt-atlantique.fr> References: <8671_1560957093_5D0A50A5_8671_291_1_D930160F.6253D%dominique.barthel@orange.com> To: dominique.barthel@orange.com X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Roll] Call for reviews for draft-ietf-roll-nsa-extension 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 Jun 2019 09:37:20 -0000 --Apple-Mail=_BD905274-5380-4F94-9A41-7712AF50B765 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you so much Dominique for your review. We will come back with an updated version, as well as with point to = point responses to your comments. Best, Georgios and Aris > On Jun 19, 2019, at 17:11, dominique.barthel@orange.com wrote: >=20 > Hello all, >=20 > Here is my review of draft-ietf-roll-nsa-extension-02. > I found it well written, with the appropriate amount of introductory = material and references. > I only have a few comments, as well as, this being me, a list of = editorial nits. See below. > Best regards >=20 > Dominique >=20 > =3D=3D >=20 > Comments > section 3.4: I believe OPTIONAL and MAY should be lowercase here, = since this draft only specifies the DMC extension, not the Objective = Function.=20 > sections 4.1.1 and 4.1.2: the DMC header fields are defined in = RFC6551, not 6550. > section 4.1.1: in RFC6551, the Prec field is meant to be used for = metrics, not for constraints. Therefore, it is unused for this NSA = extension, which is a constraint. Unfortunately, RFC6551 forgot to = specify a default value. Is this the reason why you say =E2=80=9Cused = according to RFC=E2=80=A6=E2=80=9D? I suggest you use the same text for = the Prec and A fields. It could be quoting the text from RFC6551, of = referring the reader to it, or say nothing. > section 4.1.2: =E2=80=9CFor clarity reasons, the usage of the PS = places no additional restrictions on the NSA flags (=E2=80=99A=E2=80=99 = and =E2=80=99O=E2=80=99), which can be used as normally defined in = [RFC6550]=E2=80=9D. The clarity reasons escaped me, as well as the = additional restrictions that could have been placed but which have not! = Anyway, RFC6551 states that the A Field is not used with constraints. = Overall, I think this whole subsection could go away since it specifies = nothing, says that it does not specify anything but does not say why it = says it. ;-) > Section 4.2: "Therefore, the PS IPv6 address(es) field SHOULD be = compressed using the compression method for Source Routing Header 6LoRH = (SRH-6LoRH)". I understand that a similar compression mechanism could be = used. However, this requires defining a protocol element that does not = exist today, unless I missed something. Therefore, the normative SHOULD = is irrelevant. I guess this section is merely suggesting future work.=20 > Appendix A: does the experimental implementation do compression? If = so, for information, what's the DIO size? >=20 > Nits > section 2: missing colons after the two terms being defined. > section 3: =E2=80=9Cincluded in operation=E2=80=9D =E2=80=94> = =E2=80=9Cincluded in the operation=E2=80=9D > section 3: alternative parent =E2=80=94> AP > section 3: alterantive =E2=80=94> alternative > section 3.1: =E2=80=9Cthe source node S must know its grandparent sets = both through nodes A, B, C, and D.=E2=80=9D =E2=80=94> =E2=80=9Cboth=E2=80= =9D is anadequate and can be removed altogether. > section 3.2: =E2=80=9CTherefore, node S can decide to use node B or D = as its AP node, since given that PP(PP(S)) =3D Y, for node B PS(B) =3D = {W, X, Y} and for node D PD(D) =3D {Y, Z}.=E2=80=9D. Invalid grammatical = construct. Breaking this complex sentence into two simpler ones might = help. > section 3.3: =E2=80=9Cthe node will check if its the Parent Set (PS) = of its Preferred Parent (PP), has a common node with the PS of the = potential AP.=E2=80=9D =E2=80=94> =E2=80=9Cthe node will check if the = Parent Set (PS) of its Preferred Parent (PP) has a node in common with = the PS of the potential AP.=E2=80=9D > section 4, 6LoRH type: is = =E2=80=9Chttps://tools.ietf.org/html/rfc8138#section-5.1=E2=80=9D an = editing mistake? > section 4.1: =E2=80=9Csince it can help the alternative path from = significantly deviating from the preferred path.=E2=80=9D =E2=80=94> = =E2=80=9Csince it can help the alternative path to not significantly = deviate from the preferred path.=E2=80=9D > section 4.1.1: =E2=80=9CGiven the intended usage, when using the PS, = the NSA object it is contained in MUST be used as a constraint in the = DAG Metric Container.=E2=80=9D. Complex sentence. Consider rephrasing, = or simply remove it altogether. > Section 5: =E2=80=9Chowever it=E2=80=99s use=E2=80=9D =E2=80=94> = =E2=80=9Chowever its use=E2=80=9D > Appendix A: =E2=80=9Cimmediatelly=E2=80=9D =E2=80=94> = =E2=80=9Cimmediately=E2=80=9D. (several occurences). > Appendix A: =E2=80=9CLinks are reset uniformly randomly between 70% = and 100% every 60 seconds=E2=80=9D. I guess you mean =E2=80=9CEvery 60 = s, a new Packet Delivery Rate is randomly drawn for each link, with a = uniform distribution spanning the 70% to 100% interval=E2=80=9D. >=20 >=20 > De : Roll > on = behalf of Ines Robles > > R=C3=A9pondre =C3=A0 : "roll@ietf.org " = > > Date : Thursday 6 June 2019 12:12 > =C3=80 : "roll@ietf.org " > > Objet : [Roll] Call for reviews for draft-ietf-roll-nsa-extension >=20 > Dear all, >=20 > We would like to have reviews for draft-ietf-roll-nsa-extension-01. >=20 > Please let us know if you want to review it.=20 >=20 > Thank you very much, >=20 > Ines and Peter > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. --Apple-Mail=_BD905274-5380-4F94-9A41-7712AF50B765 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank you so much Dominique for your review.
We = will come back with an updated version, as well as with point to point = responses to your comments.

Best,
Georgios and Aris


On Jun 19, 2019, at 17:11, dominique.barthel@orange.com wrote:

draft-ietf-roll-nsa-extension-01 - RPL DAG Metric = Container Node State and Attribute object type extension
Hello all,

Here is my review of draft-ietf-roll-nsa-extension-02.
I found it well written, with the appropriate amount of introductory = material and references.
I only have a few comments, as well as, this being me, a list of = editorial nits. See below.
Best regards

Dominique

=3D=3D

Comments
  • section 3.4: = I believe OPTIONAL and MAY should be lowercase here, since this draft = only specifies the DMC extension, not the Objective = Function. 
  • sections 4.1.1 and 4.1.2: the DMC = header fields are defined in RFC6551, not 6550.
  • section 4.1.1: = in RFC6551, the Prec field is meant to be used for metrics, not for = constraints. Therefore, it is unused for this NSA extension, which is a = constraint. Unfortunately, RFC6551 forgot to specify a default value. Is this the reason why you say =E2=80=9Cused according to RFC=E2=80=A6=E2= =80=9D? I suggest you use the same text for the Prec and A fields. It = could be quoting the text from RFC6551, of referring the reader to it, = or say nothing.
  • section 4.1.2: =E2=80=9CFor = clarity reasons, the usage of the PS places no additional restrictions = on the NSA flags (=E2=80=99A=E2=80=99 and =E2=80=99O=E2=80=99), which = can be used as normally defined in [RFC6550]=E2=80=9D. The clarity = reasons escaped me, as well as the additional restrictions that could have been placed but which have not! = Anyway, RFC6551 states that the A Field is not used with constraints. = Overall, I think this whole subsection could go away since it specifies = nothing, says that it does not specify anything but does not say why it says it. ;-)
  • Section 4.2: "Therefore, the = PS IPv6 address(es) field SHOULD be compressed using the = compression method for Source Routing Header 6LoRH (SRH-6LoRH)". I understand that a = similar compression mechanism could be used. However, this requires = defining a protocol element that does not exist today, unless I = missed something. Therefore, the normative SHOULD is irrelevant. I guess this section is merely suggesting future = work. 
  • Appendix A: does the experimental implementation do = compression? If so, for information, what's the DIO = size?

Nits
  • section 2: = missing colons after the two terms being defined.
  • section 3: = =E2=80=9Cincluded in operation=E2=80=9D =E2=80=94> =E2=80=9Cinclud= ed in the operation=E2=80=9D
  • section 3: alternative parent = =E2=80=94> AP
  • section 3: alterantive =E2=80=94>= ; alternative
  • section 3.1: =E2=80=9Cthe source node S must know its = grandparent sets both through nodes A, B, C, and D.=E2=80=9D =E2=80=94>= =E2=80=9Cboth=E2=80=9D is anadequate and can be removed = altogether.
  • section 3.2: =E2=80=9CTherefore, node S can decide to use = node B or D as its AP node, since given that PP(PP(S)) =3D Y, for node B = PS(B) =3D {W, X, Y} and for node D PD(D) =3D {Y, Z}.=E2=80=9D. Invalid = grammatical construct. Breaking this complex sentence into two simpler ones might help.
  • section 3.3: = =E2=80=9Cthe node will check if its the Parent Set (PS) of its Preferred = Parent (PP), has a common node with the PS of the potential AP.=E2=80=9D = =E2=80=94> =E2=80=9Cthe node will check if the Parent Set (PS) of its = Preferred Parent (PP) has a node in common with the PS of the potential AP.=E2=80=9D
    • section 4, = 6LoRH type: is =E2=80=9Chttps://tools.ietf.org/html/rfc8138#section-5.1=E2=80=9D = an editing mistake?
  • section 4.1: =E2=80=9Csince it = can help the alternative path from significantly deviating from the = preferred path.=E2=80=9D =E2=80=94> =E2=80=9Csince it can help the = alternative path to not significantly deviate from the preferred = path.=E2=80=9D
  • section 4.1.1: =E2=80=9CGiven the intended usage, when using = the PS, the NSA object it is contained in MUST be used as a constraint = in the DAG Metric Container.=E2=80=9D. Complex sentence. Consider = rephrasing, or simply remove it altogether.
  • Section 5: = =E2=80=9Chowever it=E2=80=99s use=E2=80=9D =E2=80=94> =E2=80=9Chowever = its use=E2=80=9D
  • Appendix A: =E2=80=9Cimmediatelly=E2= =80=9D =E2=80=94> =E2=80=9Cimmediately=E2=80=9D. (several = occurences).
  • Appendix A: =E2=80=9CLinks are reset uniformly randomly = between 70% and 100% every 60 seconds=E2=80=9D. I guess you mean = =E2=80=9CEvery 60 s, a new Packet Delivery Rate is randomly drawn for = each link, with a uniform distribution spanning the 70% to 100% interval=E2=80=9D.


De : Roll <roll-bounces@ietf.org> on behalf of Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org>
R=C3=A9pondre =C3=A0 : = "roll@ietf.org" = <roll@ietf.org>
Date : Thursday = 6 June 2019 12:12
=C3=80 : "roll@ietf.org" <roll@ietf.org>
Objet : [Roll] = Call for reviews for draft-ietf-roll-nsa-extension

Dear all,

We would like to have reviews = for draft-ietf-roll-nsa-extension-01.

Please let us know if you want to review it. 

Thank you very much,

Ines and Peter
 
_______________________________________________________________=
__________________________________________________________

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.

= --Apple-Mail=_BD905274-5380-4F94-9A41-7712AF50B765-- From nobody Fri Jun 21 12:55:44 2019 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 0542312009E for ; Fri, 21 Jun 2019 12:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoS-nFYeIqY8 for ; Fri, 21 Jun 2019 12:55:38 -0700 (PDT) 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 B5F721200F9 for ; Fri, 21 Jun 2019 12:55:36 -0700 (PDT) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id E1DA6973 for ; Fri, 21 Jun 2019 21:55:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1561146933; bh=hwZxFp55QSlhG37jMagFf2PbtRZmxYGlxK7S+rPGdc4=; h=References:In-Reply-To:From:Date:Subject:To:From; b=pMejOR7g+eslWsF39OTcAE+pzHKASNqL3+3O/KkH5Rssssx4P3KH63TBtrgYpqudy vrEdn4xCNJspS6Rgt4k7d+++1fgLqPqMTQQCAgXgodRI5oMGEjeJvJ/xwgc/t4+6Oa RbOsl5YrV1CD4wU2p5jqWXks+RX6bw1wmPQj4si+fh8NvMsx7vePWEvY35gvaS9F2H iSa4/CINqQSQRUpji0rsUJeg+Ja3FHwbR7u/1lnKBgo/SrnGCvaiSjKQqhCHaVMYOS x6+q0x3F2cZqW3w1fs6ZR0YepVvdYB4oRwrnADiOelpTmVK8cGSVXiWYhFoAfx+8Vw b3FLm/SrbS4hg== Received: by smtp.mailfence.com with ESMTPA for ; Fri, 21 Jun 2019 21:55:30 +0200 (CEST) Received: by mail-io1-f47.google.com with SMTP id k20so31399ios.10 for ; Fri, 21 Jun 2019 12:55:29 -0700 (PDT) X-Gm-Message-State: APjAAAURWWeaXMN0wQWh/G9ZHr92qm4MEnCXuH5ITtT/wrZJNgat8YOx UpSet+ZoaSw9OyzYBofiukt61LwUotSs6XK8Nuw= X-Google-Smtp-Source: APXvYqzk5KV92NgSvxEoHyGxkFAAQtWuZDaeSvfJ/7HWWcrs+N2GcpukorbQBXusxfAKlYCSGcZe/bPADKWY8rVZ6q4= X-Received: by 2002:a02:8a:: with SMTP id 132mr9680806jaa.89.1561146928626; Fri, 21 Jun 2019 12:55:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Remous-Aris Koutsiamanis Date: Fri, 21 Jun 2019 21:55:31 +0200 (CEST) X-Gmail-Original-Message-ID: Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="0000000000001f8268058bdad8b9" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] Call for reviews for draft-ietf-roll-nsa-extension 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, 21 Jun 2019 19:55:42 -0000 --0000000000001f8268058bdad8b9 Content-Type: text/plain; charset="UTF-8" Hello Abdussalam, Thank you very much for reading this draft and providing us with your comments. It is very much appreciated! On Mon, Jun 17, 2019 at 1:10 AM Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ines and Peter, > > IMHO the draft is not clear in its use-case, I think it must include > rfc8578 to clarify its usecase, and using references of architectures does > not help us understand but makes it more difficult. > I would like to ask some clarifying questions if you don't mind. *"the draft is not clear in its use-case, I think it must include rfc8578 to clarify its usecase"* We are aware of the DetNet usecases and following your comment we will point to the RFC8578 and specifically "Section 5. Wireless for Industrial Applications", which is what we are aiming at with this draft. We have attempted to strike a balance between the introductory material present in the draft (to help it stand alone) and referencing other sources to avoid reiterating things. If you think that just referencing RFC8578 "Section 5. Wireless for Industrial Applications" is insufficient, maybe you could provide a bit more detail on what should and should not be present in the draft. *"using references of architectures does not help us understand but makes it more difficult"* Could you please be more explicit? We reference two architectures in this draft. In "Section 1. Introduction", we refer to the 6TiSCH architecture, as the base upon which this draft builds. In "Section 1. Introduction" we reference the DetNet architecture as context for aim of maximizing packet delivery rate and minimizing latency and jitter. In "Section 5. Controlling PRE" we reference the DetNet architecture specifically as an example to allow the fine-grained control of PRE usage via flow labels. Which of these or other references to architectures did you have in mind? Kind regards Aris > AB > > > > On Thu, Jun 6, 2019 at 12:13 PM Ines Robles 40googlemail.com@dmarc.ietf.org> wrote: > >> Dear all, >> >> We would like to have reviews for draft-ietf-roll-nsa-extension-01. >> >> Please let us know if you want to review it. >> >> Thank you very much, >> >> Ines and Peter >> _______________________________________________ >> 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 > --0000000000001f8268058bdad8b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Abdussal= am,

Thank you very mu= ch for reading this draft and providing us with your comments. It is very m= uch appreciated!

On Mon, Jun 17, 2019 at 1= :10 AM Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Ines a= nd Peter,

IMHO the draft is not clear in its use-c= ase, I think it must include rfc8578 to clarify its usecase, and using refe= rences of architectures does not help us understand but makes it more diffi= cult.

I would like to ask some= clarifying questions if you don't mind.
"the draft i= s not clear in its use-case, I think it must include rfc8578 to clarify its= usecase"
We are aware of the DetNet usecases and follow= ing your comment we will point to the RFC8578 and specifically "Sectio= n 5. Wireless for Industrial Applications", which is what we are aimin= g at with this draft.
We have attempted to strike a balance b= etween the introductory material present in the draft (to help it stand alo= ne) and referencing other sources to avoid reiterating things.
If you think that just referencing RFC8578 "Section 5. Wireless for= Industrial Applications" is insufficient, maybe you could provide a b= it more detail on what should and should not be present in the draft.

"using references of architectures does not= help us understand but makes it more difficult"
Could y= ou please be more explicit?
We reference two architectures in thi= s draft.
In "Section 1. Introduction", we refer to the = 6TiSCH architecture, as the base upon which this draft builds.
In = "Section 1. Introduction" we reference the DetNet architecture as= context for aim of maximizing packet delivery rate and minimizing latency = and jitter.
In "Section 5. Controlling= PRE" we reference the DetNet architecture specifically as an example = to allow the fine-grained control of PRE usage via flow labels.

Which of these or= other references to architectures did you have in mind?

Kind regards
<= div>Aris



AB



On Thu, Jun 6, 2019 at 12:13 PM Ines Robles <mariaine= srobles=3D40googlemail.com@dmarc.ietf.org> wrote:
Dear all,

We would like to have reviews for=C2=A0draft-ietf-roll-nsa-extension-= 01.

Please let us know if you want to review it.= =C2=A0

Thank you very much,

Ines and Peter
_______________________________________________
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
--0000000000001f8268058bdad8b9-- From nobody Fri Jun 21 13:04:24 2019 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 80F42120144 for ; Fri, 21 Jun 2019 13:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icjb5jYhMozB for ; Fri, 21 Jun 2019 13:04:19 -0700 (PDT) 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 322F31200F9 for ; Fri, 21 Jun 2019 13:04:19 -0700 (PDT) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id DEF3E973 for ; Fri, 21 Jun 2019 22:04:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1561147457; bh=teqXJCE1ru7OqeGrr+ACXepcEegCf0FV2A8N29sHiwY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KmT22XFpHB1YyEeRBmAbtqIkptO/MU5Hf/t99eph50umsPdSNbXIqGYq6Doj1w892 YKSHqbqfWmaKE+I8XvLSY38isYKHrbbG6WwYPRJj2GYMR6MGCy93fn0/pbN0n5YhTl e3dKFgbBCB1N5bF6b/7QyF9xIdfhAsREiRrurKMs0BwUJkjJacJQa2Pcx17SxUFhMR 0Fy/LBryf888o9v3/gQbiJeBpq2CEGBqp0pa7iJj+krIrC1HjGkOEOThh27dGjr5z8 HR+iutGNZG9LLyFhmFFzziryXNB4tUY0+hL94l1oVly4pRMuFTn2/xjoElV8Qc7eEN ESvhhDmnQV3PA== Received: by smtp.mailfence.com with ESMTPA for ; Fri, 21 Jun 2019 22:04:13 +0200 (CEST) Received: by mail-io1-f41.google.com with SMTP id i10so582198iol.13 for ; Fri, 21 Jun 2019 13:04:13 -0700 (PDT) X-Gm-Message-State: APjAAAXgIEe3TnOGU0uz5ZvKo6C2gOIHZhNvsCPmJ8cph0xCLzJrrei3 0pYxynS15/yqpgGbjlQjRU9z5PtWuMAMvq0K1yk= X-Google-Smtp-Source: APXvYqwULyfdCxti6fLKRItPN4/wfMvHtAOJuOXHb24JLx8t6XTx9FpRGdILJv4uzCf++JM5w/acJtJiJ+DGGfUEnrg= X-Received: by 2002:a6b:901:: with SMTP id t1mr2624995ioi.42.1561147450566; Fri, 21 Jun 2019 13:04:10 -0700 (PDT) MIME-Version: 1.0 References: <8671_1560957093_5D0A50A5_8671_291_1_D930160F.6253D%dominique.barthel@orange.com> In-Reply-To: <8671_1560957093_5D0A50A5_8671_291_1_D930160F.6253D%dominique.barthel@orange.com> From: Remous-Aris Koutsiamanis Date: Fri, 21 Jun 2019 22:04:15 +0200 (CEST) X-Gmail-Original-Message-ID: Message-ID: To: Routing Over Low power and Lossy networks Cc: "mariainesrobles@googlemail.com" , "Georgios Z. Papadopoulos" Content-Type: multipart/alternative; boundary="0000000000003bb4d7058bdaf774" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] Call for reviews for draft-ietf-roll-nsa-extension 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, 21 Jun 2019 20:04:23 -0000 --0000000000003bb4d7058bdaf774 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Dominique, Thank you so very much for the detailed review and comments. They raise good points and we will address them all carefully in the next version. Responses to individual points follow inline. On Wed, Jun 19, 2019 at 5:11 PM wrote: > Hello all, > > Here is my review of draft-ietf-roll-nsa-extension-02. > I found it well written, with the appropriate amount of introductory > material and references. > I only have a few comments, as well as, this being me, a list of editoria= l > nits. See below. > Best regards > > Dominique > > =3D=3D > > Comments > > - section 3.4: I believe OPTIONAL and MAY should be lowercase here, > since this draft only specifies the DMC extension, not the Objective > Function. > > I agree. I think I got a bit too trigger-happy with the capitalised key words. Thank you. > > - sections 4.1.1 and 4.1.2: the DMC header fields are defined in > RFC6551, not 6550. > > Of course, you are right. Incorrect reference. Thanks. Fixed. > > - section 4.1.1: in RFC6551, the Prec field is meant to be used for > metrics, not for constraints. Therefore, it is unused for this NSA > extension, which is a constraint. Unfortunately, RFC6551 forgot to spe= cify > a default value. Is this the reason why you say =E2=80=9Cused accordin= g to RFC=E2=80=A6=E2=80=9D? I > suggest you use the same text for the Prec and A fields. It could be > quoting the text from RFC6551, of referring the reader to it, or say > nothing. > > You are right. We had received a (reasonable) request to spell out how th= e DMC fields should work in the case of this extension and we did so. And, no, I hadn't noticed that the Prec field does not have a default value in the case of constraints in RFC6551. Sorry :) I just assumed that it would be ignored in cases of constraints, so any value would be valid. Actually, in our implementation we sort the MCs based on Prec only for metrics, so the value of Prec does not matter at all in constraints. I dislike copy-pasting text, so I think that your suggestion makes the most sense. > - section 4.1.2: =E2=80=9CFor clarity reasons, the usage of the PS pla= ces no > additional restrictions on the NSA flags (=E2=80=99A=E2=80=99 and =E2= =80=99O=E2=80=99), which can be used > as normally defined in [RFC6550]=E2=80=9D. The clarity reasons escaped= me, as well > as the additional restrictions that could have been placed but which h= ave > not! Anyway, RFC6551 states that the A Field is not used with constrai= nts. > Overall, I think this whole subsection could go away since it specifie= s > nothing, says that it does not specify anything but does not say why i= t > says it. ;-) > > Yes, you are right and I see the point of it being superfluous. Again, though, it was requested that we be explicit about the operation of existing flags. Basically, for both 4.1.1 (DMC flags) and 4.1.2 (NSA flags) we don't actually redefine or limit the existing RFC6551 spec. So, yes, we basically should say nothing other than "This is used only as a constraint". Ideally, I prefer to avoid restating things from other documents, but I don't know what the right balance would be in this case. What would you think about replacing sections 4.1.1 (DMC flags) and 4.1.2 (NSA flags) with a simple statement like: *"The PS is used only within NSA objects configured as constraints"* > > - Section 4.2: "Therefore, the PS IPv6 address(es) field SHOULD be > compressed using the compression method for Source Routing Header > 6LoRH (SRH-6LoRH)". I understand that a similar compression mechanism = could > be used. However, this requires defining a protocol element that does = not > exist today, unless I missed something. Therefore, the normative SHOUL= D is > irrelevant. I guess this section is merely suggesting future work. > > We do have this almost fully implemented (almost: only works in single root RPL instances). Would it make sense to spell out the exact specification of the compression even if it is largely a copy of the SRH-6LoRH compression method? I can lowercase the SHOULD, but using this kind of compression really makes big difference in practice. With this in mind, what do you thing we should do? (pun intended) > > - Appendix A: does the experimental implementation do compression? If > so, for information, what's the DIO size? > > Yes, it does do compression. The size depends on the other DIO options present. We have tested using Contiki with 802.15.4-TSCH, so the max packet size is 127 bytes without fragmentation. Without compression we can fit max 2 parents in the PS and we have to remove the Prefix Information Option (if i remember correctly). I can look up the actual byte count if that's helpful. > > Nits > > - section 2: missing colons after the two terms being defined. > > Fixed, thanks. > > - section 3: =E2=80=9Cincluded in operation=E2=80=9D =E2=80=94> =E2=80= =9Cincluded in the operation=E2=80=9D > > Fixed, thanks. > > - section 3: alternative parent =E2=80=94> AP > > Fixed, thanks. > > - section 3: alterantive =E2=80=94> alternative > > Fixed, thanks. > > - section 3.1: =E2=80=9Cthe source node S must know its grandparent se= ts both > through nodes A, B, C, and D.=E2=80=9D =E2=80=94> =E2=80=9Cboth=E2=80= =9D is anadequate and can be removed > altogether. > > Of course, fixed. Thanks. > > - section 3.2: =E2=80=9CTherefore, node S can decide to use node B or = D as its > AP node, since given that PP(PP(S)) =3D Y, for node B PS(B) =3D {W, X,= Y} and > for node D PD(D) =3D {Y, Z}.=E2=80=9D. Invalid grammatical construct. = Breaking this > complex sentence into two simpler ones might help. > > Thanks, it is quite difficult to read. Will use both here and in 3.1 the same bullet-based presentation as in 3.3. > > - section 3.3: =E2=80=9Cthe node will check if its the Parent Set (PS)= of its > Preferred Parent (PP), has a common node with the PS of the potential = AP.=E2=80=9D > =E2=80=94> =E2=80=9Cthe node will check if the Parent Set (PS) of its = Preferred Parent (PP) > has a node in common with the PS of the potential AP.=E2=80=9D > > Thanks, fixed. Helps readability. > > - section 4, 6LoRH type: is =E2=80=9C > https://tools.ietf.org/html/rfc8138#section-5.1=E2=80=9D an editing mi= stake? > > Yes, definitely. Mistake in XML. > > - section 4.1: =E2=80=9Csince it can help the alternative path from > significantly deviating from the preferred path.=E2=80=9D =E2=80=94> = =E2=80=9Csince it can help the > alternative path to not significantly deviate from the preferred path.= =E2=80=9D > > Thanks, clearer as you propose. Fixed. > > - section 4.1.1: =E2=80=9CGiven the intended usage, when using the PS,= the NSA > object it is contained in MUST be used as a constraint in the DAG Metr= ic > Container.=E2=80=9D. Complex sentence. Consider rephrasing, or simply = remove it > altogether. > > True, will break up and rephrase. Thanks. > > - Section 5: =E2=80=9Chowever it=E2=80=99s use=E2=80=9D =E2=80=94> =E2= =80=9Chowever its use=E2=80=9D > > Thanks, fixed. > > - Appendix A: =E2=80=9Cimmediatelly=E2=80=9D =E2=80=94> =E2=80=9Cimmed= iately=E2=80=9D. (several occurences). > > Thanks. All fixed. > > - Appendix A: =E2=80=9CLinks are reset uniformly randomly between 70% = and 100% > every 60 seconds=E2=80=9D. I guess you mean =E2=80=9CEvery 60 s, a new= Packet Delivery Rate > is randomly drawn for each link, with a uniform distribution spanning = the > 70% to 100% interval=E2=80=9D. > > Yes, exactly that. Will use your rephrasing as it's clearer. Again, thank you very much for the comments and I look forward to your reply. Kind regards, Aris > > De : Roll on behalf of Ines Robles < > mariainesrobles=3D40googlemail.com@dmarc.ietf.org> > R=C3=A9pondre =C3=A0 : "roll@ietf.org" > Date : Thursday 6 June 2019 12:12 > =C3=80 : "roll@ietf.org" > Objet : [Roll] Call for reviews for draft-ietf-roll-nsa-extension > > Dear all, > > We would like to have reviews for draft-ietf-roll-nsa-extension-01. > > Please let us know if you want to review it. > > Thank you very much, > > Ines and Peter > > _________________________________________________________________________= ________________________________________________ > > 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. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --0000000000003bb4d7058bdaf774 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dominique,

Thank you s= o very much for the detailed review and comments. They raise good points an= d we will address them all carefully in the next version.
Respons= es to individual points follow inline.

On Wed, = Jun 19, 2019 at 5:11 PM <dominique.barthel@orange.com> wrote:
Hello all,

Here is my review of=C2=A0draft-ietf-roll-nsa-extension-02.
I found it well written, with the appropriate amount of introductory materi= al and references.
I only have a few comments, as well as, this being me, a list of editorial = nits. See below.
Best regards

Dominique

=3D=3D

Comments
  • section 3.4: I believe OPTIONAL a= nd=20 MAY should be lowercase here, since this draft only specifies the DMC=20 extension, not the Objective Function.=C2=A0
I agree. I think I got a bit too trigger-happy with = the capitalised key words. Thank you.
  • sections 4.1.1 and 4.1.2: the DMC header fields are= defined in RFC6551, not 6550.
Of course, you are right. Incorrect reference. Thanks. Fixed.
=
  • section 4.1.1: in RFC6551, the Prec field is meant to be used for metrics, not=20 for constraints. Therefore, it is unused for this NSA extension, which=20 is a constraint. Unfortunately, RFC6551 forgot to specify a default=20 value. Is this the reason why you say =E2=80=9Cused according to RFC=E2=80=A6=E2= =80=9D? I suggest you=20 use the same text for the Prec and A fields. It could be quoting the=20 text from RFC6551, of referring the reader to it, or say nothing.
You are right. We had received a (reasonable) request to spell out how the=20 DMC fields should work in the case of this extension and we did so.
And, no, I hadn't noticed that the Prec field does not have a defaul= t value in the case of constraints in RFC6551. Sorry :)
I jus= t assumed that it would be ignored in cases of constraints, so any value wo= uld be valid.
Actually, in our implementation we sort the MCs based on Prec only for metrics,=20 so the value of Prec does not matter at all in constraints.
I= dislike copy-pasting text, so I think that your suggestion makes the most = sense.

  • section 4.1.2: =E2=80=9CFor clarity reasons, the usage of the PS places no additio= nal=20 restrictions on the NSA flags (=E2=80=99A=E2=80=99 and =E2=80=99O=E2=80=99)= , which can be used as=20 normally defined in [RFC6550]=E2=80=9D. The clarity reasons escaped me, as = well=20 as the additional restrictions that could have been placed but which have not! Anyway, RFC6551 states that the A Field is not used with constraints.=20 Overall, I think this whole subsection could go away since it specifies=20 nothing, says that it does not specify anything but does not say why it says it. ;-)
Yes, you are right and I see the point of it being superflu= ous.
Again, though, it was requested that we be explicit abo= ut the operation of existing flags.
Basically, for=C2=A0both 4.1.= 1 (DMC flags) and 4.1.2 (NSA flags) we don't actually redefine or limit= the existing RFC6551 spec.
So, yes, we basically should say nothing oth= er than "This is used only as a constraint".
Ideally, I prefer= to avoid restating things from other documents, but I don't know what = the right balance would be in this case.
What would you think= about replacing sections 4.1.1 (DMC flags) and 4.1.2 (NSA flags) with a si= mple statement like:
"The PS is used only within NSA objects con= figured as constraints"
  • Section 4.2: "Therefore, the PS=C2=A0IPv6 address(es) field SHOULD be compressed using the compre= ssion=C2=A0method for Source Routing Header 6LoRH (SRH-6LoRH)".=C2=A0I understand that = a=20 similar compression mechanism could be used. However, this requires=20 defining a protocol element that does not exist today, unless=C2=A0I missed= =20 something. Therefore, the normative SHOULD is irrelevant.=C2=A0I guess this section is merely suggesting future work.=C2=A0
We do have this almost fully implemen= ted (almost: only works in single root RPL instances).
Would it m= ake sense to spell out the exact specification of the compression even if i= t is largely a copy of the SRH-6LoRH compression method?
I can lowercase= the SHOULD, but using this kind of compression really makes big difference= in practice.
With this in mind, what do you thing we should do? = (pun intended)
  • Appendix A: does the experimental implementation do compression? If so, fo= r information, what's the DIO size?
Yes, it does do compression.
The size depen= ds on the other DIO options present.
We have tested using Contiki= with 802.15.4-TSCH, so the max packet size is 127 bytes without fragmentat= ion.
Without compression we can fit max 2 parents in the PS and we have to remove=20 the Prefix Information Option (if i remember correctly).
I can lo= ok up the actual byte count if that's helpful.

Nits
  • section 2: missing colons after t= he two terms being defined.
Fixed, thanks.
  • section 3: =E2=80=9Cincluded in operation=E2=80=9D=C2=A0=E2=80=94= > =E2=80=9Cincluded in the operation=E2=80=9D
Fixed, thanks.
  • section 3: alternative parent =E2=80=94> AP=
Fixed, thanks.
  • section 3: alterantive =E2=80=94> alterna= tive
Fixed, thanks.
  • section 3.1: =E2=80=9Cthe source node S must know its grandparent sets both throug= h=20 nodes A, B, C, and D.=E2=80=9D =E2=80=94> =E2=80=9Cboth=E2=80=9D is anad= equate and can be removed=20 altogether.
Of course,= fixed. Thanks.
  • section 3.2: =E2=80=9CTherefore, node S can decide to use node B or D as its AP no= de,=20 since given that PP(PP(S)) =3D Y, for node B PS(B) =3D {W, X, Y} and for=20 node D PD(D) =3D {Y, Z}.=E2=80=9D. Invalid grammatical construct. Breaking = this=20 complex sentence into two simpler ones might help.
Thanks, it is quite difficult to read. Will use both = here and in 3.1 the same bullet-based presentation as in 3.3.
  • section 3.3: =E2=80=9Cthe node will check if its the Parent Set (PS) of its Prefer= red=20 Parent (PP), has a common node with the PS of the potential AP.=E2=80=9D = =E2=80=94>=20 =E2=80=9Cthe node will check if the Parent Set (PS) of its Preferred Parent= (PP) has a node in common with the PS of the potential AP.=E2=80=9D
Thanks, fixed. Helps readability.
Yes, definitely. Mistake in XML.
  • section 4.1: =E2=80=9Csince it can help the alternative path from significantly=20 deviating from the preferred path.=E2=80=9D =E2=80=94> =E2=80=9Csince it= can help the=20 alternative path to not significantly deviate from the preferred path.=E2= =80=9D
Thanks, clearer= as you propose. Fixed.=C2=A0
  • section 4.1.1: =E2=80=9CGiven the intended usage, when using the PS, the NSA objec= t it=20 is contained in MUST be used as a constraint in the DAG Metric=20 Container.=E2=80=9D. Complex sentence. Consider rephrasing, or simply remov= e it=20 altogether.
True, will= break up and rephrase. Thanks.
  • Section 5: =E2=80=9Chowever it=E2=80=99s use=E2=80=9D = =E2=80=94> =E2=80=9Chowever its use=E2=80=9D
Thanks, fixed.
  • Appendix A: =E2=80=9Cimmediatelly=E2=80=9D =E2= =80=94> =E2=80=9Cimmediately=E2=80=9D. (several occurences).
    • =
Thanks. All fixed.
=
  • Appendix A: =E2=80=9CLinks are reset uniformly randomly between 70% and 100% every = 60=20 seconds=E2=80=9D. I guess you mean =E2=80=9CEvery 60 s, a new Packet Delive= ry Rate is=20 randomly drawn for each link, with a uniform distribution spanning the=20 70% to 100% interval=E2=80=9D.
Yes, exactly that. Will use your rephrasing as it's clearer.

Again, thank you v= ery much for the comments and I look forward to your reply.

Kind regards,
Aris



De=C2=A0: Roll <roll-bounces@ietf.org> on= behalf of Ines Robles <mariainesrobles=3D40googlemail.com@d= marc.ietf.org>
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: Thursday 6 June 2019 12= :12
=C3=80=C2=A0: "roll@ietf.org" <roll@ietf.org>
Objet=C2=A0: [Roll] Call for review= s for draft-ietf-roll-nsa-extension

Dear all,

We would like to have reviews for=C2=A0draft-ietf-roll-nsa-extension-0= 1.

Please let us know if you want to review it.=C2=A0

Thank you very much,

Ines and Peter
 
______________________________________________________________________=
___________________________________________________

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
--0000000000003bb4d7058bdaf774-- From nobody Fri Jun 21 15:59:51 2019 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 3C8E512009E; Fri, 21 Jun 2019 15:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 4Uv9Ij3VxOqZ; Fri, 21 Jun 2019 15:59:24 -0700 (PDT) Received: from smtp.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 8537C1201CA; Fri, 21 Jun 2019 15:51:08 -0700 (PDT) Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45Vv2w2NmQzyNl; Sat, 22 Jun 2019 00:47:36 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 582850053.758204-d969fe6eaa4cca51cefe7709c042bac9 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <6C828F5C-80B1-4156-9814-0C81FFC17A44@tzi.org> Date: Sat, 22 Jun 2019 00:47:36 +0200 To: lo <6lo@ietf.org>, tisch <6tisch@ietf.org>, lp-wan , lwip@ietf.org, Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Roll] Constrained Node/Network Cluster @ IETF105: 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: Fri, 21 Jun 2019 22:59:26 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF105. Remember that there is still quite some potential for changes. Conflicts that meet the eye: COSE/TEEP again! ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less annoying. (The poor TEEP people get to both start and end the week, too.) LAKE and LOOPS -- two BOFs at the same time? All times are EDT (Eastern Daylight Time) =3D=3D UTC -4 hours. (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 22, 2019 -- OMA/T2TRG Work Meeting - @ Ericsson Montreal Office (St-Laurent) SATURDAY/SUNDAY, March 23/24. 2019 -- Hackathon (including various interops) - Centre Ville -- Sun 1700-1900 Welcome Reception - Place du Canada -- Sun 1800-2000 Hot RFC Lightning Talks - Viger MONDAY, July 22, 2019 1000-1200 Morning Session I Laurier ART dispatch Dispatch WG Van Horne SEC *** teep Trusted Execution Environment = Provisioning WG 1330-1530 Afternoon Session I Van Horne INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Place du Canada SEC secdispatch Security Dispatch WG Duluth TSV taps Transport Services WG 1550-1750 Afternoon Session II Laurier ART httpbis Hypertext Transfer Protocol WG St-Catherine OPS v6ops IPv6 Operations WG Van Horne SEC *** lake Lightweight Authenticated Key Exchange = BOF Place du Canada TSV loops Local Optimizations on Path Segments BOF 1810-1910 Afternoon Session III Laurier TSV tsvwg Transport Area Working Group WG TUESDAY, July 23, 2019 1000-1200 Morning Session I St-Catherine ART *** cbor 1000-1130 Concise Binary Object = Representation Maintenance and Extensions WG St-Catherine INT ipwave 1130-1200 IP Wireless Access in = Vehicular Environments WG Notre Dame IRTF icnrg Information-Centric Networking Duluth OPS anima Autonomic Networking Integrated Model = and Approach WG Van Horne SEC cacao Collaborative Automated Course of Action = Operations for Cyber Security BOF Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Duluth OPS anima Autonomic Networking Integrated Model = and Approach WG 1520-1650 Afternoon Session II Duluth INT intarea Internet Area Working Group WG Place du Canada IRTF irtfopen IRTF Open Meeting Van Horne SEC oauth Web Authorization Protocol WG 1710-1810 Afternoon Session III Duluth ART *** core Constrained RESTful Environments WG Laurier INT 6man IPv6 Maintenance WG Place du Canada SEC tls Transport Layer Security WG WEDNESDAY, July 24, 2019 1000-1200 Morning Session I Van Horne IRTF*** dinrg Decentralized Internet Infrastructure St-Catherine RTG *** roll Routing Over Low power and Lossy = networks WG Viger SEC *** suit Software Updates for Internet of Things = WG Place du Canada TSV quic QUIC WG 1330-1530 Afternoon Session I Place du Canada GEN netrqmts IETF Meeting Network = Requirements BOF Laurier IRTF pearg Privacy Enhancements and Assessments = Research Group Viger IRTF*** t2trg Thing-to-Thing St-Catherine RTG bier Bit Indexed Explicit Replication WG Centre Ville RTG detnet Deterministic Networking WG 1550-1650 Afternoon Session II St-Catherine RTG babel Babel routing protocol WG Centre Ville RTG detnet Deterministic Networking WG Van Horne SEC *** rats Remote ATtestation ProcedureS WG THURSDAY, July 25, 2019 1000-1200 Morning Session I Centre Ville ART *** core Constrained RESTful Environments WG St-Catherine RTG rift Routing In Fat Trees WG Place du Canada SEC tls Transport Layer Security WG Laurier TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Viger IRTF coinrg Computing in the Network Proposed = Research Group Laurier IRTF panrg Path Aware Networking RG Place du Canada SEC saag Security Area Open Meeting 1550-1720 Afternoon Session II Laurier ART httpbis Hypertext Transfer Protocol WG Duluth INT 6man IPv6 Maintenance WG Place du Canada IRTF cfrg Crypto Forum St-Catherine SEC *** rats Remote ATtestation ProcedureS WG Centre Ville TSV tsvarea Transport Area Open Meeting 1740-1910 Afternoon Session III Duluth INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Centre Ville SEC *** ace Authentication and Authorization for = Constrained Environments WG Place du Canada SEC mls Messaging Layer Security WG Notre Dame TSV rmcat RTP Media Congestion Avoidance = Techniques WG FRIDAY, July 26, 2019 1000-1200 Morning Session I Notre Dame ART ice Interactive Connectivity Establishment = WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Laurier SEC mls Messaging Layer Security WG Duluth SEC oauth Web Authorization Protocol WG 1220-1350 Afternoon Session I Centre Ville SEC acme Automated Certificate Management = Environment WG Van Horne SEC *** cose CBOR Object Signing and Encryption WG St-Catherine SEC *** teep Trusted Execution Environment = Provisioning WG From nobody Mon Jun 24 06:19:24 2019 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 7861312010C; Mon, 24 Jun 2019 06:19:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156138236248.17748.5960291027521633912.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 06:19:22 -0700 Archived-At: Subject: [Roll] Barry Leiba's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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, 24 Jun 2019 13:19:22 -0000 Barry Leiba has entered the following ballot position for draft-ietf-roll-efficient-npdao-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have one substantive comment: — Section 4.3 — With respect to the K flag, it’s clear from the description that if you set the K flag you expect a response and you’re likely to retry if you don’t get it. Cool. It’s clear that if you don’t set the K flag you might or might not get a reply, and are more likely to get a reply for an error. Also cool. What’s not clear is whether it’s reasonable to retry if you don’t get a reply, and you didn’t set the K flag. I suspect that it’s not reasonable, because you didn’t ask for a reply, and I think it would help to say that: something like, “When the sender does not set the ‘K’ flag it is an indication that the sender does not expect a response, and the sender SHOULD NOT retry the DCO.” The rest is a bunch of editorial comments, but only editorial comments. General: I’ll note that the RFC Editor will change all the section titles to title case. So, for example, “Invalidate routes of dependent nodes” will become “Invalidate Routes of Dependent Nodes”. It would not be a bad thing to make those changes now, to save the RFC Editor the time. — Abstract — The abstract reads very badly to my eyes. I think it comes from an effort to stuff it all into one sentence. The Introduction actually says it in two sentences, and I think that works lots better: This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new pro-active route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. — Section 1 — In “distance-vector-based routing scheme”, you need two hyphens, as shown here. RPL has an optional messaging in the form of DAO Here “messaging” is a modifier, but it’s not modifying anything. An optional messaging *what*? — you need a noun there. Or maybe you just need to remove “an”, which also fixes the problem. — Section 1.2 — so that the node changing it routing adjacencies can invalidate the previous route. “its routing adjacencies” (possessive) This is needed so that nodes along the previous path can release any resources (such as the routing entry) it maintains There’s a number mismatch here: “nodes” and “it maintains”. You probably want “they maintain”. — Section 1.3 — In the section title, you either need to make it not a question (“Why NPDAO Is Important”) or change the word order to be consistent with the question (“Why Is NPDAO Important?”). to better achieve resource utilization. I think “to better optimize resource utilization” is better. — Section 4.3 — DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set. It’s probably not a real issue, but it seems mildly odd to me to mark it “optional” and then say that it MUST be set sometimes. Probably just me. But maybe this?: NEW DODAGID: 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set and is OPTIONAL otherwise. END (Also in Section 4.3.4) — Section 4.3.4 — If 'K' flag is not set then the receiver of the DCO message MAY send a DCO-ACK to signal an error condition. This should probably be made parallel to the description of the K flag above (and in 4.4 bullet 4 below), and say, “especially to report an error condition.” — Section 4.4 — 1. If a node sends a DCO message with newer or different information than the prior DCO message transmission, it MUST increment the DCOSequence field by at least one. A DCO message transmission that is identical to the prior DCO message transmission MAY increment the DCOSequence field. I’m starting this by saying that I don’t think you need to change anything here, but given that I’ve just polled several SSAC folks, simply because I happen to be at ICANN right now, about the specific meaning of “increment”, I have to relate this: All say that one can “increment by ”, and that’s fine. But we are divided on what “increment” without a number being specified means. Some say it means “by one” if you don’t specify. Others say that if you don’t specify, then the number is, well, unspecified and can be anything. In the text above, you say “by at least one” the first time, which is crystal clear. The second time you use “increment”, you don’t specify. Now, I’m groping here, but I wonder whether there could possibly be interoperability trouble caused by a recipient expecting an identical DCO message to have a DCOSequence that is the same or +1, but won’t tolerate an increase >1. No, probably not, probably not. You’re right; I can’t imagine this being a problem in practice. Never mind. (But if you care to, you might change “increment” to “increase” to get around this silly babble. Or not. As you choose.) I clearly have too much time on my hands. Nit: In bullet 5, “i.e.” needs a comma in front of it, as well as behind. Or, better, just remove “i.e.” and the sentence works perfectly well. — Section 4.5 — Nits: In bullet 2, “routing table is full thus resulting in an eviction of existing routing entry.” 1. There should be a comma before “thus”. 2. Remove “an” before “eviction”. 3. Put that removed “an” before “existing”. (Or, alternatively, make it “entries”, plural.) — Section 4.6.1 — Dependent nodes do not have any indication regarding if any of its parent nodes in turn have decided to switch their parent. Nits: There are a couple of number problems here. “Nodes” doesn’t match “its” (you need “their”). And “parent nodes” doesn’t match “their parent” (probably “their parents”, but maybe “any of their parents”). Similarly, the “its” in the subsequent sentence should be “their”. And “counterproductive” is one word. — Section 4.6.2 — Nits: “Moreover” needs a comma after it. In the second paragraph, “an alternate and more optimized way” should use “alternative” instead of alternate” (the distinction matter more in UK English than in US English). — Section 4.6.3 — Nits: “This documents recommends” should say “document” (singular). “all possible parent set” should say “sets” (plural). “requirement of synchronization” should say “requirement for synchronization”. — Section 7 — Nits: In the second paragraph, “if the ancestor nodes sees” should say “ancestor” (singular). And “Having said that” needs a comma after it. From nobody Mon Jun 24 06:27:36 2019 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 4DF93120289; Mon, 24 Jun 2019 06:27:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156138284931.17506.10304714265388241548.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 06:27:29 -0700 Archived-At: Subject: [Roll] Barry Leiba's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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, 24 Jun 2019 13:27:29 -0000 Barry Leiba has entered the following ballot position for draft-ietf-roll-efficient-npdao-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (Sorry, updated to add a second substantive comment that I forgot to put in the first time.) I have two substantive comments: — Section 1 — Further a new pro-active route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. It's a small thing, but given that this is a Standards Track document, but lots of it is not specifying a standard, I think it would be useful to call out the part that is. Maybe this way?: NEW Further, a new pro-active route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. This Standards Track specification is in Section 4. END — Section 4.3 — With respect to the K flag, it’s clear from the description that if you set the K flag you expect a response and you’re likely to retry if you don’t get it. Cool. It’s clear that if you don’t set the K flag you might or might not get a reply, and are more likely to get a reply for an error. Also cool. What’s not clear is whether it’s reasonable to retry if you don’t get a reply, and you didn’t set the K flag. I suspect that it’s not reasonable, because you didn’t ask for a reply, and I think it would help to say that: something like, “When the sender does not set the ‘K’ flag it is an indication that the sender does not expect a response, and the sender SHOULD NOT retry the DCO.” The rest is a bunch of editorial comments, but only editorial comments. General: I’ll note that the RFC Editor will change all the section titles to title case. So, for example, “Invalidate routes of dependent nodes” will become “Invalidate Routes of Dependent Nodes”. It would not be a bad thing to make those changes now, to save the RFC Editor the time. — Abstract — The abstract reads very badly to my eyes. I think it comes from an effort to stuff it all into one sentence. The Introduction actually says it in two sentences, and I think that works lots better: This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new pro-active route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. — Section 1 — In “distance-vector-based routing scheme”, you need two hyphens, as shown here. RPL has an optional messaging in the form of DAO Here “messaging” is a modifier, but it’s not modifying anything. An optional messaging *what*? — you need a noun there. Or maybe you just need to remove “an”, which also fixes the problem. — Section 1.2 — so that the node changing it routing adjacencies can invalidate the previous route. “its routing adjacencies” (possessive) This is needed so that nodes along the previous path can release any resources (such as the routing entry) it maintains There’s a number mismatch here: “nodes” and “it maintains”. You probably want “they maintain”. — Section 1.3 — In the section title, you either need to make it not a question (“Why NPDAO Is Important”) or change the word order to be consistent with the question (“Why Is NPDAO Important?”). to better achieve resource utilization. I think “to better optimize resource utilization” is better. — Section 4.3 — DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set. It’s probably not a real issue, but it seems mildly odd to me to mark it “optional” and then say that it MUST be set sometimes. Probably just me. But maybe this?: NEW DODAGID: 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set and is OPTIONAL otherwise. END (Also in Section 4.3.4) — Section 4.3.4 — If 'K' flag is not set then the receiver of the DCO message MAY send a DCO-ACK to signal an error condition. This should probably be made parallel to the description of the K flag above (and in 4.4 bullet 4 below), and say, “especially to report an error condition.” — Section 4.4 — 1. If a node sends a DCO message with newer or different information than the prior DCO message transmission, it MUST increment the DCOSequence field by at least one. A DCO message transmission that is identical to the prior DCO message transmission MAY increment the DCOSequence field. I’m starting this by saying that I don’t think you need to change anything here, but given that I’ve just polled several SSAC folks, simply because I happen to be at ICANN right now, about the specific meaning of “increment”, I have to relate this: All say that one can “increment by ”, and that’s fine. But we are divided on what “increment” without a number being specified means. Some say it means “by one” if you don’t specify. Others say that if you don’t specify, then the number is, well, unspecified and can be anything. In the text above, you say “by at least one” the first time, which is crystal clear. The second time you use “increment”, you don’t specify. Now, I’m groping here, but I wonder whether there could possibly be interoperability trouble caused by a recipient expecting an identical DCO message to have a DCOSequence that is the same or +1, but won’t tolerate an increase >1. No, probably not, probably not. You’re right; I can’t imagine this being a problem in practice. Never mind. (But if you care to, you might change “increment” to “increase” to get around this silly babble. Or not. As you choose.) I clearly have too much time on my hands. Nit: In bullet 5, “i.e.” needs a comma in front of it, as well as behind. Or, better, just remove “i.e.” and the sentence works perfectly well. — Section 4.5 — Nits: In bullet 2, “routing table is full thus resulting in an eviction of existing routing entry.” 1. There should be a comma before “thus”. 2. Remove “an” before “eviction”. 3. Put that removed “an” before “existing”. (Or, alternatively, make it “entries”, plural.) — Section 4.6.1 — Dependent nodes do not have any indication regarding if any of its parent nodes in turn have decided to switch their parent. Nits: There are a couple of number problems here. “Nodes” doesn’t match “its” (you need “their”). And “parent nodes” doesn’t match “their parent” (probably “their parents”, but maybe “any of their parents”). Similarly, the “its” in the subsequent sentence should be “their”. And “counterproductive” is one word. — Section 4.6.2 — Nits: “Moreover” needs a comma after it. In the second paragraph, “an alternate and more optimized way” should use “alternative” instead of alternate” (the distinction matter more in UK English than in US English). — Section 4.6.3 — Nits: “This documents recommends” should say “document” (singular). “all possible parent set” should say “sets” (plural). “requirement of synchronization” should say “requirement for synchronization”. — Section 7 — Nits: In the second paragraph, “if the ancestor nodes sees” should say “ancestor” (singular). And “Having said that” needs a comma after it. From nobody Mon Jun 24 10:00:26 2019 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 6A295120656; Mon, 24 Jun 2019 10:00:23 -0700 (PDT) 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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <156139562335.17453.10181644975970552720@ietfa.amsl.com> Date: Mon, 24 Jun 2019 10:00:23 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-nsa-extension-02.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, 24 Jun 2019 17:00:24 -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 DAG Metric Container Node State and Attribute object type extension Authors : Remous-Aris Koutsiamanis Georgios Papadopoulos Nicolas Montavont Pascal Thubert Filename : draft-ietf-roll-nsa-extension-02.txt Pages : 14 Date : 2019-06-24 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 a packet to enable this functionality. 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-nsa-extension-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 25 00:47:00 2019 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 F27B5120219; Tue, 25 Jun 2019 00:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kiLQcj0_ZqY; Tue, 25 Jun 2019 00:46:54 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514E71201F2; Tue, 25 Jun 2019 00:46:54 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 89828EF0420A6135AA5F; Tue, 25 Jun 2019 08:46:52 +0100 (IST) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 25 Jun 2019 08:46:46 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.118]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0439.000; Tue, 25 Jun 2019 13:13:06 +0530 From: Rahul Arvind Jadhav To: Barry Leiba , "Routing Over Low power and Lossy networks" , The IESG CC: "roll-chairs@ietf.org" , "draft-ietf-roll-efficient-npdao@ietf.org" Thread-Topic: [Roll] Barry Leiba's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) Thread-Index: AQHVKo95HueC3S24RkKS1A/HOJ/XSaar7b/A Date: Tue, 25 Jun 2019 07:43:06 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF0ACBD@BLREML503-MBX.china.huawei.com> References: <156138236248.17748.5960291027521633912.idtracker@ietfa.amsl.com> In-Reply-To: <156138236248.17748.5960291027521633912.idtracker@ietfa.amsl.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Barry Leiba's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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 Jun 2019 07:46:58 -0000 VGhhbmsgeW91IEJhcnJ5IGZvciB0aGUgcmV2aWV3IGFuZCB0aGUgZmVlZGJhY2suDQoNClBsZWFz ZSBmaW5kIG15IHJlcGxpZXMgaW5saW5lLiBFeGNlcHQgb25lIHBvaW50IHJlZ2FyZGluZyAnRCcg ZmxhZyBmb3IgRE9EQUdJRCwgSSB3aWxsIHVwZGF0ZSBhbGwgb3RoZXJzIGJhc2VkIG9uIHlvdXIg c3VnZ2VzdGlvbnMuIFBsZWFzZSBjaGVjayB0aGUgcmVwbHkgW1JKKl0gcmVnYXJkaW5nICdEJyBm bGFnIGJlbG93Lg0KDQpUaGFua3MsDQpSYWh1bA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCkkgaGF2ZSBvbmUgc3Vic3RhbnRpdmUgY29tbWVudDoNCg0K4oCU IFNlY3Rpb24gNC4zIOKAlA0KV2l0aCByZXNwZWN0IHRvIHRoZSBLIGZsYWcsIGl04oCZcyBjbGVh ciBmcm9tIHRoZSBkZXNjcmlwdGlvbiB0aGF0IGlmIHlvdSBzZXQgdGhlIEsgZmxhZyB5b3UgZXhw ZWN0IGEgcmVzcG9uc2UgYW5kIHlvdeKAmXJlIGxpa2VseSB0byByZXRyeSBpZiB5b3UgZG9u4oCZ dCBnZXQgaXQuIA0KQ29vbC4gIEl04oCZcyBjbGVhciB0aGF0IGlmIHlvdSBkb27igJl0IHNldCB0 aGUgSyBmbGFnIHlvdSBtaWdodCBvciBtaWdodCBub3QgZ2V0IGEgcmVwbHksIGFuZCBhcmUgbW9y ZSBsaWtlbHkgdG8gZ2V0IGEgcmVwbHkgZm9yIGFuIGVycm9yLiAgQWxzbyBjb29sLiAgV2hhdOKA mXMgbm90IGNsZWFyIGlzIHdoZXRoZXIgaXTigJlzIHJlYXNvbmFibGUgdG8gcmV0cnkgaWYgeW91 IGRvbuKAmXQgZ2V0IGEgcmVwbHksIGFuZCB5b3UgZGlkbuKAmXQgc2V0IHRoZSBLIGZsYWcuICBJ IHN1c3BlY3QgdGhhdCBpdOKAmXMgbm90IHJlYXNvbmFibGUsIGJlY2F1c2UgeW91IGRpZG7igJl0 IGFzayBmb3IgYSByZXBseSwgYW5kIEkgdGhpbmsgaXQgd291bGQgaGVscCB0byBzYXkgdGhhdDog c29tZXRoaW5nIGxpa2UsIOKAnFdoZW4gdGhlIHNlbmRlciBkb2VzIG5vdCBzZXQgdGhlIOKAmEvi gJkgZmxhZyBpdCBpcyBhbiBpbmRpY2F0aW9uIHRoYXQgdGhlIHNlbmRlciBkb2VzIG5vdCBleHBl Y3QgYSByZXNwb25zZSwgYW5kIHRoZSBzZW5kZXIgU0hPVUxEIE5PVCByZXRyeSB0aGUgRENPLuKA nQ0KDQpbUkpdIEkgd2lsbCBtYWtlIHRoaXMgZXhwbGljaXQgaW4gdGhlIGRvY3VtZW50LiBJZiAn SycgZmxhZyBpcyBub3Qgc2V0IHRoZW4gdGhlIHNlbmRlciBTSE9VTEQgTk9UIHJldHJ5IHRoZSBE Q08uDQoNClRoZSByZXN0IGlzIGEgYnVuY2ggb2YgZWRpdG9yaWFsIGNvbW1lbnRzLCBidXQgb25s eSBlZGl0b3JpYWwgY29tbWVudHMuDQoNCkdlbmVyYWw6IEnigJlsbCBub3RlIHRoYXQgdGhlIFJG QyBFZGl0b3Igd2lsbCBjaGFuZ2UgYWxsIHRoZSBzZWN0aW9uIHRpdGxlcyB0byB0aXRsZSBjYXNl LiAgU28sIGZvciBleGFtcGxlLCDigJxJbnZhbGlkYXRlIHJvdXRlcyBvZiBkZXBlbmRlbnQgbm9k ZXPigJ0gd2lsbCBiZWNvbWUg4oCcSW52YWxpZGF0ZSBSb3V0ZXMgb2YgRGVwZW5kZW50IE5vZGVz 4oCdLiAgSXQgd291bGQgbm90IGJlIGEgYmFkIHRoaW5nIHRvIG1ha2UgdGhvc2UgY2hhbmdlcyBu b3csIHRvIHNhdmUgdGhlIFJGQyBFZGl0b3IgdGhlIHRpbWUuDQoNCltSSl0gd2lsbCBjaGFuZ2Ug dGhpcy4NCg0K4oCUIEFic3RyYWN0IOKAlA0KDQpUaGUgYWJzdHJhY3QgcmVhZHMgdmVyeSBiYWRs eSB0byBteSBleWVzLiAgSSB0aGluayBpdCBjb21lcyBmcm9tIGFuIGVmZm9ydCB0byBzdHVmZiBp dCBhbGwgaW50byBvbmUgc2VudGVuY2UuICBUaGUgSW50cm9kdWN0aW9uIGFjdHVhbGx5IHNheXMg aXQgaW4gdHdvIHNlbnRlbmNlcywgYW5kIEkgdGhpbmsgdGhhdCB3b3JrcyBsb3RzIGJldHRlcjoN Cg0KICAgVGhpcyBkb2N1bWVudCBleHBsYWlucyB0aGUgcHJvYmxlbXMNCiAgIGFzc29jaWF0ZWQg d2l0aCB0aGUgY3VycmVudCB1c2Ugb2YgTlBEQU8gbWVzc2FnaW5nIGFuZCBhbHNvIGRpc2N1c3Nl cw0KICAgdGhlIHJlcXVpcmVtZW50cyBmb3IgYW4gb3B0aW1pemVkIHJvdXRlIGludmFsaWRhdGlv biBtZXNzYWdpbmcNCiAgIHNjaGVtZS4gIEZ1cnRoZXIgYSBuZXcgcHJvLWFjdGl2ZSByb3V0ZSBp bnZhbGlkYXRpb24gbWVzc2FnZSBjYWxsZWQNCiAgIGFzICJEZXN0aW5hdGlvbiBDbGVhbnVwIE9i amVjdCIgKERDTykgaXMgc3BlY2lmaWVkIHdoaWNoIGZ1bGZpbGxzDQogICByZXF1aXJlbWVudHMg b2YgYW4gb3B0aW1pemVkIHJvdXRlIGludmFsaWRhdGlvbiBtZXNzYWdpbmcuDQoNCltSSl0gOikg VGhpcyBvbmUgc291bmRzIGJldHRlci4gV2lsbCB1cGRhdGUgdGhlIGFic3RyYWN0Lg0KDQrigJQg U2VjdGlvbiAxIOKAlA0KDQpJbiDigJxkaXN0YW5jZS12ZWN0b3ItYmFzZWQgcm91dGluZyBzY2hl bWXigJ0sIHlvdSBuZWVkIHR3byBoeXBoZW5zLCBhcyBzaG93biBoZXJlLg0KDQogICBSUEwgaGFz IGFuIG9wdGlvbmFsIG1lc3NhZ2luZyBpbiB0aGUgZm9ybSBvZiBEQU8NCg0KSGVyZSDigJxtZXNz YWdpbmfigJ0gaXMgYSBtb2RpZmllciwgYnV0IGl04oCZcyBub3QgbW9kaWZ5aW5nIGFueXRoaW5n LiAgQW4gb3B0aW9uYWwgbWVzc2FnaW5nICp3aGF0Kj8g4oCUIHlvdSBuZWVkIGEgbm91biB0aGVy ZS4gIE9yIG1heWJlIHlvdSBqdXN0IG5lZWQgdG8gcmVtb3ZlIOKAnGFu4oCdLCB3aGljaCBhbHNv IGZpeGVzIHRoZSBwcm9ibGVtLg0KDQpbUkpdIFdpbGwgcmVtb3ZlIHRoZSAiYW4iDQoNCuKAlCBT ZWN0aW9uIDEuMiDigJQNCg0KICAgc28gdGhhdCB0aGUgbm9kZQ0KICAgY2hhbmdpbmcgaXQgcm91 dGluZyBhZGphY2VuY2llcyBjYW4gaW52YWxpZGF0ZSB0aGUgcHJldmlvdXMgcm91dGUuDQoNCuKA nGl0cyByb3V0aW5nIGFkamFjZW5jaWVz4oCdIChwb3NzZXNzaXZlKQ0KDQogICBUaGlzIGlzIG5l ZWRlZCBzbyB0aGF0IG5vZGVzIGFsb25nIHRoZSBwcmV2aW91cyBwYXRoIGNhbiByZWxlYXNlIGFu eQ0KICAgcmVzb3VyY2VzIChzdWNoIGFzIHRoZSByb3V0aW5nIGVudHJ5KSBpdCBtYWludGFpbnMN Cg0KVGhlcmXigJlzIGEgbnVtYmVyIG1pc21hdGNoIGhlcmU6IOKAnG5vZGVz4oCdIGFuZCDigJxp dCBtYWludGFpbnPigJ0uICBZb3UgcHJvYmFibHkgd2FudCDigJx0aGV5IG1haW50YWlu4oCdLg0K DQpbUkpdIFdpbGwgZml4DQoNCuKAlCBTZWN0aW9uIDEuMyDigJQNCg0KSW4gdGhlIHNlY3Rpb24g dGl0bGUsIHlvdSBlaXRoZXIgbmVlZCB0byBtYWtlIGl0IG5vdCBhIHF1ZXN0aW9uICjigJxXaHkg TlBEQU8gSXMNCkltcG9ydGFudOKAnSkgb3IgY2hhbmdlIHRoZSB3b3JkIG9yZGVyIHRvIGJlIGNv bnNpc3RlbnQgd2l0aCB0aGUgcXVlc3Rpb24gKOKAnFdoeSBJcyBOUERBTyBJbXBvcnRhbnQ/4oCd KS4NCg0KICAgdG8gYmV0dGVyIGFjaGlldmUgcmVzb3VyY2UgdXRpbGl6YXRpb24uDQoNCkkgdGhp bmsg4oCcdG8gYmV0dGVyIG9wdGltaXplIHJlc291cmNlIHV0aWxpemF0aW9u4oCdIGlzIGJldHRl ci4NCg0KW1JKXSBXaWxsIGZpeCBhcyBwZXIgeW91ciBzdWdnZXN0aW9uLg0KDQrigJQgU2VjdGlv biA0LjMg4oCUDQoNCiAgIERPREFHSUQgKG9wdGlvbmFsKTogMTI4LWJpdCB1bnNpZ25lZCBpbnRl Z2VyIHNldCBieSBhIERPREFHIHJvb3QgdGhhdA0KICAgdW5pcXVlbHkgaWRlbnRpZmllcyBhIERP REFHLiAgVGhpcyBmaWVsZCBNVVNUIGJlIHByZXNlbnQgd2hlbiB0aGUgJ0QnDQogICBmbGFnIGlz IHNldC4NCg0KSXTigJlzIHByb2JhYmx5IG5vdCBhIHJlYWwgaXNzdWUsIGJ1dCBpdCBzZWVtcyBt aWxkbHkgb2RkIHRvIG1lIHRvIG1hcmsgaXQg4oCcb3B0aW9uYWzigJ0gYW5kIHRoZW4gc2F5IHRo YXQgaXQgTVVTVCBiZSBzZXQgc29tZXRpbWVzLiAgUHJvYmFibHkganVzdCBtZS4gIEJ1dCBtYXli ZSB0aGlzPzoNCg0KTkVXDQogICBET0RBR0lEOiAxMjgtYml0IHVuc2lnbmVkIGludGVnZXIgc2V0 IGJ5IGEgRE9EQUcgcm9vdCB0aGF0IHVuaXF1ZWx5DQogICBpZGVudGlmaWVzIGEgRE9EQUcuICBU aGlzIGZpZWxkIE1VU1QgYmUgcHJlc2VudCB3aGVuIHRoZSAnRCcgZmxhZyBpcw0KICAgc2V0IGFu ZCBpcyBPUFRJT05BTCBvdGhlcndpc2UuDQpFTkQNCg0KW1JKKl0gJ2lzIE9QVElPTkFMIG90aGVy d2lzZScgbWF5IG5vdCBiZSB0aGUgcmlnaHQgc3RhdGVtZW50LCBpdCB0ZWxscyB0aGUgaW1wbGVt ZW50ZXIgdGhhdCBpZiAnRCcgZmxhZyBpcyBub3Qgc2V0IHRoZW4gaXQgaXMgb3B0aW9uYWwuIElm ICdEJyBmbGFnIGlzIG5vdCBzZXQgdGhlbiBET0RBR0lEIE1VU1Qgbm90IGJlIHByZXNlbnQuIE1h eSBiZSBJIHNob3VsZCBtZW50aW9uIHRoaXMgZXhwbGljaXRseS4gSSBwbGFuIHRvIGNoYW5nZSBs aWtlIHRoaXM6DQpORVcNCiAgIERPREFHSUQ6IDEyOC1iaXQgdW5zaWduZWQgaW50ZWdlciBzZXQg YnkgYSBET0RBRyByb290IHRoYXQgdW5pcXVlbHkNCiAgIGlkZW50aWZpZXMgYSBET0RBRy4gIFRo aXMgZmllbGQgTVVTVCBiZSBwcmVzZW50IHdoZW4gdGhlICdEJyBmbGFnIGlzDQogICBzZXQgYW5k IE1VU1QgTk9UIGJlIHByZXNlbnQgaWYgJ0QnIGZsYWcgaXMgbm90IHNldC4NCkVORA0KDQooQWxz byBpbiBTZWN0aW9uIDQuMy40KQ0KDQrigJQgU2VjdGlvbiA0LjMuNCDigJQNCg0KICAgSWYNCiAg ICdLJyBmbGFnIGlzIG5vdCBzZXQgdGhlbiB0aGUgcmVjZWl2ZXIgb2YgdGhlIERDTyBtZXNzYWdl IE1BWSBzZW5kIGENCiAgIERDTy1BQ0sgdG8gc2lnbmFsIGFuIGVycm9yIGNvbmRpdGlvbi4NCg0K VGhpcyBzaG91bGQgcHJvYmFibHkgYmUgbWFkZSBwYXJhbGxlbCB0byB0aGUgZGVzY3JpcHRpb24g b2YgdGhlIEsgZmxhZyBhYm92ZSAoYW5kIGluIDQuNCBidWxsZXQgNCBiZWxvdyksIGFuZCBzYXks IOKAnGVzcGVjaWFsbHkgdG8gcmVwb3J0IGFuIGVycm9yIGNvbmRpdGlvbi7igJ0NCg0KW1JKXSBX aWxsIGZpeCB0aGlzLg0KDQrigJQgU2VjdGlvbiA0LjQg4oCUDQoNCiAgIDEuICBJZiBhIG5vZGUg c2VuZHMgYSBEQ08gbWVzc2FnZSB3aXRoIG5ld2VyIG9yIGRpZmZlcmVudCBpbmZvcm1hdGlvbg0K ICAgICAgIHRoYW4gdGhlIHByaW9yIERDTyBtZXNzYWdlIHRyYW5zbWlzc2lvbiwgaXQgTVVTVCBp bmNyZW1lbnQgdGhlDQogICAgICAgRENPU2VxdWVuY2UgZmllbGQgYnkgYXQgbGVhc3Qgb25lLiAg QSBEQ08gbWVzc2FnZSB0cmFuc21pc3Npb24NCiAgICAgICB0aGF0IGlzIGlkZW50aWNhbCB0byB0 aGUgcHJpb3IgRENPIG1lc3NhZ2UgdHJhbnNtaXNzaW9uIE1BWQ0KICAgICAgIGluY3JlbWVudCB0 aGUgRENPU2VxdWVuY2UgZmllbGQuDQoNCknigJltIHN0YXJ0aW5nIHRoaXMgYnkgc2F5aW5nIHRo YXQgSSBkb27igJl0IHRoaW5rIHlvdSBuZWVkIHRvIGNoYW5nZSBhbnl0aGluZyBoZXJlLCBidXQg Z2l2ZW4gdGhhdCBJ4oCZdmUganVzdCBwb2xsZWQgc2V2ZXJhbCBTU0FDIGZvbGtzLCBzaW1wbHkg YmVjYXVzZSBJIGhhcHBlbiB0byBiZSBhdCBJQ0FOTiByaWdodCBub3csIGFib3V0IHRoZSBzcGVj aWZpYyBtZWFuaW5nIG9mIOKAnGluY3JlbWVudOKAnSwgSSBoYXZlIHRvIHJlbGF0ZSB0aGlzOg0K DQpBbGwgc2F5IHRoYXQgb25lIGNhbiDigJxpbmNyZW1lbnQgYnkgPGEgbnVtYmVyPuKAnSwgYW5k IHRoYXTigJlzIGZpbmUuICBCdXQgd2UgYXJlIGRpdmlkZWQgb24gd2hhdCDigJxpbmNyZW1lbnTi gJ0gd2l0aG91dCBhIG51bWJlciBiZWluZyBzcGVjaWZpZWQgbWVhbnMuICBTb21lIHNheSBpdCBt ZWFucyDigJxieSBvbmXigJ0gaWYgeW91IGRvbuKAmXQgc3BlY2lmeS4gIE90aGVycyBzYXkgdGhh dCBpZiB5b3UgZG9u4oCZdCBzcGVjaWZ5LCB0aGVuIHRoZSBudW1iZXIgaXMsIHdlbGwsIHVuc3Bl Y2lmaWVkIGFuZCBjYW4gYmUgYW55dGhpbmcuICBJbiB0aGUgdGV4dCBhYm92ZSwgeW91IHNheSDi gJxieSBhdCBsZWFzdCBvbmXigJ0gdGhlIGZpcnN0IHRpbWUsIHdoaWNoIGlzIGNyeXN0YWwgY2xl YXIuICBUaGUgc2Vjb25kIHRpbWUgeW91IHVzZSDigJxpbmNyZW1lbnTigJ0sIHlvdSBkb27igJl0 IHNwZWNpZnkuDQoNCk5vdywgSeKAmW0gZ3JvcGluZyBoZXJlLCBidXQgSSB3b25kZXIgd2hldGhl ciB0aGVyZSBjb3VsZCBwb3NzaWJseSBiZSBpbnRlcm9wZXJhYmlsaXR5IHRyb3VibGUgY2F1c2Vk IGJ5IGEgcmVjaXBpZW50IGV4cGVjdGluZyBhbiBpZGVudGljYWwgRENPIG1lc3NhZ2UgdG8gaGF2 ZSBhIERDT1NlcXVlbmNlIHRoYXQgaXMgdGhlIHNhbWUgb3IgKzEsIGJ1dCB3b27igJl0IHRvbGVy YXRlIGFuIGluY3JlYXNlID4xLiAgTm8sIHByb2JhYmx5IG5vdCwgcHJvYmFibHkgbm90LiAgWW91 4oCZcmUgcmlnaHQ7IEkgY2Fu4oCZdCBpbWFnaW5lIHRoaXMgYmVpbmcgYSBwcm9ibGVtIGluIHBy YWN0aWNlLg0KDQpOZXZlciBtaW5kLg0KDQooQnV0IGlmIHlvdSBjYXJlIHRvLCB5b3UgbWlnaHQg Y2hhbmdlIOKAnGluY3JlbWVudOKAnSB0byDigJxpbmNyZWFzZeKAnSB0byBnZXQgYXJvdW5kIHRo aXMgc2lsbHkgYmFiYmxlLiAgT3Igbm90LiAgQXMgeW91IGNob29zZS4pDQoNCltSSl0gSSB0aGlu ayBJIHdpbGwgY2hhbmdlIGl0IHRvICJpbmNyZWFzZSIuIFRoYW5rcyBmb3IgY29tbWVudGluZyB0 aGUgY29udGV4dC4NCg0KSSBjbGVhcmx5IGhhdmUgdG9vIG11Y2ggdGltZSBvbiBteSBoYW5kcy4N Cg0KW1JKXTogOi0pKQ0KDQpOaXQ6IEluIGJ1bGxldCA1LCDigJxpLmUu4oCdIG5lZWRzIGEgY29t bWEgaW4gZnJvbnQgb2YgaXQsIGFzIHdlbGwgYXMgYmVoaW5kLiAgT3IsIGJldHRlciwganVzdCBy ZW1vdmUg4oCcaS5lLuKAnSBhbmQgdGhlIHNlbnRlbmNlIHdvcmtzIHBlcmZlY3RseSB3ZWxsLg0K DQpbUkpdIFdpbGwgZml4Lg0KDQrigJQgU2VjdGlvbiA0LjUg4oCUDQpOaXRzOiBJbiBidWxsZXQg Miwg4oCccm91dGluZyB0YWJsZSBpcyBmdWxsIHRodXMgcmVzdWx0aW5nIGluIGFuIGV2aWN0aW9u IG9mIGV4aXN0aW5nIHJvdXRpbmcgZW50cnku4oCdIDEuIFRoZXJlIHNob3VsZCBiZSBhIGNvbW1h IGJlZm9yZSDigJx0aHVz4oCdLiAyLiBSZW1vdmUg4oCcYW7igJ0gYmVmb3JlIOKAnGV2aWN0aW9u 4oCdLiAzLiBQdXQgdGhhdCByZW1vdmVkIOKAnGFu4oCdIGJlZm9yZSDigJxleGlzdGluZ+KAnS4g IChPciwgYWx0ZXJuYXRpdmVseSwgbWFrZSBpdCDigJxlbnRyaWVz4oCdLCBwbHVyYWwuKQ0KDQri gJQgU2VjdGlvbiA0LjYuMSDigJQNCg0KICAgRGVwZW5kZW50IG5vZGVzIGRvIG5vdCBoYXZlIGFu eSBpbmRpY2F0aW9uIHJlZ2FyZGluZyBpZiBhbnkgb2YgaXRzDQogICBwYXJlbnQgbm9kZXMgaW4g dHVybiBoYXZlIGRlY2lkZWQgdG8gc3dpdGNoIHRoZWlyIHBhcmVudC4NCg0KTml0czogVGhlcmUg YXJlIGEgY291cGxlIG9mIG51bWJlciBwcm9ibGVtcyBoZXJlLiAg4oCcTm9kZXPigJ0gZG9lc27i gJl0IG1hdGNoIOKAnGl0c+KAnQ0KKHlvdSBuZWVkIOKAnHRoZWly4oCdKS4gIEFuZCDigJxwYXJl bnQgbm9kZXPigJ0gZG9lc27igJl0IG1hdGNoIOKAnHRoZWlyIHBhcmVudOKAnSAocHJvYmFibHkg 4oCcdGhlaXIgcGFyZW50c+KAnSwgYnV0IG1heWJlIOKAnGFueSBvZiB0aGVpciBwYXJlbnRz4oCd KS4NCg0KU2ltaWxhcmx5LCB0aGUg4oCcaXRz4oCdIGluIHRoZSBzdWJzZXF1ZW50IHNlbnRlbmNl IHNob3VsZCBiZSDigJx0aGVpcuKAnS4NCg0KQW5kIOKAnGNvdW50ZXJwcm9kdWN0aXZl4oCdIGlz IG9uZSB3b3JkLg0KDQrigJQgU2VjdGlvbiA0LjYuMiDigJQNCk5pdHM6IOKAnE1vcmVvdmVy4oCd IG5lZWRzIGEgY29tbWEgYWZ0ZXIgaXQuDQoNCkluIHRoZSBzZWNvbmQgcGFyYWdyYXBoLCDigJxh biBhbHRlcm5hdGUgYW5kIG1vcmUgb3B0aW1pemVkIHdheeKAnSBzaG91bGQgdXNlIOKAnGFsdGVy bmF0aXZl4oCdIGluc3RlYWQgb2YgYWx0ZXJuYXRl4oCdICh0aGUgZGlzdGluY3Rpb24gbWF0dGVy IG1vcmUgaW4gVUsgRW5nbGlzaCB0aGFuIGluIFVTIEVuZ2xpc2gpLg0KDQrigJQgU2VjdGlvbiA0 LjYuMyDigJQNCg0KTml0czog4oCcVGhpcyBkb2N1bWVudHMgcmVjb21tZW5kc+KAnSBzaG91bGQg c2F5IOKAnGRvY3VtZW504oCdIChzaW5ndWxhcikuDQoNCuKAnGFsbCBwb3NzaWJsZSBwYXJlbnQg c2V04oCdIHNob3VsZCBzYXkg4oCcc2V0c+KAnSAocGx1cmFsKS4NCg0K4oCccmVxdWlyZW1lbnQg b2Ygc3luY2hyb25pemF0aW9u4oCdIHNob3VsZCBzYXkg4oCccmVxdWlyZW1lbnQgZm9yIHN5bmNo cm9uaXphdGlvbuKAnS4NCg0K4oCUIFNlY3Rpb24gNyDigJQNCk5pdHM6IEluIHRoZSBzZWNvbmQg cGFyYWdyYXBoLCDigJxpZiB0aGUgYW5jZXN0b3Igbm9kZXMgc2Vlc+KAnSBzaG91bGQgc2F5IOKA nGFuY2VzdG9y4oCdIChzaW5ndWxhcikuICBBbmQg4oCcSGF2aW5nIHNhaWQgdGhhdOKAnSBuZWVk cyBhIGNvbW1hIGFmdGVyIGl0Lg0KDQpbUkpdIFdpbGwgZml4IGFsbCBhYm92ZSBuaXRzLg0KDQo= From nobody Tue Jun 25 01:33:51 2019 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 377F612008A; Tue, 25 Jun 2019 01:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 1f2tlbG2n0ks; Tue, 25 Jun 2019 01:33:42 -0700 (PDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (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 1F98A1200E9; Tue, 25 Jun 2019 01:33:42 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id k8so255783iot.1; Tue, 25 Jun 2019 01:33:42 -0700 (PDT) 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=XbSQK3Bpyb6hAVXt3FRwtjLtG4rnm8mJwG75Fm25zG4=; b=EHP/yZTQGDAs/syMbg1aAN+NNvFJebKNbltB+dGY/eZXjzOxzgk8pArut7+wrshGVZ tzL1bIb9xtE7NfwuPlJdcfOx8IN064uRLz4sHELmq/VJv4ESJD91gBnlnDAVM6tjmc6C 1eGmC4L06yCAnPKAt4kkxLHwyBAyQr7Qa+yyZL1gR9pxqTVdFvXRDLtc4YfcWVwtE98p xMkHpsZn1SJ33woWESQAZ3JoJ6xtio65ZbqKAxS/tCip5tfdncRwHa43tHcrkw+sSUqN 4ohZVJ/wfpWRr2aTolVbvAtLIN+kRK54wJP94vOlsqs0boe3vjDRIxfo0CamzCKlkawU yJlQ== X-Gm-Message-State: APjAAAWmSuYDJ2YPj3eDh+fxUx11pjsHy383BAJvB1PV/OYZ03PB2IXV N8o5hyC6J6wYVggSDonjgUr9s/lGyq8drJ+pXiU= X-Google-Smtp-Source: APXvYqx/Xaj9a23jCsdWjhvD793RcwaxQpGec0qFrJFyAQ8o3iRbT7wR/a5xngNz9RhBnVXPdt/5QpuNOz12SsQTRCA= X-Received: by 2002:a02:b710:: with SMTP id g16mr38205079jam.88.1561451620817; Tue, 25 Jun 2019 01:33:40 -0700 (PDT) MIME-Version: 1.0 References: <156138236248.17748.5960291027521633912.idtracker@ietfa.amsl.com> <982B626E107E334DBE601D979F31785C5DF0ACBD@BLREML503-MBX.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DF0ACBD@BLREML503-MBX.china.huawei.com> From: Barry Leiba Date: Tue, 25 Jun 2019 09:33:29 +0100 Message-ID: To: Rahul Arvind Jadhav Cc: Routing Over Low power and Lossy networks , The IESG , "roll-chairs@ietf.org" , "draft-ietf-roll-efficient-npdao@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] Barry Leiba's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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 Jun 2019 08:33:43 -0000 Thanks, Rahul, for the quick response and for addressing my comments. On the item where I got the solution wrong: >> NEW >> DODAGID: 128-bit unsigned integer set by a DODAG root that uniquely >> identifies a DODAG. This field MUST be present when the 'D' flag is >> set and is OPTIONAL otherwise. >> END > > [RJ*] 'is OPTIONAL otherwise' may not be the right statement, it tells th= e implementer that if 'D' flag is not set then it is optional. If 'D' flag = is not set then DODAGID MUST not be present. May be I should mention this e= xplicitly. I plan to change like this: > NEW > DODAGID: 128-bit unsigned integer set by a DODAG root that uniquely > identifies a DODAG. This field MUST be present when the 'D' flag is > set and MUST NOT be present if 'D' flag is not set. > END Perfect, and thanks for correcting my misunderstanding. Barry From nobody Tue Jun 25 02:04:32 2019 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 9678112026E; Tue, 25 Jun 2019 02:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sei_wVTbsDxp; Tue, 25 Jun 2019 02:04:26 -0700 (PDT) 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 5487C12004D; Tue, 25 Jun 2019 02:04:25 -0700 (PDT) Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id DDDD81B6F; Tue, 25 Jun 2019 11:04:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1561453462; bh=Ot7TyeGBrMhw+ypfiPXpTBe9mACWNnbvJep9ui1Frfg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NfeswIcLGpaH2+YdNBIcuCJp5HN/ad2WAzw6msrbJpbQSnArcJ9j7lcv+CFBCFaPb hxWGdwT16ygN61IC5KFdgvryFKuRFY9lbiwT2Wj4b3hlw4AZe2rWFfTV50P1rf1ZEX QLA5H2x2nrRZ1+v4wFR+a4ZVxx7sAVSiyEpYTe9ENF9El5h7M3wUnL6KB1HmxgbY4Q eU8shWmswgyrfFYsAvabq27yo1iWkUb955XTuUiApt7uiXjhcGbLZPYUcG5SB7xU9U DBo2k4vAAoZQi8SjCJsffNMVgpDLhekaBZ75Mx7MJEwbnQO26lAugXCNP3S+0JRM7V jhP02HuK6yNVA== Received: by smtp.mailfence.com with ESMTPA ; Tue, 25 Jun 2019 11:04:11 +0200 (CEST) Received: by mail-io1-f50.google.com with SMTP id s7so1492799iob.11; Tue, 25 Jun 2019 02:04:11 -0700 (PDT) X-Gm-Message-State: APjAAAWWL87XBuvx3sMTLerLsQXKbnlN2bFW0MXdHlG8/NH9bneGLnY3 XJ767aFJM1Eob0nNEJda86qLfFDmw5b7I/HkphU= X-Google-Smtp-Source: APXvYqw4sG86IVz5QT4QFfJy1EfOHA409UvK9D9NAkgdQerAeuXQSaIYBu+kDGAtg5qgRp+oQxPx+CHZMeRdyBJPEkE= X-Received: by 2002:a02:c88e:: with SMTP id m14mr119769113jao.69.1561453447024; Tue, 25 Jun 2019 02:04:07 -0700 (PDT) MIME-Version: 1.0 References: <156139562335.17453.10181644975970552720@ietfa.amsl.com> In-Reply-To: <156139562335.17453.10181644975970552720@ietfa.amsl.com> From: Remous-Aris Koutsiamanis Date: Tue, 25 Jun 2019 11:04:14 +0200 (CEST) X-Gmail-Original-Message-ID: Message-ID: To: roll Cc: i-d-announce@ietf.org, Dominique.Barthel@orange-ftgroup.com, abdussalambaryun@gmail.com Content-Type: multipart/alternative; boundary="0000000000000b15f8058c22361f" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-nsa-extension-02.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 Jun 2019 09:04:30 -0000 --0000000000000b15f8058c22361f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, we have updated the draft-ietf-roll-nsa-extension draft to address most of the comments from Dominique. The remaining comments that we are awaiting an answer to follow below to make it easy to focus on the remaining issues. Best, Aris On Mon, Jun 24, 2019 at 7:00 PM wrote: > > 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 network= s > WG of the IETF. > > Title : RPL DAG Metric Container Node State and > Attribute object type extension > Authors : Remous-Aris Koutsiamanis > Georgios Papadopoulos > Nicolas Montavont > Pascal Thubert > Filename : draft-ietf-roll-nsa-extension-02.txt > Pages : 14 > Date : 2019-06-24 > > 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 a packet to enable this > functionality. > > > 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-02 > https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-nsa-extension-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > *Comments from Dominique: * On Wed, Jun 19, 2019 at 5:11 PM wrote: > > - section 4.1.1: in RFC6551, the Prec field is meant to be used for > metrics, not for constraints. Therefore, it is unused for this NSA > extension, which is a constraint. Unfortunately, RFC6551 forgot to > specify a default value. Is this the reason why you say =E2=80=9Cused = according to > RFC=E2=80=A6=E2=80=9D? I suggest you use the same text for the Prec an= d A fields. It could > be quoting the text from RFC6551, of referring the reader to it, or sa= y > nothing. > - section 4.1.2: =E2=80=9CFor clarity reasons, the usage of the PS pla= ces no > additional restrictions on the NSA flags (=E2=80=99A=E2=80=99 and =E2= =80=99O=E2=80=99), which can be > used as normally defined in [RFC6550]=E2=80=9D. The clarity reasons es= caped me, as > well as the additional restrictions that could have been placed but wh= ich > have not! Anyway, RFC6551 states that the A Field is not used with > constraints. Overall, I think this whole subsection could go away sinc= e it > specifies nothing, says that it does not specify anything but does not= say > why it says it. ;-) > > We replaced 4.1.1 and 4.1.2 with just "The PS is used only within NSA objects configured as constraints and is used as per [RFC6551 ]." in Section 4.1 > > - Section 4.2: "Therefore, the PS IPv6 address(es) field SHOULD be > compressed using the compression method for Source Routing Header > 6LoRH (SRH-6LoRH)". I understand that a similar compression mechanism = could > be used. However, this requires defining a protocol element that does = not > exist today, unless I missed something. Therefore, the normative SHOUL= D is > irrelevant. I guess this section is merely suggesting future work. > > We do have this almost fully implemented (almost: only works in single root RPL instances). Would it make sense to spell out the exact specification of the compression even if it is largely a copy of the SRH-6LoRH compression method? I can lowercase the SHOULD, but using this kind of compression really makes big difference in practice. > > - Appendix A: does the experimental implementation do compression? If > so, for information, what's the DIO size? > > Yes, it does do compression. The size depends on the other DIO options present. We have tested using Contiki with 802.15.4-TSCH, so the max packet size is 127 bytes without fragmentation. Without compression we can fit max 2 parents in the PS and we have to remove the Prefix Information Option (if i remember correctly). I can look up the actual byte count if that's helpful. *Comments from Abdussalam: * On Mon, Jun 17, 2019 at 1:10 AM Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ines and Peter, > > IMHO the draft is not clear in its use-case, I think it must include > rfc8578 to clarify its usecase, and using references of architectures doe= s > not help us understand but makes it more difficult. > Thank you very much for reading this draft and providing us with your comments. It is very much appreciated. I would like to ask some clarifying questions if you don't mind. *"the draft is not clear in its use-case, I think it must include rfc8578 to clarify its usecase"* We are aware of the DetNet usecases and following your comment we will point to the rfc8578 and specifically Section 5. Wireless for Industrial Applications, which is what we are aiming at with this draft. We have attempted to strike a balance between the introductory material present in the draft (to help it stand alone) and referencing other sources to avoid reiterating things. If you think that just referencing rfc8578 Section 5. Wireless for Industrial Applications is insufficient, maybe you could provide a bit more detail on what should and should not be present in the draft. *"using references of architectures does not help us understand but makes it more difficult"* Could you please be more explicit? We reference two architectures in this draft. In Section 1 Introduction, we refer to the 6TiSCH architecture, as the base upon which this draft builds. In Section 1 Introduction we reference the DetNet architecture as context for aim of maximizing packet delivery rate and minimizing latency and jitter. In Section 5 Controlling PRE we reference the DetNet architecture specifically as an example to allow the fine-grained control of PRE usage via flow labels. Which of these or other references to architectures did you have in mind? --0000000000000b15f8058c22361f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

we h= ave updated the draft-ietf-roll-nsa-extension draft to address most of the = comments from Dominique.
The remaining comments that we are await= ing an answer to follow below to make it easy to focus on the remaining iss= ues.

Best,
Aris

On Mon, Jun 24,= 2019 at 7:00 PM <internet-d= rafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= RPL DAG Metric Container Node State and Attribute object type extension =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Remo= us-Aris Koutsiamanis
=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 Georgios Papadopoulos
=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 Nicolas Montavont
=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 Pascal Thubert
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-roll-nsa-extension-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-06-24

Abstract:
=C2=A0 =C2=A0Implementing Packet Replication and Elimination from / to the = RPL
=C2=A0 =C2=A0root requires the ability to forward copies of packets over di= fferent
=C2=A0 =C2=A0paths via different RPL parents.=C2=A0 Selecting the appropria= te parents
=C2=A0 =C2=A0to achieve ultra-low latency and jitter requires information a= bout a
=C2=A0 =C2=A0node's parents.=C2=A0 This document details what informati= on needs to be
=C2=A0 =C2=A0transmitted and how it is encoded within a packet to enable th= is
=C2=A0 =C2=A0functionality.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-roll-nsa-extension/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-r= oll-nsa-extension-02
https://datatracker.ietf.org/d= oc/html/draft-ietf-roll-nsa-extension-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-roll-nsa-extension-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


Comments from Dominique:=C2= =A0
On Wed, Jun 19, 2019 at 5:11 PM <dominique.barthel@orange.com> w= rote:
  • secti= on 4.1.1: in RFC6551, the Prec field is meant to be used for metrics, not=20 for constraints. Therefore, it is unused for this = NSA extension, which is a constraint. Unfortunately, RFC6551 forgot to specify a=20 default value. Is this the reason why you say =E2=80=9Cused according to RFC=E2=80=A6=E2= =80=9D? I suggest you=20 use the same text for the Prec and A fields. It could be quoting the=20 text from RFC6551, of referring the reader to it, or say nothing.
  • section 4.1.2: =E2=80=9CFor clarity= reasons, the usage of the PS places no additional restrictions on the NSA flags (=E2=80=99A=E2=80=99 and =E2=80=99O=E2=80=99), which can be used as = normally defined in=20 [RFC6550]=E2=80=9D. The clarity reasons escaped me, as well as the additional restrictions that could have been placed but which have not! Anyway, RFC6551 states that the A Field is not used with constraints.=20 Overall, I think this whole subsection could go away since it specifies=20 nothing, says that it does not specify anything but does not say why it says it. ;-)
We replaced 4.1.1 and 4.1.2= with just "The PS is used only within NSA objects configured as const= raints and is used as per [RFC6551]." in Section 4.1
<= ul>
  • Section 4.2: "Therefore, the PS=C2=A0IPv6 address(es) field SHOULD be c= ompressed using the compression=C2=A0method for Source Routing Header 6LoRH (SRH-6LoRH)".=C2=A0I understand that = a=20 similar compression mechanism could be used. However, this requires=20 defining a protocol element that does not exist today, unless=C2=A0I missed= =20 something. Therefore, the normative SHOULD is irrelevant.=C2=A0I guess this section is merely suggesting future work.=C2=A0
    • We do have this almost fully implemen= ted (almost: only works in single root RPL instances).
    Would it m= ake sense to spell out the exact specification of the compression even if i= t is largely a copy of the SRH-6LoRH comp= ression method?
    I ca= n lowercase the SHOULD, but using this kind of compression really makes big= difference in practice.
    • Appendix A: does the experimental implementation do compr= ession? If so, for information, what's the DIO size?
    Yes, it does do compression.
    The size depends on the other DIO options present.
    We have tes= ted using Contiki with 802.15.4-TSCH, so the max packet size is 127 bytes w= ithout fragmentation.
    Without compression we can fit max 2 parents in the PS and we have to remove=20 the Prefix Information Option (if i remember correctly).
    I can lo= ok up the actual byte count if that's helpful.

    =


    Comments from Abdussalam:
    On Mon,= Jun 17, 2019 at 1:10 AM Abdussalam Baryun <abdussalambaryun@gmail.com> wrot= e:
    Hi Ines and Peter,

    IMHO the draft is not clear in its use-case, I think it must include rfc8578 to clarify its usecase, and using references of architectures does not=20 help us understand but makes it more difficult.

    Thank you very much for reading this draft and pro= viding us with your comments. It is very much appreciated.

    I would like to ask some clarifying questions if you don't min= d.
    "the draft is not clear in it= s use-case, I think it must include rfc8578 to clarify its usecase"
    We are aware of the DetNet usecases and following your comment we will=20 point to the rfc8578 and specifically Section 5. Wireless for Industrial Applications, which is what we are aiming at with this draft.
    We have attempted to strike a balance between the introductory material=20 present in the draft (to help it stand alone) and referencing other=20 sources to avoid reiterating things.
    If you think that=20 just referencing rfc8578 Section 5. Wireless for Industrial Applications is insufficient, maybe you could provide a bit more detail on what=20 should and should not be present in the draft.

    "using references of architectures does n= ot help us understand but makes it more difficult"
    Could you please be more explicit?
    We reference two architectur= es in this draft.
    In Section 1 Introduction, we refer to the 6TiS= CH architecture, as the base upon which this draft builds.
    In Section 1 Introduction=C2=A0 we reference the DetNet architecture as conte= xt for aim of maximizing packet delivery rate and minimizing latency and=20 jitter.
    In Section 5 Controlling PRE we=20 reference the DetNet architecture specifically as an example to allow=20 the fine-grained control of PRE usage via flow labels.

    Which of these or other re= ferences to architectures did you have in mind?


    --0000000000000b15f8058c22361f-- From nobody Tue Jun 25 04:00:52 2019 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 EFA3A120118 for ; Tue, 25 Jun 2019 04:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 RjpMZBx6lIMu for ; Tue, 25 Jun 2019 04:00:48 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 85DF31200DE for ; Tue, 25 Jun 2019 04:00:47 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id k20so397537ios.10 for ; Tue, 25 Jun 2019 04:00:47 -0700 (PDT) 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=TfhT/yjfvBLidoQHeHkBWtYqRYrCUUplUdIhFc+7Z60=; b=F4rSe5OOS5cTNRuRcD43/e7F6XiF/1A35IXclmK+hmbdXEaYBjvyCjRtmn1+gtzzB3 fNwOu2rWFB5+T86Tin+f1X6Yi7TF15RAOBI9XAV7ay37G0uh6n9KXyulA/STEVecBuJ5 q6eB/grGSlnL03O88qdnhwjhv2CZIbU9ghVuOJOSFhy7YKtqwiojbYDZTBzuMsyh/bhr srkym0MyWEBwsFYSO/iD+stFTsHcfXltuL3Jd5BcjErumDXMq/kbYP16ONbWpOcy5Qdx Aud9pkBCTW4ATgtUG0vF5h4zIyi4mGgZmpFpuJXTkhz9zc41pfhokDkLYXM+/JEuFpdx oPpA== 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=TfhT/yjfvBLidoQHeHkBWtYqRYrCUUplUdIhFc+7Z60=; b=AZxU6lAWIV4qExPeXye6RAg39UQTKIjsjc3jzuwUbkqS/dOs2f/II+P+0YOW8Fa4mi H7Dej2MOizRV7PLhup/K4+q9vdDtHH1BEyeWyOQEBWrqWsFhhSTLWntFyhJAQAbrW/pk hPGohTtTCK5Qoq0W+sAmtCKjxNR86DYtCcR3irBKOgPS4scm06RUAA16leXp1bjKC97v WiKgua+VLstgMcBETwin2DEE4lpiU23yFiKFeL6qTxG+OUeDUUty4EuHaqZmzoibmUOb SEE2s6VcupGxVwR3hdtpW1jfZJntYXAXEDg12LHXLHxmTCwWBftaIVvGIJ4BEjN3lltR GfXA== X-Gm-Message-State: APjAAAViJ3KaHVqnX1P6BJMwAxiI76i+0+q7NnKnvzm/HSAEzcrvjDVc aBgRX8FxNwKgxdA5D/XA8R7acw7TR/7ve3kdGgVHFQekASE= X-Google-Smtp-Source: APXvYqznr/OHunxSCtr428DQw/fBIeiSTURA07u2otJrMOea/nhIl8GyLmrD5a1OBGjlWAZU98cYaxdBwvSp5T/Wlnc= X-Received: by 2002:a02:c00f:: with SMTP id y15mr23142785jai.132.1561460446259; Tue, 25 Jun 2019 04:00:46 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Tue, 25 Jun 2019 14:00:35 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="0000000000003aeb8d058c23d7a6" Archived-At: Subject: [Roll] IETF 105 Presentation Topic 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 Jun 2019 11:00:51 -0000 --0000000000003aeb8d058c23d7a6 Content-Type: text/plain; charset="UTF-8" Dear all, Please let us know if you wish to present a topic at the IETF 105, specifying: - Topic To present - Time needed for presentation - Presenter - please clarify onsite or remote-. Deadline to request the slot: 8th July. The preliminary agenda states for ROLL: 10:00-12:00 Wednesday Morning session I, July 24 Thank you, Ines and Peter --0000000000003aeb8d058c23d7a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear all,

    Please let us know if you= wish to present a topic at the=C2=A0IETF= =C2=A0105, specifying:

    =
    - Topic To present
    - Time needed for presentation
    = - Presenter - please clarify onsite or remote-.

    De= adline to request the slot: 8th July.

    The prelimin= ary agenda states for ROLL: 10:00-12:00 Wednesday Morning session I, July 2= 4

    Thank you,

    Ines and Pet= er
    --0000000000003aeb8d058c23d7a6-- From nobody Tue Jun 25 08:09:07 2019 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 BEF711203EC; Tue, 25 Jun 2019 08:09:05 -0700 (PDT) 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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <156147534567.31169.10353808251200069193@ietfa.amsl.com> Date: Tue, 25 Jun 2019 08:09:05 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-30.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, 25 Jun 2019 15:09: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 RPL 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-30.txt Pages : 54 Date : 2019-06-25 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 (RPL 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 RPL 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-30 https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-30 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-30 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 Jun 25 08:16:18 2019 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 1EF81120415; Tue, 25 Jun 2019 08:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 mjIsdgpywcOM; Tue, 25 Jun 2019 08:16:05 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 C50CC1205E7; Tue, 25 Jun 2019 08:15:47 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id m24so757884ioo.2; Tue, 25 Jun 2019 08:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CqdoUgWQGGHSNJMWA8Yv3ECSRewgGjJUrOfFTmU+Iyo=; b=OVIAuihjvfYAA73qFAUkAGD3UY35A7nXLwYkoDvhrCOVCeRK1OogoMGjZWQM8sPrC0 RTVZxkrHZX4NuTewh/liV9JM74HSw+eSEIPWSqtm4qtcnjhtvJbaDpfN+9lJKTmSTcJC FAG38ji5P6P8JE16GQdxEBWBCE2PTKcZLaUAtHtmUuv1voeepCvnWPFkhAdZQ6QZiTR8 ZTxVg/3kYSae1/KRSCXU+hMDjkP66o3N5qPt7EBPo93LihnE8XeUUvoB1HzRSK27sncF HbY2635WI0U50UTAwjV14ei/QCKN8CPTIDcogW4BEWO8DEw5T/P9pNSdAqfOBP3BKMvv KtXw== 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=CqdoUgWQGGHSNJMWA8Yv3ECSRewgGjJUrOfFTmU+Iyo=; b=fkqfYTwJe3EFTJE2823zpYWlj55zBgWLANNmZkrA+wWS4Iwi45vPfHEi0UvZgYCWd+ 3LkEXKw0nxmsw5wzRN3xNcukPKOo7a7VdJHn3dMmte/HZmSubeJqegWZI9LUcTJ4wgW9 oBj1KBzlGcPBgk+BRDXKRRbpz+U7/+t0CxFwUcbm0rd3SehklJnOxMfnbqZybgg7/TYS 56VHGLCCL+xf0jtoHieEIIHpd3FBcp4SXXwf0TsygXouOAfyCV3nQwKMF9fYvc/eeuz0 AXunnNXCeZX07szKZdKGwcjlWwx6ZvrLKfRfqEoNZCmZjNYWQAQcNA5a5rIa70HbUrUI 8UkQ== X-Gm-Message-State: APjAAAWH8+wm/3FpEbqiG7Fuhs7ZzpId2IzZDzn7SzMzotGD0FX4veHS CKJ2Nlp24BNHcXLWLM0MYpx4D6b/3DSf5ZJGX2E= X-Google-Smtp-Source: APXvYqzUeG04jqSO3jWgAIClTRRbJvnAkSHWeUDSdyVKwoTo3/O4kcuWlvwtGATlLECGRwkm5z00TTHZmhwtNGPOHtY= X-Received: by 2002:a6b:7f0b:: with SMTP id l11mr119014816ioq.282.1561475746922; Tue, 25 Jun 2019 08:15:46 -0700 (PDT) MIME-Version: 1.0 References: <155893122016.5649.5181856210255754201.idtracker@ietfa.amsl.com> In-Reply-To: <155893122016.5649.5181856210255754201.idtracker@ietfa.amsl.com> From: Ines Robles Date: Tue, 25 Jun 2019 18:15:35 +0300 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-roll-useofrplinfo@ietf.org, Peter Van der Stok , Alvaro Retana , roll-chairs , roll Content-Type: multipart/alternative; boundary="00000000000038880b058c2767c4" Archived-At: Subject: Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-29: (with COMMENT) 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 Jun 2019 15:16:08 -0000 --00000000000038880b058c2767c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Benjamin, Many thanks for your new review, we believe that version 30 addresses your concerns. Please find comments in-line On Mon, May 27, 2019 at 7:27 AM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for addressing my Discuss (and Comment) points! > > I just have a few more minor notes on the -29: > > the "(1)" footnote is no longer present. > Yes, it was deleted. Because the field in the table was =E2=80=9CNo=E2=80= =9D before (version 25), so we put the footnote to indicate that for 6tisch could be relevant. but since we made RPI mandatory, it is a yes, so no need the footnote. Anyway we mention the relevance of this case for 6tisch networks. We added the explanation in the text. =E2=80=9CIn the Figure the (1) indicates a 6tisch case [RFC8180 ], where the RPI header may still be needed for the instanceID to be available for priority/channel selection at each hop=E2=80=9D > > I'm also not sure about the global change from "_i are the > intermediate routers" to "_i is the intermediate router", since the > general case can still have more than one intermediate in each > direction. But perhaps we should leave this to the RFC Editor. > We changed back to =E2=80=9Care the intermediate routers=E2=80=9D. Yes Edit= or can confirm that. > > Section 11 > > nit: "especially if the target of the attack is targeting another LLN" > had redudant "target" added -- just "especially if attack is targeting > another LLN" would be fine. > Fixed, thank you > > I think the claim that "[i]n the end, the IPsec tunnels would be > providing only BCP38-like origin authentication!" could use some > additional justifcation. > > answered it in a previous email Thank you very much, Ines, Michael and Pascal --00000000000038880b058c2767c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi Benjamin,


    M= any thanks for your new review, we believe that version 30 addresses your c= oncerns. Please find comments in-line



    On Mon, May 27, 2019 at 7:27 AM Benjamin K= aduk via Datatracker <noreply@ietf.o= rg> wrote:

    <author>

    Yes, it was deleted. Because the field in the table=C2=A0= was =E2=80=9CNo=E2=80=9D before (version 25), so we put the footnote to in= dicate that for 6tisch could be relevant. but since we made RPI mandatory, = it is a yes, so no need the footnote. Anyway we mention the relevance of th= is case for 6tisch networks. We added the explanation in the text.


    =E2= =80=9CIn the Figure the (1) indicates a 6tisch case [RFC8180],=

    =C2=A0=C2=A0=C2=A0where the RPI header may s= till be needed for the instanceID to be

    =C2=A0=C2=A0=C2=A0available for priority/channel selection at each= hop=E2=80=9D


    </author>


    =C2=A0

    I'm also not sure about the global change from "<foo>_i are = the
    intermediate routers" to "<foo>_i is the intermediate route= r", since the
    general case can still have more than one intermediate in each
    direction.=C2=A0 But perhaps we should leave this to the RFC Editor.

    <author>

    We changed back to =E2=80=9Care the int= ermediate routers=E2=80=9D. Yes Editor can confirm that.

    <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial;font-variant-numeric:normal;= font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap= "></author>


    =C2=A0

    Section 11

    nit: "especially if the target of the attack is targeting another LLN&= quot;
    had redudant "target" added -- just "especially if attack is= targeting
    another LLN" would be fine.

    <author>

    Fixed, thank you

    &= lt;/author>


    =C2=A0

    I think the claim that "[i]n the end, the IPsec tunnels would be
    providing only BCP38-like origin authentication!" could use some
    additional justifcation.

    <author> answered it = in a previous email </author>=C2=A0

    Thank you ve= ry much,

    Ines, Michael and Pascal
    --00000000000038880b058c2767c4-- From nobody Tue Jun 25 08:20:18 2019 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 C198212046B; Tue, 25 Jun 2019 08:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 ccty8Rw35tyb; Tue, 25 Jun 2019 08:20:08 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 20782120469; Tue, 25 Jun 2019 08:20:08 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id s7so4018973iob.11; Tue, 25 Jun 2019 08:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2KuqGG7gdSRTluyEsfFFuJpnQl8vs0G2tSprhcMgfPc=; b=oRoWUjZ7daAytCnf6N2uHY4WjNP/96kPeE/SZQzdEYSc3rOvy7SSYjSECIqpysSHTN CLBzLOHVZOsPmKTSfBZZwJ80mR+I8YgaM60JtJWPxuD72qD83jL3UIXXG5gqcUecP2FY sC404KdoZTLSxqchAKVKNV10nyPmiaJcyIMNjvunSSnOa/MRurZzB0IqglGp5XPFOoo8 SoiRcqEW6NyU0Dyx5zdC5FcI3m+I24+wdj78hcPaST0jERoXoz5JuAFNCz0XNNC0vbfW 2r+be6WmGI0u3le5wEoDCh+X32u1fnjxpU75DhbwMr5auspmYBUQw9t9jnS7qii9+zis jj3g== 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=2KuqGG7gdSRTluyEsfFFuJpnQl8vs0G2tSprhcMgfPc=; b=AccjZxsmrWQ7JtZGC3Clp1oMPSb/6xBlqnWeEQqlfk7X44/AAJLiXl/zig3kIr0h/V 6WysjZvcYcaiUnuijKNesAz/+16hEYxH1JEM9iHCkXjK5B6sJy1t1QGjXWGnAv9a/RSn 8agLBt5+1jGIaALKzmFGt+WylP4MBchxi3gonZzZqG4Odwosjj27paFeZ4Eo8Qdfmnbh nZokf/7KaPJveuquj2iMRd6HmzHQQMPbymFlce1wkA2K3G7sTFEc4Qtgz243/vgxxzQm 6V4DskEZeVsEk5ZcYUvLpKHG5uiWTn/UYqm+Z0o0dtTTirdJHs9ey83h+1+VLXLk3rgi geFQ== X-Gm-Message-State: APjAAAVnoxW4vDfXCoB7S9a5PK2zP/HJciPyDo0SEiBaOnTfqErbFFXS 9szYvwnKFMvLmwkaTL95LsflxfaBCRAMZ8KzoYw= X-Google-Smtp-Source: APXvYqx1pKyvnojWRKPEGaML2MsN4oe3LA4RpNIv9jjHekVUqRCTmGmkSsLN2GXHJQLHtb0dymQcZjgfuNYQqLBuQhc= X-Received: by 2002:a5e:c748:: with SMTP id g8mr62221223iop.267.1561476007342; Tue, 25 Jun 2019 08:20:07 -0700 (PDT) MIME-Version: 1.0 References: <155921848366.22184.9860598937998618938.idtracker@ietfa.amsl.com> In-Reply-To: <155921848366.22184.9860598937998618938.idtracker@ietfa.amsl.com> From: Ines Robles Date: Tue, 25 Jun 2019 18:19:56 +0300 Message-ID: To: Suresh Krishnan Cc: The IESG , draft-ietf-roll-useofrplinfo@ietf.org, Peter Van der Stok , Alvaro Retana , roll-chairs , roll Content-Type: multipart/alternative; boundary="000000000000be3653058c2776c3" Archived-At: Subject: Re: [Roll] Suresh Krishnan's No Objection on draft-ietf-roll-useofrplinfo-29: (with COMMENT) 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 Jun 2019 15:20:10 -0000 --000000000000be3653058c2776c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Suresh, Thank you very much for your review. we believe that version 30 addressed your concerns. Please find answers in-line. On Thu, May 30, 2019 at 3:14 PM Suresh Krishnan via Datatracker < noreply@ietf.org> wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Section 3.1 > > This text following the RFC8200 quote is not supported or implied by the > quote > > "This means that while it should be avoided, the impact on the Internet o= f > leaking a Hop-by-Hop header is acceptable." > > Is this text necessary? > We deleted that text > > * Section 3.2 > > It is not clear if nodes are required to change option types when the > config > flag transitions from 0 to 1 (e.g. after the reboot mentioned). Can you > please > clarify? > > New text: =E2=80=9C In case of rebooting, the node (6LN or 6LR) does not remember the RPL Option Type, that is if the flag is set, so DIO messages sent by the node would be set with the flag unset until a DIO message is received with the flag set indicating the new RPI value. The node sets to 0x23 if the node supports this feature. =E2=80=9C > * Section 6 > > In the cases where a hop-by-hop options header needs to be added (denoted > by > "hop" in the table), I am assuming that the destination address is copied > from > the inner packet into the encapsulating packet. If this is right, I think > it > might be useful to explicitly mention it as the dst field of the table > does not > provide the required information. > New text added: =E2=80=9C In the hop-by-hop basis, the destination address for the next hop is the link-layer address of the next hop.=E2=80=9D Thank you very much again, Ines, Michael and Pascal. --000000000000be3653058c2776c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Suresh,=

    = =

    = Thank you very much for your review. we bel= ieve that version 30 addressed your concerns. Please find answers in-line.<= /span>



    On Thu, May 30, 201= 9 at 3:14 PM Suresh Krishnan via Datatracker <noreply@ietf.org> wrote:

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    * Section 3.1

    This text following the RFC8200 quote is not supported or implied by the qu= ote

    "This means that while it should be avoided, the impact on the Interne= t of
    leaking a Hop-by-Hop header is acceptable."

    Is this text necessary?

    <author>

    We= deleted that text

    </author>


    = =C2=A0

    * Section 3.2

    It is not clear if nodes are required to change option types when the confi= g
    flag transitions from 0 to 1 (e.g. after the reboot mentioned). Can you ple= ase
    clarify?

    <author>

    New text: =E2=80=9C=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    =C2=A0=C2=A0<t>

    =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0In case of r= ebooting, the node (6LN or 6LR) does not remember the RPL Option Type, that= is if the flag is set, so DIO messages sent by the node would be set with = the flag unset until a DIO message is received with the flag set indicating= the new RPI value. The node sets to 0x23 if the node supports this feature= .

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</t> =E2=80=9C

    </author= >


    =
    =C2=A0
    * Section 6

    In the cases where a hop-by-hop options header needs to be added (denoted b= y
    "hop" in the table), I am assuming that the destination address i= s copied from
    the inner packet into the encapsulating packet. If this is right, I think i= t
    might be useful to explicitly mention it as the dst field of the table does= not
    provide the required information.


    <author>=

    New text added: =E2=80=9C In the hop-by-hop basis, the destin= ation address=C2=A0

    =C2=A0 =C2=A0 for the next hop is th= e link-layer address of the next hop.=E2=80=9D

    </author>=



    Than= k you very much again,

    =
    Ines, Michael and Pascal.=C2=A0
    --000000000000be3653058c2776c3-- From nobody Tue Jun 25 08:30:29 2019 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 35BCE1205D4; Tue, 25 Jun 2019 08:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_KAM_HTML_FONT_INVALID=0.01] 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 owoMFuQBXiCo; Tue, 25 Jun 2019 08:30:14 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 BD3C01205CB; Tue, 25 Jun 2019 08:30:07 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id i10so1774208iol.13; Tue, 25 Jun 2019 08:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rRVRjf8wnPJHJdTyI/1bSPz80Comh66PtpPNnJ748AU=; b=noNec1LEgt0rWipTS6z7OnrtfoK66xoQ7KSpuJi9HfqIPdLAa649YhyiOzlV322+V4 VE95pBGyuERncaJ+kkh9kSUXsey0RlK0K51wvuL3H5sDP30NRylvbFk10JMy9Mu5cMsP fVWeZc5dvEQJRfegnYsR0PDytdZdaGXijF9FTTY33bZP6Dmz68KIx6L8XkcNKTpAAK4k amXtvFxUrxv4UcYuTocB1d32EafqT6MZASiJwijqXF/LTCIGd+22E4rjx4kjaKxZfGAj w4359FovqiV2FiSGx5uTB0AQGPwAUYhJ9/bzwr3qsf86atqlIfK9Oo3he00Z80tSuMmv mOSw== 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=rRVRjf8wnPJHJdTyI/1bSPz80Comh66PtpPNnJ748AU=; b=DV4dXbIcA63MzArQZlti5fboF0/7K04tq1eAW6L0QajxtcVdAKQGz6LcUDNCt6h0Ej rPMafRI9xE5EFIcTXmNeHrS4nbgEmD4m95HVoaVtFNNpY/WLvRw6i+ZzPD2gHbGKddGt Vtyp8/UAm7hWrsXtMcHgk2WgroWTa0no7zPjNUU0doycUR70NPyCx0pu7xrheTt4V2/v lEnc0RbpZ7R6r6yqqFxrbNl9RdnMQUKQGj3WckWJ2KZ6K+1NZliLDH2DsLI3oAQy0NKg s+ueU8V0wNvzPFXLIretkZPCPdBbZFlJZmU5BnrLYB/3eBSrnQK5xb6/Ui8ZNJBUw28C MDCg== X-Gm-Message-State: APjAAAVAv3KIuAzfMBZwYbp6mv0laVl9C65TUL+b23wpcZdFSI78mfq1 3ILSEd8AIHzHQV8BG7qtn7wvE6EMZlBo7rVpwaM= X-Google-Smtp-Source: APXvYqz7i9eZi1BJhHcqS0P+9B2DrMq6lBSKI2A8jvLZwoJcy9p+8gDntAWkTOhPjDcXmelgcew3sf+7YS7kr9AUoLc= X-Received: by 2002:a5d:9550:: with SMTP id a16mr47286968ios.106.1561476606616; Tue, 25 Jun 2019 08:30:06 -0700 (PDT) MIME-Version: 1.0 References: <155680522759.24830.12360220783250812372.idtracker@ietfa.amsl.com> <20190527042217.GL18546@prolepsis.kaduk.org> <3de1e15f-e1af-ab63-9ad9-13597dc3adcd@earthlink.net> In-Reply-To: <3de1e15f-e1af-ab63-9ad9-13597dc3adcd@earthlink.net> From: Ines Robles Date: Tue, 25 Jun 2019 18:29:54 +0300 Message-ID: To: Charlie Perkins Cc: Routing Over Low power and Lossy networks , Samita Chakrabarti , roll-chairs , The IESG , draft-ietf-roll-useofrplinfo@ietf.org Content-Type: multipart/alternative; boundary="000000000000766b51058c279ac2" Archived-At: Subject: Re: [Roll] IoT-dir last call review of draft-ietf-roll-useofrplinfo 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 Jun 2019 15:30:20 -0000 --000000000000766b51058c279ac2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Charlie, Many thanks for your review, we really appreciate all your comments and suggestions to improve the draft. we believe that version 30 addresses your concerns. Please find answers in-line. -------------------------------------------- My main technical concern has to do with the attempt to classify RPI Option Types 0x23 and 0x63 as somehow being variants of the same Option Type. I don't think this is really legitimate; they have to be considered to be two different Options. I believe the idea is that it should be simple to implement both together, and type 0x23 is likely to survive traversal of the Internet. An intermediate device that implements 0x63 but not 0x23 will not process any of the configuration options present in 0x23, but at least the packet won't be dropped. I'm not sure how serious this problem is for intermediate 6LRs in the path of a 0x23 packet traversing the LLN, but those configuration options are meant for consumption by such intermediate 6LRs. We believe that is the same Option Type, with the value updated from 0x63 to 0x23. The network would switch to 0x23 when all the nodes are capable to process it. One thing that would help, is to include in the overview a very succinct list of design requirements and also a list of assumptions made during the design. I had wanted to create this list but that would take another day. Here is a start, and I hope that any misunderstanding that I have will be minor: Requirements: 1. RPI has to be in every packet that traverses the LLN 2. Because of (1), packets from the Internet have to be encapsulated 3. Extension headers may not be added or removed except by the sender or the receiver 4. Packets that will traverse RPI-unaware nodes need encapsulation, but only sender or receiver can add the new RPI option (0x23) 5. Non-storing mode requires downstream encapsulation by root for RH Assumptions: - Each IPv6 node (including Internet routers) obeys RFC 8200, so that 0x23 RPI can be safely inserted. - All 6LRs obey RFC 8200 These requirements and assumptions determine the entries in the dozens of tables included within the document. Without a clear grasp of them, it is easy to get lost in the sea of details about header insertion and encapsulation. Very good idea, thank you. We added a list of Requirements and Assumptions. Requirements: 1- The RPI option has to be in every packet that traverses the LLN 2-. Because of (1), packets from the Internet have to be encapsulated 3-. A Header cannot be inserted or removed on the fly inside an IPv6 packet that is being routed. 4-- Extension headers may not be added or removed except by the sender or the receiver. 5-- RPI and RH3 headers may be modified by routers on the path of the packet without the need to add and remove an encapsulating header 6-- An RH3 or RPI Option can only be removed by an intermediate router if it is placed in an encapsulating IPv6 Header, which is addressed to the intermediate router. .7 Non-storing mode requires downstream encapsulation by root for RH3. Assumptions: This document assumes that the LLN is using the no-drop RPI option (0x23). - Each IPv6 node (including Internet routers) obeys [RFC8200] 8200, so that 0x23 RPI can be safely inserted. - All 6LRs obey [RFC8200]. - The RPI is ignored at the IPv6 dst node (RPL-unaware-leaf). - The leaf can be a router 6LR or a host, both indicated as 6LN. - Non-constrained uses of RPL are not in scope of this document. - Compression is based on [RFC8138]. - The flow label [RFC6437] is not needed in RPL. Most of my many comments are editorial. I think that the draft could be easier to read with fewer digressions, and more consistent use of acronyms. I have made a great many example revisions directly into the attached text file, which I hope will receive consideration by the authors. Each editorial comment individually is typically less important than a technical error, but taken together I think they would greatly promote readability and thus increase the likelihood that implementers will be able to understand the intention of the specification. I have also inserted additional comments into the file, tagged by my initials "CEP:". Here are some overall comments. - not-RPL-aware --> RPL-unaware - Raf could be confused as "RPL-aware forwarder". Please change acronyms. One possibility: ~Raf --> RuL, Raf --> RaL (for., "RPL-aware-Leaf", "RPL-unaware-Leaf", respectively) Fixed, to RPL-Unaware-Leaf (RUL) and RPL-Aware-Leaf (RAL) - Since the document already uses acronyms in an essential way, please also use them to improve clarity and shorten subsection titles, etc. Fixed - Captions to figures and subsection titles should typically fit on a single line We tried to fix as much as possible in one line. I would like to verify the design assumptions and design requirements, and then use that knowledge to check the details of each of the 24 use cases. One improvement that would be *very* helpful for this purpose, would be to assert *which* of the design requirements underlies each matrix entry for the 24 summary tables. thank you very much for your hard work on the review =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Some of the use cases here described use IPv6-in-IPv6 encapsulation. Such uses follow RFC6040 [RFC6040] to construct the explicit congestion notification (ECN) field of the IP header upon entry to and exit from any IPV6-in-IPV6 tunnel. [I-D.ietf-intarea-tunnels] is also related. CEP: Should say HOW it is related. Fixed CEP: Note: the following information does NOT belong in Terminology. Fixed, added in a new section RPL defines the RPL Control messages (control plane) as subtypes of ICMPv6 [RFC4443] message Type 155. CEP: Not sure how much this adds to the clarity of the document, but O.K. RPL supports two modes of Downward traffic. In storing mode, CEP: The abbreviations here were never used again and so deleted. Fixed 2. Terminology and Requirements Language Terminology defined in [RFC7102] applies to this document: LBR, LLN, RPL, RPL Domain and ROLL. CEP: Below, it is claimed that LBR is defined in 6775. Fixed Raf: RPL-aware-leaf, i.e., a RPL-aware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG Ruf: RPL-unaware-leaf, i.e., a RPL-unaware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG RPL-aware-node: A device which implements RPL. Such a device can be found inside the LLN or outside LLN. RPL-unaware: A device which does not implement RPL. The device can be found inside the LLN. In this document a RPL-unaware node which is a leaf of a DODAG is called RPL-unaware-leaf (Ruf). Tolerant: able to accept or forward packets with RPL artifacts (whether RPL aware or not) Intolerant: unable to accept or forward packets with RPL artifacts we have fixed the terminology section, but we are unsure about tolerant and intolerant CEP: see below. This terminology isn't needed. Flag Day: A transition that involves having a network with different values of RPL Option Type. Thus the network does not work correctly. We think that the definition is for helping newcomers Non-SM: Non-storing Mode, in which intermediate 6LRs do not maintain routing state so that source routes are needed. SM: Storing Mode, in which intermediate 6LRs maintain routing state so that source routes are not needed. added a definition of NonSM and SM 6LR_i --> ... --> 6LR_i --> root(6LBR) As previously mentioned, 6LRs and 6LBR are always full-fledged RPL routers. CEP: Need definition for full-fledged. Or, better, delete this sentence. deleted Figure 8 summarizes the headers needed for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. CEP: Could use "Encaps" instead of "IP6-IP6" (or "Decaps"). fixed in terminology Figure 8: Storing mode: The use of headers from Ruf to root. [1] Case where the IPv6-in-IPv6 header is addressed to the next hop (Node B). [2] Case where the IPv6-in-IPv6 header is addressed to the root (Node A). CEP: Would be better to put [1] and [2] into footnotes, or else into the body of the text. fixed, included in the text 6.2.1. Storing Mode: from Raf to Internet RPL information from RFC 6553 may go out to Internet as it will be ignored by nodes which have not been configured to be RPI aware. CEP: At least the ones that have been updated to obey the newer specification. fixed, added in assumptions Figure 9 summarizes header processing for this use case. CEP: Each such table should be a Table, not a Figure. In the figure, IP6-IP6 refers to IPv6-in-IPv6. for complex tables we use ascii figure CEP: Should just put IP6-IP6 in Terminology if you're going to use it, to avoid duplication. fixed in terminology The 6LR_1 (i=3D1) node will add an IPv6-in-IPv6(RPI) header addressed either to the root, or hop-by-hop such that the root can remove the RPI header before passing upwards. The IPv6-in-IPv6 addressed to the root cause less processing overhead. On the other hand, with hop-by- hop the intermediate routers can check the routing tables for a better routing path, thus possibly more efficient and faster. Implementation should decide which approach to take. CEP: This should be controlled by a configuration parameter, maybe something like (ENCAPS_TO_ROOT). dont understand The originating node SHOULD leave the IPv6 flow label as zero so that the packet can be better compressed through the LLN. The 6LBR will set the flow label of the packet to a non-zero value when sending to the Internet. CEP: Why? Where is this specified? =E2=80=9Cwe point to RFC8138 for compression and RFC6437 for deta= ils on flow label The final node should be able to remove the IPv6-in-IPv6 headers which are addressed to it. The final node ignores the RPI and does not process it. Further details about this are mentioned in [I-D.thubert-roll-unaware-leaves], which specifies RPL routing for a 6LN acting as a plain host and not aware of RPL. The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to zero in order to aid in compression. CEP: Is this really legitimate? How would the original flow label be restored? It is inside of the LLN, so when adding the IPv6-in-IPv6 header the root can set the flow label of zero, since it is not needed for RPL. An example flow could be: F --> D --> B --> E --> H 6LR_ia (Node D) is an intermediate router from source to the common CEP: Why were the quotes used below? parent (6LR_x) (Node B) In this case, 1 <=3D ia <=3D n, where n is the n= umber of routers (6LR) that the packet traverses from 6LN (Node F) to the common parent (6LR_x). Fixed 6LR_id (Node E) is an intermediate router from the common parent (6LR_x) (Node B) to destination 6LN (Node H). In this case, 1 <=3D id <=3D m, where m is the number of routers (6LR) that the packet traverses from the common parent (6LR_x) to destination 6LN. CEP: The next sentence is implicit in many use cases and belongs elsewhere. It is assumed that the two nodes are in the same RPL Domain (that they share the same DODAG root). At the common parent (Node B), the direction of RPI is changed (from increasing to decreasing the rank). we think that includes clarification for the use case of the common parent 7. Non Storing mode In Non Storing Mode (Non-SM) (source routed), the 6LBR (DODAG root) has complete knowledge about the connectivity of all DODAG nodes, and all traffic traverses the root node. Thus, there is no need for all nodes to know about the existence of RPL-unaware RFC 6550 states: =E2=80=9C 3. In Non-Storing mode, the DODAG root SHOULD = store source routing table entries for destinations learned from DAOs. The DODAG root MUST be able to generate source routes for those destinations learned from DAOs that were stored.=E2=80=9D Based on that we believe that the Root has complete knowledge about connectivity to the nodes. Thank you very very much again, Ines, Michael and Pascal. On Thu, May 30, 2019 at 12:21 AM Charlie Perkins < charles.perkins@earthlink.net> wrote: > > Hello folks, > > Due to a lot of confusion on my end, this IoT-Dir review is very very > late. I hope it will be found to be useful. > > I think the draft needs a bit of work before it can be published. I have > quite a few editorial comments and a couple of important technical concer= ns. > > I started to review revision ...25.txt, but before I could finish that > review, we were already up to revision ...29.txt so I started over with > that revision. Most of these are represented, albeit incompletely, in th= e > attached file. > > My main technical concern has to do with the attempt to classify RPI > Option Types 0x23 and 0x63 as somehow being variants of the same Option > Type. I don't think this is really legitimate; they have to be considere= d > to be two different Options. I believe the idea is that it should be > simple to implement both together, and type 0x23 is likely to survive > traversal of the Internet. An intermediate device that implements 0x63 b= ut > not 0x23 will not process any of the configuration options present in 0x2= 3, > but at least the packet won't be dropped. I'm not sure how serious this > problem is for intermediate 6LRs in the path of a 0x23 packet traversing > the LLN, but those configuration options are meant for consumption by suc= h > intermediate 6LRs. > > One thing that would help, is to include in the overview a very succinct > list of design requirements and also a list of assumptions made during th= e > design. I had wanted to create this list but that would take another day= . > Here is a start, and I hope that any misunderstanding that I have will be > minor: > > Requirements: > > 1. RPI has to be in every packet that traverses the LLN > 2. Because of (1), packets from the Internet have to be encapsulated > 3. Extension headers may not be added or removed except by the sender or > the receiver > 4. Packets that will traverse RPI-unaware nodes need encapsulation, but > only sender or receiver can add the new RPI option (0x23) > 5. Non-storing mode requires downstream encapsulation by root for RH > > Assumptions: > > - Each IPv6 node (including Internet routers) obeys RFC 8200, so that 0x2= 3 > RPI can be safely inserted. > - All 6LRs obey RFC 8200 > > These requirements and assumptions determine the entries in the dozens of > tables included within the document. Without a clear grasp of them, it i= s > easy to get lost in the sea of details about header insertion and > encapsulation. > > Most of my many comments are editorial. I think that the draft could be > easier to read with fewer digressions, and more consistent use of > acronyms. I have made a great many example revisions directly into the > attached text file, which I hope will receive consideration by the > authors. Each editorial comment individually is typically less important > than a technical error, but taken together I think they would greatly > promote readability and thus increase the likelihood that implementers wi= ll > be able to understand the intention of the specification. I have also > inserted additional comments into the file, tagged by my initials "CEP:". > Here are some overall comments. > > > - not-RPL-aware --> RPL-unaware > - Raf could be confused as "RPL-aware forwarder". Please change > acronyms. One possibility: ~Raf --> RuL, Raf --> RaL (for., > "RPL-aware-Leaf", "RPL-unaware-Leaf", respectively) > - Since the document already uses acronyms in an essential way, > please also use them to improve clarity and shorten subsection titles,= etc. > - Captions to figures and subsection titles should typically fit on a > single line > > I would like to verify the design assumptions and design requirements, an= d > then use that knowledge to check the details of each of the 24 use cases. > One improvement that would be *very* helpful for this purpose, would be t= o > assert *which* of the design requirements underlies each matrix entry for > the 24 summary tables. > > Regards, > Charlie P. > > > > > --000000000000766b51058c279ac2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi Charlie,


    Ma= ny=C2=A0 thanks for your review, we really appreciate all your comments and= suggestions to improve the draft. we believe that version 30 addresses you= r concerns.

    Please find answers i= n-line.


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

    My main technical concern has to do w= ith the attempt to classify RPI Option Types 0x23 and 0x63 as somehow being= variants of the same Option Type.=C2=A0 I don't think this is really l= egitimate; they have to be considered to be two different Options. I belie= ve the idea is that it should be simple to implement both together, and typ= e 0x23 is likely to survive traversal of the Internet.=C2=A0 An intermediat= e device that implements 0x63 but not 0x23 will not process any of the conf= iguration options present in 0x23, but at least the packet won't be dro= pped. I'm not sure how serious this problem is for intermediate 6LRs i= n the path of a 0x23 packet traversing the LLN, but those configuration opt= ions are meant for consumption by such intermediate 6LRs.

    =C2=A0=

    <author>

    We believe that is the same Option Type,= with the value updated from 0x63 to 0x23.

    The network would= switch to 0x23 when all the nodes are capable to process it.

    = </author>

    =C2=A0

    One thi= ng that would help, is to include in the overview a very succinct list of d= esign requirements and also a list of assumptions made during the design.= =C2=A0 I had wanted to create this list but that would take another day. H= ere is a start, and I hope that any misunderstanding that I have will be mi= nor:

    Requirements:

    1. RPI has to be in every packet that traverses= the LLN

    2. Because of (1), packe= ts from the Internet have to be encapsulated

    3. Extension headers may not be added or removed except by the = sender or the receiver

    4. Packets= that will traverse RPI-unaware nodes need encapsulation, but only sender o= r receiver can add the new RPI option (0x23)

    5. Non-storing mode requires downstream encapsulation by root f= or RH

    Assumptions:

    - Each IPv6 node (including Internet routers) o= beys RFC 8200, so that 0x23 RPI can be safely inserted.

    - All 6LRs obey RFC 8200

    These requirements and assumptions determine the entries in = the dozens of tables included within the document.=C2=A0 Without a clear gr= asp of them, it is easy to get lost in the sea of details about header inse= rtion and encapsulation.

    =C2=A0

    <author>

    Very good idea, thank you.

    We added a list of Requirements an= d Assumptions.


    Requirements:<= /span>

    1- The RPI option has to be in ev= ery packet that traverses the LLN

    2-. Because of (1), packets from the Internet have to be encapsulated

    3-. A Header cannot be inserted or removed on the fly inside an IPv6 pack= et that is being routed.

    4-- Extension headers may not be added or re= moved except by the sender or the receiver.

    5-- RPI and RH3 headers may be modified by routers on the path = of the packet without the need to add and remove an encapsulating header

    6-- An RH3 or RPI Option can only b= e removed by an intermediate router if it is placed in an encapsulating IPv= 6 Header, which is addressed to the intermediate router.

    =C2=A0=

    =C2=A0

    =C2=A0

    =C2=A0

    .7 Non-st= oring mode requires downstream encapsulation by root for RH3.

    =C2= =A0

    =C2=A0

    Assumptions:

    =C2= =A0

    =C2=A0=C2=A0This document assumes th= at the LLN is using the no-drop RPI option

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(0x23).=C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- Each IPv= 6 node (including Internet routers) obeys [RFC8200]

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A08200, so that 0x23 RPI c= an be safely inserted.=C2=A0

    =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- All 6LRs obey [RFC8200].=C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- The = RPI is ignored at the IPv6 dst node (RPL-unaware-leaf).=C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- The leaf= can be a router 6LR or a host, both indicated as 6LN.=C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- Non-const= rained uses of RPL are not in scope of this document.=C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- Compressio= n is based on [RFC8138].=C2=A0

    = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- The flow label [RFC6437] is not neede= d in RPL.

    =C2=A0

    </author>

    =C2=A0

    =C2=A0=

    =C2=A0

    =C2=A0

    Most of my many com= ments are editorial.=C2=A0 I think that the draft could be easier to read w= ith fewer digressions, and more consistent use of acronyms.=C2=A0 I have ma= de a great many example revisions directly into the attached text file, whi= ch I hope will receive consideration by the authors.=C2=A0 Each editorial c= omment individually is typically less important than a technical error, but= taken together I think they would greatly promote readability and thus in= crease the likelihood that implementers will be able to understand the inte= ntion of the specification. =C2=A0 I have also inserted additional comments= into the file, tagged by my initials "CEP:". Here are some ove= rall comments.

    =C2=A0

    • =C2=A0not-RPL-aware --> RPL-unaware

    • =C2=A0Raf could be confused as "RPL-aware forwarder&qu= ot;. =C2=A0 Please change acronyms. One possibility: ~Raf --> RuL, =C2= =A0 Raf --> RaL (for., "RPL-aware-Leaf", "RPL-unaware-Le= af", respectively)

    <author>

    <= span style=3D"font-size:11pt;font-family:Arial;background-color:transparent= ;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:= baseline;white-space:pre-wrap">Fixed, to RPL-Unaware-Leaf (RUL) and RPL-Awa= re-Leaf (RAL)

    </author>

    • =C2=A0Since the document already u= ses acronyms in an essential way, please also use them to improve clarity a= nd shorten subsection titles, etc.

    <author> Fixed </author>=

    • =C2=A0Ca= ptions to figures and subsection titles should typically fit on a single li= ne

    <author>

    We tried to fix as much as possible in one line.

    &= lt;/author>

    I would like to ve= rify the design assumptions and design requirements, and then use that know= ledge to check the details of each of the 24 use cases.=C2=A0 One improveme= nt that would be *very* helpful for this purpose, would be to assert *which= * of the design requirements underlies each matrix entry for the 24 summary= tables.

    =C2=A0

    <author> thank you very much for your= hard work on the review </author>

    =C2=A0

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


    =C2=A0=C2=A0=C2=A0Some of the use cases here described use= IPv6-in-IPv6

    =C2=A0=C2=A0=C2=A0e= ncapsulation.=C2=A0 Such uses follow RFC6040 [RFC6040] to construct<= /p>

    =C2=A0=C2=A0=C2=A0the explicit congestio= n notification (ECN) field of the IP header upon

    =C2=A0=C2=A0=C2=A0entry to and exit from any IPV6-in-IPV6 t= unnel.

    =C2=A0=C2=A0=C2=A0[I-D.iet= f-intarea-tunnels] is also related.

    CEP: Should say HOW it is related.


    <author> Fixed </author>

    CEP: Note: the following information d= oes NOT belong in Terminology.


    <author> Fixed, added in a new section </aut= hor>


    =C2=A0=C2=A0=C2=A0RPL= defines the RPL Control messages (control plane) as subtypes of

    =

    = =C2=A0=C2=A0=C2=A0ICMPv6 [RFC4443] message = Type 155.=C2=A0=C2=A0


    CEP: No= t sure how much this adds to the clarity of the document, but O.K.

    =C2=A0=C2=A0=C2=A0RPL supports two mo= des of Downward traffic.=C2=A0 In storing mode,

    CEP: The abbreviations here were never used again and so del= eted.


    <author> Fixed </author>

    =C2=A0=C2=A0=C2=A0

    =C2=A0=C2=A0<= /span>

    2.=C2=A0 Terminology and Requirem= ents Language


    =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Terminology defined in [RFC7102] applies to this docum= ent: LBR, LLN,

    =C2=A0=C2=A0=C2=A0= RPL, RPL Domain and ROLL.

    CEP: Be= low, it is claimed that LBR is defined in 6775.


    <auth= or> Fixed </author&g= t;


    =C2=A0=C2=A0=C2=A0Raf: RPL= -aware-leaf, i.e., a RPL-aware-node which is a leaf of a

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(= Destination Oriented Directed Acyclic Graph) DODAG


    =C2=A0=C2=A0=C2=A0Ruf: RPL-unaware-leaf, i.e., a RPL-= unaware-node which is a leaf of a

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(Destination Oriented Dire= cted Acyclic Graph) DODAG


    =C2= =A0=C2=A0=C2=A0RPL-aware-node: A device which implements RPL.=C2=A0 Such a = device can be

    =C2=A0=C2=A0=C2=A0f= ound inside the LLN or outside LLN.


    =C2=A0=C2=A0=C2=A0RPL-unaware: A device which does not implement RPL= .=C2=A0 The device can be

    =C2=A0= =C2=A0=C2=A0found inside the LLN.=C2=A0 In this document a RPL-unaware node= which is a

    =C2=A0=C2=A0=C2=A0lea= f of a DODAG is called RPL-unaware-leaf (Ruf).


    =C2=A0=C2=A0=C2=A0Tolerant: able to accept or forward pac= kets with RPL artifacts

    =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(wheth= er RPL aware or not)


    =C2=A0= =C2=A0=C2=A0Intolerant: unable to accept or forward packets with RPL artifa= cts


    <author> = we have fixed the terminology section, but we are unsure about tolerant and= intolerant </author>


    =C2=A0=C2=A0

    CEP: see be= low.=C2=A0 This terminology isn't needed.


    =C2=A0=C2=A0=C2=A0Flag Day: A transition that involves hav= ing a network with different

    =C2= =A0=C2=A0=C2=A0values of RPL Option Type.=C2=A0 Thus the network does not w= ork correctly.


    =C2=A0=C2=A0<author> We think that= the definition is for helping newcomers </author>

    =C2=A0=C2=A0=C2=A0Non-SM: Non-sto= ring Mode, in which intermediate 6LRs do not maintain

    =C2=A0=C2=A0=C2=A0routing state so that source routes = are needed.


    =C2=A0=C2=A0=C2= =A0SM: Storing Mode, in which intermediate 6LRs maintain routing

    =

    = =C2=A0=C2=A0=C2=A0state so that source rout= es are not needed.


    =C2=A0<author> added a definit= ion of NonSM and SM</author>



    <!--CEP: IPv6 defines the Option Type as the entire= octet.=C2=A0 Thus, changing

    =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0the first two bits means that this document is d= efining a NEW

    =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0Option Type.=C2=A0 As a result, this document does NOT update R= FC 6553.=C2=A0 -->


    <author>

    We belie= ve that is the same Option Type, with the value updated from 0x63 to 0x23.<= /span>

    The network would switch to 0x23 when all the nodes are capabl= e to process it.

    </author>


    =C2=A0=C2=A0=C2=A00x63 as the RPI value.=C2=A0 A move to 0= x23 will not be understood by

    =C2= =A0=C2=A0=C2=A0those networks.=C2=A0 It is suggested that implementations a= ccept both

    =C2=A0=C2=A0=C2=A00x63= and 0x23 when processing.

    CEP: W= hich implementations?=C2=A0 What processing?


    <author>= ; Fixed </author>



    =C2=A0=C2=A0=C2=A0When forw= arding packets, implementations MUST use the same value as

    =C2=A0=C2=A0=C2=A0was received (the RPI type code= MUST remain unchanged [RFC8200]).

    =C2=A0=C2=A0=C2=A0This allows incremental upgrades to the network, and al= lows the

    =C2=A0=C2=A0=C2=A0DODAG = root to know which parts of the network are upgraded.

    CEP: Should xref the part of the document which explai= ns this

    =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0in more detail.


    <author> Fixed </author>


    =C2=A0=C2=A0=C2=A0When originating new packets, implem= entations SHOULD be configured

    = =C2=A0=C2=A0=C2=A0for which RPI Option to use.=C2=A0 This configuration is = controlled

    =C2=A0=C2=A0=C2=A0by a= new flag in the DIO Configuration Option as described below.

    =C2=A0=C2=A0=C2=A0A network which is switc= hing from 6lowpan compression [RFCnnnn]

    =C2=A0=C2=A0=C2=A0to that described in [RFC8138] will experience a f= lag day

    =C2=A0=C2=A0=C2=A0in the = data compression anyway, and if possible this change can be

    =C2=A0=C2=A0=C2=A0deployed at the same time.

    CEP: Devices in such a network could= accept both types of compression.


    <author> <= span style=3D"font-size:11pt;font-family:Arial;background-color:transparent= ;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:= baseline;white-space:pre-wrap">not applicable=C2=A0 </author&g= t;


    =C2=A0=C2=A0=C2=A0By using= RPI option type 0x23 instead of 0x63, [RFC8200] Section 4.2

    =C2=A0=C2=A0=C2=A0compliant nodes become tolera= nt of RPL artifacts.=C2=A0 There is

    =C2=A0=C2=A0=C2=A0therefore no longer a necessity to remove the artifact= s when sending

    =C2=A0=C2=A0=C2=A0= traffic to the Internet.=C2=A0 This document clarifies when to use an IPv6-=

    =C2=A0=C2=A0=C2=A0in-IPv6 header= , and what IPv6 addresses to use.=C2=A0 The Hop-by-Hop Options

    =C2=A0=C2=A0=C2=A0Header containing the RPI o= ption MUST always be added when 6LRs

    =C2=A0=C2=A0=C2=A0originate packets without IPv6-in-IPv6 headers.=C2=A0= IPv6-in-IPv6

    =C2=A0=C2=A0=C2=A0h= eaders MUST always be added when a 6LR needs to insert

    =C2=A0=C2=A0=C2=A0a Hop-by-Hop Options Header contain= ing the RPI option.

    =C2=A0=C2=A0= =C2=A0The IPv6-in-IPv6 header is addressed to the RPL root when on the way = up,

    =C2=A0=C2=A0=C2=A0and to the = end-host when on the way down.


    CEP: The following paragraph belongs MUCH earlier in the document, probab= ly

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= in the overview or else a new section entitled "Applicability"

    =C2=A0=C2=A0=C2=A0Non-constrained u= ses of RPL are not in scope of this document, and

    =C2=A0=C2=A0=C2=A0applicability statements for those uses = may provide different advice,

    =C2= =A0=C2=A0=C2=A0E.g.=C2=A0 [I-D.ietf-anima-autonomic-control-plane].<= /p>

    <author> Fixed, move= d to Introduction=C2=A0 </author>



    3.2.=C2=A0 Updates to RFC6550: DODAG Configuratio= n Option Flag for new RPI.


    CE= P: I don't think the document really needs to discuss "Flag Days&q= uot;.

    =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0It is *especially* unfortunate in sentences such as the next sentence

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0where= a "flag" is defined to avoid a "flag day".=C2=A0 The d= ocument

    =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0would be better simply mentioning "lack of interoperation" = instead.


    <author> We define a flag day as a lack of = interoperation </author= >


    =C2=A0=C2=A0=C2=A0In ord= er to avoid a Flag Day caused by lack of interoperation between

    <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial;background-color:transparent= ;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:= baseline;white-space:pre-wrap">=C2=A0=C2=A0=C2=A0new RPI (0x23) and old RPI= (0x63) nodes, this section defines a DODAG

    =C2=A0=C2=A0=C2=A0Configuration Option flag

    =C2=A0=C2=A0=C2=A0in the DIO Configuration Option, t= o indicate when then new RPI option

    =C2=A0=C2=A0=C2=A0can be safely used. =C2=A0 RPL-capable nodes then

    =C2=A0=C2=A0=C2=A0know if it is safe = to use 0x23 when creating a new RPI.=C2=A0 A node that

    =C2=A0=C2=A0=C2=A0forwards a packet with an RPI MUST = NOT modify the option type of the

    =C2=A0=C2=A0=C2=A0RPI.=C2=A0 If the DODAG Configuration Option flag is rec= eived with a value

    =C2=A0=C2=A0= =C2=A0zero (which is the default), then new nodes will remain in RFC6553

    =C2=A0=C2=A0=C2=A0Compatible Mode, = and originate traffic with the old-RPI (0x63) value.


    =C2=A0=C2=A0=C2=A04.=C2=A0 Sample/reference topol= ogy


    =C2=A0=C2=A0=C2=A0A RPL n= etwork is typically composed of a 6LBR (6LoWPAN Border

    =C2=A0=C2=A0=C2=A0Router), Backbone Router (6BBR), 6L= R (6LoWPAN Router) and 6LNs

    =C2= =A0=C2=A0=C2=A0(6LoWPAN Nodes) leaves logically organized in a DODAG struct= ure.

    CEP: Already defined these i= n Terminology.



    <author> Fixed=C2=A0 </author>


    =C2=A0=C2=A05.=C2=A0 Use cases


    =C2=A0=C2=A0=C2=A0In the data plane a combinati= on of RFC6553, RFC6554 and IPv6-in-IPv6

    =C2=A0=C2=A0=C2=A0encapsulation are analyzed for a number of represe= ntative traffic flows.

    =C2=A0=C2= =A0=C2=A0The use cases describe the communication in the following cases:

    =C2=A0=C2=A0=C2=A0- between RPL-aw= are-nodes with the root (6LBR)

    = =C2=A0=C2=A0=C2=A0- between RPL-aware-nodes with the Internet

    =C2=A0=C2=A0=C2=A0- between Ruf nodes within t= he LLN (e.g. see Section 6.1.4)

    = =C2=A0=C2=A0=C2=A0- inside of the LLN when the final destination address re= sides outside

    =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0of the LLN (e.g. see Section 6.2.3).

    =C2=A0=C2=A0=C2=A0The use cases are as follows:

    <= br>

    <author> Many thanks for= this text improvements=C2=A0 </author>


    =C2=A0=C2=A0

    =C2=A0In this specification, an RH3 or RPI Option can only be remove= d by an

    =C2=A0=C2=A0=C2=A0interme= diate router if it is placed in an encapsulating IPv6 Header

    =C2=A0=C2=A0=C2=A0addressed to the intermediate= router.=C2=A0 If so, the whole encapsulating header

    =C2=A0=C2=A0=C2=A0must be also removed, but a replacem= ent may be added.=C2=A0 Sometimes the outer

    =C2=A0=C2=A0=C2=A0IP headers being addressed to the next hop ro= uter use

    =C2=A0=C2=A0=C2=A0link-l= ocal addresses.

    CEP: Maybe this s= hould ALWAYS be the case, since it's only for a single hop.

    <= br>

    <author> we added as req= uirement=C2=A0 </author>


    =C2=A0=C2=A0=C2=A0

    6.= 1.1.=C2=A0 Storing Mode: from Raf to root


    =C2=A0=C2=A0=C2=A0In storing mode, RFC 6553 (RPI) is used to s= end RPL Information

    =C2=A0=C2=A0= =C2=A0instanceID and rank information.





    CEP: Should probably delete the following paragraph.= =C2=A0 It is not germane

    =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0to the subject of this section.

    =C2=A0=C2=A0=C2=A0As stated in Section 16.2 of [RFC6= 550] a Raf node does not

    =C2=A0= =C2=A0=C2=A0generally issue DIO messages; a leaf node accepts DIO messages = from

    =C2=A0=C2=A0=C2=A0upstream.= =C2=A0 (When the inconsistency in routing occurs, a leaf node

    =C2=A0=C2=A0=C2=A0will generate a DIO with an = infinite rank, to fix it).=C2=A0 It may issue

    =C2=A0=C2=A0=C2=A0DAO and DIS messages though it generally ign= ores DAO and DIS

    =C2=A0=C2=A0=C2= =A0Messages.


    <author> deleted </author>


    =C2=A0=C2=A0=C2=A0In this case the communication flow is as f= ollows:


    =C2=A0=C2=A0=C2=A0Raf= --> 6LR_i --> ... --> 6LR_i --> root(6LBR)


    =C2=A0=C2=A0=C2=A0As previously mentioned, 6LRs = and 6LBR are always full-fledged RPL routers.

    CEP: Need definition for full-fledged.=C2=A0 Or, better, delet= e this sentence.


    <author> deleted </author>


    =C2=A0=C2=A0=C2=A0

    =C2=A0=C2=A0=C2=A0Figure 8 summarizes the headers needed

    =C2=A0=C2=A0=C2=A0for this use case.=C2=A0 In t= he figure, IP6-IP6 refers to IPv6-in-IPv6.

    CEP: Could use "Encaps" instead of "IP6-IP6"= ; (or "Decaps").


    <author> fixed in terminology </author>




    =C2=A0=C2=A0=C2=A0=C2=A0Fi= gure 8: Storing mode: The use of headers from Ruf

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0to root.=C2=A0 [1] Cas= e where the IPv6-in-IPv6 header is

    =C2=A0=C2=A0=C2=A0=C2=A0addressed to the next hop (Node B). [2] Case wher= e the IPv6-in-IPv6

    =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0header is addressed to the root (Node A).

    CEP: Would be better to put [1] and [2] into foot= notes, or else into

    =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0the body of the text.


    <author> fixed, included in the text = </author>



    6.2.1.=C2= =A0 Storing Mode: from Raf to Internet


    =C2=A0=C2=A0=C2=A0RPL information from RFC 6553 may go out to I= nternet as it will be

    =C2=A0=C2= =A0=C2=A0ignored by nodes which have not been configured to be RPI aware.

    CEP: At least the ones that have b= een updated to obey the newer specification.


    <author>= ; fixed, added in assumptions </author>



    =C2= =A0=C2=A0=C2=A0Figure 9 summarizes header processing for this use case.

    CEP: Each such table should be a Tab= le, not a Figure.

    =C2=A0=C2=A0=C2= =A0In the figure, IP6-IP6 refers to IPv6-in-IPv6.


    <auth= or> for complex tables we use asc= ii=C2=A0 figure </author>


    CEP: Should just put IP6-IP6 in Terminology if you're goin= g to use it, to

    =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0avoid duplication.

    <author> fixed in terminology </author>


    =C2=A0=C2=A0=C2=A0The 6LR_1 (i= =3D1) node will add an IPv6-in-IPv6(RPI) header addressed

    =C2=A0=C2=A0=C2=A0either to the root, or hop-by-h= op such that the root can remove the

    =C2=A0=C2=A0=C2=A0RPI header before passing upwards.=C2=A0 The IPv6-in-= IPv6 addressed to the

    =C2=A0=C2= =A0=C2=A0root cause less processing overhead.=C2=A0 On the other hand, with= hop-by-

    =C2=A0=C2=A0=C2=A0hop th= e intermediate routers can check the routing tables for a

    =C2=A0=C2=A0=C2=A0better routing path, thus possi= bly more efficient and faster.

    = =C2=A0=C2=A0=C2=A0Implementation should decide which approach to take.

    CEP: This should be controlled by a c= onfiguration parameter,

    =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0maybe something like (ENCAPS_TO_ROOT).


    <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial;font-variant-numeric:normal;= font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap= "><author> dont understand     </author>


    =C2=A0= =C2=A0=C2=A0The originating node SHOULD leave the IPv6 flow label as zero

    =C2=A0=C2=A0=C2=A0so that the pack= et can be better compressed through the LLN.=C2=A0 The

    =C2=A0=C2=A0=C2=A06LBR will set the flow label of the= packet to a non-zero value when

    = =C2=A0=C2=A0=C2=A0sending to the Internet.

    CEP: Why?=C2=A0 Where is this specified?


    <= ;author> =E2=80=9Cwe point to RFC= 8138 for compression=C2=A0 and RFC6437 for details on flow label = </author>



    =C2=A0=C2= =A0=C2=A0The final node should be able to remove the IPv6-in-IPv6

    =C2=A0=C2=A0=C2=A0headers which are addres= sed to it.=C2=A0 The final node ignores the

    =C2=A0=C2=A0=C2=A0RPI and does not process it.=C2=A0 Further de= tails about

    =C2=A0=C2=A0=C2=A0thi= s are mentioned in [I-D.thubert-roll-unaware-leaves], which

    =C2=A0=C2=A0=C2=A0specifies RPL routing for a 6L= N acting as a plain host and not aware

    =C2=A0=C2=A0=C2=A0of RPL.


    =C2=A0=C2=A0=C2=A0The 6LBR may set the flow label on the inner IPv6-in-I= Pv6 header to

    =C2=A0=C2=A0=C2=A0z= ero in order to aid in compression.

    CEP: Is this really legitimate?=C2=A0 How would the original flow label<= /span>

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0be = restored?


    <author>=C2=A0

    It is inside o= f the LLN, so when adding the IPv6-in-IPv6 header the root can set the flow= label of zero, since it is not needed for RPL.=C2=A0


    <= ;/author>



    =C2=A0=C2=A0= =C2=A0An example flow could be: F --> D --> B --> E --> H


    =C2=A0=C2=A0=C2=A06LR_ia (Node D) = is an intermediate router from source to the common

    CEP: Why were the quotes used below?

    =C2=A0=C2=A0=C2=A0parent (6LR_x) (Node B) In this= case, 1 <=3D ia <=3D n, where n is the number

    =C2=A0=C2=A0=C2=A0of routers (6LR) that the packet tra= verses from 6LN (Node F) to

    =C2= =A0=C2=A0=C2=A0the common parent (6LR_x).


    <author> F= ixed </author>


    =C2=A0= =C2=A0=C2=A06LR_id (Node E) is an intermediate router from the common paren= t

    =C2=A0=C2=A0=C2=A0(6LR_x) (Node= B) to destination 6LN (Node H).=C2=A0 In this case, 1 <=3D id

    =C2=A0=C2=A0=C2=A0<=3D m, where m is th= e number of routers (6LR) that the packet traverses

    =C2=A0=C2=A0=C2=A0from the common parent (6LR_x) to de= stination 6LN.


    CEP: The next = sentence is implicit in many use cases and belongs elsewhere.

    =C2=A0=C2=A0It is assumed that the two nodes a= re in the same RPL Domain (that

    = =C2=A0=C2=A0=C2=A0they share the same DODAG root).=C2=A0 At the common pare= nt (Node B), the

    =C2=A0=C2=A0=C2= =A0direction of RPI is changed (from increasing to decreasing the rank).


    <author> we think that includes clarification for the = use case of the common parent </author>


    7.=C2=A0 Non Storing mode


    <CEP: The first sentence is not true in the case where nod= es have neighbors

    =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0at the same depth.=C2=A0 The root does not necessarily= know about that. CEP>

    =C2=A0= =C2=A0=C2=A0In Non Storing Mode (Non-SM) (source routed), the 6LBR (DODAG

    =C2=A0=C2=A0=C2=A0root) has comple= te knowledge about the connectivity of all DODAG

    =C2=A0=C2=A0=C2=A0nodes, and all traffic traverses the root= node.=C2=A0 Thus, there is

    =C2= =A0=C2=A0=C2=A0no need for all nodes to know about the existence of RPL-una= ware


    <author>

    RFC 6550 states: =E2=80=9C=C2=A0 3.=C2=A0 In Non-Storing mode, the DODAG root = SHOULD store source routing

    =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0table entries for destinations learn= ed from DAOs.=C2=A0 The DODAG root

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0MUST be able to generate source= routes for those destinations

    = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0learned from DAOs that were store= d.=E2=80=9D

    Based on that we believe that the Root has complete knowl= edge about connectivity to the nodes.

    </author>



    Than= k you very very much again,


    I= nes, Michael and Pascal.



    = On Thu, May 30, 2019 at 12:21 AM Charlie Perkins <charles.perkins@earthlink.net> wrote:
    =
    =20 =20 =20


    Hello folks,

    Due to a lot of confusion on my end, this Io= T-Dir review is very very late.=C2=A0 I hope it will be found to be useful.

    I think the draft needs a bit of work before= it can be published.=C2=A0 I have quite a few editorial comments and a couple o= f important technical concerns.

    I started to review revision ...25.txt, but = before I could finish that review, we were already up to revision ...29.txt so I started over with that revision.=C2=A0 Most of these are represented, albeit incompletely, in the attached file.

    My main technical concern has to do with the= attempt to classify RPI Option Types 0x23 and 0x63 as somehow being variants of the same Option Type.=C2=A0 I don't think this is really legitimate; = they have to be considered to be two different Options.=C2=A0 I believe th= e idea is that it should be simple to implement both together, and type 0x23 is likely to survive traversal of the Internet.=C2=A0 An intermediate device that implements 0x63 but not 0x23 will not process any of the configuration options present in 0x23, but at least the packet won't be dropped.=C2=A0 I'm not sure how ser= ious this problem is for intermediate 6LRs in the path of a 0x23 packet traversing the LLN, but those configuration options are meant for consumption by such intermediate 6LRs.

    One thing that would help, is to include in = the overview a very succinct list of design requirements and also a list of assumptions made during the design.=C2=A0 I had wanted to create this list but that would take another day.=C2=A0 Here is a start, and I ho= pe that any misunderstanding that I have will be minor:

    Requirements:

    1. RPI has to be in every packet that traver= ses the LLN
    2. Because of (1), packets from the Internet have to be encapsulated
    3. Extension headers may not be added or removed except by the sender or the receiver
    4. Packets that will traverse RPI-unaware nodes need encapsulation, but only sender or receiver can add the new RPI option (0x23)
    5. Non-storing mode requires downstream encapsulation by root for RH

    Assumptions:

    - Each IPv6 node (including Internet routers= ) obeys RFC 8200, so that 0x23 RPI can be safely inserted.
    - All 6LRs obey RFC 8200

    These requirements and assumptions determine= the entries in the dozens of tables included within the document.=C2=A0 Without a clear grasp of them, it is easy to get lost in the sea of details about header insertion and encapsulation.

    Most of my many comments are editorial.=C2= =A0 I think that the draft could be easier to read with fewer digressions, and more consistent use of acronyms.=C2=A0 I have made a great many example revisions directly into the attached text file, which I hope will receive consideration by the authors.=C2=A0 Each editorial comment individually is typically less important than a technical error, but taken together I think they would greatly=C2=A0 promote readabili= ty and thus increase the likelihood that implementers will be able to understand the intention of the specification.=C2=A0=C2=A0 I have als= o inserted additional comments into the file, tagged by my initials "CEP:".=C2=A0=C2=A0 Here are some overall comments.

    • =C2=A0not-RPL-aware --> RPL-unaware
    • =C2=A0Raf could be confused as "RPL-= aware forwarder". =C2=A0 Please change acronyms.=C2=A0 One possibility: ~Raf --> RuL,=C2=A0=C2= =A0 Raf --> RaL=C2=A0 (for., "RPL-aware-Leaf", "RPL-unaware-Leaf= ", respectively)
    • =C2=A0Since the document already uses acr= onyms in an essential way, please also use them to improve clarity and shorten subsection titles, etc.
    • =C2=A0Captions to figures and subsection = titles should typically fit on a single line

    I would like to verify the design assumption= s and design requirements, and then use that knowledge to check the details of each of the 24 use cases.=C2=A0 One improvement that would be *very* helpful for this purpose, would be to assert *which* of the design requirements underlies each matrix entry for the 24 summary tables.

    Regards,
    Charlie P.




    --000000000000766b51058c279ac2-- From nobody Tue Jun 25 08:46:00 2019 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 0745E120662; Tue, 25 Jun 2019 08:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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, 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 5A9_dJ0mPzZH; Tue, 25 Jun 2019 08:45:47 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF8A12065B; Tue, 25 Jun 2019 08:45:47 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5PFjdoe012623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jun 2019 11:45:41 -0400 Date: Tue, 25 Jun 2019 10:45:38 -0500 From: Benjamin Kaduk To: Ines Robles Cc: The IESG , draft-ietf-roll-useofrplinfo@ietf.org, Peter Van der Stok , Alvaro Retana , roll-chairs , roll Message-ID: <20190625154538.GP48838@kduck.mit.edu> References: <155893122016.5649.5181856210255754201.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-29: (with COMMENT) 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 Jun 2019 15:45:50 -0000 On Tue, Jun 25, 2019 at 06:15:35PM +0300, Ines Robles wrote: > Hi Benjamin, > > Many thanks for your new review, we believe that version 30 addresses your > concerns. Please find comments in-line > > > On Mon, May 27, 2019 at 7:27 AM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you for addressing my Discuss (and Comment) points! > > > > I just have a few more minor notes on the -29: > > > > the "(1)" footnote is no longer present. > > > > > > Yes, it was deleted. Because the field in the table was “No” before > (version 25), so we put the footnote to indicate that for 6tisch could be > relevant. but since we made RPI mandatory, it is a yes, so no need the > footnote. Anyway we mention the relevance of this case for 6tisch networks. > We added the explanation in the text. I am not 100% sure, but I think I was just noting that Figure 14 still had "(1)" in the RPI column for one row, that may have been an editorial oversight. Thanks for all the updates! -Ben > “In the Figure the (1) indicates a 6tisch case [RFC8180 > ], > > where the RPI header may still be needed for the instanceID to be > > available for priority/channel selection at each hop” > > > > > > > > > I'm also not sure about the global change from "_i are the > > intermediate routers" to "_i is the intermediate router", since the > > general case can still have more than one intermediate in each > > direction. But perhaps we should leave this to the RFC Editor. > > > > > > We changed back to “are the intermediate routers”. Yes Editor can confirm > that. > > > > > > > > > Section 11 > > > > nit: "especially if the target of the attack is targeting another LLN" > > had redudant "target" added -- just "especially if attack is targeting > > another LLN" would be fine. > > > > > > Fixed, thank you > > > > > > > > > I think the claim that "[i]n the end, the IPsec tunnels would be > > providing only BCP38-like origin authentication!" could use some > > additional justifcation. > > > > answered it in a previous email > > Thank you very much, > > Ines, Michael and Pascal From nobody Tue Jun 25 08:49:13 2019 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 F0A991206AA; Tue, 25 Jun 2019 08:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 BHUJRISeu1_v; Tue, 25 Jun 2019 08:49:02 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 5829E120372; Tue, 25 Jun 2019 08:49:02 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id n5so1972678ioc.7; Tue, 25 Jun 2019 08:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OR/2PO+a+2lHms172r7hDNLEMXeO2x3Ki9fj5F1ww/o=; b=L7kHLHmpolUhL4ZyIRTMGvb/Pje//sk74JMiacBjdU9oj6sHMwiuD4UziiZJitPyu6 8Prpntp08IjytdZcHm3eygraHVsqgSbf7WAE6h6JW0c6jincihaDAyKAuFRZ7amGS1AU WBuf7+c48VBNR752UjJm/2YgI5PmwGu5Btj1RU+m+BkgBH81JlDWfLluwj9jvE7ZnC4e zbpbJU3VB73xvrK4Acpnf1XkvQlseceDG2GQOe/TISrmfxfSsDV45FRLF1edpJ04uiec tlLhsi5ZWWXhXlaL+6+u0c57PQmWA7RByLkCuTcI0SusNUOkVfKhFCdjG0eKQhU++JBa z3AQ== 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=OR/2PO+a+2lHms172r7hDNLEMXeO2x3Ki9fj5F1ww/o=; b=XHE/E6Al5o5AQNvw7wbAS1T293YFBJnzgjvAsZcAlpZmodVCSYzNRA9Ahqn0ftyikB 3AK9KzbTtT8TXsI97t6TyXAq2n48cvDP8JSJVyL2Z3+OsBvd8Xfv2a5gSouTOwZCd92k 9A2lz6GYmxUaBToOsPiizTpHgBRIs0QECNZuiWds7vMlQTIZJkBYfyE03jWMaixx39bc vJMmKX1h4Qo37HP3tlT6vDGDm6CAKRQEjBqdjyyiU1TpI3/q7nxFhRImlHTgn1M2JGbD ANSTTAtEtE8FqtKRyq9JmdpdDOL14TuvbRI/F6jrjI9tpVRIr4YAksBAP7nvXoeuUTI9 ssKQ== X-Gm-Message-State: APjAAAWkvSbTjCqumw+La5PMO2eN1fkSRQEFnt6coOeRZTEuNgZIJD0d qk7PaxJ1rf5TUyVax4dU3d8wwYUTQGBoVZ/1qJk= X-Google-Smtp-Source: APXvYqwiv/+6MIliTehABgFpCRF8R1E4WATBkNbqqXIlbgGqkf1q03LsbqeyAVAnxouOzdf//NB//gtMz9hWVBESdU8= X-Received: by 2002:a6b:7d49:: with SMTP id d9mr5954104ioq.50.1561477741542; Tue, 25 Jun 2019 08:49:01 -0700 (PDT) MIME-Version: 1.0 References: <155893122016.5649.5181856210255754201.idtracker@ietfa.amsl.com> <20190625154538.GP48838@kduck.mit.edu> In-Reply-To: <20190625154538.GP48838@kduck.mit.edu> From: Ines Robles Date: Tue, 25 Jun 2019 18:48:49 +0300 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-roll-useofrplinfo@ietf.org, Peter Van der Stok , Alvaro Retana , roll-chairs , roll Content-Type: multipart/alternative; boundary="0000000000001c0033058c27de38" Archived-At: Subject: Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-29: (with COMMENT) 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 Jun 2019 15:49:05 -0000 --0000000000001c0033058c27de38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Benjamin, Thank you very much. Yes, you are correct. we left the (1) to indicate the 6tisch case. Cheers, Ines On Tue, Jun 25, 2019 at 6:45 PM Benjamin Kaduk wrote: > On Tue, Jun 25, 2019 at 06:15:35PM +0300, Ines Robles wrote: > > Hi Benjamin, > > > > Many thanks for your new review, we believe that version 30 addresses > your > > concerns. Please find comments in-line > > > > > > On Mon, May 27, 2019 at 7:27 AM Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > Thank you for addressing my Discuss (and Comment) points! > > > > > > I just have a few more minor notes on the -29: > > > > > > the "(1)" footnote is no longer present. > > > > > > > > > > > Yes, it was deleted. Because the field in the table was =E2=80=9CNo=E2= =80=9D before > > (version 25), so we put the footnote to indicate that for 6tisch could = be > > relevant. but since we made RPI mandatory, it is a yes, so no need the > > footnote. Anyway we mention the relevance of this case for 6tisch > networks. > > We added the explanation in the text. > > I am not 100% sure, but I think I was just noting that Figure 14 still ha= d > "(1)" in the RPI column for one row, that may have been an editorial > oversight. > > Thanks for all the updates! > > -Ben > > > =E2=80=9CIn the Figure the (1) indicates a 6tisch case [RFC8180 > > ], > > > > where the RPI header may still be needed for the instanceID to be > > > > available for priority/channel selection at each hop=E2=80=9D > > > > > > > > > > > > > > > > I'm also not sure about the global change from "_i are the > > > intermediate routers" to "_i is the intermediate router", since > the > > > general case can still have more than one intermediate in each > > > direction. But perhaps we should leave this to the RFC Editor. > > > > > > > > > > > We changed back to =E2=80=9Care the intermediate routers=E2=80=9D. Yes = Editor can confirm > > that. > > > > > > > > > > > > > > > > Section 11 > > > > > > nit: "especially if the target of the attack is targeting another LLN= " > > > had redudant "target" added -- just "especially if attack is targetin= g > > > another LLN" would be fine. > > > > > > > > > > > Fixed, thank you > > > > > > > > > > > > > > > > I think the claim that "[i]n the end, the IPsec tunnels would be > > > providing only BCP38-like origin authentication!" could use some > > > additional justifcation. > > > > > > answered it in a previous email > > > > Thank you very much, > > > > Ines, Michael and Pascal > --0000000000001c0033058c27de38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi=C2=A0Benjamin,

    Thank you very much. = Yes, you are=C2=A0correct. we left the (1) to indicate the 6tisch case.

    Cheers,

    Ines

    =
    On Tue, Ju= n 25, 2019 at 6:45 PM Benjamin Kaduk <k= aduk@mit.edu> wrote:
    On Tue, Jun 25, 2019 at 06:15:35PM +0300, Ines Robles wrote: > Hi Benjamin,
    >
    > Many thanks for your new review, we believe that version 30 addresses = your
    > concerns. Please find comments in-line
    >
    >
    > On Mon, May 27, 2019 at 7:27 AM Benjamin Kaduk via Datatracker < > noreply@ietf.org= > wrote:
    >
    > > -----------------------------------------------------------------= -----
    > > COMMENT:
    > > -----------------------------------------------------------------= -----
    > >
    > > Thank you for addressing my Discuss (and Comment) points!
    > >
    > > I just have a few more minor notes on the -29:
    > >
    > > the "(1)" footnote is no longer present.
    > >
    >
    > <author>
    >
    > Yes, it was deleted. Because the field in the table=C2=A0 was =E2=80= =9CNo=E2=80=9D before
    > (version 25), so we put the footnote to indicate that for 6tisch could= be
    > relevant. but since we made RPI mandatory, it is a yes, so no need the=
    > footnote. Anyway we mention the relevance of this case for 6tisch netw= orks.
    > We added the explanation in the text.

    I am not 100% sure, but I think I was just noting that Figure 14 still had<= br> "(1)" in the RPI column for one row, that may have been an editor= ial
    oversight.

    Thanks for all the updates!

    -Ben

    > =E2=80=9CIn the Figure the (1) indicates a 6tisch case [RFC8180
    > <https://tools.ietf.org/html/rfc8180>],
    >
    >=C2=A0 =C2=A0 where the RPI header may still be needed for the instance= ID to be
    >
    >=C2=A0 =C2=A0 available for priority/channel selection at each hop=E2= =80=9D
    >
    > </author>
    >
    >
    >
    > >
    > > I'm also not sure about the global change from "<foo&= gt;_i are the
    > > intermediate routers" to "<foo>_i is the intermed= iate router", since the
    > > general case can still have more than one intermediate in each > > direction.=C2=A0 But perhaps we should leave this to the RFC Edit= or.
    > >
    >
    > <author>
    >
    > We changed back to =E2=80=9Care the intermediate routers=E2=80=9D. Yes= Editor can confirm
    > that.
    >
    > </author>
    >
    >
    >
    > >
    > > Section 11
    > >
    > > nit: "especially if the target of the attack is targeting an= other LLN"
    > > had redudant "target" added -- just "especially if= attack is targeting
    > > another LLN" would be fine.
    > >
    >
    > <author>
    >
    > Fixed, thank you
    >
    > </author>
    >
    >
    >
    > >
    > > I think the claim that "[i]n the end, the IPsec tunnels woul= d be
    > > providing only BCP38-like origin authentication!" could use = some
    > > additional justifcation.
    > >
    > > <author> answered it in a previous email </author> >
    > Thank you very much,
    >
    > Ines, Michael and Pascal
    --0000000000001c0033058c27de38-- From nobody Tue Jun 25 10:15:03 2019 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 02526120143; Tue, 25 Jun 2019 10:14:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, consultancy@vanderstok.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156148288899.31109.1545890009202623647.idtracker@ietfa.amsl.com> Date: Tue, 25 Jun 2019 10:14:48 -0700 Archived-At: Subject: [Roll] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?roll-efficient-npdao-12=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 25 Jun 2019 17:14:49 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-roll-efficient-npdao-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a small discuss that should be easy to address: Sec 4.3: " The number of retries are implementation and deployment dependent." (and also sec 4.4 point 6) Please specify a maximum number of retries and also a minimum retry interval (of e.g. 3 sec best with exponential back-off)! ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One question on section 4.6.2: You present use of NPDAO and DCO as two options, however, the problem with the I flag is that the sender does not know if the ancestor understand the signal. Wouldn't it also make sense to use both in some cases, e.g. send DAO with I flag first and if you don't receive a DCO after some limited time, you also send the NPDAO? Nits: sec 1.2: s/so that the node changing it routing adjacencies/so that the node changing its routing adjacencies/ -> "it" instead of "its" From nobody Tue Jun 25 10:39:39 2019 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 2868D120A02; Tue, 25 Jun 2019 10:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 LvbcHAnMVYIc; Tue, 25 Jun 2019 10:39:30 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 5C112120A0C; Tue, 25 Jun 2019 10:39:30 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id i11so28356182edq.0; Tue, 25 Jun 2019 10:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=1p9rJS3rZwjNfL+DYBi9NkG70jLcNDQmECMishNiuNs=; b=edk8qkZPJeQiexQaOwcmYe8Z2I6j+0g9v958sCn7kCIIzXDptZbaCCFel5pxcfEHje 1VSqwnShPnALzoPODvx4dpTd4okFdq7F5RMffiMC/e2VZLeUHNZ1mu2ECPJGpH2gJOcw JlbAwFKSBzplIDJxWBZm6SzcAlMg8avKJHqrbF0+TeFE9lINO/PJHfd9Ior00V3fpSvT 6E3zebtv9rKCUER3yjpRHTfAG/K+DBz8l7W1u2puJzx6L3iiHjXhYO8/Z7DPZ3SOua6V TtDdAHt6ndPfEirUwIXohcruTVQ2AIO5J9C7P7BqVBePGngmQj6Lk4K7pvOHoAoRF+MH K0kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=1p9rJS3rZwjNfL+DYBi9NkG70jLcNDQmECMishNiuNs=; b=B10hip/UGxv0VNRbOFNlejRTqYMRMseg6W39k5rWEJToqRjwhktvNt2u43RFatdy4g SlS4/IHw17EmUg15+iOo1TPca0a++wiDkH8f2OQg3yWzqBt9IGNiHYyvRaErotRQ2qXR 4uc10abpmn+TEXzzKHO5bVke3NGl2Ll/CChcdpqk2Ii54ahvVnP77kKbf5Bl5rhMMyYf OCe3sBHp8FunzMOJjBFplpnaIArMTS7uzJBVN9YP2PNkEctiw4KlIo4wsKvcq4/LP7S3 b/4rAtzaJKon9NoEetTTUEehuXKiWZe2FgDASR3HS1Frgr6FGMd7dBYyKiebS4619MrI SysQ== X-Gm-Message-State: APjAAAUgom7byhlAnlaPjATZD3JqmCetnH+cwyAuW6lEyrlTtrXnUtzo c5KF45MNrY4LsrpMptuHTr6Q/xek+2vZelUFNk4= X-Google-Smtp-Source: APXvYqxmTkdlO8u80RFQR8lZYrstE3Ja3ow1DSs3UKVq9uG3n2hwsDLFBWFtW0TiFGnRIk034hqf8xNP9VVmxPc7h1Y= X-Received: by 2002:a17:906:401a:: with SMTP id v26mr120383639ejj.62.1561484368965; Tue, 25 Jun 2019 10:39:28 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 25 Jun 2019 19:39:28 +0200 From: Alvaro Retana In-Reply-To: References: <155893122016.5649.5181856210255754201.idtracker@ietfa.amsl.com> <20190625154538.GP48838@kduck.mit.edu> MIME-Version: 1.0 Date: Tue, 25 Jun 2019 19:39:28 +0200 Message-ID: To: Ines Robles , Benjamin Kaduk Cc: roll-chairs , roll , Peter Van der Stok , The IESG , draft-ietf-roll-useofrplinfo@ietf.org Content-Type: multipart/alternative; boundary="000000000000227639058c2969cf" Archived-At: Subject: Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-29: (with COMMENT) 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 Jun 2019 17:39:32 -0000 --000000000000227639058c2969cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On June 25, 2019 at 11:49:02 AM, Ines Robles (mariainesrobles@googlemail.co= m) wrote: Ines: Hi! Thank you very much. Yes, you are correct. we left the (1) to indicate the 6tisch case. There=E2=80=99s another =E2=80=9C(1)=E2=80=9D in the new text in =C2=A76: "= Because of (1), packets from the Internet have to be encapsulated.=E2=80=9D I think this is the last n= it =E2=80=94 we can take care of it while at the RFC Editor, no need for another revision. Thanks! Alvaro. --000000000000227639058c2969cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    On June 25, 2019 at 11:49:02 AM, Ines Robles (mariainesrobles@googlemail.com) wrote:

    Hi!

    Thank you very much. Yes, you are=C2=A0correct. we left the (1) to= indicate the 6tisch case.

    There=E2=80=99s another =E2=80=9C(1)=E2=80=9D in the new text in = =C2=A76: "Because of (1), packets from the Internet have to be=C2=A0en= capsulated.=E2=80=9D =C2=A0 I think this is the last nit =E2=80=94 we can t= ake care of it while at the RFC Editor, no need for another revision.

    <= /div>
    Thanks!=

    Alvaro.<= /div> --000000000000227639058c2969cf-- From nobody Tue Jun 25 10:43:56 2019 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 19C20120697; Tue, 25 Jun 2019 10:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 yfyIu_gP6nP4; Tue, 25 Jun 2019 10:43:53 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 342F4120896; Tue, 25 Jun 2019 10:43:53 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id r185so804023iod.6; Tue, 25 Jun 2019 10:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oUz4EoNUr0zYQlUonCsIpTnyQHm/UVxk9ijL9mniNac=; b=TGX0z/5tnFBPBWLhca+0i1Mtem+MRbwLhnj9FEWKdoFqy9g3ikWZFOhutjdn00BxFC 6U8WvzbkjotgQR3X7NewHKd1sHq6qYFiE74cfTU1ph4LCVmZApnEqczLa5w2n9iQ4qz7 xkiM+B07idH4EaXFpbPLWokkBF6+GlxqgslWSlk/Y/EtHO6izh9NAFKumEzEcJ7Bm1Xw AFKu4Wm1ufjOwgQ2/5JYCzhau3phSbHk7dLd/EnzECB0mGmxp9+KjbB8UqSDi4aTMDNL ajfWghOPUhIuGLIjF/NvMITlu8U48A1lo5fAh6YM9ib/oHE8rUMz8msbXmB/24jjmgoy RAvw== 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=oUz4EoNUr0zYQlUonCsIpTnyQHm/UVxk9ijL9mniNac=; b=qvQZ7vAKXLIcmq6Bm0/6gL9pNgkBeYCOvsmh/pSGgDlre2oYULjcLwknMgUTsI4X7R dtexEEsVCzoyIBH1KPTba88GUJhE3v/87x8fQ72h0z+l37TQt6QsWkqHY0p2My8F/2uQ 3JvcyHhi+fiBpJgp4mZQ2oBNLx3L+UT4+WJBT4EXgiwGmZVaChv/llVqztxMU+dVL6/Y hiAUFSkdfvPCPkey007kk+cS31wKyJk01vib/XWD9tFBJWFAoHOKSC8HZ3dUyCWqrCvX JHZjPPgtJY1DwJJylBgxCcGQIUAbD6xmGTKG/vYy/BJitma3ydHv+fJ0ijDVxofjKQSO sPkw== X-Gm-Message-State: APjAAAVWIggksOYCsYef9HTNSSBKdUcDQuZcBCfPNPHc/G5GWpvntMWZ flGIQGj1FcSB810fj1BwpXiKVB4MYmbKjRvH8LE= X-Google-Smtp-Source: APXvYqx5ghe0DgFWrE8sV7MkcImzP7SZBbMOoQtAAxvc9oeJDzMUN8iVHxwglMY9PJiUqz43OO9fj3bi7qbrljlzeyY= X-Received: by 2002:a5e:c748:: with SMTP id g8mr62921490iop.267.1561484632240; Tue, 25 Jun 2019 10:43:52 -0700 (PDT) MIME-Version: 1.0 References: <155893122016.5649.5181856210255754201.idtracker@ietfa.amsl.com> <20190625154538.GP48838@kduck.mit.edu> In-Reply-To: From: Ines Robles Date: Tue, 25 Jun 2019 20:43:40 +0300 Message-ID: To: Alvaro Retana Cc: Benjamin Kaduk , roll-chairs , roll , Peter Van der Stok , The IESG , draft-ietf-roll-useofrplinfo@ietf.org Content-Type: multipart/alternative; boundary="000000000000d3b464058c297870" Archived-At: Subject: Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-29: (with COMMENT) 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 Jun 2019 17:43:55 -0000 --000000000000d3b464058c297870 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Thank you very much for let us know, Yes. you are right. Ok, we will let us know to the RFC Editor. Best wishes, Ines. On Tue, Jun 25, 2019 at 8:39 PM Alvaro Retana wrote: > On June 25, 2019 at 11:49:02 AM, Ines Robles ( > mariainesrobles@googlemail.com) wrote: > > Ines: > > Hi! > > Thank you very much. Yes, you are correct. we left the (1) to indicate th= e > 6tisch case. > > > There=E2=80=99s another =E2=80=9C(1)=E2=80=9D in the new text in =C2=A76:= "Because of (1), packets from > the Internet have to be encapsulated.=E2=80=9D I think this is the last= nit =E2=80=94 we > can take care of it while at the RFC Editor, no need for another revision= . > > Thanks! > > Alvaro. > --000000000000d3b464058c297870 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Alvaro,

    Thank you very much for let = us know, Yes. you are right.=C2=A0 Ok, we will let us know to the RFC Edito= r.

    Best wishes,

    Ines.

    On Tue, Jun 25, 2019 at 8:39 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:
    On June 25, 2019= at 11:49:02 AM, Ines Robles (mariainesrobles@googlemail.com) wrote:

    Ines:

    Hi!

    Thank you very much. Yes, you are=C2=A0correct. we left the (1) to i= ndicate the 6tisch case.

    =
    There=E2=80=99s another =E2=80=9C(1)=E2=80=9D in the new tex= t in =C2=A76: "Because of (1), packets from the Internet have to be=C2= =A0encapsulated.=E2=80=9D =C2=A0 I think this is the last nit =E2=80=94 we = can take care of it while at the RFC Editor, no need for another revision.<= /font>

    Thanks!

    Alvaro.
    --000000000000d3b464058c297870-- From nobody Tue Jun 25 12:23:20 2019 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 72BDD1201EA; Tue, 25 Jun 2019 12:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZryOOnqk2R0; Tue, 25 Jun 2019 12:23:16 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5686912018E; Tue, 25 Jun 2019 12:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1561490596; bh=XkOpR7i4m0MF0V3c6snyGG3dpwSMxDXneWkS 4tl4o0o=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=Yq3gebdSzBAUTAgUxxcNpsaUO4BAIUnrh Da/nL4240dEwdfu8FEvKKAiDnflTVrdDzI0AReIAPnHxNUBk0m5jCUxNMY0jxzQw3Kg 6K0IVp5Df9op59Mc4R8L5nKTEdjhWvnTz4yIjB8gk8DdEhcOcmSJJjTSqcq5yHX+BCE 7Jco9L0bJetzhPy5NDmYfHRf/f0wzGld3HRMGUe1vue5+bf+8Kma4YvUsOjtp2eMEiF vxEcNc4M057GldCWe2Fda83cQlBS9dXCneQl26vT/IbpVYqu8vF72+Ng54TTP9CGUQP oP4Lc5ysA3S8+pDtCdHq1Fes4qldB+7e7ZGM3/TCw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=nAYJ1Od5LkXQ3U9erhE5S3x2vYV+2FrfOOyQXfJiTaguyw6RYIcqe96NncaplW9ghMu+N4XNNQKRiycViGof6jYHLlhJ5hW9RqVLcN1vm5gyOVMU3JavUikF+xxc6FhxKlSdZ70GXn8YIpoBeNtREwoVI7m/dW6gVm4SiBw8yjSJ3s5yKipT0rlZ+duOzPUIlUkZ60AroQSW+goHbCmJPwgb/BoIRbsxXV8ASpcblSF1bshDAJfPv6cuFUU42Qr9+vcqMsxVulW2/FMrQDygqNV31KO3og3nJ5CjoLHdZYB1mCPfNJlo7B4Ees5ACjxMGlyblxk60yo5EKTFC4PQfg==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1hfr2A-000AlY-HE; Tue, 25 Jun 2019 15:23:14 -0400 To: Ines Robles Cc: Routing Over Low power and Lossy networks , Samita Chakrabarti , roll-chairs , The IESG , draft-ietf-roll-useofrplinfo@ietf.org References: <155680522759.24830.12360220783250812372.idtracker@ietfa.amsl.com> <20190527042217.GL18546@prolepsis.kaduk.org> <3de1e15f-e1af-ab63-9ad9-13597dc3adcd@earthlink.net> From: Charlie Perkins Message-ID: Date: Tue, 25 Jun 2019 12:23:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7685FC4C53C04A7AFF42CD37" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c953f04745f44016468447fa0c0ed3c3135350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [Roll] IoT-dir last call review of draft-ietf-roll-useofrplinfo 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 Jun 2019 19:23:18 -0000 This is a multi-part message in MIME format. --------------7685FC4C53C04A7AFF42CD37 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Ines and all, Thanks for your detailed follow-up.  Right now I don't have much time, but there is one point: On 6/25/2019 8:29 AM, Ines Robles wrote: > > > > > > > We believe that is the same Option Type, with the value updated from > 0x63 to 0x23. > > The network would switch to 0x23 when all the nodes are capable to > process it. > > > RFC 8200 has the following text: ================================================================ 4.2.  Options    Two of the currently defined extension headers specified in this    document -- the Hop-by-Hop Options header and the Destination Options    header -- carry a variable number of "options" that are type-length-    value (TLV) encoded in the following format:       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -       |  Option Type  |  Opt Data Len |  Option Data       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -       Option Type         8-bit identifier of the type of option. ..... =============================================================== So I don't see how you can avoid having the Option Type be 8 bits long. And then I don't see how two options with different 8-bit types could possibly be called the same option. Could you explain in more detail why you believe they are the same option type? Please note -- I do not quibble that they are *similar*.  Just not *the same*. Regards, Charlie P. --------------7685FC4C53C04A7AFF42CD37 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Hello Ines and all,

    Thanks for your detailed follow-up.  Right now I don't have much time, but there is one point:

    On 6/25/2019 8:29 AM, Ines Robles wrote:

    <!--CEP: IPv6 defines the Option Type as the entire octet.  Thus, changing

         the first two bits means that this document is defining a NEW

         Option Type.  As a result, this document does NOT update RFC 6553.  -->


    <author>

    We believe that is the same Option Type, with the value updated from 0x63 to 0x23.

    The network would switch to 0x23 when all the nodes are capable to process it.

    </author>


    RFC 8200 has the following text:

    ================================================================

    4.2.  Options

       Two of the currently defined extension headers specified in this
       document -- the Hop-by-Hop Options header and the Destination Options
       header -- carry a variable number of "options" that are type-length-
       value (TLV) encoded in the following format:

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
          |  Option Type  |  Opt Data Len |  Option Data
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

          Option Type         8-bit identifier of the type of option.

    .....

    ===============================================================

    So I don't see how you can avoid having the Option Type be 8 bits long.

    And then I don't see how two options with different 8-bit types could possibly be called the same option.

    Could you explain in more detail why you believe they are the same option type?

    Please note -- I do not quibble that they are *similar*.  Just not *the same*.

    Regards,
    Charlie P.


    --------------7685FC4C53C04A7AFF42CD37-- From nobody Tue Jun 25 12:52:56 2019 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 6D645120044; Tue, 25 Jun 2019 12:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_KAM_HTML_FONT_INVALID=0.01] 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 2pbbAbNtPyB8; Tue, 25 Jun 2019 12:52:33 -0700 (PDT) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (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 43060120188; Tue, 25 Jun 2019 12:52:33 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id r185so1687938iod.6; Tue, 25 Jun 2019 12:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Eu9YRn7BrjUxQfdJ3qIDiJ8RQNHtK7Q5KqjG8X4wruM=; b=TWlKl1OAG7MioWGxw+stgTtqjanHnKl06HnTTJ4mVcN7WpRvU0JyPDSazY3dKEo6Gk q+PSWhogkDOUflderLu2k08Gy2DjzPk6PsZv4EOUb8W7CtNKRFi3SZk+vMLilpQY86cT ZhXQI5W3ZgBa8J751E1fp/H5tyESVuqKYeexsEoo+85KnwB5Ec7Sggapk5ar9hNPsX3v GkoarunL2wNaSiJxkL0+9p+oCnnMFh5NwBjICoIv4R/wsSzO2Viv1O1pMan/9SWBbzJP RnBvPE9vGTLRCg3flyFnwFhZ3ZS+LFKapmB7q0bpwP8ATQxPVcntsy8oWIdTR/DyP5Fh tdPg== 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=Eu9YRn7BrjUxQfdJ3qIDiJ8RQNHtK7Q5KqjG8X4wruM=; b=nSLl6PT/9XXAYZ6ASe4IwRocLg3B/KhnJNFJyedpZQLIkdJaPVpRcfXuAprrWSeYtq +TKy5U4H6fqU35WNrwYaMkDQ9UyifB4mkrYQkBqYSsCOO1ER9ee8Bk5XgQfOVjUA8I2x F0VlrnDQIHti5ae1jVDBICt6AM8G1qKyJ80HBcs0CvPyXI53qzjkPF5bXD1OgBefiHVK CFm7KAKINueZQ2WWiBNvday2Z9FfiTgzkEPAjCyKH5payrfYNZHly1m4Jy8mkMhORLry P/DpXq/vu58m2dqSe3BidT58a/ifAOM5XGhb+FeDsvOXGFRhhrI2tVUHGy3hBEiJ1HN+ ATvQ== X-Gm-Message-State: APjAAAWo8tlQ5lLn+UEFPmMulf4jGlkehPaIx4zRBirXnznY8hkBbZQB Zv+DMXSHNf4VI+Q4vG2jVMgpnPfrQ5lrlFNNDb0= X-Google-Smtp-Source: APXvYqx9xcPDCkxMskRB4TcXwldMAhGuzCD2RUBA6WBY46k7D9kXMv72wA747DCI+GrpFpQWgRab8x2b+vW4tu1rLe4= X-Received: by 2002:a6b:e00b:: with SMTP id z11mr404939iog.27.1561492352404; Tue, 25 Jun 2019 12:52:32 -0700 (PDT) MIME-Version: 1.0 References: <155680522759.24830.12360220783250812372.idtracker@ietfa.amsl.com> <20190527042217.GL18546@prolepsis.kaduk.org> <3de1e15f-e1af-ab63-9ad9-13597dc3adcd@earthlink.net> In-Reply-To: From: Ines Robles Date: Tue, 25 Jun 2019 22:52:20 +0300 Message-ID: To: Charlie Perkins Cc: Routing Over Low power and Lossy networks , Samita Chakrabarti , roll-chairs , The IESG , draft-ietf-roll-useofrplinfo@ietf.org Content-Type: multipart/alternative; boundary="000000000000fc124b058c2b4456" Archived-At: Subject: Re: [Roll] IoT-dir last call review of draft-ietf-roll-useofrplinfo 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 Jun 2019 19:52:36 -0000 --000000000000fc124b058c2b4456 Content-Type: text/plain; charset="UTF-8" Hi Charlie, Thank you very much for your reply. Apologizes if my english is not clear enough. We have the RPL Option identified with option type 0x63. Yes, we define a new value 0x23 to update the 0x63. Yes, it is a new binary combination that we aim to asign to the RPL Option, in that way we update RFC6553. The change of RPI option type from 0x63 to 0x23, makes all [RFC8200] compliant nodes tolerant of the RPL artifacts. Hope it helps to clarify your doubts. Thanks a lot, Ines. On Tue, Jun 25, 2019 at 10:23 PM Charlie Perkins < charles.perkins@earthlink.net> wrote: > Hello Ines and all, > > Thanks for your detailed follow-up. Right now I don't have much time, but > there is one point: > On 6/25/2019 8:29 AM, Ines Robles wrote: > > > > > > > We believe that is the same Option Type, with the value updated from 0x63 > to 0x23. > > The network would switch to 0x23 when all the nodes are capable to process > it. > > > > > RFC 8200 has the following text: > > ================================================================ > > 4.2. Options > > Two of the currently defined extension headers specified in this > document -- the Hop-by-Hop Options header and the Destination Options > header -- carry a variable number of "options" that are type-length- > value (TLV) encoded in the following format: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - > | Option Type | Opt Data Len | Option Data > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - > > Option Type 8-bit identifier of the type of option. > > ..... > > =============================================================== > > So I don't see how you can avoid having the Option Type be 8 bits long. > > And then I don't see how two options with different 8-bit types could > possibly be called the same option. > > Could you explain in more detail why you believe they are the same option > type? > > Please note -- I do not quibble that they are *similar*. Just not *the > same*. > > Regards, > Charlie P. > > > --000000000000fc124b058c2b4456 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi=C2=A0Charlie,

    Thank you very much fo= r your reply. Apologizes if my english is not clear enough.

    <= /div>
    We have the RPL Option identified with option type 0x63. Yes, we = define a new value 0x23 to update the 0x63. Yes, it is a new binary combina= tion that we aim to asign to the RPL Option, in that=C2=A0 way we update RF= C6553.
    The change of RPI option type from 0x63 to 0x23, makes all= [RFC8200]=C2=A0 compliant nodes tolerant of the RPL artifacts.

    Hope it helps to clarify your doubts.

    Thanks a lot,=C2=A0

    Ines.


    On Tue, Jun 25, 2019 at 10:23 PM Charlie Perkins <charles.perkins@earthlink.net> wrote:
    =20 =20 =20

    Hello Ines and all,

    Thanks for your detailed follow-up.=C2=A0 Right now I don't have= much time, but there is one point:

    On 6/25/2019= 8:29 AM, Ines Robles wrote:
    =20

    =

    <!--CEP: I= Pv6 defines the Option Type as the entire octet.=C2=A0 Thus, changing

    =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0the first two bits means that this document is defining a= NEW

    =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Option Type.=C2=A0 As a result, this document does NOT up= date RFC 6553.=C2=A0 -->


    <author>

    We believe that is the same Option Type, with the value updated = from 0x63 to 0x23.

    The network would switch to 0x23 when all the nodes are capable = to process it.

    </author>


    RFC 8200 has the following text:

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    4.2.=C2=A0 Options

    =C2=A0=C2=A0 Two of the currently defined extension headers specified in this
    =C2=A0=C2=A0 document -- the Hop-by-Hop Options header and t= he Destination Options
    =C2=A0=C2=A0 header -- carry a variable number of "opti= ons" that are type-length-
    =C2=A0=C2=A0 value (TLV) encoded in the following format:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+- - - - - - - - -
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Option Type=C2=A0 |= =C2=A0 Opt Data Len |=C2=A0 Option Data
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+- - - - - - - - -

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Option Type=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 8-bit identifier of the type of option.

    .....

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    So I don't see how you can avoid having the Option Type be 8 bit= s long.

    And then I don't see how two options with different 8-bit types could possibly be called the same option.

    Could you explain in more detail why you believe they are the same option type?

    Please note -- I do not quibble that they are *similar*.=C2=A0 Just not *the same*.

    Regards,
    Charlie P.


    --000000000000fc124b058c2b4456-- From nobody Tue Jun 25 16:56:49 2019 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 D4807120124 for ; Tue, 25 Jun 2019 16:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=mail-udp-cl.20150623.gappssmtp.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 3hRm2DsQ--Da for ; Tue, 25 Jun 2019 16:56:40 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 70954120125 for ; Tue, 25 Jun 2019 16:56:40 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id e8so662824otl.7 for ; Tue, 25 Jun 2019 16:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Ixu+EWXwHvoJNnO0lLl5TjP5EjP592xg4YNPcSBWxtM=; b=epjoBwnPIY8NYwniVuyrwiIA8cgEXSlZaJQ71fGslDUZnbg31FbO5k3fMQrpeFmNcq i6cvJuehuDv1kb6z9G4xxHjBkZMZrQZRRxo3EqBErQydc6AZCOQv8M9oeodAsF5FTl5D h0BEoOePkZ+MBjlrTyIY2tajjtlJ4VKv4QZAPgSZhwYQA5ydXpxa/pfWZQKFkQm/HaHE LOOYRocaAUDO2l5tkyEBxMgYqSRdodpIeSCKT4j1dsGDIVzGCKK9wAcDil2qltJiGU96 SoMX6j/ew5c5mSzCUDc0FOPNpd91xk7IN3kh6/l+jCpA4iITfObLLfLi5XT5bbN2/UBW vQlg== 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=Ixu+EWXwHvoJNnO0lLl5TjP5EjP592xg4YNPcSBWxtM=; b=QvyviK+V9f4FORFvRZZJ9z0vh+60ekFwRcQPgcRTRxHWv3MtuS1iEl4A0DLUcgLEJe X7mcFEV0+kkdLGvBQru2Cm/YsTKTs+mEkO5oEXRaJFybO8rm/BK3IMbsbGZGvhXfGDkG 77BlruuAuMRVBF9GXU42OU39Zi4IymqIAS00MUFNGp2rM68F3doGmBLYlJ+qQ++NPBuH XdQ4WjPX8y4rLachXl5ZPTlqgnseklbt6SS4wijL46il5s1hJhSLbqCZLsarMmvsjX/j V5nCFLoVGJUGyn/UjgRD2U+py+SxffS+F6opxFN55ypwi1F0xEufY4yBqD99EVyhreGi 5FzQ== X-Gm-Message-State: APjAAAVQbFga+SUmMPg6qMIhfCb0umLG3hJV9NWCh6tlaPNtrzu5uo2U xa3Uuoop0GhbDU/gtk4FESHpyn8FeJ/Q9+ccfE37/9bcZ9o= X-Google-Smtp-Source: APXvYqwQsb+gLTjKX7w+YvR+hL4BhNQp0bWWmg+cI+uCjKBcbF1fzNYdHudY9/FlCK2W4cV3zGip4JTAmP/LXU9XlrY= X-Received: by 2002:a05:6830:1249:: with SMTP id s9mr904677otp.33.1561506999427; Tue, 25 Jun 2019 16:56:39 -0700 (PDT) MIME-Version: 1.0 From: "Prof. Diego Dujovne" Date: Tue, 25 Jun 2019 19:56:28 -0400 Message-ID: To: roll , "Georgios Z. Papadopoulos" Content-Type: multipart/alternative; boundary="00000000000003f5f9058c2eaea3" Archived-At: Subject: [Roll] Review of draft-ietf-roll-nsa-extension-02 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 Jun 2019 23:56:44 -0000 --00000000000003f5f9058c2eaea3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, My review of the draft below: - The abstract should include more details about the purpose of packet replication and the context where the metric will be used. Is it an Objective Function? Is it a new mechanism? - I think abbreviations such as "aka" shall be avoided - The expression " to achieve their goal" shall be put in context. Which is the goal? Maybe it is easier to write "Network-enabled applications in the industrial context must provide..." - The phrase "In order for wireless networks to be able to be used in such applications, the principles of Deterministic Networking [I-D.ietf-detnet-architecture ] lead to designs that aim at maximizing packet delivery rate and minimizing latency and jitter." should be rewritten differently, it is a little bit complex and long. >From that expression, I understand that if you are aiming to apply detnet principles to LLNs, the design shall comply with these principles. Am I right? - "uses a fixed communication schedule" is it fixed? I think it could be better to explain that by using timeslots, TSCH looks like TDMA in the time dimension (and only for better understanding). - "provide a hard bound" isn't it "to provide"? and "and limit jitter" should be "to limit"? - "achieves a controlled redundancy" to "achieves controlled redundancy" - "within the remit of" I do not understand the expression. - "The specification of the transmission of this information is the focus of this document." could it be "This document focuses on the specification of the transmission of this specific path information" - "More concretely" to "Specifically" - "children nodes of the node" of the parent node? maybe "children of the parent node"? - "This specification defines the type value and structure for this TLV" to "This specification defines the type value and structure for the parent address set TLV". Is there an abbreviation of the parent address set (such as PAS)? - "The sending of multiple" to "The transmission of multiple" is better here. - "The sending of multiple copies of a packet using multi-path forwarding over a multi-hop network and the consolidation of multiple received packet copies to control flooding." looks awkward. The verb is missing. - " [I-D.papadopoulos-6tisch-pre-reqs ] for more." to " [I-D.papadopoulos-6tisch-pre-reqs ] for more details. - "The problem of how to select the next hop target node for a packet copy to be forwarded to when performing packet replication." can be rephrased: "Defines the mechanism to choose the next hop node to forward a packet copy when replicating" (although I think still needs some work on it) - "Preferred Parent (PP)" is defined after PP is used for the first time. - "AP node, functionality which is included in the operation of the RPL Objective Function (OF)." to "AP node. This functionality which is included in the operation of the RPL Objective Function (OF)." - "A scheme which allows the two paths to remain correlated is detailed here. More specifically, in this scheme a node will select an AP node close to its PP node to allow the operation of overhearing between parents. If multiple potential APs match this condition, the AP with the lowest rank will be registered". I think this expression can be improved eliminating the first part. "The node will select an AP node close to its PP node to allow the operatio= n of overhearing between parents. If multiple potential APs match this condition, the AP with the lowest rank will be registered". - I have not seen anything about overhearing before this point. I think overhearing can be either explained shortly or referenced to another document. - In general, from the abstract and the title, I was expecting only the technical description of the extension, without the AP selection mechanism. >From my point of view, either the mechanism should be described in another document and referenced in this one, or the goal of the document shall be expanded to include the mechanism too. - Moreover, the description of the NSA extension can be expanded to be used for other selection mechanisms which may consider different criteria to take advantage of alternative parent selection. As always, open to any comments on the above. Regards, Diego --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --00000000000003f5f9058c2eaea3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    <= div dir=3D"ltr">Dear all,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 My review of the draft below:

    - The abstract s= hould include more details about the purpose
    of packet replicatio= n and the context where the metric will
    be used. Is it an Objecti= ve Function? Is it a new mechanism?

    - I think abbr= eviations such as "aka" shall be avoided

    - The expression " to achieve their goal" shall be put in context.
    Which is the goal= ? Maybe it is easier to write "Network-enabled
    applications i= n the industrial context must provide..."

    =
    - The phrase "In order
    =
   for wireless networks to be able to be used in such applications, the
   principles of Deterministic Networking [I-D.ietf-detnet-=
architecture]
   lead to designs that aim at maximizing packet delivery rate and
   minimizing latency and jitter."
    should be rewritten differentl= y, it is a little bit complex and long.
    From that expression, I u= nderstand that if you are aiming to apply detnet principles to LLNs, the de= sign shall comply with these principles. Am I right?

    - "uses a fixe= d communication schedule" is it fixed? I think it could be better to e= xplain that by using timeslots, TSCH looks like TDMA in the time dimension = (and only for better understanding).

    -=C2=A0 "provide a hard bound" is= n't it "to provide"? and "and limit jitter" should be "to lim= it"?

    - "ac= hieves a controlled redundancy" to "achieves controlled redundancy"<= /div>

    <= /div>
    - "within the remit of= " I do not understand the expression.

    - "The specification of=C2=A0the transmission of this informat= ion is the focus of this document."
    could it be "This document focuses= on the specification of the transmission of this specific path information= "

    - "More concretely" to "Specifically"

    - "children nodes of the node&= quot; of the parent node?=C2=A0maybe "children of the parent node"?
    =

    =
    - "This specification defin= es the type value and structure for=C2=A0this TLV" to "This specification defines the type valu= e and structure for the parent address set=C2=A0TLV". Is there an abbreviation of the= parent address set (such as PAS)?

    - "The sending of multiple" to "The transmiss= ion of multiple" is better here.

    - "The sending of multiple=C2=A0copies of a packet using multi-path= forwarding over a multi-hop=C2=A0network and the consolidation of multiple received packe= t copies=C2=A0t= o control flooding."
    looks awkward. The verb is missing.
    <= span style=3D"color:rgb(0,0,0);font-size:13.3333px">
    <= span style=3D"color:rgb(0,0,0);font-size:13.3333px">- " [I-D.p= apadopoulos-6tisch-pre-reqs] for more." to " [I-D.papadopoulos-6tisch-pre-r= eqs] for more deta= ils.
    =
    = - "The pro= blem of how to select the=C2=A0next hop target node for a packet copy to be forwarded to w= hen=C2=A0perfor= ming packet replication." can be rephrased: "Defines the mechanis= m to choose the next hop node to forward a packet copy when replicating&quo= t; (although I think still needs some work on it)

    - "Preferred Parent (PP)" is define= d after PP is used for the first time.

    - "AP node,=C2=A0functionality which is included in the operation = of the RPL Objective=C2=A0
    =C2=A0 =C2=A0Function (OF)." to=C2=A0"AP node. This=C2=A0functionality which is includ= ed in the operation of the RPL Objective=C2=A0Function (OF)."=C2=A0=C2=A0

    - "A scheme which allows the two paths to= remain
       =
correlated is detailed here.  More specifically, in this scheme a
   node will select an AP node close to its PP node to allow the
   operation of overhearing between parents.  If multiple potential APs
   match this condition, the AP with the lowest rank will be registered&quo=
t;.
    I think this expression can be improved eliminating the first pa= rt.
    "The=C2=A0node will select an AP node close to its PP node to allow t= he=C2=A0operati= on of overhearing between parents. If multiple potential APs=C2=A0match this condition, t= he AP with the lowest rank will be registered".

    - I have not seen any= thing about overhearing before this point. I think overhearing can be eithe= r explained shortly or referenced to another document.=C2=A0

    - In general= , from the abstract and the title, I was expecting only the technical descr= iption of the extension, without the AP selection mechanism. From my point = of view, either the mechanism should be described in another document and r= eferenced in this one, or the goal of the document shall be expanded to inc= lude the mechanism too.

    -=C2=A0 Moreover, the desc= ription of the NSA extension can be expanded to be used for other selection= mechanisms which may consider different criteria to take advantage of=C2= =A0 alternative parent selection.=C2=A0

    <= div>As always, open to any comments on the above.
    Regards,
    <= div>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diego=C2=A0

    --
    DIEGO DUJOVNE
    Profesor Asociado
    Escue= la de Inform=C3=A1tica y Telecomunicaciones
    Facultad de Ingenier=C3=ADa = - Universidad Diego Portales - Chile
    www.ingenieria.udp.cl
    (56 2) 676 8125
    =
    --00000000000003f5f9058c2eaea3-- From nobody Tue Jun 25 17:27:00 2019 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 DEC6D120139; Tue, 25 Jun 2019 17:26:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, consultancy@vanderstok.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156150881090.31233.460341246895590440.idtracker@ietfa.amsl.com> Date: Tue, 25 Jun 2019 17:26:50 -0700 Archived-At: Subject: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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 Jun 2019 00:26:51 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-roll-efficient-npdao-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think that we need greater clarity about whether the DCOSequence number is just a series of monotonic (i.e., time-ordered) nonces (to be echoed back for matching request/response) or a full-on sequence counter that allows for loss detection as well as providing in-order delivery. It sounds like we just need the time-ordering and single-use properties, but I'm not entirely sure. I wavered about making this a Discuss point but ended up not doing so since I'm not sure how much harm is being risked. (I also mention this topic a couple times in the section-by-section comments below.) I agree with Barry that the Abstract is really hard to parse. Section 1.2 RPL uses NPDAO messaging in the storing mode so that the node changing it routing adjacencies can invalidate the previous route. nit: "its routing adjacencies" This is needed so that nodes along the previous path can release any resources (such as the routing entry) it maintains on behalf of target node. nit: singular/plural mismatch "nodes"/"it maintains" Section 4.1 When node A receives the regular DAO, it finds that it already has a routing table entry on behalf of the target address of node D. It finds however that the next hop information for reaching node D has changed i.e., node D has decided to change the paths. In this case, Node A which is the common ancestor node for node D along the two paths (previous and new), should generate a DCO which traverses downwards in the network. I can't decide whether or not it helps readability to reiterate that in addition to creating the DCO, node A also does normal DAO processing (e.g., forwarding to the 6LBR). I guess the example in A.1 does show this normal processing, so maybe it's overkill to also do so here. Section 4.2 Transit Information Option should be carried in the DAO message with I-flag set in case route invalidation is sought for the corresponding target(s). nit: this text as written implies thatthe I-flag is set in the DAO itself, not the TIO therein. I'd also suggest to s/in case/when/ for clarity. The common ancestor node SHOULD generate a DCO message in response to this I-flag when it sees that the routing adjacencies have changed for the target. I-flag governs the ownership of the DCO message in a way that the target node is still in control of its own route invalidation. nit: "The I-flag" (start of last sentence). I'd further suggest rewording to something like "The I-flag is intended to give the target node control over its own route invalidation, serving as a signal to request DCO generation; in normal operation a DCO would not otherwise be generated"; the current text about "ownership" has some weird connotations/implications and this text also implicitly assumes that DAO/TIO/I-flag will never be maliciously generated. It is also a little weaker about unsolicited DCO, per Section 4.5 Section 4.3 A new ICMPv6 RPL control message type is defined by this specification called as "Destination Cleanup Object" (DCO), which is nit: either "called" or "known as" or "referred to as" would be fine; "called as" is a grammatical mismatch. DCOSequence: Incremented at each unique DCO message from a node and echoed in the DCO-ACK message. The initial DCOSequence can be chosen randomly by the node. What's the behavior if a sequence number is skipped? (Why do we have a sequence number if we aren't going to detect and act on this condition?) Ah, I see Section 4.3.3, but perhaps a forward-reference is in order. Section 4.3.4 It seems that the "Reserved" field should be called "Flags", since a registry is being created for it. (I trust that the language about the D flag and DODAGID optionality from Barry's ballot thread is consistent between DCO and DCO-ACK.) Section 4.4 1. If a node sends a DCO message with newer or different information than the prior DCO message transmission, it MUST increment the DCOSequence field by at least one. A DCO message transmission that is identical to the prior DCO message transmission MAY increment the DCOSequence field. While reading up to this point I managed to confuse myself about Path Sequence (which must be consistent from DAO to DCO) and the separate DAOSequence and DCOSequence fields. To check my (less confused) understanding, I guess if I could over-summarize, Path Sequence is like a generation counter for a given node's position in the routing topology, and the other two are for managing retransmission/ack of the respective update messages. So if that mental model is correct, then there's not any value from trying to introduce a shared sequence number space for DCO and DAO, even though they are frequently going to be generated at the same time, especially since they have different recipients. Right? I do agree with the other discussion that we need clarity about whether the increment is exactly one or larger values are allowed (plus, presumably, whether the recipient should infer anything from a sequence number gap). I do note that these are expected to be "lollipop sequence counters" per RFC 6550. 4. A node receiving a unicast DCO message with the 'K' flag set SHOULD respond with a DCO-ACK. A node receiving a DCO message without the 'K' flag set MAY respond with a DCO-ACK, especially to report an error condition. This seems redundant with Section 4.3's "A node receiving a DCO message without the 'K' flag set MAY respond with a DCO-ACK, especially to report an error condition." Section 4.4 The scope of DCOSequence values is unique to each node. recipient or originator? Section 4.5 path on behalf of the target entry. The 6LR has all the state information namely, the Target address and the Path Sequence, nit: comma before "namely". Section 4.6.2 Even with the changed semantics, the current NPDAO mechanism in [RFC6550] can still be used, for example, when the route lifetime expiry of the target happens or when the node simply decides to gracefully terminate the RPL session on graceful node shutdown. Er, what changed semantics? This document does not have an Updates: relationship to any other document. Section 4.6.3 Note that there is no requirement of synchronization between DCO and DAOs. The DelayDCO timer simply ensures that the DCO control overhead can be reduced and is only needed when the network contains nodes using multiple preferred parent. This ("no requirement of synchronization") is because the benefit of DCO is in expiring routes faster than their normal expiration time to save local storage, rather than to provide synchronous route migration? (It might be worth reiterating, if you want.) Section 7 This document introduces the ability for a common ancestor node to invalidate a route on behalf of the target node. The common ancestor node is directed to do so by the target node using the 'I' flag in DCO's Transit Information Option. However, the common ancestor node nit(?): there's perhaps some wordsmithing possible about "is directed to do so", given the next sentence and Section 4.5. is also met. Having said that a malicious 6LR may spoof a DAO on behalf of the (sub) child with the I-flag set and can cause route invalidation on behalf of the (sub) child node. IIUC, such a malicious 6LR might also spoof a DAO even without this mechanism (to invalidate the "proper" Path Sequence) or otherwise cause denial of service by dropping traffic entirely, so perhaps we want to add another clause ", so this new mechanism does not present a substantially increased risk of disruption". This document assumes that the security mechanisms as defined in [RFC6550] are followed, which means that the common ancestor node and all the 6LRs are part of the RPL network because they have the required credentials. A non-secure RPL network needs to take into consideration the risks highlighted in this section. I'd consider adding "as well as those highlighted in [RFC6550]" to the end. Appendix A.1 6. Node G receives the DCO(tgt=D,pathseq=x+1). It checks if the received path sequence is latest as compared to the stored path sequence. If it is latest, Node G invalidates routing entry of target D and forwards the (un)reachability information downstream to B in DCO(tgt=D,pathseq=x+1). This wording of "latest as compared to" feels unusual to me; I would have expected "is later than the stored path sequence" and "If it is later", but perhaps there is a convention here that I'm missing. nit: "invalidates the routing entry" 9. The propagation of the DCO will stop at any node where the node does not have an routing information associated with the target. If the routing information is present and its Path Sequence is higher, then still the DCO is dropped. nit: maybye reword to "If cached routing information is present and the cached Path Sequence is higher than the value in the DCO, then the DCO is dropped". Appendix A.2 I feel like we should probably mention the DelayDAO timer as well as the DelayDCO one. I think this is a side note, but it seems like the timer mechanism for DelayDAO (and by extension, DelayDCO) are a bit fragile, as one party has to wait for the full timeout before sending the message (e.g., N22 in this example) that the other party is waiting the timeout to receive (e.g., N11). So it seems like we are still susceptible to transport delay/jitter and race conditions at some point in the network, even if it's not the next-hop of the target node. But if that's a property of DelayDAO from RFC 6550, it doesn't really make sense to try to address it in this document (and it's also possible I misunderstand the situation). From nobody Wed Jun 26 05:53:05 2019 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 BAE9D1201D2; Wed, 26 Jun 2019 05:52:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, consultancy@vanderstok.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156155357675.19915.16385205102161062477.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2019 05:52:56 -0700 Archived-At: Subject: [Roll] Roman Danyliw's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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 Jun 2019 12:52:57 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-roll-efficient-npdao-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few areas of ambiguity: (1) Section 4.3. Per “DCOSequence: Incremented at each unique DCO message …”: -- To confirm, DCOSequence is getting incremented for each new unique DCO message? If so, how is it incremented? -- How is roll-over handled? (2) Section 4.3.4. Per the Status field and “The remaining status values are reserved as rejection codes”, where are those rejections codes described and enumerated? A few editorial nits: ** Section 1. Editorial Nit. s/RPL has an optional messaging/RPL has operational messaging/ ** Section 2.3. Expand the word. s/async/asynchronous/ ** Section 4.2. Typo. s/[RFC6550] allows parent address/[RFC6550] allows the parent address/ ** Section 4.3. All of the other fields descriptions in this section specify the size of the field (e.g., 8-bit) but the description of DCOSequence does not ** Section 4.3.2. Cite the references for the permitted options ** Section 4.3.3. Typo. s/seqeunce/sequence/ ** Section 4.6.1. Per “Note that setting the I-flag”, this sentence would read more clearly without the double negative. From nobody Wed Jun 26 09:14:50 2019 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 4F853120140; Wed, 26 Jun 2019 09:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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, 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 xujICUCPFxoH; Wed, 26 Jun 2019 09:14:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715E61200C4; Wed, 26 Jun 2019 09:14:38 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id B82143808A; Wed, 26 Jun 2019 12:12:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 47191E68; Wed, 26 Jun 2019 12:14:36 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4367F60; Wed, 26 Jun 2019 12:14:36 -0400 (EDT) From: Michael Richardson To: Charlie Perkins cc: Ines Robles , Routing Over Low power and Lossy networks , Samita Chakrabarti , roll-chairs , The IESG , draft-ietf-roll-useofrplinfo@ietf.org In-Reply-To: References: <155680522759.24830.12360220783250812372.idtracker@ietfa.amsl.com> <20190527042217.GL18546@prolepsis.kaduk.org> <3de1e15f-e1af-ab63-9ad9-13597dc3adcd@earthlink.net> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] IoT-dir last call review of draft-ietf-roll-useofrplinfo 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 Jun 2019 16:14:41 -0000 --=-=-= Content-Type: text/plain Charlie Perkins wrote: > So I don't see how you can avoid having the Option Type be 8 bits long. > And then I don't see how two options with different 8-bit types could > possibly be called the same option. If you like, we could rename the old one to RPI-drop-if-unknown, and the new one to be RPI-ignore-if-unknown. (Or maybe in 8200-speak, "unconfigured to examine") I don't care about the name, but maybe 6man or the IESG has a stronger opinion. I'm not sure if your comment has a proceedural or on-the-wire impact, or if it is just an editorial change you asking for. The point is that we want to update RFC6553 to change the behaviour if unknown so that we don't have to waste many bytes and CPU cycles inserting and removing useless IPIP headers at every LLN hop. > Could you explain in more detail why you believe they are the same option > type? Because the other 5-bits are the same, and the allocation strategy that IANA has been told about is not to reuse/overlap the lower-5-bits until necessary. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0TmesACgkQgItw+93Q 3WUmLwgAixVKsM9/+eTI154+cV5GOcRMrgBnDy98MtVGJ8Hz2wD90WMnN3c0JGBO o+WpdMbPj/EMwIvy0jvosqQdci+PBCSvTuBI1WkOpbtJqeaAzcAoT11zE76eEcXV APFA3Ga63n7yvXEfFM7SO0LuhDA0gT/fYa1q+bBgmAvJfrG3FGUHqH8F/N9mpuGe hLerhrt8Sil8nXnB2bCCd3Hh1/5ea9S5sz4TUINLp0s0DUzC+kw2pKtY9tZl5hIR PW8ZefPxdOgpYUmNjWEwzwLxs18dYfLU4rUqaa+XFABOiV3PSg2WPGJ3y2yBchOc Ut5DgmyzHSdTAxaTJ4sJi6r/+G6RJA== =QfdG -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 26 16:12:56 2019 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 AAE13120314; Wed, 26 Jun 2019 16:12:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Weis via Datatracker To: Cc: draft-ietf-roll-efficient-npdao.all@ietf.org, roll@ietf.org, iesg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Brian Weis Message-ID: <156159076663.20249.2660341271739856150@ietfa.amsl.com> Date: Wed, 26 Jun 2019 16:12:46 -0700 Archived-At: Subject: [Roll] Secdir telechat review of draft-ietf-roll-efficient-npdao-12 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 Jun 2019 23:12:47 -0000 Reviewer: Brian Weis Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I previously reviewed draft version 10, and asked that some text should be added to describe a new risk that the new NPDAO message adds to ROLL. Draft version 12 adds that text, and I don't have any further comments. From nobody Wed Jun 26 16:17:14 2019 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 BBE6F1201A2; Wed, 26 Jun 2019 16:17:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, consultancy@vanderstok.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156159102176.20168.277762395154650827.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2019 16:17:01 -0700 Archived-At: Subject: [Roll] Adam Roach's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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 Jun 2019 23:17:05 -0000 Adam Roach has entered the following ballot position for draft-ietf-roll-efficient-npdao-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors for a well-written and easy-to-follow document. I only have two tiny editorial suggestions. --------------------------------------------------------------------------- §1.2: > RPL uses NPDAO messaging in the storing mode so that the node > changing it routing adjacencies can invalidate the previous route. Nit: "...changing its routing..." --------------------------------------------------------------------------- §6.2: > The following bits are currently defined: This value appears to be an enumeration rather than a bitmap, right? I think you want to replace "bits" with "values" in this sentence. From nobody Wed Jun 26 18:00:32 2019 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 D96F4120233; Wed, 26 Jun 2019 18:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL3JzKLnbMEe; Wed, 26 Jun 2019 18:00:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EBA1200C5; Wed, 26 Jun 2019 18:00:19 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4EDDB1C8908C8224EBD6; Thu, 27 Jun 2019 02:00:17 +0100 (IST) Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 02:00:16 +0100 Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 27 Jun 2019 02:00:16 +0100 Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 27 Jun 2019 02:00:16 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.118]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 06:30:05 +0530 From: Rahul Arvind Jadhav To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-roll-efficient-npdao@ietf.org" , Peter Van der Stok , "aretana.ietf@gmail.com" , "roll-chairs@ietf.org" , "roll@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1yb2xs?= =?utf-8?Q?-efficient-npdao-12:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHVK3mEroguwqI5VE6sJxU/AMt1W6at9xOw Date: Thu, 27 Jun 2019 01:00:04 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF0BF90@BLREML503-MBX.china.huawei.com> References: <156148288899.31109.1545890009202623647.idtracker@ietfa.amsl.com> In-Reply-To: <156148288899.31109.1545890009202623647.idtracker@ietfa.amsl.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?roll-efficient-npdao-12=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 27 Jun 2019 01:00:22 -0000 VGhhbmtzIE1pcmphIGZvciB0aGUgcmV2aWV3IGFuZCBmZWVkYmFjay4NCkZvciB0aGUgRElTQ1VT UyBwb2ludCwgSSBoYXZlIHRvIHJlYWNoIG91dCB0byBXRyB0byBjaGVjayBpZiBhbnlvbmUgaGFz IHNwZWNpZmljIHJlY29tbWVuZGF0aW9ucyB0b3dhcmRzIHRoaXMuIFRoZXJlIGlzIGFsc28gYSBz aW1pbGFyIG1lc3NhZ2luZyBpbiBwYXJlbnQgZG9jdW1lbnQgUkZDIDY1NTAgd2hpY2ggYWxzbyBk b2VzIG5vdCBleHBsaWNpdGx5IHB1dHMgaG93IHRoaXMgcmV0cnkgc2hvdWxkIGhhcHBlbi4NClBs ZWFzZSBmaW5kIG15IHJlc3BvbnNlcyBpbmxpbmUuDQoNClRoYW5rcywNClJhaHVsDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSSBoYXZlIGEgc21hbGwgZGlz Y3VzcyB0aGF0IHNob3VsZCBiZSBlYXN5IHRvIGFkZHJlc3M6DQoNClNlYyA0LjM6ICIgVGhlIG51 bWJlciBvZiByZXRyaWVzIGFyZSBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudA0KICAgZGVw ZW5kZW50LiINCihhbmQgYWxzbyBzZWMgNC40IHBvaW50IDYpDQoNClBsZWFzZSBzcGVjaWZ5IGEg bWF4aW11bSBudW1iZXIgb2YgcmV0cmllcyBhbmQgYWxzbyBhIG1pbmltdW0gcmV0cnkgaW50ZXJ2 YWwgKG9mIGUuZy4gMyBzZWMgYmVzdCB3aXRoIGV4cG9uZW50aWFsIGJhY2stb2ZmKSENCg0KW1JK XSBTZWN0aW9uIDQuMyBzYXlzIHRoYXQgaXQgaXMgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1l bnQgZGVwZW5kZW50LiBXZSBoYXZlIGF2b2lkZWQgdG8gcHV0IGFuIGV4YWN0IG51bWJlciBoZXJl IGJlY2F1c2Ugb2YgdGhlIGRpZmZlcmVuY2VzIGluIHBoeXNpY2FsIGxheWVycyBhbmQgd2lyZWxl c3MgZGVuc2Uvc3BhcnNlIGRlcGxveW1lbnRzIHRoaXMgY291bGQgYmUgdXNlZCBvbi4gSSBhbSBu b3Qgc3VyZSBpZiBwdXR0aW5nIGFuIGV4YWN0IHZhbHVlIGxpa2Ugc3BlY2lmeWluZyAzIHJldHJp ZXMgb3IgNCByZXRyaWVzIGlzIG9rLiBJIGRvbid0IGtub3cgd2hhdCB0byBiYXNlIHRoaXMgdmFs dWUvcmVjb21tZW5kYXRpb24gb24uIFRoZSBEQ08vRENPLUFDSyByZXRyeSBtZWNoYW5pc20gZW11 bGF0ZXMgREFPL0RBTy1BQ0sgcmV0cnkgbWVjaGFuaXNtIGZyb20gUkZDIDY1NTAgd2hpY2ggYWxz byBoYXMgbm90IHB1dCBhbiBleHBsaWNpdCBkZXRhaWxzIGZvciB0aGlzLg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpPbmUgcXVlc3Rpb24gb24gc2VjdGlvbiA0 LjYuMjogWW91IHByZXNlbnQgdXNlIG9mIE5QREFPIGFuZCBEQ08gYXMgdHdvIG9wdGlvbnMsIGhv d2V2ZXIsIHRoZSBwcm9ibGVtIHdpdGggdGhlIEkgZmxhZyBpcyB0aGF0IHRoZSBzZW5kZXIgZG9l cyBub3Qga25vdyBpZiB0aGUgYW5jZXN0b3IgdW5kZXJzdGFuZCB0aGUgc2lnbmFsLiBXb3VsZG4n dCBpdCBhbHNvIG1ha2Ugc2Vuc2UgdG8gdXNlIGJvdGggaW4gc29tZSBjYXNlcywgZS5nLiBzZW5k IERBTyB3aXRoIEkgZmxhZyBmaXJzdCBhbmQgaWYgeW91IGRvbid0IHJlY2VpdmUgYSBEQ08gYWZ0 ZXIgc29tZSBsaW1pdGVkIHRpbWUsIHlvdSBhbHNvIHNlbmQgdGhlIE5QREFPPw0KDQpbUkpdIFll cywgaXQgaXMgcG9zc2libGUgZm9yIGEgbm9kZSB0byB1c2UgYm90aCBEQ08gYW5kIE5QREFPLiBT ZWN0aW9uIDQuNi4yIHNwZWNpZmllcyB0aGlzIGluIGRldGFpbC4NCg0KTml0czoNCnNlYyAxLjI6 IHMvc28gdGhhdCB0aGUgbm9kZSBjaGFuZ2luZyBpdCByb3V0aW5nIGFkamFjZW5jaWVzL3NvIHRo YXQgdGhlIG5vZGUgY2hhbmdpbmcgaXRzIHJvdXRpbmcgYWRqYWNlbmNpZXMvIC0+ICJpdCIgaW5z dGVhZCBvZiAiaXRzIg0KDQpbUkpdIFdpbGwgZml4IHRoaXMuDQo= From nobody Wed Jun 26 18:03:08 2019 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 132BC1203D1 for ; Wed, 26 Jun 2019 18:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A2boPk6Uf_a for ; Wed, 26 Jun 2019 18:03:05 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531251200B5 for ; Wed, 26 Jun 2019 18:03:05 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D67D39C61B79B214CA5E for ; Thu, 27 Jun 2019 02:03:03 +0100 (IST) Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 02:03:03 +0100 Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 27 Jun 2019 02:03:03 +0100 Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 27 Jun 2019 02:03:02 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.118]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 06:32:53 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks CC: =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: Retrying DCO/DAO, retry parameters Thread-Index: AdUshAoU1ZNXDKIJRSu3/AosXtsQyA== Date: Thu, 27 Jun 2019 01:02:53 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF0BFA2@BLREML503-MBX.china.huawei.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DF0BFA2BLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Roll] Retrying DCO/DAO, retry parameters 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, 27 Jun 2019 01:03:07 -0000 --_000_982B626E107E334DBE601D979F31785C5DF0BFA2BLREML503MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, During IESG evaluation of (draft-ietf-roll-efficient-npdao-12) we received = a comment from Mirja regarding specifying the DCO retry operation in detail= if DCO-ACK is not received. Quoting her verbatim, "Please specify a maximu= m number of retries and also a minimum retry interval (of e.g. 3 sec best w= ith exponential back-off)!" Currently the draft says that this is "implementation and deployment depend= ent". RFC 6550 also has DAO retries if DAO-ACK is not received but it also does n= ot specify this operation in detail. Do you think we can put this explicitly and does anyone have an opinion on= the right way of putting this considering different physical layers with v= ery different characteristics operating in dense/sparse (wireless) deployme= nts? Thanks, Rahul --_000_982B626E107E334DBE601D979F31785C5DF0BFA2BLREML503MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hello All,

     

    During IESG evaluation of (draft-ietf-roll-effici= ent-npdao-12) we received a comment from Mirja regarding specifying the DCO= retry operation in detail if DCO-ACK is not received. Quoting her verbatim= , “Please specify a maximum number of retries and also a minimum retry interval (of e.g. 3 sec best with expo= nential back-off)!”

     

    Currently the draft says that this is “impleme= ntation and deployment dependent”.

    RFC 6550 also has DAO retries if DAO-ACK is not rece= ived but it also does not specify this operation in detail.

     

    Do you think we can put this explicitly  and do= es anyone have an opinion on the right way of putting this considering diff= erent physical layers with very different characteristics operating in dens= e/sparse (wireless) deployments?

     

    Thanks,

    Rahul

    --_000_982B626E107E334DBE601D979F31785C5DF0BFA2BLREML503MBXchi_-- From nobody Wed Jun 26 18:04:14 2019 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 28BE21203D1; Wed, 26 Jun 2019 18:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaeFPiJEmNuY; Wed, 26 Jun 2019 18:04:01 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACFB1200B5; Wed, 26 Jun 2019 18:04:01 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D739CEA801021022ADEF; Thu, 27 Jun 2019 02:03:59 +0100 (IST) Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 02:03:59 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.118]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 06:33:47 +0530 From: Rahul Arvind Jadhav To: Roman Danyliw , Routing Over Low power and Lossy networks , The IESG CC: "roll-chairs@ietf.org" , "draft-ietf-roll-efficient-npdao@ietf.org" Thread-Topic: [Roll] Roman Danyliw's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) Thread-Index: AQHVLB4eWysOD1Be6UKbGJp8dhZ8e6at6yIA Date: Thu, 27 Jun 2019 01:03:46 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF0BFB6@BLREML503-MBX.china.huawei.com> References: <156155357675.19915.16385205102161062477.idtracker@ietfa.amsl.com> In-Reply-To: <156155357675.19915.16385205102161062477.idtracker@ietfa.amsl.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Roman Danyliw's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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, 27 Jun 2019 01:04:03 -0000 VGhhbmtzIFJvbWFuIGZvciB0aGUgcmV2aWV3IGFuZCBmZWVkYmFjay4NClBsZWFzZSBmaW5kIG15 IHJlc3BvbnNlIGlubGluZS4NCg0KVGhhbmtzLA0KUmFodWwNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09N TUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQSBmZXcgYXJlYXMgb2YgYW1iaWd1aXR5Og0KDQooMSkg U2VjdGlvbiA0LjMuICBQZXIg4oCcRENPU2VxdWVuY2U6IEluY3JlbWVudGVkIGF0IGVhY2ggdW5p cXVlIERDTyBtZXNzYWdlIOKApuKAnToNCg0KLS0gVG8gY29uZmlybSwgRENPU2VxdWVuY2UgaXMg Z2V0dGluZyBpbmNyZW1lbnRlZCBmb3IgZWFjaCBuZXcgdW5pcXVlIERDTyBtZXNzYWdlPyAgSWYg c28sIGhvdyBpcyBpdCBpbmNyZW1lbnRlZD8NCg0KW1JKXSBUaGUgZXhhY3QgaW5jcmVtZW50IG9w ZXJhdGlvbiBpcyBtZW50aW9uZWQgaW4gc2VjdGlvbiA0LjQgIkRDTyBCYXNlIFJ1bGVzIiBwb2lu dCAxLg0KDQotLSBIb3cgaXMgcm9sbC1vdmVyIGhhbmRsZWQ/DQoNCltSSl0gVGhpcyBpcyBhbiBp bXBvcnRhbnQgY2F0Y2guIERDT1NlcXVlbmNlIGZvbGxvd3MgdGhlIHNhbWUgcHJpbmNpcGxlIGFz IG90aGVyIHNlcXVlbmNlIGNvdW50ZXJzIGFzIGluIFJQTCBSRkMgNjU1MCBTZWN0aW9uIDcuMi4g UXVvdGluZyA2NjUwLCAiQWxsIHRoZSBzZXF1ZW5jZSBjb3VudGVycyBpbiBSUEwgdXNlIGxvbGxp cG9wIGNvdW50ZXJzLCB3aGVyZSB0aGUgdmFsdWVzIGZyb20gMTI4IGFuZCBncmVhdGVyIGFyZSB1 c2VkIGFzIGEgbGluZWFyIHNlcXVlbmNlIHRvIGluZGljYXRlIGEgcmVzdGFydCBhbmQgYm9vdHN0 cmFwIHRoZSBjb3VudGVyLCBhbmQgdGhlIHZhbHVlcyBsZXNzIHRoYW4gb3IgZXF1YWwgdG8gMTI3 IHVzZWQgYXMgYSBjaXJjdWxhciBzZXF1ZW5jZSBudW1iZXIgc3BhY2Ugb2Ygc2l6ZSAxMjggYXMg aW4gUkZDMTk4Mi4iIA0KVGhpcyBuZWVkcyB0byBiZSBleHBsaWNpdGx5IHN0YXRlZC9yZWZlZCBp biB0aGUgZG9jdW1lbnQuIFRoYW5rcw0KDQooMikgU2VjdGlvbiA0LjMuNC4gIFBlciB0aGUgU3Rh dHVzIGZpZWxkIGFuZCDigJxUaGUgcmVtYWluaW5nIHN0YXR1cyB2YWx1ZXMgYXJlIHJlc2VydmVk IGFzIHJlamVjdGlvbiBjb2Rlc+KAnSwgd2hlcmUgYXJlIHRob3NlIHJlamVjdGlvbnMgY29kZXMg ZGVzY3JpYmVkIGFuZCBlbnVtZXJhdGVkPw0KDQpbUkpdIFdlIGhhdmUgYWRkZWQgYSByZXF1ZXN0 IGZvciBJQU5BIGZvciBjcmVhdGUgYSByZWdpc3RyeSBmb3IgdGhpcyAuIFNlY3Rpb24gNi4yIGRl c2NyaWJlcyBpdCBpbiBkZXRhaWwuDQoNCkEgZmV3IGVkaXRvcmlhbCBuaXRzOg0KDQoqKiBTZWN0 aW9uIDEuICBFZGl0b3JpYWwgTml0LiAgcy9SUEwgaGFzIGFuIG9wdGlvbmFsIG1lc3NhZ2luZy9S UEwgaGFzIG9wZXJhdGlvbmFsIG1lc3NhZ2luZy8NCg0KW1JKXSBXZSB3YW50ZWQgdG8gY29udmV5 IHRoYXQgUlBMIGhhcyBOUERBTyBtZXNzYWdpbmcgd2hpY2ggaXMgb3B0aW9uYWwgcGVyIDY1NTAu IEJhcnJ5IHN1Z2dlc3RlZCB3ZSByZW1vdmUgdGhlICJhbiIgdG8gbWFrZSB0aGUgc2VudGVuY2Ug Z3JhbW1hdGljYWxseSBjb3JyZWN0LiBVc2luZyAiUlBMIGhhcyBvcGVyYXRpb25hbCBtZXNzYWdp bmciIHdvbid0IGZpdCB0aGUgcmVxdWlyZWQgZGVzY3JpcHRpb24uDQoNCioqIFNlY3Rpb24gMi4z LiAgRXhwYW5kIHRoZSB3b3JkLiAgcy9hc3luYy9hc3luY2hyb25vdXMvDQoNCioqIFNlY3Rpb24g NC4yLiAgVHlwby4gcy9bUkZDNjU1MF0gYWxsb3dzIHBhcmVudCBhZGRyZXNzL1tSRkM2NTUwXSBh bGxvd3MgdGhlIHBhcmVudCBhZGRyZXNzLw0KDQoqKiBTZWN0aW9uIDQuMy4gIEFsbCBvZiB0aGUg b3RoZXIgZmllbGRzIGRlc2NyaXB0aW9ucyBpbiB0aGlzIHNlY3Rpb24gc3BlY2lmeSB0aGUgc2l6 ZSBvZiB0aGUgZmllbGQgKGUuZy4sIDgtYml0KSBidXQgdGhlIGRlc2NyaXB0aW9uIG9mIERDT1Nl cXVlbmNlIGRvZXMgbm90DQoNCioqIFNlY3Rpb24gNC4zLjIuICBDaXRlIHRoZSByZWZlcmVuY2Vz IGZvciB0aGUgcGVybWl0dGVkIG9wdGlvbnMNCg0KKiogU2VjdGlvbiA0LjMuMy4gVHlwby4gIHMv c2VxZXVuY2Uvc2VxdWVuY2UvDQoNCltSSl0gV2lsbCBmaXggYWxsIHRoZXNlIHBvaW50cw0KDQoq KiBTZWN0aW9uIDQuNi4xLiAgUGVyIOKAnE5vdGUgdGhhdCBzZXR0aW5nIHRoZSBJLWZsYWfigJ0s IHRoaXMgc2VudGVuY2Ugd291bGQgcmVhZCBtb3JlIGNsZWFybHkgd2l0aG91dCB0aGUgZG91Ymxl IG5lZ2F0aXZlLg0KDQpbUkpdIEknbGwgY2hhbmdlIHRoZSBzZW50ZW5jZSB0bywgIk5vdGUgdGhh dCBzZXR0aW5nIHRoZSBJLWZsYWcgd2lsbCBub3QgcmVzdWx0IGluIGFkZGl0aW9uYWwgY29udHJv bCBvdmVyaGVhZCBvciBvdGhlciBzaWRlLWVmZmVjdHMgZXZlbiBpZiB0aGVyZSBpcyBubyBwcmV2 aW91cyByb3V0ZSB0byBiZSBpbnZhbGlkYXRlZC4iIFdpbGwgdGhpcyBiZSBvaz8NCg== From nobody Wed Jun 26 18:08:12 2019 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 B1A3A120094; Wed, 26 Jun 2019 18:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEECVFxOiPIQ; Wed, 26 Jun 2019 18:08:02 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51436120086; Wed, 26 Jun 2019 18:08:02 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A450442674C60FA6F946; Thu, 27 Jun 2019 02:08:00 +0100 (IST) Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 02:08:00 +0100 Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 27 Jun 2019 02:08:00 +0100 Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 27 Jun 2019 02:08:00 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.118]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 06:37:51 +0530 From: Rahul Arvind Jadhav To: Adam Roach , The IESG CC: "draft-ietf-roll-efficient-npdao@ietf.org" , Peter Van der Stok , "aretana.ietf@gmail.com" , "roll-chairs@ietf.org" , "roll@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) Thread-Index: AQHVLHVOA4LrQdLDJku8xh1OK3O70Kaur5Dg Date: Thu, 27 Jun 2019 01:07:51 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF0BFD3@BLREML503-MBX.china.huawei.com> References: <156159102176.20168.277762395154650827.idtracker@ietfa.amsl.com> In-Reply-To: <156159102176.20168.277762395154650827.idtracker@ietfa.amsl.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Adam Roach's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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, 27 Jun 2019 01:08:04 -0000 VGhhbmsgeW91IEFkYW0gZm9yIHRoZSByZXZpZXcgYW5kIGZlZWRiYWNrLg0KV2lsbCBmaXggYm90 aCB0aGUgcG9pbnRzLg0KDQpUaGFua3MsDQpSYWh1bA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1F TlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoYW5rcyB0byB0aGUgYXV0aG9ycyBmb3IgYSB3ZWxsLXdy aXR0ZW4gYW5kIGVhc3ktdG8tZm9sbG93IGRvY3VtZW50Lg0KSSBvbmx5IGhhdmUgdHdvIHRpbnkg ZWRpdG9yaWFsIHN1Z2dlc3Rpb25zLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KwqcxLjI6DQoN Cj4gIFJQTCB1c2VzIE5QREFPIG1lc3NhZ2luZyBpbiB0aGUgc3RvcmluZyBtb2RlIHNvIHRoYXQg dGhlIG5vZGUgIA0KPiBjaGFuZ2luZyBpdCByb3V0aW5nIGFkamFjZW5jaWVzIGNhbiBpbnZhbGlk YXRlIHRoZSBwcmV2aW91cyByb3V0ZS4NCg0KTml0OiAiLi4uY2hhbmdpbmcgaXRzIHJvdXRpbmcu Li4iDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCsKnNi4yOg0KDQo+ICBUaGUgZm9sbG93aW5n IGJpdHMgYXJlIGN1cnJlbnRseSBkZWZpbmVkOg0KDQpUaGlzIHZhbHVlIGFwcGVhcnMgdG8gYmUg YW4gZW51bWVyYXRpb24gcmF0aGVyIHRoYW4gYSBiaXRtYXAsIHJpZ2h0PyBJIHRoaW5rIHlvdSB3 YW50IHRvIHJlcGxhY2UgImJpdHMiIHdpdGggInZhbHVlcyIgaW4gdGhpcyBzZW50ZW5jZS4NCg0K DQo= From nobody Wed Jun 26 20:38:38 2019 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 AE3AA1200E6; Wed, 26 Jun 2019 20:38:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, consultancy@vanderstok.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <156160670770.20102.6856258611522333962.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2019 20:38:27 -0700 Archived-At: Subject: [Roll] Suresh Krishnan's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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: Thu, 27 Jun 2019 03:38:28 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-roll-efficient-npdao-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 4.3 "A new ICMPv6 RPL control message type" Shouldn't this be "code" instead of "type" given that the RPL control message types are ICMPv6 codes? From nobody Wed Jun 26 21:09:35 2019 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 0FDF612011C; Wed, 26 Jun 2019 21:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdcUPZNra4hh; Wed, 26 Jun 2019 21:09:24 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7022612011A; Wed, 26 Jun 2019 21:09:24 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DD77A171E8F253AC6575; Thu, 27 Jun 2019 05:09:22 +0100 (IST) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 05:09:22 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.118]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 09:33:53 +0530 From: Rahul Arvind Jadhav To: Suresh Krishnan , The IESG CC: "draft-ietf-roll-efficient-npdao@ietf.org" , Peter Van der Stok , "aretana.ietf@gmail.com" , "roll-chairs@ietf.org" , "roll@ietf.org" Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) Thread-Index: AQHVLJnQu3bSQaKly0qv26vkYwa7Dqau3uZw Date: Thu, 27 Jun 2019 04:03:52 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF0C0CD@BLREML503-MBX.china.huawei.com> References: <156160670770.20102.6856258611522333962.idtracker@ietfa.amsl.com> In-Reply-To: <156160670770.20102.6856258611522333962.idtracker@ietfa.amsl.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Suresh Krishnan's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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, 27 Jun 2019 04:09:26 -0000 WWVzIGl0IHNob3VsZCBiZSAiY29kZSIgYW5kIG5vdCBhICJ0eXBlIiAhIFRoYW5rcyBTdXJlc2gg Zm9yIG5vdGljaW5nIHRoaXMgYW5kIGZvciB0aGUgcmV2aWV3Lg0KV2lsbCBmaXggdGhpcy4NCg0K VGhhbmtzLA0KUmFodWwNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQoqIFNlY3Rpb24gNC4zDQoNCiJBIG5ldyBJQ01QdjYgUlBMIGNvbnRyb2wgbWVzc2FnZSB0 eXBlIg0KDQpTaG91bGRuJ3QgdGhpcyBiZSAiY29kZSIgaW5zdGVhZCBvZiAidHlwZSIgZ2l2ZW4g dGhhdCB0aGUgUlBMIGNvbnRyb2wgbWVzc2FnZSB0eXBlcyBhcmUgSUNNUHY2IGNvZGVzPw0KDQoN Cg== From nobody Wed Jun 26 21:40:40 2019 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 3E6C0120137; Wed, 26 Jun 2019 21:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ericsson.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 BxBS1e41kf9U; Wed, 26 Jun 2019 21:40:34 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810042.outbound.protection.outlook.com [40.107.81.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8B4120041; Wed, 26 Jun 2019 21:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lxczeEymoRURAMSOOsNKoY9UagmiEYcu+lFnODfxvZo=; b=apkYTvIrCEmlhd0SkYjGpu386XTCRWc5zAIlobLwhTSukb9hWmnJWbGSZrK3LDEUAuRWr6Y13lSf+mBbX/UuuzgfkItnSvh/8OKuHCkmDOQPQRA1ANdjgXuBBLR1RlfA3oPVphlz9fzVkJO82TlB3PxnLGDBMUdrqSh/9XIfipM= Received: from BYAPR15MB2645.namprd15.prod.outlook.com (20.179.156.82) by BYAPR15MB3382.namprd15.prod.outlook.com (20.179.59.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 04:40:31 +0000 Received: from BYAPR15MB2645.namprd15.prod.outlook.com ([fe80::79b7:6a5e:5f9f:6edf]) by BYAPR15MB2645.namprd15.prod.outlook.com ([fe80::79b7:6a5e:5f9f:6edf%3]) with mapi id 15.20.2008.018; Thu, 27 Jun 2019 04:40:31 +0000 From: Eric Gray To: "draft-ietf-roll-efficient-npdao@ietf.org" CC: "Alvaro Retana (aretana)" , "roll@ietf.org" Thread-Topic: Last Call Review of draft-ietf-roll-efficient-npdao Thread-Index: AdUsWXgVYOX7Pfh+Snm71nZC5c50Nw== Date: Thu, 27 Jun 2019 04:40:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eric.gray@ericsson.com; x-originating-ip: [198.24.6.220] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b226d446-ecb2-42f1-a583-08d6fab99635 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR15MB3382; x-ms-traffictypediagnostic: BYAPR15MB3382: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(39860400002)(366004)(136003)(189003)(199004)(14454004)(71200400001)(26005)(2501003)(478600001)(7696005)(102836004)(6506007)(186003)(2906002)(81156014)(54906003)(6116002)(71190400001)(6916009)(99286004)(86362001)(8936002)(3846002)(790700001)(81166006)(606006)(8676002)(966005)(4326008)(14444005)(54896002)(55016002)(5640700003)(53936002)(68736007)(236005)(74316002)(25786009)(256004)(7736002)(316002)(486006)(476003)(73956011)(76116006)(64756008)(66446008)(66476007)(66556008)(66946007)(44832011)(66066001)(52536014)(6436002)(5660300002)(33656002)(9686003)(2351001)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB3382; H:BYAPR15MB2645.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: WEZusI8st01SRbfVM04CcMpOqexhl2SKqCXyJvr2e8k7+zsE3ye7NvlwTzCn4+g0nyv/TGKuUjF8HmIuhvJvn6iKx4f0Llt+/KFz6t256RELbJkN32URmYhSsr1AfqnJlBsUXT768j2eAKkdGmaibk3+hhFsv1OjKJgKATf3TanSLOmKyjNOsLmkSWQUB22uaTvXmvU//8OdS7ca1Mu5KGMy6bFNuKVSk4j/j5mQaAFAm7+quDECc1ZzCUXYWvNYMnzrJ8/aD5JDySeFAsnMliTsvyWsWAuVXxehpcvFHr/yeEjmeS5Uvrk8WBgKIeQLMlF68i5vb4M/7765TXmLXVEm4EfxPk5IdHVM2Kxp9ozGaZJKqwKCi2rJsliXRy4nkaau7n1OAM9Q46gg1EWJQFkAXN7uetEMektfw3ASmLA= Content-Type: multipart/alternative; boundary="_000_BYAPR15MB2645F83EC60E3956655CFD5397FD0BYAPR15MB2645namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b226d446-ecb2-42f1-a583-08d6fab99635 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 04:40:31.1598 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eric.gray@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3382 Archived-At: Subject: [Roll] Last Call Review of draft-ietf-roll-efficient-npdao 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, 27 Jun 2019 04:40:38 -0000 --_000_BYAPR15MB2645F83EC60E3956655CFD5397FD0BYAPR15MB2645namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-roll-efficient-npdao Reviewer: Andy Malis Review Date: 26 June 2019 IETF LC End Date: 26 June 2019 Intended Status: Standards Track Summary: Perhaps I am missing some subtleties, but this document looks like it may n= eed a little more work before it is published. Overall comments: The document is mostly well written. Issues: In the introduction, I have some trouble parsing "an optional messaging" - = perhaps it was meant to just be "optional messaging?" There are difference between the abstract (which claims the document descri= bes issues with NPDAO) and the Introduction (which goes further to say that= the document also discusses requirements and specifies a new message inten= ded to meet the requirements and solve the problems. So, it's a problem statement, requirements document and solution specificat= ion all rolled into one. I guess this is not a problem for anyone in the W= G? The title for section 1.3 should probably be "Why is NPDAO Important." In that section, I have to wonder if saving memory is the most important fa= ctor in removing route information that is no longer valid. What about iss= ues with forwarding packets toward destinations that can no longer be reach= ed along that path? Perhaps I misunderstand the approach, but it seems to me that the problems = mentioned in section 2.1 should self-resolve. The fact that one node canno= t send messages to another node to inform that node that it has no DAO info= rmation seems kind of irrelevant if the node, or the link connecting it, is= no longer there. Perhaps the issue you're really trying to describe is with unreliable links= and nodes, as opposed to missing links and nodes? That would make sense i= n a low-power and lossy network. If the behavior described in section 2.2 is common, and a more reasonable b= ehavior is not anticipated by the original NPDAO specification, than I agre= e that is a problem. If the problems described in 2.1 and 2.3 do exist, it seems likely that the= underlying issue is really about an assumption of reliable delivery where = that might not be the reality. All of this said, the 3 requirements seem reasonable at least as far as the= y go. There seems to be an implied requirement to introduce at least some = level of reliability (as I seems intended by providing the DCO-ACK). And th= ere probably should be a requirement to support compatibility with deployed= implementations. AFAICT, this document does not describe how nodes using the newly specified= messaging and behavior would be compatible with deployed nodes. Minimally= the document should be clear if the intention is not to provide for compat= ibility. There are at least a couple of indications that there is deployme= nt. --_000_BYAPR15MB2645F83EC60E3956655CFD5397FD0BYAPR15MB2645namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I have been selected as the Routing Directorate revi= ewer for this draft. The Routing Directorate seeks to review all routing or= routing-related drafts as they pass through IETF last call and IESG review= , and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For= more information about the Routing Directorate, please see http://tra= c.tools.ietf.org/area/rtg/trac/wiki/RtgDir

    Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.

    Document: draft-ietf-roll-efficient-npdao

    Reviewer: Andy Malis
    Review Date: 26 June 2019
    IETF LC End Date: 26 June 2019
    Intended Status: Standards Track

    Summary:

    Perhaps I am missing some subtleties, but this docum= ent looks like it may need a little more work before it is published.

    Overall comments:

    The document is mostly well written.

     

    Issues:

     

    In the introduction, I have some trouble parsing = 220;an optional messaging” – perhaps it was meant to just be &#= 8220;optional messaging?”

     

    There are difference between the abstract (which cla= ims the document describes issues with NPDAO) and the Introduction (which g= oes further to say that the document also discusses requirements and specif= ies a new message intended to meet the requirements and solve the problems.

     

    So, it’s a problem statement, requirements doc= ument and solution specification all rolled into one.  I guess this is= not a problem for anyone in the WG?

     

    The title for section 1.3 should probably be “= Why is NPDAO Important.”

     

    In that section, I have to wonder if saving memory i= s the most important factor in removing route information that is no longer= valid.  What about issues with forwarding packets toward destinations= that can no longer be reached along that path?

     

    Perhaps I misunderstand the approach, but it seems t= o me that the problems mentioned in section 2.1 should self-resolve.  = The fact that one node cannot send messages to another node to inform that = node that it has no DAO information seems kind of irrelevant if the node, or the link connecting it, is no longer th= ere.

     

    Perhaps the issue you’re really trying to desc= ribe is with unreliable links and nodes, as opposed to missing links and no= des?  That would make sense in a low-power and lossy network.

     

    If the behavior described in section 2.2 is common, = and a more reasonable behavior is not anticipated by the original NPDAO spe= cification, than I agree that is a problem.

     

    If the problems described in 2.1 and 2.3 do exist, i= t seems likely that the underlying issue is really about an assumption of r= eliable delivery where that might not be the reality.

     

    All of this said, the 3 requirements seem reasonable= at least as far as they go.  There seems to be an implied requirement= to introduce at least some level of reliability (as I seems intended by pr= oviding the DCO-ACK). And there probably should be a requirement to support compatibility with deployed implementat= ions.

     

    AFAICT, this document does not describe how nodes us= ing the newly specified messaging and behavior would be compatible with dep= loyed nodes.  Minimally the document should be clear if the intention = is not to provide for compatibility.  There are at least a couple of indications that there is deployment.<= /p>

     

     

     

    --_000_BYAPR15MB2645F83EC60E3956655CFD5397FD0BYAPR15MB2645namp_-- From nobody Wed Jun 26 21:41:58 2019 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 04787120137; Wed, 26 Jun 2019 21:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ericsson.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 NUPV2WeVkZlU; Wed, 26 Jun 2019 21:41:54 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810040.outbound.protection.outlook.com [40.107.81.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11094120041; Wed, 26 Jun 2019 21:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UtflmTdeLHjcpwagKQc9hSbmWjwdU5LK1k0qOivJW/w=; b=DldOR2UVjCcW8+jM5gVKKQyPbyEqYRDmZ6wUSgI/+Z/ihsH8x32BLZdR1Ypdkwd9vu1VzV/9feQurLIC7h+/ymhiiTDl5rZPdw1LikoWpBu3aePvqEGagRAc9W7QnVywoNRiRb2ZI1Uo6AtpOXi4o0j6cyY+hPwptzzX6+6qA/c= Received: from BYAPR15MB2645.namprd15.prod.outlook.com (20.179.156.82) by BYAPR15MB3382.namprd15.prod.outlook.com (20.179.59.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 04:41:52 +0000 Received: from BYAPR15MB2645.namprd15.prod.outlook.com ([fe80::79b7:6a5e:5f9f:6edf]) by BYAPR15MB2645.namprd15.prod.outlook.com ([fe80::79b7:6a5e:5f9f:6edf%3]) with mapi id 15.20.2008.018; Thu, 27 Jun 2019 04:41:52 +0000 From: Eric Gray To: "draft-ietf-roll-efficient-npdao@ietf.org" CC: "Alvaro Retana (aretana)" , "roll@ietf.org" Thread-Topic: Last Call Review of draft-ietf-roll-efficient-npdao Thread-Index: AdUsWXgVYOX7Pfh+Snm71nZC5c50NwASRBbw Date: Thu, 27 Jun 2019 04:41:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eric.gray@ericsson.com; x-originating-ip: [198.24.6.220] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4361e045-ff92-4786-7c6a-08d6fab9c69d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR15MB3382; x-ms-traffictypediagnostic: BYAPR15MB3382: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(39860400002)(366004)(136003)(189003)(199004)(14454004)(71200400001)(26005)(2501003)(478600001)(76176011)(7696005)(102836004)(53546011)(6506007)(186003)(2906002)(81156014)(54906003)(6116002)(71190400001)(6916009)(99286004)(86362001)(8936002)(3846002)(790700001)(81166006)(2940100002)(606006)(8676002)(966005)(4326008)(14444005)(54896002)(55016002)(5640700003)(6246003)(53936002)(68736007)(236005)(229853002)(74316002)(25786009)(256004)(11346002)(7736002)(316002)(486006)(476003)(73956011)(76116006)(64756008)(66446008)(66476007)(66556008)(66946007)(44832011)(66066001)(52536014)(446003)(6436002)(5660300002)(33656002)(9686003)(2351001)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB3382; H:BYAPR15MB2645.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DMYuoieE7nErG33yTJt++wC+wtiNWnL8BwpJ3N0j3EtZmdSOeWdTb9HeeV2m/O5DN+xS20PlLR2SqVC3CzBcQlzx49Jwibg6Us81uzarom2dePbGSAD58mDEYsSfw026r6Nzc0RpptTFEyxIYNDYgpcJNLgHa3+3QOE8ltYjAcepfOMpCZnmIfs73PTmFblXB2UKS3QBfdlph8InJcZwgR63Jx0aufmisV7YneR5AXN5ZlkCQZpElMpbxz/RgNLj8rktnENpqiOuQC1bNUFYKSJvdabWZmTzFLCGiydg017/x3UvAyglvYt545YmPOjhaVmsl50v9j3AvVnATNOCrl8USGa4Rgnz5SIAjqWfjVZCE7X4QKKTBby8JYf4JvDcwe9Pmmi6Qdu08GWEfmHiZwISIun681zM2MDTynlmLGg= Content-Type: multipart/alternative; boundary="_000_BYAPR15MB2645047AACDDF8E7410EBE2597FD0BYAPR15MB2645namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4361e045-ff92-4786-7c6a-08d6fab9c69d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 04:41:52.6278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eric.gray@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3382 Archived-At: Subject: Re: [Roll] Last Call Review of draft-ietf-roll-efficient-npdao 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, 27 Jun 2019 04:41:56 -0000 --_000_BYAPR15MB2645047AACDDF8E7410EBE2597FD0BYAPR15MB2645namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnksIHRoaXMgcmV2aWV3IHdhcyBkb25lIGJ5IEVyaWMgR3JheSwgbm90IEFuZHkgTWFsaXMu ICDimLkNCg0KRnJvbTogRXJpYyBHcmF5DQpTZW50OiBUaHVyc2RheSwgSnVuZSAyNywgMjAxOSAx Mjo0MSBBTQ0KVG86IGRyYWZ0LWlldGYtcm9sbC1lZmZpY2llbnQtbnBkYW9AaWV0Zi5vcmcNCkNj OiBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSA8YXJldGFuYUBjaXNjby5jb20+OyByb2xsQGlldGYu b3JnDQpTdWJqZWN0OiBMYXN0IENhbGwgUmV2aWV3IG9mIGRyYWZ0LWlldGYtcm9sbC1lZmZpY2ll bnQtbnBkYW8NCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtz IHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1l cyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJv dmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUgaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRob3VnaCB0aGVzZSBj b21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQg d291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFu eSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3Ry aXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhl IGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhbw0KUmV2 aWV3ZXI6IEFuZHkgTWFsaXMNClJldmlldyBEYXRlOiAyNiBKdW5lIDIwMTkNCklFVEYgTEMgRW5k IERhdGU6IDI2IEp1bmUgMjAxOQ0KSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sNCg0K U3VtbWFyeToNClBlcmhhcHMgSSBhbSBtaXNzaW5nIHNvbWUgc3VidGxldGllcywgYnV0IHRoaXMg ZG9jdW1lbnQgbG9va3MgbGlrZSBpdCBtYXkgbmVlZCBhIGxpdHRsZSBtb3JlIHdvcmsgYmVmb3Jl IGl0IGlzIHB1Ymxpc2hlZC4NCg0KT3ZlcmFsbCBjb21tZW50czoNClRoZSBkb2N1bWVudCBpcyBt b3N0bHkgd2VsbCB3cml0dGVuLg0KDQpJc3N1ZXM6DQoNCkluIHRoZSBpbnRyb2R1Y3Rpb24sIEkg aGF2ZSBzb21lIHRyb3VibGUgcGFyc2luZyDigJxhbiBvcHRpb25hbCBtZXNzYWdpbmfigJ0g4oCT IHBlcmhhcHMgaXQgd2FzIG1lYW50IHRvIGp1c3QgYmUg4oCcb3B0aW9uYWwgbWVzc2FnaW5nP+KA nQ0KDQpUaGVyZSBhcmUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBhYnN0cmFjdCAod2hpY2ggY2xh aW1zIHRoZSBkb2N1bWVudCBkZXNjcmliZXMgaXNzdWVzIHdpdGggTlBEQU8pIGFuZCB0aGUgSW50 cm9kdWN0aW9uICh3aGljaCBnb2VzIGZ1cnRoZXIgdG8gc2F5IHRoYXQgdGhlIGRvY3VtZW50IGFs c28gZGlzY3Vzc2VzIHJlcXVpcmVtZW50cyBhbmQgc3BlY2lmaWVzIGEgbmV3IG1lc3NhZ2UgaW50 ZW5kZWQgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIGFuZCBzb2x2ZSB0aGUgcHJvYmxlbXMuDQoN ClNvLCBpdOKAmXMgYSBwcm9ibGVtIHN0YXRlbWVudCwgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGFu ZCBzb2x1dGlvbiBzcGVjaWZpY2F0aW9uIGFsbCByb2xsZWQgaW50byBvbmUuICBJIGd1ZXNzIHRo aXMgaXMgbm90IGEgcHJvYmxlbSBmb3IgYW55b25lIGluIHRoZSBXRz8NCg0KVGhlIHRpdGxlIGZv ciBzZWN0aW9uIDEuMyBzaG91bGQgcHJvYmFibHkgYmUg4oCcV2h5IGlzIE5QREFPIEltcG9ydGFu dC7igJ0NCg0KSW4gdGhhdCBzZWN0aW9uLCBJIGhhdmUgdG8gd29uZGVyIGlmIHNhdmluZyBtZW1v cnkgaXMgdGhlIG1vc3QgaW1wb3J0YW50IGZhY3RvciBpbiByZW1vdmluZyByb3V0ZSBpbmZvcm1h dGlvbiB0aGF0IGlzIG5vIGxvbmdlciB2YWxpZC4gIFdoYXQgYWJvdXQgaXNzdWVzIHdpdGggZm9y d2FyZGluZyBwYWNrZXRzIHRvd2FyZCBkZXN0aW5hdGlvbnMgdGhhdCBjYW4gbm8gbG9uZ2VyIGJl IHJlYWNoZWQgYWxvbmcgdGhhdCBwYXRoPw0KDQpQZXJoYXBzIEkgbWlzdW5kZXJzdGFuZCB0aGUg YXBwcm9hY2gsIGJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBwcm9ibGVtcyBtZW50aW9uZWQg aW4gc2VjdGlvbiAyLjEgc2hvdWxkIHNlbGYtcmVzb2x2ZS4gIFRoZSBmYWN0IHRoYXQgb25lIG5v ZGUgY2Fubm90IHNlbmQgbWVzc2FnZXMgdG8gYW5vdGhlciBub2RlIHRvIGluZm9ybSB0aGF0IG5v ZGUgdGhhdCBpdCBoYXMgbm8gREFPIGluZm9ybWF0aW9uIHNlZW1zIGtpbmQgb2YgaXJyZWxldmFu dCBpZiB0aGUgbm9kZSwgb3IgdGhlIGxpbmsgY29ubmVjdGluZyBpdCwgaXMgbm8gbG9uZ2VyIHRo ZXJlLg0KDQpQZXJoYXBzIHRoZSBpc3N1ZSB5b3XigJlyZSByZWFsbHkgdHJ5aW5nIHRvIGRlc2Ny aWJlIGlzIHdpdGggdW5yZWxpYWJsZSBsaW5rcyBhbmQgbm9kZXMsIGFzIG9wcG9zZWQgdG8gbWlz c2luZyBsaW5rcyBhbmQgbm9kZXM/ICBUaGF0IHdvdWxkIG1ha2Ugc2Vuc2UgaW4gYSBsb3ctcG93 ZXIgYW5kIGxvc3N5IG5ldHdvcmsuDQoNCklmIHRoZSBiZWhhdmlvciBkZXNjcmliZWQgaW4gc2Vj dGlvbiAyLjIgaXMgY29tbW9uLCBhbmQgYSBtb3JlIHJlYXNvbmFibGUgYmVoYXZpb3IgaXMgbm90 IGFudGljaXBhdGVkIGJ5IHRoZSBvcmlnaW5hbCBOUERBTyBzcGVjaWZpY2F0aW9uLCB0aGFuIEkg YWdyZWUgdGhhdCBpcyBhIHByb2JsZW0uDQoNCklmIHRoZSBwcm9ibGVtcyBkZXNjcmliZWQgaW4g Mi4xIGFuZCAyLjMgZG8gZXhpc3QsIGl0IHNlZW1zIGxpa2VseSB0aGF0IHRoZSB1bmRlcmx5aW5n IGlzc3VlIGlzIHJlYWxseSBhYm91dCBhbiBhc3N1bXB0aW9uIG9mIHJlbGlhYmxlIGRlbGl2ZXJ5 IHdoZXJlIHRoYXQgbWlnaHQgbm90IGJlIHRoZSByZWFsaXR5Lg0KDQpBbGwgb2YgdGhpcyBzYWlk LCB0aGUgMyByZXF1aXJlbWVudHMgc2VlbSByZWFzb25hYmxlIGF0IGxlYXN0IGFzIGZhciBhcyB0 aGV5IGdvLiAgVGhlcmUgc2VlbXMgdG8gYmUgYW4gaW1wbGllZCByZXF1aXJlbWVudCB0byBpbnRy b2R1Y2UgYXQgbGVhc3Qgc29tZSBsZXZlbCBvZiByZWxpYWJpbGl0eSAoYXMgSSBzZWVtcyBpbnRl bmRlZCBieSBwcm92aWRpbmcgdGhlIERDTy1BQ0spLiBBbmQgdGhlcmUgcHJvYmFibHkgc2hvdWxk IGJlIGEgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBjb21wYXRpYmlsaXR5IHdpdGggZGVwbG95ZWQg aW1wbGVtZW50YXRpb25zLg0KDQpBRkFJQ1QsIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVzY3Jp YmUgaG93IG5vZGVzIHVzaW5nIHRoZSBuZXdseSBzcGVjaWZpZWQgbWVzc2FnaW5nIGFuZCBiZWhh dmlvciB3b3VsZCBiZSBjb21wYXRpYmxlIHdpdGggZGVwbG95ZWQgbm9kZXMuICBNaW5pbWFsbHkg dGhlIGRvY3VtZW50IHNob3VsZCBiZSBjbGVhciBpZiB0aGUgaW50ZW50aW9uIGlzIG5vdCB0byBw cm92aWRlIGZvciBjb21wYXRpYmlsaXR5LiAgVGhlcmUgYXJlIGF0IGxlYXN0IGEgY291cGxlIG9m IGluZGljYXRpb25zIHRoYXQgdGhlcmUgaXMgZGVwbG95bWVudC4NCg0KDQoNCg== --_000_BYAPR15MB2645047AACDDF8E7410EBE2597FD0BYAPR15MB2645namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb3JyeSwgdGhpcyByZXZpZXcg d2FzIGRvbmUgYnkgRXJpYyBHcmF5LCBub3QgQW5keSBNYWxpcy4mbmJzcDsgPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPg0K4pi5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IEVyaWMgR3JheSA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEp1bmUgMjcsIDIwMTkgMTI6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+IGRyYWZ0LWlldGYtcm9s bC1lZmZpY2llbnQtbnBkYW9AaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IEFsdmFybyBSZXRhbmEg KGFyZXRhbmEpICZsdDthcmV0YW5hQGNpc2NvLmNvbSZndDs7IHJvbGxAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gTGFzdCBDYWxsIFJldmlldyBvZiBkcmFmdC1pZXRmLXJvbGwtZWZmaWNp ZW50LW5wZGFvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUg YmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhp cyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0 aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBs YXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVz dC4NCiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0 byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5n IERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRm Lm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPC9hPjxicj4NCjxicj4NCkFsdGhvdWdoIHRoZXNl IGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBp dCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGgg YW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBz dHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0 aGUgZHJhZnQuPGJyPg0KPGJyPg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtcm9sbC1lZmZpY2llbnQt bnBkYW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJldmlld2VyOiBBbmR5 IE1hbGlzPGJyPg0KUmV2aWV3IERhdGU6IDI2IEp1bmUgMjAxOTxicj4NCklFVEYgTEMgRW5kIERh dGU6IDI2IEp1bmUgMjAxOTxicj4NCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrPGJy Pg0KPGJyPg0KU3VtbWFyeTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBl cmhhcHMgSSBhbSBtaXNzaW5nIHNvbWUgc3VidGxldGllcywgYnV0IHRoaXMgZG9jdW1lbnQgbG9v a3MgbGlrZSBpdCBtYXkgbmVlZCBhIGxpdHRsZSBtb3JlIHdvcmsgYmVmb3JlIGl0IGlzIHB1Ymxp c2hlZC48YnI+DQo8YnI+DQpPdmVyYWxsIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIGRvY3VtZW50IGlzIG1vc3RseSB3ZWxsIHdyaXR0ZW4uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklzc3Vlczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhl IGludHJvZHVjdGlvbiwgSSBoYXZlIHNvbWUgdHJvdWJsZSBwYXJzaW5nIOKAnGFuIG9wdGlvbmFs IG1lc3NhZ2luZ+KAnSDigJMgcGVyaGFwcyBpdCB3YXMgbWVhbnQgdG8ganVzdCBiZSDigJxvcHRp b25hbCBtZXNzYWdpbmc/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBkaWZm ZXJlbmNlIGJldHdlZW4gdGhlIGFic3RyYWN0ICh3aGljaCBjbGFpbXMgdGhlIGRvY3VtZW50IGRl c2NyaWJlcyBpc3N1ZXMgd2l0aCBOUERBTykgYW5kIHRoZSBJbnRyb2R1Y3Rpb24gKHdoaWNoIGdv ZXMgZnVydGhlciB0byBzYXkgdGhhdCB0aGUgZG9jdW1lbnQgYWxzbyBkaXNjdXNzZXMgcmVxdWly ZW1lbnRzIGFuZCBzcGVjaWZpZXMgYSBuZXcgbWVzc2FnZSBpbnRlbmRlZCB0byBtZWV0DQogdGhl IHJlcXVpcmVtZW50cyBhbmQgc29sdmUgdGhlIHByb2JsZW1zLiA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U28sIGl04oCZcyBhIHByb2JsZW0gc3RhdGVtZW50LCByZXF1aXJlbWVudHMgZG9jdW1l bnQgYW5kIHNvbHV0aW9uIHNwZWNpZmljYXRpb24gYWxsIHJvbGxlZCBpbnRvIG9uZS4mbmJzcDsg SSBndWVzcyB0aGlzIGlzIG5vdCBhIHByb2JsZW0gZm9yIGFueW9uZSBpbiB0aGUgV0c/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0aXRsZSBmb3Igc2VjdGlvbiAxLjMgc2hvdWxkIHByb2Jh Ymx5IGJlIOKAnFdoeSBpcyBOUERBTyBJbXBvcnRhbnQu4oCdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIHRoYXQgc2VjdGlvbiwgSSBoYXZlIHRvIHdvbmRlciBpZiBzYXZpbmcgbWVtb3J5IGlz IHRoZSBtb3N0IGltcG9ydGFudCBmYWN0b3IgaW4gcmVtb3Zpbmcgcm91dGUgaW5mb3JtYXRpb24g dGhhdCBpcyBubyBsb25nZXIgdmFsaWQuJm5ic3A7IFdoYXQgYWJvdXQgaXNzdWVzIHdpdGggZm9y d2FyZGluZyBwYWNrZXRzIHRvd2FyZCBkZXN0aW5hdGlvbnMgdGhhdCBjYW4gbm8gbG9uZ2VyIGJl IHJlYWNoZWQgYWxvbmcgdGhhdA0KIHBhdGg/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcmhh cHMgSSBtaXN1bmRlcnN0YW5kIHRoZSBhcHByb2FjaCwgYnV0IGl0IHNlZW1zIHRvIG1lIHRoYXQg dGhlIHByb2JsZW1zIG1lbnRpb25lZCBpbiBzZWN0aW9uIDIuMSBzaG91bGQgc2VsZi1yZXNvbHZl LiZuYnNwOyBUaGUgZmFjdCB0aGF0IG9uZSBub2RlIGNhbm5vdCBzZW5kIG1lc3NhZ2VzIHRvIGFu b3RoZXIgbm9kZSB0byBpbmZvcm0gdGhhdCBub2RlIHRoYXQgaXQgaGFzIG5vIERBTyBpbmZvcm1h dGlvbiBzZWVtcw0KIGtpbmQgb2YgaXJyZWxldmFudCBpZiB0aGUgbm9kZSwgb3IgdGhlIGxpbmsg Y29ubmVjdGluZyBpdCwgaXMgbm8gbG9uZ2VyIHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QZXJoYXBzIHRoZSBpc3N1ZSB5b3XigJlyZSByZWFsbHkgdHJ5aW5nIHRvIGRlc2NyaWJlIGlz IHdpdGggdW5yZWxpYWJsZSBsaW5rcyBhbmQgbm9kZXMsIGFzIG9wcG9zZWQgdG8gbWlzc2luZyBs aW5rcyBhbmQgbm9kZXM/Jm5ic3A7IFRoYXQgd291bGQgbWFrZSBzZW5zZSBpbiBhIGxvdy1wb3dl ciBhbmQgbG9zc3kgbmV0d29yay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIGJlaGF2 aW9yIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIuMiBpcyBjb21tb24sIGFuZCBhIG1vcmUgcmVhc29u YWJsZSBiZWhhdmlvciBpcyBub3QgYW50aWNpcGF0ZWQgYnkgdGhlIG9yaWdpbmFsIE5QREFPIHNw ZWNpZmljYXRpb24sIHRoYW4gSSBhZ3JlZSB0aGF0IGlzIGEgcHJvYmxlbS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgdGhlIHByb2JsZW1zIGRlc2NyaWJlZCBpbiAyLjEgYW5kIDIuMyBkbyBl eGlzdCwgaXQgc2VlbXMgbGlrZWx5IHRoYXQgdGhlIHVuZGVybHlpbmcgaXNzdWUgaXMgcmVhbGx5 IGFib3V0IGFuIGFzc3VtcHRpb24gb2YgcmVsaWFibGUgZGVsaXZlcnkgd2hlcmUgdGhhdCBtaWdo dCBub3QgYmUgdGhlIHJlYWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCBvZiB0aGlz IHNhaWQsIHRoZSAzIHJlcXVpcmVtZW50cyBzZWVtIHJlYXNvbmFibGUgYXQgbGVhc3QgYXMgZmFy IGFzIHRoZXkgZ28uJm5ic3A7IFRoZXJlIHNlZW1zIHRvIGJlIGFuIGltcGxpZWQgcmVxdWlyZW1l bnQgdG8gaW50cm9kdWNlIGF0IGxlYXN0IHNvbWUgbGV2ZWwgb2YgcmVsaWFiaWxpdHkgKGFzIEkg c2VlbXMgaW50ZW5kZWQgYnkgcHJvdmlkaW5nIHRoZSBEQ08tQUNLKS4gQW5kIHRoZXJlIHByb2Jh Ymx5DQogc2hvdWxkIGJlIGEgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBjb21wYXRpYmlsaXR5IHdp dGggZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BRkFJ Q1QsIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVzY3JpYmUgaG93IG5vZGVzIHVzaW5nIHRoZSBu ZXdseSBzcGVjaWZpZWQgbWVzc2FnaW5nIGFuZCBiZWhhdmlvciB3b3VsZCBiZSBjb21wYXRpYmxl IHdpdGggZGVwbG95ZWQgbm9kZXMuJm5ic3A7IE1pbmltYWxseSB0aGUgZG9jdW1lbnQgc2hvdWxk IGJlIGNsZWFyIGlmIHRoZSBpbnRlbnRpb24gaXMgbm90IHRvIHByb3ZpZGUgZm9yIGNvbXBhdGli aWxpdHkuJm5ic3A7IFRoZXJlDQogYXJlIGF0IGxlYXN0IGEgY291cGxlIG9mIGluZGljYXRpb25z IHRoYXQgdGhlcmUgaXMgZGVwbG95bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR15MB2645047AACDDF8E7410EBE2597FD0BYAPR15MB2645namp_-- From nobody Wed Jun 26 22:54:05 2019 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 93F0D1200FF for ; Wed, 26 Jun 2019 22:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MdyKbcLh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Ilcc/cSy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8-trQUhmQR6 for ; Wed, 26 Jun 2019 22:54:01 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CC61200B6 for ; Wed, 26 Jun 2019 22:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7115; q=dns/txt; s=iport; t=1561614841; x=1562824441; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AripIfGmY2Z9tQgMXoZOuYr/jnIQvyji0ew9I5k6DPE=; b=MdyKbcLh2KZSaKfu5B/3GxCv/WEUomH8FgZQvRXm7oz2gOmDmEZTZ/85 s5bVG9UQyElzXZF/dwJG6sPHH6dMx91sgnPpr3aYn1HAWFNFRlTw8D+4E 5zSM9PQqFLGe4itJSh6OlpLlBYBDJFDPHeB32Iq0fPLV9OXB6Lq0Jon1z Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AkVeUyhXy1hr0vbm6nzO9TlZVRiTV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankiAMRfXlJ/41mwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AAA2WRRd/5BdJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVQQBAQELAYEULyQsA2pVIAQLKIdgA45bgluSaoRUgS6BJANUCQE?= =?us-ascii?q?BAQwBAS0CAQGEQAKCfSM2Bw4BAwEBBAEBAgEFbYo3DIVKAQEBBBIbEwEBNwE?= =?us-ascii?q?PAgEIEQQBAS8yHQgBAQQOBQgagwGBHU0DHQECmi8CgTiIX4IjgnkBAQWFChi?= =?us-ascii?q?CEQmBNAGEcYZtF4FAP4ERRoJMPoQoHoM6giaTVHyVVAkCgheUDYIqhxKOGqR?= =?us-ascii?q?EAgQCBAUCDgEBBYFXAy6BWHAVgyeCQYNwilNygSmOBgEB?= X-IronPort-AV: E=Sophos;i="5.63,422,1557187200"; d="scan'208,217";a="571101275" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jun 2019 05:54:00 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x5R5rxea013347 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jun 2019 05:54:00 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 00:53:59 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 00:53:59 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Jun 2019 01:53:58 -0400 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=Ttgj9pdqn8RTwLywjW1TaN5cH5Lf2sMt1vHbwHwRC6p8IfFRaHTTQmsrfE4lPX+NBMGODLt6FtUVYefQtW+wfBQFT3Sh/wt90ZcFwlwZaLjzyRvcQpl/SCULMIT7wrsZsG0/Z5m1yldam/TALfiOmfuiigeaKbEPCFFv8eke140= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I8+9nmJlcnYYQQyE2lS+TVsV2E+PeQEZgpnXSzjK3Ag=; b=oGIFbKO0n4PHhDNNdHwj9LwnIZow5+jQ6nEa+XFQa2/0L46BGMmbEJ6vMyY29jtfOhNhRtaIj4cUv/+d3R6FYvd/IfzUckmVq0ZGPt1rb73YxcNPCZXsr8UegH3YYCWOaAcBKYi4TUoOvpygFJixX8Hsq9aldSY0100orXk94tY= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I8+9nmJlcnYYQQyE2lS+TVsV2E+PeQEZgpnXSzjK3Ag=; b=Ilcc/cSyhELSxR4MLqEIS9ueRpKiOUIvska6Ngid/xjWQRT8b36UhWaPFhtZQL6R7IwKnTP9TJIHUawMQtqooZT16nLe9p1kZTX8vxa7PpUHJiwGNxOPQZAVISdfNUEfnA/HdJkVt0xrbJVhRLByWAYJW/GjNFaWqrlqbjGNyoo= Received: from BYAPR11MB3558.namprd11.prod.outlook.com (20.178.206.75) by BYAPR11MB2903.namprd11.prod.outlook.com (20.177.225.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 05:53:43 +0000 Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::2ce6:329e:e7f1:5b4a]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::2ce6:329e:e7f1:5b4a%7]) with mapi id 15.20.2008.018; Thu, 27 Jun 2019 05:53:43 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: Retrying DCO/DAO, retry parameters Thread-Index: AdUshAoU1ZNXDKIJRSu3/AosXtsQyAAJ73yQ Date: Thu, 27 Jun 2019 05:53:36 +0000 Deferred-Delivery: Thu, 27 Jun 2019 05:52:43 +0000 Message-ID: References: <982B626E107E334DBE601D979F31785C5DF0BFA2@BLREML503-MBX.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DF0BFA2@BLREML503-MBX.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1006::89] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 91b65d63-f39b-4451-7f1f-08d6fac3cfea x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2903; x-ms-traffictypediagnostic: BYAPR11MB2903: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(136003)(366004)(199004)(53754006)(189003)(99286004)(86362001)(66574012)(46003)(6916009)(64756008)(66556008)(66476007)(52536014)(66446008)(66946007)(478600001)(4326008)(81166006)(229853002)(7696005)(25786009)(81156014)(8936002)(33656002)(6116002)(790700001)(2906002)(6436002)(446003)(8676002)(55016002)(486006)(54896002)(76176011)(256004)(9686003)(11346002)(6666004)(316002)(71190400001)(53936002)(71200400001)(76116006)(14454004)(186003)(5660300002)(6306002)(53546011)(6246003)(7736002)(6506007)(102836004)(73956011)(74316002)(476003)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2903; H:BYAPR11MB3558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: A0Z4dSClt2xc/NcJT16Mot1UwNxFUcf0VkxC55HJgnmQgPGRzpa5kIjpPYrLSQgwTqI9rV0Iw3ZcZ9nW3Ib5XZ1I7x6d2TIG5bDceKiZsSWnCSoQR5Q6fy+kJ4EAulZKQ6asCwiLfVT7zy9SJbbJUJk8vMZrbQ8uiE1QdGFulRypK0sTGVzXa+ixjMyf7ConEzlR0mhw6AIi6kzY7GCwhmUZiQjAk/Xhw5h0/riSD6VGsK+sRQNEOKAm3jd833QmeWUrXkhN3I9+7KhAE1wDciK9QAvTeqCjqIg66QRDQ/nW5N1DXNfhCYv1c4n0H1JO5KF4KmOK1FV30BBZG2frIy2vo6LXSPP95s19F7tPQWMT03QWaNHxDgCm1NzbIetGyGthbSs7v+ISNUFGjuBcU2wwZ6D4ZmUC+4nX3ElfN7A= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3558B443C789222A7604184ED8FD0BYAPR11MB3558namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 91b65d63-f39b-4451-7f1f-08d6fac3cfea X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 05:53:43.1623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2903 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Roll] Retrying DCO/DAO, retry parameters 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, 27 Jun 2019 05:54:04 -0000 --_000_BYAPR11MB3558B443C789222A7604184ED8FD0BYAPR11MB3558namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Rahul RPL is designed to operate in very different environment, and some LLNs can= be very slow, very lossy or even both. This is why RFC 6550 refrains from = being too specific. Maybe it is good enough to add text indicating that the values used for DCO= are expected to be similar/consistent with those used in DAO? All the best, Pascal From: Roll On Behalf Of Rahul Arvind Jadhav Sent: jeudi 27 juin 2019 03:03 To: Routing Over Low power and Lossy networks Cc: Mirja K=FChlewind Subject: [Roll] Retrying DCO/DAO, retry parameters Hello All, During IESG evaluation of (draft-ietf-roll-efficient-npdao-12) we received = a comment from Mirja regarding specifying the DCO retry operation in detail= if DCO-ACK is not received. Quoting her verbatim, "Please specify a maximu= m number of retries and also a minimum retry interval (of e.g. 3 sec best w= ith exponential back-off)!" Currently the draft says that this is "implementation and deployment depend= ent". RFC 6550 also has DAO retries if DAO-ACK is not received but it also does n= ot specify this operation in detail. Do you think we can put this explicitly and does anyone have an opinion on= the right way of putting this considering different physical layers with v= ery different characteristics operating in dense/sparse (wireless) deployme= nts? Thanks, Rahul --_000_BYAPR11MB3558B443C789222A7604184ED8FD0BYAPR11MB3558namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hello Rahul

     

    RPL is designed to operate in very different environ= ment, and some LLNs can be very slow, very lossy or even both. This is why = RFC 6550 refrains from being too specific.

    Maybe it is good enough to add text indicating that = the values used for DCO are expected to be similar/consistent with those us= ed in DAO?

     

    All the best,

     

    Pascal

     

    From: Roll <roll-bounces@ietf.org> O= n Behalf Of Rahul Arvind Jadhav
    Sent: jeudi 27 juin 2019 03:03
    To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Cc: Mirja K=FChlewind <ietf@kuehlewind.net>
    Subject: [Roll] Retrying DCO/DAO, retry parameters

     

    Hello All,

     

    During IESG evaluation of (draft-ietf-roll-effici= ent-npdao-12) we received a comment from Mirja regarding specifying the DCO= retry operation in detail if DCO-ACK is not received. Quoting her verbatim= , “Please specify a maximum number of retries and also a minimum retry interval (of e.g. 3 sec best with expo= nential back-off)!”

     

    Currently the draft says that this is “impleme= ntation and deployment dependent”.

    RFC 6550 also has DAO retries if DAO-ACK is not rece= ived but it also does not specify this operation in detail.

     

    Do you think we can put this explicitly  and do= es anyone have an opinion on the right way of putting this considering diff= erent physical layers with very different characteristics operating in dens= e/sparse (wireless) deployments?

     

    Thanks,

    Rahul

    --_000_BYAPR11MB3558B443C789222A7604184ED8FD0BYAPR11MB3558namp_-- From nobody Thu Jun 27 00:57:11 2019 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 0E75A12024E; Thu, 27 Jun 2019 00:57:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, consultancy@vanderstok.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156162222904.21361.4930374476172246281.idtracker@ietfa.amsl.com> Date: Thu, 27 Jun 2019 00:57:09 -0700 Archived-At: Subject: [Roll] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-roll-efficient-npdao-12=3A_=28with_COMMENT=29?= 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: Thu, 27 Jun 2019 07:57:09 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-roll-efficient-npdao-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you all for the work put into this clear and well-written document. I have only one COMMENT: DCO should be mentioned in the abstract as the document goes beyond a problem description (as currently described in the abstract). From nobody Thu Jun 27 04:35:22 2019 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 A68001200B8; Thu, 27 Jun 2019 04:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, 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=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 aKxWW2HMh3nP; Thu, 27 Jun 2019 04:35:19 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 0A09E1200FB; Thu, 27 Jun 2019 04:35:19 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id k21so6755218edq.3; Thu, 27 Jun 2019 04:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=vI/uWl1cgvesaB8DJqpRiREJmzM+WI1gBo5MDSc7JvA=; b=FaPx30ilEaWcMRp8JksU9bA8Q4OkEEauqlV4tT5iZp7K2+MgffF27dRMkdMACYi+Bx j0cGojtcrGWMoakkCWka1BGJV81c2TGobfHyWsn19rT3cDjJQwHrrIBiTY1ko7cLSE+B fXp6KRB8fuVXZTVOk0V4t47a8LUu3Sa9pRYi9tXjTk11BWjDup2o2oLVD1aGkR49hngA a6jAROS8JE4tE7cj5BIoJBwcyqXskiAFZpvw6JnZtgVRAHDGpGTwXwU0hYZ4VRL+Ky9C EjJI5AP2BFEudCtFaatMqXcNp7ow4UNAgGRWzJs9VIukQok079aMxrrg/odzO5vsAdfj 7mfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=vI/uWl1cgvesaB8DJqpRiREJmzM+WI1gBo5MDSc7JvA=; b=DCXWJn7MJ5BVdiTj88VRsmkSOFGpVj1YGN2KNwdsvMSBVfwrOKFeOK9hi5tdTXDIT4 XxvHleteea+jbKfP4Ko1oz6H+phozKa6VW58jtnbEWQJjNPP5IeIR70wZgZhYo8bg6tI a/99/SO07SYB688A7yRtfUNgxow7Knuy2Ps1PTj740LkGyam3ftOvlG4fsIBQSZEhnYx ohQq0vYUbTYX6EtpTqkqXH2z3Smd/m2fCc+XUqiwMiHx7X6kKZadtqFW7IzxP/kCH6Qo b3TtnMjjWaeCxWUVj7SN3h6wrK4wVRLWivdFC/5M6NwIOyLiOkhdcgI0kaqQe7MSD03C 3/dg== X-Gm-Message-State: APjAAAXn5eC8rVyxxV6sw3V9uAjlQme5JoyFkGMQTn35XQJKZ62smeys v5qRqOVObkuknuUUeLCCoo+SwblALE/KRLxBEsQ= X-Google-Smtp-Source: APXvYqw9XA0XIySAxfw3Sn2F4QFw+uHNhH7bBaiUKP91EIeqEPi//qrkpCnt/PHcBHNtfoErIWQaTUFKOnLG3ZFhFBQ= X-Received: by 2002:a17:906:e241:: with SMTP id gq1mr2599526ejb.265.1561635317614; Thu, 27 Jun 2019 04:35:17 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 27 Jun 2019 07:35:17 -0400 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 27 Jun 2019 07:35:17 -0400 Message-ID: To: Eric Gray , "draft-ietf-roll-efficient-npdao@ietf.org" Cc: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000600fd5058c4c8ebf" Archived-At: Subject: Re: [Roll] Last Call Review of draft-ietf-roll-efficient-npdao 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, 27 Jun 2019 11:35:21 -0000 --000000000000600fd5058c4c8ebf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On June 27, 2019 at 12:42:03 AM, Eric Gray (eric.gray@ericsson.com) wrote: Eric: Hi! So, it=E2=80=99s a problem statement, requirements document and solution specification all rolled into one. I guess this is not a problem for anyone in the WG? Nope. In fact, I think that for problems like this one where the result is an enhancement to the protocol, this type of all-in-one document is ideal and more efficient. Thanks! Alvaro. --000000000000600fd5058c4c8ebf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    On June 27, 2019 at 12:42:03 AM, Eric Gray (eric.gray@ericsson.com) wrote:

    Eric:

    Hi!

    So, it=E2=80=99s a problem statement, requir= ements document and solution specification all rolled into one.=C2=A0 I gue= ss this is not a problem for anyone in the WG?

    Nope.=C2=A0 In fact, I think that for p= roblems like this one where the result is an enhancement to the protocol, t= his type of all-in-one document is ideal and more efficient.

    <= font face=3D"Helvetica">Thanks!

    Alvar= o.

    --000000000000600fd5058c4c8ebf-- From nobody Thu Jun 27 05:53:10 2019 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 DF26A120452; Thu, 27 Jun 2019 05:53:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, roll-chairs@ietf.org, consultancy@vanderstok.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <156163998890.21568.17755918950369424230.idtracker@ietfa.amsl.com> Date: Thu, 27 Jun 2019 05:53:08 -0700 Archived-At: Subject: [Roll] Martin Vigoureux's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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: Thu, 27 Jun 2019 12:53:09 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-roll-efficient-npdao-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, thank you for this document. I only have minor comments/questions: * Please expand LLNs * it's a bit pity that D flag is bit '0' in DCO and bit '1' in DCO-ACK * 0x05 RPL Target and 0x06 Transit Information are RPL Control Message Options but they are not really DCO Options as they MUST be present. * it is not fully clear to me whether Path Sequence can or should be incremented on DCO retry. * I'm not sure this has any meaning (didn't have enough time to think about this scenario) but what would happen if D sends a DAO which never reaches A and A decides to send an unsolicited DCO. How would D react to receiving a message with a sequence number which is smaller than the one it has sent? Is that an issue? * I feel that imposing the unused flags to be set to zero is not necessary. MUST ignore the unspecified flags is sufficient. From nobody Thu Jun 27 06:12:38 2019 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 7E5E41200B3; Thu, 27 Jun 2019 06:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ericsson.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 yQcxZTmqdvcd; Thu, 27 Jun 2019 06:12:34 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720054.outbound.protection.outlook.com [40.107.72.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC3A120043; Thu, 27 Jun 2019 06:12:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=h6mYKZZlNlh92CZM1a38Mxu5tRYS/j7vDPBnOcacTu0N9nmsYmcjm7oxxK1fhh9wgNu5BFeOxGOFeig9gDLqmaNgZVNx2kKSJsRTKUysl5CTamMkkwMtlzPMlrMkbviEi6v9kjYQ7ggk0Wwx57x4zX7PNR90TOCbJ7H10BvmTF8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LfJ2j+KkDgxUnsDByhRmzhGOJbqc4jH1jdm3OCm/w+8=; b=rd8o9Ah2Lgk9ndIdOkiFnUpkPhAubHan7NDAn0cAI3toonBnNkG67NjWFzA4enx0nnWda6IrNlJds2v2Ytv8eR9dg8Y0yYVCsK6SijBnT/PVzL7C7ubeookMcvUVbRLWoaaYa6OIIYyAl5rMNyz4aR+4VyIZxGRrcT0h7F4h/lE= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LfJ2j+KkDgxUnsDByhRmzhGOJbqc4jH1jdm3OCm/w+8=; b=jnYjlIY2VQ+Hd38JkE8Bm9ZClaEOsUAWvrvf6AVMviFSQus2aDvKoRju6C6Jym8CUioK2wX2Vqni3tms6O284VLbn/x1waBxlWMGRnIXqyLMA4YyByDJPfOseBfe5zwh9TEwwh9Rem0g0RMcQOxGTNQw3QPKjJob8Isv609gQxM= Received: from BN8PR15MB2644.namprd15.prod.outlook.com (20.179.138.27) by BN8PR15MB2769.namprd15.prod.outlook.com (20.179.139.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 13:12:30 +0000 Received: from BN8PR15MB2644.namprd15.prod.outlook.com ([fe80::155b:861f:389b:3434]) by BN8PR15MB2644.namprd15.prod.outlook.com ([fe80::155b:861f:389b:3434%7]) with mapi id 15.20.2008.018; Thu, 27 Jun 2019 13:12:30 +0000 From: Eric Gray To: Alvaro Retana , "draft-ietf-roll-efficient-npdao@ietf.org" CC: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Last Call Review of draft-ietf-roll-efficient-npdao Thread-Index: AdUsWXgVYOX7Pfh+Snm71nZC5c50NwASRBbwAA53DYAAA13lgA== Date: Thu, 27 Jun 2019 13:12:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eric.gray@ericsson.com; x-originating-ip: [2601:85:4680:3329:5537:9346:268e:f64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7fd2dd1a-7698-461d-04da-08d6fb011c32 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN8PR15MB2769; x-ms-traffictypediagnostic: BN8PR15MB2769: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(39860400002)(366004)(136003)(199004)(189003)(51444003)(54896002)(9686003)(316002)(66446008)(6246003)(76116006)(64756008)(86362001)(66476007)(4326008)(46003)(66556008)(73956011)(25786009)(66946007)(68736007)(186003)(6436002)(102836004)(55016002)(6506007)(53546011)(229853002)(33656002)(236005)(14454004)(6306002)(53936002)(7696005)(5660300002)(478600001)(7736002)(256004)(99286004)(790700001)(6116002)(74316002)(2906002)(52536014)(476003)(8676002)(446003)(81166006)(81156014)(76176011)(11346002)(71200400001)(8936002)(4744005)(71190400001)(2501003)(110136005)(486006)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR15MB2769; H:BN8PR15MB2644.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: D4GuQBiPktx3PvFyLIxuuS9IqooutCWP+Twi9Pd8bm2Q/F3tyn28sYirrJPu6FxzGCUJU1f2DHTbQfOpfEEILCgxt+kCn4m5sKImLlzdKJE4E44EeJdEPatITIHWh/5Owk53kguF4KNYRTrcIx6AvpfTals0eCvlrHq/QAjKilfE5+GA+UFjNSyMhPvH9/syohDpcr40EbZLw0QtgZpogk0sq7dnVkNZGlLouth9fqmJ57iOxXFsUy2lbyWPhUUDvPF7ztbcyKehdC5P2UbQz0tFaz5MhfRQ5ZN1dImX+w8x/b7lf+ceTdDphQePfv6LC237AVVgZKHCRNEtvP3uuQ29oAfcP/ovhpZjh4081hl4PUr7p5v/8+aOifmNAueJlCEErB8tLe33VWf+A+PYmjudnLI54opcMNgyEdJOt+M= Content-Type: multipart/alternative; boundary="_000_BN8PR15MB26442ECFBE6EC9446F1A713A97FD0BN8PR15MB2644namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7fd2dd1a-7698-461d-04da-08d6fb011c32 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 13:12:30.4254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eric.gray@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB2769 Archived-At: Subject: Re: [Roll] Last Call Review of draft-ietf-roll-efficient-npdao 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, 27 Jun 2019 13:12:37 -0000 --_000_BN8PR15MB26442ECFBE6EC9446F1A713A97FD0BN8PR15MB2644namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgd2h5IEkgZGlkIG5vdCBzdGF0ZSB0aGlzIGFzIGFuIGlzc3VlLCBleGFjdGx5LCBi dXQgbW9yZSBhcyBhbiBxdWVyeS4NCg0KRnJvbTogQWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRm QGdtYWlsLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI3LCAyMDE5IDc6MzUgQU0NClRvOiBF cmljIEdyYXkgPGVyaWMuZ3JheUBlcmljc3Nvbi5jb20+OyBkcmFmdC1pZXRmLXJvbGwtZWZmaWNp ZW50LW5wZGFvQGlldGYub3JnDQpDYzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kg bmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1JvbGxdIExhc3QgQ2FsbCBS ZXZpZXcgb2YgZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhbw0KSW1wb3J0YW5jZTogSGln aA0KDQpPbiBKdW5lIDI3LCAyMDE5IGF0IDEyOjQyOjAzIEFNLCBFcmljIEdyYXkgKGVyaWMuZ3Jh eUBlcmljc3Nvbi5jb208bWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nvbi5jb20+KSB3cm90ZToNCg0K RXJpYzoNCg0KSGkhDQoNClNvLCBpdOKAmXMgYSBwcm9ibGVtIHN0YXRlbWVudCwgcmVxdWlyZW1l bnRzIGRvY3VtZW50IGFuZCBzb2x1dGlvbiBzcGVjaWZpY2F0aW9uIGFsbCByb2xsZWQgaW50byBv bmUuICBJIGd1ZXNzIHRoaXMgaXMgbm90IGEgcHJvYmxlbSBmb3IgYW55b25lIGluIHRoZSBXRz8N Cg0KTm9wZS4gIEluIGZhY3QsIEkgdGhpbmsgdGhhdCBmb3IgcHJvYmxlbXMgbGlrZSB0aGlzIG9u ZSB3aGVyZSB0aGUgcmVzdWx0IGlzIGFuIGVuaGFuY2VtZW50IHRvIHRoZSBwcm90b2NvbCwgdGhp cyB0eXBlIG9mIGFsbC1pbi1vbmUgZG9jdW1lbnQgaXMgaWRlYWwgYW5kIG1vcmUgZWZmaWNpZW50 Lg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg== --_000_BN8PR15MB26442ECFBE6EC9446F1A713A97FD0BN8PR15MB2644namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YXTigJlzIHdoeSBJIGRpZCBub3Qgc3RhdGUgdGhpcyBhcyBhbiBpc3N1ZSwgZXhhY3RseSwgYnV0 IG1vcmUgYXMgYW4gcXVlcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQWx2YXJvIFJldGFuYSAmbHQ7YXJldGFu YS5pZXRmQGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDI3 LCAyMDE5IDc6MzUgQU08YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgR3JheSAmbHQ7ZXJpYy5ncmF5QGVy aWNzc29uLmNvbSZndDs7IGRyYWZ0LWlldGYtcm9sbC1lZmZpY2llbnQtbnBkYW9AaWV0Zi5vcmc8 YnI+DQo8Yj5DYzo8L2I+IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtz ICZsdDtyb2xsQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1JvbGxdIExh c3QgQ2FsbCBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhbzxicj4NCjxi PkltcG9ydGFuY2U6PC9iPiBIaWdoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEp1bmUgMjcsIDIwMTkgYXQgMTI6NDI6 MDMgQU0sIEVyaWMgR3JheSAoPGEgaHJlZj0ibWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nvbi5jb20i PmVyaWMuZ3JheUBlcmljc3Nvbi5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkVyaWM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IaSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TbywgaXTi gJlzIGEgcHJvYmxlbSBzdGF0ZW1lbnQsIHJlcXVpcmVtZW50cyBkb2N1bWVudCBhbmQgc29sdXRp b24gc3BlY2lmaWNhdGlvbiBhbGwgcm9sbGVkIGludG8gb25lLiZuYnNwOyBJIGd1ZXNzIHRoaXMg aXMgbm90IGEgcHJvYmxlbSBmb3IgYW55b25lIGluIHRoZSBXRz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ob3BlLiZu YnNwOyBJbiBmYWN0LCBJIHRoaW5rIHRoYXQgZm9yIHByb2JsZW1zIGxpa2UgdGhpcyBvbmUgd2hl cmUgdGhlIHJlc3VsdCBpcyBhbiBlbmhhbmNlbWVudCB0byB0aGUgcHJvdG9jb2wsIHRoaXMgdHlw ZSBvZiBhbGwtaW4tb25lIGRvY3VtZW50IGlzIGlkZWFsIGFuZCBtb3JlIGVmZmljaWVudC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BbHZhcm8uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN8PR15MB26442ECFBE6EC9446F1A713A97FD0BN8PR15MB2644namp_-- From nobody Fri Jun 28 01:37:41 2019 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 202D312018B; Fri, 28 Jun 2019 01:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6stJ7WNXCl2; Fri, 28 Jun 2019 01:37:37 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB42C1200B5; Fri, 28 Jun 2019 01:37:36 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id EE0D13743FFFAC6EAFED; Fri, 28 Jun 2019 09:37:34 +0100 (IST) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 28 Jun 2019 09:37:33 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.118]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0439.000; Fri, 28 Jun 2019 14:07:22 +0530 From: Rahul Arvind Jadhav To: Eric Gray , "draft-ietf-roll-efficient-npdao@ietf.org" CC: "Alvaro Retana (aretana)" , "roll@ietf.org" , Shwetha Bhandari Thread-Topic: Last Call Review of draft-ietf-roll-efficient-npdao Thread-Index: AdUsWXgVYOX7Pfh+Snm71nZC5c50NwASRBbwACvln8A= Date: Fri, 28 Jun 2019 08:37:22 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF0CD01@BLREML503-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DF0CD01BLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Last Call Review of draft-ietf-roll-efficient-npdao 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 Jun 2019 08:37:39 -0000 --_000_982B626E107E334DBE601D979F31785C5DF0CD01BLREML503MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEVyaWMgZm9yIHRoZSByZXZpZXcgYW5kIGZlZWRiYWNrLg0KUmVnYXJkaW5nIGNvbXBh dGliaWxpdHkgd2l0aCBvbGQgZGVwbG95ZWQgbm9kZXMsIHdlIGhhdmUgcmVjZWl2ZWQgc2ltaWxh ciBmZWVkYmFjayAoZnJvbSBTaHdldGhhIEJoYW5kYXJpKSBiZWZvcmUuIE1heSBiZSBpdCBpcyBi ZXR0ZXIgdG8gbWFrZSB0aGlzIGV4cGxpY2l0IGluIHRoZSBkb2N1bWVudC4gUGxlYXNlIGNoZWNr IGlmIHRoZSBzdGF0ZW1lbnQgYmVsb3cgbWFrZXMgc2Vuc2UuDQoNCk5FVw0KICAgICAgICAgICAg ICAgIFRoaXMgZG9jdW1lbnQgYXNzdW1lcyB0aGF0IGFsbCB0aGUgNkxScyBpbiB0aGUgbmV0d29y ayBzdXBwb3J0IHRoaXMgZG9jdW1lbnQuIElmIHRoZXJlIGFyZSA2TFJzIGVuLXJvdXRlIERDTyBt ZXNzYWdpbmcgd2hpY2ggZG8gbm90IHN1cHBvcnQgdGhpcyBkb2N1bWVudCwgdGhlbiB0aGUgcm91 dGUgaW52YWxpZGF0aW9uIGZvciBjb3JyZXNwb25kaW5nIHRhcmdldHMgbWF5IG5vdCB3b3JrIG9y IG1heSB3b3JrIHBhcnRpYWxseSBpLmUuLCBvbmx5IHBhcnQgb2YgdGhlIHBhdGggc3VwcG9ydGlu ZyBEQ08gbWF5IGJlIGludmFsaWRhdGVkLg0KQWx0ZXJuYXRpdmVseSwgYSBub2RlIGNvdWxkIGdl bmVyYXRlIGFuIE5QREFPIGlmIGl0IGRvZXMgbm90IHJlY2VpdmUgYSBEQ08gd2l0aCBpdHNlbGYg YXMgdGFyZ2V0IHdpdGhpbiBhIHNwZWNpZmllZCB0aW1lIGxpbWl0LiBUaGUgc3BlY2lmaWVkIHRp bWUgbGltaXQgaXMgZGVwbG95bWVudCBzcGVjaWZpYyBhbmQgZGVwZW5kcyB1cG9uIHRoZSBtYXhp bXVtIGRlcHRoIG9mIHRoZSBuZXR3b3JrIGFuZCBwZXIgaG9wIGxhdGVuY3kuIE5vdGUgdGhhdCBz ZW5kaW5nIE5QREFPIGFuZCBEQ08gZm9yIHRoZSBzYW1lIG9wZXJhdGlvbiB3b3VsZCBub3QgcmVz dWx0IGluIHVud2FudGVkIHNpZGUtZWZmZWN0cyBhcyBkZXRhaWxlZCBpbiBTZWN0aW9uIDQuNi4y Lg0KRU5EDQoNCkZvciBvdGhlciBjb21tZW50cywgZmluZCBteSByZXNwb25zZXMgaW5saW5lLg0K DQpUaGFua3MsDQpSYWh1bA0KDQpJc3N1ZXM6DQoNCkluIHRoZSBpbnRyb2R1Y3Rpb24sIEkgaGF2 ZSBzb21lIHRyb3VibGUgcGFyc2luZyDigJxhbiBvcHRpb25hbCBtZXNzYWdpbmfigJ0g4oCTIHBl cmhhcHMgaXQgd2FzIG1lYW50IHRvIGp1c3QgYmUg4oCcb3B0aW9uYWwgbWVzc2FnaW5nP+KAnQ0K DQpbUkpdIFllcyB0aGlzIGhhcyB0byBiZSBmaXhlZC4gV2lsbCByZW1vdmUg4oCcYW7igJ0uIFRo aXMgaGFzIGJlZW4gYnJvdWdodCB0byBub3RpY2UgYnkgb3RoZXJzIGFsc28hDQoNClRoZXJlIGFy ZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGFic3RyYWN0ICh3aGljaCBjbGFpbXMgdGhlIGRvY3Vt ZW50IGRlc2NyaWJlcyBpc3N1ZXMgd2l0aCBOUERBTykgYW5kIHRoZSBJbnRyb2R1Y3Rpb24gKHdo aWNoIGdvZXMgZnVydGhlciB0byBzYXkgdGhhdCB0aGUgZG9jdW1lbnQgYWxzbyBkaXNjdXNzZXMg cmVxdWlyZW1lbnRzIGFuZCBzcGVjaWZpZXMgYSBuZXcgbWVzc2FnZSBpbnRlbmRlZCB0byBtZWV0 IHRoZSByZXF1aXJlbWVudHMgYW5kIHNvbHZlIHRoZSBwcm9ibGVtcy4NCg0KU28sIGl04oCZcyBh IHByb2JsZW0gc3RhdGVtZW50LCByZXF1aXJlbWVudHMgZG9jdW1lbnQgYW5kIHNvbHV0aW9uIHNw ZWNpZmljYXRpb24gYWxsIHJvbGxlZCBpbnRvIG9uZS4gIEkgZ3Vlc3MgdGhpcyBpcyBub3QgYSBw cm9ibGVtIGZvciBhbnlvbmUgaW4gdGhlIFdHPw0KDQpUaGUgdGl0bGUgZm9yIHNlY3Rpb24gMS4z IHNob3VsZCBwcm9iYWJseSBiZSDigJxXaHkgaXMgTlBEQU8gSW1wb3J0YW50LuKAnQ0KW1JKXSBJ IGFtIG5vdCBzdXJlIGlmIHF1ZXN0aW9uIG1hcmsgaGVyZSBpcyBpbmNvcnJlY3QuIFRoaXMgc2Vj dGlvbiB0aXRsZSBpcyBzdXBwb3NlZCB0byBpbmRlZWQgcmVhZCBhcyBhIHF1ZXN0aW9uLg0KDQpJ biB0aGF0IHNlY3Rpb24sIEkgaGF2ZSB0byB3b25kZXIgaWYgc2F2aW5nIG1lbW9yeSBpcyB0aGUg bW9zdCBpbXBvcnRhbnQgZmFjdG9yIGluIHJlbW92aW5nIHJvdXRlIGluZm9ybWF0aW9uIHRoYXQg aXMgbm8gbG9uZ2VyIHZhbGlkLiAgV2hhdCBhYm91dCBpc3N1ZXMgd2l0aCBmb3J3YXJkaW5nIHBh Y2tldHMgdG93YXJkIGRlc3RpbmF0aW9ucyB0aGF0IGNhbiBubyBsb25nZXIgYmUgcmVhY2hlZCBh bG9uZyB0aGF0IHBhdGg/DQpbUkpdIE91ciBpbml0aWFsIG1vdGl2YXRpb24gdG8gd29yayBvbiB0 aGlzIHByb2JsZW0gd2FzIG1lbW9yeSBpc3N1ZS4gQnV0IHllcywgSSBhZ3JlZSB0aGF0IGluIFAy UCB0cmFmZmljIHNjZW5hcmlvIHRoZSBmb3J3YXJkaW5nIHdpbGwgYmUgYSBwcm9ibGVtLiBUaGlz IGhhcyBiZWVuIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMw0KDQpQZXJoYXBzIEkgbWlzdW5kZXJz dGFuZCB0aGUgYXBwcm9hY2gsIGJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBwcm9ibGVtcyBt ZW50aW9uZWQgaW4gc2VjdGlvbiAyLjEgc2hvdWxkIHNlbGYtcmVzb2x2ZS4gIFRoZSBmYWN0IHRo YXQgb25lIG5vZGUgY2Fubm90IHNlbmQgbWVzc2FnZXMgdG8gYW5vdGhlciBub2RlIHRvIGluZm9y bSB0aGF0IG5vZGUgdGhhdCBpdCBoYXMgbm8gREFPIGluZm9ybWF0aW9uIHNlZW1zIGtpbmQgb2Yg aXJyZWxldmFudCBpZiB0aGUgbm9kZSwgb3IgdGhlIGxpbmsgY29ubmVjdGluZyBpdCwgaXMgbm8g bG9uZ2VyIHRoZXJlLg0KDQpQZXJoYXBzIHRoZSBpc3N1ZSB5b3XigJlyZSByZWFsbHkgdHJ5aW5n IHRvIGRlc2NyaWJlIGlzIHdpdGggdW5yZWxpYWJsZSBsaW5rcyBhbmQgbm9kZXMsIGFzIG9wcG9z ZWQgdG8gbWlzc2luZyBsaW5rcyBhbmQgbm9kZXM/ICBUaGF0IHdvdWxkIG1ha2Ugc2Vuc2UgaW4g YSBsb3ctcG93ZXIgYW5kIGxvc3N5IG5ldHdvcmsuDQoNCklmIHRoZSBiZWhhdmlvciBkZXNjcmli ZWQgaW4gc2VjdGlvbiAyLjIgaXMgY29tbW9uLCBhbmQgYSBtb3JlIHJlYXNvbmFibGUgYmVoYXZp b3IgaXMgbm90IGFudGljaXBhdGVkIGJ5IHRoZSBvcmlnaW5hbCBOUERBTyBzcGVjaWZpY2F0aW9u LCB0aGFuIEkgYWdyZWUgdGhhdCBpcyBhIHByb2JsZW0uDQoNCklmIHRoZSBwcm9ibGVtcyBkZXNj cmliZWQgaW4gMi4xIGFuZCAyLjMgZG8gZXhpc3QsIGl0IHNlZW1zIGxpa2VseSB0aGF0IHRoZSB1 bmRlcmx5aW5nIGlzc3VlIGlzIHJlYWxseSBhYm91dCBhbiBhc3N1bXB0aW9uIG9mIHJlbGlhYmxl IGRlbGl2ZXJ5IHdoZXJlIHRoYXQgbWlnaHQgbm90IGJlIHRoZSByZWFsaXR5Lg0KDQpbUkpdIFRo YXQncyB0cnVlLiBVbmxpa2UgTlBEQU8sIERDTyBkZXBlbmRzIG9uIOKAnG1vcmXigJ0gcmVsaWFi bGUgbGlua3MgdGh1cyBhbGxldmlhdGluZyAoYnV0IG1heSBub3QgY29tcGxldGVseSBlbGltaW5h dGUpIHRoZSBwcm9ibGVtIG9mIHJvdXRlIGludmFsaWRhdGlvbi4NCg0KQWxsIG9mIHRoaXMgc2Fp ZCwgdGhlIDMgcmVxdWlyZW1lbnRzIHNlZW0gcmVhc29uYWJsZSBhdCBsZWFzdCBhcyBmYXIgYXMg dGhleSBnby4gIFRoZXJlIHNlZW1zIHRvIGJlIGFuIGltcGxpZWQgcmVxdWlyZW1lbnQgdG8gaW50 cm9kdWNlIGF0IGxlYXN0IHNvbWUgbGV2ZWwgb2YgcmVsaWFiaWxpdHkgKGFzIEkgc2VlbXMgaW50 ZW5kZWQgYnkgcHJvdmlkaW5nIHRoZSBEQ08tQUNLKS4gQW5kIHRoZXJlIHByb2JhYmx5IHNob3Vs ZCBiZSBhIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgY29tcGF0aWJpbGl0eSB3aXRoIGRlcGxveWVk IGltcGxlbWVudGF0aW9ucy4NCg0KQUZBSUNULCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGRlc2Ny aWJlIGhvdyBub2RlcyB1c2luZyB0aGUgbmV3bHkgc3BlY2lmaWVkIG1lc3NhZ2luZyBhbmQgYmVo YXZpb3Igd291bGQgYmUgY29tcGF0aWJsZSB3aXRoIGRlcGxveWVkIG5vZGVzLiAgTWluaW1hbGx5 IHRoZSBkb2N1bWVudCBzaG91bGQgYmUgY2xlYXIgaWYgdGhlIGludGVudGlvbiBpcyBub3QgdG8g cHJvdmlkZSBmb3IgY29tcGF0aWJpbGl0eS4gIFRoZXJlIGFyZSBhdCBsZWFzdCBhIGNvdXBsZSBv ZiBpbmRpY2F0aW9ucyB0aGF0IHRoZXJlIGlzIGRlcGxveW1lbnQuDQoNCltSSl0gWWVzLiBIYXZl IHNwZWNpZmllZCB0aGUgY29ycmVzcG9uZGluZyB0ZXh0IGFib3ZlLiBLaW5kbHkgY2hlY2sgaWYg aXQgbWFrZXMgc2Vuc2UuDQo= --_000_982B626E107E334DBE601D979F31785C5DF0CD01BLREML503MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIEVyaWMgZm9yIHRoZSByZXZpZXcgYW5kIGZlZWRi YWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgY29tcGF0aWJpbGl0eSB3aXRoIG9sZCBkZXBs b3llZCBub2Rlcywgd2UgaGF2ZSByZWNlaXZlZCBzaW1pbGFyIGZlZWRiYWNrIChmcm9tIFNod2V0 aGEgQmhhbmRhcmkpIGJlZm9yZS4gTWF5IGJlIGl0IGlzIGJldHRlciB0byBtYWtlIHRoaXMgZXhw bGljaXQgaW4gdGhlIGRvY3VtZW50LiBQbGVhc2UgY2hlY2sgaWYgdGhlIHN0YXRlbWVudCBiZWxv dw0KIG1ha2VzIHNlbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TkVX PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGRv Y3VtZW50IGFzc3VtZXMgdGhhdCBhbGwgdGhlIDZMUnMgaW4gdGhlIG5ldHdvcmsgc3VwcG9ydCB0 aGlzIGRvY3VtZW50LiBJZiB0aGVyZSBhcmUgNkxScyBlbi1yb3V0ZSBEQ08gbWVzc2FnaW5nIHdo aWNoIGRvIG5vdCBzdXBwb3J0IHRoaXMgZG9jdW1lbnQsIHRoZW4gdGhlIHJvdXRlIGludmFsaWRh dGlvbiBmb3IgY29ycmVzcG9uZGluZw0KIHRhcmdldHMgbWF5IG5vdCB3b3JrIG9yIG1heSB3b3Jr IHBhcnRpYWxseSBpLmUuLCBvbmx5IHBhcnQgb2YgdGhlIHBhdGggc3VwcG9ydGluZyBEQ08gbWF5 IGJlIGludmFsaWRhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5BbHRlcm5hdGl2ZWx5LCBhIG5vZGUgY291bGQgZ2VuZXJhdGUgYW4gTlBEQU8gaWYgaXQgZG9l cyBub3QgcmVjZWl2ZSBhIERDTyB3aXRoIGl0c2VsZiBhcyB0YXJnZXQgd2l0aGluIGEgc3BlY2lm aWVkIHRpbWUgbGltaXQuIFRoZSBzcGVjaWZpZWQgdGltZSBsaW1pdCBpcyBkZXBsb3ltZW50IHNw ZWNpZmljIGFuZCBkZXBlbmRzDQogdXBvbiB0aGUgbWF4aW11bSBkZXB0aCBvZiB0aGUgbmV0d29y ayBhbmQgcGVyIGhvcCBsYXRlbmN5LiBOb3RlIHRoYXQgc2VuZGluZyBOUERBTyBhbmQgRENPIGZv ciB0aGUgc2FtZSBvcGVyYXRpb24gd291bGQgbm90IHJlc3VsdCBpbiB1bndhbnRlZCBzaWRlLWVm ZmVjdHMgYXMgZGV0YWlsZWQgaW4gU2VjdGlvbiA0LjYuMi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FTkQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkZvciBvdGhlciBjb21tZW50cywg ZmluZCBteSByZXNwb25zZXMgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SYWh1bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXNzdWVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgaW50cm9kdWN0 aW9uLCBJIGhhdmUgc29tZSB0cm91YmxlIHBhcnNpbmcg4oCcYW4gb3B0aW9uYWwgbWVzc2FnaW5n 4oCdIOKAkyBwZXJoYXBzIGl0IHdhcyBtZWFudCB0byBqdXN0IGJlIOKAnG9wdGlvbmFsIG1lc3Nh Z2luZz/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1JKXSBZZXMgdGhpcyBoYXMg dG8gYmUgZml4ZWQuIFdpbGwgcmVtb3ZlIOKAnGFu4oCdLiBUaGlzIGhhcyBiZWVuIGJyb3VnaHQg dG8gbm90aWNlIGJ5IG90aGVycyBhbHNvIQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGVyZSBhcmUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBhYnN0cmFjdCAod2hpY2ggY2xhaW1z IHRoZSBkb2N1bWVudCBkZXNjcmliZXMgaXNzdWVzIHdpdGggTlBEQU8pIGFuZCB0aGUgSW50cm9k dWN0aW9uICh3aGljaCBnb2VzIGZ1cnRoZXIgdG8gc2F5IHRoYXQgdGhlIGRvY3VtZW50IGFsc28g ZGlzY3Vzc2VzIHJlcXVpcmVtZW50cyBhbmQgc3BlY2lmaWVzIGEgbmV3IG1lc3NhZ2UgaW50ZW5k ZWQgdG8gbWVldA0KIHRoZSByZXF1aXJlbWVudHMgYW5kIHNvbHZlIHRoZSBwcm9ibGVtcy4gPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCBpdOKAmXMgYSBwcm9ibGVtIHN0YXRlbWVudCwgcmVx dWlyZW1lbnRzIGRvY3VtZW50IGFuZCBzb2x1dGlvbiBzcGVjaWZpY2F0aW9uIGFsbCByb2xsZWQg aW50byBvbmUuJm5ic3A7IEkgZ3Vlc3MgdGhpcyBpcyBub3QgYSBwcm9ibGVtIGZvciBhbnlvbmUg aW4gdGhlIFdHPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdGl0bGUgZm9yIHNlY3Rpb24g MS4zIHNob3VsZCBwcm9iYWJseSBiZSDigJxXaHkgaXMgTlBEQU8gSW1wb3J0YW50LuKAnTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPltSSl0gSSBhbSBub3Qgc3VyZSBpZiBxdWVzdGlvbiBtYXJrIGhlcmUgaXMgaW5jb3JyZWN0 LiBUaGlzIHNlY3Rpb24gdGl0bGUgaXMgc3VwcG9zZWQgdG8gaW5kZWVkIHJlYWQgYXMgYSBxdWVz dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoYXQgc2VjdGlvbiwgSSBo YXZlIHRvIHdvbmRlciBpZiBzYXZpbmcgbWVtb3J5IGlzIHRoZSBtb3N0IGltcG9ydGFudCBmYWN0 b3IgaW4gcmVtb3Zpbmcgcm91dGUgaW5mb3JtYXRpb24gdGhhdCBpcyBubyBsb25nZXIgdmFsaWQu Jm5ic3A7IFdoYXQgYWJvdXQgaXNzdWVzIHdpdGggZm9yd2FyZGluZyBwYWNrZXRzIHRvd2FyZCBk ZXN0aW5hdGlvbnMgdGhhdCBjYW4gbm8gbG9uZ2VyIGJlIHJlYWNoZWQgYWxvbmcgdGhhdA0KIHBh dGg/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+W1JKXSBPdXIgaW5pdGlhbCBtb3RpdmF0aW9uIHRvIHdvcmsgb24gdGhpcyBw cm9ibGVtIHdhcyBtZW1vcnkgaXNzdWUuIEJ1dCB5ZXMsIEkgYWdyZWUgdGhhdCBpbiBQMlAgdHJh ZmZpYyBzY2VuYXJpbyB0aGUgZm9yd2FyZGluZyB3aWxsIGJlIGEgcHJvYmxlbS4gVGhpcyBoYXMg YmVlbiBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlBlcmhhcHMgSSBtaXN1bmRlcnN0YW5kIHRoZSBhcHByb2FjaCwgYnV0IGl0IHNlZW1zIHRv IG1lIHRoYXQgdGhlIHByb2JsZW1zIG1lbnRpb25lZCBpbiBzZWN0aW9uIDIuMSBzaG91bGQgc2Vs Zi1yZXNvbHZlLiZuYnNwOyBUaGUgZmFjdCB0aGF0IG9uZSBub2RlIGNhbm5vdCBzZW5kIG1lc3Nh Z2VzIHRvIGFub3RoZXIgbm9kZSB0byBpbmZvcm0gdGhhdCBub2RlIHRoYXQgaXQgaGFzIG5vIERB TyBpbmZvcm1hdGlvbiBzZWVtcw0KIGtpbmQgb2YgaXJyZWxldmFudCBpZiB0aGUgbm9kZSwgb3Ig dGhlIGxpbmsgY29ubmVjdGluZyBpdCwgaXMgbm8gbG9uZ2VyIHRoZXJlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5QZXJoYXBzIHRoZSBpc3N1ZSB5b3XigJlyZSByZWFsbHkgdHJ5aW5nIHRvIGRl c2NyaWJlIGlzIHdpdGggdW5yZWxpYWJsZSBsaW5rcyBhbmQgbm9kZXMsIGFzIG9wcG9zZWQgdG8g bWlzc2luZyBsaW5rcyBhbmQgbm9kZXM/Jm5ic3A7IFRoYXQgd291bGQgbWFrZSBzZW5zZSBpbiBh IGxvdy1wb3dlciBhbmQgbG9zc3kgbmV0d29yay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYg dGhlIGJlaGF2aW9yIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIuMiBpcyBjb21tb24sIGFuZCBhIG1v cmUgcmVhc29uYWJsZSBiZWhhdmlvciBpcyBub3QgYW50aWNpcGF0ZWQgYnkgdGhlIG9yaWdpbmFs IE5QREFPIHNwZWNpZmljYXRpb24sIHRoYW4gSSBhZ3JlZSB0aGF0IGlzIGEgcHJvYmxlbS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIHByb2JsZW1zIGRlc2NyaWJlZCBpbiAyLjEgYW5k IDIuMyBkbyBleGlzdCwgaXQgc2VlbXMgbGlrZWx5IHRoYXQgdGhlIHVuZGVybHlpbmcgaXNzdWUg aXMgcmVhbGx5IGFib3V0IGFuIGFzc3VtcHRpb24gb2YgcmVsaWFibGUgZGVsaXZlcnkgd2hlcmUg dGhhdCBtaWdodCBub3QgYmUgdGhlIHJlYWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPltSSl0gVGhhdCdzIHRydWUuIFVubGlrZSBOUERBTywgRENPIGRlcGVuZHMgb24g4oCcbW9y ZeKAnSByZWxpYWJsZSBsaW5rcyB0aHVzIGFsbGV2aWF0aW5nIChidXQgbWF5IG5vdCBjb21wbGV0 ZWx5IGVsaW1pbmF0ZSkgdGhlIHByb2JsZW0gb2Ygcm91dGUgaW52YWxpZGF0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsIG9mIHRoaXMgc2FpZCwgdGhlIDMgcmVxdWlyZW1l bnRzIHNlZW0gcmVhc29uYWJsZSBhdCBsZWFzdCBhcyBmYXIgYXMgdGhleSBnby4mbmJzcDsgVGhl cmUgc2VlbXMgdG8gYmUgYW4gaW1wbGllZCByZXF1aXJlbWVudCB0byBpbnRyb2R1Y2UgYXQgbGVh c3Qgc29tZSBsZXZlbCBvZiByZWxpYWJpbGl0eSAoYXMgSSBzZWVtcyBpbnRlbmRlZCBieSBwcm92 aWRpbmcgdGhlIERDTy1BQ0spLiBBbmQgdGhlcmUgcHJvYmFibHkNCiBzaG91bGQgYmUgYSByZXF1 aXJlbWVudCB0byBzdXBwb3J0IGNvbXBhdGliaWxpdHkgd2l0aCBkZXBsb3llZCBpbXBsZW1lbnRh dGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFGQUlDVCwgdGhpcyBkb2N1bWVudCBkb2Vz IG5vdCBkZXNjcmliZSBob3cgbm9kZXMgdXNpbmcgdGhlIG5ld2x5IHNwZWNpZmllZCBtZXNzYWdp bmcgYW5kIGJlaGF2aW9yIHdvdWxkIGJlIGNvbXBhdGlibGUgd2l0aCBkZXBsb3llZCBub2Rlcy4m bmJzcDsgTWluaW1hbGx5IHRoZSBkb2N1bWVudCBzaG91bGQgYmUgY2xlYXIgaWYgdGhlIGludGVu dGlvbiBpcyBub3QgdG8gcHJvdmlkZSBmb3IgY29tcGF0aWJpbGl0eS4mbmJzcDsgVGhlcmUNCiBh cmUgYXQgbGVhc3QgYSBjb3VwbGUgb2YgaW5kaWNhdGlvbnMgdGhhdCB0aGVyZSBpcyBkZXBsb3lt ZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bUkpdIFllcy4gSGF2ZSBzcGVjaWZp ZWQgdGhlIGNvcnJlc3BvbmRpbmcgdGV4dCBhYm92ZS4gS2luZGx5IGNoZWNrIGlmIGl0IG1ha2Vz IHNlbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_982B626E107E334DBE601D979F31785C5DF0CD01BLREML503MBXchi_-- From nobody Fri Jun 28 08:44:52 2019 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 8D45212017E; Fri, 28 Jun 2019 08:44:50 -0700 (PDT) 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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <156173669053.20393.15465761462741061523@ietfa.amsl.com> Date: Fri, 28 Jun 2019 08:44:50 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-nsa-extension-03.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: Fri, 28 Jun 2019 15:44:51 -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 DAG Metric Container Node State and Attribute object type extension Authors : Remous-Aris Koutsiamanis Georgios Papadopoulos Nicolas Montavont Pascal Thubert Filename : draft-ietf-roll-nsa-extension-03.txt Pages : 14 Date : 2019-06-28 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 a packet to enable this functionality. 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-nsa-extension-03 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 Jun 28 08:45:42 2019 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 3484F12017E for ; Fri, 28 Jun 2019 08:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bGo3_4YNhH5 for ; Fri, 28 Jun 2019 08:45:33 -0700 (PDT) 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 6F3231201BB for ; Fri, 28 Jun 2019 08:45:32 -0700 (PDT) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 23B33CDA for ; Fri, 28 Jun 2019 17:45:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1561736730; bh=6fnDgivy4sQzAV/nCH84tbs6ItAlVPUGCYMZiXlOj0s=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Uiohj8sNULSfCWgzzoQmcT9toRfbrxRUbfj51IIePoCeRB9zB/TcKwbCj8MKWzpUr IQsKBT2SSyDqSzMw5tjkT/hXaBBL/+oA2JIrevXaSdgux+79dktkLLMr34nla9Bsnz TfDR9Pio/AqZui+VauUs9BhT7ZM/IFJRATSyRm+2Q4UyOsPe63ThJDBUESb+QVsEQ3 Inl6ThISdR88fusMdldSeUguM6Z/b+xl+UYbBqAEmrojMoMOQzJWpVdqMSFRCdXmiZ AsM1HPm8DrXx3eNE6ryXJDzjoM1CYAo7JDAvzEm45/n0uGKMDuc95UjwqQVVtbCjWx ytu7HaJOH54Iw== Received: by smtp.mailfence.com with ESMTPA for ; Fri, 28 Jun 2019 17:45:23 +0200 (CEST) Received: by mail-io1-f42.google.com with SMTP id e3so13406439ioc.12 for ; Fri, 28 Jun 2019 08:45:23 -0700 (PDT) X-Gm-Message-State: APjAAAXbLeqOyNvOF6o/o1n4gaca7Qe5gMGg5xPJ0xSO+3ueLUMP1l9c C6vr71FEMOJMSBUavzcarqXhU8PSHpszLVaZLe4= X-Google-Smtp-Source: APXvYqxLd0xMtQzTRYodsPksE2vgITxErD431zsYFiR1trxF5IJ/BOiJVcXvCftsZrRmUT0gGlZXt9vwROj6mLu8YPM= X-Received: by 2002:a5e:db0a:: with SMTP id q10mr11910374iop.168.1561736720650; Fri, 28 Jun 2019 08:45:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Remous-Aris Koutsiamanis Date: Fri, 28 Jun 2019 17:45:26 +0200 (CEST) X-Gmail-Original-Message-ID: Message-ID: To: Routing Over Low power and Lossy networks Cc: "Georgios Z. Papadopoulos" , Diego Dujovne , rahul.ietf@gmail.com Content-Type: multipart/alternative; boundary="000000000000779d2b058c642a4d" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-nsa-extension-02 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 Jun 2019 15:45:37 -0000 --000000000000779d2b058c642a4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Diego, thank you very much for reviewing the draft and for providing us with your feedback. The issue of scope also might concern Rahul as well, so I have CCed him as well. Responses follow inline. On Wed, Jun 26, 2019 at 1:56 AM Prof. Diego Dujovne wrote: > Dear all, > My review of the draft below: > > - The abstract should include more details about the purpose > of packet replication and the context where the metric will > be used. Is it an Objective Function? Is it a new mechanism? > As you guessed and as you said in another of your comments further below, the scope of this draft may need some clarification. Up to this point, the from feedback that we have received and from discussions with others, we took the path of providing some introductory material as well as examples of potential uses of the Parent Set information in an Objective Function. However, and this is the main point, the draft only specifies the information to be transferred, its encoding, compression, etc. How exactly it is to be used (Objective Function) is outside the specification. The options are to: a) Create another document with the operation of an OF which uses this b) Extend this draft with the spec of an OF that uses the information. Since there is already work by Rahul which might take advantage of the same information in a different way, we chose a). Rahul, any comments? In any case, do you think that "This document details what information needs to be transmitted and how it is encoded within a packet to enable this functionality." is not clear enough? > - I think abbreviations such as "aka" shall be avoided > Absolutely, thanks. An instance of "aka" and "one" of i.e. have been replaced. > > - The expression " to achieve their goal" shall be put in context. > Which is the goal? Maybe it is easier to write "Network-enabled > applications in the industrial context must provide..." > No problem. What do you think about this rephrase: "Network-enabled applications in the industrial context must provide string= ent guarantees in terms of reliability and predictability. To achieve this they typically leverage 1+1 redundancy, also known as Packet Replication and Elimination (PRE) [I-D.papadopoulos-6tisch-pre-reqs ]. > - The phrase "In order > > for wireless networks to be able to be used in such applications, the > principles of Deterministic Networking [I-D.ietf-detnet-architecture <= https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02#ref-I-D.ietf-d= etnet-architecture>] > lead to designs that aim at maximizing packet delivery rate and > minimizing latency and jitter." > > should be rewritten differently, it is a little bit complex and long. > From that expression, I understand that if you are aiming to apply detnet > principles to LLNs, the design shall comply with these principles. Am I > right? > Yes, you are correct. This is the idea. What do you think about this rephrase: "Allowing these kinds of applications to function over wireless networks requires the application of the principles of Deterministic Networking [I-D= . ietf-detnet-architecture ].This results in designs which aim at maximizing packet delivery rate and minimizing latency and jitter." > > - "uses a fixed communication schedule" is it fixed? I think it could be > better to explain that by using timeslots, TSCH looks like TDMA in the ti= me > dimension (and only for better understanding). > Well, actually the schedule is not completely fixed, at least not permanently. The point is that with TSCH you can avoid probabilistic medium access by having a common agreed-upon schedule. Maybe this rephrase is better? "As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154-2015 ] provides Time-Slotted Channel Hopping (TSCH), a mode of operation which uses a common communication schedule based on timeslots to allow deterministic medium access as well as ..." > - " isn't it "to provide"? and "and limit jitter" should be "to limit"? > Thanks, fixed. > - "achieves a controlled redundancy" to "achieves controlled redundancy" > Yes, thanks, fixed. > - "within the remit of" I do not understand the expression. > Means within the area of responsibility of. Rephrased as: "which is among the responsibilities of the RPL Objective Function" > - "The specification of the transmission of this information is the focus > of this document." > could it be "This document focuses on the specification of the > transmission of this specific path information" > Sure, thanks. Rephrased as suggested. > - "More concretely" to "Specifically" > It is followed by "this specification focuses ..". It would become: "Specifically, this specification focuses .." Left as is, unless a bigger rephrase is required. > - "children nodes of the node" of the parent node? maybe "children of the > parent node"? > Yes, better, rephrased as "children of the node". > - "This specification defines the type value and structure for this TLV" > to "This specification defines the type value and structure for the > parent address set TLV". Is there an abbreviation of the parent address > set (such as PAS)? > No problem, replaced as suggested. The abbreviation is PS (Parent Set). > - "The sending of multiple" to "The transmission of multiple" is better > here. > No problem. Replaced as suggested. > - "The sending of multiple copies of a packet using multi-path forwarding > over a multi-hop network and the consolidation of multiple received > packet copies to control flooding." > looks awkward. The verb is missing. > Well, the defined term is a noun so for me it makes sense that there is no verb. I would agree that it is a bit complex, however. Rephrased to: "A method which transmits multiple copies of a packet using multi-path forwarding over a multi-hop network and which consolidates multiple received packet copies to control flooding. See "Exploiting Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs ] for more details." > - " [I-D.papadopoulos-6tisch-pre-reqs > ] > for more." to " [I-D.papadopoulos-6tisch-pre-reqs > ] > for more details. > No problem. Fixed. - "The problem of how to select the next hop target node for a packet copy > to be forwarded to when performing packet replication." can be rephrased: > "Defines the mechanism to choose the next hop node to forward a packet co= py > when replicating" (although I think still needs some work on it) > Thanks. As a first step rephrased to: "The mechanism for choosing the next hop node to forward a packet copy when replicating packets." - "Preferred Parent (PP)" is defined after PP is used for the first time. > Good catch, thanks. Fixed. > - "AP node, functionality which is included in the operation of the RPL > Objective > Function (OF)." to "AP node. This functionality which is included in > the operation of the RPL Objective Function (OF)." > No problem, replaced as suggested. > - "A scheme which allows the two paths to remain > > correlated is detailed here. More specifically, in this scheme a > node will select an AP node close to its PP node to allow the > operation of overhearing between parents. If multiple potential APs > match this condition, the AP with the lowest rank will be registered". > > I think this expression can be improved eliminating the first part. > "The node will select an AP node close to its PP node to allow the operat= ion > of overhearing between parents. If multiple potential APs match this > condition, the AP with the lowest rank will be registered". > Thank you for the comment. In this instance I would prefer that "A scheme which allows the two paths to remain correlated is detailed here." is kept, because at this point the draft only gives an **example** of a potential scheme for alternative parent selection, with the specific feature that the two paths remain correlated. There are other options available and this draft at this point does not propose any choice. I would like to keep it clear that this scheme is not part of the spec itself. I am of course open for discussion. - I have not seen anything about overhearing before this point. I think > overhearing can be either explained shortly or referenced to another > document. > Very good point. This is actually the only mention of overhearing, since although it is beneficial to performance and we do use it in our implementation, it is in no way required for this spec. Overhearing is only mentioned here because keeping the paths correlated increased the chances of taking advantage of overhearing. I have referenced a section in papadopoulos-6tisch-pre-reqs which explains it a bit more for those interested. > - In general, from the abstract and the title, I was expecting only the > technical description of the extension, without the AP selection mechanis= m. > From my point of view, either the mechanism should be described in anothe= r > document and referenced in this one, or the goal of the document shall be > expanded to include the mechanism too. > I agree that this is an issue. As I have answered to your first comment in more detail, for now the answer has been that this draft only specifies the parent set information, not the Objective Function. We can definitely discuss this though. - Moreover, the description of the NSA extension can be expanded to be > used for other selection mechanisms which may consider different criteria > to take advantage of alternative parent selection. > Sure, any ideas are very welcome. :) > > As always, open to any comments on the above. > Regards, > > Diego > Again, thank you very much for the help. A new version of the draft (draft-ietf-roll-nsa-extension-03) has been posted with the discussed changes. Best, Aris > > -- > DIEGO DUJOVNE > Profesor Asociado > Escuela de Inform=C3=A1tica y Telecomunicaciones > Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile > www.ingenieria.udp.cl > (56 2) 676 8125 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --000000000000779d2b058c642a4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello Diego,

    thank you very much for reviewing the draft and for providing us with you= r feedback.
    The issue of scope also might concern Rahul as well, = so I have CCed him as well.

    Responses follow <= span id=3D"gmail-m_-1290419612844235248:2cl.1">inline.

    On Wed, Jun 26, 2019 at 1:56 AM Prof. Diego Dujovne <diego.dujovne@mail.udp.cl> wrote:
    <= div dir=3D"ltr">
    Dear all,
    =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 My review of the draft below:

    =
    - The abstract should include more details about the purpose
    of packet replication and the context where the metric will
    be u= sed. Is it an Objective Function? Is it a new mechanism?
    <= /div>

    As you guessed and as you said in another of your comments further below,=20 the scope of this draft may need some clarification. Up to this point,=20 the from feedback that we have received and from discussions with=20 others, we took the path of providing some introductory material as well as examples of potential uses of the Parent Set information in an=20 Objective Function.
    However, and this is the main point, the=20 draft only specifies the information to be transferred, its encoding,=20 compression, etc. How exactly it is to be used (Objective Function) is=20 outside the specification. The options are to:
    a) Create another = document with the operation of an OF which uses this
    b) Extend th= is draft with the spec of an OF that uses the information.

    Since there is already work by Rahul which might take advantage of the same informatio= n in a different way, we chose a).
    Rahul, any comments?

    = In any case, do you think that
    "This document details what info= rmation needs to be
    transmitted and how it is = encoded within a packet to enable this
    functio= nality."
     is not clear enough?


    - I think abbreviations such as "ak= a" shall be avoided
    =

    Absolutely, thank= s. An instance of "aka" and "one" of i.e. have been rep= laced.
    =C2=A0

    - The = expression " to a= chieve their goal" shall be put in context.
    Which is the goal? Maybe= it is easier to write "Network-enabled
    applications in the i= ndustrial context must provide..."
    <= /div>

    =
    No problem. What do you think about this rephrase:
    "Network-enabled applications in t= he industrial context must provide stringent guarantees in terms of reliability and predictability. To achieve this=20 they typically leverage 1+1 redundancy, also known as Packet Replication and Elimination (PRE) [I-D.papadopoulos-6tisch-pre-reqs].

    =C2=A0
    - The phrase "In order
       for wireless networks to be able to be used in such applications,=
 the
   principles of Deterministic Networking [I-D.ietf-detnet-architecture]
   lead to designs that aim at maximizing packet delivery rate and
   minimizing latency and jitter."
    should be rewritten differentl= y, it is a little bit complex and long.
    From that expression, I understand that if you are aiming to apply detnet=20 principles to LLNs, the design shall comply with these principles. Am I=20 right?
    =

    Yes, you are correct. This is the i= dea.
    What do you think about this rephrase:
    "Allowing these kinds of applications to function over wireless networks requires the application of the principles of Deterministic Networking [I-D.ietf-detnet-architecture].This results in designs which aim at maximizing pack= et delivery rate and minimizing latency and jitter."
    =C2=A0

    - "uses a fixed communication schedule" is it fixed? I think it could be bett= er to explain that by using timeslots, TSCH looks like TDMA in the time=20 dimension (and only for better understanding).
    <= /div>

    =
    Well, actually the schedule is not completely fixed, at least n= ot permanently.
    The point is that with TSCH you can avoid probabilistic medium acces= s by having a common agreed-upon schedule.

    Maybe t= his rephrase is better?
    "As =
an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154-2015] provides
    Time-Slotted Chan=
nel Hopping (TSCH),=
 a mode of operation which uses a common communication schedule
    based on=
 timeslots to allow=
 deterministic medium access as well as ..."
    =C2=A0
    <= div dir=3D"ltr">
    -=C2=A0 " isn't it "to provid= e"? and "and limit jitter" should be "to limit"?
    <= /div>

    Thanks, fixed.
    =C2= =A0
    - "achieves a controlled redu= ndancy" to "achieves controlled redundancy"
    <= /div>

    Yes, thanks, fixed.
    =C2=A0<= /div>
    <= span style=3D"color:rgb(0,0,0);font-size:13.3333px">- "within the remit of" I do= not understand the expression.
    <= /div>

    Mea= ns within the area of responsibility of. Rephrased as:
    "which is among the responsibi= lities of the RPL O= bjective Function"
    =C2=A0
    =
    - "The specification of=C2=A0the transmission of th= is information is the focus of this document."
    could it be "This docum= ent focuses on the specification of the transmission of this specific path = information"
    =

    Sure, thanks. Rep= hrased as suggested.
    =C2=A0
    <= div dir=3D"ltr">
    - "More concretely" to = "Specifically"

    It is foll= owed by "this specif= ication focuses ..".
    It would become: "Specifically, this specificat= ion focuses .."
    Left as is, unless a bigger rephrase is required.
    <= span class=3D"gmail-im">
    =C2=A0
    - "children nodes of the node" of the parent node?=C2=A0maybe "children of the= parent node"?
    <= /div>

    Yes, better, re= phrased as "child= ren of the node".
    <= div>=C2=A0
    <= /div>
    - "This specification = defines the type value and structure for=C2=A0this TLV" to "This specification defines the ty= pe value and structure for the parent address set=C2=A0TLV". Is there an abbreviation= of the parent address set (such as PAS)?
    =

    No problem, replaced as suggested. The abbreviation is PS (Parent Se= t).
    =C2=A0
    <= div dir=3D"ltr">
    - "The sending of multiple" to "The transmissi= on of multiple" is better here.

    No problem. Replaced as suggested.
    =C2=A0
    <= div dir=3D"ltr">
    - "The sending of mult= iple=C2=A0copie= s of a packet using multi-path forwarding over a multi-hop=C2=A0network and the consolidat= ion of multiple received packet copies=C2=A0to control flooding."
    looks awkward. The verb = is missing.
    =

    Well, the defined term is a noun so for me it makes sense that there is no=20 verb. I would agree that it is a bit complex, however. Rephrased to:
    <= div>"A method which transmits multiple copies of a packet using=20 multi-path forwarding over a multi-hop network and which consolidates=20 multiple received packet copies
    to control flooding. See "Exploiting Packet R= eplication and Elimination in Complex Tracks in 6TiSCH LLNs"
    = [I-D.papadopoulos-6tisch-pre-reqs] for more de= tails."
    =C2=A0
    <= div dir=3D"ltr">
    <= /div>

    No pro= blem. Fixed.

    <= div dir=3D"ltr">
    - "The problem of how to select the=C2=A0next hop target node for a pac= ket copy to be forwarded to when=C2=A0performing packet replication." can be rephrased: "Defines the mechanism to= choose the next hop node to forward a packet copy when replicating" (althoug= h I think still needs some work on it)
    =

    Thanks. As a first step rephrased to:
    "The mechanism for choosing the next hop node to forward a pack= et copy when replicating packets."

    <= div dir=3D"ltr">
    - &quo= t;Preferred Par= ent (PP)" is defined after PP is used for the first time.
    =

    Good catch, thanks. Fixed.
    =C2=A0
    <= div dir=3D"ltr">
    - "AP nod= e,=C2=A0functio= nality which is included in the operation of the RPL Objective=C2=A0=
    =C2=A0 =C2= =A0Function (OF)." to=C2=A0"AP node. This=C2=A0functionality which is included in the operation of the RPL Obj= ective=C2=A0Fun= ction (OF)."=C2=A0=C2=A0
    =

    No problem, replaced= as suggested.
    =C2=A0
    =
    - "A scheme which allows the two paths to remai= n
       correlated is detailed he=
re.  More specifically, in this scheme a
   node will select an AP node close to its PP node to allow the
   operation of overhearing between parents.  If multiple potential APs
   match this condition, the AP with the lowest rank will be registered&quo=
t;.
    I think this expression can be improved eliminating the first pa= rt.
    "The=C2=A0node will sele= ct an AP node close to its PP node to allow the=C2=A0operation of overhearing between pare= nts. If multiple potential APs=C2=A0match this condition, the AP with the lowest rank wil= l be registered".
    <= /div>

    = Thank you for the comment. In this instance I would prefer that
    <= span class=3D"gmail-im">
    "A scheme which allows the two paths to r= emain correlated is detailed here."
    is kept, b= ecause at this point the draft only gives an *example* of a potential scheme for alternative parent selection, with the=20 specific feature that the two paths remain correlated. There are other=20 options available and this draft at this point does not propose any=20 choice.
    I would like to keep it clear that this scheme is not par= t of the spec itself.
    I am of course open for discussion.

    <= div dir=3D"ltr">
    - I have not seen anything about overhearing before this point. I think=20 overhearing can be either explained shortly or referenced to another=20 document.=C2=A0

    Very good point. This is actually the only mention of overhearing, since=20 although it is beneficial to performance and we do use it in our=20 implementation, it is in no way required for this spec. Overhearing is=20 only mentioned here because keeping the paths correlated increased the=20 chances of taking advantage of overhearing.
    I have referenced a s= ection in=C2=A0papadopoulos-6tisch-pre-reqs which explains it a bit more fo= r those interested.
    =C2=A0
    <= div dir=3D"ltr">
    - In general, from the abstract and the title, I was expecting only the=20 technical description of the extension, without the AP selection=20 mechanism. From my point of view, either the mechanism should be=20 described in another document and referenced in this one, or the goal of the document shall be expanded to include the mechanism too.=
    =

    I agree that this is an issue. As I have answered to your first comment=20 in more detail, for now the answer has been that this draft only=20 specifies the parent set information, not the Objective Function.
    We can definitely discuss this though.
    <= div>
    <= div dir=3D"ltr">
    =
    -=C2=A0 Moreover, the description of the NSA extension can be expanded to be=20 used for other selection mechanisms which may consider different=20 criteria to take advantage of=C2=A0 alternative parent selection.=C2=A0

    Sure, any ideas are very = welcome. :)
    =C2=A0

    As always, open to any comments on the above.
    Regards,

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diego=C2=A0
    <= /div>

    Again, thank you very much for the help= .
    A new version of the draft (draf= t-ietf-roll-nsa-extension-03) has been posted with the discussed cha= nges.

    Best,
    Aris

    <= div class=3D"gmail-im">
    =C2=A0

    --
    DIEGO DUJOVNE
    Profes= or Asociado
    Escuela de Inform=C3=A1tica y Telecomunicaciones
    Facultad= de Ingenier=C3=ADa - Universidad Diego Portales - Chile
    www.ingenieria.udp.cl
    (5= 6 2) 676 8125
    <= /div>
    _______________________________________________
    Roll mailing list
    Roll@ietf.org
    https://www.ietf.org/mailman/listinfo/roll
    --000000000000779d2b058c642a4d-- From nobody Fri Jun 28 16:02:17 2019 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 A99121209A8; Fri, 28 Jun 2019 15:57:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: roll@ietf.org, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267968.11015.3709807251344707407.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:59 -0700 Archived-At: Subject: [Roll] roll - Requested session has been scheduled for IETF 105 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 Jun 2019 22:58:12 -0000 Dear Ines Robles, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. roll Session 1 (2:00 requested) Wednesday, 24 July 2019, Morning Session I 1000-1200 Room Name: Sainte-Catherine size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/roll.ics Request Information: --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Ines Robles Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: anima manet 6tisch core ace Second Priority: rtgarea 6lo 6man lwig cbor t2trg Third Priority: rtgwg intarea lpwan People who must be present: Michael Richardson Peter van der Stok Alvaro Retana Ines Robles Resources Requested: Special Requests: One of the chairs leaves on Friday, it would be nice please if we could have the meeting before Friday. Meetecho Support --------------------------------------------------------- From nobody Fri Jun 28 19:12:06 2019 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 449DC120181 for ; Fri, 28 Jun 2019 19:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OcQUBOln-Oz for ; Fri, 28 Jun 2019 19:12:03 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B472D120173 for ; Fri, 28 Jun 2019 19:12:02 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id F2B4992CFB239CD95DBB; Sat, 29 Jun 2019 03:12:00 +0100 (IST) Received: from BLREML702-CAH.china.huawei.com (10.20.4.171) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 29 Jun 2019 03:12:00 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.241]) by blreml702-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Sat, 29 Jun 2019 07:41:49 +0530 From: Rahul Arvind Jadhav To: Remous-Aris Koutsiamanis , "Routing Over Low power and Lossy networks" CC: "Georgios Z. Papadopoulos" , Diego Dujovne , "rahul.ietf@gmail.com" Thread-Topic: [Roll] Review of draft-ietf-roll-nsa-extension-02 Thread-Index: AQHVK7GxEgkUeK7yFk2oQvQe9eCnlKaw3WyAgAD1s0A= Date: Sat, 29 Jun 2019 02:11:49 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF192C3@BLREML503-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DF192C3BLREML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-nsa-extension-02 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 Jun 2019 02:12:05 -0000 --_000_982B626E107E334DBE601D979F31785C5DF192C3BLREML503MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhY3R1YWxseSBwcmVmZXIgaGF2aW5nIE9GIGRlZmluZWQgaW4gdGhlIHNhbWUgZG9jdW1lbnQu IEhhdmluZyBPRiBkZWZpbmVkIGdpdmVzIGEgY2xlYXIgY29udGV4dCBvbiBob3cgdG8gdXNlIHRo ZSBuZXdseSBkZWZpbmVkIG1ldHJpY3MvY29uc3RyYWludHMuIFNlY29uZGx5IHdlIGhhdmUgdmVy eSBmZXcgT0NQcyBkZWZpbmVkIHRpbGwgZGF0ZS4gV2UgaGF2ZSBqdXN0IHVzZWQgMiBPQ1BzIGZy b20gYSB0b3RhbCBvZiA2NTUzNiAobGFzdCBPQ1Agd2FzIGRlZmluZWQgYWxtb3N0IDggeWVhcnMg YmFjaykuIEluIHlvdXIgY2FzZSB5b3UgYWxyZWFkeSBoYXZlIGRvbmUgZXhwZXJpbWVudHMgYW5k IHlvdSBoYXZlIHRoZSB0ZXN0LWJlZOKApiBzbyB3ZSBtaWdodCBhcyB3ZWxsIHRyeSB0byBnZXQg T0YgZG9uZSBpbiB0aGUgc2FtZSBleHBlcmltZW50Lg0KDQrigKYuIHdlIHRvb2sgdGhlIHBhdGgg b2YgcHJvdmlkaW5nIHNvbWUgaW50cm9kdWN0b3J5IG1hdGVyaWFsIGFzIHdlbGwgYXMgZXhhbXBs ZXMgb2YgcG90ZW50aWFsIHVzZXMgb2YgdGhlIFBhcmVudCBTZXQgaW5mb3JtYXRpb24gaW4gYW4g T2JqZWN0aXZlIEZ1bmN0aW9uLg0KSG93ZXZlciwgYW5kIHRoaXMgaXMgdGhlIG1haW4gcG9pbnQs IHRoZSBkcmFmdCBvbmx5IHNwZWNpZmllcyB0aGUgaW5mb3JtYXRpb24gdG8gYmUgdHJhbnNmZXJy ZWQsIGl0cyBlbmNvZGluZywgY29tcHJlc3Npb24sIGV0Yy4gSG93IGV4YWN0bHkgaXQgaXMgdG8g YmUgdXNlZCAoT2JqZWN0aXZlIEZ1bmN0aW9uKSBpcyBvdXRzaWRlIHRoZSBzcGVjaWZpY2F0aW9u LiBUaGUgb3B0aW9ucyBhcmUgdG86DQphKSBDcmVhdGUgYW5vdGhlciBkb2N1bWVudCB3aXRoIHRo ZSBvcGVyYXRpb24gb2YgYW4gT0Ygd2hpY2ggdXNlcyB0aGlzDQpiKSBFeHRlbmQgdGhpcyBkcmFm dCB3aXRoIHRoZSBzcGVjIG9mIGFuIE9GIHRoYXQgdXNlcyB0aGUgaW5mb3JtYXRpb24uDQoNClNp bmNlIHRoZXJlIGlzIGFscmVhZHkgd29yayBieSBSYWh1bCB3aGljaCBtaWdodCB0YWtlIGFkdmFu dGFnZSBvZiB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiBhIGRpZmZlcmVudCB3YXksIHdlIGNob3Nl IGEpLg0KUmFodWwsIGFueSBjb21tZW50cz8NCg0KDQo= --_000_982B626E107E334DBE601D979F31785C5DF192C3BLREML503MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uZ21haWwtaW0NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtaW07fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5nbWFpbC1m aWxlbmFtZQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1maWxlbmFtZTt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5JIGFjdHVhbGx5IHByZWZlciBoYXZpbmcgT0YgZGVmaW5lZCBpbiB0aGUgc2FtZSBkb2N1 bWVudC4gSGF2aW5nIE9GIGRlZmluZWQgZ2l2ZXMgYSBjbGVhciBjb250ZXh0IG9uIGhvdyB0byB1 c2UgdGhlIG5ld2x5IGRlZmluZWQgbWV0cmljcy9jb25zdHJhaW50cy4gU2Vjb25kbHkgd2UgaGF2 ZSB2ZXJ5IGZldyBPQ1BzIGRlZmluZWQgdGlsbCBkYXRlLiBXZSBoYXZlDQoganVzdCB1c2VkIDIg T0NQcyBmcm9tIGEgdG90YWwgb2YgNjU1MzYgKGxhc3QgT0NQIHdhcyBkZWZpbmVkIGFsbW9zdCA4 IHllYXJzIGJhY2spLiBJbiB5b3VyIGNhc2UgeW91IGFscmVhZHkgaGF2ZSBkb25lIGV4cGVyaW1l bnRzIGFuZCB5b3UgaGF2ZSB0aGUgdGVzdC1iZWTigKYgc28gd2UgbWlnaHQgYXMgd2VsbCB0cnkg dG8gZ2V0IE9GIGRvbmUgaW4gdGhlIHNhbWUgZXhwZXJpbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPuKApi48L3NwYW4+IHdlIHRvb2sgdGhlIHBhdGggb2YgcHJvdmlk aW5nIHNvbWUgaW50cm9kdWN0b3J5IG1hdGVyaWFsIGFzIHdlbGwgYXMgZXhhbXBsZXMgb2YgcG90 ZW50aWFsIHVzZXMgb2YgdGhlIFBhcmVudCBTZXQgaW5mb3JtYXRpb24gaW4gYW4gT2JqZWN0aXZl IEZ1bmN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SG93ZXZlciwgYW5kIHRoaXMgaXMgdGhlIG1haW4gcG9pbnQsIHRoZSBkcmFmdCBvbmx5 IHNwZWNpZmllcyB0aGUgaW5mb3JtYXRpb24gdG8gYmUgdHJhbnNmZXJyZWQsIGl0cyBlbmNvZGlu ZywgY29tcHJlc3Npb24sIGV0Yy4gSG93IGV4YWN0bHkgaXQgaXMgdG8gYmUgdXNlZCAoT2JqZWN0 aXZlIEZ1bmN0aW9uKSBpcyBvdXRzaWRlIHRoZSBzcGVjaWZpY2F0aW9uLiBUaGUgb3B0aW9ucyBh cmUgdG86PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5hKSBDcmVhdGUgYW5vdGhlciBkb2N1bWVudCB3aXRoIHRoZSBvcGVyYXRpb24gb2YgYW4gT0Yg d2hpY2ggdXNlcyB0aGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5iKSBFeHRlbmQgdGhpcyBkcmFmdCB3aXRoIHRoZSBzcGVjIG9mIGFuIE9GIHRo YXQgdXNlcyB0aGUgaW5mb3JtYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNlIHRoZXJlIGlzIGFscmVhZHkgd29yayBieSBSYWh1 bCB3aGljaCBtaWdodCB0YWtlIGFkdmFudGFnZSBvZiB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiBh IGRpZmZlcmVudCB3YXksIHdlIGNob3NlIGEpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmFodWwsIGFueSBjb21tZW50cz88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_982B626E107E334DBE601D979F31785C5DF192C3BLREML503MBSchi_-- From nobody Fri Jun 28 19:58:12 2019 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 5324B1202D7; Fri, 28 Jun 2019 19:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfFdYoHIbjO9; Fri, 28 Jun 2019 19:58:00 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B8312003F; Fri, 28 Jun 2019 19:58:00 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7B6BAA0A490BEA8D55F4; Sat, 29 Jun 2019 03:57:58 +0100 (IST) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 29 Jun 2019 03:57:37 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.241]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0439.000; Sat, 29 Jun 2019 08:27:25 +0530 From: Rahul Arvind Jadhav To: Martin Vigoureux , The IESG CC: "draft-ietf-roll-efficient-npdao@ietf.org" , Peter Van der Stok , "aretana.ietf@gmail.com" , "roll-chairs@ietf.org" , "roll@ietf.org" Thread-Topic: Martin Vigoureux's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) Thread-Index: AQHVLOdNw7Yz5yBN5kmurujYBJgKGKax5jwg Date: Sat, 29 Jun 2019 02:57:25 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF1B2EB@BLREML503-MBS.china.huawei.com> References: <156163998890.21568.17755918950369424230.idtracker@ietfa.amsl.com> In-Reply-To: <156163998890.21568.17755918950369424230.idtracker@ietfa.amsl.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Martin Vigoureux's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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 Jun 2019 02:58:03 -0000 VGhhbmsgeW91IE1hcnRpbiBmb3IgdGhlIHJldmlldyBhbmQgZmVlZGJhY2suDQpQbGVhc2UgZmlu ZCBteSByZXNwb25zZXMgaW5saW5lLg0KDQpUaGFua3MsDQpSYWh1bA0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkhpLA0KDQp0aGFuayB5b3UgZm9yIHRoaXMg ZG9jdW1lbnQuDQoNCkkgb25seSBoYXZlIG1pbm9yIGNvbW1lbnRzL3F1ZXN0aW9uczoNCiogUGxl YXNlIGV4cGFuZCBMTE5zDQpbUkpdIFllcy4gV2lsbCBhZGQgTExOIGluIHRoZSB0ZXJtaW5vbG9n eSBzZWN0aW9uLiBMTE4gdGVybSBpcyBub3QgdXNlZCBhbnl3aGVyZSBiZWZvcmUgdGVybWlub2xv Z3kgc2VjdGlvbiwgc28gaXQgc2hvdWxkIGJlIG9rIHRvIGFkZCBpbiB0ZXJtaW5vbG9neSBzZWN0 aW9uLg0KDQoqIGl0J3MgYSBiaXQgcGl0eSB0aGF0IEQgZmxhZyBpcyBiaXQgJzAnIGluIERDTyBh bmQgYml0ICcxJyBpbiBEQ08tQUNLDQpbUkpdOiBZZXMhDQoNCiogMHgwNSBSUEwgVGFyZ2V0IGFu ZCAweDA2IFRyYW5zaXQgSW5mb3JtYXRpb24gYXJlIFJQTCBDb250cm9sIE1lc3NhZ2UgT3B0aW9u cyBidXQgdGhleSBhcmUgbm90IHJlYWxseSBEQ08gT3B0aW9ucyBhcyB0aGV5IE1VU1QgYmUgcHJl c2VudC4NCltSSl06IFRoYXQncyB0cnVlISBUaGUgZG9jdW1lbnQgaGFzIGluaGVyaXRlZCB0aGlz IHRlcm1pbm9sb2d5IGZyb20gNjU1MCEgQnV0IEkgZG9uJ3QgdGhpbmsgd2UgY2FuIGNhbGwgIk9w dGlvbnMiIGFueXRoaW5nIGVsc2UgaW4gdGhpcyBkb2N1bWVudC4NCg0KKiBpdCBpcyBub3QgZnVs bHkgY2xlYXIgdG8gbWUgd2hldGhlciBQYXRoIFNlcXVlbmNlIGNhbiBvciBzaG91bGQgYmUgaW5j cmVtZW50ZWQgb24gRENPIHJldHJ5Lg0KW1JKXTogU2VjdGlvbiA0LjMuMyBjbGFyaWZpZXMgdGhh dCB0aGUgUGF0aCBTZXF1ZW5jZSBpbiBEQ08gc2hvdWxkIGJlIGNvcGllZCBmcm9tIHRoZSBEQU8g bWVzc2FnZSBpbiByZXNwb25zZSB0byB3aGljaCB0aGlzIERDTyBpcyBnZW5lcmF0ZWQuDQpJIGhh ZCB0byBhZGQgb25lIG1vcmUgc2VudGVuY2UgaGVyZSB0byBjbGFyaWZ5IGFub3RoZXIgY29uZGl0 aW9uLCAiV2hlbiB0aGUgRENPIGlzIGdlbmVyYXRlZCBpbiByZXNwb25zZSB0byBhIERDTyBmcm9t IHVwc3RyZWFtIHBhcmVudCwgdGhlIFBhdGggU2VxdWVuY2UgTVVTVCBiZSBjb3BpZWQgZnJvbSB0 aGUgcmVjZWl2ZWQgRENPLiINCg0KKiBJJ20gbm90IHN1cmUgdGhpcyBoYXMgYW55IG1lYW5pbmcg KGRpZG4ndCBoYXZlIGVub3VnaCB0aW1lIHRvIHRoaW5rIGFib3V0IHRoaXMgc2NlbmFyaW8pIGJ1 dCB3aGF0IHdvdWxkIGhhcHBlbiBpZiBEIHNlbmRzIGEgREFPIHdoaWNoIG5ldmVyIHJlYWNoZXMg QSBhbmQgQSBkZWNpZGVzIHRvIHNlbmQgYW4gdW5zb2xpY2l0ZWQgRENPLiBIb3cgd291bGQgRCBy ZWFjdCB0byByZWNlaXZpbmcgYSBtZXNzYWdlIHdpdGggYSBzZXF1ZW5jZSBudW1iZXIgd2hpY2gg aXMgc21hbGxlciB0aGFuIHRoZSBvbmUgaXQgaGFzIHNlbnQ/IElzIHRoYXQgYW4gaXNzdWU/DQpb UkpdIFRoaXMgaXMgYSBwb3NzaWJsZSBzY2VuYXJpby4gU2VjdGlvbiA0LjQuICJEQ08gQmFzZSBS dWxlcyIgcG9pbnQgNSBleHBsYWlucyBob3cgdG8gZGVhbCB3aXRoIHRoaXMuIEVzc2VudGlhbGx5 IHRoZSBEQ08gd291bGQgYmUgZHJvcHBlZCBiZWNhdXNlIHRoZSBQYXRoIFNlcXVlbmNlIGlzIG9s ZC4NCg0KKiBJIGZlZWwgdGhhdCBpbXBvc2luZyB0aGUgdW51c2VkIGZsYWdzIHRvIGJlIHNldCB0 byB6ZXJvIGlzIG5vdCBuZWNlc3NhcnkuDQpNVVNUIGlnbm9yZSB0aGUgdW5zcGVjaWZpZWQgZmxh Z3MgaXMgc3VmZmljaWVudC4NCltSSl0gQWdhaW4gdGhlIGRvY3VtZW50IGhhcyBpbmhlcml0ZWQg dGhlIHdvcmRpbmdzIGFzLWlzIGZyb20gdGhlIHBhcmVudCBkb2N1bWVudCAoUkZDIDY1NTApLiBV bmxlc3MgaXQgaXMgIm5lZWRlZCIgdG8gYmUgcmVtb3ZlZCwgSSB3b3VsZCBwcmVmZXIga2VlcGlu ZyBpdCBpbiBzeW5jLiBQbGVhc2UgbGV0IGtub3cgaWYgeW91IHN0aWxsIGJlbGlldmUgd2Ugc2hv dWxkIHJlbW92ZSB0aGUgaW1wb3Npbmcgc3RhdGVtZW50LiBUaGFua3MNCg== From nobody Fri Jun 28 20:50:40 2019 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 5203912092E; Fri, 28 Jun 2019 20:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTC-wgtPDMKH; Fri, 28 Jun 2019 20:50:29 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2C312009C; Fri, 28 Jun 2019 20:50:29 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4BA6443958B3FE9BD195; Sat, 29 Jun 2019 04:50:27 +0100 (IST) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 29 Jun 2019 04:50:26 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.241]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0439.000; Sat, 29 Jun 2019 09:20:13 +0530 From: Rahul Arvind Jadhav To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-roll-efficient-npdao@ietf.org" , Peter Van der Stok , "aretana.ietf@gmail.com" , "roll-chairs@ietf.org" , "roll@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtcm9s?= =?utf-8?Q?l-efficient-npdao-12:_(with_COMMENT)?= Thread-Index: AQHVLL3zZpC+U5khkUmZQg2bWVErwaayAVfQ Date: Sat, 29 Jun 2019 03:50:13 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF1B34A@BLREML503-MBS.china.huawei.com> References: <156162222904.21361.4930374476172246281.idtracker@ietfa.amsl.com> In-Reply-To: <156162222904.21361.4930374476172246281.idtracker@ietfa.amsl.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-roll-efficient-npdao-12=3A_=28with_COMMENT=29?= 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 Jun 2019 03:50:32 -0000 VGhhbmsgeW91IEVyaWMgZm9yIHRoZSByZXZpZXcuDQoNCkJhcnJ5IGdhdmUgdXMgYW4gdXBkYXRl ZCBhYnN0cmFjdCB0ZXh0IHdoaWNoIG5vdCBvbmx5IHJlYWRzIHdlbGwgYnV0IGFsc28gZml4ZXMg dGhlIGNvbW1lbnQgeW91IG1hZGUuIERDTyB3aWxsIGJlIG1lbnRpb25lZCBpbiB0aGUgYWJzdHJh Y3QuDQoNClRoYW5rcywNClJhaHVsDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNClRoYW5rIHlvdSBhbGwgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMgY2xlYXIg YW5kIHdlbGwtd3JpdHRlbiBkb2N1bWVudC4gSSBoYXZlIG9ubHkgb25lIENPTU1FTlQ6ICBEQ08g c2hvdWxkIGJlIG1lbnRpb25lZCBpbiB0aGUgYWJzdHJhY3QgYXMgdGhlIGRvY3VtZW50IGdvZXMg YmV5b25kIGEgcHJvYmxlbSBkZXNjcmlwdGlvbiAoYXMgY3VycmVudGx5IGRlc2NyaWJlZCBpbiB0 aGUgYWJzdHJhY3QpLg0KDQoNCg== From nobody Sun Jun 30 17:51:49 2019 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 918D81201E5; Sun, 30 Jun 2019 17:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKWgZyN5FyEg; Sun, 30 Jun 2019 17:51:37 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B95B1201DA; Sun, 30 Jun 2019 17:51:37 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 20455D0B4C5A9E3BB416; Mon, 1 Jul 2019 01:51:35 +0100 (IST) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 1 Jul 2019 01:51:34 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.50]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0439.000; Mon, 1 Jul 2019 06:21:23 +0530 From: Rahul Arvind Jadhav To: Benjamin Kaduk , The IESG CC: "draft-ietf-roll-efficient-npdao@ietf.org" , Peter Van der Stok , "aretana.ietf@gmail.com" , "roll-chairs@ietf.org" , "roll@ietf.org" Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) Thread-Index: AQHVK7Xi/CWQui2aBEWZkjjOk8ibZKa06qOA Date: Mon, 1 Jul 2019 00:51:22 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF26D0C@BLREML503-MBX.china.huawei.com> References: <156150881090.31233.460341246895590440.idtracker@ietfa.amsl.com> In-Reply-To: <156150881090.31233.460341246895590440.idtracker@ietfa.amsl.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT) 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, 01 Jul 2019 00:51:42 -0000 VGhhbmsgeW91IEJlbmphbWluIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3IGFuZCB0aGUgY29tbWVu dHMuDQpQbGVhc2UgZmluZCBteSByZXNwb25zZXMgaW5saW5lLg0KDQpUaGFua3MsDQpSYWh1bA0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJIHRoaW5rIHRoYXQg d2UgbmVlZCBncmVhdGVyIGNsYXJpdHkgYWJvdXQgd2hldGhlciB0aGUgRENPU2VxdWVuY2UgbnVt YmVyIGlzIGp1c3QgYSBzZXJpZXMgb2YgbW9ub3RvbmljIChpLmUuLCB0aW1lLW9yZGVyZWQpIG5v bmNlcyAodG8gYmUgZWNob2VkIGJhY2sgZm9yIG1hdGNoaW5nIHJlcXVlc3QvcmVzcG9uc2UpIG9y IGEgZnVsbC1vbiBzZXF1ZW5jZSBjb3VudGVyIHRoYXQgYWxsb3dzIGZvciBsb3NzIGRldGVjdGlv biBhcyB3ZWxsIGFzIHByb3ZpZGluZyBpbi1vcmRlciBkZWxpdmVyeS4NCkl0IHNvdW5kcyBsaWtl IHdlIGp1c3QgbmVlZCB0aGUgdGltZS1vcmRlcmluZyBhbmQgc2luZ2xlLXVzZSBwcm9wZXJ0aWVz LCBidXQgSSdtIG5vdCBlbnRpcmVseSBzdXJlLiAgSSB3YXZlcmVkIGFib3V0IG1ha2luZyB0aGlz IGEgRGlzY3VzcyBwb2ludCBidXQgZW5kZWQgdXAgbm90IGRvaW5nIHNvIHNpbmNlIEknbSBub3Qg c3VyZSBob3cgbXVjaCBoYXJtIGlzIGJlaW5nIHJpc2tlZC4gIChJIGFsc28gbWVudGlvbiB0aGlz IHRvcGljIGEgY291cGxlIHRpbWVzIGluIHRoZSBzZWN0aW9uLWJ5LXNlY3Rpb24gY29tbWVudHMg YmVsb3cuKQ0KDQpbUkpdIFRoZSBEQ09TZXF1ZW5jZSBpcyBub3QgZXhwZWN0ZWQgdG8gcHJvdmlk ZSBpbi1vcmRlciBkZWxpdmVyeS4gVGhlIHJlY2VpdmVyDQppcyBzaW1wbHkgZXhwZWN0ZWQgdG8g ZWNobyBiYWNrIHRoZSBEQ09TZXF1ZW5jZSB3aGF0ZXZlciBpcyByZWNlaXZlZCB3aGljaA0KaW5m b3JtcyB0aGUgc2VuZGVyIHRoYXQgdGhlIGluZm8gaXMgcmVjZWl2ZWQuIEV2ZW4gaWYgcmVjZWl2 ZWQgdW4tb3JkZXJlZCB0aGUgcmVjZWl2ZXIgaXMgZXhwZWN0ZWQgdG8ganVzdCBhY2sgdGhlIHJj dmQgRENPLg0KDQpJIGFncmVlIHdpdGggQmFycnkgdGhhdCB0aGUgQWJzdHJhY3QgaXMgcmVhbGx5 IGhhcmQgdG8gcGFyc2UuDQoNCltSSl0gWWVzLiBXZSBoYWQgdXBkYXRlZCB0aGUgYWJzdHJhY3Qg YXMgcGVyIEJhcnJ5J3Mgc3VnZ2VzdGlvbi4NCg0KU2VjdGlvbiAxLjINCg0KICAgUlBMIHVzZXMg TlBEQU8gbWVzc2FnaW5nIGluIHRoZSBzdG9yaW5nIG1vZGUgc28gdGhhdCB0aGUgbm9kZQ0KICAg Y2hhbmdpbmcgaXQgcm91dGluZyBhZGphY2VuY2llcyBjYW4gaW52YWxpZGF0ZSB0aGUgcHJldmlv dXMgcm91dGUuDQoNCm5pdDogIml0cyByb3V0aW5nIGFkamFjZW5jaWVzIg0KDQpbUkpdIEZpeGVk DQoNCiAgIFRoaXMgaXMgbmVlZGVkIHNvIHRoYXQgbm9kZXMgYWxvbmcgdGhlIHByZXZpb3VzIHBh dGggY2FuIHJlbGVhc2UgYW55DQogICByZXNvdXJjZXMgKHN1Y2ggYXMgdGhlIHJvdXRpbmcgZW50 cnkpIGl0IG1haW50YWlucyBvbiBiZWhhbGYgb2YNCiAgIHRhcmdldCBub2RlLg0KDQpuaXQ6IHNp bmd1bGFyL3BsdXJhbCBtaXNtYXRjaCAibm9kZXMiLyJpdCBtYWludGFpbnMiDQpbUkpdIGNoYW5n ZWQgIml0IG1haW50YWlucyIgdG8gInRoZXkgbWFpbnRhaW4iDQoNClNlY3Rpb24gNC4xDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFdoZW4gbm9kZSBBDQogICByZWNlaXZlcyB0aGUgcmVndWxhciBEQU8sIGl0IGZpbmRzIHRoYXQg aXQgYWxyZWFkeSBoYXMgYSByb3V0aW5nDQogICB0YWJsZSBlbnRyeSBvbiBiZWhhbGYgb2YgdGhl IHRhcmdldCBhZGRyZXNzIG9mIG5vZGUgRC4gIEl0IGZpbmRzDQogICBob3dldmVyIHRoYXQgdGhl IG5leHQgaG9wIGluZm9ybWF0aW9uIGZvciByZWFjaGluZyBub2RlIEQgaGFzIGNoYW5nZWQNCiAg IGkuZS4sIG5vZGUgRCBoYXMgZGVjaWRlZCB0byBjaGFuZ2UgdGhlIHBhdGhzLiAgSW4gdGhpcyBj YXNlLCBOb2RlIEENCiAgIHdoaWNoIGlzIHRoZSBjb21tb24gYW5jZXN0b3Igbm9kZSBmb3Igbm9k ZSBEIGFsb25nIHRoZSB0d28gcGF0aHMNCiAgIChwcmV2aW91cyBhbmQgbmV3KSwgc2hvdWxkIGdl bmVyYXRlIGEgRENPIHdoaWNoIHRyYXZlcnNlcyBkb3dud2FyZHMNCiAgIGluIHRoZSBuZXR3b3Jr Lg0KDQpJIGNhbid0IGRlY2lkZSB3aGV0aGVyIG9yIG5vdCBpdCBoZWxwcyByZWFkYWJpbGl0eSB0 byByZWl0ZXJhdGUgdGhhdCBpbiBhZGRpdGlvbiB0byBjcmVhdGluZyB0aGUgRENPLCBub2RlIEEg YWxzbyBkb2VzIG5vcm1hbCBEQU8gcHJvY2Vzc2luZyAoZS5nLiwgZm9yd2FyZGluZyB0byB0aGUg NkxCUikuICBJIGd1ZXNzIHRoZSBleGFtcGxlIGluIEEuMSBkb2VzIHNob3cgdGhpcyBub3JtYWwg cHJvY2Vzc2luZywgc28gbWF5YmUgaXQncyBvdmVya2lsbCB0byBhbHNvIGRvIHNvIGhlcmUuDQoN CltSSl0gQXMgeW91IGhpbnRlZCwgSXQgd291bGQgYmUgYmV0dGVyIGZvciB0aGUgc2FrZSBvZiBj b21wbGV0ZW5lc3MgdG8gYWRkIERBTyBwcm9jZXNzaW5nIHBvaW50IGhlcmUgYXMgd2VsbC4gSSBo YXZlIGFkZGVkIGEgc3RhdGVtZW50IHNheWluZywgIk5vZGUgQSBoYW5kbGVzIG5vcm1hbCBEQU8g Zm9yd2FyZGluZyB0bw0KNkxCUiBhcyByZXF1aXJlZCBieSB0aGUgUkZDNjU1MC4iDQoNClNlY3Rp b24gNC4yDQoNCiAgICAgICAgICAgICAgIFRyYW5zaXQgSW5mb3JtYXRpb24gT3B0aW9uIHNob3Vs ZCBiZSBjYXJyaWVkIGluIHRoZSBEQU8NCiAgIG1lc3NhZ2Ugd2l0aCBJLWZsYWcgc2V0IGluIGNh c2Ugcm91dGUgaW52YWxpZGF0aW9uIGlzIHNvdWdodCBmb3IgdGhlDQogICBjb3JyZXNwb25kaW5n IHRhcmdldChzKS4NCg0Kbml0OiB0aGlzIHRleHQgYXMgd3JpdHRlbiBpbXBsaWVzIHRoYXR0aGUg SS1mbGFnIGlzIHNldCBpbiB0aGUgREFPIGl0c2VsZiwgbm90IHRoZSBUSU8gdGhlcmVpbi4NCg0K W1JKXSBVcGRhdGVkIHRvIHNheSwgIlRyYW5zaXQgSW5mb3JtYXRpb24gT3B0aW9uIHdpdGggSS1m bGFnIHNldCBzaG91bGQgYmUgY2FycmllZCBpbiB0aGUgREFPIG1lc3NhZ2Ugd2hlbiByb3V0ZSBp bnZhbGlkYXRpb24gaXMgc291Z2h0IC4uLiINCg0KSSdkIGFsc28gc3VnZ2VzdCB0byBzL2luIGNh c2Uvd2hlbi8gZm9yIGNsYXJpdHkuDQoNCltSSl0gRml4ZWQgYXMgbWVudGlvbmVkIGFib3ZlLg0K DQogICBUaGUgY29tbW9uIGFuY2VzdG9yIG5vZGUgU0hPVUxEIGdlbmVyYXRlIGEgRENPIG1lc3Nh Z2UgaW4gcmVzcG9uc2UgdG8NCiAgIHRoaXMgSS1mbGFnIHdoZW4gaXQgc2VlcyB0aGF0IHRoZSBy b3V0aW5nIGFkamFjZW5jaWVzIGhhdmUgY2hhbmdlZA0KICAgZm9yIHRoZSB0YXJnZXQuICBJLWZs YWcgZ292ZXJucyB0aGUgb3duZXJzaGlwIG9mIHRoZSBEQ08gbWVzc2FnZSBpbiBhDQogICB3YXkg dGhhdCB0aGUgdGFyZ2V0IG5vZGUgaXMgc3RpbGwgaW4gY29udHJvbCBvZiBpdHMgb3duIHJvdXRl DQogICBpbnZhbGlkYXRpb24uDQoNCm5pdDogIlRoZSBJLWZsYWciIChzdGFydCBvZiBsYXN0IHNl bnRlbmNlKS4NCg0KW1JKXSBGaXhlZA0KDQpJJ2QgZnVydGhlciBzdWdnZXN0IHJld29yZGluZyB0 byBzb21ldGhpbmcgbGlrZSAiVGhlIEktZmxhZyBpcyBpbnRlbmRlZCB0byBnaXZlIHRoZSB0YXJn ZXQgbm9kZSBjb250cm9sIG92ZXIgaXRzIG93biByb3V0ZSBpbnZhbGlkYXRpb24sIHNlcnZpbmcg YXMgYSBzaWduYWwgdG8gcmVxdWVzdCBEQ08gZ2VuZXJhdGlvbjsgaW4gbm9ybWFsIG9wZXJhdGlv biBhIERDTyB3b3VsZCBub3Qgb3RoZXJ3aXNlIGJlIGdlbmVyYXRlZCI7IHRoZSBjdXJyZW50IHRl eHQgYWJvdXQgIm93bmVyc2hpcCIgaGFzIHNvbWUgd2VpcmQgY29ubm90YXRpb25zL2ltcGxpY2F0 aW9ucyBhbmQgdGhpcyB0ZXh0IGFsc28gaW1wbGljaXRseSBhc3N1bWVzIHRoYXQgREFPL1RJTy9J LWZsYWcgd2lsbCBuZXZlciBiZSBtYWxpY2lvdXNseSBnZW5lcmF0ZWQuICBJdCBpcyBhbHNvIGEg bGl0dGxlIHdlYWtlciBhYm91dCB1bnNvbGljaXRlZCBEQ08sIHBlciBTZWN0aW9uIDQuNQ0KDQpb UkpdIEhhdmUgdXBkYXRlZCB0aGUgdGV4dCwgIiBUaGUgSS1mbGFnIGlzIGludGVuZGVkIHRvIGdp dmUgdGhlIHRhcmdldCBub2RlIGNvbnRyb2wgb3ZlciBpdHMgb3duIHJvdXRlIGludmFsaWRhdGlv biwgc2VydmluZyBhcyBhIHNpZ25hbCB0byByZXF1ZXN0IERDTyBnZW5lcmF0aW9uLiINCkkgaGF2 ZSBhdm9pZGVkIHRvIHNheSAiaW4gbm9ybWFsIG9wZXJhdGlvbiBhIERDTyB3b3VsZCBub3Qgb3Ro ZXJ3aXNlIGJlIGdlbmVyYXRlZCIgZXNwZWNpYWxseSBnaXZlbiB0aGUgY2FzZSBvZiB1bnNvbGlj aXRlZCBEQ08uDQoNClNlY3Rpb24gNC4zDQoNCiAgIEEgbmV3IElDTVB2NiBSUEwgY29udHJvbCBt ZXNzYWdlIHR5cGUgaXMgZGVmaW5lZCBieSB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbGxlZCBh cyAiRGVzdGluYXRpb24gQ2xlYW51cCBPYmplY3QiIChEQ08pLCB3aGljaCBpcw0KDQpuaXQ6IGVp dGhlciAiY2FsbGVkIiBvciAia25vd24gYXMiIG9yICJyZWZlcnJlZCB0byBhcyIgd291bGQgYmUg ZmluZTsgImNhbGxlZCBhcyIgaXMgYSBncmFtbWF0aWNhbCBtaXNtYXRjaC4NCg0KW1JKXSBmaXhl ZC4gdXNpbmcgInJlZmVycmVkIHRvIGFzIg0KDQogICBEQ09TZXF1ZW5jZTogSW5jcmVtZW50ZWQg YXQgZWFjaCB1bmlxdWUgRENPIG1lc3NhZ2UgZnJvbSBhIG5vZGUgYW5kDQogICBlY2hvZWQgaW4g dGhlIERDTy1BQ0sgbWVzc2FnZS4gIFRoZSBpbml0aWFsIERDT1NlcXVlbmNlIGNhbiBiZSBjaG9z ZW4NCiAgIHJhbmRvbWx5IGJ5IHRoZSBub2RlLg0KDQpXaGF0J3MgdGhlIGJlaGF2aW9yIGlmIGEg c2VxdWVuY2UgbnVtYmVyIGlzIHNraXBwZWQ/ICAoV2h5IGRvIHdlIGhhdmUgYSBzZXF1ZW5jZSBu dW1iZXIgaWYgd2UgYXJlbid0IGdvaW5nIHRvIGRldGVjdCBhbmQgYWN0IG9uIHRoaXMgY29uZGl0 aW9uPykgQWgsIEkgc2VlIFNlY3Rpb24gNC4zLjMsIGJ1dCBwZXJoYXBzIGEgZm9yd2FyZC1yZWZl cmVuY2UgaXMgaW4gb3JkZXIuDQoNCltSSl0gQWRkZWQgYSBmb3J3YXJkLXJlZmVyZW5jZS4NCg0K U2VjdGlvbiA0LjMuNA0KDQpJdCBzZWVtcyB0aGF0IHRoZSAiUmVzZXJ2ZWQiIGZpZWxkIHNob3Vs ZCBiZSBjYWxsZWQgIkZsYWdzIiwgc2luY2UgYSByZWdpc3RyeSBpcyBiZWluZyBjcmVhdGVkIGZv ciBpdC4NCg0KW1JKXSBZZXMsIGNoYW5nZWQgdGhlICJSZXNlcnZlZCIgZmllbGQgbmFtZSB0byAi RmxhZ3MiIGluIGJvdGggdGhlIGZpZ3VyZSBhcyB3ZWxsIGFzIHRoZSBkZXNjcmlwdGlvbiBiZWxv dy4NCg0KKEkgdHJ1c3QgdGhhdCB0aGUgbGFuZ3VhZ2UgYWJvdXQgdGhlIEQgZmxhZyBhbmQgRE9E QUdJRCBvcHRpb25hbGl0eSBmcm9tIEJhcnJ5J3MgYmFsbG90IHRocmVhZCBpcyBjb25zaXN0ZW50 IGJldHdlZW4gRENPIGFuZCBEQ08tQUNLLikNCg0KW1JKXSBZZXMgdGhlIERPREFHSUQgb3B0aW9u YWxpdHkgc3RhdGVtZW50IGlzIGZpeGVkIGluIGJvdGggdGhlIHBsYWNlcyBhcyBwZXIgQmFycnkn cyBzdWdnZXN0aW9uLiBUaGFua3MgZm9yIHJlbWluZGluZyBhYm91dCB0aGUgdHdvIHBsYWNlcyB0 byBmaXguDQoNClNlY3Rpb24gNC40DQoNCiAgIDEuICBJZiBhIG5vZGUgc2VuZHMgYSBEQ08gbWVz c2FnZSB3aXRoIG5ld2VyIG9yIGRpZmZlcmVudCBpbmZvcm1hdGlvbg0KICAgICAgIHRoYW4gdGhl IHByaW9yIERDTyBtZXNzYWdlIHRyYW5zbWlzc2lvbiwgaXQgTVVTVCBpbmNyZW1lbnQgdGhlDQog ICAgICAgRENPU2VxdWVuY2UgZmllbGQgYnkgYXQgbGVhc3Qgb25lLiAgQSBEQ08gbWVzc2FnZSB0 cmFuc21pc3Npb24NCiAgICAgICB0aGF0IGlzIGlkZW50aWNhbCB0byB0aGUgcHJpb3IgRENPIG1l c3NhZ2UgdHJhbnNtaXNzaW9uIE1BWQ0KICAgICAgIGluY3JlbWVudCB0aGUgRENPU2VxdWVuY2Ug ZmllbGQuDQoNCldoaWxlIHJlYWRpbmcgdXAgdG8gdGhpcyBwb2ludCBJIG1hbmFnZWQgdG8gY29u ZnVzZSBteXNlbGYgYWJvdXQgUGF0aCBTZXF1ZW5jZSAod2hpY2ggbXVzdCBiZSBjb25zaXN0ZW50 IGZyb20gREFPIHRvIERDTykgYW5kIHRoZSBzZXBhcmF0ZSBEQU9TZXF1ZW5jZSBhbmQgRENPU2Vx dWVuY2UgZmllbGRzLiAgVG8gY2hlY2sgbXkgKGxlc3MgY29uZnVzZWQpIHVuZGVyc3RhbmRpbmcs IEkgZ3Vlc3MgaWYgSSBjb3VsZCBvdmVyLXN1bW1hcml6ZSwgUGF0aCBTZXF1ZW5jZSBpcyBsaWtl IGEgZ2VuZXJhdGlvbiBjb3VudGVyIGZvciBhIGdpdmVuIG5vZGUncyBwb3NpdGlvbiBpbiB0aGUg cm91dGluZyB0b3BvbG9neSwgYW5kIHRoZSBvdGhlciB0d28gYXJlIGZvciBtYW5hZ2luZyByZXRy YW5zbWlzc2lvbi9hY2sgb2YgdGhlIHJlc3BlY3RpdmUgdXBkYXRlIG1lc3NhZ2VzLiAgU28gaWYg dGhhdCBtZW50YWwgbW9kZWwgaXMgY29ycmVjdCwgdGhlbiB0aGVyZSdzIG5vdCBhbnkgdmFsdWUg ZnJvbSB0cnlpbmcgdG8gaW50cm9kdWNlIGEgc2hhcmVkIHNlcXVlbmNlIG51bWJlciBzcGFjZSBm b3IgRENPIGFuZCBEQU8sIGV2ZW4gdGhvdWdoIHRoZXkgYXJlIGZyZXF1ZW50bHkgZ29pbmcgdG8g YmUgZ2VuZXJhdGVkIGF0IHRoZSBzYW1lIHRpbWUsIGVzcGVjaWFsbHkgc2luY2UgdGhleSBoYXZl IGRpZmZlcmVudCByZWNpcGllbnRzLiAgUmlnaHQ/DQoNCltSSl0gVGhlIERBT1NlcXVlbmNlIGFu ZCBEQ09TZXF1ZW5jZSBhcmUgbm90IGRlcGVuZGVudCBvbiBlYWNoIG90aGVyIGF0IGFsbC4NClll cywgdGhlIERBTyBjb3VsZCBiZSBnZW5lcmF0ZWQgYW5kIERDTyBjb3VsZCBiZSBnZW5lcmF0ZWQg YXQgdGhlIHNhbWUgdGltZSBmb3INCmRpZmZlcmVudCByZWNpcGllbnRzLg0KDQpJIGRvIGFncmVl IHdpdGggdGhlIG90aGVyIGRpc2N1c3Npb24gdGhhdCB3ZSBuZWVkIGNsYXJpdHkgYWJvdXQgd2hl dGhlciB0aGUgaW5jcmVtZW50IGlzIGV4YWN0bHkgb25lIG9yIGxhcmdlciB2YWx1ZXMgYXJlIGFs bG93ZWQgKHBsdXMsIHByZXN1bWFibHksIHdoZXRoZXIgdGhlIHJlY2lwaWVudCBzaG91bGQgaW5m ZXIgYW55dGhpbmcgZnJvbSBhIHNlcXVlbmNlIG51bWJlciBnYXApLiAgSSBkbyBub3RlIHRoYXQg dGhlc2UgYXJlIGV4cGVjdGVkIHRvIGJlICJsb2xsaXBvcCBzZXF1ZW5jZSBjb3VudGVycyIgcGVy IFJGQyA2NTUwLg0KDQpbUkpdIFRoaXMgd2lsbCBiZSBmaXhlZCBpLmUuLCB3ZSB3aWxsIG1ha2Ug aXQgZXhwbGljaXQgYWJvdXQgdGhlIHNlcXVlbmNlDQpjb3VudGVyIG9wZXJhdGlvbiBhbmQgYWRk IGEgcmVmIHRvIHRoZSBjb3JyZXNwb25kaW5nIHNlY3Rpb24gaW4gNjU1MC4NCg0KICAgNC4gIEEg bm9kZSByZWNlaXZpbmcgYSB1bmljYXN0IERDTyBtZXNzYWdlIHdpdGggdGhlICdLJyBmbGFnIHNl dA0KICAgICAgIFNIT1VMRCByZXNwb25kIHdpdGggYSBEQ08tQUNLLiAgQSBub2RlIHJlY2Vpdmlu ZyBhIERDTyBtZXNzYWdlDQogICAgICAgd2l0aG91dCB0aGUgJ0snIGZsYWcgc2V0IE1BWSByZXNw b25kIHdpdGggYSBEQ08tQUNLLCBlc3BlY2lhbGx5DQogICAgICAgdG8gcmVwb3J0IGFuIGVycm9y IGNvbmRpdGlvbi4NCg0KVGhpcyBzZWVtcyByZWR1bmRhbnQgd2l0aCBTZWN0aW9uIDQuMydzICJB IG5vZGUgcmVjZWl2aW5nIGEgRENPIG1lc3NhZ2Ugd2l0aG91dCB0aGUgJ0snIGZsYWcgc2V0IE1B WSByZXNwb25kIHdpdGggYSBEQ08tQUNLLCBlc3BlY2lhbGx5IHRvIHJlcG9ydCBhbiBlcnJvciBj b25kaXRpb24uIg0KDQpbUkpdIFllcyBpdCBpcyByZWR1bmRhbnQuIEJ1dCBpIGZlZWwgaXQgaXMg YmV0dGVyIHRvIGhhdmUgaXQgaW4gYm90aCBwbGFjZXMuDQpUaGUgc3RhdGVtZW50cyBhcmUgY29u c2lzdGVudCB3aXRoIGVhY2ggb3RoZXIuDQoNClNlY3Rpb24gNC40DQoNCiAgIFRoZSBzY29wZSBv ZiBEQ09TZXF1ZW5jZSB2YWx1ZXMgaXMgdW5pcXVlIHRvIGVhY2ggbm9kZS4NCg0KcmVjaXBpZW50 IG9yIG9yaWdpbmF0b3I/DQoNCltSSl0gQ2hhbmdlZCB0aGlzIHRvLCAiVGhlIHNjb3BlIG9mIERD T1NlcXVlbmNlIHZhbHVlcyBpcyB1bmlxdWUgdG8gdGhlIG5vZGUNCndoaWNoIGdlbmVyYXRlcyBp dC4iDQoNClNlY3Rpb24gNC41DQoNCiAgIHBhdGggb24gYmVoYWxmIG9mIHRoZSB0YXJnZXQgZW50 cnkuICBUaGUgNkxSIGhhcyBhbGwgdGhlIHN0YXRlDQogICBpbmZvcm1hdGlvbiBuYW1lbHksIHRo ZSBUYXJnZXQgYWRkcmVzcyBhbmQgdGhlIFBhdGggU2VxdWVuY2UsDQoNCm5pdDogY29tbWEgYmVm b3JlICJuYW1lbHkiLg0KDQpbUkpdIEZpeGVkDQoNClNlY3Rpb24gNC42LjINCg0KICAgRXZlbiB3 aXRoIHRoZSBjaGFuZ2VkIHNlbWFudGljcywgdGhlIGN1cnJlbnQgTlBEQU8gbWVjaGFuaXNtIGlu DQogICBbUkZDNjU1MF0gY2FuIHN0aWxsIGJlIHVzZWQsIGZvciBleGFtcGxlLCB3aGVuIHRoZSBy b3V0ZSBsaWZldGltZQ0KICAgZXhwaXJ5IG9mIHRoZSB0YXJnZXQgaGFwcGVucyBvciB3aGVuIHRo ZSBub2RlIHNpbXBseSBkZWNpZGVzIHRvDQogICBncmFjZWZ1bGx5IHRlcm1pbmF0ZSB0aGUgUlBM IHNlc3Npb24gb24gZ3JhY2VmdWwgbm9kZSBzaHV0ZG93bi4NCg0KRXIsIHdoYXQgY2hhbmdlZCBz ZW1hbnRpY3M/ICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGhhdmUgYW4gVXBkYXRlczoNCnJlbGF0 aW9uc2hpcCB0byBhbnkgb3RoZXIgZG9jdW1lbnQuDQoNCltSSl0gSSBoYXZlIHJld29yZGVkIHRo ZSBzZWN0aW9uIHJlbW92aW5nIHRoZSBzdGF0ZW1lbnQsICJFdmVuIHdpdGggdGhlIGNoYW5nZWQN CnNlbWFudGljcyIuIEFsc28gKEkgYmVsaWV2ZSkgdGhlIHNlY3Rpb24gaXMgbW9yZSByZWFkYWJs ZSBub3cuDQoNClNlY3Rpb24gNC42LjMNCg0KICAgTm90ZSB0aGF0IHRoZXJlIGlzIG5vIHJlcXVp cmVtZW50IG9mIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIERDTyBhbmQNCiAgIERBT3MuICBUaGUg RGVsYXlEQ08gdGltZXIgc2ltcGx5IGVuc3VyZXMgdGhhdCB0aGUgRENPIGNvbnRyb2wNCiAgIG92 ZXJoZWFkIGNhbiBiZSByZWR1Y2VkIGFuZCBpcyBvbmx5IG5lZWRlZCB3aGVuIHRoZSBuZXR3b3Jr IGNvbnRhaW5zDQogICBub2RlcyB1c2luZyBtdWx0aXBsZSBwcmVmZXJyZWQgcGFyZW50Lg0KDQpU aGlzICgibm8gcmVxdWlyZW1lbnQgb2Ygc3luY2hyb25pemF0aW9uIikgaXMgYmVjYXVzZSB0aGUg YmVuZWZpdCBvZiBEQ08gaXMgaW4gZXhwaXJpbmcgcm91dGVzIGZhc3RlciB0aGFuIHRoZWlyIG5v cm1hbCBleHBpcmF0aW9uIHRpbWUgdG8gc2F2ZSBsb2NhbCBzdG9yYWdlLCByYXRoZXIgdGhhbiB0 byBwcm92aWRlIHN5bmNocm9ub3VzIHJvdXRlIG1pZ3JhdGlvbj8gIChJdCBtaWdodCBiZSB3b3J0 aCByZWl0ZXJhdGluZywgaWYgeW91IHdhbnQuKQ0KDQpbUkpdIFNvcnJ5LCBidXQgaSBkaWRuJ3Qg dW5kZXJzdGFuZCB0aGlzLiBJIGRpZG4ndCB1bmRlcnN0YW5kIHdoeSB0aGUgc3RhdGVtZW50DQoi dGhlIGJlbmVmaXRzIG9mIERDTyBpcyBpbiBleHBpcmluZyByb3V0ZXMgZmFzdGVyIHRoYW4gdGhl aXIgbm9ybWFsIGV4cGlyYXRpb24NCnRpbWUgLi4uLiIgc2hvdWxkIGJlIG1lbnRpb25lZCBpbiB0 aGlzIGNvbnRleHQ/IE5QREFPIGFuZCBEQ08gYm90aCBhcmUNCnByb2FjdGl2ZSByb3V0ZSBpbnZh bGlkYXRpb24gbWVzc2FnaW5nIHRlY2huaXF1ZXMgYW5kIHRoZXkgYm90aCBoZWxwIGluIGV4cGly aW5nDQpyb3V0ZXMgZmFzdGVyIHRoYW4gdGhlaXIgbm9ybWFsIGV4cGlyYXRpb24gdGltZXMuIERD TyBzaW1wbHkgaXMgbW9yZSByZWxpYWJsZQ0KZHVlIHRvIGl0cyB1c2Ugb24gbW9yZSByZWxpYWJs ZSBsaW5rcy4NCg0KU2VjdGlvbiA3DQoNCiAgIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUg YWJpbGl0eSBmb3IgYSBjb21tb24gYW5jZXN0b3Igbm9kZSB0bw0KICAgaW52YWxpZGF0ZSBhIHJv dXRlIG9uIGJlaGFsZiBvZiB0aGUgdGFyZ2V0IG5vZGUuICBUaGUgY29tbW9uIGFuY2VzdG9yDQog ICBub2RlIGlzIGRpcmVjdGVkIHRvIGRvIHNvIGJ5IHRoZSB0YXJnZXQgbm9kZSB1c2luZyB0aGUg J0knIGZsYWcgaW4NCiAgIERDTydzIFRyYW5zaXQgSW5mb3JtYXRpb24gT3B0aW9uLiAgSG93ZXZl ciwgdGhlIGNvbW1vbiBhbmNlc3RvciBub2RlDQoNCm5pdCg/KTogdGhlcmUncyBwZXJoYXBzIHNv bWUgd29yZHNtaXRoaW5nIHBvc3NpYmxlIGFib3V0ICJpcyBkaXJlY3RlZCB0byBkbyBzbyIsIGdp dmVuIHRoZSBuZXh0IHNlbnRlbmNlIGFuZCBTZWN0aW9uIDQuNS4NCg0KW1JKXSBJIGNoYW5nZWQg dGhlIHN0YXRlbWVudCwgIlRoZSBjb21tb24gYW5jZXN0b3Igbm9kZSBpcyBkaXJlY3RlZCB0byBk byBzbyBieQ0KdGhlIHRhcmdldCBub2RlIC4uLiIgdG8gIlRoZSBjb21tb24gYW5jZXN0b3Igbm9k ZSBjb3VsZCBiZSBkaXJlY3RlZCB0byBkbyBzbyBieQ0KdGhlIHRhcmdldCBub2RlIC4uLiINCg0K ICAgaXMgYWxzbyBtZXQuICBIYXZpbmcgc2FpZCB0aGF0IGEgbWFsaWNpb3VzIDZMUiBtYXkgc3Bv b2YgYSBEQU8gb24NCiAgIGJlaGFsZiBvZiB0aGUgKHN1YikgY2hpbGQgd2l0aCB0aGUgSS1mbGFn IHNldCBhbmQgY2FuIGNhdXNlIHJvdXRlDQogICBpbnZhbGlkYXRpb24gb24gYmVoYWxmIG9mIHRo ZSAoc3ViKSBjaGlsZCBub2RlLg0KDQpJSVVDLCBzdWNoIGEgbWFsaWNpb3VzIDZMUiBtaWdodCBh bHNvIHNwb29mIGEgREFPIGV2ZW4gd2l0aG91dCB0aGlzIG1lY2hhbmlzbSAodG8gaW52YWxpZGF0 ZSB0aGUgInByb3BlciIgUGF0aCBTZXF1ZW5jZSkgb3Igb3RoZXJ3aXNlIGNhdXNlIGRlbmlhbCBv ZiBzZXJ2aWNlIGJ5IGRyb3BwaW5nIHRyYWZmaWMgZW50aXJlbHksIHNvIHBlcmhhcHMgd2Ugd2Fu dCB0byBhZGQgYW5vdGhlciBjbGF1c2UgIiwgc28gdGhpcyBuZXcgbWVjaGFuaXNtIGRvZXMgbm90 IHByZXNlbnQgYSBzdWJzdGFudGlhbGx5IGluY3JlYXNlZCByaXNrIG9mIGRpc3J1cHRpb24iLg0K DQpbUkpdIFJld29yZGVkIGFuZCBhZGRlZCBuZXcgc3RhdGVtZW50cyBiYXNlZCBvbiB5b3VyIHN1 Z2dlc3Rpb25zIHRvIHRoaXMgcGFyYS4NCg0KICAgVGhpcyBkb2N1bWVudCBhc3N1bWVzIHRoYXQg dGhlIHNlY3VyaXR5IG1lY2hhbmlzbXMgYXMgZGVmaW5lZCBpbg0KICAgW1JGQzY1NTBdIGFyZSBm b2xsb3dlZCwgd2hpY2ggbWVhbnMgdGhhdCB0aGUgY29tbW9uIGFuY2VzdG9yIG5vZGUgYW5kDQog ICBhbGwgdGhlIDZMUnMgYXJlIHBhcnQgb2YgdGhlIFJQTCBuZXR3b3JrIGJlY2F1c2UgdGhleSBo YXZlIHRoZQ0KICAgcmVxdWlyZWQgY3JlZGVudGlhbHMuICBBIG5vbi1zZWN1cmUgUlBMIG5ldHdv cmsgbmVlZHMgdG8gdGFrZSBpbnRvDQogICBjb25zaWRlcmF0aW9uIHRoZSByaXNrcyBoaWdobGln aHRlZCBpbiB0aGlzIHNlY3Rpb24uDQoNCkknZCBjb25zaWRlciBhZGRpbmcgImFzIHdlbGwgYXMg dGhvc2UgaGlnaGxpZ2h0ZWQgaW4gW1JGQzY1NTBdIiB0byB0aGUgZW5kLg0KDQpbUkpdIEFkZGVk IHRoZSBtZW50aW9uZWQgd29yZHMgdG8gdGhlIGVuZCBvZiB0aGUgcGFyYS4NCg0KQXBwZW5kaXgg QS4xDQoNCiAgIDYuICBOb2RlIEcgcmVjZWl2ZXMgdGhlIERDTyh0Z3Q9RCxwYXRoc2VxPXgrMSku ICBJdCBjaGVja3MgaWYgdGhlDQogICAgICAgcmVjZWl2ZWQgcGF0aCBzZXF1ZW5jZSBpcyBsYXRl c3QgYXMgY29tcGFyZWQgdG8gdGhlIHN0b3JlZCBwYXRoDQogICAgICAgc2VxdWVuY2UuICBJZiBp dCBpcyBsYXRlc3QsIE5vZGUgRyBpbnZhbGlkYXRlcyByb3V0aW5nIGVudHJ5IG9mDQogICAgICAg dGFyZ2V0IEQgYW5kIGZvcndhcmRzIHRoZSAodW4pcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uIGRv d25zdHJlYW0NCiAgICAgICB0byBCIGluIERDTyh0Z3Q9RCxwYXRoc2VxPXgrMSkuDQoNClRoaXMg d29yZGluZyBvZiAibGF0ZXN0IGFzIGNvbXBhcmVkIHRvIiBmZWVscyB1bnVzdWFsIHRvIG1lOyBJ IHdvdWxkIGhhdmUgZXhwZWN0ZWQgImlzIGxhdGVyIHRoYW4gdGhlIHN0b3JlZCBwYXRoIHNlcXVl bmNlIiBhbmQgIklmIGl0IGlzIGxhdGVyIiwgYnV0IHBlcmhhcHMgdGhlcmUgaXMgYSBjb252ZW50 aW9uIGhlcmUgdGhhdCBJJ20gbWlzc2luZy4NCg0KW1JKXSBJIGNvdWxkIG5vdCBmaW5kIGEgZ2Vu ZXJhbCBjb252ZW50aW9uIGhlcmUgKGFmdGVyIGNoZWNraW5nIGluIDY1NTApLCBzbyBJDQpjaGFu Z2VkIGl0IHBlciB5b3VyIHN1Z2dlc3Rpb24gdG8gdXNlICJsYXRlciIgaW4gYm90aCB0aGUgc3Rh dGVtZW50cy4NCg0Kbml0OiAiaW52YWxpZGF0ZXMgdGhlIHJvdXRpbmcgZW50cnkiDQoNCltSSl0g Rml4ZWQuDQoNCiAgIDkuICBUaGUgcHJvcGFnYXRpb24gb2YgdGhlIERDTyB3aWxsIHN0b3AgYXQg YW55IG5vZGUgd2hlcmUgdGhlIG5vZGUNCiAgICAgICBkb2VzIG5vdCBoYXZlIGFuIHJvdXRpbmcg aW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSB0YXJnZXQuDQogICAgICAgSWYgdGhlIHJv dXRpbmcgaW5mb3JtYXRpb24gaXMgcHJlc2VudCBhbmQgaXRzIFBhdGggU2VxdWVuY2UgaXMNCiAg ICAgICBoaWdoZXIsIHRoZW4gc3RpbGwgdGhlIERDTyBpcyBkcm9wcGVkLg0KDQpuaXQ6IG1heWJ5 ZSByZXdvcmQgdG8gIklmIGNhY2hlZCByb3V0aW5nIGluZm9ybWF0aW9uIGlzIHByZXNlbnQgYW5k IHRoZSBjYWNoZWQgUGF0aCBTZXF1ZW5jZSBpcyBoaWdoZXIgdGhhbiB0aGUgdmFsdWUgaW4gdGhl IERDTywgdGhlbiB0aGUgRENPIGlzIGRyb3BwZWQiLg0KDQpbUkpdIFRoaXMgc291bmRzIGxvdCBi ZXR0ZXIuIFRoYW5rcyBmb3IgdGhlIHRleHQuDQoNCkFwcGVuZGl4IEEuMg0KDQpJIGZlZWwgbGlr ZSB3ZSBzaG91bGQgcHJvYmFibHkgbWVudGlvbiB0aGUgRGVsYXlEQU8gdGltZXIgYXMgd2VsbCBh cyB0aGUgRGVsYXlEQ08gb25lLg0KDQpJIHRoaW5rIHRoaXMgaXMgYSBzaWRlIG5vdGUsIGJ1dCBp dCBzZWVtcyBsaWtlIHRoZSB0aW1lciBtZWNoYW5pc20gZm9yIERlbGF5REFPIChhbmQgYnkgZXh0 ZW5zaW9uLCBEZWxheURDTykgYXJlIGEgYml0IGZyYWdpbGUsIGFzIG9uZSBwYXJ0eSBoYXMgdG8g d2FpdCBmb3IgdGhlIGZ1bGwgdGltZW91dCBiZWZvcmUgc2VuZGluZyB0aGUgbWVzc2FnZSAoZS5n LiwgTjIyIGluIHRoaXMgZXhhbXBsZSkgdGhhdCB0aGUgb3RoZXIgcGFydHkgaXMgd2FpdGluZyB0 aGUgdGltZW91dCB0byByZWNlaXZlIChlLmcuLCBOMTEpLiAgU28gaXQgc2VlbXMgbGlrZSB3ZSBh cmUgc3RpbGwgc3VzY2VwdGlibGUgdG8gdHJhbnNwb3J0IGRlbGF5L2ppdHRlciBhbmQgcmFjZSBj b25kaXRpb25zIGF0IHNvbWUgcG9pbnQgaW4gdGhlIG5ldHdvcmssIGV2ZW4gaWYgaXQncyBub3Qg dGhlIG5leHQtaG9wIG9mIHRoZSB0YXJnZXQgbm9kZS4gIEJ1dCBpZiB0aGF0J3MgYSBwcm9wZXJ0 eSBvZiBEZWxheURBTyBmcm9tIFJGQyA2NTUwLCBpdCBkb2Vzbid0IHJlYWxseSBtYWtlIHNlbnNl IHRvIHRyeSB0byBhZGRyZXNzIGl0IGluIHRoaXMgZG9jdW1lbnQgKGFuZCBpdCdzIGFsc28gcG9z c2libGUgSSBtaXN1bmRlcnN0YW5kIHRoZSBzaXR1YXRpb24pLg0KDQpbUkpdIERlbGF5REFPIGFu ZCBEZWxheURDTyBhcmUgbWVjaGFuaXNtcyB0byByZWR1Y2UgdGhlIGNvbnRyb2wgb3ZlcmhlYWQg aW4gdGhlDQpuZXR3b3JrLiBJZiBhbiBpbXBsZW1lbnRhdGlvbiBjaG9vc2VzIG5vdCB0byB1c2Ug aXQsIGl0IHdpbGwgc3RpbGwgd29yayBvaywNCmFsYmVpdCB3aXRoIG1vcmUgY29udHJvbCBvdmVy aGVhZC4gWWVzIHRoZSBEZWxheURDTyBpcyBtb2RlbGVkIHNpbWlsYXIgdG8NCkRlbGF5REFPIGFu ZCBpdCBpcyBleHBlY3RlZCB0aGF0IGEgbm9kZSBzaW1wbHkgd2FpdHMgZm9yIHRoZSB0aW1lciB0 byBleHBpcmUNCmJlZm9yZSBpdCBjb3VsZCBzdGFydCBzZW5kaW5nIHRoZSBjb3JyZXNwb25kaW5n IG1lc3NhZ2UgKERDTyBpcyB0aGlzIGNhc2UsIERBTw0KaW4gY2FzZSBvZiA2NTUwKS4gSSBhbSBu b3QgZnVsbHkgc3VyZSBpZiBJIGNvbXBsZXRlbHkgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuDQpi eSAic3VzY2VwdGliaWxpdHkgdG8gdHJhbnNwb3J0IGRlbGF5L2ppdHRlciIgYnV0IGkgdW5kZXJz dGFuZCB0aGF0IHRoZXJlIGNvdWxkDQpiZSByYWNlIGNvbmRpdGlvbnMuIElmIHRoZSByYWNlIGNv bmRpdGlvbnMgaGFwcGVuIHRoZSB3b3JzdCBjYXNlIHByb2JsZW0gd291bGQNCmJlIHNsaWdodGx5 IG1vcmUgY29udHJvbCBvdmVyaGVhZC4gUmFjZSBjb25kaXRpb24gd291bGQgbm90IHJlc3VsdCBp biBpbnZhbGlkDQpzdGF0ZXMgb24gYW55IG5vZGVzLg0K From nobody Sun Jun 30 17:59:22 2019 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 A98F91201DA; Sun, 30 Jun 2019 17:59:20 -0700 (PDT) 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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <156194276061.21928.10788638244127072171@ietfa.amsl.com> Date: Sun, 30 Jun 2019 17:59:20 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-efficient-npdao-13.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, 01 Jul 2019 00:59:21 -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 : Efficient Route Invalidation Authors : Rahul Arvind Jadhav Pascal Thubert Rabi Narayan Sahoo Zhen Cao Filename : draft-ietf-roll-efficient-npdao-13.txt Pages : 22 Date : 2019-06-30 Abstract: This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new proactive route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-efficient-npdao-13 https://datatracker.ietf.org/doc/html/draft-ietf-roll-efficient-npdao-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-efficient-npdao-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 30 18:03:52 2019 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 1D6C41201E3 for ; Sun, 30 Jun 2019 18:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v3puW9byJ1e for ; Sun, 30 Jun 2019 18:03:48 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CD31201DA for ; Sun, 30 Jun 2019 18:03:47 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 28275C6EE8CA8846E850 for ; Mon, 1 Jul 2019 02:03:45 +0100 (IST) Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 1 Jul 2019 02:03:44 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.50]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Mon, 1 Jul 2019 06:33:32 +0530 From: Rahul Arvind Jadhav To: "roll@ietf.org" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-efficient-npdao-13.txt Thread-Index: AQHVL6hAybqj6vT+DE2BHGfuxFAr9aa08UOw Date: Mon, 1 Jul 2019 01:03:31 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DF29D38@BLREML503-MBX.china.huawei.com> References: <156194276061.21928.10788638244127072171@ietfa.amsl.com> In-Reply-To: <156194276061.21928.10788638244127072171@ietfa.amsl.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Roll] FW: I-D Action: draft-ietf-roll-efficient-npdao-13.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, 01 Jul 2019 01:03:50 -0000 Hello All, The updates are primarily based on the review comments from IESG members. A big thanks to all the IESG members for the detailed review and helping sh= ape the document better. Regards, Rahul -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: 01 July 2019 08:59 To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-efficient-npdao-13.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF. Title : Efficient Route Invalidation Authors : Rahul Arvind Jadhav Pascal Thubert Rabi Narayan Sahoo Zhen Cao Filename : draft-ietf-roll-efficient-npdao-13.txt Pages : 22 Date : 2019-06-30 Abstract: This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new proactive route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-efficient-npdao-13 https://datatracker.ietf.org/doc/html/draft-ietf-roll-efficient-npdao-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-efficient-npdao-13 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll