From nobody Wed Sep 5 09:55:51 2018 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 E8EC31274D0 for ; Wed, 5 Sep 2018 09:55:48 -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 lECuEHgNY1-w for ; Wed, 5 Sep 2018 09:55:47 -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 61B8F12426A for ; Wed, 5 Sep 2018 09:55:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 13FAE20491 for ; Wed, 5 Sep 2018 13:14:20 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id DA05B11C8; Wed, 5 Sep 2018 12:55:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D72C5AE8 for ; Wed, 5 Sep 2018 12:55:45 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr 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: [Roll] on omitting RPI artifact in downward routes in non-storing mode 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 Sep 2018 16:55:49 -0000 --=-=-= Content-Type: text/plain Ines and I, in dealing with the review from Alvaro have clarified the text in section 5 to say: from: RPI should be present in every single RPL data packet. There is one to: RPI SHOULD be present in every single RPL data packet. There is one exception in non-storing mode: when a packet is going down from the root the RPI MAY be omitted. The rational is that in a downward non-storing mode, the entire route is written, so there can be no loops by construction, nor any confusion about which forwarding table to use (as the root has already made all routing decisions). However, there are still cases, such as in 6tisch, where the instanceID portion of the RPI header may still be needed to pick an appropriate priority or channel at each hop. So, we have a situation where there is one case where the RPI might not be present, and we have an exception to THAT exception. That seems like a lot of code complexity. Given compression of the RPI is defined now, maybe having this exception is DUMB... Since the receiver MUST deal with upward traffic that has the RPI, then it has to be able to process the header (compressed or not) anyway. I'd like to remove the exception (the "MAY be ommitted"), and just make the SHOULD a MUST. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluQCpEACgkQgItw+93Q 3WXkmggAp2lvpMG2br6tRE36tSXThs0FVmX5/QYniySNuy6vwMk+TWNQKsmgn0/a jP53XZY4oZpsfl/Qth0L1ezMtHj5IFoct4rmnxg+XurAWKuc7+9gfRztvOI/5ce0 qUz3uAZvn0xkBSpfcr2/YHXtlZVYHi2iPRwfK3grllte3kOcXk1OsCszHHnvWXjF XWdAqAYUeMo0pU1GpbDSQGCfCCxseaa51NjNKeCLm5FjW5XkjVFzajnJsLj4X/dL JX1tpN+mPhuZJmileWm9eOZgjznpnNCFQSmj29VS9E/Lvc+CRsWMUbNJNJq16cd4 uXt7j8pIa41+r0unjebxdEbvqtpHCw== =s87o -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 5 12:13:06 2018 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 51E721271FF for ; Wed, 5 Sep 2018 12:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bbqJANQL12q for ; Wed, 5 Sep 2018 12:13:02 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E71F1292F1 for ; Wed, 5 Sep 2018 12:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2908; q=dns/txt; s=iport; t=1536174782; x=1537384382; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JDykFJL2W3QGZRNgFiVTdWQNN/IbQyeXCeIdOvThDno=; b=Nyp2GmVoxMsOnFPX59AOdKG5ynZJ538mcnhIbejK+Usfb8y/KKLjv7ZM 8djOQ5Ou7Rv2P+XnX+QL2Mhh28C+1i5x2VguPyC6mSDLAFnuWBP+2bY6z 5GQ1pb4L5vVQtk4wu7VraPpKgTpErkGM0dK3OucmTgIICkP+sPS9ZjQuJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAgCbKZBb/5FdJa1aGwEBAQEDAQE?= =?us-ascii?q?BCQEBAYMkKmV/KINyiBKMMYINgz2ScoF6CxgLgVSCdQIXgzkhNBgBAgEBAgE?= =?us-ascii?q?BAm0cDIU4AQEBAgEBASERMwcQCwIBCBoCJgICAiULFRACBBODIQGBeQgPolW?= =?us-ascii?q?BLoRshRYFgQuJTReBQT+BEicfgh4ugxsBAYRiMYImAptcCQKPfBeBQIQ7iGe?= =?us-ascii?q?TTQIRFIEkHTiBVXAVOyoBgkGDNgEHh1eFPm+OAgEB?= X-IronPort-AV: E=Sophos;i="5.53,334,1531785600"; d="scan'208";a="167589451" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Sep 2018 19:13:01 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w85JD185004664 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Sep 2018 19:13:01 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 5 Sep 2018 14:13:00 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1367.000; Wed, 5 Sep 2018 14:13:00 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] on omitting RPI artifact in downward routes in non-storing mode Thread-Index: AQHURTlUiOWktaQdok+N26RzsDYla6TiDnnY Date: Wed, 5 Sep 2018 19:13:00 +0000 Message-ID: References: <23950.1536166545@localhost> In-Reply-To: <23950.1536166545@localhost> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Roll] on omitting RPI artifact in downward routes in non-storing mode 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 Sep 2018 19:13:04 -0000 SGVsbG8gTWljaGFlbCANCg0KVGhlIFJQSSBpcyBuZWVkZWQgYnkgNkxvUkggdG8gY29tcHJlc3Mg dGhlIHJvdXRpbmcgaGVhZGVyLiBJdCBjYXJyaWVzIHRoZSBpbnN0YW5jZSBJRCBmcm9tIHdoaWNo IHRoZSByb290IGl0IGRlZHVjdGVkIHNvIHdlIGNhbiBjb21wcmVzcyAgYWRkcmVzc2VzIHVzaW5n IGl0IGFzIHJlZmVyZW5jZS4gDQoNClNvIHBsZWFzZSBubywgZG8gbm90IGFsbG93IHRvIG9taXQg dGhlIFJQSSwgdW5sZXNzLCBtYXliZSwgeW91IGluZGljYXRlIHRoYXQgdGhlIGltcGxpY2l0IG1l YW5pbmcgaXMgaW5zdGFuY2UgMC4uLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQo+IExlIDUgc2Vw dC4gMjAxOCDDoCAxODo1NiwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4u Y2E+IGEgw6ljcml0IDoNCj4gDQo+IA0KPiBJbmVzIGFuZCBJLCBpbiBkZWFsaW5nIHdpdGggdGhl IHJldmlldyBmcm9tIEFsdmFybyBoYXZlIGNsYXJpZmllZCB0aGUgdGV4dA0KPiBpbiBzZWN0aW9u IDUgdG8gc2F5Og0KPiANCj4gZnJvbToNCj4gICBSUEkgc2hvdWxkIGJlIHByZXNlbnQgaW4gZXZl cnkgc2luZ2xlIFJQTCBkYXRhIHBhY2tldC4gIFRoZXJlIGlzIG9uZQ0KPiANCj4gdG86DQo+ICAg ICAgICAgICAgUlBJIFNIT1VMRCBiZSBwcmVzZW50IGluIGV2ZXJ5IHNpbmdsZSBSUEwgZGF0YSBw YWNrZXQuIFRoZXJlIGlzIG9uZQ0KPiAgICAgICAgICAgIGV4Y2VwdGlvbiBpbiBub24tc3Rvcmlu ZyBtb2RlOiB3aGVuIGEgcGFja2V0IGlzIGdvaW5nIGRvd24gZnJvbSB0aGUNCj4gICAgICAgICAg ICByb290IHRoZSBSUEkgTUFZIGJlIG9taXR0ZWQuDQo+IA0KPiAgICAgICAgICAgIFRoZSByYXRp b25hbCBpcyB0aGF0IGluIGEgZG93bndhcmQgbm9uLXN0b3JpbmcgbW9kZSwgdGhlIGVudGlyZQ0K PiAgICAgICAgICAgIHJvdXRlIGlzIHdyaXR0ZW4sIHNvIHRoZXJlIGNhbiBiZSBubyBsb29wcyBi eSBjb25zdHJ1Y3Rpb24sIG5vciBhbnkNCj4gICAgICAgICAgICBjb25mdXNpb24gYWJvdXQgd2hp Y2ggZm9yd2FyZGluZyB0YWJsZSB0byB1c2UgKGFzIHRoZSByb290IGhhcw0KPiAgICAgICAgICAg IGFscmVhZHkgbWFkZSBhbGwgcm91dGluZyBkZWNpc2lvbnMpLiAgSG93ZXZlciwgdGhlcmUgYXJl IHN0aWxsDQo+ICAgICAgICAgICAgY2FzZXMsIHN1Y2ggYXMgaW4gNnRpc2NoLCB3aGVyZSB0aGUg aW5zdGFuY2VJRCBwb3J0aW9uIG9mIHRoZSBSUEkNCj4gICAgICAgICAgICBoZWFkZXIgbWF5IHN0 aWxsIGJlIG5lZWRlZCB0byBwaWNrIGFuIGFwcHJvcHJpYXRlIHByaW9yaXR5IG9yDQo+ICAgICAg ICAgICAgY2hhbm5lbCBhdCBlYWNoIGhvcC4NCj4gDQo+IA0KPiBTbywgd2UgaGF2ZSBhIHNpdHVh dGlvbiB3aGVyZSB0aGVyZSBpcyBvbmUgY2FzZSB3aGVyZSB0aGUgUlBJIG1pZ2h0IG5vdCBiZQ0K PiBwcmVzZW50LCBhbmQgd2UgaGF2ZSBhbiBleGNlcHRpb24gdG8gVEhBVCBleGNlcHRpb24uICBU aGF0IHNlZW1zIGxpa2UgYSBsb3QNCj4gb2YgY29kZSBjb21wbGV4aXR5LiAgR2l2ZW4gY29tcHJl c3Npb24gb2YgdGhlIFJQSSBpcyBkZWZpbmVkIG5vdywgbWF5YmUNCj4gaGF2aW5nIHRoaXMgZXhj ZXB0aW9uIGlzIERVTUIuLi4NCj4gDQo+IFNpbmNlIHRoZSByZWNlaXZlciBNVVNUIGRlYWwgd2l0 aCB1cHdhcmQgdHJhZmZpYyB0aGF0IGhhcyB0aGUgUlBJLCB0aGVuIGl0DQo+IGhhcyB0byBiZSBh YmxlIHRvIHByb2Nlc3MgdGhlIGhlYWRlciAoY29tcHJlc3NlZCBvciBub3QpIGFueXdheS4NCj4g DQo+IEknZCBsaWtlIHRvIHJlbW92ZSB0aGUgZXhjZXB0aW9uICh0aGUgIk1BWSBiZSBvbW1pdHRl ZCIpLCBhbmQganVzdCBtYWtlDQo+IHRoZSBTSE9VTEQgYSBNVVNULg0KPiANCj4gLS0NCj4gTWlj aGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdh cmUgV29ya3MNCj4gLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KPiANCj4gDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxp bmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcm9sbA0K From nobody Wed Sep 5 22:02:18 2018 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 0237E12F1AB for ; Wed, 5 Sep 2018 22:02:17 -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 9Xz9jcRb1nUR for ; Wed, 5 Sep 2018 22:02:14 -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 598191274D0 for ; Wed, 5 Sep 2018 22:02:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E851420491 for ; Thu, 6 Sep 2018 01:20:47 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 13D7F11C9; Thu, 6 Sep 2018 01:02:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1023E4E7 for ; Thu, 6 Sep 2018 01:02:12 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <23950.1536166545@localhost> 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] on omitting RPI artifact in downward routes in non-storing mode 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 Sep 2018 05:02:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal Thubert \(pthubert\) wrote: > The RPI is needed by 6LoRH to compress the routing header. It carries > the instance ID from which the root it deducted so we can compress > addresses using it as reference. > So please no, do not allow to omit the RPI, unless, maybe, you indica= te > that the implicit meaning is instance 0... Good, you are agree with me that allowing the RPI to be ommited in this very very specific case is a code complexity we should avoid. >> Le 5 sept. 2018 =C3=A0 18:56, Michael Richardson a >> =C3=A9crit : >> >> >> Ines and I, in dealing with the review from Alvaro have clarified the >> text in section 5 to say: >> >> from: RPI should be present in every single RPL data packet. There = is >> one >> >> to: RPI SHOULD be present in every single RPL data packet. There is >> one exception in non-storing mode: when a packet is going down from >> the root the RPI MAY be omitted. >> >> The rational is that in a downward non-storing mode, the entire route >> is written, so there can be no loops by construction, nor any >> confusion about which forwarding table to use (as the root has alrea= dy >> made all routing decisions). However, there are still cases, such as >> in 6tisch, where the instanceID portion of the RPI header may still = be >> needed to pick an appropriate priority or channel at each hop. >> >> >> So, we have a situation where there is one case where the RPI might >> not be present, and we have an exception to THAT exception. That >> seems like a lot of code complexity. Given compression of the RPI is >> defined now, maybe having this exception is DUMB... >> >> Since the receiver MUST deal with upward traffic that has the RPI, >> then it has to be able to process the header (compressed or not) >> anyway. >> >> I'd like to remove the exception (the "MAY be ommitted"), and just >> make the SHOULD a MUST. >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> >> >> >> _______________________________________________ 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 =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluQtNMACgkQgItw+93Q 3WWufQgAl9SIiWkrPSce+0AiCllAy2nq667lTWOVvEjWPebmzhTqWeis6iRSRPER RXn+yjSDJOFvaaBBDC+3wpX5vm5wGzAbKeMyRrae4qVch11snhZDxGWSnE6mFVjR K/BGYRF1vE4/fntzg/93afNHawKyh+4//KcSXGS7FpGYjs8jciOS8S3fGb+7j+tF DGZ2civHI9uyyzXoMcXxufiHcWPpG72fi4XEFNsBDiQSUVjZAkld5y1sautsT4Zh FB7TtN2PRurPjh3v0/6y6ns9k2tbkJrk8JPAD3TIbnvGoJ2Vp8u32/zahsIIgezA WLnMKow1d+GVxjgCcNvPCSnfw7BUJw== =/eWg -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 5 22:30:59 2018 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 D5172129C6A for ; Wed, 5 Sep 2018 22:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_MED=-0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skA58AC4ezn9 for ; Wed, 5 Sep 2018 22:30:56 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A551286D9 for ; Wed, 5 Sep 2018 22:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4028; q=dns/txt; s=iport; t=1536211856; x=1537421456; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hTHpNshpAIL1OhpMO4vAq2Bz9FCU4oZx/hGjqz6j4aU=; b=Q9KoGEUVnfa3oFokHKHm9N16vp4NXZeLkzwImW5byeAinWQvkI26LdsU Ug891zFLE7w0GYDvCmIKUT0BEEwoKQbssbGvAGtcP8K47LAa8FQrqih0j MsPqTFHZitaVMMkMpUjzQBA5624ABWn/mA29UGVa8De1VDCnLyGzdvn24 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AwDCupBb/49dJa1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMkKmV/KINyllCDPZJygXoLGAuBVIJ1AheDOSE1FwECAQE?= =?us-ascii?q?CAQECbRwMhTcBAQEDAQEBIREzBxALAgEIGAICJgICAiULFRACBBODIQGBeQg?= =?us-ascii?q?PoXWBLoRshRUFgQuJTheBQT+BEicfgh4ugxsBAQKBPwEBgx8xgiYCh3qTZAk?= =?us-ascii?q?Cj3sXgUCEO4hnk04CERSBJB8BNYFVcBU7KgGCQYM2AQeHV4U+bwGLPoI8AQE?= X-IronPort-AV: E=Sophos;i="5.53,334,1531785600"; d="scan'208";a="445240438" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2018 05:30:54 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w865UsET026050 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Sep 2018 05:30:54 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 6 Sep 2018 00:30:54 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1367.000; Thu, 6 Sep 2018 00:30:54 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] on omitting RPI artifact in downward routes in non-storing mode Thread-Index: AQHURTlUiOWktaQdok+N26RzsDYla6TiDnnYgAD4cAD//7Q0Bw== Date: Thu, 6 Sep 2018 05:30:54 +0000 Message-ID: <8C45B058-24B8-4FFC-A91F-E570EF925A7F@cisco.com> References: <23950.1536166545@localhost> , <16741.1536210132@localhost> In-Reply-To: <16741.1536210132@localhost> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Roll] on omitting RPI artifact in downward routes in non-storing mode 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 Sep 2018 05:30:58 -0000 WWVzLCBNaWNoYWVsLg0KDQpJIHdhcyB1bmNsZWFyIHdoYXQgeW91ciBzdWdnZXN0aW9uIHdhcyBw YXJzaW5nIHlvdXIgbWFpbC4gUlBJIGlzIG5lZWRlZC4gV2UgY2FuIHJlZmVyIHRvIFJGQyA4MTM4 IHRvIHN1cHBvcnQgdGhhdCBhc3NlcnRpb24uDQoNClJlZ2FyZHMsDQoNClBhc2NhbA0KDQo+IExl IDYgc2VwdC4gMjAxOCDDoCAwNzowMiwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5k ZWxtYW4uY2E+IGEgw6ljcml0IDoNCj4gDQo+IA0KPiBQYXNjYWwgVGh1YmVydCBcKHB0aHViZXJ0 XCkgPHB0aHViZXJ0PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4+IFRoZSBS UEkgaXMgbmVlZGVkIGJ5IDZMb1JIIHRvIGNvbXByZXNzIHRoZSByb3V0aW5nIGhlYWRlci4gSXQg Y2Fycmllcw0KPj4gdGhlIGluc3RhbmNlIElEIGZyb20gd2hpY2ggdGhlIHJvb3QgaXQgZGVkdWN0 ZWQgc28gd2UgY2FuIGNvbXByZXNzDQo+PiBhZGRyZXNzZXMgdXNpbmcgaXQgYXMgcmVmZXJlbmNl Lg0KPiANCj4+IFNvIHBsZWFzZSBubywgZG8gbm90IGFsbG93IHRvIG9taXQgdGhlIFJQSSwgdW5s ZXNzLCBtYXliZSwgeW91IGluZGljYXRlDQo+PiB0aGF0IHRoZSBpbXBsaWNpdCBtZWFuaW5nIGlz IGluc3RhbmNlIDAuLi4NCj4gDQo+IEdvb2QsIHlvdSBhcmUgYWdyZWUgd2l0aCBtZSB0aGF0IGFs bG93aW5nIHRoZSBSUEkgdG8gYmUgb21taXRlZCBpbiB0aGlzDQo+IHZlcnkgdmVyeSBzcGVjaWZp YyBjYXNlIGlzIGEgY29kZSBjb21wbGV4aXR5IHdlIHNob3VsZCBhdm9pZC4NCj4gDQo+IA0KPj4+ IExlIDUgc2VwdC4gMjAxOCDDoCAxODo1NiwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBz YW5kZWxtYW4uLmNhPiBhDQo+Pj4gw6ljcml0IDoNCj4+PiANCj4+PiANCj4+PiBJbmVzIGFuZCBJ LCBpbiBkZWFsaW5nIHdpdGggdGhlIHJldmlldyBmcm9tIEFsdmFybyBoYXZlIGNsYXJpZmllZCB0 aGUNCj4+PiB0ZXh0IGluIHNlY3Rpb24gNSB0byBzYXk6DQo+Pj4gDQo+Pj4gZnJvbTogUlBJIHNo b3VsZCBiZSBwcmVzZW50IGluIGV2ZXJ5IHNpbmdsZSBSUEwgZGF0YSBwYWNrZXQuICBUaGVyZSBp cw0KPj4+IG9uZQ0KPj4+IA0KPj4+IHRvOiBSUEkgU0hPVUxEIGJlIHByZXNlbnQgaW4gZXZlcnkg c2luZ2xlIFJQTCBkYXRhIHBhY2tldC4gVGhlcmUgaXMNCj4+PiBvbmUgZXhjZXB0aW9uIGluIG5v bi1zdG9yaW5nIG1vZGU6IHdoZW4gYSBwYWNrZXQgaXMgZ29pbmcgZG93biBmcm9tDQo+Pj4gdGhl IHJvb3QgdGhlIFJQSSBNQVkgYmUgb21pdHRlZC4NCj4+PiANCj4+PiBUaGUgcmF0aW9uYWwgaXMg dGhhdCBpbiBhIGRvd253YXJkIG5vbi1zdG9yaW5nIG1vZGUsIHRoZSBlbnRpcmUgcm91dGUNCj4+ PiBpcyB3cml0dGVuLCBzbyB0aGVyZSBjYW4gYmUgbm8gbG9vcHMgYnkgY29uc3RydWN0aW9uLCBu b3IgYW55DQo+Pj4gY29uZnVzaW9uIGFib3V0IHdoaWNoIGZvcndhcmRpbmcgdGFibGUgdG8gdXNl IChhcyB0aGUgcm9vdCBoYXMgYWxyZWFkeQ0KPj4+IG1hZGUgYWxsIHJvdXRpbmcgZGVjaXNpb25z KS4gIEhvd2V2ZXIsIHRoZXJlIGFyZSBzdGlsbCBjYXNlcywgc3VjaCBhcw0KPj4+IGluIDZ0aXNj aCwgd2hlcmUgdGhlIGluc3RhbmNlSUQgcG9ydGlvbiBvZiB0aGUgUlBJIGhlYWRlciBtYXkgc3Rp bGwgYmUNCj4+PiBuZWVkZWQgdG8gcGljayBhbiBhcHByb3ByaWF0ZSBwcmlvcml0eSBvciBjaGFu bmVsIGF0IGVhY2ggaG9wLg0KPj4+IA0KPj4+IA0KPj4+IFNvLCB3ZSBoYXZlIGEgc2l0dWF0aW9u IHdoZXJlIHRoZXJlIGlzIG9uZSBjYXNlIHdoZXJlIHRoZSBSUEkgbWlnaHQNCj4+PiBub3QgYmUg cHJlc2VudCwgYW5kIHdlIGhhdmUgYW4gZXhjZXB0aW9uIHRvIFRIQVQgZXhjZXB0aW9uLiAgVGhh dA0KPj4+IHNlZW1zIGxpa2UgYSBsb3Qgb2YgY29kZSBjb21wbGV4aXR5LiAgR2l2ZW4gY29tcHJl c3Npb24gb2YgdGhlIFJQSSBpcw0KPj4+IGRlZmluZWQgbm93LCBtYXliZSBoYXZpbmcgdGhpcyBl eGNlcHRpb24gaXMgRFVNQi4uLg0KPj4+IA0KPj4+IFNpbmNlIHRoZSByZWNlaXZlciBNVVNUIGRl YWwgd2l0aCB1cHdhcmQgdHJhZmZpYyB0aGF0IGhhcyB0aGUgUlBJLA0KPj4+IHRoZW4gaXQgaGFz IHRvIGJlIGFibGUgdG8gcHJvY2VzcyB0aGUgaGVhZGVyIChjb21wcmVzc2VkIG9yIG5vdCkNCj4+ PiBhbnl3YXkuDQo+Pj4gDQo+Pj4gSSdkIGxpa2UgdG8gcmVtb3ZlIHRoZSBleGNlcHRpb24gKHRo ZSAiTUFZIGJlIG9tbWl0dGVkIiksIGFuZCBqdXN0DQo+Pj4gbWFrZSB0aGUgU0hPVUxEIGEgTVVT VC4NCj4+PiANCj4+PiAtLQ0KPj4+IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVs bWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQo+Pj4gLT0gSVB2NiBJb1QgY29uc3Vs dGluZyA9LQ0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIFJvbGwgbWFpbGluZyBsaXN0DQo+Pj4gUm9sbEBpZXRmLm9y ZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFJvbGwgbWFpbGluZyBsaXN0 DQo+PiBSb2xsQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbA0KPiANCj4gLS0NCj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4u Y2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4gLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9 LQ0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From nobody Thu Sep 6 06:10:45 2018 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 9A160130E1D; Thu, 6 Sep 2018 06:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JWCPPdyaH93M; Thu, 6 Sep 2018 06:10:33 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0036.hostedemail.com [216.40.44.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE46130E42; Thu, 6 Sep 2018 06:10:29 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id 61EC8100E86C1; Thu, 6 Sep 2018 13:10:28 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:41:72:152:355:379:582:800:962:967:968:973:983:988:989:1152:1189:1208:1221:1260:1263:1313:1314:1345:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1730:1776:1792:2194:2199:2525:2553:2561:2564:2682:2685:2693:2829:2859:2894:2898:2899:2902:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3355:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4118:4250:4321:4425:4659:5007:6119:6261:6298:6659:7903:8603:9010:9015:9025:9108:9177:9388:10004:10400:10450:10455:10848:10904:11232:11658:11914:12043:12109:12114:12295:12555:12679:12895:12986:13071:13138:13139:13161:13199:13229:13231:13439:13618:13846:14096:14180:14181:14721:19904:19999:21060:21080:21433:21451:21625:21691:21740, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SP X-HE-Tag: plant59_3e3004c4cb049 X-Filterd-Recvd-Size: 7693 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf06.hostedemail.com (Postfix) with ESMTPA; Thu, 6 Sep 2018 13:10:27 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_d67a234adc92cecd8f40dc2466f8d029" Date: Thu, 06 Sep 2018 15:10:26 +0200 From: Peter van der Stok To: draft-ietf-roll-efficient-npdao@ietf.org Cc: Roll Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: <65ac8a93279212d8757d1ecf24ac9e42@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.219.15] Archived-At: Subject: [Roll] draft-ietf-roll-efficient-npdao review 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 Sep 2018 13:10:41 -0000 --=_d67a234adc92cecd8f40dc2466f8d029 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi authors, Many thanks for this work and solving an open important problem. being the shepherd of this draft, I looked at the text to look for improvements to facilitate the reading by the IESG. I found the document difficult to read due to the use of multiple terms for the same concept. I would appreciate that the first 3 sections are improved, such that I can continue the review afterwards without me wondering about my choices in the interpretation of the text. For example: is a sub-node the same thing as a child in the node? and what is a dependent node? Some suggestions to improve the document are written below. Can you use, for example, the terms Switching-node (S-node) After-switching parent (A-parent) and Before-switching parent (B-parent); that will simplify the text and improve readability. Please use consistently throughout one DODAG terminology like parent, child, ancestor or another preferred terminology. What does "target" mean: an endpoint of a path, a field in a packet, or the S-node? I thought that there can be many common ancestors on two paths with same source and destination, and one of them is the first common ancestor. BTW is the first one important; The rest of the text does not seem to rely on it. In section 1.4; to which what subtree do you refer? In section 8.2.1 of RFC6550 it is mentioned that there can be a set of preferred parents. However, I have the impression that your assumption is the existence of a single preferred parent, Some explanatory text would help. Some textual suggestions: Every first introduction of an acronym must be introduced with the full name; for example: DAO must be written out both in the abstract as in the text for the first use; please look for all the first instances in the text. In section 1.1 it will help if the list of used terms of RFC6550 is added. Section 3; a reminder that this applies only to storing mode may help. 3.1 How can transmission be tolerant to a link failure when the link has disappeared completely or the node has been removed; some explanation is needed here. It would help if the assumptions are listed: like there is another path via .... In section 3.1, 3.2 and 3.3 it should not be necessary to repeat what is written in section 2.1, 2.2 and 2.3, just a reference to the corresponding section will do. Section 7 is rather short; I doubt that it will be accepted in this form. There have been earlier comments on the insufficiency of the security considerations in RPL documents, I hope I conveyed my problems sufficiently, and look forward to a new version to continue the review. All the best, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_d67a234adc92cecd8f40dc2466f8d029 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
Hi authors,

Many thanks for this work and solving an open i= mportant problem.

being the shepherd of this draft, I looked at = the text to look for improvements to facilitate the reading by the IESG.I found the document difficult to read due to the use of multiple terms = for the same concept.
I would appreciate that the first 3 sections are= improved, such that I can continue the review afterwards without me wonder= ing about my choices in the interpretation of the text.

For exam= ple: is a sub-node the same thing as a child in the node? and what is a dep= endent node?
Some suggestions to improve the document are written belo= w.

Can you use, for example, the terms Switching-node (S-node) A= fter-switching parent (A-parent) and Before-switching parent (B-parent); th= at will simplify the text and improve readability.
Please use consiste= ntly throughout one DODAG terminology like parent, child, ancestor or anoth= er preferred terminology.
What does "target" mean: an endpoint of a pa= th, a field in a packet, or the S-node?
I thought that there can be ma= ny common ancestors on two paths with same source and destination, and one = of them is the first common ancestor. BTW is the first one important; The r= est of the text does not seem to rely on it.

In section 1.4; to = which what subtree do you refer?

In section 8.2.1 of RFC6550 it = is mentioned that there can be a set of preferred parents.
However, I = have the impression that your assumption is the existence of a single prefe= rred parent, Some explanatory text would help.

Some textual sugg= estions:
Every first introduction of an acronym must be introduce= d with the full name; for example: DAO must be written out both in the abst= ract as in the text for the first use; please look for all the first instan= ces in the text.
In section 1.1 it will help if the list of used terms= of RFC6550 is added.

Section 3; a reminder that this applies on= ly to storing mode may help.

3.1 How can transmission be toleran= t to a link failure when the link has disappeared completely or the node ha= s been removed; some explanation is needed here. It would help if the assum= ptions are listed: like there is another path via ....

In sectio= n 3.1, 3.2 and 3.3 it should not be necessary to repeat what is written in = section 2.1, 2.2 and 2.3, just a reference to the corresponding section wil= l do.

Section 7 is rather short; I doubt that it will be accepte= d in this form.
There have been earlier comments on the insufficiency = of the security considerations in RPL documents,

I hope I convey= ed my problems sufficiently, and look forward to a new version to continue = the review.

All the best,

Peter

--
= Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok= =2Eorg, stokc= ons@bbhmail.nl
www: www.vanderstok.org
tel NL: +31(0)4= 92474673     F: +33(0)966015248
--=_d67a234adc92cecd8f40dc2466f8d029-- From nobody Thu Sep 6 09:07:28 2018 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 74FAC130EB1; Thu, 6 Sep 2018 09:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.798, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 yuRusKozj6jy; Thu, 6 Sep 2018 09:07:24 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 10C9E130DE4; Thu, 6 Sep 2018 09:07:24 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id m26-v6so9270191uap.2; Thu, 06 Sep 2018 09:07:23 -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 :cc; bh=SLxU3pbnaksYh8V1btqU2PuyTQlCdFQ/x9Rqt4Qi1jA=; b=rzP8DNaMhf4yIqhXwMVQL70uQlLmjCRszqWCRv3KfJ7v+EHblBzkUqQIm9p9byWZK0 +s2iJSL+zHWLVqhQX6QIzkOLTPmfhVHskBefmmnWfP6HdVsfiJA938L5brTl9A+kEeea mFnE4EdNly3uQF0hCcSlVWwwut69eIDPYCIEio4hXO3cl2gZvLydvIBHQ219DRo3w1m6 LycIKcNR7Cqu8lDcTsRj45YKjSSMT9HikP7aVwAZz25VZajQ3bVEII8KNRPP8qAHdlBT n2XkWclQPVowicfSdmw+oUwZpL1I1p+lcMI9f3EEcew1a5n6lTMmc9oAE8cIV0w+O1ZB mk2w== 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=SLxU3pbnaksYh8V1btqU2PuyTQlCdFQ/x9Rqt4Qi1jA=; b=cXqSsW8B1krP/LwgJwtwPogx/uITczkUnBdyIkwX7x6NRBOBTK1vmhiUp22pM9S2DM GBeyxDYqZCicwY9chjA8fhVele11Az3k7/cc7iTpP7w2KBBipBlXtT+Xbxqdi2fj8gCI GJZPdPG3hrYuJsTGBtlkz5FlN+KMEhVLyAnmknIKZDreINYSAMYjbqPXzsPMwmbsqJSw sszgSqpw1Hp3gfRcKOz50prdTO4Y7f4troWqeJ8QAfcIKo8u0GCxqAqo+gRjtszlce9/ S4vdBXx+cN/8BcEugu3vm62UfNKy+kDOfb4b28J8KUldkBMzLcjQm3uMSIqtigvCsDg9 RYyQ== X-Gm-Message-State: APzg51CDCSx2LNZULK+5zwxP4ViP7JKXVSm9qrPptx8eVJ0VMQ3BVSEx dksjO16m8JRZvR7/Hh9sPEYONgxb8uFpXNHYKFdlug== X-Google-Smtp-Source: ANB0VdbSFW6X5ly79IDPscvYiN8T91R/+TCiZwwNkbnjzFL/L+4YCg4z8RFHwic3zSdR8tNW1EQAE5f2rgvD8+pQVhE= X-Received: by 2002:ab0:80e:: with SMTP id a14-v6mr1198087uaf.114.1536250042789; Thu, 06 Sep 2018 09:07:22 -0700 (PDT) MIME-Version: 1.0 References: <65ac8a93279212d8757d1ecf24ac9e42@bbhmail.nl> In-Reply-To: <65ac8a93279212d8757d1ecf24ac9e42@bbhmail.nl> From: Rahul Jadhav Date: Thu, 6 Sep 2018 21:37:12 +0530 Message-ID: To: consultancy@vanderstok.org Cc: Roll , draft-ietf-roll-efficient-npdao@ietf.org Content-Type: multipart/alternative; boundary="0000000000001635220575361647" Archived-At: Subject: Re: [Roll] draft-ietf-roll-efficient-npdao review 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 Sep 2018 16:07:27 -0000 --0000000000001635220575361647 Content-Type: text/plain; charset="UTF-8" Many thanks Peter for the review. We will work on these comments and update the draft and provide detailed response soon. Thanks, Rahul On Thu, 6 Sep 2018 at 6:40 PM, Peter van der Stok wrote: > Hi authors, > > Many thanks for this work and solving an open important problem. > > being the shepherd of this draft, I looked at the text to look for > improvements to facilitate the reading by the IESG. > I found the document difficult to read due to the use of multiple terms > for the same concept. > I would appreciate that the first 3 sections are improved, such that I can > continue the review afterwards without me wondering about my choices in the > interpretation of the text. > > For example: is a sub-node the same thing as a child in the node? and what > is a dependent node? > Some suggestions to improve the document are written below. > > Can you use, for example, the terms Switching-node (S-node) > After-switching parent (A-parent) and Before-switching parent (B-parent); > that will simplify the text and improve readability. > Please use consistently throughout one DODAG terminology like parent, > child, ancestor or another preferred terminology. > What does "target" mean: an endpoint of a path, a field in a packet, or > the S-node? > I thought that there can be many common ancestors on two paths with same > source and destination, and one of them is the first common ancestor. BTW > is the first one important; The rest of the text does not seem to rely on > it. > > In section 1.4; to which what subtree do you refer? > > In section 8.2.1 of RFC6550 it is mentioned that there can be a set of > preferred parents. > However, I have the impression that your assumption is the existence of a > single preferred parent, Some explanatory text would help. > > Some textual suggestions: > Every first introduction of an acronym must be introduced with the full > name; for example: DAO must be written out both in the abstract as in the > text for the first use; please look for all the first instances in the text. > In section 1.1 it will help if the list of used terms of RFC6550 is added. > > Section 3; a reminder that this applies only to storing mode may help. > > 3.1 How can transmission be tolerant to a link failure when the link has > disappeared completely or the node has been removed; some explanation is > needed here. It would help if the assumptions are listed: like there is > another path via .... > > In section 3.1, 3.2 and 3.3 it should not be necessary to repeat what is > written in section 2.1, 2.2 and 2.3, just a reference to the corresponding > section will do. > > Section 7 is rather short; I doubt that it will be accepted in this form. > There have been earlier comments on the insufficiency of the security > considerations in RPL documents, > > I hope I conveyed my problems sufficiently, and look forward to a new > version to continue the review. > > All the best, > > Peter > > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > --0000000000001635220575361647 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Many thanks Peter for the review. We will work on th= ese comments and update the draft and provide detailed response soon.
=

Thanks,
Rahul

O= n Thu, 6 Sep 2018 at 6:40 PM, Peter van der Stok <stokcons@bbhmail.nl> wrote:
Hi authors,

Many thanks for this work and solving an open impor= tant problem.

being the shepherd of this draft, I looked at the text= to look for improvements to facilitate the reading by the IESG.
I found= the document difficult to read due to the use of multiple terms for the sa= me concept.
I would appreciate that the first 3 sections are improved, s= uch that I can continue the review afterwards without me wondering about my= choices in the interpretation of the text.

For example: is a sub-no= de the same thing as a child in the node? and what is a dependent node?
= Some suggestions to improve the document are written below.

Can you = use, for example, the terms Switching-node (S-node) After-switching parent = (A-parent) and Before-switching parent (B-parent); that will simplify the t= ext and improve readability.
Please use consistently throughout one DODA= G terminology like parent, child, ancestor or another preferred terminology= .
What does "target" mean: an endpoint of a path, a field in a= packet, or the S-node?
I thought that there can be many common ancestor= s on two paths with same source and destination, and one of them is the fir= st common ancestor. BTW is the first one important; The rest of the text do= es not seem to rely on it.

In section 1.4; to which what subtree do = you refer?

In section 8.2.1 of RFC6550 it is mentioned that there ca= n be a set of preferred parents.
However, I have the impression that you= r assumption is the existence of a single preferred parent, Some explanator= y text would help.

Some textual suggestions:
Every first introduc= tion of an acronym=C2=A0must be introduced with the full name; for example:= DAO must be written out both in the abstract as in the text for the first = use; please look for all the first instances in the text.
In section 1.1= it will help if the list of used terms of RFC6550 is added.

Section= 3; a reminder that this applies only to storing mode may help.

3.1 = How can transmission be tolerant to a link failure when the link has disapp= eared completely or the node has been removed; some explanation is needed h= ere. It would help if the assumptions are listed: like there is another pat= h via ....

In section 3.1, 3.2 and 3.3 it should not be necessary to= repeat what is written in section 2.1, 2.2 and 2.3, just a reference to th= e corresponding section will do.

Section 7 is rather short; I doubt = that it will be accepted in this form.
There have been earlier comments = on the insufficiency of the security considerations in RPL documents,
I hope I conveyed my problems sufficiently, and look forward to a new ver= sion to continue the review.

All the best,

Peter
<= div style=3D"font-size:10pt;font-family:Verdana,Geneva,sans-serif">

--
Peter van der Stok
vanderstok consultancy
mailto: = consultancy@vanderstok.org, stokcons@bbhmail.nl
www: <= a href=3D"http://www.vanderstok.org" rel=3D"noreferrer" target=3D"_blank">w= ww.vanderstok.org
tel NL: +31(0)492474673 =C2=A0=C2=A0=C2=A0=C2=A0F= : +33(0)966015248
--0000000000001635220575361647-- From nobody Sat Sep 8 04:16:06 2018 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 42DFE130DC8; Sat, 8 Sep 2018 04:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, T_DKIMWL_WL_HIGH=-0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtAY0suC-XLn; Sat, 8 Sep 2018 04:16:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957F2130DC4; Sat, 8 Sep 2018 04:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13118; q=dns/txt; s=iport; t=1536405361; x=1537614961; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/8i3yEbewLXU8PN7BAPpnreEyP+n1w1Ngpa60kJbtPI=; b=ANQvMgNdCxBT8l+9oWDxJV8VuGCliBbYwx0Xj+DKDS6q6+MUgPFFzlya HDe4Cq7CkDU3dVKK5IjiJhtXbBcJQnGLPzFVTvf+ynRuCR7/WvnoCWHvA gaph6NPR6RQjlcEN+4cnQ10kzCeNpsSs6L81cMUgNnl8BGaouXu/+rOb9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgCSrpNb/4YNJK1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJXd2V/KINylzqHYognhUeBZgsfhE0CF4NLITgUAQIBAQIBAQJ?= =?us-ascii?q?tHAyFOQYjJjAQAgEIPwMCAgIfERQRAgQOBYMhAYEdTAMVpQ2BLoNAg2YNgRm?= =?us-ascii?q?BNYplF4FBP4ESJx9RgUY1glaBcCAvJ4JDMYImAo0yE4VOiCcjKwkCiTODOoM?= =?us-ascii?q?TEQaBQIQ/gn6Fc4hJg1eHRgIRFIElNCGBVXAVOyoBgkEJiwyFPm+OMwEB?= X-IronPort-AV: E=Sophos;i="5.53,346,1531785600"; d="scan'208,217";a="449461821" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Sep 2018 11:16:00 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w88BG0Vd031706 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 8 Sep 2018 11:16:00 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 8 Sep 2018 06:15:59 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Sat, 8 Sep 2018 06:15:59 -0500 From: "Pascal Thubert (pthubert)" To: Rahul Jadhav CC: "consultancy@vanderstok.org" , Roll , "draft-ietf-roll-efficient-npdao@ietf.org" Thread-Topic: draft-ietf-roll-efficient-npdao review Thread-Index: AQHUReMGP6D/WZ/UdU+9SxTvphKiTKTjv2IAgALSGYA= Date: Sat, 8 Sep 2018 11:15:59 +0000 Message-ID: References: <65ac8a93279212d8757d1ecf24ac9e42@bbhmail.nl> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_E78532A5D8E54394921BC67527099615ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Roll] draft-ietf-roll-efficient-npdao review 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, 08 Sep 2018 11:16:04 -0000 --_000_E78532A5D8E54394921BC67527099615ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwNCg0KSSBtYWRlIG15IG93biByZXZpZXcgYW5kIGZpbmQgdGhlIGRvY3VtZW50IG1v c3RseSByZWFkeS4gSSBhZ3JlZSB0aGF0IFBldGVy4oCZcyBjb21tZW50cyBuZWVkIGhhbmRsaW5n IHRvIG1ha2UgdGhlIGJlc3QgdGV4dCBjbGVhbmVyLiBUaGUgaW50cm9kdWN0aW9uIGNvdWxkIGFs c28gYmUgdGlnaHRlbmVkIGFuZCB0aGUgRW5nbGlzaCBpbXByb3ZlZCBhIGJpdCwgYnV0IEkgZ3Vl c3MgdGhlIHJmYyBlZGl0b3Igd2lsbCBoZWxwIHVzIHRoZXJlLg0KDQpBIHdvcmQgb24gREFPIHZz LiBOUERBTyB3aXRoIGEgc2FtZSBzZXF1ZW5jZSB3b3VsZCBjbGFyaWZ5IHRoYXQgdGhlIERBTyBp cyB2YWxpZCBhbmQgdGhlIHJvdXRlIGluc3RhbGxlZCBvciBrZXB0IGRlcGVuZGluZyBvbiB0aGUg b3JkZXIgb2YgdGhlIDIgbWVzc2FnZXMuIEEgREFPIHJlY2VpdmVkIGFmdGVyIGEgTlBEQU8gYnV0 IHdpdGggYW4gb2xkZXIgc2VxdWVuY2UgaXMgaWdub3JlZC4gVGhpcyBpcyBjbGFzc2ljYWwgUlBM LCBidXQgbWVudGlvbmluZyBpdCBjb3VsZCBzdGlsbCBiZSB1c2VmdWwuDQoNCk9uZSBsYXN0IHRo aW5nIGNvdWxkIGJlIGEgYml0IG1vcmUgZGV0YWlscyBvbiB3aGVuIHRvIHBsYWNlIG9wdGlvbnMg YW5kIHdoeS4NCg0KT3RoZXJ3aXNlIGFsbCBnb29kIGZvciBtZSENCg0KUGFzY2FsDQoNCkxlIDYg c2VwdC4gMjAxOCDDoCAxODowNywgUmFodWwgSmFkaGF2IDxyYWh1bC5pZXRmQGdtYWlsLmNvbTxt YWlsdG86cmFodWwuaWV0ZkBnbWFpbC5jb20+PiBhIMOpY3JpdCA6DQoNCk1hbnkgdGhhbmtzIFBl dGVyIGZvciB0aGUgcmV2aWV3LiBXZSB3aWxsIHdvcmsgb24gdGhlc2UgY29tbWVudHMgYW5kIHVw ZGF0ZSB0aGUgZHJhZnQgYW5kIHByb3ZpZGUgZGV0YWlsZWQgcmVzcG9uc2Ugc29vbi4NCg0KVGhh bmtzLA0KUmFodWwNCg0KT24gVGh1LCA2IFNlcCAyMDE4IGF0IDY6NDAgUE0sIFBldGVyIHZhbiBk ZXIgU3RvayA8c3Rva2NvbnNAYmJobWFpbC5ubDxtYWlsdG86c3Rva2NvbnNAYmJobWFpbC5ubD4+ IHdyb3RlOg0KSGkgYXV0aG9ycywNCg0KTWFueSB0aGFua3MgZm9yIHRoaXMgd29yayBhbmQgc29s dmluZyBhbiBvcGVuIGltcG9ydGFudCBwcm9ibGVtLg0KDQpiZWluZyB0aGUgc2hlcGhlcmQgb2Yg dGhpcyBkcmFmdCwgSSBsb29rZWQgYXQgdGhlIHRleHQgdG8gbG9vayBmb3IgaW1wcm92ZW1lbnRz IHRvIGZhY2lsaXRhdGUgdGhlIHJlYWRpbmcgYnkgdGhlIElFU0cuDQpJIGZvdW5kIHRoZSBkb2N1 bWVudCBkaWZmaWN1bHQgdG8gcmVhZCBkdWUgdG8gdGhlIHVzZSBvZiBtdWx0aXBsZSB0ZXJtcyBm b3IgdGhlIHNhbWUgY29uY2VwdC4NCkkgd291bGQgYXBwcmVjaWF0ZSB0aGF0IHRoZSBmaXJzdCAz IHNlY3Rpb25zIGFyZSBpbXByb3ZlZCwgc3VjaCB0aGF0IEkgY2FuIGNvbnRpbnVlIHRoZSByZXZp ZXcgYWZ0ZXJ3YXJkcyB3aXRob3V0IG1lIHdvbmRlcmluZyBhYm91dCBteSBjaG9pY2VzIGluIHRo ZSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgdGV4dC4NCg0KRm9yIGV4YW1wbGU6IGlzIGEgc3ViLW5v ZGUgdGhlIHNhbWUgdGhpbmcgYXMgYSBjaGlsZCBpbiB0aGUgbm9kZT8gYW5kIHdoYXQgaXMgYSBk ZXBlbmRlbnQgbm9kZT8NClNvbWUgc3VnZ2VzdGlvbnMgdG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQg YXJlIHdyaXR0ZW4gYmVsb3cuDQoNCkNhbiB5b3UgdXNlLCBmb3IgZXhhbXBsZSwgdGhlIHRlcm1z IFN3aXRjaGluZy1ub2RlIChTLW5vZGUpIEFmdGVyLXN3aXRjaGluZyBwYXJlbnQgKEEtcGFyZW50 KSBhbmQgQmVmb3JlLXN3aXRjaGluZyBwYXJlbnQgKEItcGFyZW50KTsgdGhhdCB3aWxsIHNpbXBs aWZ5IHRoZSB0ZXh0IGFuZCBpbXByb3ZlIHJlYWRhYmlsaXR5Lg0KUGxlYXNlIHVzZSBjb25zaXN0 ZW50bHkgdGhyb3VnaG91dCBvbmUgRE9EQUcgdGVybWlub2xvZ3kgbGlrZSBwYXJlbnQsIGNoaWxk LCBhbmNlc3RvciBvciBhbm90aGVyIHByZWZlcnJlZCB0ZXJtaW5vbG9neS4NCldoYXQgZG9lcyAi dGFyZ2V0IiBtZWFuOiBhbiBlbmRwb2ludCBvZiBhIHBhdGgsIGEgZmllbGQgaW4gYSBwYWNrZXQs IG9yIHRoZSBTLW5vZGU/DQpJIHRob3VnaHQgdGhhdCB0aGVyZSBjYW4gYmUgbWFueSBjb21tb24g YW5jZXN0b3JzIG9uIHR3byBwYXRocyB3aXRoIHNhbWUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiwg YW5kIG9uZSBvZiB0aGVtIGlzIHRoZSBmaXJzdCBjb21tb24gYW5jZXN0b3IuIEJUVyBpcyB0aGUg Zmlyc3Qgb25lIGltcG9ydGFudDsgVGhlIHJlc3Qgb2YgdGhlIHRleHQgZG9lcyBub3Qgc2VlbSB0 byByZWx5IG9uIGl0Lg0KDQpJbiBzZWN0aW9uIDEuNDsgdG8gd2hpY2ggd2hhdCBzdWJ0cmVlIGRv IHlvdSByZWZlcj8NCg0KSW4gc2VjdGlvbiA4LjIuMSBvZiBSRkM2NTUwIGl0IGlzIG1lbnRpb25l ZCB0aGF0IHRoZXJlIGNhbiBiZSBhIHNldCBvZiBwcmVmZXJyZWQgcGFyZW50cy4NCkhvd2V2ZXIs IEkgaGF2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IHlvdXIgYXNzdW1wdGlvbiBpcyB0aGUgZXhpc3Rl bmNlIG9mIGEgc2luZ2xlIHByZWZlcnJlZCBwYXJlbnQsIFNvbWUgZXhwbGFuYXRvcnkgdGV4dCB3 b3VsZCBoZWxwLg0KDQpTb21lIHRleHR1YWwgc3VnZ2VzdGlvbnM6DQpFdmVyeSBmaXJzdCBpbnRy b2R1Y3Rpb24gb2YgYW4gYWNyb255bSBtdXN0IGJlIGludHJvZHVjZWQgd2l0aCB0aGUgZnVsbCBu YW1lOyBmb3IgZXhhbXBsZTogREFPIG11c3QgYmUgd3JpdHRlbiBvdXQgYm90aCBpbiB0aGUgYWJz dHJhY3QgYXMgaW4gdGhlIHRleHQgZm9yIHRoZSBmaXJzdCB1c2U7IHBsZWFzZSBsb29rIGZvciBh bGwgdGhlIGZpcnN0IGluc3RhbmNlcyBpbiB0aGUgdGV4dC4NCkluIHNlY3Rpb24gMS4xIGl0IHdp bGwgaGVscCBpZiB0aGUgbGlzdCBvZiB1c2VkIHRlcm1zIG9mIFJGQzY1NTAgaXMgYWRkZWQuDQoN ClNlY3Rpb24gMzsgYSByZW1pbmRlciB0aGF0IHRoaXMgYXBwbGllcyBvbmx5IHRvIHN0b3Jpbmcg bW9kZSBtYXkgaGVscC4NCg0KMy4xIEhvdyBjYW4gdHJhbnNtaXNzaW9uIGJlIHRvbGVyYW50IHRv IGEgbGluayBmYWlsdXJlIHdoZW4gdGhlIGxpbmsgaGFzIGRpc2FwcGVhcmVkIGNvbXBsZXRlbHkg b3IgdGhlIG5vZGUgaGFzIGJlZW4gcmVtb3ZlZDsgc29tZSBleHBsYW5hdGlvbiBpcyBuZWVkZWQg aGVyZS4gSXQgd291bGQgaGVscCBpZiB0aGUgYXNzdW1wdGlvbnMgYXJlIGxpc3RlZDogbGlrZSB0 aGVyZSBpcyBhbm90aGVyIHBhdGggdmlhIC4uLi4NCg0KSW4gc2VjdGlvbiAzLjEsIDMuMiBhbmQg My4zIGl0IHNob3VsZCBub3QgYmUgbmVjZXNzYXJ5IHRvIHJlcGVhdCB3aGF0IGlzIHdyaXR0ZW4g aW4gc2VjdGlvbiAyLjEsIDIuMiBhbmQgMi4zLCBqdXN0IGEgcmVmZXJlbmNlIHRvIHRoZSBjb3Jy ZXNwb25kaW5nIHNlY3Rpb24gd2lsbCBkby4NCg0KU2VjdGlvbiA3IGlzIHJhdGhlciBzaG9ydDsg SSBkb3VidCB0aGF0IGl0IHdpbGwgYmUgYWNjZXB0ZWQgaW4gdGhpcyBmb3JtLg0KVGhlcmUgaGF2 ZSBiZWVuIGVhcmxpZXIgY29tbWVudHMgb24gdGhlIGluc3VmZmljaWVuY3kgb2YgdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGluIFJQTCBkb2N1bWVudHMsDQoNCkkgaG9wZSBJIGNvbnZleWVk IG15IHByb2JsZW1zIHN1ZmZpY2llbnRseSwgYW5kIGxvb2sgZm9yd2FyZCB0byBhIG5ldyB2ZXJz aW9uIHRvIGNvbnRpbnVlIHRoZSByZXZpZXcuDQoNCkFsbCB0aGUgYmVzdCwNCg0KUGV0ZXINCg0K DQotLQ0KUGV0ZXIgdmFuIGRlciBTdG9rDQp2YW5kZXJzdG9rIGNvbnN1bHRhbmN5DQptYWlsdG86 IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPG1haWx0bzpjb25zdWx0YW5jeUB2YW5kZXJzdG9r Lm9yZz4sIHN0b2tjb25zQGJiaG1haWwubmw8bWFpbHRvOnN0b2tjb25zQGJiaG1haWwubmw+DQp3 d3c6IHd3dy52YW5kZXJzdG9rLm9yZzxodHRwOi8vd3d3LnZhbmRlcnN0b2sub3JnPg0KdGVsIE5M OiArMzEoMCk0OTI0NzQ2NzMgICAgIEY6ICszMygwKTk2NjAxNTI0OA0K --_000_E78532A5D8E54394921BC67527099615ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5EC49D36CFD51D439C69D9A3A5189A6D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpE ZWFyIGFsbA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBtYWRlIG15IG93biByZXZpZXcgYW5k IGZpbmQgdGhlIGRvY3VtZW50IG1vc3RseSByZWFkeS4gSSBhZ3JlZSB0aGF0IFBldGVy4oCZcyBj b21tZW50cyBuZWVkIGhhbmRsaW5nIHRvIG1ha2UgdGhlIGJlc3QgdGV4dCBjbGVhbmVyLiBUaGUg aW50cm9kdWN0aW9uIGNvdWxkIGFsc28gYmUgdGlnaHRlbmVkIGFuZCB0aGUgRW5nbGlzaCBpbXBy b3ZlZCBhIGJpdCwgYnV0IEkgZ3Vlc3MgdGhlIHJmYyBlZGl0b3Igd2lsbCBoZWxwIHVzIHRoZXJl LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QSB3b3JkIG9uIERBTyB2cy4gTlBEQU8g d2l0aCBhIHNhbWUgc2VxdWVuY2Ugd291bGQgY2xhcmlmeSB0aGF0IHRoZSBEQU8gaXMgdmFsaWQg YW5kIHRoZSByb3V0ZSBpbnN0YWxsZWQgb3Iga2VwdCBkZXBlbmRpbmcgb24gdGhlIG9yZGVyIG9m IHRoZSAyIG1lc3NhZ2VzLiBBIERBTyByZWNlaXZlZCBhZnRlciBhIE5QREFPIGJ1dCB3aXRoIGFu IG9sZGVyIHNlcXVlbmNlIGlzIGlnbm9yZWQuIFRoaXMgaXMgY2xhc3NpY2FsIFJQTCwgYnV0IG1l bnRpb25pbmcNCiBpdCBjb3VsZCBzdGlsbCBiZSB1c2VmdWwuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5PbmUgbGFzdCB0aGluZyBjb3VsZCBiZSBhIGJpdCBtb3JlIGRldGFpbHMgb24g d2hlbiB0byBwbGFjZSBvcHRpb25zIGFuZCB3aHkuPC9kaXY+DQo8ZGl2Pjxicj4NCjxkaXY+DQo8 ZGl2Pk90aGVyd2lzZSBhbGwgZ29vZCBmb3IgbWUhPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5QYXNjYWw8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQpMZSA2IHNlcHQuIDIwMTggw6Ag MTg6MDcsIFJhaHVsIEphZGhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhaHVsLmlldGZAZ21haWwu Y29tIj5yYWh1bC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IGEgw6ljcml0Jm5ic3A7Ojxicj4NCjxi cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYg ZGlyPSJhdXRvIj5NYW55IHRoYW5rcyBQZXRlciBmb3IgdGhlIHJldmlldy4gV2Ugd2lsbCB3b3Jr IG9uIHRoZXNlIGNvbW1lbnRzIGFuZCB1cGRhdGUgdGhlIGRyYWZ0IGFuZCBwcm92aWRlIGRldGFp bGVkIHJlc3BvbnNlIHNvb24uPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8 L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+UmFo dWw8L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9 Imx0ciI+T24gVGh1LCA2IFNlcCAyMDE4IGF0IDY6NDAgUE0sIFBldGVyIHZhbiBkZXIgU3RvayAm bHQ7PGEgaHJlZj0ibWFpbHRvOnN0b2tjb25zQGJiaG1haWwubmwiPnN0b2tjb25zQGJiaG1haWwu bmw8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1p bHk6VmVyZGFuYSxHZW5ldmEsc2Fucy1zZXJpZiI+DQo8ZGl2PkhpIGF1dGhvcnMsPGJyPg0KPGJy Pg0KTWFueSB0aGFua3MgZm9yIHRoaXMgd29yayBhbmQgc29sdmluZyBhbiBvcGVuIGltcG9ydGFu dCBwcm9ibGVtLjxicj4NCjxicj4NCmJlaW5nIHRoZSBzaGVwaGVyZCBvZiB0aGlzIGRyYWZ0LCBJ IGxvb2tlZCBhdCB0aGUgdGV4dCB0byBsb29rIGZvciBpbXByb3ZlbWVudHMgdG8gZmFjaWxpdGF0 ZSB0aGUgcmVhZGluZyBieSB0aGUgSUVTRy48YnI+DQpJIGZvdW5kIHRoZSBkb2N1bWVudCBkaWZm aWN1bHQgdG8gcmVhZCBkdWUgdG8gdGhlIHVzZSBvZiBtdWx0aXBsZSB0ZXJtcyBmb3IgdGhlIHNh bWUgY29uY2VwdC48YnI+DQpJIHdvdWxkIGFwcHJlY2lhdGUgdGhhdCB0aGUgZmlyc3QgMyBzZWN0 aW9ucyBhcmUgaW1wcm92ZWQsIHN1Y2ggdGhhdCBJIGNhbiBjb250aW51ZSB0aGUgcmV2aWV3IGFm dGVyd2FyZHMgd2l0aG91dCBtZSB3b25kZXJpbmcgYWJvdXQgbXkgY2hvaWNlcyBpbiB0aGUgaW50 ZXJwcmV0YXRpb24gb2YgdGhlIHRleHQuPGJyPg0KPGJyPg0KRm9yIGV4YW1wbGU6IGlzIGEgc3Vi LW5vZGUgdGhlIHNhbWUgdGhpbmcgYXMgYSBjaGlsZCBpbiB0aGUgbm9kZT8gYW5kIHdoYXQgaXMg YSBkZXBlbmRlbnQgbm9kZT88YnI+DQpTb21lIHN1Z2dlc3Rpb25zIHRvIGltcHJvdmUgdGhlIGRv Y3VtZW50IGFyZSB3cml0dGVuIGJlbG93Ljxicj4NCjxicj4NCkNhbiB5b3UgdXNlLCBmb3IgZXhh bXBsZSwgdGhlIHRlcm1zIFN3aXRjaGluZy1ub2RlIChTLW5vZGUpIEFmdGVyLXN3aXRjaGluZyBw YXJlbnQgKEEtcGFyZW50KSBhbmQgQmVmb3JlLXN3aXRjaGluZyBwYXJlbnQgKEItcGFyZW50KTsg dGhhdCB3aWxsIHNpbXBsaWZ5IHRoZSB0ZXh0IGFuZCBpbXByb3ZlIHJlYWRhYmlsaXR5Ljxicj4N ClBsZWFzZSB1c2UgY29uc2lzdGVudGx5IHRocm91Z2hvdXQgb25lIERPREFHIHRlcm1pbm9sb2d5 IGxpa2UgcGFyZW50LCBjaGlsZCwgYW5jZXN0b3Igb3IgYW5vdGhlciBwcmVmZXJyZWQgdGVybWlu b2xvZ3kuPGJyPg0KV2hhdCBkb2VzICZxdW90O3RhcmdldCZxdW90OyBtZWFuOiBhbiBlbmRwb2lu dCBvZiBhIHBhdGgsIGEgZmllbGQgaW4gYSBwYWNrZXQsIG9yIHRoZSBTLW5vZGU/PGJyPg0KSSB0 aG91Z2h0IHRoYXQgdGhlcmUgY2FuIGJlIG1hbnkgY29tbW9uIGFuY2VzdG9ycyBvbiB0d28gcGF0 aHMgd2l0aCBzYW1lIHNvdXJjZSBhbmQgZGVzdGluYXRpb24sIGFuZCBvbmUgb2YgdGhlbSBpcyB0 aGUgZmlyc3QgY29tbW9uIGFuY2VzdG9yLiBCVFcgaXMgdGhlIGZpcnN0IG9uZSBpbXBvcnRhbnQ7 IFRoZSByZXN0IG9mIHRoZSB0ZXh0IGRvZXMgbm90IHNlZW0gdG8gcmVseSBvbiBpdC48YnI+DQo8 YnI+DQpJbiBzZWN0aW9uIDEuNDsgdG8gd2hpY2ggd2hhdCBzdWJ0cmVlIGRvIHlvdSByZWZlcj88 YnI+DQo8YnI+DQpJbiBzZWN0aW9uIDguMi4xIG9mIFJGQzY1NTAgaXQgaXMgbWVudGlvbmVkIHRo YXQgdGhlcmUgY2FuIGJlIGEgc2V0IG9mIHByZWZlcnJlZCBwYXJlbnRzLjxicj4NCkhvd2V2ZXIs IEkgaGF2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IHlvdXIgYXNzdW1wdGlvbiBpcyB0aGUgZXhpc3Rl bmNlIG9mIGEgc2luZ2xlIHByZWZlcnJlZCBwYXJlbnQsIFNvbWUgZXhwbGFuYXRvcnkgdGV4dCB3 b3VsZCBoZWxwLjxicj4NCjxicj4NClNvbWUgdGV4dHVhbCBzdWdnZXN0aW9uczo8YnI+DQpFdmVy eSBmaXJzdCBpbnRyb2R1Y3Rpb24gb2YgYW4gYWNyb255bSZuYnNwO211c3QgYmUgaW50cm9kdWNl ZCB3aXRoIHRoZSBmdWxsIG5hbWU7IGZvciBleGFtcGxlOiBEQU8gbXVzdCBiZSB3cml0dGVuIG91 dCBib3RoIGluIHRoZSBhYnN0cmFjdCBhcyBpbiB0aGUgdGV4dCBmb3IgdGhlIGZpcnN0IHVzZTsg cGxlYXNlIGxvb2sgZm9yIGFsbCB0aGUgZmlyc3QgaW5zdGFuY2VzIGluIHRoZSB0ZXh0Ljxicj4N CkluIHNlY3Rpb24gMS4xIGl0IHdpbGwgaGVscCBpZiB0aGUgbGlzdCBvZiB1c2VkIHRlcm1zIG9m IFJGQzY1NTAgaXMgYWRkZWQuPGJyPg0KPGJyPg0KU2VjdGlvbiAzOyBhIHJlbWluZGVyIHRoYXQg dGhpcyBhcHBsaWVzIG9ubHkgdG8gc3RvcmluZyBtb2RlIG1heSBoZWxwLjxicj4NCjxicj4NCjMu MSBIb3cgY2FuIHRyYW5zbWlzc2lvbiBiZSB0b2xlcmFudCB0byBhIGxpbmsgZmFpbHVyZSB3aGVu IHRoZSBsaW5rIGhhcyBkaXNhcHBlYXJlZCBjb21wbGV0ZWx5IG9yIHRoZSBub2RlIGhhcyBiZWVu IHJlbW92ZWQ7IHNvbWUgZXhwbGFuYXRpb24gaXMgbmVlZGVkIGhlcmUuIEl0IHdvdWxkIGhlbHAg aWYgdGhlIGFzc3VtcHRpb25zIGFyZSBsaXN0ZWQ6IGxpa2UgdGhlcmUgaXMgYW5vdGhlciBwYXRo IHZpYSAuLi4uPGJyPg0KPGJyPg0KSW4gc2VjdGlvbiAzLjEsIDMuMiBhbmQgMy4zIGl0IHNob3Vs ZCBub3QgYmUgbmVjZXNzYXJ5IHRvIHJlcGVhdCB3aGF0IGlzIHdyaXR0ZW4gaW4gc2VjdGlvbiAy LjEsIDIuMiBhbmQgMi4zLCBqdXN0IGEgcmVmZXJlbmNlIHRvIHRoZSBjb3JyZXNwb25kaW5nIHNl Y3Rpb24gd2lsbCBkby48YnI+DQo8YnI+DQpTZWN0aW9uIDcgaXMgcmF0aGVyIHNob3J0OyBJIGRv dWJ0IHRoYXQgaXQgd2lsbCBiZSBhY2NlcHRlZCBpbiB0aGlzIGZvcm0uPGJyPg0KVGhlcmUgaGF2 ZSBiZWVuIGVhcmxpZXIgY29tbWVudHMgb24gdGhlIGluc3VmZmljaWVuY3kgb2YgdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGluIFJQTCBkb2N1bWVudHMsPGJyPg0KPGJyPg0KSSBob3BlIEkg Y29udmV5ZWQgbXkgcHJvYmxlbXMgc3VmZmljaWVudGx5LCBhbmQgbG9vayBmb3J3YXJkIHRvIGEg bmV3IHZlcnNpb24gdG8gY29udGludWUgdGhlIHJldmlldy48YnI+DQo8YnI+DQpBbGwgdGhlIGJl c3QsPGJyPg0KPGJyPg0KUGV0ZXI8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXpl OjEwcHQ7Zm9udC1mYW1pbHk6VmVyZGFuYSxHZW5ldmEsc2Fucy1zZXJpZiI+DQo8ZGl2Pjxicj4N Cjxicj4NCi0tIDxicj4NCjxkaXYgY2xhc3M9Im1fLTIxNzk4MDM1OTg0MzEyOTUxNDlwcmUiIHN0 eWxlPSJtYXJnaW46MDtwYWRkaW5nOjA7Zm9udC1mYW1pbHk6bW9ub3NwYWNlIj4NClBldGVyIHZh biBkZXIgU3Rvazxicj4NCnZhbmRlcnN0b2sgY29uc3VsdGFuY3k8YnI+DQptYWlsdG86IDxhIGhy ZWY9Im1haWx0bzpjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZyIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+DQpjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzwvYT4sIDxhIGhyZWY9 Im1haWx0bzpzdG9rY29uc0BiYmhtYWlsLm5sIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2Js YW5rIj4NCnN0b2tjb25zQGJiaG1haWwubmw8L2E+PGJyPg0Kd3d3OiA8YSBocmVmPSJodHRwOi8v d3d3LnZhbmRlcnN0b2sub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj53d3cu dmFuZGVyc3Rvay5vcmc8L2E+PGJyPg0KdGVsIE5MOiAmIzQzOzMxKDApNDkyNDc0NjczICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO0Y6ICYjNDM7MzMoMCk5NjYwMTUyNDg8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E78532A5D8E54394921BC67527099615ciscocom_-- From nobody Tue Sep 11 02:19:36 2018 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 5E0761310EB; Tue, 11 Sep 2018 02:19:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: roll-chairs@ietf.org, roll@ietf.org, mariainesrobles@googlemail.com, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153665756629.16975.17251769337864704766.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 02:19:26 -0700 Archived-At: Subject: [Roll] roll - New Meeting Session Request for IETF 103 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 09:19:35 -0000 A new meeting session request has just been submitted by Ines Robles, a Chair of the roll working group. --------------------------------------------------------- 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 Thursday evening, it would be nice please if we could have the meeting before Friday or before Thursday afternoon. Meetecho Support --------------------------------------------------------- From nobody Wed Sep 12 09:12:39 2018 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 75070130E7F for ; Wed, 12 Sep 2018 09:12:37 -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 x-ChuIyzA5ic for ; Wed, 12 Sep 2018 09:12:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715F9130E7B for ; Wed, 12 Sep 2018 09:12:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68BE820491 for ; Wed, 12 Sep 2018 12:31:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 790ED230; Wed, 12 Sep 2018 12:12:34 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7400412F for ; Wed, 12 Sep 2018 12:12:34 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr 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 Date: Wed, 12 Sep 2018 12:12:34 -0400 Message-ID: <20351.1536768754@localhost> Archived-At: Subject: [Roll] diagrams from IETF102 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 16:12:38 -0000 We get lots of really nice diagrams in the slides. Just visually appealing... They are usually images, and they are in PDF, and it's hard to pull them out. If you have done any diagrams/images/visuals that relate to ROLL, I'd like to create a collage of such images to use as a background image for ... well stuff... slides, video conferences. (Not going to profit from this... It'd be CC https://creativecommons.org/licenses/by/4.0/ ) Please unicast them to me, I'll make a collection, stick it into github, and make a collage or two from them. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sun Sep 23 13:38:44 2018 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 42188130E5E; Sun, 23 Sep 2018 13:38:35 -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 diqfq3Ys2Cwy; Sun, 23 Sep 2018 13:38:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7230130E5D; Sun, 23 Sep 2018 13:38:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8B35720491; Sun, 23 Sep 2018 16:38:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8776416FB; Sun, 23 Sep 2018 16:38:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 84488A9; Sun, 23 Sep 2018 16:38:32 -0400 (EDT) From: Michael Richardson To: "Georgios Z. Papadopoulos" cc: "Pascal Thubert \(pthubert\)" , tisch <6tisch@ietf.org>, roll@ietf.org In-Reply-To: References: <153213124330.11513.14157137359028132358@ietfa.amsl.com> 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] [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2018 20:38:35 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Georgios Z. Papadopoulos wrote: > Many thanks for this work. Going through the draft, I have a > comment/question : > Considering that =E2=80=9CThe containing Enhanced Beacon is not encry= pted.=E2=80=9D > (Section 3), is it necessary to include =E2=80=9Crank priority=E2=80= =9D at L2 and, > thus, revealing this information? I consider it a concern as well. When returning from a deep sleep, where there may be multiple LLNs on different PANIDs (and in 6tisch, with different schedules, even usi= ng different sets of channels), there is a desire to know which network will "closer". I think that we need to understand the tradeoffs, so let's discuss (also in the ROLL WG!). Perhaps a compromise is that the rank priority can be forced to maximum value on networks that want to keep the information private. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlun+cgACgkQgItw+93Q 3WWGowf/cV//VhO4Cj/3miI0YwdUE8uIA+RssM088x2EtjpiDgHwy1SrwPhDP1tA 0SvD3omvHnTee2fbrPEti1zh9HG6g65gjnFE+bH8/1G4nhHXtzxBSn7fkEYGT6o0 DKHLTCJHMdVGHUetOEK5N9oyLi5Lp19SE5+dEkNsPMGVwsjGsm1x9WgSCz2vUqZu Q/vcmucEVPwCfc9z7x6vEqBVTM7MU3Z+8BBJTBw6p2efVguWxx+NMiWY/LkGKD8C Jb1QHu/uitG4Mc3cso2ZfH1Th3EmmqOV2ccJTvwS3xKdjUBGPo9jwifgDtEIr6jJ UCzhd94t8J1IE6Ls+GUr2JSnWsAfMg== =U5/G -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Sep 23 13:50:16 2018 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 4013A130DF5 for ; Sun, 23 Sep 2018 13:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0yYPFHb1j68W for ; Sun, 23 Sep 2018 13:50:05 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 CC615130E13 for ; Sun, 23 Sep 2018 13:50:05 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id a203-v6so963251oib.0 for ; Sun, 23 Sep 2018 13:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eTLx5X3AjkgkgYBIADA9f2nDoYFZFFadLP6K/SpNHDk=; b=P44+D4Wq4YEzbpCydNRt0m1hSKc4Iyr4LgqD67CkYQmxPvHydSGatFMr/yKr7xnBnp avjYND20sACeDr17Qx0yaS/RXuMl+soUX7E9hToG8A7RW1h1B+7psl0z+4xEn3btiELb pV1JemlpJHezINkFF6ejbIqTmKEEsZqkI+J5ba4PlkCndFsDJ8O6hfq/B9s13hTv2Wac SoydOf6s/uPxWF1JsEb/3r2+e7nsPsEtccJPTzWiE+Lnwt0x/bwDKkjR4bPjAjnwUSZb mCRXR0/lIbZtOq1Ecbst6CRgatndzTCkudofAA8sEhVGnqTiV0gDU93C6rsrYtIY5nu7 hVaQ== 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=eTLx5X3AjkgkgYBIADA9f2nDoYFZFFadLP6K/SpNHDk=; b=Sq0iYhvJ4nZ3fEzSgeeD06fBwiuN4PbZmlMIAj86iNci7hkdgA6lFe42EMIzmkf+ZT Gw2dFYhBF3SN9ZMAN9cypWEtZ5FBhK0PYodULds3brXVIkwYM+owlNM2GCz/3kMHlfzE viHcUPcZaS/lgT5bx4+wZHY1YZh36wVW1Gbcp3t20hvJqqPXznUyktu9U/nVrFFc7JYr I9MYOGGLHgs4TH1SbQs8P9guzID3jX/31wFA5tHHRBNs/P/5LjPnO+NwZIsxh0Ev9v4N eaaP0MzIVc1meJ8m3rO2CQ2LhAulKDOVjf2Y226NkOTmLQqa+DGCzTGop7NbR5+joryo VGyA== X-Gm-Message-State: APzg51A1P3Ws8+ijEkkcf2hR0Ve47xQuDrFj5pd5Bxq9aQao57b0c93w vuX6wG+TuiKV34jeNiZN8pCTr+q0D6FC0tp9gIow2Q== X-Google-Smtp-Source: ANB0VdYkE1TPNPjudN7v/Yq0rzgCOlzezYkAByL2qXmi3FAwy1DpbxEfe7maMRXxBUItYryzzqdLgCKM8mOd7OM/RzE= X-Received: by 2002:aca:d7c1:: with SMTP id o184-v6mr3952616oig.347.1537735805041; Sun, 23 Sep 2018 13:50:05 -0700 (PDT) MIME-Version: 1.0 References: <153213124330.11513.14157137359028132358@ietfa.amsl.com> <25023.1537735112@localhost> In-Reply-To: <25023.1537735112@localhost> From: "Prof. Diego Dujovne" Date: Sun, 23 Sep 2018 17:49:53 -0300 Message-ID: To: Michael Richardson Cc: "Georgios Z. Papadopoulos" , "Pascal Thubert (pthubert)" , roll , 6tisch@ietf.org Content-Type: multipart/alternative; boundary="0000000000006b1197057690049a" Archived-At: Subject: Re: [Roll] [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2018 20:50:10 -0000 --0000000000006b1197057690049a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael, I agree on putting the rank to the maximum value to code that the network is not interested in accepting more members, thus, keeping their internal data private. Regards, Diego Le dim. 23 sept. 2018 =C3=A0 17:38, Michael Richardson a =C3=A9crit : > > Georgios Z. Papadopoulos wrote: > > Many thanks for this work. Going through the draft, I have a > > comment/question : > > > Considering that =E2=80=9CThe containing Enhanced Beacon is not enc= rypted.=E2=80=9D > > (Section 3), is it necessary to include =E2=80=9Crank priority=E2= =80=9D at L2 and, > > thus, revealing this information? > > I consider it a concern as well. > > When returning from a deep sleep, where there may be multiple > LLNs on different PANIDs (and in 6tisch, with different schedules, even > using > different sets of channels), there is a desire to know which network wil= l > "closer". > > I think that we need to understand the tradeoffs, so let's discuss > (also in the ROLL WG!). Perhaps a compromise is that the rank priority c= an > be forced to maximum value on networks that want to keep the information > private. > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > --=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 --0000000000006b1197057690049a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I agree on putting the rank to the maximum value
to code that = the network is not interested in accepting more members,
thus, ke= eping their internal data private.
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=A0Diego

Le=C2=A0dim. 23 sept. 2018 =C3=A0=C2=A017:38, Micha= el Richardson <mcr+ietf@sande= lman.ca> a =C3=A9crit=C2=A0:

Georgios Z. Papadopoulos <georgios.papadopoulos@imt-atlantique.fr&= gt; wrote:
=C2=A0 =C2=A0 > Many thanks for this work.=C2=A0 Going through the draft= , I have a
=C2=A0 =C2=A0 > comment/question :

=C2=A0 =C2=A0 > Considering that =E2=80=9CThe containing Enhanced Beacon= is not encrypted.=E2=80=9D
=C2=A0 =C2=A0 > (Section 3), is it necessary to include =E2=80=9Crank pr= iority=E2=80=9D at L2 and,
=C2=A0 =C2=A0 > thus, revealing this information?

I consider it a concern as well.

When returning from a deep sleep,=C2=A0 where there may be multiple
LLNs on different PANIDs (and in 6tisch, with different schedules, even usi= ng
different sets of channels),=C2=A0 there is a desire to know which network = will
"closer".

I think that we need to understand the tradeoffs, so let's discuss
(also in the ROLL WG!).=C2=A0 Perhaps a compromise is that the rank priorit= y can
be forced to maximum value on networks that want to keep the information private.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



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


--
DIEGO DUJOVNE
Profesor Asociado
Escuel= a de Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa -= Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
--0000000000006b1197057690049a-- From nobody Wed Sep 26 04:02:48 2018 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 67953130E7F; Wed, 26 Sep 2018 04:02:46 -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.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <153795976638.21587.8841062008123490454@ietfa.amsl.com> Date: Wed, 26 Sep 2018 04:02:46 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-efficient-npdao-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 11:02:46 -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-06.txt Pages : 14 Date : 2018-09-26 Abstract: This document describes the problems associated with the use of NPDAO messaging in RPL 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-roll-efficient-npdao-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-efficient-npdao-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 26 04:07:08 2018 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 81D91130E84 for ; Wed, 26 Sep 2018 04:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZANuKtUKiHKc for ; Wed, 26 Sep 2018 04:07:05 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 28DFE130E7F for ; Wed, 26 Sep 2018 04:07:05 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id m26-v6so10672559uap.2 for ; Wed, 26 Sep 2018 04:07:05 -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=alfr5RTGb3rLHWcOfhgXkPD6qRPrtLvkm4W/FxCn3gg=; b=KlYiWZSmMELDrHzEj32caaS2DpjFIVl5gAjYhS0GkFFLuWUxtfKcZXAsE0pl3Q4vb8 fz+mPCSaQ7HMPJxzR89DBYutkYrSJrExBcvMBJsoVfPjAaqDV5Kn4Lfs17aXuskjbeWd eusbFI111bEa3sXbk6ByqEI1y1EGLiUQYK48H5t7v1wzyEWrn4JFjdMkW4bl4o96w0ue BFTll2sGnYzMU6MKNEqqW4r/G9so50UXVU2vRW+WHVZrVhopryOZhL/3qjvvF1zp80CI oGv9G9SY7f9HlLz8e8sMEzTDZSP0rMrtG3gd2ykMMfV6SfUNmwseG/+XS5+tLLW/4lEG Scpw== 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=alfr5RTGb3rLHWcOfhgXkPD6qRPrtLvkm4W/FxCn3gg=; b=ibi9y3wK0k7zYRhA8955G3o9zAEI8EK0nvUnrD0GCz9HmgdWpq05xCl18KkFu5iVul SzOk6/jBfa22lW56eTRELHi6IPOWEUP4dfXaI+NvrV4vEWFYBWdpAZQLbBBNuSUVzthp 6mo+9QMLCPILrBoOeSyxovQAi19Nv1TcmgjGH1VQ//DQqUzO6aiNKG8nQwkf/wgMBqjv 4aU4LvuYLWrjYJ8QVqs7cc29pQe9a7Lj5qC9fDZci+GuCjBVvXC2woN0LB90Wpg7al/4 77Cou4XrDOLXizb4OqZMxCG6eRH5vktcVOXlPwDQA1kxWxr7OKYmXtlPDKAE4uwagZOQ r/rA== X-Gm-Message-State: ABuFfoi8FzWrpSls8Zk7FfqjjyxmwViXQF9I1rxGd3vqnaFw00wQ0qCp 78FKc6tKmUgB0MBYCPRhIZ8skwgamN5DiV7++0S07Q== X-Google-Smtp-Source: ACcGV62cBpF2me1kV7vBSlvMoZOt91nJku4JBt9sSJ3DZXDWOTBH4z7i0Vin54Nbp2ex0eNiME1ZQ7B12ImLF+Q3gjk= X-Received: by 2002:ab0:1052:: with SMTP id g18-v6mr596502uab.38.1537960023637; Wed, 26 Sep 2018 04:07:03 -0700 (PDT) MIME-Version: 1.0 References: <153795976638.21587.8841062008123490454@ietfa.amsl.com> In-Reply-To: <153795976638.21587.8841062008123490454@ietfa.amsl.com> From: Rahul Jadhav Date: Wed, 26 Sep 2018 16:36:51 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000e344040576c43836" Archived-At: Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-efficient-npdao-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 11:07:07 -0000 --000000000000e344040576c43836 Content-Type: text/plain; charset="UTF-8" Hello All, The updates are based on comments from Peter. Thank you Peter for the review. We have simplied the text in several sections so as to ease readability and made consistent use of terminology throughout the document. Hope it helps. Thanks, Rahul ---------- Forwarded message --------- From: Date: Wed, 26 Sep 2018 at 16:32 Subject: [Roll] I-D Action: draft-ietf-roll-efficient-npdao-06.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Efficient Route Invalidation Authors : Rahul Arvind Jadhav Pascal Thubert Rabi Narayan Sahoo Zhen Cao Filename : draft-ietf-roll-efficient-npdao-06.txt Pages : 14 Date : 2018-09-26 Abstract: This document describes the problems associated with the use of NPDAO messaging in RPL 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-roll-efficient-npdao-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-efficient-npdao-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --000000000000e344040576c43836 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,=C2=A0

The updates are based = on comments from Peter. Thank you Peter for the review.=C2=A0
We = have simplied the text in several sections so as to ease readability and ma= de consistent use of terminology throughout the document. Hope it helps.

Thanks,
Rahul

---------- Forwarded message ---------
Fro= m: <intern= et-drafts@ietf.org>
Date: Wed, 26 Sep 2018 at 16:32
Sub= ject: [Roll] I-D Action: draft-ietf-roll-efficient-npdao-06.txt
To: <= ;i-d-announce@ietf.org>
= Cc: <roll@ietf.org>


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:= Efficient Route Invalidation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rahu= l Arvind Jadhav
=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Rabi Narayan Sahoo
=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 Zhen Cao
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-roll-efficient-npdao-06.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 := 2018-09-26

Abstract:
=C2=A0 =C2=A0This document describes the problems associated with the use o= f NPDAO
=C2=A0 =C2=A0messaging in RPL and signaling changes to improve route invali= dation
=C2=A0 =C2=A0efficiency.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-roll-efficient-npdao/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf= -roll-efficient-npdao-06
https://datatracker.ietf.org= /doc/html/draft-ietf-roll-efficient-npdao-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-roll-efficient-npdao-06


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
--000000000000e344040576c43836-- From nobody Thu Sep 27 01:49:26 2018 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 272AE130E13; Thu, 27 Sep 2018 01:49:25 -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_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 zleYSkwVXTXv; Thu, 27 Sep 2018 01:49:23 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 C5616130ECA; Thu, 27 Sep 2018 01:49:22 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id i4-v6so665478uak.0; Thu, 27 Sep 2018 01:49:22 -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 :cc; bh=T1HYXqcaP+Qbd1CK1yVmkMRIvasHXFSq8oyn3Hxsg+Q=; b=AAFkzNe0S9RpGlyubxYcXkFU4/ZpdV4p22y+SbaSfdVin1Whrgue/qupWoxiJcg5Yf 1ZH+MrQeMhQEz203gfKd2EVOQIIJfEugydCShjJFAhQLdXGEwn6YAkf/1LzaJvlvsP0K BCbe2EEJyPtXHkcluogKqQ4jhZZkgQoLozzzTUPcJOeGnTUL1+BHIhIZCrh8i/qBLttl 89DyqH1P3wI7pNjRqrz6IitALryC+Ua5spl2WKfcBEHj+X/09jvGA/+pyPtmuxPXlwxC mI7JNpXVdKcNJKUqvyLHWZqdcI9qeUY0XajuGbKoayiooAe/Munh1Jhio8Z0LgGPZtLi I9Dg== 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=T1HYXqcaP+Qbd1CK1yVmkMRIvasHXFSq8oyn3Hxsg+Q=; b=R97yc1/Yqa7Lb9dlVuNXBYHUNAWiTBiyXrHZZ0cC5rXVvDjkpmXj4d0gypDF+x+Gyc zTDWQhX4xIEq55vv4kbIBaZCcECA7Np8i3xdwR391grcBCnYKxJC0FDYtxLuzdHA6y9w gMfQYQybXiBldpQMy7YVwgoWjZUWrbkNO0ttUrmhlW+uEXrdKZN9WaILgk/Uio/2HJ2N gV/yJe4DKkN0kDm9FtHJ6rZ9APul/CQJrw5KBxpSgu01XGnMz5WtsCsdcChtcmJqs0eu 81Eo3BaVUqw9L70MWOHE29N2tGiW4J0wVJLDwn8EiBSmxrscbon6nQWonOg4481QJI1u 18SA== X-Gm-Message-State: ABuFfoiPqgq9o92hcNGKP6M9iN6sY4WcBjkX4Yj9A+v2kiQCf5coG/0n F1+BKiwoxUeechRuBUUp7PIZ/T0bEKujcc8BRjE= X-Google-Smtp-Source: ACcGV60ZuN71WMRVEtq/gNjUlMzDRIEbeHI/Z7Q1kcxT1XenxLZQUAfo27er5DXVXRtAZ39d5yZJfhdcVBS7Lv3XlEI= X-Received: by 2002:ab0:4ade:: with SMTP id t30-v6mr3207464uae.35.1538038161702; Thu, 27 Sep 2018 01:49:21 -0700 (PDT) MIME-Version: 1.0 References: <65ac8a93279212d8757d1ecf24ac9e42@bbhmail.nl> In-Reply-To: <65ac8a93279212d8757d1ecf24ac9e42@bbhmail.nl> From: Rahul Jadhav Date: Thu, 27 Sep 2018 14:19:10 +0530 Message-ID: To: "consultancy@vanderstok.org" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="0000000000004785830576d66a13" Archived-At: Subject: Re: [Roll] draft-ietf-roll-efficient-npdao review 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 Sep 2018 08:49:25 -0000 --0000000000004785830576d66a13 Content-Type: text/plain; charset="UTF-8" Please find responses inline. Thanks, Rahul On Thu, 6 Sep 2018 at 18:40, Peter van der Stok wrote: > Hi authors, > > Many thanks for this work and solving an open important problem. > > being the shepherd of this draft, I looked at the text to look for > improvements to facilitate the reading by the IESG. > I found the document difficult to read due to the use of multiple terms > for the same concept. > I would appreciate that the first 3 sections are improved, such that I can > continue the review afterwards without me wondering about my choices in the > interpretation of the text. > > For example: is a sub-node the same thing as a child in the node? and what > is a dependent node? > Some suggestions to improve the document are written below. > [RJ] We have revisited all such instances and reworded to make the terminology consistent. > > Can you use, for example, the terms Switching-node (S-node) > After-switching parent (A-parent) and Before-switching parent (B-parent); > that will simplify the text and improve readability. > Please use consistently throughout one DODAG terminology like parent, > child, ancestor or another preferred terminology. > What does "target" mean: an endpoint of a path, a field in a packet, or > the S-node? > I thought that there can be many common ancestors on two paths with same > source and destination, and one of them is the first common ancestor. BTW > is the first one important; The rest of the text does not seem to rely on > it. > [RJ] We had a good discussion internally to check whether to use the new terms you suggested. But we thought it might further complicate things and deter readability. We have updated the terminology sections with few previously un-explained terms and have revised wordings for sections 2 and 3. > > In section 1.4; to which what subtree do you refer? > > In section 8.2.1 of RFC6550 it is mentioned that there can be a set of > preferred parents. > However, I have the impression that your assumption is the existence of a > single preferred parent, Some explanatory text would help. > [RJ] We have added an explicit section "DCO with multiple preferred parents" to make it explicit. > > Some textual suggestions: > Every first introduction of an acronym must be introduced with the full > name; for example: DAO must be written out both in the abstract as in the > text for the first use; please look for all the first instances in the text. > In section 1.1 it will help if the list of used terms of RFC6550 is added. > > Section 3; a reminder that this applies only to storing mode may help. > [RJ] In introduction section we have explicitly added text saying the technique is applicable for storing MOP only. > > 3.1 How can transmission be tolerant to a link failure when the link has > disappeared completely or the node has been removed; some explanation is > needed here. It would help if the assumptions are listed: like there is > another path via .... > [RJ] Have reworded the para. > > In section 3.1, 3.2 and 3.3 it should not be necessary to repeat what is > written in section 2.1, 2.2 and 2.3, just a reference to the corresponding > section will do. > > [RJ] we have removed duplicate sentences and reworded section 2 heavily. > Section 7 is rather short; I doubt that it will be accepted in this form. > There have been earlier comments on the insufficiency of the security > considerations in RPL documents, > > [RJ]: I have changed the wordings here, but i m not sure if there is any more security considerations that could be added. Is there any other consideration that is applicable? Would like to get feedback from WG. > I hope I conveyed my problems sufficiently, and look forward to a new > version to continue the review. > > --0000000000004785830576d66a13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please find responses inline.

Thanks,
Rahul

On Thu,= 6 Sep 2018 at 18:40, Peter van der Stok <stokcons@bbhmail.nl> wrote:
Hi authors,

Many thanks for this work and solving an open impor= tant problem.

being the shepherd of this draft, I looked at the text= to look for improvements to facilitate the reading by the IESG.
I found= the document difficult to read due to the use of multiple terms for the sa= me concept.
I would appreciate that the first 3 sections are improved, s= uch that I can continue the review afterwards without me wondering about my= choices in the interpretation of the text.

For example: is a sub-no= de the same thing as a child in the node? and what is a dependent node?
= Some suggestions to improve the document are written below.
=

[RJ] We have revisited all such instances = and reworded to make the terminology consistent.
=C2=A0

Can you use, for example, t= he terms Switching-node (S-node) After-switching parent (A-parent) and Befo= re-switching parent (B-parent); that will simplify the text and improve rea= dability.
Please use consistently throughout one DODAG terminology like = parent, child, ancestor or another preferred terminology.
What does &quo= t;target" mean: an endpoint of a path, a field in a packet, or the S-n= ode?
I thought that there can be many common ancestors on two paths with= same source and destination, and one of them is the first common ancestor.= BTW is the first one important; The rest of the text does not seem to rely= on it.

[RJ] We had a good = discussion internally to check whether to use the new terms you suggested. = But we thought it might further complicate things and deter readability. We= have updated the terminology sections with few previously un-explained ter= ms and have revised wordings for sections 2 and 3.
=C2=A0

In section 1.4; to which = what subtree do you refer?

In section 8.2.1 of RFC6550 it is mention= ed that there can be a set of preferred parents.
However, I have the imp= ression that your assumption is the existence of a single preferred parent,= Some explanatory text would help.

[RJ] We have added an explicit section "DCO with multiple pref= erred parents" to make it explicit.

=C2=A0

Some textual suggest= ions:
Every first introduction of an acronym=C2=A0must be introduced wit= h the full name; for example: DAO must be written out both in the abstract = as in the text for the first use; please look for all the first instances i= n the text.
In section 1.1 it will help if the list of used terms of RFC= 6550 is added.

Section 3; a reminder that this applies only to stori= ng mode may help.

[RJ] In i= ntroduction section we have explicitly added text saying the technique is a= pplicable for storing MOP only.=C2=A0=C2=A0

3.1 How can transmission be tolerant to a link fa= ilure when the link has disappeared completely or the node has been removed= ; some explanation is needed here. It would help if the assumptions are lis= ted: like there is another path via ....
<= br>
[RJ] Have reworded the para.
=C2=A0

In section 3.1, 3.2 and 3.3 it sh= ould not be necessary to repeat what is written in section 2.1, 2.2 and 2.3= , just a reference to the corresponding section will do.

[RJ] we have removed duplicate sentences and reworded se= ction 2 heavily.=C2=A0
=C2=A0
Section 7 is rather short; I doubt that it will be accept= ed in this form.
There have been earlier comments on the insufficiency o= f the security considerations in RPL documents,

[RJ]: I have changed the wordings here, but i m not sure if there= is any more security considerations that could be added. Is there any othe= r consideration that is applicable? Would like to get=C2=A0 feedback from W= G.
=C2=A0
=
I = hope I conveyed my problems sufficiently, and look forward to a new version= to continue the review.

--0000000000004785830576d66a13-- From nobody Thu Sep 27 01:51:10 2018 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 963C6130E1D; Thu, 27 Sep 2018 01:51:02 -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.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <153803826259.26285.715815590686590741@ietfa.amsl.com> Date: Thu, 27 Sep 2018 01:51:02 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-efficient-npdao-07.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: Thu, 27 Sep 2018 08:51:03 -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-07.txt Pages : 14 Date : 2018-09-27 Abstract: This document describes the problems associated with the use of NPDAO messaging in RPL 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-roll-efficient-npdao-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-efficient-npdao-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 27 01:55:52 2018 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 A7EA2130E27; Thu, 27 Sep 2018 01:55: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_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 304E8rTss_vH; Thu, 27 Sep 2018 01:55:48 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 070B0130E1D; Thu, 27 Sep 2018 01:55:48 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id r15-v6so670326uao.1; Thu, 27 Sep 2018 01:55:47 -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 :cc; bh=PT6ikekQIi6QvvZwAcoVe+AJVBKLZOaqRsZx+WIXJI4=; b=bLgyjpib2vXXSJe1Ubu9VWcdTrvMsg7/sLEe8wXB12+qhHYKKY+6kPyrF9rtZIZcFG gycUtlR5Vm+epLXm+B2BmBu3/rFr8dw1cGb95yWvAGZYmaiRnvKnxCTxapLSYYUtFynD tqp+9fMFgOUynHQaYt/9j1B6uGxVpaJuUpTGuBZebqJSN7p4WZzJRBokuIrGinHsjH1i EYKm9lhCZ55IHDWgayp/OHDSymugbZOoZ1QKdIU8uSMF1f0Lj8d0TVGCYT+HFG3WkwGk fLenxq8bUrFBaaZnb7yw+YuT7EomU4L0tlznzTLMhywAjqF1sqmoljfMw/Xn7rj40BRh LpFg== 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=PT6ikekQIi6QvvZwAcoVe+AJVBKLZOaqRsZx+WIXJI4=; b=X/fUax3JKKYkeeze99BiXZfUCriYwbzcbDL9nxrBG2qf/O4yYwWtgsWLHTQ3spmSLu kzofQ/57d40DqjQjZ0vMonMpSnB/3EHQd07RIKcqoZBpEZPAAaeppWMy5Q80EqQy4hIm dlGehwJoD3dmtckqUn4S5AdFldOQM1ItekwuJ4QtZbwvhCuhw/su9HASzx78SaowPmIY kYbl8UgTejF5+PC7KLfcBgX2d2eZ0fW2a07dqIIjlT26ANUY8LEi+wwG33QZWV32/TZG vtaH6jBBlK6n9PmiA6eMji5tQpgctA0QpPPXMCnQ1AgwgCxLsKFH7HmqfqsGWLvlJ3EI zNWQ== X-Gm-Message-State: ABuFfogrVQKtPGGMvUlkw+p6B6Pj0pyV4PO9irAIrWjDE6nuOqypKozi qdHxEmVWikcK3iuvyPj9sgN+0tMI0dIxP1ZKkCgFd4qJ X-Google-Smtp-Source: ACcGV60RHmuHKDG0udtNSq7o3Lp8NL2XE+D9OcK+ywt1nXAv8Hc2/z50TXDoFFK4lBIIGFCMDSvu0ILyTR2AWjzMmp8= X-Received: by 2002:ab0:4ade:: with SMTP id t30-v6mr3214414uae.35.1538038546880; Thu, 27 Sep 2018 01:55:46 -0700 (PDT) MIME-Version: 1.0 References: <65ac8a93279212d8757d1ecf24ac9e42@bbhmail.nl> In-Reply-To: From: Rahul Jadhav Date: Thu, 27 Sep 2018 14:25:35 +0530 Message-ID: To: "Pascal Thubert (pthubert)" Cc: "consultancy@vanderstok.org" , Routing Over Low power and Lossy networks , draft-ietf-roll-efficient-npdao@ietf.org Content-Type: multipart/alternative; boundary="0000000000003cdda00576d6817b" Archived-At: Subject: Re: [Roll] draft-ietf-roll-efficient-npdao review 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 Sep 2018 08:55:51 -0000 --0000000000003cdda00576d6817b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Pascal, Thank you for the review. Have incorporated your comments and updated the draft (-07). Please find my response inline. Best, Rahul On Sat, 8 Sep 2018 at 16:46, Pascal Thubert (pthubert) wrote: > Dear all > > I made my own review and find the document mostly ready. I agree that > Peter=E2=80=99s comments need handling to make the best text cleaner. The > introduction could also be tightened and the English improved a bit, but = I > guess the rfc editor will help us there. > > A word on DAO vs. NPDAO with a same sequence would clarify that the DAO i= s > valid and the route installed or kept depending on the order of the 2 > messages. A DAO received after a NPDAO but with an older sequence is > ignored. This is classical RPL, but mentioning it could still be useful. > [RJ]: Have updated Section 4.3.3 "Path Sequence Number in DCO" to explicitly state the sequence number handling. > > One last thing could be a bit more details on when to place options and > why. > [RJ]: Have updated Section 4.2 to explain this. > > Otherwise all good for me! > > Pascal > > Le 6 sept. 2018 =C3=A0 18:07, Rahul Jadhav a =C3= =A9crit : > > Many thanks Peter for the review. We will work on these comments and > update the draft and provide detailed response soon. > > Thanks, > Rahul > > On Thu, 6 Sep 2018 at 6:40 PM, Peter van der Stok > wrote: > >> Hi authors, >> >> Many thanks for this work and solving an open important problem. >> >> being the shepherd of this draft, I looked at the text to look for >> improvements to facilitate the reading by the IESG. >> I found the document difficult to read due to the use of multiple terms >> for the same concept. >> I would appreciate that the first 3 sections are improved, such that I >> can continue the review afterwards without me wondering about my choices= in >> the interpretation of the text. >> >> For example: is a sub-node the same thing as a child in the node? and >> what is a dependent node? >> Some suggestions to improve the document are written below. >> >> Can you use, for example, the terms Switching-node (S-node) >> After-switching parent (A-parent) and Before-switching parent (B-parent)= ; >> that will simplify the text and improve readability. >> Please use consistently throughout one DODAG terminology like parent, >> child, ancestor or another preferred terminology. >> What does "target" mean: an endpoint of a path, a field in a packet, or >> the S-node? >> I thought that there can be many common ancestors on two paths with same >> source and destination, and one of them is the first common ancestor. BT= W >> is the first one important; The rest of the text does not seem to rely o= n >> it. >> >> In section 1.4; to which what subtree do you refer? >> >> In section 8.2.1 of RFC6550 it is mentioned that there can be a set of >> preferred parents. >> However, I have the impression that your assumption is the existence of = a >> single preferred parent, Some explanatory text would help. >> >> Some textual suggestions: >> Every first introduction of an acronym must be introduced with the full >> name; for example: DAO must be written out both in the abstract as in th= e >> text for the first use; please look for all the first instances in the t= ext. >> In section 1.1 it will help if the list of used terms of RFC6550 is adde= d. >> >> Section 3; a reminder that this applies only to storing mode may help. >> >> 3.1 How can transmission be tolerant to a link failure when the link has >> disappeared completely or the node has been removed; some explanation is >> needed here. It would help if the assumptions are listed: like there is >> another path via .... >> >> In section 3.1, 3.2 and 3.3 it should not be necessary to repeat what is >> written in section 2.1, 2.2 and 2.3, just a reference to the correspondi= ng >> section will do. >> >> Section 7 is rather short; I doubt that it will be accepted in this form= . >> There have been earlier comments on the insufficiency of the security >> considerations in RPL documents, >> >> I hope I conveyed my problems sufficiently, and look forward to a new >> version to continue the review. >> >> All the best, >> >> Peter >> >> >> -- >> Peter van der Stok >> vanderstok consultancy >> mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl >> www: www.vanderstok.org >> tel NL: +31(0)492474673 F: +33(0)966015248 >> > --0000000000003cdda00576d6817b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Pascal,=C2=A0

Thank you for the r= eview. Have incorporated your comments and updated the draft (-07).
Please find my response inline.

Best,
Rahul

On Sat, 8 Sep 2= 018 at 16:46, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
Dear all

I made my own review and find the document mostly ready. I agree that = Peter=E2=80=99s comments need handling to make the best text cleaner. The i= ntroduction could also be tightened and the English improved a bit, but I g= uess the rfc editor will help us there.

A word on DAO vs. NPDAO with a same sequence would clarify that the DA= O is valid and the route installed or kept depending on the order of the 2 = messages. A DAO received after a NPDAO but with an older sequence is ignore= d. This is classical RPL, but mentioning it could still be useful.

[RJ]= : Have updated Section 4.3.3 "Path Sequence Number in DCO"=C2=A0= =C2=A0=C2=A0to explicitly state the sequence= number handling.

One last thing could be a bit more details on when to place options an= d why.

[RJ]: Have updated Secti= on 4.2 to explain this.
=C2=A0

Otherwise all good for me!

Pascal

Le 6 sept. 2018 =C3=A0 18:07, Rahul Jadhav <rahul.ietf@gmail.com> a =C3=A9crit=C2= =A0:

Many thanks Peter for the review. We will work on these c= omments and update the draft and provide detailed response soon.

Thanks,
Rahul

On Thu, 6 Sep 2018 at 6:40 PM, Peter van der Stok <stokcons@bbhmail.nl> wrote:
Hi authors,

Many thanks for this work and solving an open important problem.

being the shepherd of this draft, I looked at the text to look for improvem= ents to facilitate the reading by the IESG.
I found the document difficult to read due to the use of multiple terms for= the same concept.
I would appreciate that the first 3 sections are improved, such that I can = continue the review afterwards without me wondering about my choices in the= interpretation of the text.

For example: is a sub-node the same thing as a child in the node? and what = is a dependent node?
Some suggestions to improve the document are written below.

Can you use, for example, the terms Switching-node (S-node) After-switching= parent (A-parent) and Before-switching parent (B-parent); that will simpli= fy the text and improve readability.
Please use consistently throughout one DODAG terminology like parent, child= , ancestor or another preferred terminology.
What does "target" mean: an endpoint of a path, a field in a pack= et, or the S-node?
I thought that there can be many common ancestors on two paths with same so= urce and destination, and one of them is the first common ancestor. BTW is = the first one important; The rest of the text does not seem to rely on it.<= br>
In section 1.4; to which what subtree do you refer?

In section 8.2.1 of RFC6550 it is mentioned that there can be a set of pref= erred parents.
However, I have the impression that your assumption is the existence of a s= ingle preferred parent, Some explanatory text would help.

Some textual suggestions:
Every first introduction of an acronym=C2=A0must be introduced with the ful= l name; for example: DAO must be written out both in the abstract as in the= text for the first use; please look for all the first instances in the tex= t.
In section 1.1 it will help if the list of used terms of RFC6550 is added.<= br>
Section 3; a reminder that this applies only to storing mode may help.

3.1 How can transmission be tolerant to a link failure when the link has di= sappeared completely or the node has been removed; some explanation is need= ed here. It would help if the assumptions are listed: like there is another= path via ....

In section 3.1, 3.2 and 3.3 it should not be necessary to repeat what is wr= itten in section 2.1, 2.2 and 2.3, just a reference to the corresponding se= ction will do.

Section 7 is rather short; I doubt that it will be accepted in this form. There have been earlier comments on the insufficiency of the security consi= derations in RPL documents,

I hope I conveyed my problems sufficiently, and look forward to a new versi= on to continue the review.

All the best,

Peter
--0000000000003cdda00576d6817b-- From nobody Thu Sep 27 04:36:14 2018 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 36893130FF0 for ; Thu, 27 Sep 2018 04:36:06 -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, 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 Ebkcn2t6mBsg for ; Thu, 27 Sep 2018 04:36:03 -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 BF7F8130EF6 for ; Thu, 27 Sep 2018 04:36:03 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id j68-v6so1820425oib.7 for ; Thu, 27 Sep 2018 04:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=78g94FYGdn90mMpevtwgGWtd8TsFtno/Bco8wTlw5wk=; b=aYKZDSw3boEgL7lGEFW6fNYzfjkX8IsFfN4lnOt6K3Vpc/ATkt1Msryp7HEKLhQCXk +0kBsBaD17/TEqY0OuODh/O3q8V1yX7dZ0XISthkWCx8Ax0AqOGngZsMEa308yhcyFSa c9b1dBP7NLp6v9J3b87DIMtvAHvPoECEEMwDhhSiL2GoRYhSkzP/KROgrJ216KDoAdUs ud9AU0qGgzrWkrPuLsHcMlOcKODaebaG0E4LI+0qVjJGsakao42y6l8WoiLjJljobYW6 o9rji60f3RtXZKFHQqNkEp/W+DWbwNzOwZpVoEItrO4FccpOMTLhylhuQKZ/e6IJ4Kpk xkDQ== 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=78g94FYGdn90mMpevtwgGWtd8TsFtno/Bco8wTlw5wk=; b=SGeI7DaxmgFXYQkuEwY4gE4HQ07dDQ6ZZfD4ZsLfkXxXWf1kBL8jx4xusi7cqeKACM 5eU3lgvaZdR+s8Z7qLo34VlpCGd2AcU4cHqgqClIZ6UJWvCtaT82x+RZIJ4MRxHogPUl eB2J9KCo7FKTvzeDkX2WeaQ3mCUYzEdfuWIXQe+gCuDBFxPAwKyI6gVeHF8zejoPdcws M8GBEhwurdfggfYaSMqv8H4fG0+zF7lRWemOK1BAIzVuRGYl8B49y07Uy1EYQqoXv3Jh AyqmPKT4TGligF9ip4meqEufIOGblvUwusc71RysOrodyxNFBX8UOFcbaOo5Z2NWnskA eJ1A== X-Gm-Message-State: ABuFfohxhFuJ2zSk63VyrPqNRzCoNoVegct1XbtOzL4HEKe4Z/bSHs4g 5EJ0Pjnm+p2tqEhif35SfGO4k+DSTrJX8RsDU+9yeIRI X-Google-Smtp-Source: ACcGV612SnMpeNTSzLb6l3vhVZrt45Bb4hT3GCP2UMQ9GKrKxJga+AbbGNM6xrXvc5TyeU0IdBSXOrhmZm/qoa5yepA= X-Received: by 2002:aca:d01:: with SMTP id 1-v6mr2761104oin.239.1538048162740; Thu, 27 Sep 2018 04:36:02 -0700 (PDT) MIME-Version: 1.0 From: Moussa ABOUBAKAR Date: Thu, 27 Sep 2018 13:33:09 +0200 Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary="000000000000633f3d0576d8bec8" Archived-At: Subject: [Roll] OMNeT++ code for RPL 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 Sep 2018 11:36:12 -0000 --000000000000633f3d0576d8bec8 Content-Type: text/plain; charset="UTF-8" Dear all, I'm PhD student and I'm now working on routing scheme on Low power and lossy network. I'm now looking for the code of RPL on Omnet++ to start simulation. Any help you can provide is welcome. Kinds regards, -- ABOUBAKAR Moussa PhD student Computer Science Twitter: abakamousa https://www.linkedin.com/in/aboubakar-moussa Tel: +33 7 58 30 82 16 --000000000000633f3d0576d8bec8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

I'm PhD stude= nt and I'm now working on routing scheme on Low power=C2=A0 and lossy n= etwork.
I'm now looking for the code of RPL on Omnet++ to start simu= lation.
Any help you can provide is welcome.

<= /div>
Kinds regards,


--
<= div dir=3D"ltr">
=
ABOU= BAKAR Moussa
PhD student Computer Science
Twitter: abakamousa
http= s://www.linkedin.com/in/aboubakar-moussa=C2=A0
Tel: +33 7 58 30 82 = 16
--000000000000633f3d0576d8bec8-- From nobody Thu Sep 27 04:59:28 2018 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 D47FF130E43 for ; Thu, 27 Sep 2018 04:59:25 -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] 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 k0qoay93qI_4 for ; Thu, 27 Sep 2018 04:59:23 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 E6E421277CC for ; Thu, 27 Sep 2018 04:59:22 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w8RBxKkl013798 for ; Thu, 27 Sep 2018 13:59:20 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id A0D2B1D53C1 for ; Thu, 27 Sep 2018 13:59:19 +0200 (CEST) Received: from 83.35.166.151 by webmail.entel.upc.edu with HTTP; Thu, 27 Sep 2018 13:59:20 +0200 Message-ID: In-Reply-To: References: Date: Thu, 27 Sep 2018 13:59:20 +0200 From: "Carles Gomez Montenegro" To: "Routing Over Low power and Lossy networks" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Thu, 27 Sep 2018 13:59:20 +0200 (CEST) Archived-At: Subject: Re: [Roll] OMNeT++ code for RPL 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 Sep 2018 11:59:26 -0000 Dear Moussa, In 2014 we published the code you can find below (look at the arrow on the right and lower corner of the screen for download): https://sites.google.com/site/carlesgomez/home/code The code is for MiXiM, an OMNeT++ framework. However, please be aware that this simulation code is quite limited: it does not support DAO messages. I hope this helps anyway... Cheers, Carles > Dear all, > > I'm PhD student and I'm now working on routing scheme on Low power and > lossy network. > I'm now looking for the code of RPL on Omnet++ to start simulation. > Any help you can provide is welcome. > > Kinds regards, > > > -- > ABOUBAKAR Moussa From nobody Thu Sep 27 05:05:32 2018 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 CDBB5130E3B; Thu, 27 Sep 2018 05:05:24 -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.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <153804992481.26407.344912097213406345@ietfa.amsl.com> Date: Thu, 27 Sep 2018 05:05:24 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-rpl-observations-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 12:05:25 -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 Observations Authors : Rahul Arvind Jadhav Rabi Narayan Sahoo Yuefeng Wu Dacheng Zhang Filename : draft-ietf-roll-rpl-observations-00.txt Pages : 15 Date : 2018-09-27 Abstract: This document describes RPL protocol design issues, various observations and possible consequences of the design and implementation choices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-observations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-00 https://datatracker.ietf.org/doc/html/draft-ietf-roll-rpl-observations-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 27 05:10:53 2018 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 44B2C130EAA; Thu, 27 Sep 2018 05:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 bBl00_VUHjQZ; Thu, 27 Sep 2018 05:10:44 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A231130EC0; Thu, 27 Sep 2018 05:10:44 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 7E08B82044; Thu, 27 Sep 2018 14:10:42 +0200 (CEST) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id f4_d4Y6GdtpL; Thu, 27 Sep 2018 14:10:41 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 5A84982013; Thu, 27 Sep 2018 14:10:41 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr 5A84982013 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1538050241; bh=8U70cuqLGs2LhuLJZdAUhOEXeBzNmywIABnWwBTlbeI=; h=Mime-Version:From:Date:Message-Id:To; b=MLhNZHENl3h4Njn0bVoulhqlaWddMj3sI0wZK24+qYAnPeyE4zAHCcBen8n0udyFi 0yF8sJfvATkK+yUfl2mJ6//azzQ4xs0WLA/gMbBmKwLEsmMPWxvrQDEoUfq2u8vTir bcDfO/dKfgl6aChCBgJWajRk8EiqXh0Eh/7najDY= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id zddZuncZtBwd; Thu, 27 Sep 2018 14:10:41 +0200 (CEST) Received: from [IPv6:2001:660:7301:3728:4c44:ac3b:85fd:ac33] (unknown [IPv6:2001:660:7301:3728:4c44:ac3b:85fd:ac33]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 2070A8200E; Thu, 27 Sep 2018 14:10:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Georgios Z. Papadopoulos" In-Reply-To: <25023.1537735112@localhost> Date: Thu, 27 Sep 2018 14:10:40 +0200 Cc: "Pascal Thubert (pthubert)" , tisch <6tisch@ietf.org>, roll@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3451E11C-A642-4206-8788-86B4B1530AD7@imt-atlantique.fr> References: <153213124330.11513.14157137359028132358@ietfa.amsl.com> <25023.1537735112@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Roll] [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 12:10:51 -0000 Hello Michael, > On Sep 23, 2018, at 22:38, Michael Richardson = wrote: >=20 >=20 > Georgios Z. Papadopoulos = wrote: >> Many thanks for this work. Going through the draft, I have a >> comment/question : >=20 >> Considering that =E2=80=9CThe containing Enhanced Beacon is not = encrypted.=E2=80=9D >> (Section 3), is it necessary to include =E2=80=9Crank priority=E2=80=9D= at L2 and, >> thus, revealing this information? >=20 > I consider it a concern as well. >=20 > When returning from a deep sleep, where there may be multiple > LLNs on different PANIDs (and in 6tisch, with different schedules, = even using > different sets of channels), there is a desire to know which network = will > "closer". >=20 > I think that we need to understand the tradeoffs, so let's discuss > (also in the ROLL WG!). Perhaps a compromise is that the rank = priority can > be forced to maximum value on networks that want to keep the = information > private. +1 Georgios > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Thu Sep 27 05:37:43 2018 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 4479D130E78 for ; Thu, 27 Sep 2018 05:37:41 -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_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 nAi--G25hW36 for ; Thu, 27 Sep 2018 05:37:38 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 C785A130E43 for ; Thu, 27 Sep 2018 05:37:38 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id e21-v6so2346743otk.10 for ; Thu, 27 Sep 2018 05:37:38 -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=20bfPG6xsbJX5Zv09wTmLTkzhv/v9Vgx9BAidaaFncY=; b=qkTVU77bOaVUJFJ1P090KaFqZlSefqJq8x3zAkTPQEnkwGRJxR3W4sygDQ4MmgO7st nmKMKT1B4fAVec26pMkxvNdU4owjgWnrgejaiKi42qNfCGykDsvQeYQ5GBMUty2VbJLx Z4C3urqzChpXTNcw2N/fivFkqq6WEk5kFh2Babv6wW7W9pl97NpFQXtIAcbbfN1hCyzE dEAo2SXZJSFm4NHxxyiup7x6Ju5tCq62WpAJWwHBj9PyXKE4jtYRLlrCvBsFoY9BCdVJ iEOdw9V7wMlYeTlBHjDafQpwyXBI23lXeE4zoU6DxA2XT/emFv+Q3JYYF4UF0jtQaC62 jl/A== 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=20bfPG6xsbJX5Zv09wTmLTkzhv/v9Vgx9BAidaaFncY=; b=i3pd46DcxuREUcZArehRjRvWrGbt/JEFxvpniMJn+Q1kZIHx6UTIh+TrSHsBOLcMfr N5UdYi8cLPRbJ+F4SbivrMSS4bCAM9rWN+7amDibf4qm99zgxWiX9OLcrSvMeqRDabez Jggewwh++FMWX3y3q+yYDqHs64SCmn6YY359BmkybokUf4EcOn+WFSsmqxNf/dcQReTs 0NXtrQ61MjKtZftMJ4yO8bP+Lr+8Vs7upQAUYcEIOAtK3GaNEiOHK3AKEjpST1MQ55dv jnSpfqrCUj/A04mkB8CVZT/yLwFP4HfwB4n0llTW0NDKrzBWv0Bm3T/+c9THBHw9a8vP 4anw== X-Gm-Message-State: ABuFfojDjbtcynLo0aEj/1rtA5lcoVocoCYWfm50uxV7jyqDJ/NjQ5vp LrMBbl+g1XLCx4WDySUDiGLPu/jnqjGUrNqzbKQd9jQq X-Google-Smtp-Source: ACcGV62b1XKKMkX6aclFFpcmdqpgWgodR4xtqL2f5rHoTAGLD7MdjqX026pamIR9cPwHGbUdeetAF3WiRPpZ3vW8kOk= X-Received: by 2002:a9d:437:: with SMTP id 52-v6mr7338365otc.31.1538051857528; Thu, 27 Sep 2018 05:37:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Moussa ABOUBAKAR Date: Thu, 27 Sep 2018 14:34:43 +0200 Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary="0000000000009d3d820576d99a98" Archived-At: Subject: Re: [Roll] OMNeT++ code for RPL 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 Sep 2018 12:37:41 -0000 --0000000000009d3d820576d99a98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Carles, Thank you for your response. I'm going to try starting with that code. Cheers Le jeu. 27 sept. 2018 =C3=A0 13:59, Carles Gomez Montenegro < carlesgo@entel.upc.edu> a =C3=A9crit : > Dear Moussa, > > In 2014 we published the code you can find below (look at the arrow on th= e > right and lower corner of the screen for download): > https://sites.google.com/site/carlesgomez/home/code > > The code is for MiXiM, an OMNeT++ framework. > > However, please be aware that this simulation code is quite limited: it > does not support DAO messages. > > I hope this helps anyway... > > Cheers, > > Carles > > > > Dear all, > > > > I'm PhD student and I'm now working on routing scheme on Low power and > > lossy network. > > I'm now looking for the code of RPL on Omnet++ to start simulation. > > Any help you can provide is welcome. > > > > Kinds regards, > > > > > > -- > > ABOUBAKAR Moussa > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=20 ABOUBAKAR Moussa PhD student Computer Science Twitter: abakamousa https://www.linkedin.com/in/aboubakar-moussa Tel: +33 7 58 30 82 16 --0000000000009d3d820576d99a98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Carles= ,

Thank you for your response.

I'm going to try starting with that code.

Cheers

Le=C2=A0jeu. 27 sept. 2018 =C3=A0=C2=A013:59, Carles Gomez Montenegro &= lt;carlesgo@entel.upc.edu>= a =C3=A9crit=C2=A0:
Dear Moussa,
In 2014 we published the code you can find below (look at the arrow on the<= br> right and lower corner of the screen for download):
https://sites.google.com/site/carlesgomez/home/co= de

The code is for MiXiM, an OMNeT++ framework.

However, please be aware that this simulation code is quite limited: it
does not support DAO messages.

I hope this helps anyway...

Cheers,

Carles


> Dear all,
>
> I'm PhD student and I'm now working on routing scheme on Low p= ower=C2=A0 and
> lossy network.
> I'm now looking for the code of RPL on Omnet++ to start simulation= .
> Any help you can provide is welcome.
>
> Kinds regards,
>
>
> --
> ABOUBAKAR Moussa


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


--
ABOUBAKAR Moussa
PhD stude= nt Computer Science
Twitter: abakamousa
https://www.linkedin.com/in/a= boubakar-moussa=C2=A0
Tel: +33 7 58 30 82 16
=
--0000000000009d3d820576d99a98-- From nobody Thu Sep 27 06:12:27 2018 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 790EB130E89; Thu, 27 Sep 2018 06:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zI9MKushSdPc; Thu, 27 Sep 2018 06:12:23 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E201130E79; Thu, 27 Sep 2018 06:12:22 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 94DA418014B97; Thu, 27 Sep 2018 13:12:21 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:1:2:41:72:152:355:379:582:599:800:960:962:967:968:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1617:1730:1776:1792:2198:2199:2525:2527:2538:2553:2557:2559:2564:2682:2685:2693:2859:2894:2895:2899:2902:2911:2924:2925:2926:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3148:3642:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4050:4250:4321:4362:4425:4557:4860:5007:6119:6261:6298:6657:6659:6678:7464:7903:8603:9025:9094:9177:10004:10346:10848:11232:11657:11658:11914:12043:12109:12114:12291:12295:12438:12663:12683:12740:12895:13139:13237:14096:21060:21063:21080:21324:21433:21451:21611:21625:21740:21796:30029:30036:30054:30062:30070:30083:30090:30091, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netch X-HE-Tag: smoke65_88e8011fd5f45 X-Filterd-Recvd-Size: 14301 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf02.hostedemail.com (Postfix) with ESMTPA; Thu, 27 Sep 2018 13:12:20 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_46f1255f053090e2fd900572e1e759e6" Date: Thu, 27 Sep 2018 15:12:20 +0200 From: Peter van der Stok To: Rahul Jadhav Cc: consultancy@vanderstok.org, draft-ietf-roll-efficient-npdao@ietf.org, Routing Over Low power and Lossy networks Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <65ac8a93279212d8757d1ecf24ac9e42@bbhmail.nl> Message-ID: <2b26f398a3ebd41b32cf46aa7f328603@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.220.17] Archived-At: Subject: Re: [Roll] draft-ietf-roll-efficient-npdao review 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 Sep 2018 13:12:26 -0000 --=_46f1255f053090e2fd900572e1e759e6 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Please find answers to responses and additional review of -06, later switching to -07 Peter Rahul Jadhav schreef op 2018-09-27 10:49: > Please find responses inline. > > Thanks, > Rahul > > On Thu, 6 Sep 2018 at 18:40, Peter van der Stok wrote: > [RJ] We have revisited all such instances and reworded to make the terminology consistent. > [RJ] We had a good discussion internally to check whether to use the new terms you suggested. But we thought it might further complicate things and deter readability. We have updated the terminology sections with few previously un-explained terms and have revised wordings for sections 2 and 3. > > [pvds]The terminology is not a objective in itself. I think the text has been much clarified. thanks. > BTW, sometimes it helps to introduce concepts and name them to make the text and ideas clearer. > >> In section 1.4; to which what subtree do you refer? > > [RJ] We have added an explicit section "DCO with multiple preferred parents" to make it explicit. > [pvds]see my review below > >> > > [RJ] In introduction section we have explicitly added text saying the technique is applicable for storing MOP only. > [pvds]That helped a lot. > >> 3.1 How can transmission be tolerant to a link failure when the link has disappeared completely or the node has been removed; some explanation is needed here. It would help if the assumptions are listed: like there is another path via .... > > [RJ] Have reworded the para. > [pvds] I still don't get it; what happens when no packet at all passes through the link? The NPDAO will never reach (B), (G), and (H) (your example), the DCO will reach (B) and (G); is that the tolerance you mean? > >> In section 3.1, 3.2 and 3.3 it should not be necessary to repeat what is written in section 2.1, 2.2 and 2.3, just a reference to the corresponding section will do. > > [RJ] we have removed duplicate sentences and reworded section 2 heavily. > [pvds]Quite nice. > >> Section 7 is rather short; I doubt that it will be accepted in this form. >> There have been earlier comments on the insufficiency of the security considerations in RPL documents. >> >> [Pvds]You may be inspired by RFC7733, RFC7416 and draft-richardson-roll-applicability-template-02 [1] >> __________________________________________________________________________________ >> >> Review npdao-06/-07 >> >> Hi co-author, >> >> Thanks for this version that reads much more easily. >> >> Please, give the full name at first appearance of the following terms. >> >> RPL, 6LBR, 6LR; Otherwise someone from IESG will ask you to do so. >> >> Common ancestor node: s/child node/target Node/ >> >> Section 1.1 which terms from RFC6550 are used. It is good practice to enumerate them to help the reader, otherwise he wonders for each unknown term where it comes from. >> >> Section 1.2 end: s/BR/6LBR/ to align with earlier text and figure.. >> >> At the end of this section some text about multiple parents is helpful; Do you exclude that possibility? Or does an additional set of parents (foreseen in RFC6550) have no influence? I doubt it. >> >> Just read version 07; section 4.4.3 is a statement that needs some explanation to be understood. Also an implementer needs some guidance on what to do; send a NPDAO to all parents, probably not,? Do you need an additional new parent? Send the DCO from all common ancestors on all paths? >> >> Section 1.3 subtree switching example, suggested text is: needs to be done for the routing table entries of (C), (H), (A), (G), and (B) with destination (D), (E), and (F). >> >> Section 2.2 suggested text: >> >> There is no NPDAO generated by the child nodes (E) and (F), through the previous path via (D) to (B) and (G), resulting….. >> >> Section 2.3 s/from previous route may invalidate the existing/via previous route may invalidate the previous/ >> >> Sec 3.1 the title mentions "parents" (plural) where the earlier text only considers a single parent >> >> Sec 4.1; How does a common ancestor know, it is a common ancestor? I am not convinced that a node which has an old entry that specifies a different route is still necessarily a common ancestor. That old path may pass through different nodes; not (G) and (H) to follow the example. >> >> Sec 4.2 /specifies/specify/ ---plural options >> >> Section 4.3 What are the initial values of the attributes of the DCO?. >> >> Learned from the DIO means: copied from last received DIO? >> >> DCOsequence is incremented but it is not clear what its initial value is (same for DCO-ACK) >> >> Suppose the K-flag is set and no ack arrives, after how long a period the sender does what? Under what conditions does the K-flag need to be set? >> >> Section 4.1 Are the dependent nodes the nodes in the subtree introduced in section 1.3? or only the children of the switching node? Thanks for the work, >> >> hope this helps. >> When you see that my suggestions are unrelated to the intended text, please consider rephrasing of the text, because the text is apparently unclear. >> >> Greetings, >> >> peter Links: ------ [1] https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template/ --=_46f1255f053090e2fd900572e1e759e6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Please find answers to responses and additional review of -06, later switch= ing to -07

Peter

Rahul Jadhav schreef op 2018-09-27 10:49:

Please find responses inline.
 
Thanks,
Rahul

On Thu, 6 Sep 2018 at 18:40, Peter van der Stok <stokcons@bbhmail.nl= > wrote:
[RJ] We have revisited all such instances and reworded to make the ter= minology consistent.
 
[RJ] We had a good discussion internally to check whether to use the n= ew terms you suggested. But we thought it might further complicate things a= nd deter readability. We have updated the terminology sections with few pre= viously un-explained terms and have revised wordings for sections 2 and 3= =2E

[pvds]The terminology is not a objective in itself. I think = the text has been much clarified. thanks.
BTW, sometimes it helps to i= ntroduce concepts and name them to make the text and ideas clearer.

In section 1.4; to which what subtree do you refer?
 
[RJ] We have added an explicit section "DCO with multiple preferred pa= rents" to make it explicit.
[pvds]see my review below
 
 
 
[RJ] In introduction section we have explicitly added text saying the = technique is applicable for storing MOP only.  
[pvds]That h= elped a lot.

3.1 How can transmission be tolerant to a link failure when the = link has disappeared completely or the node has been removed; some explanat= ion is needed here. It would help if the assumptions are listed: like there= is another path via ....
 
[RJ] Have reworded the para.
[pvds] I still don't get it; what ha= ppens when no packet at all passes through the link? The NPDAO will never r= each (B), (G), and (H) (your example), the DCO will reach (B) and (G); is t= hat the tolerance you mean?

In section 3.1, 3.2 and 3.3 it should not be necessary to repeat= what is written in section 2.1, 2.2 and 2.3, just a reference to the corre= sponding section will do.

[RJ] we have removed duplicate sentences and reworded section 2 heavil= y. 
[pvds]Quite nice.
Section 7 is rather short; I doubt that it will be accepted in this fo= rm.
There have been earlier comments on the insufficiency of the secur= ity considerations in RPL documents.

[Pvds]You may be inspired b= y RFC7733, RFC7416 and draft-richardson-roll-applicabi= lity-template-02 
_________________________= _________________________________________________________

Review npdao-06/-07

Hi co-author,

Thanks for this version that reads much more easily.

Please, give the full name at first appearance of the following terms.

RPL, 6LBR, 6LR; Otherwise someone from IESG will ask you to do so.

Common ancestor node: s/child node/target Node/

Section 1.1 which terms from RFC6550 are used. It is good practice to en= umerate them to help the reader, otherwise he wonders for each unknown term= where it comes from.

Section 1.2 end: s/BR/6LBR/ to align with earlier text and figure..

At the end of this section some text about multiple parents is helpful; = Do you exclude that possibility? Or does an additional set of parents (fore= seen in RFC6550) have no influence? I doubt it.

Just read version 07; section 4.4.3 is a statement that needs some expla= nation to be understood. Also an implementer needs some guidance on what to= do; send a NPDAO to all parents, probably not,? Do you need an additional = new parent? Send the DCO from all common ancestors on all paths?

Section 1.3 subtree switching example, suggested text is: needs to be do= ne for the routing table entries of (C), (H), (A), (G), and (B) with destin= ation (D), (E), and (F).

Section 2.2 suggested text:

There is no NPDAO generated by the child nodes (E) and (F), through the = previous path via (D) to (B) and (G), resulting…..

Section 2.3 s/from previous route may invalidate the existing/via previo= us route may invalidate the previous/

Sec 3.1 the title mentions “parents” (plural) where the earl= ier text only considers a single parent

Sec 4.1; How does a common ancestor know, it is a common ancestor? I am = not convinced that a node which has an old entry that specifies a different= route is still necessarily a common ancestor. That old path may pass throu= gh different nodes; not (G) and (H) to follow the example.

Sec 4.2 /specifies/specify/  ---plural options

Section 4.3 What are the initial values of the attributes of the DCO?.

Learned from the DIO means: copied from last received DIO?

DCOsequence is incremented but it is not clear what its initial value is= (same for DCO-ACK)

Suppose the K-flag is set and no ack arrives, after how long a period th= e sender does what? Under what conditions does the K-flag need to be set?

Section 4.1 Are the dependent nodes the nodes in the subtree introduced = in section 1.3? or only the children of the switching node?

Thanks for the work,

hope this helps.
When you see that my = suggestions are unrelated to the intended text, please consider rephrasing = of the text, because the text is apparently unclear.

 Greet= ings,

peter

 
--=_46f1255f053090e2fd900572e1e759e6-- From nobody Thu Sep 27 10:05:13 2018 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 022E5130EC7 for ; Thu, 27 Sep 2018 10:05:11 -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 gQ0YzyY0wMqk for ; Thu, 27 Sep 2018 10:05:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59993130E19 for ; Thu, 27 Sep 2018 10:05:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A21F20491; Thu, 27 Sep 2018 13:05:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7EDF11273; Thu, 27 Sep 2018 13:05:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7A53F471; Thu, 27 Sep 2018 13:05:08 -0400 (EDT) From: Michael Richardson To: "Georgios Z. Papadopoulos" CC: roll@ietf.org In-Reply-To: <69EA99AA-7F3A-454A-93D2-57787AA9415D@imt-atlantique.fr> References: <153358180422.26781.7855639877073942213@ietfa.amsl.com> <26711.1533595394@localhost> <69EA99AA-7F3A-454A-93D2-57787AA9415D@imt-atlantique.fr> 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] [6tisch] I-D Action: draft-richardson-6tisch-roll-enrollment-priority-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 17:05:11 -0000 <#secure method=3Dpgpmime mode=3Dsign> Georgios Z. Papadopoulos asked about a name conflict between my two documents. Namely, draft-richardson-6tisch-roll-enrollment-priority-01 it is defined as =E2=80=9Cmin. priority" while in draft-ietf-6tisch-enrollment-enhanced-beacon-00 as =E2=80=9Cproxy = priority=E2=80=9D. To put this question in better context, and to assure myself that this wasn= 't an issue due to uneven document editing/revision: draft-ietf-6tisch-enrollment-enhanced-beacon-00 says: | TBD-XXX |R| proxy prio. | rank priority | +-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+ | pan priority | | and is dated July 17, 2018. draft-richardson-6tisch-roll-enrollment-priority-01 says: 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D TBD01|Opt Length =3D 1|R| min. priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ min.priority a 7 bit field which provides a base value for the Enhanced Beacon Join priority. A value of 0x7f (127) disables the Join Proxy function entirely. and is dated August 6, 2018. The intent is that min. priority value would provide a floor value for the proxy prio. above. The local node would add to it based upon local conditions. Since 0x7f is the infinite value, if the DODAG root wants to turn off join by sending out 0x7f. We should change the name from min. priority to something like: Proxy Join Priority Base Value =3D=3D PJPBV ?? (Makes me think about Peanut Butter and Jelly sandwiches) Perhaps you can suggest better terms, but I don't think that the terms should be identical, because the value is not passed straight on. -- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- From nobody Thu Sep 27 21:37:30 2018 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 C923F1271FF for ; Thu, 27 Sep 2018 21:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whn1kzXlOmAL for ; Thu, 27 Sep 2018 21:37:26 -0700 (PDT) Received: from mail-vk1-xa44.google.com (mail-vk1-xa44.google.com [IPv6:2607:f8b0:4864:20::a44]) (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 619B7124C04 for ; Thu, 27 Sep 2018 21:37:26 -0700 (PDT) Received: by mail-vk1-xa44.google.com with SMTP id v136-v6so122642vke.0 for ; Thu, 27 Sep 2018 21:37:26 -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=+lCE9LcYGNdAu8o/qXOpO41iUA+NbShFQ7eFH8Nc/aY=; b=HfTOSAQLxa0P09026B9kOmCcsVjeoHLCzWT7lyERwDTyepvEovpydO3egwFqbNolS/ qMOwpemqyBs3WJqEkjafKAQXEBUJfhFxk6Svs2e9JY2A8nZ2b8JE/pISf+u0EdelMEJV sPGDAw8TJC4yAXMjUoOwjmShm/3xTIpPf1c8+BOD6F5R86SxieJsz2IIGHhPT5ynMrtb hzYS+GMMPO/a+hMNOhNcH+sB1/LVGJsegnROqXlmK+lfPF8j1qUnjM22lUFRDANG87MC Hmnyup4vYKrHEmZxnTRzv1bZ5CN706xLr5RLyJ+xh6QNv/vf3xINozzrOsyGE9TKwbR0 2qTQ== 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=+lCE9LcYGNdAu8o/qXOpO41iUA+NbShFQ7eFH8Nc/aY=; b=RL9ztexcgehMW/CzD3s9QoxzuuGC8gbBF1I0cBY4RrDxgRsBs28DsdEceuoQjQ/K8a 81YiM3wSg28XU2fPNDHHrjb6ygLRq0HcREV+cuhKLAxcro2/i9bwtZJE/IYRD0wpnLbQ QdXuBgnOKgNeTH2F9kYWg//iB4/YlLCf2lw7PU5Cc5nuQJWNkyguEDfmFoOMpU48JIk2 ayUdtg7tiKpE4UmTVTca0xX3cRux0T7OjVP13jSwPKEb+57oMNJp/mAvm8Nr5xG4qxfu y8y79h4jyRckVoEIrvW2oDvxFCp6b6vXyWl3Y/pCgWtbxondx7+/nMztvFLdR2jA6lRF eLtw== X-Gm-Message-State: ABuFfogdarEuYYadUQot7VXRXTxRtJUbqWjOGRKBH2qo9qn0WiD2F0Zh BY6t8FMoq0SBSzVKwbp7+l2E8pvhxNe3QJXVGlqLgEJj X-Google-Smtp-Source: ACcGV607UXcytNrO9CYqFzRZTq/PfdSxZ83ZnxkxB4b5e0jyayFybrptC2EF+Ioyq1XibqBCf6iJ+qlVL8gCNxvJD8k= X-Received: by 2002:a1f:2f01:: with SMTP id v1-v6mr4456823vkv.92.1538109445027; Thu, 27 Sep 2018 21:37:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rahul Jadhav Date: Fri, 28 Sep 2018 10:07:13 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="00000000000018bc3b0576e7032f" Archived-At: Subject: Re: [Roll] OMNeT++ code for RPL 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 Sep 2018 04:37:29 -0000 --00000000000018bc3b0576e7032f Content-Type: text/plain; charset="UTF-8" Hello Moussa, Is your goal to simulate RPL on 802.15.4/LoWPAN or in general IPv6 networks ? Simulating RPL over 802.15.4 in Omnet++ means you have to use either Castalia or Mixim along with Omnet++. Earlier we started work on Castalia but we had to abandon it because the license didn't allow us to use it (Omnet++ has Academic Public License,.. it will work just fine for you). Meanwhile (in 2016) we started working on an open-source framework which uses NS3 for wireless simulation and integrates contiki/riot. https://github.com/whitefield-framework/whitefield We have been using this framework for most of the work we do in IETF. The advantage of this framework is that you do not have to port RPL/6lo implementation to NS3 specifically for simulation, reducing experimentation time and you do not need to understand NS3 design to use it. The framework adds whitefield as a platform in contiki/riot. But there are advantages with regards to using Castalia/Mixim with Omnet++: Mixim supports 802.15.4A Impulse Radio Ultra Wide band standard in addition to the narrow band version. Castalia supports various 802.15.4 MAC layers including TMAC, SMAC which provides RDC (radio duty cycling). NS3 supports only vanilla 802154-2006 MAC layer in unslotted CSMA/CA mode (which is also supported by Castalia). Hope it helps. Best, Rahul On Thu, 27 Sep 2018 at 17:06, Moussa ABOUBAKAR wrote: > Dear all, > > I'm PhD student and I'm now working on routing scheme on Low power and > lossy network. > I'm now looking for the code of RPL on Omnet++ to start simulation. > Any help you can provide is welcome. > > Kinds regards, > > > -- > ABOUBAKAR Moussa > PhD student Computer Science > Twitter: abakamousa > https://www.linkedin.com/in/aboubakar-moussa > > Tel: +33 7 58 30 82 16 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00000000000018bc3b0576e7032f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Moussa,

Is your = goal to simulate RPL on 802.15.4/LoWPAN or in general IPv6 networks ?=C2=A0=
Simulating RPL over 802.15.4 in Omnet++ means you have to use ei= ther Castalia or Mixim along with Omnet++.=C2=A0
Earlier we start= ed work on Castalia but we had to abandon it because the license didn't= allow us to use it (Omnet++ has Academic Public License,.. it will work ju= st fine for you).

Meanwhile (in 2016) we started w= orking on an open-source framework which uses NS3 for wireless simulation a= nd integrates contiki/riot.
We have been using this framework for most of the work = we do in IETF. The advantage of this framework is that you do not have to p= ort RPL/6lo implementation to NS3 specifically for simulation, reducing exp= erimentation time and you do not need to understand NS3 design to use it. T= he framework adds whitefield as a platform in contiki/riot.

<= /div>
But there are advantages with regards to using Castalia/Mixim wit= h Omnet++:
Mixim supports 802.15.4A Impulse Radio Ultra Wide band= standard in addition to the narrow band version.
Castalia suppor= ts various 802.15.4 MAC layers including TMAC, SMAC which provides RDC (rad= io duty cycling).
NS3 supports only vanilla 802154-2006 MAC layer= in unslotted CSMA/CA mode (which is also supported by Castalia).

Hope it helps.

Best,
Rah= ul

On Thu,= 27 Sep 2018 at 17:06, Moussa ABOUBAKAR <abakamousa@gmail.com> wrote:
Dear all,

I'm= PhD student and I'm now working on routing scheme on Low power=C2=A0 a= nd lossy network.
I'm now looking for the code of RPL on Omnet++ to = start simulation.
Any help you can provide is welcome.

Kinds regards,


-= -
<= div dir=3D"ltr">
=
ABOUBAKAR Moussa
PhD student Computer Science=
Twitter: abakamousa
https://www.linkedin.com/in/aboubakar-moussa=C2= =A0
Tel: +33 7 58 30 82 16
=
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--00000000000018bc3b0576e7032f-- From nobody Fri Sep 28 02:50:35 2018 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 408F5130E6F for ; Fri, 28 Sep 2018 02:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tpwbHItyT1hs for ; Fri, 28 Sep 2018 02:50:25 -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 CE7AA130F58 for ; Fri, 28 Sep 2018 02:50:24 -0700 (PDT) Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 8B9AF2379 for ; Fri, 28 Sep 2018 11:50:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1538128221; bh=vPgrAvk5xz29OCdIJajGbxtCHCghQAdTXdmdjNcu19Q=; h=From:Date:Subject:To:From; b=kpgkeRNaVxUBjv92ph2sPcjFMTT2Q2CJSGV3e0EHsInDucL+hZm2N0BT7aHYIfGJs 1xyesEzX5prP8ZzEftpXSr8VuUdHj+/OstI5/fYFaagn9a33yOU0tqNfPz4Qfi8/6Q n+vdPIjOIS+DdIyInAM70lSgK4T06ARJshJmyTPYFomZ5iRtOuhHvwswcaxacvoQVm ilOccjNpbos0G6d0vdzsrgVInxJnmOkTv4FbsTxHwh65qVyYUfU0JHi9UCkwZOcFu/ fQOGc9d/hyyFA8cXB9WNp+04sF9SK3hfoNu9ygwQwqaD7ErDzra6owHLJuQ/3c92id lLjql0CVTlYjw== Received: from mail-it1-f176.google.com ([209.85.166.176]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Fri, 28 Sep 2018 11:50:17 +0200 (CEST) Received: by mail-it1-f176.google.com with SMTP id 139-v6so1899785itf.0 for ; Fri, 28 Sep 2018 02:50:17 -0700 (PDT) X-Gm-Message-State: ABuFfojSE2jL2krkI8MstWEiMh7yJsUUVP16z5syNuBzzwgdeOZX6vZ+ ewVw+si5CkkWPm4fd7/9DYt42eNTkv6EyCgyDZY= X-Google-Smtp-Source: ACcGV62BMPuG+Q93EWyf2t727DzAiakLysYB5byfPBQnV2aQelY73CYxUgEvMLoMTB9J3usqsU4yfpORLeSStE9KrDA= X-Received: by 2002:a24:fa0a:: with SMTP id v10-v6mr940148ith.109.1538128216394; Fri, 28 Sep 2018 02:50:16 -0700 (PDT) MIME-Version: 1.0 From: Remous-Aris Koutsiamanis Date: Fri, 28 Sep 2018 11:50:19 +0200 (CEST) X-Gmail-Original-Message-ID: Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000f516140576eb6194" X-ContactOffice-Account: com:113819248 Archived-At: Subject: [Roll] Throughput Metric in RFC 6551 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 Sep 2018 09:50:34 -0000 --000000000000f516140576eb6194 Content-Type: text/plain; charset="UTF-8" Hello, I would like some clarification on the the Throughput metric in RFC 6551. The text has a first segment which states: "For efficient operation, it may be desirable for nodes to report the range of throughput that their links can handle in addition to the currently available throughput." and then a bit later: "The first Throughput sub-object MUST be the most recently estimated actual throughput" The first segment refers to "currently available throughput", which I understand as the currently remaining traffic capacity. E.g. the node has a total traffic capacity of 10 pkt/s (e.g. for sending towards the root), it is currently having traffic of 3 pkt/s, so the remaining=available throughput is 10-3=7pkt/s. The second segment segment on the contrary seems to refer to the current "actual throughput" on the node; in the previous example, this would be the 3pkt/s value. How should the metric be used and which of the values should it contain? Cordially, Aris --000000000000f516140576eb6194 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I would like some clarification on the the T= hroughput metric in RFC 6551.
The text has a first segment which states:=
"For efficient ope= ration, it may be desirable for nodes to report the range of throughput
= that their links can handle in addition to the currently available throughp= ut."

and then a bit later:
"The first Throughput sub-object MUST be the mo= st recently estimated actual throughput"

The first segme= nt refers to "currently available throughput", which I understand= as the currently remaining traffic capacity.
E.g. the node has a total= traffic capacity of 10 pkt/s (e.g. for sending towards the root), it is cu= rrently having traffic of 3 pkt/s, so the remaining=3Davailable throughput = is 10-3=3D7pkt/s.

The second segment segment on the contrary seems t= o refer to the current "actual throughput" on the node; in the pr= evious example, this would be the 3pkt/s value.

How should the metri= c be used and which of the values should it contain?

Cordially,
<= br>Aris
--000000000000f516140576eb6194-- From nobody Sun Sep 30 22:00:44 2018 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 80D98128B14; Sun, 30 Sep 2018 22:00:36 -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.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <153837003649.13311.11386674957801418863@ietfa.amsl.com> Date: Sun, 30 Sep 2018 22:00:36 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-efficient-npdao-08.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 Oct 2018 05:00:37 -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-08.txt Pages : 17 Date : 2018-09-30 Abstract: This document describes the problems associated with NPDAO messaging used in 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-roll-efficient-npdao-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-efficient-npdao-08 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 Sep 30 22:07:59 2018 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 90B0D128CE4; Sun, 30 Sep 2018 22:07:58 -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_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 IxrFWkGQbeaL; Sun, 30 Sep 2018 22:07:55 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 EFA83127AC2; Sun, 30 Sep 2018 22:07:54 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id z130-v6so6746899vsc.7; Sun, 30 Sep 2018 22:07:54 -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 :cc; bh=ayYCaizBEjKPWc8abTQb32NqSyslU4bw3Wz8x1l4zEU=; b=WgmwhZQoCJcW1jSVbbC+xy2SAevVYaAOawBRjmQrZQt1Da/3Nostu5QdsCx5MC48KB dJ7Aow2P7PaoQzakoPsIjdKwh3gLcC4ZFeD1CAJ+K9TolGOkySpgupOzIf0RlJVtUWWm fuGpqycs7q1UTXw1QMfe4BvX3XkpxoMpYjCVeaJUbWJLoHEByqpISy5DVy/MetQxG8N6 4QCiRZhU1JCEzbhE3s5yZlTpnqsKwrrriskMNNi0ohbtIOM3z6LCgCBPXp+MfkO82EHG tZQP86PAxauSQFDrqR6hV6MLZVzuK1yk82RvbtECb93vYydmwDgKacSQDUtjzaeJmTtB wxLA== 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=ayYCaizBEjKPWc8abTQb32NqSyslU4bw3Wz8x1l4zEU=; b=KywDGc+gpEbxoj3F9ROIxwuS8rmrRpV/QW4BeWqfGXvHL59wWVjBoIgIL52y0neMFh XxuGzxW1odhAZ/dgp1OJZzIxqEjgYnfUAHWobsOg2Moh+T40SJkrRVc+yrO1Kf6Z4ylC 3U6quQOgsl7zTTa5l5MCC7P0gof0g+0khbI/qhmgW37cC0xhBmzi+e9bIJ7ZxqDsQodc 1weIUiT9mqUOKo5dEa4cp9yY0XkvaK/sEmE55HnuYQoAdoBI5rh/tq3oXoeIbJ5ZmORz ccBZpS1+EkWA65/sTlplJEL3ntUUanCBO6NKpzYQ+dOkFQ7I0HBL8cQJfaRYXAHvP4uF HSNA== X-Gm-Message-State: ABuFfoi+KPlZou39v07KuDPU8ua+H2QszzXm1I87fpSWCChGbPAGbNT7 H9KB9v40uRl7WyNfDXd1ZLH8J7YMEvoQ9s9Sou1DdA== X-Google-Smtp-Source: ACcGV62PwT5bi1PSla/2ypNH1rYSfW6/U71TwvFPRJOGmP8VrFVtpdcqI7fqqNHP18f9kYtZvnKH1Ya6W9Z4Hw/9a90= X-Received: by 2002:a67:e114:: with SMTP id d20-v6mr3216652vsl.170.1538370473883; Sun, 30 Sep 2018 22:07:53 -0700 (PDT) MIME-Version: 1.0 References: <65ac8a93279212d8757d1ecf24ac9e42@bbhmail.nl> <2b26f398a3ebd41b32cf46aa7f328603@bbhmail.nl> In-Reply-To: <2b26f398a3ebd41b32cf46aa7f328603@bbhmail.nl> From: Rahul Jadhav Date: Mon, 1 Oct 2018 10:37:42 +0530 Message-ID: To: "consultancy@vanderstok.org" Cc: draft-ietf-roll-efficient-npdao@ietf.org, Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000a0fde1057723c9c5" Archived-At: Subject: Re: [Roll] draft-ietf-roll-efficient-npdao review 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 Oct 2018 05:07:59 -0000 --000000000000a0fde1057723c9c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Peter for the thorough review. Updates in -08: 1. Section 4.4.3 (DCO with multiple preferred parent) is updated with more detailed text. Also an example DCO messaging for multiple preferred parents is added in the Appendix section (A.2). 2. DCO, DCO-ACK initial values for DCOSequence is updated. Handling of DCO-ACK failure explained. 3. Security considerations Please find responses inline.. Thanks, Rahul On Thu, 27 Sep 2018 at 18:42, Peter van der Stok wrote: > Please find answers to responses and additional review of -06, later > switching to -07 > > Peter > > Rahul Jadhav schreef op 2018-09-27 10:49: > > Please find responses inline. > > Thanks, > Rahul > > On Thu, 6 Sep 2018 at 18:40, Peter van der Stok > wrote: > [RJ] We have revisited all such instances and reworded to make the > terminology consistent. > > > [RJ] We had a good discussion internally to check whether to use the new > terms you suggested. But we thought it might further complicate things an= d > deter readability. We have updated the terminology sections with few > previously un-explained terms and have revised wordings for sections 2 an= d > 3. > > [pvds]The terminology is not a objective in itself. I think the text has > been much clarified. thanks. > BTW, sometimes it helps to introduce concepts and name them to make the > text and ideas clearer. > > [RJ]: We have added definitions of 6LBR, 6LR DODAG, DAG in the terminolog= y section. Some of it we duplicated from 6550 so as to help the reader. > >> In section 1.4; to which what subtree do you refer? >> > > [RJ] We have added an explicit section "DCO with multiple preferred > parents" to make it explicit. > [pvds]see my review below > > >> >> > > [RJ] In introduction section we have explicitly added text saying the > technique is applicable for storing MOP only. > [pvds]That helped a lot. > >> >> 3.1 How can transmission be tolerant to a link failure when the link has >> disappeared completely or the node has been removed; some explanation is >> needed here. It would help if the assumptions are listed: like there is >> another path via .... >> > > [RJ] Have reworded the para. > [pvds] I still don't get it; what happens when no packet at all passes > through the link? The NPDAO will never reach (B), (G), and (H) (your > example), the DCO will reach (B) and (G); is that the tolerance you mean? > > [RJ] Yes. The new mechanism does not depend on previous route link failures and thus is tolerant. That is what was meant. We have changed the title of the section since it sounded confusing (especially the term tolerant). Thank you for pointing it. Please check if the new title and section rewording makes sense. >> In section 3.1, 3.2 and 3.3 it should not be necessary to repeat what is >> written in section 2.1, 2.2 and 2.3, just a reference to the correspondi= ng >> section will do. >> >> [RJ] we have removed duplicate sentences and reworded section 2 heavily. > [pvds]Quite nice. > >> Section 7 is rather short; I doubt that it will be accepted in this form= . >> There have been earlier comments on the insufficiency of the security >> considerations in RPL documents. >> >> [Pvds]You may be inspired by RFC7733, RFC7416 and >> draft-richardson-roll-applicability-template-02 >> >> >> > [RJ] We have updated security considerations based on security considerations from RFC 6550. I have also gone through 7733, 7416 and the applicability template for inspiration. I think the applicability documents security considerations are much different and it talks about key provisioning/management which i feel are irrelevant for DCO, DCO-ACK. We have explained the use of secure messaging in Preinstalled/Authenticated/Unsecured security modes of 6550 for DCO, DCO-ACK. > >> ________________________________________________________________________= __________ >> >> Review npdao-06/-07 >> >> Hi co-author, >> >> Thanks for this version that reads much more easily. >> >> Please, give the full name at first appearance of the following terms. >> >> RPL, 6LBR, 6LR; Otherwise someone from IESG will ask you to do so. >> > [RJ] Updated all acronyms regardless of whether they are from base specification or not,, to improve readability and completeness. > Common ancestor node: s/child node/target Node/ >> > [RJ] Fixed > Section 1.1 which terms from RFC6550 are used. It is good practice to >> enumerate them to help the reader, otherwise he wonders for each unknown >> term where it comes from. >> > [RJ] Have enumerated certain terms from 6550 such as DODAG, DAG, 6LBR, 6L= R for improving readability. > Section 1.2 end: s/BR/6LBR/ to align with earlier text and figure.. >> > [RJ] Fixed. > At the end of this section some text about multiple parents is helpful; D= o >> you exclude that possibility? Or does an additional set of parents >> (foreseen in RFC6550) have no influence? I doubt it. >> >> Just read version 07; section 4.4.3 is a statement that needs some >> explanation to be understood. Also an implementer needs some guidance on >> what to do; send a NPDAO to all parents, probably not,? Do you need an >> additional new parent? Send the DCO from all common ancestors on all pat= hs? >> > [RJ] There has been a major text update for this. Section 4.4.3 is update= d and an example DCO signalling for multiple preferred parents is added in appendix (A.2). > Section 1.3 subtree switching example, suggested text is: needs to be don= e >> for the routing table entries of (C), (H), (A), (G), and (B) with >> destination (D), (E), and (F). >> > [RJ] Fixed. > Section 2.2 suggested text: >> >> There is no NPDAO generated by the child nodes (E) and (F), through the >> previous path via (D) to (B) and (G), resulting=E2=80=A6.. >> > [RJ] Fixed. > Section 2.3 s/from previous route may invalidate the existing/via previou= s >> route may invalidate the previous/ >> > [RJ] Fixed. > Sec 3.1 the title mentions =E2=80=9Cparents=E2=80=9D (plural) where the e= arlier text only >> considers a single parent >> > [RJ] Fixed. > Sec 4.1; How does a common ancestor know, it is a common ancestor? I am >> not convinced that a node which has an old entry that specifies a differ= ent >> route is still necessarily a common ancestor. That old path may pass >> through different nodes; not (G) and (H) to follow the example. >> > [RJ] A node which has an old entry that specifies a different route and has received an updated DAO ... essentially means it is a common ancestor. If there is any old path, it requires invalidation nonetheless. > Sec 4.2 /specifies/specify/ ---plural options >> > [RJ] Fixed > Section 4.3 What are the initial values of the attributes of the DCO?. >> > [RJ] Have updated DCOSequence initial value consideration. Also for DCO-ACK the DCOSequence needs to be copied from DCO message. The text has been updated. > Learned from the DIO means: copied from last received DIO? >> > [RJ] Yes. We have tried using the same statements as with DAO messages in 6550. > DCOsequence is incremented but it is not clear what its initial value is >> (same for DCO-ACK) >> > [RJ] Fixed as mentioned above > Suppose the K-flag is set and no ack arrives, after how long a period the >> sender does what? Under what conditions does the K-flag need to be set? >> > [RJ] Have added K-flag handling in the signalling section. > Section 4.1 Are the dependent nodes the nodes in the subtree introduced i= n >> section 1.3? or only the children of the switching node? >> > [RJ] Sorry but I didn't understand this. There is no reference to dependent nodes or child nodes in section 4.1. Thanks for the work, >> > [RJ] Thank you for the thorough review. --000000000000a0fde1057723c9c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Peter for the thorough review.

Updates in -08:
1. Section 4.4.3 (DCO with multiple preferred p= arent) is updated with more detailed text. Also an example DCO messaging fo= r multiple preferred parents is added in the Appendix section (A.2).
<= div>2. DCO, DCO-ACK initial values for DCOSequence is updated. Handling of = DCO-ACK failure explained.
3. Security considerations
<= br>
Please find responses inline..

Thank= s,
Rahul

On = Thu, 27 Sep 2018 at 18:42, Peter van der Stok <stokcons@bbhmail.nl> wrote:
Please find answers to responses and additional review of -06, later switch= ing to -07

Peter

Rahul Jadhav schreef op 2018-09-27 10:49:

Please find responses inline.
=C2=A0
Thanks,
Rahul

On Thu, 6 Sep 2018 at 18:40, Peter van der Stok <stokc= ons@bbhmail.nl> wrote:
[RJ] We have revisited all such instances and reworded to make the ter= minology consistent.
=C2=A0
[RJ] We had a good discussion internally to check whether to use the n= ew terms you suggested. But we thought it might further complicate things a= nd deter readability. We have updated the terminology sections with few pre= viously un-explained terms and have revised wordings for sections 2 and 3.<= br>
[pvds]The terminology is not a objective in itself. I think the text= has been much clarified. thanks.
BTW, sometimes it helps to introduce c= oncepts and name them to make the text and ideas clearer.
=
[RJ]: We have added definitions of 6LB= R, 6LR DODAG, DAG in the terminology section. Some of it we duplicated from= 6550 so as to=C2=A0 help the reader.
=C2=A0

In section 1.4; to which what subtree do you refer?
=C2=A0
[RJ] We have added an explicit section "DCO with multiple preferr= ed parents" to make it explicit.
[pvds]see my review below
=C2=A0
=C2=A0
=C2=A0
[RJ] In introduction section we have explicitly added text saying the = technique is applicable for storing MOP only.=C2=A0=C2=A0
[pvds]That hel= ped a lot.

3.1 How can transmission be tolerant to a link failure when the li= nk has disappeared completely or the node has been removed; some explanatio= n is needed here. It would help if the assumptions are listed: like there i= s another path via ....
=C2=A0
[RJ] Have reworded the para.
[pvds] I still don't get it; what = happens when no packet at all passes through the link? The NPDAO will never= reach (B), (G), and (H) (your example), the DCO will reach (B) and (G); is= that the tolerance you mean?

[RJ]=C2=A0 Yes. The new mechanism does not depend o= n previous route link failures and thus is tolerant. That is what was meant= .
We have changed the title of the section since it sounded c= onfusing (especially the term tolerant). Thank you for pointing it. Please = check if the new title and section rewording makes sense.


In section 3.1, 3.2 and 3.3 it should not be necessary to repeat w= hat is written in section 2.1, 2.2 and 2.3, just a reference to the corresp= onding section will do.

[RJ] we have removed duplicate sentences and reworded section 2 heavil= y.=C2=A0
[pvds]Quite nice.
Section 7 is rather short; I doubt that it will be accepted in this fo= rm.
There have been earlier comments on the insufficiency of the securit= y considerations in RPL documents.

[Pvds]You may be inspired by RFC7= 733, RFC7416 and=C2=A0draft-richardson-ro= ll-applicability-template-02=C2=A0
<= /span>
=

[RJ] We have updated security considerations based on s= ecurity considerations from RFC 6550. I have also gone through 7733, 7416 a= nd the applicability template for inspiration. I think the applicability do= cuments security considerations are much different and it talks about key p= rovisioning/management which i feel are irrelevant for DCO, DCO-ACK. We hav= e explained the use of secure messaging in Preinstalled/Authenticated/Unsec= ured security modes of 6550 for DCO, DCO-ACK.
=C2=A0
=
____________________________________________________= ______________________________

Review npdao-06/-07

Hi co-author,

Thanks for this version that reads much more easily.

Please, give the full name at first appearance of the following terms.

RPL, 6LBR, 6LR; Otherwise someone from IESG will ask you to do so.

[RJ= ] Updated all acronyms regardless of whether they are from base specificati= on or not,, to improve readability=C2=A0 and completeness.

Common ancestor node: s/child node/target Node/

[RJ] Fixed=C2=A0
=

Section 1.1 which terms from RFC6550 are used. It is good practice to en= umerate them to help the reader, otherwise he wonders for each unknown term= where it comes from.

=
[RJ] Have enumerated certain terms from 6550 such a= s DODAG, DAG, 6LBR, 6LR for improving readability.=C2=A0
<= div class=3D"gmail_quote">

Section 1.2 end: s/BR/6LBR/ to align with earlier text and figure..

<= /div>
[R= J] Fixed.=C2=A0

At the end of this section some text about multiple parents is helpful; = Do you exclude that possibility? Or does an additional set of parents (fore= seen in RFC6550) have no influence? I doubt it.

Just read version 07; section 4.4.3 is a statement that needs some expla= nation to be understood. Also an implementer needs some guidance on what to= do; send a NPDAO to all parents, probably not,? Do you need an additional = new parent? Send the DCO from all common ancestors on all paths?

<= /div>
[RJ] The= re has been a major text update for this. Section 4.4.3 is updated and an e= xample DCO signalling for multiple preferred parents is added in appendix (= A.2).

Section 1.3 subtree switching example, suggested text is: needs to be do= ne for the routing table entries of (C), (H), (A), (G), and (B) with destin= ation (D), (E), and (F).

[RJ] Fixed.=C2=A0

Section 2.2 suggested text:

There is no NPDAO generated by the child nodes (E) and (F), through the = previous path via (D) to (B) and (G), resulting=E2=80=A6..

<= /blockquote>
[RJ] Fixed.=C2= =A0

Section 2.3 s/from previous route may invalidate the existing/via previo= us route may invalidate the previous/

[RJ] Fixed.=C2=A0
=

Sec 3.1 the title mentions =E2=80=9Cparents=E2=80=9D (plural) where the = earlier text only considers a single parent

[RJ] Fixed.=C2=A0

Sec 4.1; How does a common ancestor know, it is a common ancestor? I am = not convinced that a node which has an old entry that specifies a different= route is still necessarily a common ancestor. That old path may pass throu= gh different nodes; not (G) and (H) to follow the example.

<= /blockquote>
[RJ] A node wh= ich has an old entry that specifies a different route and has received an u= pdated DAO ... essentially means it is a common ancestor. If there is any o= ld path, it requires invalidation nonetheless.=C2=A0=C2=A0

Sec 4.2 /specifies/specify/=C2=A0 ---plural options

[RJ] Fixed=C2=A0
<= div dir=3D"ltr">

Section 4.3 What are the initial values of the attributes of the DCO?.

[RJ] Have updated DCOSequence initial value consideration. Also for DCO-AC= K the DCOSequence needs to be copied from DCO message. The text has been up= dated.=C2=A0=C2=A0
<= div style=3D"font-size:10pt;font-family:Verdana,Geneva,sans-serif">

Learned from the DIO means: copied from last received DIO?

[RJ] Yes. W= e have tried using the same statements as with DAO messages in 6550.=C2=A0<= /div>
=

DCOsequence is incremented but it is not clear what its initial value is= (same for DCO-ACK)

[RJ] Fixed as mentioned above=C2=A0
=

Suppose the K-flag is set and no ack arrives, after how long a period th= e sender does what? Under what conditions does the K-flag need to be set?

[RJ] Have added K-flag handling in the signalling section.=C2=A0

Section 4.1 Are the dependent nodes the nodes in the subtree introduced = in section 1.3? or only the children of the switching node?

=
[RJ]=C2=A0 So= rry but I didn't understand this. There is no reference to dependent no= des or child nodes in section 4.1.=C2=A0

=
Thanks for the work,
<= /div>

[RJ] Thank you for the thorough revie= w.
--000000000000a0fde1057723c9c5--