From nobody Wed Jul 1 09:30:22 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CB31A90DD; Wed, 1 Jul 2015 09:30:21 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qAfe3hTNQEA; Wed, 1 Jul 2015 09:30:20 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34E51A7030; Wed, 1 Jul 2015 09:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5826; q=dns/txt; s=iport; t=1435768219; x=1436977819; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=yDPy81sbsLNj8vMioaNVHVEQ03AtpwrXrSgQmrWbf48=; b=mspMmG3azfd8OfQGYaibMyejPnDVFJgLh2C/8tn+W5G+NAvI0iKBFJXs 8MUFTyo2+q9AtsMtRYSacUjWWxxvClincqEpRhwIjQpJ5owTVIn6uvl2K BJeOHdfuVtwNj2a4TIyMG6+NsVuvWXVmMU6vh2wlS0S+73R/nXGMeKMCu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AIBAAhFZRV/4YNJK1bgxFUXwaDGboQCYFkCoV4HoE4OBQBAQEBAQEBgQqEIwEBBAEBATE6CxIBCBgEKAQlCycEAQ0FiC8NmFCdEQaWfQEBAQEBAQEBAQEBAQEBAQEBAQEVBIEbii+EOxgzgmmBSQWRLoJiAYtggTqEFIpziAMmg3pvgUaBAgEBAQ X-IronPort-AV: E=Sophos;i="5.15,386,1432598400"; d="scan'208";a="164703150" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2015 16:30:18 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t61GUINZ002911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 16:30:18 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.106]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 11:30:18 -0500 From: "Alvaro Retana (aretana)" To: Yusuke DOI , "draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org" Thread-Topic: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration Thread-Index: AQHQtBs3LC0iFpiKQ0qg/P9swhcNUg== Date: Wed, 1 Jul 2015 16:30:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="euc-kr" Content-ID: <87FFAF0393D6C543AF664904B72C5333@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "roll-chairs@ietf.org" , Routing Over Low power and Lossy networks , Ines Robles Subject: Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 16:30:21 -0000 WXVzdWtlOg0KDQpIaSEgIA0KDQpJIGRpZG6hr3Qgc2VlIGEgZm9sbG93IHVwIGZyb20geW91LCBi dXQgSaGvbSBhc3N1bWluZyB0aGF0IHdloa9yZSBvbiB0aGUgc2FtZQ0KcGFnZS4NCg0KVGhpcyBk cmFmdCBpcyBvbiB0aGUgYWdlbmRhIGZvciBkaXNjdXNzaW9uIGluIHRoZSBJRVNHIG5leHQgd2Vl ayAoSnVseS85KS4NCiBUaGUgSUVURiBMYXN0IENhbGwgaGFzIGVuZGVkLCBhbmQgdGhlcmUgYXJl IG91dHN0YW5kaW5nIGNvbW1lbnRzIChtaW5vcg0KYW5kIG5pdHMpIGZyb20gSUFOQSwgU2VjRGly IGFuZCBHZW5BUlQuDQoNClBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgY29tbWVudHMgYW5kIHBv c3QgYW4gdXBkYXRlIGJlZm9yZSBuZXh0IHdlZWsuDQpUaGUgc29vbmVyIHRoZSBiZXR0ZXIgdG8g Z2l2ZSB0aGUgSUVTRyBhIGdvb2QgY2hhbmNlIHRvIHJldmlldyB0aGUgbGF0ZXN0DQp0ZXh0Lg0K DQpUaGFua3MhDQoNCkFsdmFyby4NCg0KDQoNCk9uIDYvMTgvMTUsIDE6NDkgUE0sICJSb2xsIG9u IGJlaGFsZiBvZiBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSINCjxyb2xsLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIGFyZXRhbmFAY2lzY28uY29tPiB3cm90ZToNCg0KPk9uIDYvMTcvMTUs IDE6NDMgUE0sICJZdXN1a2UgRE9JIiA8eXVzdWtlLmRvaUB0b3NoaWJhLmNvLmpwPiB3cm90ZToN Cj4NCj5ZdXN1a2U6DQo+DQo+SGkhDQo+DQo+LiAuIC4NCj4+PiBNaW5vcjoNCj4+Pg0KPj4+ICAx LiBTZWN0aW9uIDEgKEludHJvZHVjdGlvbik6ICJTb21lIG1hbmFnZWQgd2lyZWxlc3MgbWVzaCBu ZXR3b3JrcyBtYXkNCj4+PiAgICAgaGF2ZSBhIERIQ1Agc2VydmVyIHRvIGNvbmZpZ3VyZSBuZXR3 b3JrIHBhcmFtZXRlcnMuqfcgIEhvdyBjb21tb24gaXMNCj4+PiAgICAgdGhlIHVzZSBvZiBESENQ PyAgqfhTb21lLi5tYXmp9yBkb2Vzbqn2dCBzb3VuZCBsaWtlIHRoaXMgZXh0ZW5zaW9uDQo+Pj53 aWxsDQo+Pj4gICAgIGJlIHVzZWQgYSBsb3QuICBIb3cgZG8gb3RoZXIgbmV0d29ya3MgY29uZmln dXJlIHRoZWlyIHBhcmFtZXRlcnM/DQo+Pj4gICAgICAgSan2bSBhc3N1bWluZyBtYW51YWxseS4u DQo+Pg0KPj5JIGhhdmUgbm8gb3RoZXIgZXhwZXJpZW5jZSwgYnV0IEkgYXNzdW1lIHRoZSBjb25m aWd1cmF0aW9uIHdpbGwgYmUgZG9uZQ0KPj5tYW51YWxseS4uLg0KPi4gLiAuDQo+Pg0KPj4+ICAz LiBTZWN0aW9uIDIuMyAoTVBMIEZvcndhcmRlciBCZWhhdmlvcikgIEpvaW5pbmcgYW5kIGxlYXZp bmcgdGhlDQo+Pj4gICAgIGRvbWFpbi4gIEkgbXVzdCBiZSBtaXNzaW5nIHNvbWV0aGluZy4uDQo+ Pj4gICAgICAgKiAidGhlIG5vZGUgTUFZIGpvaW4gdGhlIE1QTCBkb21haW4gZ2l2ZW4gYnkgdGhl IG9wdGlvbqn3ICBXaHkNCj4+PiAgICAgICAgIHdvdWxkIHRoZSBjbGllbnQgcmVxdWVzdCB0aGUg T3B0aW9uIGFuZCB0aGVuIG5vdCBqb2luIHRoZQ0KPj4+ZG9tYWluPw0KPj4NCj4+T25lIHJlYXNv biBpcyByZXNvdXJjZSBjb25zdHJhaW50LiBBcyBqb2luaW5nIHRvIGEgTVBMIGRvbWFpbiByZXF1 aXJlcw0KPj5jZXJ0YWluIGFtb3VudCBvZiBidWZmZXJzIGFsbG9jYXRlZCwgYSBub2RlIG1heSBm YWlsIHRvIGpvaW4gYWxsIG9mIHRoZQ0KPj5kb21haW5zIGdpdmVuIGJ5IHRoZSBvcHRpb24uDQo+ DQo+VGhlIHVzZSBvZiCp+E1BWan3IGFib3ZlIGdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQgam9p bmluZyBpcyBvcHRpb25hbC4gIEJ1dA0KPnlvdan2cmUgc2F5aW5nIHRoYXQgZXZlbiBpZiB0aGUg bm9kZSB3YW50cyB0byBqb2luIGl0IG1heSBub3QgYmUgYWJsZSB0bywNCj53aGljaCBpcyBkaWZm ZXJlbnQuDQo+DQo+U3VnZ2VzdGlvbjoNCj4NCj5PTEQ+DQo+DQo+ICAgSWYgYSBESENQdjYgY2xp ZW50IHJlcXVlc3RzIGFuZCByZWNlaXZlcyBNUEwgUGFyYW1ldGVyIENvbmZpZ3VyYXRpb24NCj4g ICBPcHRpb24sIHRoZSBub2RlIE1BWSBqb2luIHRoZSBNUEwgZG9tYWluIGdpdmVuIGJ5IHRoZSBv cHRpb24gYW5kIGFjdA0KPiAgIGFzIGFuIE1QTCBmb3J3YXJkZXIuDQo+DQo+DQo+TkVXPg0KPg0K PiAgIElmIGEgREhDUHY2IGNsaWVudCByZXF1ZXN0cyBhbmQgcmVjZWl2ZXMgTVBMIFBhcmFtZXRl ciBDb25maWd1cmF0aW9uDQo+ICAgT3B0aW9uLCB0aGUgbm9kZSBTSE9VTEQgam9pbiB0aGUgTVBM IGRvbWFpbiBnaXZlbiBieSB0aGUgb3B0aW9uIGFuZCBhY3QNCj4gICBhcyBhbiBNUEwgZm9yd2Fy ZGVyLiAgTm90ZSB0aGF0IHRoZXJlIG1heSBiZSBjYXNlcyBpbiB3aGljaCBhIG5vZGUgbWF5DQo+ ICAgZmFpbCBpcyB0byBqb2luIGEgZG9tYWluIChvciBkb21haW5zKSBkdWUgdG8gbG9jYWwgcmVz b3VyY2UNCj5jb25zdHJhaW50cy4NCj4NCj5JqfZtIG5vdCBzdXJlIGlmIHlvdS90aGUgV0cgd2Fu dCB0byBhZGQgc29tZXRoaW5nIGVsc2UgdG8gdGhhdCBwYXJhZ3JhcGguLg0KPg0KPg0KPg0KPj4+ ICAgICAgICogIkEgbm9kZSBNQVkgbGVhdmUgZnJvbSBhbiBNUEwgZG9tYWluLi6p9yAgVGhlIGNv bmRpdGlvbnMgc2VlbSB0bw0KPj4+ICAgICAgICAgc2F5IHRoYXQgdGhlIGRvbWFpbiBpbiB0aGUg T3B0aW9uIGNoYW5nZWQsIGlzIHRoYXQgdHJ1ZT8gIElmDQo+Pj50aGUNCj4+PiAgICAgICAgIGRv bWFpbiBpbiB0aGUgb3B0aW9uIGNoYW5nZWQsIHdoeSB3b3VsZCB0aGUgbm9kZSBub3QgbGVhdmUg dGhlDQo+Pj4gICAgICAgICBkb21haW4/DQo+Pg0KPj5UaGVyZSdzIG5vIHJlYXNvbiBleGNlcHQg dGhlIGRvbWFpbiBpcyBjb25maWd1cmVkIG1hbnVhbGx5IGF0IHRoZSBzYW1lDQo+PnRpbWUgKHRo ZSBmaXJzdCBjb25kaXRpb24gaXMgbm90IG1ldCkuIElmIHRoZXJlIGFyZSBhIG1hbnVhbA0KPj5j b25maWd1cmF0aW9uLCBpbXBsZW1lbnRhdGlvbiBtYXkgY29uc2lkZXIgaXQncyBvdmVycmlkaW5n IHRoZSBESENQdjYNCj4+T3B0aW9uLg0KPj4NCj4+SXMgdGhpcyBjbGVhcj86DQo+Pg0KPj4iIiIN Cj4+QSBub2RlIFNIT1VMRCBsZWF2ZSBmcm9tIGEgTVBMIGRvbWFpbiBpZiB0aGUgbm9kZSByZWNl aXZlZCBhIG5ldyBvcHRpb24NCj4+d2l0aG91dCBjb25maWd1cmF0aW9uIGZvciB0aGUgTVBMIGRv bWFpbiwgdW5sZXNzIGl0IGhhcyBvdmVycmlkaW5nDQo+PmV4dGVybmFsIGNvbmZpZ3VyYXRpb24g b24gdGhlIE1QTCBkb21haW4uDQo+PiIiIg0KPg0KPkhvdyBhYm91dCB0aGlzIGluc3RlYWQ6DQo+ DQo+TkVXPg0KPg0KPiAgIEEgbm9kZSBTSE9VTEQgbGVhdmUgYW4gTVBMIGRvbWFpbiBpZiBpdCBy ZWNlaXZlcyBhbiB1cGRhdGVkDQo+ICAgTVBMIFBhcmFtZXRlciBDb25maWd1cmF0aW9uIE9wdGlv biB3aXRob3V0IGEgY29uZmlndXJhdGlvbiBmb3IgdGhlDQo+ICAgTVBMIGRvbWFpbiwgdW5sZXNz IGl0IGhhcyBvdmVycmlkaW5nIGV4dGVybmFsIGNvbmZpZ3VyYXRpb24uDQo+DQo+DQo+San2bSBu b3Qgc3VyZSBpZiCp+GV4dGVybmFsqfcgaXMgdGhlIHJpZ2h0IHdvcmQuLm9yIGlmIKn4bWFudWFs qfcgbWlnaHQgYmUNCj5iZXR0ZXIuICBMb29rIGF0IHRoZSBwb2ludCAjMSBhYm92ZSBhYm91dCBo b3cgb3RoZXIgbm9kZXMgbWF5IGJlDQo+Y29uZmlndXJlZC4NCj4NCj5JbiB0aGlzIHNlY3Rpb24g KDIuMykgdGhlcmWp9nMgYSBwcmlvcml0eSBvZiBjb25maWd1cmF0aW9uIHNob3duOg0KPg0KPiAg IFRoZSBwcmlvcml0eSBvZiBNUEwgUGFyYW1ldGVyIENvbmZpZ3VyYXRpb24gYXBwbGllZCBmb3Ig YW4gTVBMIERvbWFpbg0KPiAgIGlzIGFzIGZvbGxvd3MgKGhpZ2ggdG8gbG93KS4NCj4NCj4gICBv ICBTcGVjaWZpYyBNUEwgUGFyYW1ldGVyIENvbmZpZ3VyYXRpb24gdG8gdGhlIE1QTCBEb21haW4g KG9wdGxlbj0zNCkNCj4NCj4gICBvICBXaWxkY2FyZCBNUEwgUGFyYW1ldGVyIENvbmZpZ3VyYXRp b24gKG9wdGxlbj0xOCkNCj4NCj4gICBvICBEZWZhdWx0IGNvbmZpZ3VyYXRpb24gZ2l2ZW4gaW4g dGhlIE1QTCBzcGVjaWZpY2F0aW9uLg0KPg0KPg0KPkJ1dCB0aGVyZSBpcyBubyBtZW50aW9uIGFu eXdoZXJlIGluIHRoZSBkb2N1bWVudCB0byBleHRlcm5hbC9tYW51YWwNCj5jb25maWd1cmF0aW9u LiAgV2hlcmUgaW4gdGhhdCBwcmlvcml0eSBsaXN0IHNob3VsZCBpdCBmaXQ/DQo+DQo+VGhhbmtz IQ0KPg0KPkFsdmFyby4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPlJvbGwgbWFpbGluZyBsaXN0DQo+Um9sbEBpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KDQo= From nobody Wed Jul 1 17:44:43 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6758F1B2B3A; Wed, 1 Jul 2015 17:44:42 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRjL9S9LgkbL; Wed, 1 Jul 2015 17:44:40 -0700 (PDT) Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C5C1B2B39; Wed, 1 Jul 2015 17:44:39 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t620iauu006671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2015 09:44:36 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t620ibmr007069; Thu, 2 Jul 2015 09:44:37 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 618; Thu, 2 Jul 2015 09:44:37 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t620ibxJ007060; Thu, 2 Jul 2015 09:44:37 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t620iaBJ014358; Thu, 2 Jul 2015 09:44:36 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA14321; Thu, 2 Jul 2015 09:44:34 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t620iX6K002790; Thu, 2 Jul 2015 09:44:33 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t620iRuX016357; Thu, 2 Jul 2015 09:44:27 +0900 (JST) Received: from [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8] (unknown [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id A7DDD18F4D9; Thu, 2 Jul 2015 09:44:28 +0900 (JST) Message-ID: <5594896C.4090802@toshiba.co.jp> Date: Thu, 02 Jul 2015 09:44:28 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Alvaro Retana (aretana)" , "draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp id t620ibxJ007060 Archived-At: Cc: "roll-chairs@ietf.org" , Routing Over Low power and Lossy networks , Ines Robles Subject: Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 00:44:42 -0000 Hi Alvaro, Thank you again for the review. I think the document is almost ready and = I will submit it later today. Best Regards, Yusuke On 2015-07-02 01:30, Alvaro Retana (aretana) wrote: > Yusuke: >=20 > Hi! >=20 > I didn=A1=AFt see a follow up from you, but I=A1=AFm assuming that we=A1= =AFre on the same > page. >=20 > This draft is on the agenda for discussion in the IESG next week (July/= 9). > The IETF Last Call has ended, and there are outstanding comments (min= or > and nits) from IANA, SecDir and GenART. >=20 > Please take a look at the comments and post an update before next week. > The sooner the better to give the IESG a good chance to review the late= st > text. >=20 > Thanks! >=20 > Alvaro. >=20 >=20 >=20 > On 6/18/15, 1:49 PM, "Roll on behalf of Alvaro Retana (aretana)" > wrote: >=20 >> On 6/17/15, 1:43 PM, "Yusuke DOI" wrote: >> >> Yusuke: >> >> Hi! >> >> . . . >>>> Minor: >>>> >>>> 1. Section 1 (Introduction): "Some managed wireless mesh networks = may >>>> have a DHCP server to configure network parameters.=A9=F7 How = common is >>>> the use of DHCP? =A9=F8Some..may=A9=F7 doesn=A9=F6t sound like= this extension >>>> will >>>> be used a lot. How do other networks configure their parameter= s? >>>> I=A9=F6m assuming manually.. >>> >>> I have no other experience, but I assume the configuration will be do= ne >>> manually... >> . . . >>> >>>> 3. Section 2.3 (MPL Forwarder Behavior) Joining and leaving the >>>> domain. I must be missing something.. >>>> * "the node MAY join the MPL domain given by the option=A9=F7= Why >>>> would the client request the Option and then not join the >>>> domain? >>> >>> One reason is resource constraint. As joining to a MPL domain require= s >>> certain amount of buffers allocated, a node may fail to join all of t= he >>> domains given by the option. >> >> The use of =A9=F8MAY=A9=F7 above gives the impression that joining is = optional. But >> you=A9=F6re saying that even if the node wants to join it may not be a= ble to, >> which is different. >> >> Suggestion: >> >> OLD> >> >> If a DHCPv6 client requests and receives MPL Parameter Configuratio= n >> Option, the node MAY join the MPL domain given by the option and ac= t >> as an MPL forwarder. >> >> >> NEW> >> >> If a DHCPv6 client requests and receives MPL Parameter Configuratio= n >> Option, the node SHOULD join the MPL domain given by the option and= act >> as an MPL forwarder. Note that there may be cases in which a node = may >> fail is to join a domain (or domains) due to local resource >> constraints. >> >> I=A9=F6m not sure if you/the WG want to add something else to that par= agraph.. >> >> >> >>>> * "A node MAY leave from an MPL domain..=A9=F7 The condition= s seem to >>>> say that the domain in the Option changed, is that true? I= f >>>> the >>>> domain in the option changed, why would the node not leave = the >>>> domain? >>> >>> There's no reason except the domain is configured manually at the sam= e >>> time (the first condition is not met). If there are a manual >>> configuration, implementation may consider it's overriding the DHCPv6 >>> Option. >>> >>> Is this clear?: >>> >>> """ >>> A node SHOULD leave from a MPL domain if the node received a new opti= on >>> without configuration for the MPL domain, unless it has overriding >>> external configuration on the MPL domain. >>> """ >> >> How about this instead: >> >> NEW> >> >> A node SHOULD leave an MPL domain if it receives an updated >> MPL Parameter Configuration Option without a configuration for the >> MPL domain, unless it has overriding external configuration. >> >> >> I=A9=F6m not sure if =A9=F8external=A9=F7 is the right word..or if =A9= =F8manual=A9=F7 might be >> better. Look at the point #1 above about how other nodes may be >> configured. >> >> In this section (2.3) there=A9=F6s a priority of configuration shown: >> >> The priority of MPL Parameter Configuration applied for an MPL Doma= in >> is as follows (high to low). >> >> o Specific MPL Parameter Configuration to the MPL Domain (optlen=3D= 34) >> >> o Wildcard MPL Parameter Configuration (optlen=3D18) >> >> o Default configuration given in the MPL specification. >> >> >> But there is no mention anywhere in the document to external/manual >> configuration. Where in that priority list should it fit? >> >> Thanks! >> >> Alvaro. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 From nobody Thu Jul 2 00:45:23 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C267E1B3027; Thu, 2 Jul 2015 00:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zqr-sFmepR8; Thu, 2 Jul 2015 00:45:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BB11B3037; Thu, 2 Jul 2015 00:45:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702074516.451.9178.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 00:45:16 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 07:45:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : MPL Parameter Configuration Option for DHCPv6 Authors : Yusuke Doi Matthew Gillmore Filename : draft-ietf-roll-mpl-parameter-configuration-05.txt Pages : 10 Date : 2015-07-02 Abstract: This document defines a way to configure a parameter set for MPL (Multicast Protocol for Low power and Lossy Networks) via a DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameters easily. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-05 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 Jul 2 00:45:24 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43301B3033; Thu, 2 Jul 2015 00:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU4mojPCTcLL; Thu, 2 Jul 2015 00:45:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D731B3039; Thu, 2 Jul 2015 00:45:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702074516.451.36706.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 00:45:16 -0700 Archived-At: Subject: [Roll] New Version Notification - draft-ietf-roll-mpl-parameter-configuration-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 07:45:22 -0000 A new version (-05) has been submitted for draft-ietf-roll-mpl-parameter-configuration: https://www.ietf.org/internet-drafts/draft-ietf-roll-mpl-parameter-configuration-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-05 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. IETF Secretariat. From nobody Thu Jul 2 02:24:00 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E101B30ED; Thu, 2 Jul 2015 02:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F43idKnTMx49; Thu, 2 Jul 2015 02:23:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 812441B30FF; Thu, 2 Jul 2015 02:23:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702092352.28797.56787.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 02:23:52 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 09:23:58 -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 Working Group of the IETF. Title : MPL Parameter Configuration Option for DHCPv6 Authors : Yusuke Doi Matthew Gillmore Filename : draft-ietf-roll-mpl-parameter-configuration-06.txt Pages : 10 Date : 2015-07-02 Abstract: This document defines a way to configure a parameter set for MPL (Multicast Protocol for Low power and Lossy Networks) via a DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameters easily. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-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 Thu Jul 2 02:24:02 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472661B30F7; Thu, 2 Jul 2015 02:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbKoubrxRaFs; Thu, 2 Jul 2015 02:23:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 963831B3101; Thu, 2 Jul 2015 02:23:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702092352.28797.44255.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 02:23:52 -0700 Archived-At: Subject: [Roll] New Version Notification - draft-ietf-roll-mpl-parameter-configuration-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 09:23:59 -0000 A new version (-06) has been submitted for draft-ietf-roll-mpl-parameter-configuration: https://www.ietf.org/internet-drafts/draft-ietf-roll-mpl-parameter-configuration-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-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. IETF Secretariat. From nobody Thu Jul 2 02:24:53 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139EB1B30FF; Thu, 2 Jul 2015 02:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEVFfqn7ouiF; Thu, 2 Jul 2015 02:24:49 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3672C1B30ED; Thu, 2 Jul 2015 02:24:48 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t629OiCL025902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2015 18:24:45 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629OilZ005910; Thu, 2 Jul 2015 18:24:44 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 919; Thu, 2 Jul 2015 18:24:44 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629OhHP005894; Thu, 2 Jul 2015 18:24:43 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id t629Ohhi001104; Thu, 2 Jul 2015 18:24:43 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id UAA01094; Thu, 2 Jul 2015 18:24:43 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t629OgoJ019471; Thu, 2 Jul 2015 18:24:42 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t629OfUe018294; Thu, 2 Jul 2015 18:24:41 +0900 (JST) Received: from [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8] (unknown [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id C931C18F4D9; Thu, 2 Jul 2015 18:24:41 +0900 (JST) Message-ID: <55950359.8050601@toshiba.co.jp> Date: Thu, 02 Jul 2015 18:24:41 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: aretana@cisco.com, draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org References: <5581A3AD.8060309@toshiba.co.jp> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp id t629OhHP005894 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com Subject: Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 09:24:52 -0000 Dear Alvaro, Sorry for late update. I've just submitted revised version (06, not 05, s= orry for unfixed nits) On 2015-06-19 01:49, Alvaro Retana (aretana) wrote: > The use of =B3MAY=B2 above gives the impression that joining is optiona= l. But > you=B9re saying that even if the node wants to join it may not be able = to, > which is different. > > Suggestion: > > OLD> > > If a DHCPv6 client requests and receives MPL Parameter Configuratio= n > Option, the node MAY join the MPL domain given by the option and ac= t > as an MPL forwarder. > > > NEW> > > If a DHCPv6 client requests and receives MPL Parameter Configuratio= n > Option, the node SHOULD join the MPL domain given by the option and= act > as an MPL forwarder. Note that there may be cases in which a node = may > fail is to join a domain (or domains) due to local resource constra= ints. > > I=B9m not sure if you/the WG want to add something else to that paragra= ph.. Thank you. I used your suggested text. > How about this instead: > > NEW> > > A node SHOULD leave an MPL domain if it receives an updated > MPL Parameter Configuration Option without a configuration for the > MPL domain, unless it has overriding external configuration. > > > I=B9m not sure if =B3external=B2 is the right word..or if =B3manual=B2 = might be > better. Look at the point #1 above about how other nodes may be > configured. > > In this section (2.3) there=B9s a priority of configuration shown: > > The priority of MPL Parameter Configuration applied for an MPL Doma= in > is as follows (high to low). > > o Specific MPL Parameter Configuration to the MPL Domain (optlen=3D= 34) > > o Wildcard MPL Parameter Configuration (optlen=3D18) > > o Default configuration given in the MPL specification. > > > But there is no mention anywhere in the document to external/manual > configuration. Where in that priority list should it fit? I added some text on manual configuration on -06. I believe the priority of manual configuration is up to the implementatio= n and out of scope of the document. BTW, on your previous e-mail on June 16: > 2.5. (DHCPv6 Relay Behavior). A reference to rfc6422 would be nice. I think this document does not have any Relay-supplied information. Is th= e reference still nice-to-have? (-06 does not have reference for 6422). Thanks! Yusuke From nobody Thu Jul 2 02:25:22 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB31B3100; Thu, 2 Jul 2015 02:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J63bgw1ybtXE; Thu, 2 Jul 2015 02:25:19 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D4F1B30EC; Thu, 2 Jul 2015 02:25:18 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t629PErG026157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2015 18:25:15 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629PDdB007249; Thu, 2 Jul 2015 18:25:13 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 591; Thu, 2 Jul 2015 18:25:13 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629PDov007245; Thu, 2 Jul 2015 18:25:13 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id t629PDL0001683; Thu, 2 Jul 2015 18:25:13 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id UAA01675; Thu, 2 Jul 2015 18:25:12 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t629PCcf019752; Thu, 2 Jul 2015 18:25:12 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t629PBGW019145; Thu, 2 Jul 2015 18:25:11 +0900 (JST) Received: from [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8] (unknown [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id B2B9518F4D9; Thu, 2 Jul 2015 18:25:11 +0900 (JST) Message-ID: <55950377.3020000@toshiba.co.jp> Date: Thu, 02 Jul 2015 18:25:11 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: roll@ietf.org, iesg@ietf.org, secdir@ietf.org References: <5BE572AB-D17A-4890-8385-B0F9A16C2A3F@cisco.com> In-Reply-To: <5BE572AB-D17A-4890-8385-B0F9A16C2A3F@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp id t629PDov007245 Archived-At: Cc: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org Subject: Re: [Roll] Secdir review of draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 09:25:20 -0000 Brian, Thank you very much for your review. I submitted revised version (-06, no= t -05, sorry for unfixed nits). On 2015-06-26 05:18, Brian Weis (bew) wrote: > 1. Describing a resource consumption threat ("excessive layer-2 > broadcasting=93) resulting from a man-in-the-middle modifying policy > sent within an option. If there is a suggested mitigation (e.g., a > means of integrity protecting the DHCPv6 traffic between the client > and server) this would be worth noting. But I=92m not sure if there > any available mitigation in a ROLL environment. I added some text on network level protection case in addition to use of = DHCPv6 security, including filter on the border router in a ROLL network. > 2. Making a requirement that a server implementation choose > reasonable policy values. This might be more useful if it were > phrased as a threat, something like =93Server implementations need to > take care in setting reasonable bounds for each parameter in order to > avoid overloading the network." Thanks. I used your text with 'server and client implementations.' > 3. Making a requirement that the "DHCP server or the network itself > shall be trusted by some means including network access control or > DHCP authentication=94. Is this this =93shall=94 intended to be an RFC > 2119 =93MUST=94? No. I think making secure network properly to use DHCPv6 option is just a= generic requirement and it's beyond the scope of this document. Best Regards, Yusuke From nobody Thu Jul 2 02:25:30 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2AFDF1B30FE; Thu, 2 Jul 2015 02:25:21 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9751B30EC for ; Thu, 2 Jul 2015 02:25:21 -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, SPF_FAIL=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sodwqV1KxrgQ for ; Thu, 2 Jul 2015 02:25:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B6E1B30FE for ; Thu, 2 Jul 2015 02:25:20 -0700 (PDT) Received: from imx2.toshiba.co.jp ([106.186.93.51]:51145) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAakB-0008IN-LT for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Thu, 02 Jul 2015 02:25:20 -0700 Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t629PDfY020766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Jul 2015 18:25:13 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629PEWM021271 for ; Thu, 2 Jul 2015 18:25:14 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 69 for ; Thu, 2 Jul 2015 18:25:14 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629PE5T021265 for ; Thu, 2 Jul 2015 18:25:14 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t629PCaF002328 for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Thu, 2 Jul 2015 18:25:12 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA02325; Thu, 2 Jul 2015 18:25:12 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t629PCYR012746 for ; Thu, 2 Jul 2015 18:25:12 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t629PB29026901; Thu, 2 Jul 2015 18:25:11 +0900 (JST) Received: from [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8] (unknown [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id B2B9518F4D9; Thu, 2 Jul 2015 18:25:11 +0900 (JST) Message-ID: <55950377.3020000@toshiba.co.jp> Date: Thu, 02 Jul 2015 18:25:11 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: roll@ietf.org, iesg@ietf.org, secdir@ietf.org References: <5BE572AB-D17A-4890-8385-B0F9A16C2A3F@cisco.com> In-Reply-To: <5BE572AB-D17A-4890-8385-B0F9A16C2A3F@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp id t629PE5T021265 X-SA-Exim-Connect-IP: 106.186.93.51 X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org X-SA-Exim-Mail-From: yusuke.doi@toshiba.co.jp X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org Resent-Message-Id: <20150702092520.43B6E1B30FE@ietfa.amsl.com> Resent-Date: Thu, 2 Jul 2015 02:25:20 -0700 (PDT) Resent-From: yusuke.doi@toshiba.co.jp Archived-At: Archived-At: Cc: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org Subject: Re: [Roll] Secdir review of draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 09:25:21 -0000 Brian, Thank you very much for your review. I submitted revised version (-06, no= t -05, sorry for unfixed nits). On 2015-06-26 05:18, Brian Weis (bew) wrote: > 1. Describing a resource consumption threat ("excessive layer-2 > broadcasting=93) resulting from a man-in-the-middle modifying policy > sent within an option. If there is a suggested mitigation (e.g., a > means of integrity protecting the DHCPv6 traffic between the client > and server) this would be worth noting. But I=92m not sure if there > any available mitigation in a ROLL environment. I added some text on network level protection case in addition to use of = DHCPv6 security, including filter on the border router in a ROLL network. > 2. Making a requirement that a server implementation choose > reasonable policy values. This might be more useful if it were > phrased as a threat, something like =93Server implementations need to > take care in setting reasonable bounds for each parameter in order to > avoid overloading the network." Thanks. I used your text with 'server and client implementations.' > 3. Making a requirement that the "DHCP server or the network itself > shall be trusted by some means including network access control or > DHCP authentication=94. Is this this =93shall=94 intended to be an RFC > 2119 =93MUST=94? No. I think making secure network properly to use DHCPv6 option is just a= generic requirement and it's beyond the scope of this document. Best Regards, Yusuke From nobody Thu Jul 2 02:26:43 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8E01B310F; Thu, 2 Jul 2015 02:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.764 X-Spam-Level: ** X-Spam-Status: No, score=2.764 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3MAfYH2kuAQ; Thu, 2 Jul 2015 02:26:40 -0700 (PDT) Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D98C1B3107; Thu, 2 Jul 2015 02:26:40 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t629Qcbh021469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2015 18:26:38 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629QdjW024600; Thu, 2 Jul 2015 18:26:39 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 101; Thu, 2 Jul 2015 18:26:39 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629QdIx024576; Thu, 2 Jul 2015 18:26:39 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t629QbDA003866; Thu, 2 Jul 2015 18:26:37 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA03860; Thu, 2 Jul 2015 18:26:37 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t629QbkQ013615; Thu, 2 Jul 2015 18:26:37 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t629QaUl021510; Thu, 2 Jul 2015 18:26:36 +0900 (JST) Received: from [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8] (unknown [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id CBF5B18F4D9; Thu, 2 Jul 2015 18:26:36 +0900 (JST) Message-ID: <559503CC.7030409@toshiba.co.jp> Date: Thu, 02 Jul 2015 18:26:36 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: roll@ietf.org, draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org References: <01ea01d0af9c$de6319e0$9b294da0$@akayla.com> In-Reply-To: <01ea01d0af9c$de6319e0$9b294da0$@akayla.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: gen-art@ietf.org Subject: Re: [Roll] Gen-ART LC review for draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 09:26:41 -0000 Dear Peter, Thank you for review. I submitted -06 (-05 contains some nits) as a revised version. On 2015-06-26 08:15, Peter Yee wrote: > Some of the parameters are described with their bit lengths, others are not. > Lengths are listed haphazardly. Be consistent in either including them or > not. Timer lengths are listed as n-bit integers, but this may be confusing > given that the document says "Short floating point format is used to > describe the wide range of timer values". So, are the timer values floating > point or integer? Is the combined implication supposed to be that the > numbers are formatted as floating point (for greater range), but only take > on integer values? Given that the values in this document are all given in > reference to division by the value of TUNIT, it's possible that values might > not be integers. If that happens and only integers are desired, is rounding > or truncation preferred? Also note that Appendix A indicates that "short > unsigned floating point" was dropped. It's not completely clear if that > means that "short [signed?] floating point" was adopted in its stead or > whether actual short integers were preferred. Short floating point is dropped but some texts have not removed (my mistake). Thank you for pointing out. All values should be in integer. Thank you again for your efforts on review (and sorry for lot of nits...) Yusuke From nobody Thu Jul 2 02:26:58 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E1E291B311C; Thu, 2 Jul 2015 02:26:53 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59551B311C for ; Thu, 2 Jul 2015 02:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.268 X-Spam-Level: X-Spam-Status: No, score=0.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, SPF_FAIL=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpIW9lRCn3YR for ; Thu, 2 Jul 2015 02:26:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E791B3107 for ; Thu, 2 Jul 2015 02:26:52 -0700 (PDT) Received: from imx12.toshiba.co.jp ([61.202.160.132]:62102) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAale-0005vH-VV for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Thu, 02 Jul 2015 02:26:52 -0700 Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t629Qehg026830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Jul 2015 18:26:40 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629Qd5U010476 for ; Thu, 2 Jul 2015 18:26:39 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 947 for ; Thu, 2 Jul 2015 18:26:39 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629QcEF010440 for ; Thu, 2 Jul 2015 18:26:39 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id t629Qcr8003051 for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Thu, 2 Jul 2015 18:26:38 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id UAA03048; Thu, 2 Jul 2015 18:26:38 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t629QbZj020467 for ; Thu, 2 Jul 2015 18:26:37 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t629QaqU029278; Thu, 2 Jul 2015 18:26:36 +0900 (JST) Received: from [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8] (unknown [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id CBF5B18F4D9; Thu, 2 Jul 2015 18:26:36 +0900 (JST) Message-ID: <559503CC.7030409@toshiba.co.jp> Date: Thu, 02 Jul 2015 18:26:36 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: roll@ietf.org, draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org References: <01ea01d0af9c$de6319e0$9b294da0$@akayla.com> In-Reply-To: <01ea01d0af9c$de6319e0$9b294da0$@akayla.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 61.202.160.132 X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org X-SA-Exim-Mail-From: yusuke.doi@toshiba.co.jp X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org Resent-Message-Id: <20150702092652.E9E791B3107@ietfa.amsl.com> Resent-Date: Thu, 2 Jul 2015 02:26:52 -0700 (PDT) Resent-From: yusuke.doi@toshiba.co.jp Archived-At: Archived-At: Cc: gen-art@ietf.org Subject: Re: [Roll] Gen-ART LC review for draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 09:26:54 -0000 Dear Peter, Thank you for review. I submitted -06 (-05 contains some nits) as a revised version. On 2015-06-26 08:15, Peter Yee wrote: > Some of the parameters are described with their bit lengths, others are not. > Lengths are listed haphazardly. Be consistent in either including them or > not. Timer lengths are listed as n-bit integers, but this may be confusing > given that the document says "Short floating point format is used to > describe the wide range of timer values". So, are the timer values floating > point or integer? Is the combined implication supposed to be that the > numbers are formatted as floating point (for greater range), but only take > on integer values? Given that the values in this document are all given in > reference to division by the value of TUNIT, it's possible that values might > not be integers. If that happens and only integers are desired, is rounding > or truncation preferred? Also note that Appendix A indicates that "short > unsigned floating point" was dropped. It's not completely clear if that > means that "short [signed?] floating point" was adopted in its stead or > whether actual short integers were preferred. Short floating point is dropped but some texts have not removed (my mistake). Thank you for pointing out. All values should be in integer. Thank you again for your efforts on review (and sorry for lot of nits...) Yusuke From nobody Thu Jul 2 05:53:11 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851091A1B5E; Thu, 2 Jul 2015 05:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC2sI8kfOhw5; Thu, 2 Jul 2015 05:53:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 735041A1B6D; Thu, 2 Jul 2015 05:52:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702125255.14957.22146.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 05:52:55 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-11.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 12:53:08 -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 Working Group of the IETF. Title : Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control Authors : Anders Brandt Emmanuel Baccelli Robert Cragie Peter van der Stok Filename : draft-ietf-roll-applicability-home-building-11.txt Pages : 35 Date : 2015-07-02 Abstract: The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-11 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 Jul 2 08:36:04 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977BA1AC422; Thu, 2 Jul 2015 08:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R_ahfI9iqdU; Thu, 2 Jul 2015 08:36:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 941B81AC429; Thu, 2 Jul 2015 08:35:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702153558.10072.83202.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 08:35:58 -0700 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 15:36:03 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ From nobody Fri Jul 3 00:45:40 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1D01A1B0E; Fri, 3 Jul 2015 00:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E18JL9xL9VYn; Fri, 3 Jul 2015 00:45:05 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B141A1AE6; Fri, 3 Jul 2015 00:44:55 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.205]) by smtp-cloud2.xs4all.net with ESMTP id njkn1q00A4RV18J01jknwM; Fri, 03 Jul 2015 09:44:53 +0200 Received: from [2001:983:a264:1:ddf7:71d4:4944:4487] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 03 Jul 2015 09:44:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 03 Jul 2015 09:44:47 +0200 From: peter van der Stok To: Stephen Farrell Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> <0b35569a80c62337655b16c7010a84da@xs4all.nl> <12442.1429113740@sandelman.ca> <32c66dc3bb9f396188b90a178ff767d9@xs4all.nl> <15944.1429209784@sandelman.ca> <4b7fa589766fa21d12403ee8cc49262e@xs4all.nl> <55586FF8.5060908@cs.tcd.ie> Message-ID: <95014c56b8f831a1bea3c56928cbce96@xs4all.nl> X-Sender: stokcons@xs4all.nl (DR29llPtChA0l0ws78st6M9mMAFQppO+) User-Agent: XS4ALL Webmail Archived-At: X-Mailman-Approved-At: Fri, 03 Jul 2015 00:45:39 -0700 Cc: mcr@sandelman.ca, roll-chairs@ietf.org, Michael Richardson , Routing Over Low power and Lossy networks , draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 07:45:08 -0000 Hi Stephen, A new draft has been submitted The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-11 The following things have been done. In section 4.1.8 a description of the link-layer security as deployed by SEP 2.0 is added. Sections 7.1 , 7.2 and 7.3 have been adapted to discuss future link-layer security alternatives to SEP2.0 deployment. Looking forward to your reaction, Peter >> >> I'm sorry to say I don't think we're there yet. I just read the >> current draft and I think we still have significant issues for >> this DISCUSS. >> >> - If the way in which we are achieving interoperable security is >> via layer2-only then I would argue that that has to be more clearly >> stated up front (for truth-in-advertising reasons) as otherwise >> people may implement/deploy assuming the opposite. >> >> - I really seriously question the proposition that layer2-only >> security is sufficient for more complex building requirements. >> If that is true, then this document needs to say when it is safe >> and when it is unsafe to use RPL in such networks. (I can accept >> that layer2-only is ok for simple buildings and homes, at least >> for the next few years.) From nobody Fri Jul 3 06:53:37 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640011B3013; Fri, 3 Jul 2015 06:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.023 X-Spam-Level: * X-Spam-Status: No, score=1.023 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_GIRL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmZpa43DCbOl; Fri, 3 Jul 2015 06:53:29 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F401F1B3010; Fri, 3 Jul 2015 06:53:22 -0700 (PDT) Received: by wgjx7 with SMTP id x7so88941473wgj.2; Fri, 03 Jul 2015 06:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=q2XBqrWzcVySnyQicqJ7f5fNUV2ckywjn9fpDNay2YQ=; b=SFMPUW2PB9Ti2YwaiALoWH7Pq966JDHWWzRhAc0UZwq0sKHGz2UDnxBTu+lDq18D/J u6CJTu7n66W69eNyRNfARVdNDAJGtfvjDF7s73x3Yn5/JWzL4efj25es2YBdc4k9rxyb eDp0GulQgaMREk/U37jDvcnhl+gqR3IwQPMa9Se5FtkdqZ6i8xCzRs/NvM7Si2DptjBa vhJIHSUPovu+zemwZfjrMgcM26F1y0vLA8vfhV1Qf/Oog1/m39TKL5pQeJzKdA1M1aPC eLmoTttioWGErV1GDc9UHjAdaPBFKjTioT3T3FYo5zTn9198ZRxda4LTXpPMVQSnckab 6xAg== X-Received: by 10.181.11.129 with SMTP id ei1mr63172727wid.90.1435931576822; Fri, 03 Jul 2015 06:52:56 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.28.134.146 with HTTP; Fri, 3 Jul 2015 06:52:36 -0700 (PDT) From: Thomas Watteyne Date: Fri, 3 Jul 2015 15:52:36 +0200 X-Google-Sender-Auth: a5jMHceCYjEFIhOnfDBBtAhoHRw Message-ID: To: IETF ROLL , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=f46d043c81708ef24e0519f8dfff Archived-At: Subject: [Roll] Thomas' remarks on draft-robles-roll-useofrplinfo-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 13:53:34 -0000 --f46d043c81708ef24e0519f8dfff Content-Type: text/plain; charset=UTF-8 Ines, Michael, Please find my remarks about draft-robles-roll-useofrplinfo-00 below. Thomas ---- TW> overall comments TW> - this is a super important informational draft, which TW> clears up a lot of questions TW> - I think it would be very useful to have more example TW> packets. We are building such information for the upcoming 6TiSCH TW> plugtest, so I can help there. TW> - After this is done I would recommend to ask explicitly for TW> reviewers. Robert Cragie should be TW> on the list of people to ask; he has provided very useful info TW> during our discussions. ROLL Working Group M.I. Robles Internet-Draft Ericsson Intended status: Informational M. Richardson Expires: December 29, 2015 SSW June 27, 2015 When to use RFC 6553, 6554 and IPv6-in-IPv6 draft-robles-roll-useofrplinfo-00 Abstract This document states different cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is required to set the bases to help defining the compression of RPL routing information in LLN environments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 29, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Robles & Richardson Expires December 29, 2015 [Page 1] Internet-Draft Useof6553 June 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Requirements Language . . . . . . . . . . . . 2 3. Sample/reference topology . . . . . . . . . . . . . . . . . . 3 4. Example flow from leaf to root . . . . . . . . . . . . . . . 4 4.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Example flow from leaf to Internet . . . . . . . . . . . . . 6 5.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Example flow from leaf to leaf . . . . . . . . . . . . . . . 7 6.1. Traditional storing . . . . . . . . . . . . . . . . . . . 7 6.2. Traditional non-storing . . . . . . . . . . . . . . . . . 7 6.3. P2P non-storing . . . . . . . . . . . . . . . . . . . . . 7 7. Example flow from Internet to leaf . . . . . . . . . . . . . 7 7.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 8. Example flow from root to leaf . . . . . . . . . . . . . . . 7 8.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction RPL [RFC6550] defines RPL Option to transmit routing information. RFC 6553 [RFC6553] defines how to transmit in a Hop-By-Hop Option RPL Information,such as information to avoid and detect loops. RFC 6554 [RFC6554] defines the use of Extension header for Source Routing. TW> this is a bit confusing to me. AFAICT: TW> - RFC6550 defines the RPL routing protocol TW> - RFC6553 defines the "RPL option", carried within the IPv6 Hop-by-Hop TW> header to quickly identify inconsistencies in the routing topology TW> - RFC6554 defines the "RPL Source Route Header", an IPv6 Extension Header to deliver datagrams within a RPL routing domain Several discussions in TW> the ROLL/6lo/6tisch TW> 6tisch -> 6TiSCH Mailing Lists took place focusing in the definition TW> of how to compress RPL Information in constrained environment. ROLL Virtual Interim Meeting (02-2015) concluded that there is a need to define how to use RFC 6553, RFC6554 TW> you have to decide whether you use "RFC 123" or "RFC123". I would TW> recommend you replace this by a hyperlink and tunneling (IP-in-IP) TW> I would say "and IP-in-IP encapsulation" to be able to set the correct environment for compression. 2. Terminology and Requirements Language TW> you're actually not using any of this language in the draft. TW> if you keep it that way, and since the draft is informational TW> I would recommend to remove this section Robles & Richardson Expires December 29, 2015 [Page 2] Internet-Draft Useof6553 June 2015 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Terminology defined in [RFC7102] 3. Sample/reference topology In a typical topology we found TW> "we found" reads strange. What about "A RPL network is composed of TW> ...[6LR,6LBR]... logically organized in a DODAG structure". 6LBR (6LoWPAN Border Router), 6lR TW> 6LR (6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf connected in a DODAG (Destination Oriented Directed Acyclic Graph). Between these entities messages such as DIS, DIO and DAO are transmitted. RPL defines the RPL Control message as an ICMPv6 information message with a Type of 155. TW> RPL defines the RPL Control message, a new ICMPv6 message with TW> Type 155. DIS, DIO and DAO messages are all RPL Control messages TW> but with different Code values. RPL supports two modes of Downward traffic: Storing, it is fully stateful or Non-Storing it is fully source routed. Any given RPL Instance is either storing or non-storing. TW> please specify that a RPL Instance is either fully storing or fully TW> non-storing, i.e. a RPL Instance with a combination of storing and TW> non-storing nodes is not supported +--------------+ | Upper Layers | | | +--------------+ | RPL | | | +--------------+ | ICMPv6 | | | +--------------+ | IPv6 | | | +--------------+ | 6LoWPAN | | | +--------------+ | PHY-MAC | | | +--------------+ Figure 1: RPL Stack Robles & Richardson Expires December 29, 2015 [Page 3] Internet-Draft Useof6553 June 2015 +---------+ +---+Internet | | +---------+ | +----+--+ |DODAG | +---------+Root +----------+ | |6LBR | | | +----+--+ | | | | | | | | | | +-----+-+ +--+---+ +--+---+ |6LR | | | | | +-----+ | | | | | | | | | | | +------+ | +-----+-+ +-+----+ +-+----+ | | | | | | | | | | | | | | | | +-+---+ +-+---+ +--+--+ +- --+ +---+-+ |Leaf | | | | | | | | | |6LN | | | | | | | | | +-----+ +-----+ +-----+ +----+ +-----+ Figure 2: A reference RPL Topology TW> I would add a "." at end of each caption In different scenarios the use of RFC 6553, RFC 6554 and tunneling can take place: TW> I would say that a combination of RFC6553, RFC6554 and IP-in-IP TW> encapsulation is used for the following traffic flows: -Flow from leaf to root TW> remove newlines? -Flow from leaf to Internet -Flow from leaf to leaf -Flow from Internet to leaf -Flow from leaf to root TW> duplicate 4. Example flow from leaf to root A leaf node generates DAO and DIS messages and in general does not accept them. TW> what do you mean by "accept"? Additionally, this kind of nodes TW> node accepts DIO messages, but in general do TW> does not generate them. (In inconsistency A leaf node generates DIO with infinite rank, to fix it). TW> A -> a Robles & Richardson Expires December 29, 2015 [Page 4] Internet-Draft Useof6553 June 2015 4.1. Non-storing In non-storing TW> mode in this case TW> remove "in this case" the leaf node uses Hop-By-Hop option (RFC 6553) to indicate the routing information to send messages to the DODAG root, this message is going to be analyzed in each node until arrive the DODAG root. RFC 6554 was created to strictly send information between RPL routers in the same RPL routing domain. How it would be in 6554? TW> I assume a "TODO" missing before last sentence? TBD: Tunneling is necessary in case that there is information to send outside RPL Domain and other cases? +------+ | | | 6LBR | | | +---+--+ | | LoWPAN_HC | Route= 6LN-6LR-6LBR ^ | | +---+-+ | | | | | 6LR | | | | | +--+--+ | | LoWPAN_HC | | Route= 6LN-6LR-6LBR | | + | +--+--+ | 6LN | | | | | +-----+ Figure 3: From leaf to Root - Non-Storing Mode TW> I don't fully understand what message this figure conveys TW> I would use A B and C to name the nodes, and write their role TW> next to them 4.2. Storing IP6 6553{X,Y] ?ipip payload. TW> something's wrong In storing mode is suitable the use of RFC 6553 to send RPL Information through HBH field checking the routing table to find out where to send the message. TW> I don't understand "checking the routing table to find out where TW> to send the message" It may include IP-in-IP encapsulation to transmit information not related with the RPL domain. TW> I would expand this info Robles & Richardson Expires December 29, 2015 [Page 5] Internet-Draft Useof6553 June 2015 +------+ | | | 6LBR | | | +---+--+ | | LoWPAN_HC | 0x63|HBH Data ^ | | +---+-+ | | | | | 6LR | 6LR check in routing table | | | | +--+--+ | | LoWPAN_HC | | 0x63|HBH Data | | + | +--+--+ | 6LN | | | | | +-----+ Figure 4: From leaf to Root - Storing Mode 5. Example flow from leaf to Internet 5.1. Non-storing In this case the IP-in-IP encapsulation should take place to send information not related to the RPL domain inside of the RPL domain. RPL information from RFC 6553 should not go out to Internet. The router sould TW> typo take this information out before send the packet to Internet. The HBH Option is going to be analyzed in each node to the root. TW> illustrate this with a fig? Related to RFC 6554 the Source Header route is added and removed by DODAG root. However, RFC 6554 was created to strictly send information between RPL routers in the same RPL routing domain. How it would be in 6554? TW> this paragraph relates to down traffic, right? The name of the section TW> is "from leaf to Internet" Robles & Richardson Expires December 29, 2015 [Page 6] Internet-Draft Useof6553 June 2015 5.2. Storing In storing the information of RFC 6553 should take away by DODAG root before go to Internet. TW> but as well in non-storing, no? 6. Example flow from leaf to leaf can leafs insert appropriate headers, without ipip? In [RFC6550] RPL allows a simple one-hop P2P optimization for both storing and non- storing networks. A node may send a P2P packet destined to a one-hop neighbor direclty TW> typo to that node. Section 9 in [RFC6550]. TW> I would say that IP-in-IP is not needed in this case 6.1. Traditional storing TW> why "Traditional"? The route go through an ancestor that knows the route to the destination, using HBH [RFC6553] to carry RPL Information. 6.2. Traditional non-storing The route go through the DODAG root, using source routing [RFC6554]. 6.3. P2P non-storing (p2p storing? TBD) 7. Example flow from Internet to leaf A DODAG root do not add routing extension to incoming packets, it instead uses tunneling. 7.1. Storing DODAG root adds the HBH header [RFC6553] and send the packet downward to the destination. 7.2. Non-storing DODAG root is going to add the source route header [RFC6554] 8. Example flow from root to leaf 8.1. Storing DODAG root adds the HBH header [RFC6553] and send the packet downward to the destination. 8.2. Non-storing Robles & Richardson Expires December 29, 2015 [Page 7] Internet-Draft Useof6553 June 2015 DODAG root is going to add the source route header [RFC6554] 9. IANA Considerations There are no IANA considerations related to this document. 10. Security Considerations TBD. TW> I would replace TBD by TODO, per usual covention 11. Acknowledgements TW> typo This work is partially funded by the FP7 Marie Curie Initial Training Network (ITN) METRICS project (grant agreement No. 607728) 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, March 2012. [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012. 12.2. Informative References [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, January 2014. Authors' Addresses Robles & Richardson Expires December 29, 2015 [Page 8] Internet-Draft Useof6553 June 2015 Maria Ines Robles Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: maria.ines.robles@ericsson.com Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA Email: mcr+ietf@sandelman.ca URI: http://www.sandelman.ca/ Robles & Richardson Expires December 29, 2015 [Page 9] --f46d043c81708ef24e0519f8dfff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ines, Michael,
Please find my remarks about=C2=A0draft= -robles-roll-useofrplinfo-00 below.
Thomas

----

T= W> overall comments
TW> - this is a super important informational draft, which
=
TW> =C2=A0 clears up a lot of q= uestions
TW> - I th= ink it would be very useful to have more example
TW> =C2=A0 packets. We are building such info= rmation for the upcoming 6TiSCH
TW> =C2=A0 plugtest, so I can help there.
TW> - After this is done I would recomm= end to ask=C2=A0expl= icitly=C2=A0<= span style=3D"font-family:monospace,monospace">for
TW> =C2=A0 reviewers. Robert Cr= agie should be
TW> = =C2=A0 on the list of people to ask; he has provided very useful info
TW> =C2=A0 during our di= scussions.

=

ROLL Working Group =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M.I. Robles
Internet-Draft =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Ericsson
Intende= d status: Informational =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 M. Richardson
=
Expires: December 29, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SSW
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=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=A0June 27, 2015


=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When to use RFC 6553, 6554 an= d IPv6-in-IPv6
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-robles-= roll-useofrplinfo-00
<= br>
Abstract

=C2=A0 =C2=A0This document states different case= s where RFC 6553, RFC 6554 and
=C2=A0 =C2=A0IPv6-in-IPv6 encapsulation is required to set the bas= es to help
=C2=A0 =C2= =A0defining the compression of RPL routing information in LLN
<= div>=C2=A0 =C2=A0environments.

Status of This Memo

=C2=A0 =C2=A0This Internet-Draft is submitted in full conformance = with the
=C2=A0 =C2=A0= provisions of BCP 78 and BCP 79.

=C2=A0= =C2=A0Internet-Drafts are working documents of the Internet Engineering
=C2=A0 =C2=A0Task Force = (IETF).=C2=A0 Note that other groups may also distribute
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0working documents as Intern= et-Drafts.=C2=A0 The list of current Internet-

=C2=A0 =C2=A0Internet-Drafts are= draft documents valid for a maximum of six months
=C2=A0 =C2=A0and may be updated, replaced, or = obsoleted by other documents at any
=C2=A0 =C2=A0time.=C2=A0 It is inappropriate to use Internet-= Drafts as reference
= =C2=A0 =C2=A0material or to cite them other than as "work in progress.= "

=C2=A0 =C2=A0This Internet-Draft= will expire on December 29, 2015.

Copy= right Notice

=C2=A0 =C2=A0Copyright (c)= 2015 IETF Trust and the persons identified as the
=C2=A0 =C2=A0document authors.=C2=A0 All right= s reserved.

=C2=A0 =C2=A0This document = is subject to BCP 78 and the IETF Trust's Legal
=C2=A0 =C2=A0Provisions Relating to IETF Docu= ments
=C2=A0 =C2=A0(http://trustee.ietf.org/lice= nse-info) in effect on the date of
=C2=A0 =C2=A0publication of this document.=C2=A0 Please re= view these documents
= =C2=A0 =C2=A0carefully, as they describe your rights and restrictions with = respect
=C2=A0 =C2=A0t= o this document.=C2=A0 Code Components extracted from this document must
=C2=A0 =C2=A0include Sim= plified BSD License text as described in Section 4.e of
=C2=A0 =C2=A0the Trust Legal Provisions a= nd are provided without warranty as
=C2=A0 =C2=A0described in the Simplified BSD License.<= /div>



Roble= s & Richardson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 1]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


Table of Contents
<= br>
=C2=A0 =C2=A01.=C2= =A0 Introduction =C2=A0. . . . . . . . . . . . . . . . . . . . . . . . =C2= =A0 2
=C2=A0 =C2=A02.= =C2=A0 Terminology and Requirements Language . . . . . . . . . . . . =C2=A0= 2
=C2=A0 =C2=A03.=C2= =A0 Sample/reference topology . . . . . . . . . . . . . . . . . . =C2=A0 3<= /font>
=C2=A0 =C2=A04.=C2=A0 = Example flow from leaf to root =C2=A0. . . . . . . . . . . . . . . =C2=A0 4=
=C2=A0 =C2=A0 =C2=A04= .1.=C2=A0 Non-storing . . . . . . . . . . . . . . . . . . . . . . . =C2=A0 = 5
=C2=A0 =C2=A0 =C2=A0= 4.2.=C2=A0 Storing . . . . . . . . . . . . . . . . . . . . . . . . . =C2=A0= 5
=C2=A0 =C2=A05.=C2= =A0 Example flow from leaf to Internet =C2=A0. . . . . . . . . . . . . =C2= =A0 6
=C2=A0 =C2=A0 = =C2=A05.1.=C2=A0 Non-storing . . . . . . . . . . . . . . . . . . . . . . . = =C2=A0 6
=C2=A0 =C2=A0= =C2=A05.2.=C2=A0 Storing . . . . . . . . . . . . . . . . . . . . . . . . .= =C2=A0 7
=C2=A0 =C2= =A06.=C2=A0 Example flow from leaf to leaf =C2=A0. . . . . . . . . . . . . = . . =C2=A0 7
=C2=A0 = =C2=A0 =C2=A06.1.=C2=A0 Traditional storing . . . . . . . . . . . . . . . .= . . . =C2=A0 7
=C2=A0= =C2=A0 =C2=A06.2.=C2=A0 Traditional non-storing . . . . . . . . . . . . . = . . . . =C2=A0 7
=C2= =A0 =C2=A0 =C2=A06.3.=C2=A0 P2P non-storing . . . . . . . . . . . . . . . .= . . . . . =C2=A0 7
= =C2=A0 =C2=A07.=C2=A0 Example flow from Internet to leaf =C2=A0. . . . . . = . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A07.1.=C2=A0 Storing . . . . . . . . . . . . . . . . . .= . . . . . . . =C2=A0 7
=C2=A0 =C2=A08.=C2=A0 Example flow from root to leaf =C2=A0. . . . . . .= . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A08.1.=C2=A0 Storing . . . . . . . . . . . . . . . . = . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A08.2.=C2=A0 Non-storing . . . . . . . . . . . . . .= . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A09.=C2=A0 IANA Considerations . . . . . . . . . . . . . .= . . . . . . . =C2=A0 8
=C2=A0 = =C2=A011. Acknowledgements =C2=A0. . . . . . . . . . . . . . . . . . . . . = . =C2=A0 8
=C2=A0 =C2= =A012. References =C2=A0. . . . . . . . . . . . . . . . . . . . . . . . . = =C2=A0 8
=C2=A0 =C2=A0= =C2=A012.1.=C2=A0 Normative References . . . . . . . . . . . . . . . . . .= =C2=A0 8
=C2=A0 =C2= =A0 =C2=A012.2.=C2=A0 Informative References . . . . . . . . . . . . . . . = . . =C2=A0 8
=C2=A0 = =C2=A0Authors' Addresses =C2=A0. . . . . . . . . . . . . . . . . . . . = . . . =C2=A0 8


1.=C2=A0 Introduction

=C2=A0 =C2=A0RPL [RFC6550] defines RPL Option to transmit = routing information.
= =C2=A0 =C2=A0RFC 6553 [RFC6553] defines how to transmit in a Hop-By-Hop Opt= ion RPL
=C2=A0 =C2=A0I= nformation,such as information to avoid and detect loops.=C2=A0 RFC 6554
=C2=A0 =C2=A0[RFC6554] d= efines the use of Extension header for Source Routing.
TW> this is a bit confusing to me. AFAI= CT:
TW> - RFC6550 d= efines the RPL routing protocol
TW> - RFC6553 defines the "RPL option", carried with= in the IPv6 Hop-by-Hop
TW> =C2=A0 header to =C2=A0quickly identify inconsistencies in the rout= ing topology
TW> - = RFC6554 defines the "RPL Source Route Header", an IPv6 Extension<= /font>
=C2=A0 =C2=A0 =C2=A0 H= eader to deliver datagrams within a RPL routing domain

=C2=A0 =C2=A0Several discussions in
TW> the
=C2=A0 =C2=A0ROLL/6lo/6tisch
TW> 6tisch -> 6TiSCH
=C2=A0 =C2=A0Mailing Lists took place=
=C2=A0 =C2=A0focusing in the= definition
TW> of<= /font>
=C2=A0 =C2=A0how to co= mpress RPL Information in
=C2=A0 =C2=A0constrained environment.=C2=A0 ROLL Virtual Interim Meetin= g (02-2015)
=C2=A0 =C2= =A0concluded that there is a need to define how to use RFC 6553, RFC6554
TW> you have to decid= e whether you use "RFC 123" or "RFC123". I would=
TW> recommend you replace= this by a hyperlink
= =C2=A0 =C2=A0and tunneling (IP-in-IP)
TW> I would say "and IP-in-IP encapsulation"
=C2=A0 =C2=A0to be able= to set the correct environment
=C2=A0 =C2=A0for compression.

2.=C2=A0 Terminology and Requirements Language

TW> you're actually not using any of this language in the d= raft.
TW> if you ke= ep it that way, and since the draft is informational
TW> I would recommend to remove this sect= ion

<= div>


Robles &= ; Richardson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]
=0C
<= font face=3D"monospace, monospace">Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


= =C2=A0 =C2=A0The key words "MUST", "MUST NOT", "RE= QUIRED", "SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SH= OULD NOT", "RECOMMENDED", "MAY", and "OPTIONA= L" in this
=C2=A0= =C2=A0document are to be interpreted as described in RFC 2119 [RFC2119].

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0Terminology defined in [RFC= 7102]

3.=C2=A0 Sample/reference topolog= y

=C2=A0 =C2=A0In a typical topology we= found
TW> "we= found" reads strange. What about "A RPL network is composed of
TW> ...[6LR,6LBR]...= logically organized in a DODAG structure".
=C2=A0 =C2=A06LBR (6LoWPAN Border Router), 6lR
TW> 6LR
=
=C2=A0 =C2=A0(6LoWPAN Router) and = 6LN (6LoWPAN Node) as leaf connected in a DODAG
=C2=A0 =C2=A0(Destination Oriented Directed Acycl= ic Graph).=C2=A0 Between these
=C2=A0 =C2=A0entities messages such as DIS, DIO and DAO are transm= itted.=C2=A0 RPL
=C2= =A0 =C2=A0defines the RPL Control message as an ICMPv6 information message = with
=C2=A0 =C2=A0a Ty= pe of 155.
TW> RPL = defines the RPL Control message, a new ICMPv6 message with
TW> Type 155. DIS, DIO and DAO mess= ages are all RPL Control messages
TW> but with different Code values.
=C2=A0 =C2=A0RPL supports two modes of Downwar= d traffic: Storing,
= =C2=A0 =C2=A0it is fully stateful or Non-Storing it is fully source routed.= =C2=A0 Any
=C2=A0 =C2= =A0given RPL Instance is either storing or non-storing.
TW> please specify that a RPL Instance= is either fully storing or fully
TW> non-storing, i.e. a RPL Instance with a combination of s= toring and
TW> non-= storing nodes is not supported

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=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| Upper Layers |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 RPL =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 ICMPv6 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 IPv6 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 6LoWPAN =C2=A0 =C2=A0|
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 PHY-MAC =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+



=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F= igure 1: RPL Stack










<= font face=3D"monospace, monospace">Robles & Richardson =C2=A0 =C2=A0Exp= ires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[Page 3]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 June 2015

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +---+Internet |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 +---------+
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+----+--+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|DODAG =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+---------+Root =C2=A0 +----------= +
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |6LBR =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +----+--+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+-+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--+---+ =C2=A0 =C2=A0 =C2=A0+--+---+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|6LR =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +-----+ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0+------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 +-----+-+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+----+= =C2=A0 =C2=A0 =C2=A0+-+----+ =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0+-+---+ =C2=A0 =C2=A0 +-+---+ =C2=A0 =C2=A0 =C2=A0+--+= --+ =C2=A0 =C2=A0 =C2=A0 +- --+ =C2=A0 =C2=A0 +---+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|Leaf | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|6LN =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+ =C2=A0 =C2=A0 +-----+ =C2=A0 =C2=A0 =C2= =A0+-----+ =C2=A0 =C2=A0 =C2=A0 +----+ =C2=A0 =C2=A0 +-----+


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Figure 2: A reference RPL Topology
TW> I would add a "." at end of each caption

=C2=A0 =C2=A0In different scenarios the use= of RFC 6553, RFC 6554 and tunneling
=C2=A0 =C2=A0can take place:
TW> I would say that a combination of RFC6553, RFC= 6554 and IP-in-IP
TW&g= t; encapsulation is used for the following traffic flows:
=
=C2=A0 =C2=A0-Flow from leaf to root
TW> remove newlines?
= =C2=A0 =C2=A0-Flow from leaf to Interne= t

=C2=A0 =C2=A0-Flow from leaf to leaf<= /font>

= =C2=A0 =C2=A0-Flow from Internet to lea= f

=C2=A0 =C2=A0-Flow from leaf to root<= /font>
TW> duplicate

4.=C2=A0 Example flow from leaf to root

=C2=A0 =C2=A0A leaf node generates DAO and = DIS messages and in general does not
=C2=A0 =C2=A0accept them.
TW> what do you mean by "accept"?
=C2=A0 =C2=A0Additionally, this= kind of nodes
TW> = node
=C2=A0 =C2=A0acce= pts DIO messages,
=C2= =A0 =C2=A0but in general do
TW> does
=C2= =A0 =C2=A0not generate them. =C2=A0(In inconsistency A leaf node
=C2=A0 =C2=A0generates DIO with = infinite rank, to fix it).
TW> A -> a
=

=


Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2015 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]
=0C
Internet-Draft =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


4.1.=C2=A0 Non-storing

=C2=A0 =C2=A0In non-storing
TW> mode
=C2= =A0 =C2=A0in this case
TW> remove "in this case"
=C2=A0 =C2=A0the leaf node uses Hop-By-Hop option (RFC
=C2=A0 =C2=A06553) to in= dicate the routing information to send messages to the
=C2=A0 =C2=A0DODAG root, this message is g= oing to be analyzed in each node until
=C2=A0 =C2=A0arrive the DODAG root.

=C2=A0 =C2=A0RFC 6554 was created to strictly send informatio= n between RPL routers
= =C2=A0 =C2=A0in the same RPL routing domain.=C2=A0 How it would be in 6554?=
TW> I assume a &qu= ot;TODO" missing before last sentence?

=C2=A0 =C2=A0TBD: Tunneling is necessary in case that there is informa= tion to send
=C2=A0 = =C2=A0outside RPL Domain and other cases?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6LBR |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+--+
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0LoWPAN_HC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0Route=3D 6LN-6LR-6LBR=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0+---+-+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0| 6LR |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 LoWPAN_HC
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = | =C2=A0 Route=3D 6LN-6LR-6LBR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6LN |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----= -+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Figure 3: From leaf to Root - Non-Storing Mode

TW> I don't fully understand what message this= figure conveys
TW>= I would use A B and C to name the nodes, and write their role
=
TW> next to them



4.2.=C2=A0 S= toring

=C2=A0 =C2=A0IP6 6553{X,Y] ?ipip= payload.
TW> somet= hing's wrong
=C2= =A0 =C2=A0In storing mode is suitable the use of
=C2=A0 =C2=A0RFC 6553 to send RPL Information th= rough HBH field checking the
=C2=A0 =C2=A0routing table to find out where to send the message.
TW> I don't under= stand "checking the routing table to find out where
<= font face=3D"monospace, monospace">TW> to send the message"<= /div>
=C2=A0 =C2=A0It may include
=C2=A0 =C2=A0IP-in-IP e= ncapsulation to transmit information not related with the
= =C2=A0 =C2=A0RPL domain.
TW> I would expand this info




Robles & Richardson =C2=A0 =C2= =A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Page 5]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------+
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6LBR |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0LoWPAN_HC
<= font face=3D"monospace, monospace">=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=A00x63|HBH Data<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+---+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| 6LR | 6LR check in routing tabl= e
=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 |<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 LoWPAN_HC
=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 0x63|= HBH Data
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=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 | 6LN |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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 Figure 4: From leaf to Ro= ot - Storing Mode

=
5.=C2=A0 Example flow= from leaf to Internet

5.1.=C2=A0 Non-s= toring

=C2=A0 =C2=A0In this case the IP= -in-IP encapsulation should take place to send
=C2=A0 =C2=A0information not related to the RPL d= omain inside of the RPL domain.

=C2=A0 = =C2=A0RPL information from RFC 6553 should not go out to Internet.=C2=A0 Th= e
=C2=A0 =C2=A0router = sould
TW> typo
=C2=A0 =C2=A0take this inf= ormation out before send the packet to
=C2=A0 =C2=A0Internet.=C2=A0 The HBH Option is going to be= analyzed in each node to the
=C2=A0 =C2=A0root.
TW> illustrate this with a fig?

=C2=A0 =C2=A0Related to RFC 6554 the Source Header route is added and remo= ved by
=C2=A0 =C2=A0DO= DAG root.=C2=A0 However, RFC 6554 was created to strictly send
=
=C2=A0 =C2=A0information between R= PL routers in the same RPL routing domain.=C2=A0 How
=C2=A0 =C2=A0it would be in 6554?
TW> this paragraph relates to= down traffic, right? The name of the section
TW> is "from leaf to Internet"








Robles & Richardson =C2=A0= =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[Page 6]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=
5.2.=C2=A0 Storing

=C2=A0 =C2=A0In storing the information o= f RFC 6553 should take away by DODAG root
=C2=A0 =C2=A0before go to Internet.
TW> but as well in non-storing, no?

6.=C2=A0 Example flow from leaf to leaf

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0can leafs insert appropriat= e headers, without ipip?=C2=A0 In [RFC6550] RPL
=C2=A0 =C2=A0allows a simple one-hop P2P optimiza= tion for both storing and non-
=C2=A0 =C2=A0storing networks.=C2=A0 A node may send a P2P packet = destined to a one-hop
= =C2=A0 =C2=A0neighbor direclty
TW> typo
= =C2=A0 =C2=A0to that node.=C2=A0 Section 9 in [RFC6550].
<= font face=3D"monospace, monospace">TW> I would say that IP-in-IP is not = needed in this case
6.1.=C2=A0 Traditio= nal storing
TW> why= "Traditional"?
=C2=A0 =C2=A0The route go through an ancestor that knows the route to t= he
=C2=A0 =C2=A0destin= ation, using HBH [RFC6553] to carry RPL Information.

6.2.=C2=A0 Traditional non-storing

=C2=A0 =C2=A0The route go through the DODAG root, using source ro= uting [RFC6554].

<= /font>
6.3.=C2=A0 P2P non-sto= ring

=
=C2=A0 =C2=A0(p2p storing?=C2=A0 T= BD)

<= div>7.=C2=A0 Example flow from Internet= to leaf

=C2=A0 =C2=A0A DODAG root do n= ot add routing extension to incoming packets, it
=C2=A0 =C2=A0instead uses tunneling.

7.1.=C2=A0 Storing

=C2=A0 =C2=A0DODAG root adds the HBH header [RFC6553] and send the pa= cket downward
=C2=A0 = =C2=A0to the destination.

7.2.=C2=A0 No= n-storing

<= /div>
=C2=A0 =C2=A0DODAG root is go= ing to add the source route header [RFC6554]

8.=C2=A0 Example flow from root to leaf

8.1.=C2=A0 Storing

=C2=A0 =C2= =A0DODAG root adds the HBH header [RFC6553] and send the packet downward
=C2=A0 =C2=A0to the dest= ination.

8.2.=C2=A0 Non-storing<= /div>




<= /font>
Robles & Richardso= n =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0[Page 7]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 =C2=A0D= ODAG root is going to add the source route header [RFC6554]

9.=C2=A0 IANA Considerations

=C2=A0 =C2=A0There are no IANA considerations related to this do= cument.

10.=C2=A0 Security Consideratio= ns

=C2=A0 =C2=A0TBD.
<= font face=3D"monospace, monospace">TW> I would replace TBD by TODO, per = usual covention

11.=C2=A0 Acknowledgeme= nts
TW> typo=

=C2=A0 =C2=A0This work is partially funded by= the FP7 Marie Curie Initial Training
=C2=A0 =C2=A0Network (ITN) METRICS project (grant agreement= No. =C2=A0607728)
12.=C2=A0 References=

12.1.=C2=A0 Normative References

=C2=A0 =C2=A0[RFC2119] =C2=A0Bradner, S., &q= uot;Key words for use in RFCs to Indicate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Requir= ement Levels", BCP 14, RFC 2119, March 1997.

=C2=A0 =C2=A0[RFC6550] =C2=A0Winter, T., Thubert, P., Brandt, A.= , Hui, J., Kelsey, R.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Levis, P., Pister, K., St= ruik, R., Vasseur, JP., and R.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alexander, "= RPL: IPv6 Routing Protocol for Low-Power and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Los= sy Networks", RFC 6550, March 2012.

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Power and Lossy Networks (RPL= ) Option for Carrying RPL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Information in Data-Pl= ane Datagrams", RFC 6553, March
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2012.

=C2=A0 =C2=A0[RFC6554] =C2=A0Hui, J., Vasseu= r, JP., Culler, D., and V. Manral, "An IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Routing Header for Source Routes with the Routing Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 for Low-Power and Lossy Networks (RPL)", RFC 6554, March=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 2012.

12.2.= =C2=A0 Informative References

=C2=A0 = =C2=A0[RFC7102] =C2=A0Vasseur, JP., "Terms Used in Routing for Low-Pow= er and
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lossy Networks", RFC 7102, January = 2014.

Authors' Addresses







<= br>
Robles & Richa= rdson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 8]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 = =C2=A0Maria Ines Robles
=C2=A0 =C2=A0Jorvas =C2=A002420
=C2=A0 =C2=A0Finland

= =C2=A0 =C2=A0Email: maria= .ines.robles@ericsson.com


=C2=A0 =C2=A0Michael C. Ri= chardson
=C2=A0 =C2=A0= Sandelman Software Works
=C2=A0 =C2=A0470 Dawson Avenue
=C2=A0 =C2=A0Ottawa, ON =C2=A0K1Z 5V7
=C2=A0 =C2=A0CA

=C2=A0 =C2=A0Email: mcr+iet= f@sandelman.ca
=C2= =A0 =C2=A0URI: =C2=A0 http://www.sande= lman.ca/









<= /div>




<= /font>

=









<= br>

<= div>



=

Robles & Richardson =C2=A0 =C2=A0Expires = December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[P= age 9]

--f46d043c81708ef24e0519f8dfff-- From nobody Fri Jul 3 09:55:22 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6201B30C3; Fri, 3 Jul 2015 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.023 X-Spam-Level: * X-Spam-Status: No, score=1.023 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_GIRL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTA35jmFOFeM; Fri, 3 Jul 2015 09:55:15 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D111B30CA; Fri, 3 Jul 2015 09:55:13 -0700 (PDT) Received: by qkhu186 with SMTP id u186so76228140qkh.0; Fri, 03 Jul 2015 09:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8ZtRTbAkEnukUaAfgqArNThBrpGwMvDmn5hFZMFU6N4=; b=MO2dojcoZOa0mQIIln/1BAzwtur5k4qPMmzyEqFeORo9svPcPWvkfP+1qiKIYjt/kf XIhdgm72eM75XnkeC3VbPYfzHe6oZqgqfzA1IIQaQSYB3E9dwt+G4rr5j4YLozGS+j6s WJ+C5WhhHOmNPaNXI+8M1lfPJMZvomW+YKfa3OiAcfZHdvrDh//RiSn0kujnCxSSH5E9 O7Iz7QVnkIQHe3CZ5DETB9L/5vfHBHOSH5AQohLjH7C00zv9zo5+dxIQY4tR/eLVmLmu 35BahhKWS2CJnpxHuJeNWvU6bnT1luAd08I38rAnIO0gK7gufn6SauIBAi+z5LZgoNRE rRoQ== MIME-Version: 1.0 X-Received: by 10.140.93.79 with SMTP id c73mr53494819qge.54.1435942512829; Fri, 03 Jul 2015 09:55:12 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.140.108.201 with HTTP; Fri, 3 Jul 2015 09:55:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Jul 2015 17:55:12 +0100 X-Google-Sender-Auth: Fa7xNEuHT6d8Ftl0sIBmkJw_Qis Message-ID: From: Robert Cragie To: Thomas Watteyne Content-Type: multipart/alternative; boundary=001a11398758652a4a0519fb6b7c Archived-At: Cc: IETF ROLL , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] Thomas' remarks on draft-robles-roll-useofrplinfo-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 16:55:21 -0000 --001a11398758652a4a0519fb6b7c Content-Type: text/plain; charset=UTF-8 Hi all, Happy to help out - I will take a closer look next week. A couple of points on first cursory read: 1) The control plane and data plane concepts should be distinct. By all means talk about control plane (i.e. RPL messages) and how they are formatted but keep this distinct from the structure of data plane packets used where RPL is used for routing. It is the data plane where IP-in-IP, RPL HbH and source routing headers are used and where the focus of the document should really be. 2) In the data plane, there are potentially two sorts of leaf node to consider: a) RPL-aware and b) not RPL-aware. This is important as it determines whether IP-in-IP is needed between nodes in a 6LoWPAN. Robert On 3 July 2015 at 14:52, Thomas Watteyne wrote: > Ines, Michael, > Please find my remarks about draft-robles-roll-useofrplinfo-00 below. > Thomas > > ---- > > TW> overall comments > TW> - this is a super important informational draft, which > TW> clears up a lot of questions > TW> - I think it would be very useful to have more example > TW> packets. We are building such information for the upcoming 6TiSCH > TW> plugtest, so I can help there. > TW> - After this is done I would recommend to ask explicitly for > TW> reviewers. Robert Cragie should be > TW> on the list of people to ask; he has provided very useful info > TW> during our discussions. > > > ROLL Working Group M.I. Robles > Internet-Draft Ericsson > Intended status: Informational M. Richardson > Expires: December 29, 2015 SSW > June 27, 2015 > > > When to use RFC 6553, 6554 and IPv6-in-IPv6 > draft-robles-roll-useofrplinfo-00 > > Abstract > > This document states different cases where RFC 6553, RFC 6554 and > IPv6-in-IPv6 encapsulation is required to set the bases to help > defining the compression of RPL routing information in LLN > environments. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on December 29, 2015. > > Copyright Notice > > Copyright (c) 2015 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > > Robles & Richardson Expires December 29, 2015 [Page 1] > Internet-Draft Useof6553 June 2015 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Terminology and Requirements Language . . . . . . . . . . . . 2 > 3. Sample/reference topology . . . . . . . . . . . . . . . . . . 3 > 4. Example flow from leaf to root . . . . . . . . . . . . . . . 4 > 4.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 5 > 4.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 5. Example flow from leaf to Internet . . . . . . . . . . . . . 6 > 5.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 6 > 5.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 6. Example flow from leaf to leaf . . . . . . . . . . . . . . . 7 > 6.1. Traditional storing . . . . . . . . . . . . . . . . . . . 7 > 6.2. Traditional non-storing . . . . . . . . . . . . . . . . . 7 > 6.3. P2P non-storing . . . . . . . . . . . . . . . . . . . . . 7 > 7. Example flow from Internet to leaf . . . . . . . . . . . . . 7 > 7.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 7.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 > 8. Example flow from root to leaf . . . . . . . . . . . . . . . 7 > 8.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 8.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 > 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 > 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 > 12.2. Informative References . . . . . . . . . . . . . . . . . 8 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 > > > 1. Introduction > > RPL [RFC6550] defines RPL Option to transmit routing information. > RFC 6553 [RFC6553] defines how to transmit in a Hop-By-Hop Option RPL > Information,such as information to avoid and detect loops. RFC 6554 > [RFC6554] defines the use of Extension header for Source Routing. > TW> this is a bit confusing to me. AFAICT: > TW> - RFC6550 defines the RPL routing protocol > TW> - RFC6553 defines the "RPL option", carried within the IPv6 Hop-by-Hop > TW> header to quickly identify inconsistencies in the routing topology > TW> - RFC6554 defines the "RPL Source Route Header", an IPv6 Extension > Header to deliver datagrams within a RPL routing domain > > Several discussions in > TW> the > ROLL/6lo/6tisch > TW> 6tisch -> 6TiSCH > Mailing Lists took place > focusing in the definition > TW> of > how to compress RPL Information in > constrained environment. ROLL Virtual Interim Meeting (02-2015) > concluded that there is a need to define how to use RFC 6553, RFC6554 > TW> you have to decide whether you use "RFC 123" or "RFC123". I would > TW> recommend you replace this by a hyperlink > and tunneling (IP-in-IP) > TW> I would say "and IP-in-IP encapsulation" > to be able to set the correct environment > for compression. > > 2. Terminology and Requirements Language > > TW> you're actually not using any of this language in the draft. > TW> if you keep it that way, and since the draft is informational > TW> I would recommend to remove this section > > > > > Robles & Richardson Expires December 29, 2015 [Page 2] > Internet-Draft Useof6553 June 2015 > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > Terminology defined in [RFC7102] > > 3. Sample/reference topology > > In a typical topology we found > TW> "we found" reads strange. What about "A RPL network is composed of > TW> ...[6LR,6LBR]... logically organized in a DODAG structure". > 6LBR (6LoWPAN Border Router), 6lR > TW> 6LR > (6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf connected in a DODAG > (Destination Oriented Directed Acyclic Graph). Between these > entities messages such as DIS, DIO and DAO are transmitted. RPL > defines the RPL Control message as an ICMPv6 information message with > a Type of 155. > TW> RPL defines the RPL Control message, a new ICMPv6 message with > TW> Type 155. DIS, DIO and DAO messages are all RPL Control messages > TW> but with different Code values. > RPL supports two modes of Downward traffic: Storing, > it is fully stateful or Non-Storing it is fully source routed. Any > given RPL Instance is either storing or non-storing. > TW> please specify that a RPL Instance is either fully storing or fully > TW> non-storing, i.e. a RPL Instance with a combination of storing and > TW> non-storing nodes is not supported > > +--------------+ > | Upper Layers | > | | > +--------------+ > | RPL | > | | > +--------------+ > | ICMPv6 | > | | > +--------------+ > | IPv6 | > | | > +--------------+ > | 6LoWPAN | > | | > +--------------+ > | PHY-MAC | > | | > +--------------+ > > > > Figure 1: RPL Stack > > > > > > > > > > > > Robles & Richardson Expires December 29, 2015 [Page 3] > Internet-Draft Useof6553 June 2015 > > > +---------+ > +---+Internet | > | +---------+ > | > +----+--+ > |DODAG | > +---------+Root +----------+ > | |6LBR | | > | +----+--+ | > | | | > | | | > | | | > +-----+-+ +--+---+ +--+---+ > |6LR | | | | | > +-----+ | | | | | > | | | | | | +------+ > | +-----+-+ +-+----+ +-+----+ | > | | | | | > | | | | | > | | | | | > +-+---+ +-+---+ +--+--+ +- --+ +---+-+ > |Leaf | | | | | | | | | > |6LN | | | | | | | | | > +-----+ +-----+ +-----+ +----+ +-----+ > > > Figure 2: A reference RPL Topology > TW> I would add a "." at end of each caption > > In different scenarios the use of RFC 6553, RFC 6554 and tunneling > can take place: > TW> I would say that a combination of RFC6553, RFC6554 and IP-in-IP > TW> encapsulation is used for the following traffic flows: > > -Flow from leaf to root > TW> remove newlines? > -Flow from leaf to Internet > > -Flow from leaf to leaf > > -Flow from Internet to leaf > > -Flow from leaf to root > TW> duplicate > > 4. Example flow from leaf to root > > A leaf node generates DAO and DIS messages and in general does not > accept them. > TW> what do you mean by "accept"? > Additionally, this kind of nodes > TW> node > accepts DIO messages, > but in general do > TW> does > not generate them. (In inconsistency A leaf node > generates DIO with infinite rank, to fix it). > TW> A -> a > > > > > Robles & Richardson Expires December 29, 2015 [Page 4] > Internet-Draft Useof6553 June 2015 > > > 4.1. Non-storing > > In non-storing > TW> mode > in this case > TW> remove "in this case" > the leaf node uses Hop-By-Hop option (RFC > 6553) to indicate the routing information to send messages to the > DODAG root, this message is going to be analyzed in each node until > arrive the DODAG root. > > RFC 6554 was created to strictly send information between RPL routers > in the same RPL routing domain. How it would be in 6554? > TW> I assume a "TODO" missing before last sentence? > > TBD: Tunneling is necessary in case that there is information to send > outside RPL Domain and other cases? > > +------+ > | | > | 6LBR | > | | > +---+--+ > | > | LoWPAN_HC > | Route= 6LN-6LR-6LBR > ^ | > | +---+-+ > | | | > | | 6LR | > | | | > | +--+--+ > | | LoWPAN_HC > | | Route= 6LN-6LR-6LBR > | | > + | > +--+--+ > | 6LN | > | | > | | > +-----+ > > Figure 3: From leaf to Root - Non-Storing Mode > > TW> I don't fully understand what message this figure conveys > TW> I would use A B and C to name the nodes, and write their role > TW> next to them > > > > 4.2. Storing > > IP6 6553{X,Y] ?ipip payload. > TW> something's wrong > In storing mode is suitable the use of > RFC 6553 to send RPL Information through HBH field checking the > routing table to find out where to send the message. > TW> I don't understand "checking the routing table to find out where > TW> to send the message" > It may include > IP-in-IP encapsulation to transmit information not related with the > RPL domain. > TW> I would expand this info > > > > > > Robles & Richardson Expires December 29, 2015 [Page 5] > Internet-Draft Useof6553 June 2015 > > > +------+ > | | > | 6LBR | > | | > +---+--+ > | > | LoWPAN_HC > | 0x63|HBH Data > ^ | > | +---+-+ > | | | > | | 6LR | 6LR check in routing table > | | | > | +--+--+ > | | LoWPAN_HC > | | 0x63|HBH Data > | | > + | > +--+--+ > | 6LN | > | | > | | > +-----+ > > Figure 4: From leaf to Root - Storing Mode > > 5. Example flow from leaf to Internet > > 5.1. Non-storing > > In this case the IP-in-IP encapsulation should take place to send > information not related to the RPL domain inside of the RPL domain. > > RPL information from RFC 6553 should not go out to Internet. The > router sould > TW> typo > take this information out before send the packet to > Internet. The HBH Option is going to be analyzed in each node to the > root. > TW> illustrate this with a fig? > > Related to RFC 6554 the Source Header route is added and removed by > DODAG root. However, RFC 6554 was created to strictly send > information between RPL routers in the same RPL routing domain. How > it would be in 6554? > TW> this paragraph relates to down traffic, right? The name of the section > TW> is "from leaf to Internet" > > > > > > > > > > Robles & Richardson Expires December 29, 2015 [Page 6] > Internet-Draft Useof6553 June 2015 > > > 5.2. Storing > > In storing the information of RFC 6553 should take away by DODAG root > before go to Internet. > TW> but as well in non-storing, no? > > 6. Example flow from leaf to leaf > > can leafs insert appropriate headers, without ipip? In [RFC6550] RPL > allows a simple one-hop P2P optimization for both storing and non- > storing networks. A node may send a P2P packet destined to a one-hop > neighbor direclty > TW> typo > to that node. Section 9 in [RFC6550]. > TW> I would say that IP-in-IP is not needed in this case > > 6.1. Traditional storing > TW> why "Traditional"? > The route go through an ancestor that knows the route to the > destination, using HBH [RFC6553] to carry RPL Information. > > 6.2. Traditional non-storing > > The route go through the DODAG root, using source routing [RFC6554]. > > 6.3. P2P non-storing > > (p2p storing? TBD) > > 7. Example flow from Internet to leaf > > A DODAG root do not add routing extension to incoming packets, it > instead uses tunneling. > > 7.1. Storing > > DODAG root adds the HBH header [RFC6553] and send the packet downward > to the destination. > > 7.2. Non-storing > > DODAG root is going to add the source route header [RFC6554] > > 8. Example flow from root to leaf > > 8.1. Storing > > DODAG root adds the HBH header [RFC6553] and send the packet downward > to the destination. > > 8.2. Non-storing > > > > > Robles & Richardson Expires December 29, 2015 [Page 7] > Internet-Draft Useof6553 June 2015 > > > DODAG root is going to add the source route header [RFC6554] > > 9. IANA Considerations > > There are no IANA considerations related to this document. > > 10. Security Considerations > > TBD. > TW> I would replace TBD by TODO, per usual covention > > 11. Acknowledgements > TW> typo > > This work is partially funded by the FP7 Marie Curie Initial Training > Network (ITN) METRICS project (grant agreement No. 607728) > > 12. References > > 12.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., > Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. > Alexander, "RPL: IPv6 Routing Protocol for Low-Power and > Lossy Networks", RFC 6550, March 2012. > > [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- > Power and Lossy Networks (RPL) Option for Carrying RPL > Information in Data-Plane Datagrams", RFC 6553, March > 2012. > > [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 > Routing Header for Source Routes with the Routing Protocol > for Low-Power and Lossy Networks (RPL)", RFC 6554, March > 2012. > > 12.2. Informative References > > [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and > Lossy Networks", RFC 7102, January 2014. > > Authors' Addresses > > > > > > > > > Robles & Richardson Expires December 29, 2015 [Page 8] > Internet-Draft Useof6553 June 2015 > > > Maria Ines Robles > Ericsson > Hirsalantie 11 > Jorvas 02420 > Finland > > Email: maria.ines.robles@ericsson.com > > > Michael C. Richardson > Sandelman Software Works > 470 Dawson Avenue > Ottawa, ON K1Z 5V7 > CA > > Email: mcr+ietf@sandelman.ca > URI: http://www.sandelman.ca/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Robles & Richardson Expires December 29, 2015 [Page 9] > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --001a11398758652a4a0519fb6b7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Happy to help out - I will take= a closer look next week.

A couple of points on fi= rst cursory read:

1) The control plane and data pl= ane concepts should be distinct. By all means talk about control plane (i.e= . RPL messages) and how they are formatted but keep this distinct from the = structure of data plane packets used where RPL is used for routing. It is t= he data plane where IP-in-IP, RPL HbH and source routing headers are used a= nd where the focus of the document should really be.
2) In the da= ta plane, there are potentially two sorts of leaf node to consider: a) RPL-= aware and b) not RPL-aware. This is important as it determines whether IP-i= n-IP is needed between nodes in a 6LoWPAN.

Robert<= /div>

On 3 J= uly 2015 at 14:52, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:
Ines= , Michael,
Please find my remarks about=C2=A0draft-robles-roll-useofrpl= info-00 below.
Thomas

----
TW> overall comment= s
TW> - this is a s= uper important informational draft, which
TW> =C2=A0 clears up a lot of questions
=
TW> - I think it would be very = useful to have more example
TW> =C2=A0 packets. We are building such information for the upcom= ing 6TiSCH
TW> =C2= =A0 plugtest, so I can help there.
TW> - After this is done I would recommend to ask=C2=A0explicitly=C2=A0for
TW> =C2=A0 reviewers. Robert Cragie should be
TW> =C2=A0 on the list o= f people to ask; he has provided very useful info
TW> =C2=A0 during our discussions.


ROLL Working Group =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 M.I. Robles
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson<= /div>
Intended status: Informationa= l =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 M. Richardson
Expires: December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SSW
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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=A0June 27, 2015


<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 When to use RFC 6553, 6554 and IPv6-in-IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-robles-roll-useofrplinfo-00

Abstract

=C2=A0 =C2=A0This document states different cases where RFC 6553, RFC 65= 54 and
=C2=A0 =C2=A0IP= v6-in-IPv6 encapsulation is required to set the bases to help
<= div>=C2=A0 =C2=A0defining the compressi= on of RPL routing information in LLN
=C2=A0 =C2=A0environments.

Status of This Memo

=C2=A0 =C2=A0Thi= s Internet-Draft is submitted in full conformance with the
=C2=A0 =C2=A0provisions of BCP 78 and = BCP 79.

=C2=A0 =C2=A0Internet-Drafts ar= e working documents of the Internet Engineering
=C2=A0 =C2=A0Task Force (IETF).=C2=A0 Note that o= ther groups may also distribute
=C2=A0 =C2=A0working documents as Internet-Drafts.=C2=A0 The list= of current Internet-

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0Internet-Drafts are draft d= ocuments valid for a maximum of six months
=C2=A0 =C2=A0and may be updated, replaced, or obsolete= d by other documents at any
=C2=A0 =C2=A0time.=C2=A0 It is inappropriate to use Internet-Drafts a= s reference
=C2=A0 =C2= =A0material or to cite them other than as "work in progress."

=C2=A0 =C2=A0This Internet-Draft will expi= re on December 29, 2015.

Copyright Noti= ce

=C2=A0 =C2=A0Copyright (c) 2015 IETF= Trust and the persons identified as the
=C2=A0 =C2=A0document authors.=C2=A0 All rights reserved= .

=C2=A0 =C2=A0This document is subject= to BCP 78 and the IETF Trust's Legal
=C2=A0 =C2=A0Provisions Relating to IETF Documents
=C2=A0 =C2=A0(http://trustee.ietf.= org/license-info) in effect on the date of
=C2=A0 =C2=A0publication of this document.=C2=A0 = Please review these documents
=C2=A0 =C2=A0carefully, as they describe your rights and restrictio= ns with respect
=C2=A0= =C2=A0to this document.=C2=A0 Code Components extracted from this document= must
=C2=A0 =C2=A0inc= lude Simplified BSD License text as described in Section 4.e of
=C2=A0 =C2=A0the Trust Legal Prov= isions and are provided without warranty as
=C2=A0 =C2=A0described in the Simplified BSD License.=



Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 1]
= =0C
Internet-Draft =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


Table of Contents

=C2=A0 = =C2=A01.=C2=A0 Introduction =C2=A0. . . . . . . . . . . . . . . . . . . . .= . . . =C2=A0 2
=C2=A0= =C2=A02.=C2=A0 Terminology and Requirements Language . . . . . . . . . . .= . =C2=A0 2
=C2=A0 =C2= =A03.=C2=A0 Sample/reference topology . . . . . . . . . . . . . . . . . . = =C2=A0 3
=C2=A0 =C2=A0= 4.=C2=A0 Example flow from leaf to root =C2=A0. . . . . . . . . . . . . . .= =C2=A0 4
=C2=A0 =C2= =A0 =C2=A04.1.=C2=A0 Non-storing . . . . . . . . . . . . . . . . . . . . . = . . =C2=A0 5
=C2=A0 = =C2=A0 =C2=A04.2.=C2=A0 Storing . . . . . . . . . . . . . . . . . . . . . .= . . . =C2=A0 5
=C2=A0= =C2=A05.=C2=A0 Example flow from leaf to Internet =C2=A0. . . . . . . . . = . . . . =C2=A0 6
=C2= =A0 =C2=A0 =C2=A05.1.=C2=A0 Non-storing . . . . . . . . . . . . . . . . . .= . . . . . =C2=A0 6
= =C2=A0 =C2=A0 =C2=A05.2.=C2=A0 Storing . . . . . . . . . . . . . . . . . . = . . . . . . . =C2=A0 7
=C2=A0 =C2=A06.=C2=A0 Example flow from leaf to leaf =C2=A0. . . . . . . .= . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.2.=C2=A0 Traditional non-storing . . . . . . . . .= . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.3.=C2=A0 P2P non-storing . . . . . . . . . . . . = . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A07.=C2=A0 Example flow from Internet to leaf =C2=A0. . . .= . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A07.1.=C2=A0 Storing . . . . . . . . . . . . . . . = . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A07.2.=C2=A0 Non-storing . . . . . . . . . . . . .= . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A08.=C2=A0 Example flow from root to leaf =C2=A0. . . . = . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A08.1.=C2=A0 Storing . . . . . . . . . . . . . .= . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A08.2.=C2=A0 Non-storing . . . . . . . . . . . = . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A09.=C2=A0 IANA Considerations . . . . . . . . . . . = . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A010. Security Considerations . . . . . . . . . . . . . .= . . . . . =C2=A0 8
= =C2=A0 =C2=A011. Acknowledgements =C2=A0. . . . . . . . . . . . . . . . . .= . . . . =C2=A0 8
=C2= =A0 =C2=A012. References =C2=A0. . . . . . . . . . . . . . . . . . . . . . = . . . =C2=A0 8
=C2=A0 = =C2=A0 =C2=A012.1.=C2=A0 Normative References . . . . . . . . . . . . . . .= . . . =C2=A0 8
=C2=A0= =C2=A0 =C2=A012.2.=C2=A0 Informative References . . . . . . . . . . . . . = . . . . =C2=A0 8
=C2= =A0 =C2=A0Authors' Addresses =C2=A0. . . . . . . . . . . . . . . . . . = . . . . . =C2=A0 8

1.=C2=A0 Introduction

=C2=A0 =C2=A0RPL [RFC6550] defines RPL Option to trans= mit routing information.
=C2=A0 =C2=A0RFC 6553 [RFC6553] defines how to transmit in a Hop-By-Hop = Option RPL
=C2=A0 =C2= =A0Information,such as information to avoid and detect loops.=C2=A0 RFC 655= 4
=C2=A0 =C2=A0[RFC655= 4] defines the use of Extension header for Source Routing.
TW> this is a bit confusing to me. = AFAICT:
TW> - RFC65= 50 defines the RPL routing protocol
TW> - RFC6553 defines the "RPL option", carried = within the IPv6 Hop-by-Hop
TW> =C2=A0 header to =C2=A0quickly identify inconsistencies in the = routing topology
TW>= ; - RFC6554 defines the "RPL Source Route Header", an IPv6 Extens= ion
=C2=A0 =C2=A0 =C2= =A0 Header to deliver datagrams within a RPL routing domain

=C2=A0 =C2=A0Several discussions in
<= font face=3D"monospace, monospace">TW> the
=C2=A0 =C2=A0ROLL/6lo/6tisch
TW> 6tisch -> 6TiSCH
=C2=A0 =C2=A0Mailing Lists took place=
=C2=A0 =C2=A0focusing= in the definition
TW&= gt; of
=C2=A0 =C2=A0ho= w to compress RPL Information in
=C2=A0 =C2=A0constrained environment.=C2=A0 ROLL Virtual Interim= Meeting (02-2015)
=C2= =A0 =C2=A0concluded that there is a need to define how to use RFC 6553, RFC= 6554
TW> you have t= o decide whether you use "RFC 123" or "RFC123". I would=
TW> recommend you = replace this by a hyperlink
=C2=A0 =C2=A0and tunneling (IP-in-IP)
TW> I would say "and IP-in-IP encapsulation&q= uot;
=C2=A0 =C2=A0to b= e able to set the correct environment
=C2=A0 =C2=A0for compression.

2.=C2=A0 Terminology and Requirements Language

TW> you're actually not using any of this language = in the draft.
TW> i= f you keep it that way, and since the draft is informational
TW> I would recommend to remove t= his section




Rob= les & Richardson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015
=


=C2=A0 =C2=A0The key words "MUST", "MUST NOT",= "REQUIRED", "SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD",= "SHOULD NOT", "RECOMMENDED", "MAY", and &quo= t;OPTIONAL" in this
=C2=A0 =C2=A0document are to be interpreted as described in RFC 2119 [RF= C2119].

=C2=A0 =C2=A0Terminology define= d in [RFC7102]

3.=C2=A0 Sample/referenc= e topology

=
=C2=A0 =C2=A0In a typical to= pology we found
TW>= "we found" reads strange. What about "A RPL network is comp= osed of
TW> ...[6LR= ,6LBR]... logically organized in a DODAG structure".
= =C2=A0 =C2=A06LBR (6LoWPAN Border Route= r), 6lR
TW> 6LR
=C2=A0 =C2=A0(6LoWPAN Rou= ter) and 6LN (6LoWPAN Node) as leaf connected in a DODAG
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0(Destination Oriented Direc= ted Acyclic Graph).=C2=A0 Between these
=C2=A0 =C2=A0entities messages such as DIS, DIO and DAO a= re transmitted.=C2=A0 RPL
=C2=A0 =C2=A0defines the RPL Control message as an ICMPv6 information m= essage with
=C2=A0 =C2= =A0a Type of 155.
TW&g= t; RPL defines the RPL Control message, a new ICMPv6 message with
TW> Type 155. DIS, DIO and D= AO messages are all RPL Control messages
TW> but with different Code values.
= =C2=A0 =C2=A0RPL supports two modes of = Downward traffic: Storing,
=C2=A0 =C2=A0it is fully stateful or Non-Storing it is fully source ro= uted.=C2=A0 Any
=C2=A0= =C2=A0given RPL Instance is either storing or non-storing.
TW> please specify that a RPL Inst= ance is either fully storing or fully
TW> non-storing, i.e. a RPL Instance with a combination = of storing and
TW> = non-storing nodes is not supported

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=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| Upper Layers |=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------= --+
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 RPL =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 ICMPv6 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 IPv6 =C2=A0 =C2=A0= =C2=A0 |
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 6LoWPAN =C2=A0 =C2=A0|
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 PHY-MAC =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+



=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F= igure 1: RPL Stack










<= font face=3D"monospace, monospace">Robles & Richardson =C2=A0 =C2=A0Exp= ires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[Page 3]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 June 2015

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +---+Internet |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 +---------+
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+----+--+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|DODAG =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+---------+Root =C2=A0 +----------= +
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |6LBR =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +----+--+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+-+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--+---+ =C2=A0 =C2=A0 =C2=A0+--+---+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|6LR =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +-----+ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0+------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 +-----+-+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+----+= =C2=A0 =C2=A0 =C2=A0+-+----+ =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0+-+---+ =C2=A0 =C2=A0 +-+---+ =C2=A0 =C2=A0 =C2=A0+--+= --+ =C2=A0 =C2=A0 =C2=A0 +- --+ =C2=A0 =C2=A0 +---+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|Leaf | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|6LN =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+ =C2=A0 =C2=A0 +-----+ =C2=A0 =C2=A0 =C2= =A0+-----+ =C2=A0 =C2=A0 =C2=A0 +----+ =C2=A0 =C2=A0 +-----+


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Figure 2: A reference RPL Topology
TW> I would add a "." at end of each caption

=C2=A0 =C2=A0In different scenarios the use= of RFC 6553, RFC 6554 and tunneling
=C2=A0 =C2=A0can take place:
TW> I would say that a combination of RFC6553, RFC= 6554 and IP-in-IP
TW&g= t; encapsulation is used for the following traffic flows:
=
=C2=A0 =C2=A0-Flow from leaf to root
TW> remove newlines?
= =C2=A0 =C2=A0-Flow from leaf to Interne= t

=C2=A0 =C2=A0-Flow from leaf to leaf<= /font>

= =C2=A0 =C2=A0-Flow from Internet to lea= f

=C2=A0 =C2=A0-Flow from leaf to root<= /font>
TW> duplicate

4.=C2=A0 Example flow from leaf to root

=C2=A0 =C2=A0A leaf node generates DAO and = DIS messages and in general does not
=C2=A0 =C2=A0accept them.
TW> what do you mean by "accept"?
=C2=A0 =C2=A0Additionally, this= kind of nodes
TW> = node
=C2=A0 =C2=A0acce= pts DIO messages,
=C2= =A0 =C2=A0but in general do
TW> does
=C2= =A0 =C2=A0not generate them. =C2=A0(In inconsistency A leaf node
=C2=A0 =C2=A0generates DIO with = infinite rank, to fix it).
TW> A -> a
=

=


Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2015 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]
=0C
Internet-Draft =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


4.1.=C2=A0 Non-storing

=C2=A0 =C2=A0In non-storing
TW> mode
=C2= =A0 =C2=A0in this case
TW> remove "in this case"
=C2=A0 =C2=A0the leaf node uses Hop-By-Hop option (RFC
=C2=A0 =C2=A06553) to in= dicate the routing information to send messages to the
=C2=A0 =C2=A0DODAG root, this message is g= oing to be analyzed in each node until
=C2=A0 =C2=A0arrive the DODAG root.

=C2=A0 =C2=A0RFC 6554 was created to strictly send informatio= n between RPL routers
= =C2=A0 =C2=A0in the same RPL routing domain.=C2=A0 How it would be in 6554?=
TW> I assume a &qu= ot;TODO" missing before last sentence?

=C2=A0 =C2=A0TBD: Tunneling is necessary in case that there is informa= tion to send
=C2=A0 = =C2=A0outside RPL Domain and other cases?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6LBR |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+--+
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0LoWPAN_HC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0Route=3D 6LN-6LR-6LBR=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0+---+-+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0| 6LR |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 LoWPAN_HC
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = | =C2=A0 Route=3D 6LN-6LR-6LBR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6LN |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----= -+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Figure 3: From leaf to Root - Non-Storing Mode

TW> I don't fully understand what message this= figure conveys
TW>= I would use A B and C to name the nodes, and write their role
=
TW> next to them



4.2.=C2=A0 S= toring

=C2=A0 =C2=A0IP6 6553{X,Y] ?ipip= payload.
TW> somet= hing's wrong
=C2= =A0 =C2=A0In storing mode is suitable the use of
=C2=A0 =C2=A0RFC 6553 to send RPL Information th= rough HBH field checking the
=C2=A0 =C2=A0routing table to find out where to send the message.
TW> I don't under= stand "checking the routing table to find out where
<= font face=3D"monospace, monospace">TW> to send the message"<= /div>
=C2=A0 =C2=A0It may include
=C2=A0 =C2=A0IP-in-IP e= ncapsulation to transmit information not related with the
= =C2=A0 =C2=A0RPL domain.
TW> I would expand this info




Robles & Richardson =C2=A0 =C2= =A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Page 5]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------+
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6LBR |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0LoWPAN_HC
<= font face=3D"monospace, monospace">=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=A00x63|HBH Data<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+---+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| 6LR | 6LR check in routing tabl= e
=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 |<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 LoWPAN_HC
=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 0x63|= HBH Data
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=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 | 6LN |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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 Figure 4: From leaf to Ro= ot - Storing Mode

=
5.=C2=A0 Example flow= from leaf to Internet

5.1.=C2=A0 Non-s= toring

=C2=A0 =C2=A0In this case the IP= -in-IP encapsulation should take place to send
=C2=A0 =C2=A0information not related to the RPL d= omain inside of the RPL domain.

=C2=A0 = =C2=A0RPL information from RFC 6553 should not go out to Internet.=C2=A0 Th= e
=C2=A0 =C2=A0router = sould
TW> typo
=C2=A0 =C2=A0take this inf= ormation out before send the packet to
=C2=A0 =C2=A0Internet.=C2=A0 The HBH Option is going to be= analyzed in each node to the
=C2=A0 =C2=A0root.
TW> illustrate this with a fig?

=C2=A0 =C2=A0Related to RFC 6554 the Source Header route is added and remo= ved by
=C2=A0 =C2=A0DO= DAG root.=C2=A0 However, RFC 6554 was created to strictly send
=
=C2=A0 =C2=A0information between R= PL routers in the same RPL routing domain.=C2=A0 How
=C2=A0 =C2=A0it would be in 6554?
TW> this paragraph relates to= down traffic, right? The name of the section
TW> is "from leaf to Internet"








Robles & Richardson =C2=A0= =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[Page 6]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=
5.2.=C2=A0 Storing

=C2=A0 =C2=A0In storing the information o= f RFC 6553 should take away by DODAG root
=C2=A0 =C2=A0before go to Internet.
TW> but as well in non-storing, no?

6.=C2=A0 Example flow from leaf to leaf

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0can leafs insert appropriat= e headers, without ipip?=C2=A0 In [RFC6550] RPL
=C2=A0 =C2=A0allows a simple one-hop P2P optimiza= tion for both storing and non-
=C2=A0 =C2=A0storing networks.=C2=A0 A node may send a P2P packet = destined to a one-hop
= =C2=A0 =C2=A0neighbor direclty
TW> typo
= =C2=A0 =C2=A0to that node.=C2=A0 Section 9 in [RFC6550].
<= font face=3D"monospace, monospace">TW> I would say that IP-in-IP is not = needed in this case
6.1.=C2=A0 Traditio= nal storing
TW> why= "Traditional"?
=C2=A0 =C2=A0The route go through an ancestor that knows the route to t= he
=C2=A0 =C2=A0destin= ation, using HBH [RFC6553] to carry RPL Information.

6.2.=C2=A0 Traditional non-storing

=C2=A0 =C2=A0The route go through the DODAG root, using source ro= uting [RFC6554].

<= /font>
6.3.=C2=A0 P2P non-sto= ring

=
=C2=A0 =C2=A0(p2p storing?=C2=A0 T= BD)

<= div>7.=C2=A0 Example flow from Internet= to leaf

=C2=A0 =C2=A0A DODAG root do n= ot add routing extension to incoming packets, it
=C2=A0 =C2=A0instead uses tunneling.

7.1.=C2=A0 Storing

=C2=A0 =C2=A0DODAG root adds the HBH header [RFC6553] and send the pa= cket downward
=C2=A0 = =C2=A0to the destination.

7.2.=C2=A0 No= n-storing

<= /div>
=C2=A0 =C2=A0DODAG root is go= ing to add the source route header [RFC6554]

8.=C2=A0 Example flow from root to leaf

8.1.=C2=A0 Storing

=C2=A0 =C2= =A0DODAG root adds the HBH header [RFC6553] and send the packet downward
=C2=A0 =C2=A0to the dest= ination.

8.2.=C2=A0 Non-storing<= /div>




<= /font>
Robles & Richardso= n =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0[Page 7]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 =C2=A0D= ODAG root is going to add the source route header [RFC6554]

9.=C2=A0 IANA Considerations

=C2=A0 =C2=A0There are no IANA considerations related to this do= cument.

10.=C2=A0 Security Consideratio= ns

=C2=A0 =C2=A0TBD.
<= font face=3D"monospace, monospace">TW> I would replace TBD by TODO, per = usual covention

11.=C2=A0 Acknowledgeme= nts
TW> typo=

=C2=A0 =C2=A0This work is partially funded by= the FP7 Marie Curie Initial Training
=C2=A0 =C2=A0Network (ITN) METRICS project (grant agreement= No. =C2=A0607728)
12.=C2=A0 References=

12.1.=C2=A0 Normative References

=C2=A0 =C2=A0[RFC2119] =C2=A0Bradner, S., &q= uot;Key words for use in RFCs to Indicate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Requir= ement Levels", BCP 14, RFC 2119, March 1997.

=C2=A0 =C2=A0[RFC6550] =C2=A0Winter, T., Thubert, P., Brandt, A.= , Hui, J., Kelsey, R.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Levis, P., Pister, K., St= ruik, R., Vasseur, JP., and R.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alexander, "= RPL: IPv6 Routing Protocol for Low-Power and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Los= sy Networks", RFC 6550, March 2012.

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Power and Lossy Networks (RPL= ) Option for Carrying RPL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Information in Data-Pl= ane Datagrams", RFC 6553, March
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2012.

=C2=A0 =C2=A0[RFC6554] =C2=A0Hui, J., Vasseu= r, JP., Culler, D., and V. Manral, "An IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Routing Header for Source Routes with the Routing Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 for Low-Power and Lossy Networks (RPL)", RFC 6554, March=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 2012.

12.2.= =C2=A0 Informative References

=C2=A0 = =C2=A0[RFC7102] =C2=A0Vasseur, JP., "Terms Used in Routing for Low-Pow= er and
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lossy Networks", RFC 7102, January = 2014.

Authors' Addresses







<= br>
Robles & Richa= rdson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 8]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 = =C2=A0Maria Ines Robles
=C2=A0 =C2=A0Jorvas =C2=A002420
=C2=A0 =C2=A0Finland

= =C2=A0 =C2=A0Email: maria.ines.robles@ericsson.com


=C2=A0 = =C2=A0Michael C. Richardson
=C2=A0 =C2=A0Sandelman Software Works
=C2=A0 =C2=A0470 Dawson Avenue
=C2=A0 =C2=A0Ottawa, ON =C2=A0K1Z 5V7=
=C2=A0 =C2=A0CA
=

=C2=A0 =C2=A0Email: mcr+ietf@sandelman.ca
= =C2=A0 =C2=A0URI: =C2=A0 http://www.sandelman.ca/













<= font face=3D"monospace, monospace">










<= br>

<= div>



=


Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2015= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 9]


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


--001a11398758652a4a0519fb6b7c-- From nobody Fri Jul 3 20:05:35 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9C11B2A24 for ; Fri, 3 Jul 2015 20:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.923 X-Spam-Level: X-Spam-Status: No, score=0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_GIRL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxUv1Yc752Jx for ; Fri, 3 Jul 2015 20:05:28 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FB91B330D for ; Fri, 3 Jul 2015 20:05:27 -0700 (PDT) Received: by lagx9 with SMTP id x9so101489114lag.1 for ; Fri, 03 Jul 2015 20:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9gktXBvA/kvaDCPlY0G74XKUp4QoTD7xtzt83GLE7n4=; b=cuAOPBcpunrhhx78rlsz1Z0Gusg6Afe6SC1+Aqw6hKid3BTGLZySbTjLVfY9k3gpk+ h+HN1cqxamXfIZsyf6Reo3fVI9TJzXIX56rL0FZ86oFuiVZ5tI4EqEJChkeroXKITkkw OtEoTMphd1Az/xLmbze1KR0ctEdtX6FKrFYTBoKa8Uopfs0OmB/ZyIgD12KN1e2nhsNd iheSAM4XhOi2LkxQdqLIIsx9mZmWrs3omfY1zgfPkCZ0dWWUnkILFKiBoTxfkkZDfv1W lXFUXSzIe627Y3dLsYDhSBPBnERsoYbZMzLirUAoczcNlT9zD/zshnMdGRolwCMsheuH oNMg== MIME-Version: 1.0 X-Received: by 10.152.26.163 with SMTP id m3mr38598511lag.86.1435979125937; Fri, 03 Jul 2015 20:05:25 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Fri, 3 Jul 2015 20:05:25 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Fri, 3 Jul 2015 20:05:25 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 Jul 2015 06:05:25 +0300 Message-ID: From: Ines Robles To: roll , Thomas Watteyne Content-Type: multipart/alternative; boundary=089e0158c73eb4db14051a03f1d4 Archived-At: Subject: Re: [Roll] Thomas' remarks on draft-robles-roll-useofrplinfo-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 03:05:34 -0000 --089e0158c73eb4db14051a03f1d4 Content-Type: text/plain; charset=UTF-8 Thank you very much Thomas for your comments, we will fix the document. Cheers, Ines On 3 Jul 2015 16:54, "Thomas Watteyne" wrote: > Ines, Michael, > Please find my remarks about draft-robles-roll-useofrplinfo-00 below. > Thomas > > ---- > > TW> overall comments > TW> - this is a super important informational draft, which > TW> clears up a lot of questions > TW> - I think it would be very useful to have more example > TW> packets. We are building such information for the upcoming 6TiSCH > TW> plugtest, so I can help there. > TW> - After this is done I would recommend to ask explicitly for > TW> reviewers. Robert Cragie should be > TW> on the list of people to ask; he has provided very useful info > TW> during our discussions. > > > ROLL Working Group M.I. Robles > Internet-Draft Ericsson > Intended status: Informational M. Richardson > Expires: December 29, 2015 SSW > June 27, 2015 > > > When to use RFC 6553, 6554 and IPv6-in-IPv6 > draft-robles-roll-useofrplinfo-00 > > Abstract > > This document states different cases where RFC 6553, RFC 6554 and > IPv6-in-IPv6 encapsulation is required to set the bases to help > defining the compression of RPL routing information in LLN > environments. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on December 29, 2015. > > Copyright Notice > > Copyright (c) 2015 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > > Robles & Richardson Expires December 29, 2015 [Page 1] > Internet-Draft Useof6553 June 2015 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Terminology and Requirements Language . . . . . . . . . . . . 2 > 3. Sample/reference topology . . . . . . . . . . . . . . . . . . 3 > 4. Example flow from leaf to root . . . . . . . . . . . . . . . 4 > 4.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 5 > 4.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 5. Example flow from leaf to Internet . . . . . . . . . . . . . 6 > 5.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 6 > 5.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 6. Example flow from leaf to leaf . . . . . . . . . . . . . . . 7 > 6.1. Traditional storing . . . . . . . . . . . . . . . . . . . 7 > 6.2. Traditional non-storing . . . . . . . . . . . . . . . . . 7 > 6.3. P2P non-storing . . . . . . . . . . . . . . . . . . . . . 7 > 7. Example flow from Internet to leaf . . . . . . . . . . . . . 7 > 7.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 7.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 > 8. Example flow from root to leaf . . . . . . . . . . . . . . . 7 > 8.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 8.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 > 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 > 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 > 12.2. Informative References . . . . . . . . . . . . . . . . . 8 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 > > > 1. Introduction > > RPL [RFC6550] defines RPL Option to transmit routing information. > RFC 6553 [RFC6553] defines how to transmit in a Hop-By-Hop Option RPL > Information,such as information to avoid and detect loops. RFC 6554 > [RFC6554] defines the use of Extension header for Source Routing. > TW> this is a bit confusing to me. AFAICT: > TW> - RFC6550 defines the RPL routing protocol > TW> - RFC6553 defines the "RPL option", carried within the IPv6 Hop-by-Hop > TW> header to quickly identify inconsistencies in the routing topology > TW> - RFC6554 defines the "RPL Source Route Header", an IPv6 Extension > Header to deliver datagrams within a RPL routing domain > > Several discussions in > TW> the > ROLL/6lo/6tisch > TW> 6tisch -> 6TiSCH > Mailing Lists took place > focusing in the definition > TW> of > how to compress RPL Information in > constrained environment. ROLL Virtual Interim Meeting (02-2015) > concluded that there is a need to define how to use RFC 6553, RFC6554 > TW> you have to decide whether you use "RFC 123" or "RFC123". I would > TW> recommend you replace this by a hyperlink > and tunneling (IP-in-IP) > TW> I would say "and IP-in-IP encapsulation" > to be able to set the correct environment > for compression. > > 2. Terminology and Requirements Language > > TW> you're actually not using any of this language in the draft. > TW> if you keep it that way, and since the draft is informational > TW> I would recommend to remove this section > > > > > Robles & Richardson Expires December 29, 2015 [Page 2] > Internet-Draft Useof6553 June 2015 > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > Terminology defined in [RFC7102] > > 3. Sample/reference topology > > In a typical topology we found > TW> "we found" reads strange. What about "A RPL network is composed of > TW> ...[6LR,6LBR]... logically organized in a DODAG structure". > 6LBR (6LoWPAN Border Router), 6lR > TW> 6LR > (6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf connected in a DODAG > (Destination Oriented Directed Acyclic Graph). Between these > entities messages such as DIS, DIO and DAO are transmitted. RPL > defines the RPL Control message as an ICMPv6 information message with > a Type of 155. > TW> RPL defines the RPL Control message, a new ICMPv6 message with > TW> Type 155. DIS, DIO and DAO messages are all RPL Control messages > TW> but with different Code values. > RPL supports two modes of Downward traffic: Storing, > it is fully stateful or Non-Storing it is fully source routed. Any > given RPL Instance is either storing or non-storing. > TW> please specify that a RPL Instance is either fully storing or fully > TW> non-storing, i.e. a RPL Instance with a combination of storing and > TW> non-storing nodes is not supported > > +--------------+ > | Upper Layers | > | | > +--------------+ > | RPL | > | | > +--------------+ > | ICMPv6 | > | | > +--------------+ > | IPv6 | > | | > +--------------+ > | 6LoWPAN | > | | > +--------------+ > | PHY-MAC | > | | > +--------------+ > > > > Figure 1: RPL Stack > > > > > > > > > > > > Robles & Richardson Expires December 29, 2015 [Page 3] > Internet-Draft Useof6553 June 2015 > > > +---------+ > +---+Internet | > | +---------+ > | > +----+--+ > |DODAG | > +---------+Root +----------+ > | |6LBR | | > | +----+--+ | > | | | > | | | > | | | > +-----+-+ +--+---+ +--+---+ > |6LR | | | | | > +-----+ | | | | | > | | | | | | +------+ > | +-----+-+ +-+----+ +-+----+ | > | | | | | > | | | | | > | | | | | > +-+---+ +-+---+ +--+--+ +- --+ +---+-+ > |Leaf | | | | | | | | | > |6LN | | | | | | | | | > +-----+ +-----+ +-----+ +----+ +-----+ > > > Figure 2: A reference RPL Topology > TW> I would add a "." at end of each caption > > In different scenarios the use of RFC 6553, RFC 6554 and tunneling > can take place: > TW> I would say that a combination of RFC6553, RFC6554 and IP-in-IP > TW> encapsulation is used for the following traffic flows: > > -Flow from leaf to root > TW> remove newlines? > -Flow from leaf to Internet > > -Flow from leaf to leaf > > -Flow from Internet to leaf > > -Flow from leaf to root > TW> duplicate > > 4. Example flow from leaf to root > > A leaf node generates DAO and DIS messages and in general does not > accept them. > TW> what do you mean by "accept"? > Additionally, this kind of nodes > TW> node > accepts DIO messages, > but in general do > TW> does > not generate them. (In inconsistency A leaf node > generates DIO with infinite rank, to fix it). > TW> A -> a > > > > > Robles & Richardson Expires December 29, 2015 [Page 4] > Internet-Draft Useof6553 June 2015 > > > 4.1. Non-storing > > In non-storing > TW> mode > in this case > TW> remove "in this case" > the leaf node uses Hop-By-Hop option (RFC > 6553) to indicate the routing information to send messages to the > DODAG root, this message is going to be analyzed in each node until > arrive the DODAG root. > > RFC 6554 was created to strictly send information between RPL routers > in the same RPL routing domain. How it would be in 6554? > TW> I assume a "TODO" missing before last sentence? > > TBD: Tunneling is necessary in case that there is information to send > outside RPL Domain and other cases? > > +------+ > | | > | 6LBR | > | | > +---+--+ > | > | LoWPAN_HC > | Route= 6LN-6LR-6LBR > ^ | > | +---+-+ > | | | > | | 6LR | > | | | > | +--+--+ > | | LoWPAN_HC > | | Route= 6LN-6LR-6LBR > | | > + | > +--+--+ > | 6LN | > | | > | | > +-----+ > > Figure 3: From leaf to Root - Non-Storing Mode > > TW> I don't fully understand what message this figure conveys > TW> I would use A B and C to name the nodes, and write their role > TW> next to them > > > > 4.2. Storing > > IP6 6553{X,Y] ?ipip payload. > TW> something's wrong > In storing mode is suitable the use of > RFC 6553 to send RPL Information through HBH field checking the > routing table to find out where to send the message. > TW> I don't understand "checking the routing table to find out where > TW> to send the message" > It may include > IP-in-IP encapsulation to transmit information not related with the > RPL domain. > TW> I would expand this info > > > > > > Robles & Richardson Expires December 29, 2015 [Page 5] > Internet-Draft Useof6553 June 2015 > > > +------+ > | | > | 6LBR | > | | > +---+--+ > | > | LoWPAN_HC > | 0x63|HBH Data > ^ | > | +---+-+ > | | | > | | 6LR | 6LR check in routing table > | | | > | +--+--+ > | | LoWPAN_HC > | | 0x63|HBH Data > | | > + | > +--+--+ > | 6LN | > | | > | | > +-----+ > > Figure 4: From leaf to Root - Storing Mode > > 5. Example flow from leaf to Internet > > 5.1. Non-storing > > In this case the IP-in-IP encapsulation should take place to send > information not related to the RPL domain inside of the RPL domain. > > RPL information from RFC 6553 should not go out to Internet. The > router sould > TW> typo > take this information out before send the packet to > Internet. The HBH Option is going to be analyzed in each node to the > root. > TW> illustrate this with a fig? > > Related to RFC 6554 the Source Header route is added and removed by > DODAG root. However, RFC 6554 was created to strictly send > information between RPL routers in the same RPL routing domain. How > it would be in 6554? > TW> this paragraph relates to down traffic, right? The name of the section > TW> is "from leaf to Internet" > > > > > > > > > > Robles & Richardson Expires December 29, 2015 [Page 6] > Internet-Draft Useof6553 June 2015 > > > 5.2. Storing > > In storing the information of RFC 6553 should take away by DODAG root > before go to Internet. > TW> but as well in non-storing, no? > > 6. Example flow from leaf to leaf > > can leafs insert appropriate headers, without ipip? In [RFC6550] RPL > allows a simple one-hop P2P optimization for both storing and non- > storing networks. A node may send a P2P packet destined to a one-hop > neighbor direclty > TW> typo > to that node. Section 9 in [RFC6550]. > TW> I would say that IP-in-IP is not needed in this case > > 6.1. Traditional storing > TW> why "Traditional"? > The route go through an ancestor that knows the route to the > destination, using HBH [RFC6553] to carry RPL Information. > > 6.2. Traditional non-storing > > The route go through the DODAG root, using source routing [RFC6554]. > > 6.3. P2P non-storing > > (p2p storing? TBD) > > 7. Example flow from Internet to leaf > > A DODAG root do not add routing extension to incoming packets, it > instead uses tunneling. > > 7.1. Storing > > DODAG root adds the HBH header [RFC6553] and send the packet downward > to the destination. > > 7.2. Non-storing > > DODAG root is going to add the source route header [RFC6554] > > 8. Example flow from root to leaf > > 8.1. Storing > > DODAG root adds the HBH header [RFC6553] and send the packet downward > to the destination. > > 8.2. Non-storing > > > > > Robles & Richardson Expires December 29, 2015 [Page 7] > Internet-Draft Useof6553 June 2015 > > > DODAG root is going to add the source route header [RFC6554] > > 9. IANA Considerations > > There are no IANA considerations related to this document. > > 10. Security Considerations > > TBD. > TW> I would replace TBD by TODO, per usual covention > > 11. Acknowledgements > TW> typo > > This work is partially funded by the FP7 Marie Curie Initial Training > Network (ITN) METRICS project (grant agreement No. 607728) > > 12. References > > 12.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., > Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. > Alexander, "RPL: IPv6 Routing Protocol for Low-Power and > Lossy Networks", RFC 6550, March 2012. > > [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- > Power and Lossy Networks (RPL) Option for Carrying RPL > Information in Data-Plane Datagrams", RFC 6553, March > 2012. > > [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 > Routing Header for Source Routes with the Routing Protocol > for Low-Power and Lossy Networks (RPL)", RFC 6554, March > 2012. > > 12.2. Informative References > > [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and > Lossy Networks", RFC 7102, January 2014. > > Authors' Addresses > > > > > > > > > Robles & Richardson Expires December 29, 2015 [Page 8] > Internet-Draft Useof6553 June 2015 > > > Maria Ines Robles > Ericsson > Hirsalantie 11 > Jorvas 02420 > Finland > > Email: maria.ines.robles@ericsson.com > > > Michael C. Richardson > Sandelman Software Works > 470 Dawson Avenue > Ottawa, ON K1Z 5V7 > CA > > Email: mcr+ietf@sandelman.ca > URI: http://www.sandelman.ca/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Robles & Richardson Expires December 29, 2015 [Page 9] > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e0158c73eb4db14051a03f1d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you very much Thomas for your comments, we will fix th= e document.
Cheers,
Ines

On 3 Jul 2015 16:54, "Thomas Watteyne"= <watteyne@eecs.berkeley.e= du> wrote:
Ines, Michael,
Please find my remarks about=C2=A0draft-r= obles-roll-useofrplinfo-00 below.
Thomas

----

TW&= gt; overall comments
T= W> - this is a super important informational draft, which
TW> =C2=A0 clears up a lot of que= stions
TW> - I thin= k it would be very useful to have more example
TW> =C2=A0 packets. We are building such infor= mation for the upcoming 6TiSCH
TW> =C2=A0 plugtest, so I can help there.
TW> - After this is done I would recomme= nd to ask=C2=A0expli= citly=C2=A0for
TW> =C2=A0 reviewers. Robert Cra= gie should be
TW> = =C2=A0 on the list of people to ask; he has provided very useful info
TW> =C2=A0 during our di= scussions.

=

ROLL Working Group =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M.I. Robles
Internet-Draft =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Ericsson
Intende= d status: Informational =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 M. Richardson
=
Expires: December 29, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SSW
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=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=A0June 27, 2015


=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When to use RFC 6553, 6554 an= d IPv6-in-IPv6
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-robles-= roll-useofrplinfo-00
<= br>
Abstract

=C2=A0 =C2=A0This document states different case= s where RFC 6553, RFC 6554 and
=C2=A0 =C2=A0IPv6-in-IPv6 encapsulation is required to set the bas= es to help
=C2=A0 =C2= =A0defining the compression of RPL routing information in LLN
<= div>=C2=A0 =C2=A0environments.

Status of This Memo

=C2=A0 =C2=A0This Internet-Draft is submitted in full conformance = with the
=C2=A0 =C2=A0= provisions of BCP 78 and BCP 79.

=C2=A0= =C2=A0Internet-Drafts are working documents of the Internet Engineering
=C2=A0 =C2=A0Task Force = (IETF).=C2=A0 Note that other groups may also distribute
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0working documents as Intern= et-Drafts.=C2=A0 The list of current Internet-

=C2=A0 =C2=A0I= nternet-Drafts are draft documents valid for a maximum of six months=
=C2=A0 =C2=A0and may be upda= ted, replaced, or obsoleted by other documents at any
=C2=A0 =C2=A0time.=C2=A0 It is inappropriat= e to use Internet-Drafts as reference
=C2=A0 =C2=A0material or to cite them other than as "w= ork in progress."

=C2=A0 =C2=A0Thi= s Internet-Draft will expire on December 29, 2015.

Copyright Notice

=C2=A0 =C2= =A0Copyright (c) 2015 IETF Trust and the persons identified as the
=C2=A0 =C2=A0document authors.= =C2=A0 All rights reserved.

=C2=A0 =C2= =A0This document is subject to BCP 78 and the IETF Trust's Legal=
=C2=A0 =C2=A0Provisions Rela= ting to IETF Documents
=C2=A0 =C2=A0(http://trustee.ietf.org/license-info) in effect on the date of
=C2=A0 =C2=A0publicatio= n of this document.=C2=A0 Please review these documents
=C2=A0 =C2=A0carefully, as they describe = your rights and restrictions with respect
=C2=A0 =C2=A0to this document.=C2=A0 Code Components ex= tracted from this document must
=C2=A0 =C2=A0include Simplified BSD License text as described in = Section 4.e of
=C2=A0 = =C2=A0the Trust Legal Provisions and are provided without warranty as
=C2=A0 =C2=A0described in t= he Simplified BSD License.


<= /div>

Robles & Richardson =C2=A0 =C2=A0Expires D= ecember 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Pa= ge 1]
=0C
In= ternet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6= 553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 June 2015

<= /font>

= Table of Contents

=C2=A0 =C2=A01.=C2=A0 Introduction =C2=A0. . . . . . . . . .= . . . . . . . . . . . . . . =C2=A0 2
=C2=A0 =C2=A02.=C2=A0 Terminology and Requirements Language= . . . . . . . . . . . . =C2=A0 2
=C2=A0 =C2=A03.=C2=A0 Sample/reference topology . . . . . . . .= . . . . . . . . . . =C2=A0 3
=C2=A0 =C2=A04.=C2=A0 Example flow from leaf to root =C2=A0. . . . = . . . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A0 =C2=A04.1.=C2=A0 Non-storing . . . . . . . . . . . .= . . . . . . . . . . . =C2=A0 5
=C2=A0 =C2=A0 =C2=A04.2.=C2=A0 Storing . . . . . . . . . . . . . = . . . . . . . . . . . . =C2=A0 5
=C2=A0 =C2=A05.=C2=A0 Example flow from leaf to Internet =C2=A0.= . . . . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A05.1.=C2=A0 Non-storing . . . . . . . . . . = . . . . . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A05.2.=C2=A0 Storing . . . . . . . . . . . .= . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A06.=C2=A0 Example flow from leaf to leaf =C2=A0. = . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.1.=C2=A0 Traditional storing . . . . .= . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.2.=C2=A0 Traditional non-storing . . = . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.3.=C2=A0 P2P non-storing . . . . . .= . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A07.=C2=A0 Example flow from Internet to leaf = =C2=A0. . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A07.1.=C2=A0 Storing . . . . . . . . .= . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A07.2.=C2=A0 Non-storing . . . . . . = . . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A08.=C2=A0 Example flow from root to leaf = =C2=A0. . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A08.1.=C2=A0 Storing . . . . . . .= . . . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A08.2.=C2=A0 Non-storing . . . = . . . . . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A09.=C2=A0 IANA Considerations . . . = . . . . . . . . . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A010. Security Considerations . . . . . .= . . . . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A011. Acknowledgements =C2=A0. . . . . . . . . . .= . . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A012. References =C2=A0. . . . . . . . . . . . . . . .= . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A012.1.=C2=A0 Normative References . . . . . . . . = . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A012.2.=C2=A0 Informative References . . . . . . .= . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0Authors' Addresses =C2=A0. . . . . . . . . . . . .= . . . . . . . . . . =C2=A0 8


1.=C2=A0 Introduction

=C2=A0 =C2=A0RPL [RFC6550] defines RPL Opti= on to transmit routing information.
=C2=A0 =C2=A0RFC 6553 [RFC6553] defines how to transmit in a = Hop-By-Hop Option RPL
= =C2=A0 =C2=A0Information,such as information to avoid and detect loops.=C2= =A0 RFC 6554
=C2=A0 = =C2=A0[RFC6554] defines the use of Extension header for Source Routing.
TW> this is a bit conf= using to me. AFAICT:
T= W> - RFC6550 defines the RPL routing protocol
TW> - RFC6553 defines the "RPL option&qu= ot;, carried within the IPv6 Hop-by-Hop
TW> =C2=A0 header to =C2=A0quickly identify inconsiste= ncies in the routing topology
TW> - RFC6554 defines the "RPL Source Route Header", a= n IPv6 Extension
=C2= =A0 =C2=A0 =C2=A0 Header to deliver datagrams within a RPL routing domain

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0Several discussions in
TW> the
=C2=A0 =C2=A0ROLL/6lo/6tisch
TW> 6tisch -> 6TiSCH
=C2=A0 =C2=A0Mailing List= s took place
=C2=A0 = =C2=A0focusing in the definition
TW> of
= =C2=A0 =C2=A0how to compress RPL Information in
=C2=A0 =C2=A0constrained environment.=C2=A0 ROLL = Virtual Interim Meeting (02-2015)
=C2=A0 =C2=A0concluded that there is a need to define how to us= e RFC 6553, RFC6554
TW= > you have to decide whether you use "RFC 123" or "RFC123= ". I would
TW>= recommend you replace this by a hyperlink
=C2=A0 =C2=A0and tunneling (IP-in-IP)
TW> I would say "and IP-in-IP = encapsulation"
= =C2=A0 =C2=A0to be able to set the correct environment
=C2=A0 =C2=A0for compression.
=

2.=C2=A0 Terminology and Requirements Language

TW> you're actually not using any = of this language in the draft.
TW> if you keep it that way, and since the draft is information= al
TW> I would reco= mmend to remove this section




Robles & Richardson =C2=A0 =C2=A0Expires December 29, 201= 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]
=0C
Internet-Draft = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June = 2015

=

=C2=A0 =C2=A0The key words "MUST", &quo= t;MUST NOT", "REQUIRED", "SHALL", "SHALL NOT&= quot;,
=C2=A0 =C2=A0&q= uot;SHOULD", "SHOULD NOT", "RECOMMENDED", "MA= Y", and "OPTIONAL" in this
=C2=A0 =C2=A0document are to be interpreted as describe= d in RFC 2119 [RFC2119].

=C2=A0 =C2=A0T= erminology defined in [RFC7102]

3.=C2= =A0 Sample/reference topology

=C2=A0 = =C2=A0In a typical topology we found
TW> "we found" reads strange. What about "= A RPL network is composed of
TW> ...[6LR,6LBR]... logically organized in a DODAG structure&quo= t;.
=C2=A0 =C2=A06LBR = (6LoWPAN Border Router), 6lR
TW> 6LR
=C2= =A0 =C2=A0(6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf connected in a DO= DAG
=C2=A0 =C2=A0(Dest= ination Oriented Directed Acyclic Graph).=C2=A0 Between these
<= div>=C2=A0 =C2=A0entities messages such= as DIS, DIO and DAO are transmitted.=C2=A0 RPL
=C2=A0 =C2=A0defines the RPL Control message as a= n ICMPv6 information message with
=C2=A0 =C2=A0a Type of 155.
TW> RPL defines the RPL Control message, a new ICMPv6 = message with
TW> Ty= pe 155. DIS, DIO and DAO messages are all RPL Control messages
=
TW> but with different Code val= ues.
=C2=A0 =C2=A0RPL = supports two modes of Downward traffic: Storing,
=C2=A0 =C2=A0it is fully stateful or Non-Storing= it is fully source routed.=C2=A0 Any
=C2=A0 =C2=A0given RPL Instance is either storing or non-st= oring.
TW> please s= pecify that a RPL Instance is either fully storing or fully
TW> non-storing, i.e. a RPL Instan= ce with a combination of storing and
TW> non-storing nodes is not supported
<= font face=3D"monospace, monospace">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=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| = Upper Layers |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 RPL =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----= ---------+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 ICMPv6 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 IPv6 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 6LoWPAN =C2=A0= =C2=A0|
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 PHY-MAC =C2=A0 =C2=A0|
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+



= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Figure 1: RPL Stack



=




=




Robles & R= ichardson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 3]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----= -----+
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+Internet |
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 +---------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|DODAG= =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+----= -----+Root =C2=A0 +----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 |6LBR =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----+--+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+-----+-+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--+---+ =C2=A0 =C2=A0 =C2=A0+--+-= --+
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|6LR =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0+------+
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +-----+-+ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +-+----+ =C2=A0 =C2=A0 =C2=A0+-+----+ =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+---+ =C2=A0 =C2=A0 += -+---+ =C2=A0 =C2=A0 =C2=A0+--+--+ =C2=A0 =C2=A0 =C2=A0 +- --+ =C2=A0 =C2= =A0 +---+-+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|Leaf | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|6LN =C2=A0| =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+ =C2=A0 =C2= =A0 +-----+ =C2=A0 =C2=A0 =C2=A0+-----+ =C2=A0 =C2=A0 =C2=A0 +----+ =C2=A0 = =C2=A0 +-----+


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 2: A reference RPL Topology
TW> I would add a "."= ; at end of each caption

=C2=A0 =C2=A0I= n different scenarios the use of RFC 6553, RFC 6554 and tunneling
=C2=A0 =C2=A0can take place:
TW> I would say that = a combination of RFC6553, RFC6554 and IP-in-IP
TW> encapsulation is used for the following tr= affic flows:

=C2=A0 =C2=A0-Flow from le= af to root
TW> remo= ve newlines?
=C2=A0 = =C2=A0-Flow from leaf to Internet

=C2= =A0 =C2=A0-Flow from leaf to leaf

=C2= =A0 =C2=A0-Flow from Internet to leaf

= =C2=A0 =C2=A0-Flow from leaf to root
TW> duplicate

4.=C2= =A0 Example flow from leaf to root

=C2= =A0 =C2=A0A leaf node generates DAO and DIS messages and in general does no= t
=C2=A0 =C2=A0accept = them.
TW> what do y= ou mean by "accept"?
=C2=A0 =C2=A0Additionally, this kind of nodes
TW> node
=C2=A0 =C2=A0accepts DIO messages,
= =C2=A0 =C2=A0but in general do
TW> does
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0not generate them. =C2=A0(I= n inconsistency A leaf node
=C2=A0 =C2=A0generates DIO with infinite rank, to fix it).
TW> A -> a




Robles & Richardson =C2=A0= =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[Page 4]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=
4.1.=C2=A0 Non-storin= g

=C2=A0 =C2=A0In non-storing
TW> mode
=C2=A0 =C2=A0in this case
TW> remove "in this case"= ;
=C2=A0 =C2=A0the lea= f node uses Hop-By-Hop option (RFC
=C2=A0 =C2=A06553) to indicate the routing information to send= messages to the
=C2= =A0 =C2=A0DODAG root, this message is going to be analyzed in each node unt= il
=C2=A0 =C2=A0arrive= the DODAG root.

<= /font>
=C2=A0 =C2=A0RFC 6554 = was created to strictly send information between RPL routers
=C2=A0 =C2=A0in the same RPL routing= domain.=C2=A0 How it would be in 6554?
TW> I assume a "TODO" missing before last se= ntence?

=C2=A0 =C2=A0TBD: Tunneling is = necessary in case that there is information to send
=C2=A0 =C2=A0outside RPL Domain and other cas= es?

<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0|
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | 6LBR |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0LoWPAN_HC
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0Route=3D 6LN-6LR-6LBR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+---+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| 6LR |
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0= =C2=A0 |
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0+--+--+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 | =C2=A0 LoWPAN_HC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 Route=3D 6LN-6LR-6LBR
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = |
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--+--+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | 6LN |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 3: From le= af to Root - Non-Storing Mode

TW> I = don't fully understand what message this figure conveys
TW> I would use A B and C to name = the nodes, and write their role
TW> next to them



4.2.=C2=A0 Storing

=C2=A0 =C2=A0IP6 6553{X,Y] ?ipip payload.
TW> something's wrong
=C2=A0 =C2=A0In storing mode is suit= able the use of
=C2=A0= =C2=A0RFC 6553 to send RPL Information through HBH field checking the
=C2=A0 =C2=A0routing table= to find out where to send the message.
TW> I don't understand "checking the routing = table to find out where
=C2=A0 =C2=A0It may include
=C2=A0 =C2=A0IP-in-IP encapsulation to transmit informat= ion not related with the
=C2=A0 =C2=A0RPL domain.
TW> I would expand this info

<= br>

<= div>

Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 5]
= =0C
Internet-Draft =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | 6LBR |
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 +---+--+
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0LoWPAN_HC
=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=A00x63|HBH Data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0+---+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0| 6LR | 6LR check in routing table
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0+--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 LoWPAN_HC
=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 0x63|HBH Data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =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 | 6LN |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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 Figure 4: From leaf to Root - Storing Mode

5.=C2=A0 Example flow from leaf to Internet

5.1.=C2=A0 Non-storing

=C2=A0 =C2=A0In this case the IP-in-IP encapsulation should = take place to send
=C2= =A0 =C2=A0information not related to the RPL domain inside of the RPL domai= n.

=C2=A0 =C2=A0RPL information from RF= C 6553 should not go out to Internet.=C2=A0 The
=C2=A0 =C2=A0router sould
TW> typo
=C2=A0 =C2=A0take this information out before send the = packet to
=C2=A0 =C2= =A0Internet.=C2=A0 The HBH Option is going to be analyzed in each node to t= he
=C2=A0 =C2=A0root.<= /font>
TW> illustrate this= with a fig?

=C2=A0 =C2=A0Related to RF= C 6554 the Source Header route is added and removed by
=C2=A0 =C2=A0DODAG root.=C2=A0 However, RF= C 6554 was created to strictly send
=C2=A0 =C2=A0information between RPL routers in the same RPL = routing domain.=C2=A0 How
=C2=A0 =C2=A0it would be in 6554?
TW> this paragraph relates to down traffic, right? The n= ame of the section
TW&= gt; is "from leaf to Internet"








Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2= 015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]<= /div>
=0C
Internet-Draft = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June = 2015

=

5.2.=C2=A0 Storing

=C2=A0 =C2=A0In storing the information of RFC 6553 should take away = by DODAG root
=C2=A0 = =C2=A0before go to Internet.
TW> but as well in non-storing, no?

6.=C2=A0 Example flow from leaf to leaf

=C2=A0 =C2=A0can leafs insert appropriate headers, without ipip?= =C2=A0 In [RFC6550] RPL
=C2=A0 =C2=A0st= oring networks.=C2=A0 A node may send a P2P packet destined to a one-hop
=C2=A0 =C2=A0neighbor di= reclty
TW> typo
=C2=A0 =C2=A0to that node= .=C2=A0 Section 9 in [RFC6550].
TW> I would say that IP-in-IP is not needed in this case

6.1.=C2=A0 Traditional storing
<= div>TW> why "Traditional"?=
=C2=A0 =C2=A0The rout= e go through an ancestor that knows the route to the
=C2=A0 =C2=A0destination, using HBH [RFC6553= ] to carry RPL Information.

6.2.=C2=A0 = Traditional non-storing
=C2=A0 =C2=A0Th= e route go through the DODAG root, using source routing [RFC6554].

6.3.=C2=A0 P2P non-storing

=C2=A0 =C2=A0(p2p storing?=C2=A0 TBD)

7.=C2=A0 Example flow from Internet to leaf

=C2=A0 =C2=A0A DODAG root do not add routing extension = to incoming packets, it

= 7.1.=C2=A0 Storing
=C2=A0 =C2=A0DODAG r= oot adds the HBH header [RFC6553] and send the packet downward
=
=C2=A0 =C2=A0to the destination.

<= font face=3D"monospace, monospace">7.2.=C2=A0 Non-storing
=
=C2=A0 =C2=A0DODAG root is going to add the source route= header [RFC6554]

=
8.=C2=A0 Example flow= from root to leaf
8.1.=C2=A0 Storing

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0DODAG root adds the HBH hea= der [RFC6553] and send the packet downward
=C2=A0 =C2=A0to the destination.

8.2.=C2=A0 Non-storing

<= br>

<= div>
Robles & Richardson =C2=A0 =C2=A0Expires Decembe= r 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 7]<= /font>
=0C
Internet= -Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 June 2015


=C2=A0 =C2=A0DODAG root is going to add th= e source route header [RFC6554]

9.=C2= =A0 IANA Considerations
=C2=A0 =C2=A0Th= ere are no IANA considerations related to this document.
<= font face=3D"monospace, monospace">
10.=C2=A0 Security Considerations

=C2=A0 =C2=A0TBD.
TW> I would replace TBD by TODO, per usual covention

11.=C2=A0 Acknowledgements
TW> typo

=C2=A0 =C2=A0This work is partially funded by the FP7 Marie Curie Initi= al Training
=C2=A0 =C2= =A0Network (ITN) METRICS project (grant agreement No. =C2=A0607728)<= /div>

12.=C2=A0 References

12.1.=C2=A0 Normative References

=C2=A0 =C2=A0[RFC2119] =C2=A0Bradner, S., "Key words for use in R= FCs to Indicate
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Requirement Levels", BCP 14= , RFC 2119, March 1997.
=C2=A0 =C2=A0[R= FC6550] =C2=A0Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Levis, P., Pister, K., Struik, R., Vasseur, JP., a= nd R.
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alexander, "RPL: IPv6 Routing Proto= col for Low-Power and
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lossy Networks", RFC = 6550, March 2012.

=
=C2=A0 =C2=A0[RFC6553= ] =C2=A0Hui, J. and JP. Vasseur, "The Routing Protocol for Low-=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Power and Lossy Networks (RPL) Option for Carrying RPL=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Information in Data-Plane Datagrams", RFC = 6553, March
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2012.

=C2=A0 =C2=A0[RFC6554] =C2=A0Hui, J., Vasseur, JP., Culler, D., and V= . Manral, "An IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for Low-Power= and Lossy Networks (RPL)", RFC 6554, March
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 2012.

12.2.=C2=A0 Informative Referenc= es

=C2=A0 =C2=A0[RFC7102] =C2=A0Vasseur= , JP., "Terms Used in Routing for Low-Power and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Lossy Networks", RFC 7102, January 2014.

Authors' Addresses






<= /div>

Robles & Richardson =C2=A0 =C2=A0Expires D= ecember 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Pa= ge 8]
=0C
In= ternet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6= 553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 June 2015

<= /font>

= =C2=A0 =C2=A0Maria Ines Robles
=C2=A0 =C2=A0Ericsson
=C2=A0 =C2=A0Hirsalantie 11
=C2=A0 =C2=A0Jorvas =C2= =A002420
=C2=A0 =C2=A0= Finland


<= /font>

= =C2=A0 =C2=A0Michael C. Richardson
=C2=A0 =C2=A0Sandelman Sof= tware Works
=C2=A0 =C2= =A0470 Dawson Avenue
= =C2=A0 =C2=A0Ottawa, ON =C2=A0K1Z 5V7
=C2=A0 =C2=A0CA

=C2=A0 = =C2=A0Email: m= cr+ietf@sandelman.ca
=C2=A0 =C2=A0URI: =C2=A0 http://www.sandelman.ca/






<= /div>




<= /font>

=









<= br>

<= div>



=




=
Robles & Richards= on =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0[Page 9]


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

--089e0158c73eb4db14051a03f1d4-- From nobody Fri Jul 3 20:58:27 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C841B3354; Fri, 3 Jul 2015 20:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.023 X-Spam-Level: * X-Spam-Status: No, score=1.023 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_GIRL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0ZAqjuWAM1S; Fri, 3 Jul 2015 20:58:18 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 C9DB61B2AA9; Fri, 3 Jul 2015 20:58:17 -0700 (PDT) Received: by wiga1 with SMTP id a1so189710347wig.0; Fri, 03 Jul 2015 20:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OiQlSSI9+0yxRevOfFqbKSS6QSt6i5aN1baQheUENtI=; b=D9pLtFurOFJ0pHXCrOmR3u9KwmY4PENdfARRFM28F1VWu+kCUzvdBwMed1bLhhlBPr YyvmrLFx7bx5Q7Atm6mril23FmlY+3hAs6tNW8g5U1PJF9O2f95/HSWsz1Z6NI8Z/CGx G3q9ObX/lMZ777twUD7rrbMUTeTzx/hhuMxsXfRdgAz++2u5ufgFmBMbFHrX0z7txVzr uCnpldi2Nc8iajihOhBe0zpi70kQfV4hQ65H5pEIpFWdF9GdBjP3/T9h3InUbLWE/m01 UqRc0vS2TqYlZjq70gMluCDA93DrZA1VZhXWUx4V/DSm13vQ1ilROtqXcAKRiSpGZbwZ ig1g== MIME-Version: 1.0 X-Received: by 10.194.78.175 with SMTP id c15mr72230357wjx.136.1435982296578; Fri, 03 Jul 2015 20:58:16 -0700 (PDT) Sender: xvilajosana@gmail.com Received: by 10.27.86.218 with HTTP; Fri, 3 Jul 2015 20:58:16 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 Jul 2015 05:58:16 +0200 X-Google-Sender-Auth: IWZQ7rfp-Je5Q50jaRDlAtbz7wY Message-ID: From: Xavier Vilajosana To: Robert Cragie , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7bfcf874b0fea7051a04ae68 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6tisch] Thomas' remarks on draft-robles-roll-useofrplinfo-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 03:58:25 -0000 --047d7bfcf874b0fea7051a04ae68 Content-Type: text/plain; charset=UTF-8 Dear Ines, Michael, It would be also very good to have several examples (drawings) detailing how Extension headers are placed in the outer IPv6 header and how this extension headers coexist (or are concatenated) with other extension headers (non-RPL) such as IPv6 Fragment Header , IPv6 Hop-by-Hop Options Header, IPv6 Header --Inner-- (EID 7), etc.. The drawings can also show how a sequence of extension headers is followed by a transport layer protocol such as UDP and if this affects HC. The examples can be complemented with the byte streams of that headers as clarification examples or to verify compliance. It would also be good to comment about header compression and all the possibilities we have or at least point to the RFCs that detail how extension headers are compressed and when compression cannot be applied or any other consideration. I think this draft is very valuable for most of us. Thanks for the work! regards, Xavi 2015-07-03 18:55 GMT+02:00 Robert Cragie : > Hi all, > > Happy to help out - I will take a closer look next week. > > A couple of points on first cursory read: > > 1) The control plane and data plane concepts should be distinct. By all > means talk about control plane (i.e. RPL messages) and how they are > formatted but keep this distinct from the structure of data plane packets > used where RPL is used for routing. It is the data plane where IP-in-IP, > RPL HbH and source routing headers are used and where the focus of the > document should really be. > 2) In the data plane, there are potentially two sorts of leaf node to > consider: a) RPL-aware and b) not RPL-aware. This is important as it > determines whether IP-in-IP is needed between nodes in a 6LoWPAN. > > Robert > > On 3 July 2015 at 14:52, Thomas Watteyne > wrote: > >> Ines, Michael, >> Please find my remarks about draft-robles-roll-useofrplinfo-00 below. >> Thomas >> >> ---- >> >> TW> overall comments >> TW> - this is a super important informational draft, which >> TW> clears up a lot of questions >> TW> - I think it would be very useful to have more example >> TW> packets. We are building such information for the upcoming 6TiSCH >> TW> plugtest, so I can help there. >> TW> - After this is done I would recommend to ask explicitly for >> TW> reviewers. Robert Cragie should be >> TW> on the list of people to ask; he has provided very useful info >> TW> during our discussions. >> >> >> ROLL Working Group M.I. Robles >> Internet-Draft Ericsson >> Intended status: Informational M. Richardson >> Expires: December 29, 2015 SSW >> June 27, 2015 >> >> >> When to use RFC 6553, 6554 and IPv6-in-IPv6 >> draft-robles-roll-useofrplinfo-00 >> >> Abstract >> >> This document states different cases where RFC 6553, RFC 6554 and >> IPv6-in-IPv6 encapsulation is required to set the bases to help >> defining the compression of RPL routing information in LLN >> environments. >> >> Status of This Memo >> >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on December 29, 2015. >> >> Copyright Notice >> >> Copyright (c) 2015 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with respect >> to this document. Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the Simplified BSD License. >> >> >> >> Robles & Richardson Expires December 29, 2015 [Page 1] >> Internet-Draft Useof6553 June 2015 >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 >> 2. Terminology and Requirements Language . . . . . . . . . . . . 2 >> 3. Sample/reference topology . . . . . . . . . . . . . . . . . . 3 >> 4. Example flow from leaf to root . . . . . . . . . . . . . . . 4 >> 4.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 5 >> 4.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 5 >> 5. Example flow from leaf to Internet . . . . . . . . . . . . . 6 >> 5.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 6 >> 5.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 >> 6. Example flow from leaf to leaf . . . . . . . . . . . . . . . 7 >> 6.1. Traditional storing . . . . . . . . . . . . . . . . . . . 7 >> 6.2. Traditional non-storing . . . . . . . . . . . . . . . . . 7 >> 6.3. P2P non-storing . . . . . . . . . . . . . . . . . . . . . 7 >> 7. Example flow from Internet to leaf . . . . . . . . . . . . . 7 >> 7.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 >> 7.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 >> 8. Example flow from root to leaf . . . . . . . . . . . . . . . 7 >> 8.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 >> 8.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 >> 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 >> 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 >> 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 >> 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 >> 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 >> 12.2. Informative References . . . . . . . . . . . . . . . . . 8 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 >> >> >> 1. Introduction >> >> RPL [RFC6550] defines RPL Option to transmit routing information. >> RFC 6553 [RFC6553] defines how to transmit in a Hop-By-Hop Option RPL >> Information,such as information to avoid and detect loops. RFC 6554 >> [RFC6554] defines the use of Extension header for Source Routing. >> TW> this is a bit confusing to me. AFAICT: >> TW> - RFC6550 defines the RPL routing protocol >> TW> - RFC6553 defines the "RPL option", carried within the IPv6 Hop-by-Hop >> TW> header to quickly identify inconsistencies in the routing topology >> TW> - RFC6554 defines the "RPL Source Route Header", an IPv6 Extension >> Header to deliver datagrams within a RPL routing domain >> >> Several discussions in >> TW> the >> ROLL/6lo/6tisch >> TW> 6tisch -> 6TiSCH >> Mailing Lists took place >> focusing in the definition >> TW> of >> how to compress RPL Information in >> constrained environment. ROLL Virtual Interim Meeting (02-2015) >> concluded that there is a need to define how to use RFC 6553, RFC6554 >> TW> you have to decide whether you use "RFC 123" or "RFC123". I would >> TW> recommend you replace this by a hyperlink >> and tunneling (IP-in-IP) >> TW> I would say "and IP-in-IP encapsulation" >> to be able to set the correct environment >> for compression. >> >> 2. Terminology and Requirements Language >> >> TW> you're actually not using any of this language in the draft. >> TW> if you keep it that way, and since the draft is informational >> TW> I would recommend to remove this section >> >> >> >> >> Robles & Richardson Expires December 29, 2015 [Page 2] >> Internet-Draft Useof6553 June 2015 >> >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> >> Terminology defined in [RFC7102] >> >> 3. Sample/reference topology >> >> In a typical topology we found >> TW> "we found" reads strange. What about "A RPL network is composed of >> TW> ...[6LR,6LBR]... logically organized in a DODAG structure". >> 6LBR (6LoWPAN Border Router), 6lR >> TW> 6LR >> (6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf connected in a DODAG >> (Destination Oriented Directed Acyclic Graph). Between these >> entities messages such as DIS, DIO and DAO are transmitted. RPL >> defines the RPL Control message as an ICMPv6 information message with >> a Type of 155. >> TW> RPL defines the RPL Control message, a new ICMPv6 message with >> TW> Type 155. DIS, DIO and DAO messages are all RPL Control messages >> TW> but with different Code values. >> RPL supports two modes of Downward traffic: Storing, >> it is fully stateful or Non-Storing it is fully source routed. Any >> given RPL Instance is either storing or non-storing. >> TW> please specify that a RPL Instance is either fully storing or fully >> TW> non-storing, i.e. a RPL Instance with a combination of storing and >> TW> non-storing nodes is not supported >> >> +--------------+ >> | Upper Layers | >> | | >> +--------------+ >> | RPL | >> | | >> +--------------+ >> | ICMPv6 | >> | | >> +--------------+ >> | IPv6 | >> | | >> +--------------+ >> | 6LoWPAN | >> | | >> +--------------+ >> | PHY-MAC | >> | | >> +--------------+ >> >> >> >> Figure 1: RPL Stack >> >> >> >> >> >> >> >> >> >> >> >> Robles & Richardson Expires December 29, 2015 [Page 3] >> Internet-Draft Useof6553 June 2015 >> >> >> +---------+ >> +---+Internet | >> | +---------+ >> | >> +----+--+ >> |DODAG | >> +---------+Root +----------+ >> | |6LBR | | >> | +----+--+ | >> | | | >> | | | >> | | | >> +-----+-+ +--+---+ +--+---+ >> |6LR | | | | | >> +-----+ | | | | | >> | | | | | | +------+ >> | +-----+-+ +-+----+ +-+----+ | >> | | | | | >> | | | | | >> | | | | | >> +-+---+ +-+---+ +--+--+ +- --+ +---+-+ >> |Leaf | | | | | | | | | >> |6LN | | | | | | | | | >> +-----+ +-----+ +-----+ +----+ +-----+ >> >> >> Figure 2: A reference RPL Topology >> TW> I would add a "." at end of each caption >> >> In different scenarios the use of RFC 6553, RFC 6554 and tunneling >> can take place: >> TW> I would say that a combination of RFC6553, RFC6554 and IP-in-IP >> TW> encapsulation is used for the following traffic flows: >> >> -Flow from leaf to root >> TW> remove newlines? >> -Flow from leaf to Internet >> >> -Flow from leaf to leaf >> >> -Flow from Internet to leaf >> >> -Flow from leaf to root >> TW> duplicate >> >> 4. Example flow from leaf to root >> >> A leaf node generates DAO and DIS messages and in general does not >> accept them. >> TW> what do you mean by "accept"? >> Additionally, this kind of nodes >> TW> node >> accepts DIO messages, >> but in general do >> TW> does >> not generate them. (In inconsistency A leaf node >> generates DIO with infinite rank, to fix it). >> TW> A -> a >> >> >> >> >> Robles & Richardson Expires December 29, 2015 [Page 4] >> Internet-Draft Useof6553 June 2015 >> >> >> 4.1. Non-storing >> >> In non-storing >> TW> mode >> in this case >> TW> remove "in this case" >> the leaf node uses Hop-By-Hop option (RFC >> 6553) to indicate the routing information to send messages to the >> DODAG root, this message is going to be analyzed in each node until >> arrive the DODAG root. >> >> RFC 6554 was created to strictly send information between RPL routers >> in the same RPL routing domain. How it would be in 6554? >> TW> I assume a "TODO" missing before last sentence? >> >> TBD: Tunneling is necessary in case that there is information to send >> outside RPL Domain and other cases? >> >> +------+ >> | | >> | 6LBR | >> | | >> +---+--+ >> | >> | LoWPAN_HC >> | Route= 6LN-6LR-6LBR >> ^ | >> | +---+-+ >> | | | >> | | 6LR | >> | | | >> | +--+--+ >> | | LoWPAN_HC >> | | Route= 6LN-6LR-6LBR >> | | >> + | >> +--+--+ >> | 6LN | >> | | >> | | >> +-----+ >> >> Figure 3: From leaf to Root - Non-Storing Mode >> >> TW> I don't fully understand what message this figure conveys >> TW> I would use A B and C to name the nodes, and write their role >> TW> next to them >> >> >> >> 4.2. Storing >> >> IP6 6553{X,Y] ?ipip payload. >> TW> something's wrong >> In storing mode is suitable the use of >> RFC 6553 to send RPL Information through HBH field checking the >> routing table to find out where to send the message. >> TW> I don't understand "checking the routing table to find out where >> TW> to send the message" >> It may include >> IP-in-IP encapsulation to transmit information not related with the >> RPL domain. >> TW> I would expand this info >> >> >> >> >> >> Robles & Richardson Expires December 29, 2015 [Page 5] >> Internet-Draft Useof6553 June 2015 >> >> >> +------+ >> | | >> | 6LBR | >> | | >> +---+--+ >> | >> | LoWPAN_HC >> | 0x63|HBH Data >> ^ | >> | +---+-+ >> | | | >> | | 6LR | 6LR check in routing table >> | | | >> | +--+--+ >> | | LoWPAN_HC >> | | 0x63|HBH Data >> | | >> + | >> +--+--+ >> | 6LN | >> | | >> | | >> +-----+ >> >> Figure 4: From leaf to Root - Storing Mode >> >> 5. Example flow from leaf to Internet >> >> 5.1. Non-storing >> >> In this case the IP-in-IP encapsulation should take place to send >> information not related to the RPL domain inside of the RPL domain. >> >> RPL information from RFC 6553 should not go out to Internet. The >> router sould >> TW> typo >> take this information out before send the packet to >> Internet. The HBH Option is going to be analyzed in each node to the >> root. >> TW> illustrate this with a fig? >> >> Related to RFC 6554 the Source Header route is added and removed by >> DODAG root. However, RFC 6554 was created to strictly send >> information between RPL routers in the same RPL routing domain. How >> it would be in 6554? >> TW> this paragraph relates to down traffic, right? The name of the section >> TW> is "from leaf to Internet" >> >> >> >> >> >> >> >> >> >> Robles & Richardson Expires December 29, 2015 [Page 6] >> Internet-Draft Useof6553 June 2015 >> >> >> 5.2. Storing >> >> In storing the information of RFC 6553 should take away by DODAG root >> before go to Internet. >> TW> but as well in non-storing, no? >> >> 6. Example flow from leaf to leaf >> >> can leafs insert appropriate headers, without ipip? In [RFC6550] RPL >> allows a simple one-hop P2P optimization for both storing and non- >> storing networks. A node may send a P2P packet destined to a one-hop >> neighbor direclty >> TW> typo >> to that node. Section 9 in [RFC6550]. >> TW> I would say that IP-in-IP is not needed in this case >> >> 6.1. Traditional storing >> TW> why "Traditional"? >> The route go through an ancestor that knows the route to the >> destination, using HBH [RFC6553] to carry RPL Information. >> >> 6.2. Traditional non-storing >> >> The route go through the DODAG root, using source routing [RFC6554]. >> >> 6.3. P2P non-storing >> >> (p2p storing? TBD) >> >> 7. Example flow from Internet to leaf >> >> A DODAG root do not add routing extension to incoming packets, it >> instead uses tunneling. >> >> 7.1. Storing >> >> DODAG root adds the HBH header [RFC6553] and send the packet downward >> to the destination. >> >> 7.2. Non-storing >> >> DODAG root is going to add the source route header [RFC6554] >> >> 8. Example flow from root to leaf >> >> 8.1. Storing >> >> DODAG root adds the HBH header [RFC6553] and send the packet downward >> to the destination. >> >> 8.2. Non-storing >> >> >> >> >> Robles & Richardson Expires December 29, 2015 [Page 7] >> Internet-Draft Useof6553 June 2015 >> >> >> DODAG root is going to add the source route header [RFC6554] >> >> 9. IANA Considerations >> >> There are no IANA considerations related to this document. >> >> 10. Security Considerations >> >> TBD. >> TW> I would replace TBD by TODO, per usual covention >> >> 11. Acknowledgements >> TW> typo >> >> This work is partially funded by the FP7 Marie Curie Initial Training >> Network (ITN) METRICS project (grant agreement No. 607728) >> >> 12. References >> >> 12.1. Normative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., >> Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. >> Alexander, "RPL: IPv6 Routing Protocol for Low-Power and >> Lossy Networks", RFC 6550, March 2012. >> >> [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- >> Power and Lossy Networks (RPL) Option for Carrying RPL >> Information in Data-Plane Datagrams", RFC 6553, March >> 2012. >> >> [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 >> Routing Header for Source Routes with the Routing Protocol >> for Low-Power and Lossy Networks (RPL)", RFC 6554, March >> 2012. >> >> 12.2. Informative References >> >> [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and >> Lossy Networks", RFC 7102, January 2014. >> >> Authors' Addresses >> >> >> >> >> >> >> >> >> Robles & Richardson Expires December 29, 2015 [Page 8] >> Internet-Draft Useof6553 June 2015 >> >> >> Maria Ines Robles >> Ericsson >> Hirsalantie 11 >> Jorvas 02420 >> Finland >> >> Email: maria.ines.robles@ericsson.com >> >> >> Michael C. Richardson >> Sandelman Software Works >> 470 Dawson Avenue >> Ottawa, ON K1Z 5V7 >> CA >> >> Email: mcr+ietf@sandelman.ca >> URI: http://www.sandelman.ca/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Robles & Richardson Expires December 29, 2015 [Page 9] >> >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --047d7bfcf874b0fea7051a04ae68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Ines, Michael,

It would be also ve= ry good to have several examples (drawings) detailing how Extension headers= are placed in the outer IPv6 header and how this extension headers coexist= (or are concatenated) with other extension headers (non-RPL) such as=C2=A0= IPv6 Fragment= Header=C2=A0,=C2=A0IPv6 Hop-by-Hop Options Header,=C2=A0IPv6 Header --Inner-- (EID 7),= etc.. The drawings can also show how a sequence of extension headers is fo= llowed by a transport layer protocol such as UDP and if this affects HC. Th= e examples can be complemented with the byte streams of that headers as cla= rification examples or to verify compliance.=C2=A0

= It would also be good to comment about header compression and all the possi= bilities we have or at least point to the RFCs that detail how extension he= aders are compressed and when compression cannot be applied or any other co= nsideration.

I think this draft is= very valuable for most of us. Thanks for the work!

<= /span>
regards,
= Xavi
=

2015-07-03 18:55 = GMT+02:00 Robert Cragie <robert.cragie@gridmerge.com>:
Hi all,

Happy to help out - I will take a closer look next week.
=
A couple of points on first cursory read:

1) The control plane and data plane concepts should be distinct. By = all means talk about control plane (i.e. RPL messages) and how they are for= matted but keep this distinct from the structure of data plane packets used= where RPL is used for routing. It is the data plane where IP-in-IP, RPL Hb= H and source routing headers are used and where the focus of the document s= hould really be.
2) In the data plane, there are potentially two = sorts of leaf node to consider: a) RPL-aware and b) not RPL-aware. This is = important as it determines whether IP-in-IP is needed between nodes in a 6L= oWPAN.

Robert

On 3 July 2015 at 1= 4:52, Thomas Watteyne <watteyne@eecs.berkeley.edu> = wrote:
Ines, Michael,
Please find my remarks about=C2=A0draf= t-robles-roll-useofrplinfo-00 below.
Thomas

<= div>----

= TW> overall comments
TW> =C2=A0 clears up a lot of = questions
TW> - I t= hink it would be very useful to have more example
TW> =C2=A0 packets. We are building such inf= ormation for the upcoming 6TiSCH
TW> =C2=A0 plugtest, so I can help there.
TW> - After this is done I would recom= mend to ask=C2=A0exp= licitly=C2=A0= for
TW> =C2=A0 reviewers. Robert C= ragie should be
TW>= =C2=A0 on the list of people to ask; he has provided very useful info
TW> =C2=A0 during our d= iscussions.


ROLL Working Group =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M.I. Robles
Internet-Draft =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Ericsson
Intende= d status: Informational =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 M. Richardson
=
Expires: December 29, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SSW
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=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=A0June 27, 2015


=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When to use RFC 6553, 6554 an= d IPv6-in-IPv6
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-robles-= roll-useofrplinfo-00
<= br>
Abstract

=C2=A0 =C2=A0This document states different case= s where RFC 6553, RFC 6554 and
=C2=A0 =C2=A0IPv6-in-IPv6 encapsulation is required to set the bas= es to help
=C2=A0 =C2= =A0defining the compression of RPL routing information in LLN
<= div>=C2=A0 =C2=A0environments.

Status of This Memo

=C2=A0 =C2=A0This Internet-Draft is submitted in full conformance = with the
=C2=A0 =C2=A0= provisions of BCP 78 and BCP 79.

=C2=A0= =C2=A0Internet-Drafts are working documents of the Internet Engineering
=C2=A0 =C2=A0Task Force = (IETF).=C2=A0 Note that other groups may also distribute
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0working documents as Intern= et-Drafts.=C2=A0 The list of current Internet-

=C2=A0 =C2=A0I= nternet-Drafts are draft documents valid for a maximum of six months=
=C2=A0 =C2=A0and may be upda= ted, replaced, or obsoleted by other documents at any
=C2=A0 =C2=A0time.=C2=A0 It is inappropriat= e to use Internet-Drafts as reference
=C2=A0 =C2=A0material or to cite them other than as "w= ork in progress."

=C2=A0 =C2=A0Thi= s Internet-Draft will expire on December 29, 2015.

Copyright Notice

=C2=A0 =C2= =A0Copyright (c) 2015 IETF Trust and the persons identified as the
=C2=A0 =C2=A0document authors.= =C2=A0 All rights reserved.

=C2=A0 =C2= =A0This document is subject to BCP 78 and the IETF Trust's Legal=
=C2=A0 =C2=A0Provisions Rela= ting to IETF Documents
=C2=A0 =C2=A0(http://trustee.ietf.org/license-info) in effect on the date of
=C2=A0 =C2=A0publicatio= n of this document.=C2=A0 Please review these documents
=C2=A0 =C2=A0carefully, as they describe = your rights and restrictions with respect
=C2=A0 =C2=A0to this document.=C2=A0 Code Components ex= tracted from this document must
=C2=A0 =C2=A0include Simplified BSD License text as described in = Section 4.e of
=C2=A0 = =C2=A0the Trust Legal Provisions and are provided without warranty as
=C2=A0 =C2=A0described in t= he Simplified BSD License.


<= /div>

Robles & Richardson =C2=A0 =C2=A0Expires D= ecember 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Pa= ge 1]
=0C
In= ternet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6= 553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 June 2015

<= /font>

= Table of Contents

=C2=A0 =C2=A01.=C2=A0 Introduction =C2=A0. . . . . . . . . .= . . . . . . . . . . . . . . =C2=A0 2
=C2=A0 =C2=A02.=C2=A0 Terminology and Requirements Language= . . . . . . . . . . . . =C2=A0 2
=C2=A0 =C2=A03.=C2=A0 Sample/reference topology . . . . . . . .= . . . . . . . . . . =C2=A0 3
=C2=A0 =C2=A04.=C2=A0 Example flow from leaf to root =C2=A0. . . . = . . . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A0 =C2=A04.1.=C2=A0 Non-storing . . . . . . . . . . . .= . . . . . . . . . . . =C2=A0 5
=C2=A0 =C2=A0 =C2=A04.2.=C2=A0 Storing . . . . . . . . . . . . . = . . . . . . . . . . . . =C2=A0 5
=C2=A0 =C2=A05.=C2=A0 Example flow from leaf to Internet =C2=A0.= . . . . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A05.1.=C2=A0 Non-storing . . . . . . . . . . = . . . . . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A05.2.=C2=A0 Storing . . . . . . . . . . . .= . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A06.=C2=A0 Example flow from leaf to leaf =C2=A0. = . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.1.=C2=A0 Traditional storing . . . . .= . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.2.=C2=A0 Traditional non-storing . . = . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.3.=C2=A0 P2P non-storing . . . . . .= . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A07.=C2=A0 Example flow from Internet to leaf = =C2=A0. . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A07.1.=C2=A0 Storing . . . . . . . . .= . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A07.2.=C2=A0 Non-storing . . . . . . = . . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A08.=C2=A0 Example flow from root to leaf = =C2=A0. . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A08.1.=C2=A0 Storing . . . . . . .= . . . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A08.2.=C2=A0 Non-storing . . . = . . . . . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A09.=C2=A0 IANA Considerations . . . = . . . . . . . . . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A010. Security Considerations . . . . . .= . . . . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A011. Acknowledgements =C2=A0. . . . . . . . . . .= . . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A012. References =C2=A0. . . . . . . . . . . . . . . .= . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A012.1.=C2=A0 Normative References . . . . . . . . = . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A012.2.=C2=A0 Informative References . . . . . . .= . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0Authors' Addresses =C2=A0. . . . . . . . . . . . .= . . . . . . . . . . =C2=A0 8


1.=C2=A0 Introduction

=C2=A0 =C2=A0RPL [RFC6550] defines RPL Opti= on to transmit routing information.
=C2=A0 =C2=A0RFC 6553 [RFC6553] defines how to transmit in a = Hop-By-Hop Option RPL
= =C2=A0 =C2=A0Information,such as information to avoid and detect loops.=C2= =A0 RFC 6554
=C2=A0 = =C2=A0[RFC6554] defines the use of Extension header for Source Routing.
TW> this is a bit conf= using to me. AFAICT:
T= W> - RFC6550 defines the RPL routing protocol
TW> - RFC6553 defines the "RPL option&qu= ot;, carried within the IPv6 Hop-by-Hop
TW> =C2=A0 header to =C2=A0quickly identify inconsiste= ncies in the routing topology
TW> - RFC6554 defines the "RPL Source Route Header", a= n IPv6 Extension
=C2= =A0 =C2=A0 =C2=A0 Header to deliver datagrams within a RPL routing domain

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0Several discussions in
TW> the
=C2=A0 =C2=A0ROLL/6lo/6tisch
TW> 6tisch -> 6TiSCH
=C2=A0 =C2=A0Mailing List= s took place
=C2=A0 = =C2=A0focusing in the definition
TW> of
= =C2=A0 =C2=A0how to compress RPL Information in
=C2=A0 =C2=A0constrained environment.=C2=A0 ROLL = Virtual Interim Meeting (02-2015)
=C2=A0 =C2=A0concluded that there is a need to define how to us= e RFC 6553, RFC6554
TW= > you have to decide whether you use "RFC 123" or "RFC123= ". I would
TW>= recommend you replace this by a hyperlink
=C2=A0 =C2=A0and tunneling (IP-in-IP)
TW> I would say "and IP-in-IP = encapsulation"
= =C2=A0 =C2=A0to be able to set the correct environment
=C2=A0 =C2=A0for compression.
=

2.=C2=A0 Terminology and Requirements Language

TW> you're actually not using any = of this language in the draft.
TW> if you keep it that way, and since the draft is information= al
TW> I would reco= mmend to remove this section




Robles & Richardson =C2=A0 =C2=A0Expires December 29, 201= 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]
=0C
Internet-Draft = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June = 2015

=

=C2=A0 =C2=A0The key words "MUST", &quo= t;MUST NOT", "REQUIRED", "SHALL", "SHALL NOT&= quot;,
=C2=A0 =C2=A0&q= uot;SHOULD", "SHOULD NOT", "RECOMMENDED", "MA= Y", and "OPTIONAL" in this
=C2=A0 =C2=A0document are to be interpreted as describe= d in RFC 2119 [RFC2119].

=C2=A0 =C2=A0T= erminology defined in [RFC7102]

3.=C2= =A0 Sample/reference topology

=C2=A0 = =C2=A0In a typical topology we found
TW> "we found" reads strange. What about "= A RPL network is composed of
TW> ...[6LR,6LBR]... logically organized in a DODAG structure&quo= t;.
=C2=A0 =C2=A06LBR = (6LoWPAN Border Router), 6lR
TW> 6LR
=C2= =A0 =C2=A0(6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf connected in a DO= DAG
=C2=A0 =C2=A0(Dest= ination Oriented Directed Acyclic Graph).=C2=A0 Between these
<= div>=C2=A0 =C2=A0entities messages such= as DIS, DIO and DAO are transmitted.=C2=A0 RPL
=C2=A0 =C2=A0defines the RPL Control message as a= n ICMPv6 information message with
=C2=A0 =C2=A0a Type of 155.
TW> RPL defines the RPL Control message, a new ICMPv6 = message with
TW> Ty= pe 155. DIS, DIO and DAO messages are all RPL Control messages
=
TW> but with different Code val= ues.
=C2=A0 =C2=A0RPL = supports two modes of Downward traffic: Storing,
=C2=A0 =C2=A0it is fully stateful or Non-Storing= it is fully source routed.=C2=A0 Any
=C2=A0 =C2=A0given RPL Instance is either storing or non-st= oring.
TW> please s= pecify that a RPL Instance is either fully storing or fully
TW> non-storing, i.e. a RPL Instan= ce with a combination of storing and
TW> non-storing nodes is not supported
<= font face=3D"monospace, monospace">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=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| = Upper Layers |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 RPL =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----= ---------+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 ICMPv6 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 IPv6 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 6LoWPAN =C2=A0= =C2=A0|
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 PHY-MAC =C2=A0 =C2=A0|
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+



= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Figure 1: RPL Stack



=




=




Robles & R= ichardson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 3]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----= -----+
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+Internet |
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 +---------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|DODAG= =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+----= -----+Root =C2=A0 +----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 |6LBR =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----+--+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+-----+-+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--+---+ =C2=A0 =C2=A0 =C2=A0+--+-= --+
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|6LR =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0+------+
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +-----+-+ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +-+----+ =C2=A0 =C2=A0 =C2=A0+-+----+ =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+---+ =C2=A0 =C2=A0 += -+---+ =C2=A0 =C2=A0 =C2=A0+--+--+ =C2=A0 =C2=A0 =C2=A0 +- --+ =C2=A0 =C2= =A0 +---+-+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|Leaf | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|6LN =C2=A0| =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+ =C2=A0 =C2= =A0 +-----+ =C2=A0 =C2=A0 =C2=A0+-----+ =C2=A0 =C2=A0 =C2=A0 +----+ =C2=A0 = =C2=A0 +-----+


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 2: A reference RPL Topology
TW> I would add a "."= ; at end of each caption

=C2=A0 =C2=A0I= n different scenarios the use of RFC 6553, RFC 6554 and tunneling
=C2=A0 =C2=A0can take place:
TW> I would say that = a combination of RFC6553, RFC6554 and IP-in-IP
TW> encapsulation is used for the following tr= affic flows:

=C2=A0 =C2=A0-Flow from le= af to root
TW> remo= ve newlines?
=C2=A0 = =C2=A0-Flow from leaf to Internet

=C2= =A0 =C2=A0-Flow from leaf to leaf

=C2= =A0 =C2=A0-Flow from Internet to leaf

= =C2=A0 =C2=A0-Flow from leaf to root
TW> duplicate

4.=C2= =A0 Example flow from leaf to root

=C2= =A0 =C2=A0A leaf node generates DAO and DIS messages and in general does no= t
=C2=A0 =C2=A0accept = them.
TW> what do y= ou mean by "accept"?
=C2=A0 =C2=A0Additionally, this kind of nodes
TW> node
=C2=A0 =C2=A0accepts DIO messages,
= =C2=A0 =C2=A0but in general do
TW> does
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0not generate them. =C2=A0(I= n inconsistency A leaf node
=C2=A0 =C2=A0generates DIO with infinite rank, to fix it).
TW> A -> a




Robles & Richardson =C2=A0= =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[Page 4]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=
4.1.=C2=A0 Non-storin= g

=C2=A0 =C2=A0In non-storing
TW> mode
=C2=A0 =C2=A0in this case
TW> remove "in this case"= ;
=C2=A0 =C2=A0the lea= f node uses Hop-By-Hop option (RFC
=C2=A0 =C2=A06553) to indicate the routing information to send= messages to the
=C2= =A0 =C2=A0DODAG root, this message is going to be analyzed in each node unt= il
=C2=A0 =C2=A0arrive= the DODAG root.

<= /font>
=C2=A0 =C2=A0RFC 6554 = was created to strictly send information between RPL routers
=C2=A0 =C2=A0in the same RPL routing= domain.=C2=A0 How it would be in 6554?
TW> I assume a "TODO" missing before last se= ntence?

=C2=A0 =C2=A0TBD: Tunneling is = necessary in case that there is information to send
=C2=A0 =C2=A0outside RPL Domain and other cas= es?

<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0|
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | 6LBR |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0LoWPAN_HC
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0Route=3D 6LN-6LR-6LBR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+---+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| 6LR |
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0= =C2=A0 |
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0+--+--+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 | =C2=A0 LoWPAN_HC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 Route=3D 6LN-6LR-6LBR
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = |
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--+--+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | 6LN |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 3: From le= af to Root - Non-Storing Mode

TW> I = don't fully understand what message this figure conveys
TW> I would use A B and C to name = the nodes, and write their role
TW> next to them



4.2.=C2=A0 Storing

=C2=A0 =C2=A0IP6 6553{X,Y] ?ipip payload.
TW> something's wrong
=C2=A0 =C2=A0In storing mode is suit= able the use of
=C2=A0= =C2=A0RFC 6553 to send RPL Information through HBH field checking the
=C2=A0 =C2=A0routing table= to find out where to send the message.
TW> I don't understand "checking the routing = table to find out where
=C2=A0 =C2=A0It may include
=C2=A0 =C2=A0IP-in-IP encapsulation to transmit informat= ion not related with the
=C2=A0 =C2=A0RPL domain.
TW> I would expand this info

<= br>

<= div>

Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 5]
= =0C
Internet-Draft =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | 6LBR |
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 +---+--+
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0LoWPAN_HC
=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=A00x63|HBH Data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0+---+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0| 6LR | 6LR check in routing table
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0+--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 LoWPAN_HC
=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 0x63|HBH Data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =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 | 6LN |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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 Figure 4: From leaf to Root - Storing Mode

5.=C2=A0 Example flow from leaf to Internet

5.1.=C2=A0 Non-storing

=C2=A0 =C2=A0In this case the IP-in-IP encapsulation should = take place to send
=C2= =A0 =C2=A0information not related to the RPL domain inside of the RPL domai= n.

=C2=A0 =C2=A0RPL information from RF= C 6553 should not go out to Internet.=C2=A0 The
=C2=A0 =C2=A0router sould
TW> typo
=C2=A0 =C2=A0take this information out before send the = packet to
=C2=A0 =C2= =A0Internet.=C2=A0 The HBH Option is going to be analyzed in each node to t= he
=C2=A0 =C2=A0root.<= /font>
TW> illustrate this= with a fig?

=C2=A0 =C2=A0Related to RF= C 6554 the Source Header route is added and removed by
=C2=A0 =C2=A0DODAG root.=C2=A0 However, RF= C 6554 was created to strictly send
=C2=A0 =C2=A0information between RPL routers in the same RPL = routing domain.=C2=A0 How
=C2=A0 =C2=A0it would be in 6554?
TW> this paragraph relates to down traffic, right? The n= ame of the section
TW&= gt; is "from leaf to Internet"








Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2= 015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]<= /div>
=0C
Internet-Draft = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June = 2015

=

5.2.=C2=A0 Storing

=C2=A0 =C2=A0In storing the information of RFC 6553 should take away = by DODAG root
=C2=A0 = =C2=A0before go to Internet.
TW> but as well in non-storing, no?

6.=C2=A0 Example flow from leaf to leaf

=C2=A0 =C2=A0can leafs insert appropriate headers, without ipip?= =C2=A0 In [RFC6550] RPL
=C2=A0 =C2=A0st= oring networks.=C2=A0 A node may send a P2P packet destined to a one-hop
=C2=A0 =C2=A0neighbor di= reclty
TW> typo
=C2=A0 =C2=A0to that node= .=C2=A0 Section 9 in [RFC6550].
TW> I would say that IP-in-IP is not needed in this case

6.1.=C2=A0 Traditional storing
<= div>TW> why "Traditional"?=
=C2=A0 =C2=A0The rout= e go through an ancestor that knows the route to the
=C2=A0 =C2=A0destination, using HBH [RFC6553= ] to carry RPL Information.

6.2.=C2=A0 = Traditional non-storing
=C2=A0 =C2=A0Th= e route go through the DODAG root, using source routing [RFC6554].

6.3.=C2=A0 P2P non-storing

=C2=A0 =C2=A0(p2p storing?=C2=A0 TBD)

7.=C2=A0 Example flow from Internet to leaf

=C2=A0 =C2=A0A DODAG root do not add routing extension = to incoming packets, it

= 7.1.=C2=A0 Storing
=C2=A0 =C2=A0DODAG r= oot adds the HBH header [RFC6553] and send the packet downward
=
=C2=A0 =C2=A0to the destination.

<= font face=3D"monospace, monospace">7.2.=C2=A0 Non-storing
=
=C2=A0 =C2=A0DODAG root is going to add the source route= header [RFC6554]

=
8.=C2=A0 Example flow= from root to leaf
8.1.=C2=A0 Storing

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0DODAG root adds the HBH hea= der [RFC6553] and send the packet downward
=C2=A0 =C2=A0to the destination.

8.2.=C2=A0 Non-storing

<= br>

<= div>
Robles & Richardson =C2=A0 =C2=A0Expires Decembe= r 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 7]<= /font>
=0C
Internet= -Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 June 2015


=C2=A0 =C2=A0DODAG root is going to add th= e source route header [RFC6554]

9.=C2= =A0 IANA Considerations
=C2=A0 =C2=A0Th= ere are no IANA considerations related to this document.
<= font face=3D"monospace, monospace">
10.=C2=A0 Security Considerations

=C2=A0 =C2=A0TBD.
TW> I would replace TBD by TODO, per usual covention

11.=C2=A0 Acknowledgements
TW> typo

=C2=A0 =C2=A0This work is partially funded by the FP7 Marie Curie Initi= al Training
=C2=A0 =C2= =A0Network (ITN) METRICS project (grant agreement No. =C2=A0607728)<= /div>

12.=C2=A0 References

12.1.=C2=A0 Normative References

=C2=A0 =C2=A0[RFC2119] =C2=A0Bradner, S., "Key words for use in R= FCs to Indicate
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Requirement Levels", BCP 14= , RFC 2119, March 1997.
=C2=A0 =C2=A0[R= FC6550] =C2=A0Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Levis, P., Pister, K., Struik, R., Vasseur, JP., a= nd R.
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alexander, "RPL: IPv6 Routing Proto= col for Low-Power and
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lossy Networks", RFC = 6550, March 2012.

=
=C2=A0 =C2=A0[RFC6553= ] =C2=A0Hui, J. and JP. Vasseur, "The Routing Protocol for Low-=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Power and Lossy Networks (RPL) Option for Carrying RPL=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Information in Data-Plane Datagrams", RFC = 6553, March
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2012.

=C2=A0 =C2=A0[RFC6554] =C2=A0Hui, J., Vasseur, JP., Culler, D., and V= . Manral, "An IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for Low-Power= and Lossy Networks (RPL)", RFC 6554, March
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 2012.

12.2.=C2=A0 Informative Referenc= es

=C2=A0 =C2=A0[RFC7102] =C2=A0Vasseur= , JP., "Terms Used in Routing for Low-Power and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Lossy Networks", RFC 7102, January 2014.

Authors' Addresses






<= /div>

Robles & Richardson =C2=A0 =C2=A0Expires D= ecember 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Pa= ge 8]
=0C
In= ternet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6= 553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 June 2015

<= /font>

= =C2=A0 =C2=A0Maria Ines Robles
=C2=A0 =C2=A0Ericsson
=C2=A0 =C2=A0Hirsalantie 11
=C2=A0 =C2=A0Jorvas =C2= =A002420
=C2=A0 =C2=A0= Finland


<= /font>

= =C2=A0 =C2=A0Michael C. Richardson
=C2=A0 =C2=A0Sandelman Sof= tware Works
=C2=A0 =C2= =A0470 Dawson Avenue
= =C2=A0 =C2=A0Ottawa, ON =C2=A0K1Z 5V7
=C2=A0 =C2=A0CA

=C2=A0 = =C2=A0Email: m= cr+ietf@sandelman.ca
=C2=A0 =C2=A0URI: =C2=A0 http://www.sandelman.ca/






<= /div>




<= /font>

=









<= br>

<= div>



=




=
Robles & Richards= on =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0[Page 9]


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



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


--047d7bfcf874b0fea7051a04ae68-- From nobody Fri Jul 3 23:44:34 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57251A8871 for ; Fri, 3 Jul 2015 23:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.923 X-Spam-Level: X-Spam-Status: No, score=0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_GIRL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19SJAlNacCAC for ; Fri, 3 Jul 2015 23:44:26 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9981A886F for ; Fri, 3 Jul 2015 23:44:25 -0700 (PDT) Received: by laar3 with SMTP id r3so104477362laa.0 for ; Fri, 03 Jul 2015 23:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OZX9My4IHDkPN71k2u2c3/ePfX2WGrcImvXdbB1bxAg=; b=r1Q+vqUIUikUQQUWUIl7JPikdJpGC7QrAacgugkf9p7xjdw4rGU2QdQuS6O2zncDLS RUgp8JUogfgAI3u1PNw9i+x0HrAfd90FV+Rzqvph/JYfwlT0MCW7ogpFFtFgCvmaDew2 /e+2HGz6CJlWSdEFVYhit5LHc/Od2gRYun6uyzokE7GODUmC4++mgH3fpJO/UTTOvx7T S87JQGrBCVqrhKJ5lELzhw30fc/A5e+AFLDVClCZOZzwpvW5T9kJ8QyxKZrsiSQl24QW xjhnMdWKFAqQPzZY/UYJXXtozVOPqf2kckM3B+A+oDH1XLEN+QV1F7WVH9nisag+4fZX K0LA== MIME-Version: 1.0 X-Received: by 10.112.222.133 with SMTP id qm5mr39194250lbc.86.1435992263550; Fri, 03 Jul 2015 23:44:23 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Fri, 3 Jul 2015 23:44:23 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Fri, 3 Jul 2015 23:44:23 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 Jul 2015 09:44:23 +0300 Message-ID: From: Ines Robles To: roll , Xavi Vilajosana Content-Type: multipart/alternative; boundary=001a11346db0c4ed20051a0700e2 Archived-At: Subject: Re: [Roll] [6tisch] Thomas' remarks on draft-robles-roll-useofrplinfo-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 06:44:32 -0000 --001a11346db0c4ed20051a0700e2 Content-Type: text/plain; charset=UTF-8 Ok, Thanks for the suggestions Xavi :-). We will work on that. Cheers On 4 Jul 2015 06:58, "Xavier Vilajosana" wrote: > Dear Ines, Michael, > > It would be also very good to have several examples (drawings) detailing > how Extension headers are placed in the outer IPv6 header and how this > extension headers coexist (or are concatenated) with other extension > headers (non-RPL) such as IPv6 Fragment Header , IPv6 Hop-by-Hop Options > Header, IPv6 Header --Inner-- (EID 7), etc.. The drawings can also show > how a sequence of extension headers is followed by a transport layer > protocol such as UDP and if this affects HC. The examples can be > complemented with the byte streams of that headers as clarification > examples or to verify compliance. > > It would also be good to comment about header compression and all the > possibilities we have or at least point to the RFCs that detail how > extension headers are compressed and when compression cannot be applied or > any other consideration. > > I think this draft is very valuable for most of us. Thanks for the work! > > regards, > Xavi > > 2015-07-03 18:55 GMT+02:00 Robert Cragie : > >> Hi all, >> >> Happy to help out - I will take a closer look next week. >> >> A couple of points on first cursory read: >> >> 1) The control plane and data plane concepts should be distinct. By all >> means talk about control plane (i.e. RPL messages) and how they are >> formatted but keep this distinct from the structure of data plane packets >> used where RPL is used for routing. It is the data plane where IP-in-IP, >> RPL HbH and source routing headers are used and where the focus of the >> document should really be. >> 2) In the data plane, there are potentially two sorts of leaf node to >> consider: a) RPL-aware and b) not RPL-aware. This is important as it >> determines whether IP-in-IP is needed between nodes in a 6LoWPAN. >> >> Robert >> >> On 3 July 2015 at 14:52, Thomas Watteyne >> wrote: >> >>> Ines, Michael, >>> Please find my remarks about draft-robles-roll-useofrplinfo-00 below. >>> Thomas >>> >>> ---- >>> >>> TW> overall comments >>> TW> - this is a super important informational draft, which >>> TW> clears up a lot of questions >>> TW> - I think it would be very useful to have more example >>> TW> packets. We are building such information for the upcoming 6TiSCH >>> TW> plugtest, so I can help there. >>> TW> - After this is done I would recommend to ask explicitly for >>> TW> reviewers. Robert Cragie should be >>> TW> on the list of people to ask; he has provided very useful info >>> TW> during our discussions. >>> >>> >>> ROLL Working Group M.I. Robles >>> Internet-Draft Ericsson >>> Intended status: Informational M. Richardson >>> Expires: December 29, 2015 SSW >>> June 27, 2015 >>> >>> >>> When to use RFC 6553, 6554 and IPv6-in-IPv6 >>> draft-robles-roll-useofrplinfo-00 >>> >>> Abstract >>> >>> This document states different cases where RFC 6553, RFC 6554 and >>> IPv6-in-IPv6 encapsulation is required to set the bases to help >>> defining the compression of RPL routing information in LLN >>> environments. >>> >>> Status of This Memo >>> >>> This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79. >>> >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF). Note that other groups may also distribute >>> working documents as Internet-Drafts. The list of current Internet- >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>> >>> Internet-Drafts are draft documents valid for a maximum of six months >>> and may be updated, replaced, or obsoleted by other documents at any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>> >>> This Internet-Draft will expire on December 29, 2015. >>> >>> Copyright Notice >>> >>> Copyright (c) 2015 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with respect >>> to this document. Code Components extracted from this document must >>> include Simplified BSD License text as described in Section 4.e of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the Simplified BSD License. >>> >>> >>> >>> Robles & Richardson Expires December 29, 2015 [Page 1] >>> Internet-Draft Useof6553 June 2015 >>> >>> >>> Table of Contents >>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 >>> 2. Terminology and Requirements Language . . . . . . . . . . . . 2 >>> 3. Sample/reference topology . . . . . . . . . . . . . . . . . . 3 >>> 4. Example flow from leaf to root . . . . . . . . . . . . . . . 4 >>> 4.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 5 >>> 4.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 5 >>> 5. Example flow from leaf to Internet . . . . . . . . . . . . . 6 >>> 5.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 6 >>> 5.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 >>> 6. Example flow from leaf to leaf . . . . . . . . . . . . . . . 7 >>> 6.1. Traditional storing . . . . . . . . . . . . . . . . . . . 7 >>> 6.2. Traditional non-storing . . . . . . . . . . . . . . . . . 7 >>> 6.3. P2P non-storing . . . . . . . . . . . . . . . . . . . . . 7 >>> 7. Example flow from Internet to leaf . . . . . . . . . . . . . 7 >>> 7.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 >>> 7.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 >>> 8. Example flow from root to leaf . . . . . . . . . . . . . . . 7 >>> 8.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 >>> 8.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 >>> 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 >>> 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 >>> 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 >>> 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 >>> 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 >>> 12.2. Informative References . . . . . . . . . . . . . . . . . 8 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 >>> >>> >>> 1. Introduction >>> >>> RPL [RFC6550] defines RPL Option to transmit routing information. >>> RFC 6553 [RFC6553] defines how to transmit in a Hop-By-Hop Option RPL >>> Information,such as information to avoid and detect loops. RFC 6554 >>> [RFC6554] defines the use of Extension header for Source Routing. >>> TW> this is a bit confusing to me. AFAICT: >>> TW> - RFC6550 defines the RPL routing protocol >>> TW> - RFC6553 defines the "RPL option", carried within the IPv6 >>> Hop-by-Hop >>> TW> header to quickly identify inconsistencies in the routing topology >>> TW> - RFC6554 defines the "RPL Source Route Header", an IPv6 Extension >>> Header to deliver datagrams within a RPL routing domain >>> >>> Several discussions in >>> TW> the >>> ROLL/6lo/6tisch >>> TW> 6tisch -> 6TiSCH >>> Mailing Lists took place >>> focusing in the definition >>> TW> of >>> how to compress RPL Information in >>> constrained environment. ROLL Virtual Interim Meeting (02-2015) >>> concluded that there is a need to define how to use RFC 6553, RFC6554 >>> TW> you have to decide whether you use "RFC 123" or "RFC123". I would >>> TW> recommend you replace this by a hyperlink >>> and tunneling (IP-in-IP) >>> TW> I would say "and IP-in-IP encapsulation" >>> to be able to set the correct environment >>> for compression. >>> >>> 2. Terminology and Requirements Language >>> >>> TW> you're actually not using any of this language in the draft. >>> TW> if you keep it that way, and since the draft is informational >>> TW> I would recommend to remove this section >>> >>> >>> >>> >>> Robles & Richardson Expires December 29, 2015 [Page 2] >>> Internet-Draft Useof6553 June 2015 >>> >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >>> document are to be interpreted as described in RFC 2119 [RFC2119]. >>> >>> Terminology defined in [RFC7102] >>> >>> 3. Sample/reference topology >>> >>> In a typical topology we found >>> TW> "we found" reads strange. What about "A RPL network is composed of >>> TW> ...[6LR,6LBR]... logically organized in a DODAG structure". >>> 6LBR (6LoWPAN Border Router), 6lR >>> TW> 6LR >>> (6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf connected in a DODAG >>> (Destination Oriented Directed Acyclic Graph). Between these >>> entities messages such as DIS, DIO and DAO are transmitted. RPL >>> defines the RPL Control message as an ICMPv6 information message with >>> a Type of 155. >>> TW> RPL defines the RPL Control message, a new ICMPv6 message with >>> TW> Type 155. DIS, DIO and DAO messages are all RPL Control messages >>> TW> but with different Code values. >>> RPL supports two modes of Downward traffic: Storing, >>> it is fully stateful or Non-Storing it is fully source routed. Any >>> given RPL Instance is either storing or non-storing. >>> TW> please specify that a RPL Instance is either fully storing or fully >>> TW> non-storing, i.e. a RPL Instance with a combination of storing and >>> TW> non-storing nodes is not supported >>> >>> +--------------+ >>> | Upper Layers | >>> | | >>> +--------------+ >>> | RPL | >>> | | >>> +--------------+ >>> | ICMPv6 | >>> | | >>> +--------------+ >>> | IPv6 | >>> | | >>> +--------------+ >>> | 6LoWPAN | >>> | | >>> +--------------+ >>> | PHY-MAC | >>> | | >>> +--------------+ >>> >>> >>> >>> Figure 1: RPL Stack >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Robles & Richardson Expires December 29, 2015 [Page 3] >>> Internet-Draft Useof6553 June 2015 >>> >>> >>> +---------+ >>> +---+Internet | >>> | +---------+ >>> | >>> +----+--+ >>> |DODAG | >>> +---------+Root +----------+ >>> | |6LBR | | >>> | +----+--+ | >>> | | | >>> | | | >>> | | | >>> +-----+-+ +--+---+ +--+---+ >>> |6LR | | | | | >>> +-----+ | | | | | >>> | | | | | | +------+ >>> | +-----+-+ +-+----+ +-+----+ | >>> | | | | | >>> | | | | | >>> | | | | | >>> +-+---+ +-+---+ +--+--+ +- --+ +---+-+ >>> |Leaf | | | | | | | | | >>> |6LN | | | | | | | | | >>> +-----+ +-----+ +-----+ +----+ +-----+ >>> >>> >>> Figure 2: A reference RPL Topology >>> TW> I would add a "." at end of each caption >>> >>> In different scenarios the use of RFC 6553, RFC 6554 and tunneling >>> can take place: >>> TW> I would say that a combination of RFC6553, RFC6554 and IP-in-IP >>> TW> encapsulation is used for the following traffic flows: >>> >>> -Flow from leaf to root >>> TW> remove newlines? >>> -Flow from leaf to Internet >>> >>> -Flow from leaf to leaf >>> >>> -Flow from Internet to leaf >>> >>> -Flow from leaf to root >>> TW> duplicate >>> >>> 4. Example flow from leaf to root >>> >>> A leaf node generates DAO and DIS messages and in general does not >>> accept them. >>> TW> what do you mean by "accept"? >>> Additionally, this kind of nodes >>> TW> node >>> accepts DIO messages, >>> but in general do >>> TW> does >>> not generate them. (In inconsistency A leaf node >>> generates DIO with infinite rank, to fix it). >>> TW> A -> a >>> >>> >>> >>> >>> Robles & Richardson Expires December 29, 2015 [Page 4] >>> Internet-Draft Useof6553 June 2015 >>> >>> >>> 4.1. Non-storing >>> >>> In non-storing >>> TW> mode >>> in this case >>> TW> remove "in this case" >>> the leaf node uses Hop-By-Hop option (RFC >>> 6553) to indicate the routing information to send messages to the >>> DODAG root, this message is going to be analyzed in each node until >>> arrive the DODAG root. >>> >>> RFC 6554 was created to strictly send information between RPL routers >>> in the same RPL routing domain. How it would be in 6554? >>> TW> I assume a "TODO" missing before last sentence? >>> >>> TBD: Tunneling is necessary in case that there is information to send >>> outside RPL Domain and other cases? >>> >>> +------+ >>> | | >>> | 6LBR | >>> | | >>> +---+--+ >>> | >>> | LoWPAN_HC >>> | Route= 6LN-6LR-6LBR >>> ^ | >>> | +---+-+ >>> | | | >>> | | 6LR | >>> | | | >>> | +--+--+ >>> | | LoWPAN_HC >>> | | Route= 6LN-6LR-6LBR >>> | | >>> + | >>> +--+--+ >>> | 6LN | >>> | | >>> | | >>> +-----+ >>> >>> Figure 3: From leaf to Root - Non-Storing Mode >>> >>> TW> I don't fully understand what message this figure conveys >>> TW> I would use A B and C to name the nodes, and write their role >>> TW> next to them >>> >>> >>> >>> 4.2. Storing >>> >>> IP6 6553{X,Y] ?ipip payload. >>> TW> something's wrong >>> In storing mode is suitable the use of >>> RFC 6553 to send RPL Information through HBH field checking the >>> routing table to find out where to send the message. >>> TW> I don't understand "checking the routing table to find out where >>> TW> to send the message" >>> It may include >>> IP-in-IP encapsulation to transmit information not related with the >>> RPL domain. >>> TW> I would expand this info >>> >>> >>> >>> >>> >>> Robles & Richardson Expires December 29, 2015 [Page 5] >>> Internet-Draft Useof6553 June 2015 >>> >>> >>> +------+ >>> | | >>> | 6LBR | >>> | | >>> +---+--+ >>> | >>> | LoWPAN_HC >>> | 0x63|HBH Data >>> ^ | >>> | +---+-+ >>> | | | >>> | | 6LR | 6LR check in routing table >>> | | | >>> | +--+--+ >>> | | LoWPAN_HC >>> | | 0x63|HBH Data >>> | | >>> + | >>> +--+--+ >>> | 6LN | >>> | | >>> | | >>> +-----+ >>> >>> Figure 4: From leaf to Root - Storing Mode >>> >>> 5. Example flow from leaf to Internet >>> >>> 5.1. Non-storing >>> >>> In this case the IP-in-IP encapsulation should take place to send >>> information not related to the RPL domain inside of the RPL domain. >>> >>> RPL information from RFC 6553 should not go out to Internet. The >>> router sould >>> TW> typo >>> take this information out before send the packet to >>> Internet. The HBH Option is going to be analyzed in each node to the >>> root. >>> TW> illustrate this with a fig? >>> >>> Related to RFC 6554 the Source Header route is added and removed by >>> DODAG root. However, RFC 6554 was created to strictly send >>> information between RPL routers in the same RPL routing domain. How >>> it would be in 6554? >>> TW> this paragraph relates to down traffic, right? The name of the >>> section >>> TW> is "from leaf to Internet" >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Robles & Richardson Expires December 29, 2015 [Page 6] >>> Internet-Draft Useof6553 June 2015 >>> >>> >>> 5.2. Storing >>> >>> In storing the information of RFC 6553 should take away by DODAG root >>> before go to Internet. >>> TW> but as well in non-storing, no? >>> >>> 6. Example flow from leaf to leaf >>> >>> can leafs insert appropriate headers, without ipip? In [RFC6550] RPL >>> allows a simple one-hop P2P optimization for both storing and non- >>> storing networks. A node may send a P2P packet destined to a one-hop >>> neighbor direclty >>> TW> typo >>> to that node. Section 9 in [RFC6550]. >>> TW> I would say that IP-in-IP is not needed in this case >>> >>> 6.1. Traditional storing >>> TW> why "Traditional"? >>> The route go through an ancestor that knows the route to the >>> destination, using HBH [RFC6553] to carry RPL Information. >>> >>> 6.2. Traditional non-storing >>> >>> The route go through the DODAG root, using source routing [RFC6554]. >>> >>> 6.3. P2P non-storing >>> >>> (p2p storing? TBD) >>> >>> 7. Example flow from Internet to leaf >>> >>> A DODAG root do not add routing extension to incoming packets, it >>> instead uses tunneling. >>> >>> 7.1. Storing >>> >>> DODAG root adds the HBH header [RFC6553] and send the packet downward >>> to the destination. >>> >>> 7.2. Non-storing >>> >>> DODAG root is going to add the source route header [RFC6554] >>> >>> 8. Example flow from root to leaf >>> >>> 8.1. Storing >>> >>> DODAG root adds the HBH header [RFC6553] and send the packet downward >>> to the destination. >>> >>> 8.2. Non-storing >>> >>> >>> >>> >>> Robles & Richardson Expires December 29, 2015 [Page 7] >>> Internet-Draft Useof6553 June 2015 >>> >>> >>> DODAG root is going to add the source route header [RFC6554] >>> >>> 9. IANA Considerations >>> >>> There are no IANA considerations related to this document. >>> >>> 10. Security Considerations >>> >>> TBD. >>> TW> I would replace TBD by TODO, per usual covention >>> >>> 11. Acknowledgements >>> TW> typo >>> >>> This work is partially funded by the FP7 Marie Curie Initial Training >>> Network (ITN) METRICS project (grant agreement No. 607728) >>> >>> 12. References >>> >>> 12.1. Normative References >>> >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>> >>> [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., >>> Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. >>> Alexander, "RPL: IPv6 Routing Protocol for Low-Power and >>> Lossy Networks", RFC 6550, March 2012. >>> >>> [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- >>> Power and Lossy Networks (RPL) Option for Carrying RPL >>> Information in Data-Plane Datagrams", RFC 6553, March >>> 2012. >>> >>> [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 >>> Routing Header for Source Routes with the Routing Protocol >>> for Low-Power and Lossy Networks (RPL)", RFC 6554, March >>> 2012. >>> >>> 12.2. Informative References >>> >>> [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and >>> Lossy Networks", RFC 7102, January 2014. >>> >>> Authors' Addresses >>> >>> >>> >>> >>> >>> >>> >>> >>> Robles & Richardson Expires December 29, 2015 [Page 8] >>> Internet-Draft Useof6553 June 2015 >>> >>> >>> Maria Ines Robles >>> Ericsson >>> Hirsalantie 11 >>> Jorvas 02420 >>> Finland >>> >>> Email: maria.ines.robles@ericsson.com >>> >>> >>> Michael C. Richardson >>> Sandelman Software Works >>> 470 Dawson Avenue >>> Ottawa, ON K1Z 5V7 >>> CA >>> >>> Email: mcr+ietf@sandelman.ca >>> URI: http://www.sandelman.ca/ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Robles & Richardson Expires December 29, 2015 [Page 9] >>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> >> _______________________________________________ >> 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 > > --001a11346db0c4ed20051a0700e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ok, Thanks for the suggestions Xavi :-). We will work on tha= t.
Cheers

On 4 Jul 2015 06:58, "Xavier Vilajosana&quo= t; <xvilajosana@eecs.be= rkeley.edu> wrote:
Dear Ines, Michael,

It would be a= lso very good to have several examples (drawings) detailing how Extension h= eaders are placed in the outer IPv6 header and how this extension headers c= oexist (or are concatenated) with other extension headers (non-RPL) such as= =C2=A0IPv6 Fr= agment Header=C2=A0,=C2=A0IPv6 Hop-by-Hop Options Header,=C2=A0IPv6 Header --Inner-- (E= ID 7), etc.. The drawings can also show how a sequence of extension headers= is followed by a transport layer protocol such as UDP and if this affects = HC. The examples can be complemented with the byte streams of that headers = as clarification examples or to verify compliance.=C2=A0

It would also be good to comment about header compression and all the= possibilities we have or at least point to the RFCs that detail how extens= ion headers are compressed and when compression cannot be applied or any ot= her consideration.

I think this dr= aft is very valuable for most of us. Thanks for the work!

regards,
Xavi
=

2015-07-03 = 18:55 GMT+02:00 Robert Cragie <robert.cragie@gridmerge.com&g= t;:
Hi all,
<= br>
Happy to help out - I will take a closer look next week.

A couple of points on first cursory read:
1) The control plane and data plane concepts should be distinc= t. By all means talk about control plane (i.e. RPL messages) and how they a= re formatted but keep this distinct from the structure of data plane packet= s used where RPL is used for routing. It is the data plane where IP-in-IP, = RPL HbH and source routing headers are used and where the focus of the docu= ment should really be.
2) In the data plane, there are potentiall= y two sorts of leaf node to consider: a) RPL-aware and b) not RPL-aware. Th= is is important as it determines whether IP-in-IP is needed between nodes i= n a 6LoWPAN.

Robert

On 3 July 2015 at 14:52, T= homas Watteyne <watteyne@eecs.berkeley.edu> wrote:<= br>
In= es, Michael,
Please find my remarks about=C2=A0draft-robles-roll-useofr= plinfo-00 below.
Thomas

----
<= br>
TW> overall comme= nts
TW> - this is a= super important informational draft, which
TW> =C2=A0 clears up a lot of questions
TW> - I think it would be ver= y useful to have more example
TW> =C2=A0 packets. We are building such information for the upc= oming 6TiSCH
TW> = =C2=A0 plugtest, so I can help there.
TW> - After this is done I would recommend to ask=C2=A0<= /font>explicitly=C2=A0for
TW> =C2=A0 reviewers. Robert Cragie should be
TW> =C2=A0 on the lis= t of people to ask; he has provided very useful info
TW> =C2=A0 during our discussions.=


ROLL Working Group =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M.I. Robles
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson
Intended status: Informati= onal =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 M. Richardson
Expires: December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SSW
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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=A0June 27, 2015


=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 When to use RFC 6553, 6554 and IPv6-in-IPv6=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-robles-roll-useofrplinfo-00<= /font>

= Abstract

=C2=A0 =C2=A0This document states different cases where RFC 6553, RFC= 6554 and
=C2=A0 =C2= =A0IPv6-in-IPv6 encapsulation is required to set the bases to help
=C2=A0 =C2=A0defining the comp= ression of RPL routing information in LLN
=C2=A0 =C2=A0environments.

Status of This Memo

=C2=A0 =C2= =A0This Internet-Draft is submitted in full conformance with the
=C2=A0 =C2=A0provisions of BCP 7= 8 and BCP 79.

=C2=A0 =C2=A0Internet-Dra= fts are working documents of the Internet Engineering
=C2=A0 =C2=A0Task Force (IETF).=C2=A0 Note = that other groups may also distribute
=C2=A0 =C2=A0working documents as Internet-Drafts.=C2=A0 Th= e list of current Internet-

=
=C2=A0 =C2=A0Internet-Drafts are d= raft documents valid for a maximum of six months
=C2=A0 =C2=A0and may be updated, replaced, or ob= soleted by other documents at any
=C2=A0 =C2=A0time.=C2=A0 It is inappropriate to use Internet-Dr= afts as reference
=C2= =A0 =C2=A0material or to cite them other than as "work in progress.&qu= ot;

<= div>=C2=A0 =C2=A0This Internet-Draft wi= ll expire on December 29, 2015.


<= /div>
=C2=A0 =C2=A0Copyright (c) 20= 15 IETF Trust and the persons identified as the
=C2=A0 =C2=A0document authors.=C2=A0 All rights r= eserved.

=C2=A0 =C2=A0This document is = subject to BCP 78 and the IETF Trust's Legal
=C2=A0 =C2=A0Provisions Relating to IETF Documen= ts
=C2=A0 =C2=A0publication of this document.= =C2=A0 Please review these documents
=C2=A0 =C2=A0carefully, as they describe your rights and res= trictions with respect
=C2=A0 =C2=A0to this document.=C2=A0 Code Components extracted from this d= ocument must
=C2=A0 = =C2=A0include Simplified BSD License text as described in Section 4.e of
=C2=A0 =C2=A0the Trust L= egal Provisions and are provided without warranty as
=C2=A0 =C2=A0described in the Simplified BSD= License.

<= /div>


Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2015 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 1]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 201= 5


Table of Contents

= =C2=A0 =C2=A01.=C2=A0 Introduction =C2=A0. . . . . . . . . . . . . . . . . = . . . . . . . =C2=A0 2
=C2=A0 =C2=A02.=C2=A0 Terminology and Requirements Language . . . . . . . = . . . . . =C2=A0 2
=C2= =A0 =C2=A03.=C2=A0 Sample/reference topology . . . . . . . . . . . . . . . = . . . =C2=A0 3
=C2=A0 = =C2=A04.=C2=A0 Example flow from leaf to root =C2=A0. . . . . . . . . . . .= . . . =C2=A0 4
=C2=A0= =C2=A0 =C2=A04.1.=C2=A0 Non-storing . . . . . . . . . . . . . . . . . . . = . . . . =C2=A0 5
=C2= =A0 =C2=A0 =C2=A04.2.=C2=A0 Storing . . . . . . . . . . . . . . . . . . . .= . . . . . =C2=A0 5
= =C2=A0 =C2=A05.=C2=A0 Example flow from leaf to Internet =C2=A0. . . . . . = . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A05.1.=C2=A0 Non-storing . . . . . . . . . . . . . . . .= . . . . . . . =C2=A0 6
=C2=A0 =C2=A06.=C2=A0 Example flow from leaf to leaf =C2=A0. . . . . . .= . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.1.=C2=A0 Traditional storing . . . . . . . . . . = . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.2.=C2=A0 Traditional non-storing . . . . . . . .= . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.3.=C2=A0 P2P non-storing . . . . . . . . . . . = . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A07.=C2=A0 Example flow from Internet to leaf =C2=A0. . .= . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A07.1.=C2=A0 Storing . . . . . . . . . . . . . . = . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A07.2.=C2=A0 Non-storing . . . . . . . . . . . .= . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A08.=C2=A0 Example flow from root to leaf =C2=A0. . . = . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A08.1.=C2=A0 Storing . . . . . . . . . . . . .= . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A08.2.=C2=A0 Non-storing . . . . . . . . . . = . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A09.=C2=A0 IANA Considerations . . . . . . . . . . = . . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A010. Security Considerations . . . . . . . . . . . . .= . . . . . . =C2=A0 8
= =C2=A0 =C2=A011. Acknowledgements =C2=A0. . . . . . . . . . . . . . . . . .= . . . . =C2=A0 8
=C2= =A0 =C2=A012. References =C2=A0. . . . . . . . . . . . . . . . . . . . . . = . . . =C2=A0 8
=C2=A0 = =C2=A0 =C2=A012.1.=C2=A0 Normative References . . . . . . . . . . . . . . .= . . . =C2=A0 8
=C2=A0= =C2=A0 =C2=A012.2.=C2=A0 Informative References . . . . . . . . . . . . . = . . . . =C2=A0 8
=C2= =A0 =C2=A0Authors' Addresses =C2=A0. . . . . . . . . . . . . . . . . . = . . . . . =C2=A0 8

1.=C2=A0 Introduction

=C2=A0 =C2=A0RPL [RFC6550] defines RPL Option to trans= mit routing information.
=C2=A0 =C2=A0RFC 6553 [RFC6553] defines how to transmit in a Hop-By-Hop = Option RPL
=C2=A0 =C2= =A0Information,such as information to avoid and detect loops.=C2=A0 RFC 655= 4
=C2=A0 =C2=A0[RFC655= 4] defines the use of Extension header for Source Routing.
TW> this is a bit confusing to me. = AFAICT:
TW> - RFC65= 50 defines the RPL routing protocol
TW> - RFC6553 defines the "RPL option", carried = within the IPv6 Hop-by-Hop
TW> =C2=A0 header to =C2=A0quickly identify inconsistencies in the = routing topology
TW>= ; - RFC6554 defines the "RPL Source Route Header", an IPv6 Extens= ion
=C2=A0 =C2=A0 =C2= =A0 Header to deliver datagrams within a RPL routing domain

=C2=A0 =C2=A0Several discussions in
<= font face=3D"monospace, monospace">TW> the
=C2=A0 =C2=A0ROLL/6lo/6tisch
TW> 6tisch -> 6TiSCH
=C2=A0 =C2=A0Mailing Lists took place=
=C2=A0 =C2=A0focusing= in the definition
TW&= gt; of
=C2=A0 =C2=A0ho= w to compress RPL Information in
=C2=A0 =C2=A0constrained environment.=C2=A0 ROLL Virtual Interim= Meeting (02-2015)
=C2= =A0 =C2=A0concluded that there is a need to define how to use RFC 6553, RFC= 6554
TW> you have t= o decide whether you use "RFC 123" or "RFC123". I would=
TW> recommend you = replace this by a hyperlink
=C2=A0 =C2=A0and tunneling (IP-in-IP)
TW> I would say "and IP-in-IP encapsulation&q= uot;
=C2=A0 =C2=A0to b= e able to set the correct environment
=C2=A0 =C2=A0for compression.

2.=C2=A0 Terminology and Requirements Language

TW> you're actually not using any of this language = in the draft.
TW> i= f you keep it that way, and since the draft is informational
TW> I would recommend to remove t= his section




Rob= les & Richardson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015
=


=C2=A0 =C2=A0The key words "MUST", "MUST NOT",= "REQUIRED", "SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD",= "SHOULD NOT", "RECOMMENDED", "MAY", and &quo= t;OPTIONAL" in this
=C2=A0 =C2=A0document are to be interpreted as described in RFC 2119 [RF= C2119].

=C2=A0 =C2=A0Terminology define= d in [RFC7102]

3.=C2=A0 Sample/referenc= e topology

=
=C2=A0 =C2=A0In a typical to= pology we found
TW>= "we found" reads strange. What about "A RPL network is comp= osed of
TW> ...[6LR= ,6LBR]... logically organized in a DODAG structure".
= =C2=A0 =C2=A06LBR (6LoWPAN Border Route= r), 6lR
TW> 6LR
=C2=A0 =C2=A0(6LoWPAN Rou= ter) and 6LN (6LoWPAN Node) as leaf connected in a DODAG
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0(Destination Oriented Direc= ted Acyclic Graph).=C2=A0 Between these
=C2=A0 =C2=A0entities messages such as DIS, DIO and DAO a= re transmitted.=C2=A0 RPL
=C2=A0 =C2=A0defines the RPL Control message as an ICMPv6 information m= essage with
=C2=A0 =C2= =A0a Type of 155.
TW&g= t; RPL defines the RPL Control message, a new ICMPv6 message with
TW> Type 155. DIS, DIO and D= AO messages are all RPL Control messages
TW> but with different Code values.
= =C2=A0 =C2=A0RPL supports two modes of = Downward traffic: Storing,
=C2=A0 =C2=A0it is fully stateful or Non-Storing it is fully source ro= uted.=C2=A0 Any
=C2=A0= =C2=A0given RPL Instance is either storing or non-storing.
TW> please specify that a RPL Inst= ance is either fully storing or fully
TW> non-storing, i.e. a RPL Instance with a combination = of storing and
TW> = non-storing nodes is not supported

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=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| Upper Layers |=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------= --+
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 RPL =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 ICMPv6 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 IPv6 =C2=A0 =C2=A0= =C2=A0 |
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 6LoWPAN =C2=A0 =C2=A0|
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 PHY-MAC =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------+



=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F= igure 1: RPL Stack










<= font face=3D"monospace, monospace">Robles & Richardson =C2=A0 =C2=A0Exp= ires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[Page 3]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 June 2015

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +---+Internet |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 +---------+
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+----+--+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|DODAG =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+---------+Root =C2=A0 +----------= +
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |6LBR =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +----+--+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+-+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--+---+ =C2=A0 =C2=A0 =C2=A0+--+---+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|6LR =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +-----+ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0+------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 +-----+-+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+----+= =C2=A0 =C2=A0 =C2=A0+-+----+ =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0+-+---+ =C2=A0 =C2=A0 +-+---+ =C2=A0 =C2=A0 =C2=A0+--+= --+ =C2=A0 =C2=A0 =C2=A0 +- --+ =C2=A0 =C2=A0 +---+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|Leaf | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|6LN =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+ =C2=A0 =C2=A0 +-----+ =C2=A0 =C2=A0 =C2= =A0+-----+ =C2=A0 =C2=A0 =C2=A0 +----+ =C2=A0 =C2=A0 +-----+


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Figure 2: A reference RPL Topology
TW> I would add a "." at end of each caption

=C2=A0 =C2=A0In different scenarios the use= of RFC 6553, RFC 6554 and tunneling
=C2=A0 =C2=A0can take place:
TW> I would say that a combination of RFC6553, RFC= 6554 and IP-in-IP
TW&g= t; encapsulation is used for the following traffic flows:
=
=C2=A0 =C2=A0-Flow from leaf to root
TW> remove newlines?
= =C2=A0 =C2=A0-Flow from leaf to Interne= t

=C2=A0 =C2=A0-Flow from leaf to leaf<= /font>

= =C2=A0 =C2=A0-Flow from Internet to lea= f

=C2=A0 =C2=A0-Flow from leaf to root<= /font>
TW> duplicate

4.=C2=A0 Example flow from leaf to root

=C2=A0 =C2=A0A leaf node generates DAO and = DIS messages and in general does not
=C2=A0 =C2=A0accept them.
TW> what do you mean by "accept"?
=C2=A0 =C2=A0Additionally, this= kind of nodes
TW> = node
=C2=A0 =C2=A0acce= pts DIO messages,
=C2= =A0 =C2=A0but in general do
TW> does
=C2= =A0 =C2=A0not generate them. =C2=A0(In inconsistency A leaf node
=C2=A0 =C2=A0generates DIO with = infinite rank, to fix it).
TW> A -> a
=

=


Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2015 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]
=0C
Internet-Draft =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


4.1.=C2=A0 Non-storing

=C2=A0 =C2=A0In non-storing
TW> mode
=C2= =A0 =C2=A0in this case
TW> remove "in this case"
=C2=A0 =C2=A0the leaf node uses Hop-By-Hop option (RFC
=C2=A0 =C2=A06553) to in= dicate the routing information to send messages to the
=C2=A0 =C2=A0DODAG root, this message is g= oing to be analyzed in each node until
=C2=A0 =C2=A0arrive the DODAG root.

=C2=A0 =C2=A0RFC 6554 was created to strictly send informatio= n between RPL routers
= =C2=A0 =C2=A0in the same RPL routing domain.=C2=A0 How it would be in 6554?=
TW> I assume a &qu= ot;TODO" missing before last sentence?

=C2=A0 =C2=A0TBD: Tunneling is necessary in case that there is informa= tion to send
=C2=A0 = =C2=A0outside RPL Domain and other cases?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6LBR |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+--+
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0LoWPAN_HC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0Route=3D 6LN-6LR-6LBR=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0+---+-+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0| 6LR |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 LoWPAN_HC
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = | =C2=A0 Route=3D 6LN-6LR-6LBR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6LN |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----= -+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Figure 3: From leaf to Root - Non-Storing Mode

TW> I don't fully understand what message this= figure conveys
TW>= I would use A B and C to name the nodes, and write their role
=
TW> next to them



4.2.=C2=A0 S= toring

=C2=A0 =C2=A0IP6 6553{X,Y] ?ipip= payload.
TW> somet= hing's wrong
=C2= =A0 =C2=A0In storing mode is suitable the use of
=C2=A0 =C2=A0RFC 6553 to send RPL Information th= rough HBH field checking the
=C2=A0 =C2=A0routing table to find out where to send the message.
TW> I don't under= stand "checking the routing table to find out where
<= font face=3D"monospace, monospace">TW> to send the message"<= /div>
=C2=A0 =C2=A0It may include
=C2=A0 =C2=A0IP-in-IP e= ncapsulation to transmit information not related with the
= =C2=A0 =C2=A0RPL domain.
TW> I would expand this info




Robles & Richardson =C2=A0 =C2= =A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Page 5]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------+
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6LBR |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0LoWPAN_HC
<= font face=3D"monospace, monospace">=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=A00x63|HBH Data<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+---+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0| 6LR | 6LR check in routing tabl= e
=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 |<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 LoWPAN_HC
=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 0x63|= HBH Data
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=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 | 6LN |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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 Figure 4: From leaf to Ro= ot - Storing Mode

=
5.=C2=A0 Example flow= from leaf to Internet

5.1.=C2=A0 Non-s= toring

=C2=A0 =C2=A0In this case the IP= -in-IP encapsulation should take place to send
=C2=A0 =C2=A0information not related to the RPL d= omain inside of the RPL domain.

=C2=A0 = =C2=A0RPL information from RFC 6553 should not go out to Internet.=C2=A0 Th= e
=C2=A0 =C2=A0router = sould
TW> typo
=C2=A0 =C2=A0take this inf= ormation out before send the packet to
=C2=A0 =C2=A0Internet.=C2=A0 The HBH Option is going to be= analyzed in each node to the
=C2=A0 =C2=A0root.
TW> illustrate this with a fig?

=C2=A0 =C2=A0Related to RFC 6554 the Source Header route is added and remo= ved by
=C2=A0 =C2=A0DO= DAG root.=C2=A0 However, RFC 6554 was created to strictly send
=
=C2=A0 =C2=A0information between R= PL routers in the same RPL routing domain.=C2=A0 How
=C2=A0 =C2=A0it would be in 6554?
TW> this paragraph relates to= down traffic, right? The name of the section
TW> is "from leaf to Internet"








Robles & Richardson =C2=A0= =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[Page 6]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=
5.2.=C2=A0 Storing

=C2=A0 =C2=A0In storing the information o= f RFC 6553 should take away by DODAG root
=C2=A0 =C2=A0before go to Internet.
TW> but as well in non-storing, no?

6.=C2=A0 Example flow from leaf to leaf

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0can leafs insert appropriat= e headers, without ipip?=C2=A0 In [RFC6550] RPL
=C2=A0 =C2=A0allows a simple one-hop P2P optimiza= tion for both storing and non-
=C2=A0 =C2=A0storing networks.=C2=A0 A node may send a P2P packet = destined to a one-hop
= =C2=A0 =C2=A0neighbor direclty
TW> typo
= =C2=A0 =C2=A0to that node.=C2=A0 Section 9 in [RFC6550].
<= font face=3D"monospace, monospace">TW> I would say that IP-in-IP is not = needed in this case
6.1.=C2=A0 Traditio= nal storing
TW> why= "Traditional"?
=C2=A0 =C2=A0The route go through an ancestor that knows the route to t= he
=C2=A0 =C2=A0destin= ation, using HBH [RFC6553] to carry RPL Information.

6.2.=C2=A0 Traditional non-storing

=C2=A0 =C2=A0The route go through the DODAG root, using source ro= uting [RFC6554].

<= /font>
6.3.=C2=A0 P2P non-sto= ring

=
=C2=A0 =C2=A0(p2p storing?=C2=A0 T= BD)

<= div>7.=C2=A0 Example flow from Internet= to leaf

=C2=A0 =C2=A0A DODAG root do n= ot add routing extension to incoming packets, it
=C2=A0 =C2=A0instead uses tunneling.

7.1.=C2=A0 Storing

=C2=A0 =C2=A0DODAG root adds the HBH header [RFC6553] and send the pa= cket downward
=C2=A0 = =C2=A0to the destination.

7.2.=C2=A0 No= n-storing

<= /div>
=C2=A0 =C2=A0DODAG root is go= ing to add the source route header [RFC6554]

8.=C2=A0 Example flow from root to leaf

8.1.=C2=A0 Storing

=C2=A0 =C2= =A0DODAG root adds the HBH header [RFC6553] and send the packet downward
=C2=A0 =C2=A0to the dest= ination.

8.2.=C2=A0 Non-storing<= /div>




<= /font>
Robles & Richardso= n =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0[Page 7]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 =C2=A0D= ODAG root is going to add the source route header [RFC6554]

9.=C2=A0 IANA Considerations

=C2=A0 =C2=A0There are no IANA considerations related to this do= cument.

10.=C2=A0 Security Consideratio= ns

=C2=A0 =C2=A0TBD.
<= font face=3D"monospace, monospace">TW> I would replace TBD by TODO, per = usual covention

11.=C2=A0 Acknowledgeme= nts
TW> typo=

=C2=A0 =C2=A0This work is partially funded by= the FP7 Marie Curie Initial Training
=C2=A0 =C2=A0Network (ITN) METRICS project (grant agreement= No. =C2=A0607728)
12.=C2=A0 References=

12.1.=C2=A0 Normative References

=C2=A0 =C2=A0[RFC2119] =C2=A0Bradner, S., &q= uot;Key words for use in RFCs to Indicate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Requir= ement Levels", BCP 14, RFC 2119, March 1997.

=C2=A0 =C2=A0[RFC6550] =C2=A0Winter, T., Thubert, P., Brandt, A.= , Hui, J., Kelsey, R.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Levis, P., Pister, K., St= ruik, R., Vasseur, JP., and R.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alexander, "= RPL: IPv6 Routing Protocol for Low-Power and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Los= sy Networks", RFC 6550, March 2012.

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Power and Lossy Networks (RPL= ) Option for Carrying RPL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Information in Data-Pl= ane Datagrams", RFC 6553, March
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2012.

=C2=A0 =C2=A0[RFC6554] =C2=A0Hui, J., Vasseu= r, JP., Culler, D., and V. Manral, "An IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Routing Header for Source Routes with the Routing Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 for Low-Power and Lossy Networks (RPL)", RFC 6554, March=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 2012.

12.2.= =C2=A0 Informative References

=C2=A0 = =C2=A0[RFC7102] =C2=A0Vasseur, JP., "Terms Used in Routing for Low-Pow= er and
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lossy Networks", RFC 7102, January = 2014.

Authors' Addresses







<= br>
Robles & Richa= rdson =C2=A0 =C2=A0Expires December 29, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 8]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Useof6553 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 June 2015


=C2=A0 = =C2=A0Maria Ines Robles
=C2=A0 =C2=A0Jorvas =C2=A002420
=C2=A0 =C2=A0Finland

= =C2=A0 =C2=A0Email: maria.ines.robles@ericsson.com


=C2=A0 = =C2=A0Michael C. Richardson
=C2=A0 =C2=A0Sandelman Software Works
=C2=A0 =C2=A0470 Dawson Avenue
=C2=A0 =C2=A0Ottawa, ON =C2=A0K1Z 5V7=
=C2=A0 =C2=A0CA
=

=C2=A0 =C2=A0Email: mcr+ietf@sandelman.ca
= =C2=A0 =C2=A0URI: =C2=A0 http://www.sandelman.ca/













<= font face=3D"monospace, monospace">










<= br>

<= div>



=


Robles & Richardson =C2=A0 =C2=A0Expires December 29, 2015= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 9]


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



_______________________________________________
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

--001a11346db0c4ed20051a0700e2-- From nobody Sat Jul 4 03:59:06 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAF71A03D5 for ; Sat, 4 Jul 2015 03:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.21 X-Spam-Level: X-Spam-Status: No, score=-12.21 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, MANGLED_GIRL=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ko7ayiwGA42s for ; Sat, 4 Jul 2015 03:58:58 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F3D1A01F0 for ; Sat, 4 Jul 2015 03:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=95613; q=dns/txt; s=iport; t=1436007538; x=1437217138; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Ry7uAYqFvy6jVpZw0ISAsu4Hjf+mxw3vJAud6vUJWew=; b=ctleuXE+Cyed5G9h2DD8WTXarAmVnYxkQi45vhBdUmdCVyYThgUdCF3T B0JqYBKydOmtMwBQ1q8JCYe3YmuNDrhewY20Gcv5ipPAPF4xlATJQTdMa er8JS4RKA4uV7IRr3FuEJbePbfoNKyR2VHALmGcEH2wlXj9xqUZBcNnvq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B+CQDmupdV/51dJa1SCoJFTVRgrmSOO4F+GQEJgkOCakoCgSQ8EAEBAQEBAQGBCoQkAQEEAQEBFwEMQAcbAgEIOAEGBycLFBECBBMch34DEg3BQA2FYAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLS4JNgUsKAQYLAQItHguDF4EUBYcFhRQ4hGCCZAGEYYRigiQBgTkUMINRgw+MG4NdERWCDByBU28BgQyBPgEBAQ X-IronPort-AV: E=Sophos;i="5.15,405,1432598400"; d="scan'208,217";a="165493761" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 04 Jul 2015 10:58:56 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t64Awu4J017809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 4 Jul 2015 10:58:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.112]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Sat, 4 Jul 2015 05:58:55 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [6tisch] Thomas' remarks on draft-robles-roll-useofrplinfo-00 Thread-Index: AQHQtiTrNXvIAJApukyimvjiup0+qp3LJIxF Date: Sat, 4 Jul 2015 10:58:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EFB43824D17247949371770ECF92CF27ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] [6tisch] Thomas' remarks on draft-robles-roll-useofrplinfo-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 10:59:05 -0000 --_000_EFB43824D17247949371770ECF92CF27ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On the side Ines I m willing to contribute with formats in the compressed = form from the 6LoRH draft if it is successful at 6lo. Would you want that in? Pascal Le 4 juil. 2015 =E0 08:44, Ines Robles > a =E9crit : Ok, Thanks for the suggestions Xavi :-). We will work on that. Cheers On 4 Jul 2015 06:58, "Xavier Vilajosana" > wrote: Dear Ines, Michael, It would be also very good to have several examples (drawings) detailing ho= w Extension headers are placed in the outer IPv6 header and how this extens= ion headers coexist (or are concatenated) with other extension headers (non= -RPL) such as IPv6 Fragment Header , IPv6 Hop-by-Hop Options Header, IPv6 H= eader --Inner-- (EID 7), etc.. The drawings can also show how a sequence of= extension headers is followed by a transport layer protocol such as UDP an= d if this affects HC. The examples can be complemented with the byte stream= s of that headers as clarification examples or to verify compliance. It would also be good to comment about header compression and all the possi= bilities we have or at least point to the RFCs that detail how extension he= aders are compressed and when compression cannot be applied or any other co= nsideration. I think this draft is very valuable for most of us. Thanks for the work! regards, Xavi 2015-07-03 18:55 GMT+02:00 Robert Cragie >: Hi all, Happy to help out - I will take a closer look next week. A couple of points on first cursory read: 1) The control plane and data plane concepts should be distinct. By all mea= ns talk about control plane (i.e. RPL messages) and how they are formatted = but keep this distinct from the structure of data plane packets used where = RPL is used for routing. It is the data plane where IP-in-IP, RPL HbH and s= ource routing headers are used and where the focus of the document should r= eally be. 2) In the data plane, there are potentially two sorts of leaf node to consi= der: a) RPL-aware and b) not RPL-aware. This is important as it determines = whether IP-in-IP is needed between nodes in a 6LoWPAN. Robert On 3 July 2015 at 14:52, Thomas Watteyne > wrote: Ines, Michael, Please find my remarks about draft-robles-roll-useofrplinfo-00 below. Thomas ---- TW> overall comments TW> - this is a super important informational draft, which TW> clears up a lot of questions TW> - I think it would be very useful to have more example TW> packets. We are building such information for the upcoming 6TiSCH TW> plugtest, so I can help there. TW> - After this is done I would recommend to ask explicitly for TW> reviewers. Robert Cragie should be TW> on the list of people to ask; he has provided very useful info TW> during our discussions. ROLL Working Group M.I. Robles Internet-Draft Ericsson Intended status: Informational M. Richardson Expires: December 29, 2015 SSW June 27, 2015 When to use RFC 6553, 6554 and IPv6-in-IPv6 draft-robles-roll-useofrplinfo-00 Abstract This document states different cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is required to set the bases to help defining the compression of RPL routing information in LLN environments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 29, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Robles & Richardson Expires December 29, 2015 [Page 1] Internet-Draft Useof6553 June 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Requirements Language . . . . . . . . . . . . 2 3. Sample/reference topology . . . . . . . . . . . . . . . . . . 3 4. Example flow from leaf to root . . . . . . . . . . . . . . . 4 4.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Example flow from leaf to Internet . . . . . . . . . . . . . 6 5.1. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Example flow from leaf to leaf . . . . . . . . . . . . . . . 7 6.1. Traditional storing . . . . . . . . . . . . . . . . . . . 7 6.2. Traditional non-storing . . . . . . . . . . . . . . . . . 7 6.3. P2P non-storing . . . . . . . . . . . . . . . . . . . . . 7 7. Example flow from Internet to leaf . . . . . . . . . . . . . 7 7.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 8. Example flow from root to leaf . . . . . . . . . . . . . . . 7 8.1. Storing . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.2. Non-storing . . . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction RPL [RFC6550] defines RPL Option to transmit routing information. RFC 6553 [RFC6553] defines how to transmit in a Hop-By-Hop Option RPL Information,such as information to avoid and detect loops. RFC 6554 [RFC6554] defines the use of Extension header for Source Routing. TW> this is a bit confusing to me. AFAICT: TW> - RFC6550 defines the RPL routing protocol TW> - RFC6553 defines the "RPL option", carried within the IPv6 Hop-by-Hop TW> header to quickly identify inconsistencies in the routing topology TW> - RFC6554 defines the "RPL Source Route Header", an IPv6 Extension Header to deliver datagrams within a RPL routing domain Several discussions in TW> the ROLL/6lo/6tisch TW> 6tisch -> 6TiSCH Mailing Lists took place focusing in the definition TW> of how to compress RPL Information in constrained environment. ROLL Virtual Interim Meeting (02-2015) concluded that there is a need to define how to use RFC 6553, RFC6554 TW> you have to decide whether you use "RFC 123" or "RFC123". I would TW> recommend you replace this by a hyperlink and tunneling (IP-in-IP) TW> I would say "and IP-in-IP encapsulation" to be able to set the correct environment for compression. 2. Terminology and Requirements Language TW> you're actually not using any of this language in the draft. TW> if you keep it that way, and since the draft is informational TW> I would recommend to remove this section Robles & Richardson Expires December 29, 2015 [Page 2] Internet-Draft Useof6553 June 2015 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Terminology defined in [RFC7102] 3. Sample/reference topology In a typical topology we found TW> "we found" reads strange. What about "A RPL network is composed of TW> ...[6LR,6LBR]... logically organized in a DODAG structure". 6LBR (6LoWPAN Border Router), 6lR TW> 6LR (6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf connected in a DODAG (Destination Oriented Directed Acyclic Graph). Between these entities messages such as DIS, DIO and DAO are transmitted. RPL defines the RPL Control message as an ICMPv6 information message with a Type of 155. TW> RPL defines the RPL Control message, a new ICMPv6 message with TW> Type 155. DIS, DIO and DAO messages are all RPL Control messages TW> but with different Code values. RPL supports two modes of Downward traffic: Storing, it is fully stateful or Non-Storing it is fully source routed. Any given RPL Instance is either storing or non-storing. TW> please specify that a RPL Instance is either fully storing or fully TW> non-storing, i.e. a RPL Instance with a combination of storing and TW> non-storing nodes is not supported +--------------+ | Upper Layers | | | +--------------+ | RPL | | | +--------------+ | ICMPv6 | | | +--------------+ | IPv6 | | | +--------------+ | 6LoWPAN | | | +--------------+ | PHY-MAC | | | +--------------+ Figure 1: RPL Stack Robles & Richardson Expires December 29, 2015 [Page 3] Internet-Draft Useof6553 June 2015 +---------+ +---+Internet | | +---------+ | +----+--+ |DODAG | +---------+Root +----------+ | |6LBR | | | +----+--+ | | | | | | | | | | +-----+-+ +--+---+ +--+---+ |6LR | | | | | +-----+ | | | | | | | | | | | +------+ | +-----+-+ +-+----+ +-+----+ | | | | | | | | | | | | | | | | +-+---+ +-+---+ +--+--+ +- --+ +---+-+ |Leaf | | | | | | | | | |6LN | | | | | | | | | +-----+ +-----+ +-----+ +----+ +-----+ Figure 2: A reference RPL Topology TW> I would add a "." at end of each caption In different scenarios the use of RFC 6553, RFC 6554 and tunneling can take place: TW> I would say that a combination of RFC6553, RFC6554 and IP-in-IP TW> encapsulation is used for the following traffic flows: -Flow from leaf to root TW> remove newlines? -Flow from leaf to Internet -Flow from leaf to leaf -Flow from Internet to leaf -Flow from leaf to root TW> duplicate 4. Example flow from leaf to root A leaf node generates DAO and DIS messages and in general does not accept them. TW> what do you mean by "accept"? Additionally, this kind of nodes TW> node accepts DIO messages, but in general do TW> does not generate them. (In inconsistency A leaf node generates DIO with infinite rank, to fix it). TW> A -> a Robles & Richardson Expires December 29, 2015 [Page 4] Internet-Draft Useof6553 June 2015 4.1. Non-storing In non-storing TW> mode in this case TW> remove "in this case" the leaf node uses Hop-By-Hop option (RFC 6553) to indicate the routing information to send messages to the DODAG root, this message is going to be analyzed in each node until arrive the DODAG root. RFC 6554 was created to strictly send information between RPL routers in the same RPL routing domain. How it would be in 6554? TW> I assume a "TODO" missing before last sentence? TBD: Tunneling is necessary in case that there is information to send outside RPL Domain and other cases? +------+ | | | 6LBR | | | +---+--+ | | LoWPAN_HC | Route=3D 6LN-6LR-6LBR ^ | | +---+-+ | | | | | 6LR | | | | | +--+--+ | | LoWPAN_HC | | Route=3D 6LN-6LR-6LBR | | + | +--+--+ | 6LN | | | | | +-----+ Figure 3: From leaf to Root - Non-Storing Mode TW> I don't fully understand what message this figure conveys TW> I would use A B and C to name the nodes, and write their role TW> next to them 4.2. Storing IP6 6553{X,Y] ?ipip payload. TW> something's wrong In storing mode is suitable the use of RFC 6553 to send RPL Information through HBH field checking the routing table to find out where to send the message. TW> I don't understand "checking the routing table to find out where TW> to send the message" It may include IP-in-IP encapsulation to transmit information not related with the RPL domain. TW> I would expand this info Robles & Richardson Expires December 29, 2015 [Page 5] Internet-Draft Useof6553 June 2015 +------+ | | | 6LBR | | | +---+--+ | | LoWPAN_HC | 0x63|HBH Data ^ | | +---+-+ | | | | | 6LR | 6LR check in routing table | | | | +--+--+ | | LoWPAN_HC | | 0x63|HBH Data | | + | +--+--+ | 6LN | | | | | +-----+ Figure 4: From leaf to Root - Storing Mode 5. Example flow from leaf to Internet 5.1. Non-storing In this case the IP-in-IP encapsulation should take place to send information not related to the RPL domain inside of the RPL domain. RPL information from RFC 6553 should not go out to Internet. The router sould TW> typo take this information out before send the packet to Internet. The HBH Option is going to be analyzed in each node to the root. TW> illustrate this with a fig? Related to RFC 6554 the Source Header route is added and removed by DODAG root. However, RFC 6554 was created to strictly send information between RPL routers in the same RPL routing domain. How it would be in 6554? TW> this paragraph relates to down traffic, right? The name of the section TW> is "from leaf to Internet" Robles & Richardson Expires December 29, 2015 [Page 6] Internet-Draft Useof6553 June 2015 5.2. Storing In storing the information of RFC 6553 should take away by DODAG root before go to Internet. TW> but as well in non-storing, no? 6. Example flow from leaf to leaf can leafs insert appropriate headers, without ipip? In [RFC6550] RPL allows a simple one-hop P2P optimization for both storing and non- storing networks. A node may send a P2P packet destined to a one-hop neighbor direclty TW> typo to that node. Section 9 in [RFC6550]. TW> I would say that IP-in-IP is not needed in this case 6.1. Traditional storing TW> why "Traditional"? The route go through an ancestor that knows the route to the destination, using HBH [RFC6553] to carry RPL Information. 6.2. Traditional non-storing The route go through the DODAG root, using source routing [RFC6554]. 6.3. P2P non-storing (p2p storing? TBD) 7. Example flow from Internet to leaf A DODAG root do not add routing extension to incoming packets, it instead uses tunneling. 7.1. Storing DODAG root adds the HBH header [RFC6553] and send the packet downward to the destination. 7.2. Non-storing DODAG root is going to add the source route header [RFC6554] 8. Example flow from root to leaf 8.1. Storing DODAG root adds the HBH header [RFC6553] and send the packet downward to the destination. 8.2. Non-storing Robles & Richardson Expires December 29, 2015 [Page 7] Internet-Draft Useof6553 June 2015 DODAG root is going to add the source route header [RFC6554] 9. IANA Considerations There are no IANA considerations related to this document. 10. Security Considerations TBD. TW> I would replace TBD by TODO, per usual covention 11. Acknowledgements TW> typo This work is partially funded by the FP7 Marie Curie Initial Training Network (ITN) METRICS project (grant agreement No. 607728) 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, March 2012. [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012. 12.2. Informative References [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, January 2014. Authors' Addresses Robles & Richardson Expires December 29, 2015 [Page 8] Internet-Draft Useof6553 June 2015 Maria Ines Robles Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: maria.ines.robles@ericsson.com Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA Email: mcr+ietf@sandelman.ca URI: http://www.sandelman.ca/ Robles & Richardson Expires December 29, 2015 [Page 9] _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_EFB43824D17247949371770ECF92CF27ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On the side Ines I m willing to contribute  with formats in the c= ompressed form from the 6LoRH draft if it is successful at 6lo.

Would you want that in?

Pascal

Le 4 juil. 2015 =E0 08:44, Ines Robles <mariainesrobles@googlemail.com> a =E9crit :

Ok, Thanks for the suggestions Xavi :-). We will work on tha= t.
Cheers

On 4 Jul 2015 06:58, "Xavier Vilajosana&quo= t; <xvilajosana@eecs.be= rkeley.edu> wrote:
Dear Ines, Michael,

It would be also very good to have several examples (drawings) detaili= ng how Extension headers are placed in the outer IPv6 header and how this e= xtension headers coexist (or are concatenated) with other extension headers= (non-RPL) such as IPv6 Fragment Header , IPv6 Hop-by-Hop Options Header, IPv6 Header --Inner--= (EID 7), etc.. The drawings can also show how a sequence of extension headers is followed by a transport layer protocol such as UDP= and if this affects HC. The examples can be complemented with the byte str= eams of that headers as clarification examples or to verify compliance.&nbs= p;

I= t would also be good to comment about header compression and all the possib= ilities we have or at least point to the RFCs that detail how extension hea= ders are compressed and when compression cannot be applied or any other consideration.
<= br>
I= think this draft is very valuable for most of us. Thanks for the work!
<= br>
r= egards,
X= avi

2015-07-03 18:55 GMT+02:00 Robert Cragie <robert= .cragie@gridmerge.com>:
Hi all,

Happy to help out - I will take a closer look next week.

A couple of points on first cursory read:

1) The control plane and data plane concepts should be distinct. By al= l means talk about control plane (i.e. RPL messages) and how they are forma= tted but keep this distinct from the structure of data plane packets used w= here RPL is used for routing. It is the data plane where IP-in-IP, RPL HbH and source routing headers are u= sed and where the focus of the document should really be.
2) In the data plane, there are potentially two sorts of leaf node to = consider: a) RPL-aware and b) not RPL-aware. This is important as it determ= ines whether IP-in-IP is needed between nodes in a 6LoWPAN.

Robert

On 3 July 2015 at 14:52, Thomas Watteyne <watteyne@eecs.berk= eley.edu> wrote:
Ines, Michael,
Please find my remarks about draft-robles-roll-useofrplinfo-00 be= low.
Thomas

----

TW> overall comments
TW> - this is a super important= informational draft, which
TW>   clears up a lot of q= uestions
TW> - I think it would be very = useful to have more example
TW>   packets. We are buil= ding such information for the upcoming 6TiSCH
TW>   plugtest, so I can h= elp there.
TW> - After this is done I woul= d recommend to ask explicitly = for
TW>   reviewer= s. Robert Cragie should be
TW>   on the list of peopl= e to ask; he has provided very useful info
TW>   during our discussio= ns.


ROLL Working Group     &= nbsp;                    =                 M.I. Robles=
Internet-Draft      = ;                     &nb= sp;                     &= nbsp;Ericsson
Intended status: Informational &nb= sp;                     &= nbsp;     M. Richardson
Expires: December 29, 2015   =                      = ;                   SSW=
         =                     &nbs= p;                     &n= bsp;      June 27, 2015


         =     When to use RFC 6553, 6554 and IPv6-in-IPv6
         =          draft-robles-roll-useofrplinfo-00=

Abstract

   This document states = different cases where RFC 6553, RFC 6554 and
   IPv6-in-IPv6 encapsul= ation is required to set the bases to help
   defining the compress= ion of RPL routing information in LLN
   environments.<= /div>

Status of This Memo

   This Internet-Draft i= s submitted in full conformance with the
   provisions of BCP 78 = and BCP 79.

   Internet-Drafts are w= orking documents of the Internet Engineering
   Task Force (IETF).&nb= sp; Note that other groups may also distribute
   working documents as = Internet-Drafts.  The list of current Internet-

   Internet-Drafts are d= raft documents valid for a maximum of six months
   and may be updated, r= eplaced, or obsoleted by other documents at any
   time.  It is ina= ppropriate to use Internet-Drafts as reference
   material or to cite t= hem other than as "work in progress."

   This Internet-Draft w= ill expire on December 29, 2015.

Copyright Notice

   Copyright (c) 2015 IE= TF Trust and the persons identified as the
   document authors.&nbs= p; All rights reserved.

   This document is subj= ect to BCP 78 and the IETF Trust's Legal
   Provisions Relating t= o IETF Documents
   (http://trustee.ietf.org/lice= nse-info) in effect on the date of
   publication of this d= ocument.  Please review these documents
   carefully, as they de= scribe your rights and restrictions with respect
   to this document.&nbs= p; Code Components extracted from this document must
   include Simplified BS= D License text as described in Section 4.e of
   the Trust Legal Provi= sions and are provided without warranty as
   described in the Simp= lified BSD License.



Robles & Richardson   &nb= sp;Expires December 29, 2015             &nbs= p;  [Page 1]
Internet-Draft      = ;           Useof6553         =               June 2015


Table of Contents

   1.  Introduction=  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology = and Requirements Language . . . . . . . . . . . .   2
   3.  Sample/refer= ence topology . . . . . . . . . . . . . . . . . .   3
   4.  Example flow= from leaf to root  . . . . . . . . . . . . . . .   4
     4.1.  Non= -storing . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Sto= ring . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Example flow= from leaf to Internet  . . . . . . . . . . . . .   6
     5.1.  Non= -storing . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Sto= ring . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Example flow= from leaf to leaf  . . . . . . . . . . . . . . .   7
     6.1.  Tra= ditional storing . . . . . . . . . . . . . . . . . . .   7
     6.2.  Tra= ditional non-storing . . . . . . . . . . . . . . . . .   7
     6.3.  P2P= non-storing . . . . . . . . . . . . . . . . . . . . .   7
   7.  Example flow= from Internet to leaf  . . . . . . . . . . . . .   7
     7.1.  Sto= ring . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.2.  Non= -storing . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Example flow= from root to leaf  . . . . . . . . . . . . . . .   7
     8.1.  Sto= ring . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.2.  Non= -storing . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Conside= rations . . . . . . . . . . . . . . . . . . . . .   8
   10. Security Consider= ations . . . . . . . . . . . . . . . . . . .   8
   11. Acknowledgements =  . . . . . . . . . . . . . . . . . . . . . .   8
   12. References  = . . . . . . . . . . . . . . . . . . . . . . . . .   8
     12.1.  No= rmative References . . . . . . . . . . . . . . . . . .   8
     12.2.  In= formative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses &n= bsp;. . . . . . . . . . . . . . . . . . . . . . .   8


1.  Introduction

   RPL [RFC6550] defines= RPL Option to transmit routing information.
   RFC 6553 [RFC6553] de= fines how to transmit in a Hop-By-Hop Option RPL
   Information,such as i= nformation to avoid and detect loops.  RFC 6554
   [RFC6554] defines the= use of Extension header for Source Routing.
TW> this is a bit confusing to = me. AFAICT:
TW> - RFC6550 defines the RPL r= outing protocol
TW> - RFC6553 defines the "= ;RPL option", carried within the IPv6 Hop-by-Hop
TW>   header to  quic= kly identify inconsistencies in the routing topology
TW> - RFC6554 defines the "= ;RPL Source Route Header", an IPv6 Extension
      Header to del= iver datagrams within a RPL routing domain

   Several discussions i= n
TW> the
   ROLL/6lo/6tisch
TW> 6tisch -> 6TiSCH<= /div>
   Mailing Lists took pl= ace
   focusing in the defin= ition
TW> of
   how to compress RPL I= nformation in
   constrained environme= nt.  ROLL Virtual Interim Meeting (02-2015)
   concluded that there = is a need to define how to use RFC 6553, RFC6554
TW> you have to decide whether = you use "RFC 123" or "RFC123". I would
TW> recommend you replace this = by a hyperlink
   and tunneling (IP-in-= IP)
TW> I would say "and IP-in= -IP encapsulation"
   to be able to set the= correct environment
   for compression.

2.  Terminology and Requireme= nts Language

TW> you're actually not using a= ny of this language in the draft.
TW> if you keep it that way, an= d since the draft is informational
TW> I would recommend to remove= this section




Robles & Richardson   &nb= sp;Expires December 29, 2015             &nbs= p;  [Page 2]
Internet-Draft      = ;           Useof6553         =               June 2015


   The key words "M= UST", "MUST NOT", "REQUIRED", "SHALL", &= quot;SHALL NOT",
   "SHOULD", &= quot;SHOULD NOT", "RECOMMENDED", "MAY", and "= OPTIONAL" in this
   document are to be in= terpreted as described in RFC 2119 [RFC2119].

   Terminology defined i= n [RFC7102]

3.  Sample/reference topology=

   In a typical topology= we found
TW> "we found" reads = strange. What about "A RPL network is composed of
TW> ...[6LR,6LBR]... logically = organized in a DODAG structure".
   6LBR (6LoWPAN Border = Router), 6lR
TW> 6LR
   (6LoWPAN Router) and = 6LN (6LoWPAN Node) as leaf connected in a DODAG
   (Destination Oriented= Directed Acyclic Graph).  Between these
   entities messages suc= h as DIS, DIO and DAO are transmitted.  RPL
   defines the RPL Contr= ol message as an ICMPv6 information message with
   a Type of 155.=
TW> RPL defines the RPL Control= message, a new ICMPv6 message with
TW> Type 155. DIS, DIO and DAO = messages are all RPL Control messages
TW> but with different Code val= ues.
   RPL supports two mode= s of Downward traffic: Storing,
   it is fully stateful = or Non-Storing it is fully source routed.  Any
   given RPL Instance is= either storing or non-storing.
TW> please specify that a RPL I= nstance is either fully storing or fully
TW> non-storing, i.e. a RPL Ins= tance with a combination of storing and
TW> non-storing nodes is not su= pported

         =                    += --------------+
         =                    | Upp= er Layers |
         =                    | &nb= sp;            |
         =                    += --------------+
         =                    | &nb= sp; RPL        |
         =                    | &nb= sp;            |
         =                    += --------------+
         =                    | &nb= sp; ICMPv6     |
         =                    | &nb= sp;            |
         =                    += --------------+
         =                    | &nb= sp; IPv6       |
         =                    | &nb= sp;            |
         =                    += --------------+
         =                    | &nb= sp; 6LoWPAN    |
         =                    | &nb= sp;            |
         =                    += --------------+
         =                    | &nb= sp; PHY-MAC    |
         =                    | &nb= sp;            |
         =                    += --------------+



         =                   Figure 1: R= PL Stack











Robles & Richardson   &nb= sp;Expires December 29, 2015             &nbs= p;  [Page 3]
Internet-Draft      = ;           Useof6553         =               June 2015


         =                     &nbs= p;           +---------+
         =                     &nbs= p;       +---+Internet |
         =                     &nbs= p;       |   +---------+
         =                     &nbs= p;       |
         =                     &nbs= p;  +----+--+
         =                     &nbs= p;  |DODAG  |
         =              +---------+Root &n= bsp; +----------+
         =              |       &nb= sp; |6LBR   |          |
         =              |       &nb= sp; +----+--+          |
         =              |       &nb= sp;      |             |
         =              |       &nb= sp;      |             |
         =              |       &nb= sp;      |             |
         =        +-----+-+       &nbs= p; +--+---+      +--+---+
         =        |6LR    |        = |      |      |      |=
         =  +-----+       |         |=      |      |      |
         =  |     |       |        = |      |      |      +---= ---+
         =  |     +-----+-+         &#= 43;-+----+      +-+----+     &= nbsp;|
         =  |           |         &= nbsp;   |             |     &n= bsp;     |
         =  |           |         &= nbsp;   |             |     &n= bsp;     |
         =  |           |         &= nbsp;   |             |     &n= bsp;     |
         = +-+---+     +-+---+      &= #43;--+--+       +- --+     +-= --+-+
         = |Leaf |     |     |      |    = |       |    |     |     |
         = |6LN  |     |     |      |   &= nbsp; |       |    |     |    = |
         = +-----+     +-----+      +----= -+       +----+     +-----+


         =           Figure 2: A reference RPL Topology
TW> I would add a "."= at end of each caption

   In different scenario= s the use of RFC 6553, RFC 6554 and tunneling
   can take place:
TW> I would say that a combinat= ion of RFC6553, RFC6554 and IP-in-IP
TW> encapsulation is used for t= he following traffic flows:

   -Flow from leaf to ro= ot
TW> remove newlines?
   -Flow from leaf to In= ternet

   -Flow from leaf to le= af

   -Flow from Internet t= o leaf

   -Flow from leaf to ro= ot
TW> duplicate

4.  Example flow from leaf to= root

   A leaf node generates= DAO and DIS messages and in general does not
   accept them.
TW> what do you mean by "a= ccept"?
   Additionally, this ki= nd of nodes
TW> node
   accepts DIO messages,=
   but in general do
TW> does
   not generate them. &n= bsp;(In inconsistency A leaf node
   generates DIO with in= finite rank, to fix it).
TW> A -> a




Robles & Richardson   &nb= sp;Expires December 29, 2015             &nbs= p;  [Page 4]
Internet-Draft      = ;           Useof6553         =               June 2015


4.1.  Non-storing

   In non-storing=
TW> mode
   in this case
TW> remove "in this case&q= uot;
   the leaf node uses Ho= p-By-Hop option (RFC
   6553) to indicate the= routing information to send messages to the
   DODAG root, this mess= age is going to be analyzed in each node until
   arrive the DODAG root= .

   RFC 6554 was created = to strictly send information between RPL routers
   in the same RPL routi= ng domain.  How it would be in 6554?
TW> I assume a "TODO"= missing before last sentence?

   TBD: Tunneling is nec= essary in case that there is information to send
   outside RPL Domain an= d other cases?

         =                 +------+
         =                 |     &n= bsp;|
         =                 | 6LBR |
         =                 |     &n= bsp;|
         =                 +---+--= 3;
         =                     |
         =                     | &n= bsp;LoWPAN_HC
         =                     | &n= bsp;Route=3D 6LN-6LR-6LBR
         =              ^      |
         =              |  +---+-+= ;
         =              |  |     |<= /font>
         =              |  | 6LR |
         =              |  |     |<= /font>
         =              |  +--+--+= ;
         =              |     |   L= oWPAN_HC
         =              |     |   R= oute=3D 6LN-6LR-6LBR
         =              |     |
         =              +     |
         =                 +--+--+= ;
         =                 | 6LN |
         =                 |     |<= /font>
         =                 |     |<= /font>
         =                 +-----+

         =     Figure 3: From leaf to Root - Non-Storing Mode

TW> I don't fully understand wh= at message this figure conveys
TW> I would use A B and C to na= me the nodes, and write their role
TW> next to them



4.2.  Storing

   IP6 6553{X,Y] ?ipip p= ayload.
TW> something's wrong
   In storing mode is su= itable the use of
   RFC 6553 to send RPL = Information through HBH field checking the
   routing table to find= out where to send the message.
TW> I don't understand "ch= ecking the routing table to find out where
TW> to send the message"
   It may include=
   IP-in-IP encapsulatio= n to transmit information not related with the
   RPL domain.
TW> I would expand this info





Robles & Richardson   &nb= sp;Expires December 29, 2015             &nbs= p;  [Page 5]
Internet-Draft      = ;           Useof6553         =               June 2015


         =             +------+
         =             |      |
         =             | 6LBR |
         =             |      |
         =             +---+--+
         =                 |
         =                 |  LoWPAN_HC<= /font>
         =                 |  0x63|HBH D= ata
         =          ^      |
         =          |  +---+-+
         =          |  |     |
         =          |  | 6LR | 6LR check in routing tab= le
         =          |  |     |
         =          |  +--+--+
         =          |     |   LoWPAN_HC
         =          |     |   0x63|HBH Data
         =          |     |
         =          +     |
         =             +--+--+
         =             | 6LN |
         =             |     |
         =             |     |
         =             +-----+

         =       Figure 4: From leaf to Root - Storing Mode

5.  Example flow from leaf to= Internet

5.1.  Non-storing

   In this case the IP-i= n-IP encapsulation should take place to send
   information not relat= ed to the RPL domain inside of the RPL domain.

   RPL information from = RFC 6553 should not go out to Internet.  The
   router sould
TW> typo
   take this information= out before send the packet to
   Internet.  The H= BH Option is going to be analyzed in each node to the
   root.
TW> illustrate this with a fig?=

   Related to RFC 6554 t= he Source Header route is added and removed by
   DODAG root.  How= ever, RFC 6554 was created to strictly send
   information between R= PL routers in the same RPL routing domain.  How
   it would be in 6554?<= /font>
TW> this paragraph relates to d= own traffic, right? The name of the section
TW> is "from leaf to Inter= net"









Robles & Richardson   &nb= sp;Expires December 29, 2015             &nbs= p;  [Page 6]
Internet-Draft      = ;           Useof6553         =               June 2015


5.2.  Storing

   In storing the inform= ation of RFC 6553 should take away by DODAG root
   before go to Internet= .
TW> but as well in non-storing,= no?

6.  Example flow from leaf to= leaf

   can leafs insert appr= opriate headers, without ipip?  In [RFC6550] RPL
   allows a simple one-h= op P2P optimization for both storing and non-
   storing networks.&nbs= p; A node may send a P2P packet destined to a one-hop
   neighbor direclty
TW> typo
   to that node.  S= ection 9 in [RFC6550].
TW> I would say that IP-in-IP i= s not needed in this case

6.1.  Traditional storing
TW> why "Traditional"= ?
   The route go through = an ancestor that knows the route to the
   destination, using HB= H [RFC6553] to carry RPL Information.

6.2.  Traditional non-storing=

   The route go through = the DODAG root, using source routing [RFC6554].

6.3.  P2P non-storing<= /div>

   (p2p storing?  T= BD)

7.  Example flow from Interne= t to leaf

   A DODAG root do not a= dd routing extension to incoming packets, it
   instead uses tunnelin= g.

7.1.  Storing

   DODAG root adds the H= BH header [RFC6553] and send the packet downward
   to the destination.

7.2.  Non-storing

   DODAG root is going t= o add the source route header [RFC6554]

8.  Example flow from root to= leaf

8.1.  Storing

   DODAG root adds the H= BH header [RFC6553] and send the packet downward
   to the destination.

8.2.  Non-storing




Robles & Richardson   &nb= sp;Expires December 29, 2015             &nbs= p;  [Page 7]
Internet-Draft      = ;           Useof6553         =               June 2015


   DODAG root is going t= o add the source route header [RFC6554]

9.  IANA Considerations

   There are no IANA con= siderations related to this document.

10.  Security Considerations<= /font>

   TBD.
TW> I would replace TBD by TODO= , per usual covention

11.  Acknowledgements<= /div>
TW> typo

   This work is partiall= y funded by the FP7 Marie Curie Initial Training
   Network (ITN) METRICS= project (grant agreement No.  607728)

12.  References

12.1.  Normative References

   [RFC2119]  Bradn= er, S., "Key words for use in RFCs to Indicate
         =     Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6550]  Winte= r, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
         =     Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
         =     Alexander, "RPL: IPv6 Routing Protocol for Low-Power an= d
         =     Lossy Networks", RFC 6550, March 2012.

   [RFC6553]  Hui, = J. and JP. Vasseur, "The Routing Protocol for Low-
         =     Power and Lossy Networks (RPL) Option for Carrying RPL
         =     Information in Data-Plane Datagrams", RFC 6553, March
         =     2012.

   [RFC6554]  Hui, = J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
         =     Routing Header for Source Routes with the Routing Protocol
         =     for Low-Power and Lossy Networks (RPL)", RFC 6554, Marc= h
         =     2012.

12.2.  Informative References=

   [RFC7102]  Vasse= ur, JP., "Terms Used in Routing for Low-Power and
         =     Lossy Networks", RFC 7102, January 2014.

Authors' Addresses








Robles & Richardson   &nb= sp;Expires December 29, 2015             &nbs= p;  [Page 8]
Internet-Draft      = ;           Useof6553         =               June 2015


   Maria Ines Robles
   Ericsson
   Hirsalantie 11=
   Jorvas  02420
   Finland



   Michael C. Richardson=
   Sandelman Software Wo= rks
   470 Dawson Avenue
   Ottawa, ON  K1Z = 5V7
   CA


































Robles & Richardson   &nb= sp;Expires December 29, 2015             &nbs= p;  [Page 9]


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



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



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

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ie= tf.org/mailman/listinfo/roll
--_000_EFB43824D17247949371770ECF92CF27ciscocom_-- From nobody Sat Jul 4 06:34:19 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027BE1ACDFA for ; Sat, 4 Jul 2015 06:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL4aXl0YAD48 for ; Sat, 4 Jul 2015 06:34:14 -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 8060A1ACDEA for ; Sat, 4 Jul 2015 06:34:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A9EFD20012 for ; Sat, 4 Jul 2015 09:49:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A3C1163AEC; Sat, 4 Jul 2015 09:34:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8890C63AE8 for ; Sat, 4 Jul 2015 09:34:12 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: [Roll] some comments on draft-thubert-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 13:34:17 -0000 --=-=-= Content-Type: text/plain Pascal, thank you for this document. I especially appreciated your figure 2, the way that you numbered the nodes with their gross rank as the the tens part. You write on page 8: The root sends the DAO directly to the last node in the segment, which is expected to be able to route to the targets on its own. It would be good to make it clear which direction one counts the "segment" to know which one is last. I don't like "segment" here, I think it's a routing path... Could you define segment if you think it's the most natural term to use. (There are also some articles like "the" missing in places, btw) Then you write: The node strips the last Via Information option which corresponds to self, and uses it as source address for the DAO to the predecessor. I think that what is described, to use the numbering in your example, is that the root would send a message to 41, with a target=51, list of VIAs:11,22,31,41 and *then* 41 would send a DAO to 31, with a list of VIAs 11,22,31, etc. It's the "then" above part that I *think* is a critical part of the protocol, and is perhaps not clearly spelled out. I wasn't entirely sure if I read it correctly. In the case where nodes have different downstream and upstream addresses (because, for instance they had different radios), then there might be some confusion and maybe both hops should be listed. I recall I posted a thread asking about that a year or so ago, but I don't recall what the conclusion was. But, then in the example on page 9, after sending these Via-DAOs to 45 and 46, it says: The root may then send a DAO to node 35 indicating targets 55 and 56 a Via segment (13, 24, 35) to fully optimize that path. While the root had initially optimized the 45/46 out the routing header with the first set of Via-DOAs (do you have a name for these messages? Projected-DAOs? maybe), couldn't that set of DOAs have included 13,24 in the list as well? Alternatively, could the root have sent a single Via-DOA with destination *35* to 24, with the route 13,24? That would have resulted in a routing header like: ROOT -> 35 since 13 and 24 should be able to reach 35 in a loose source route, and 35 would know how to reach 55 and 56? **** in section 3.1, the description of the VIA extension, you write: Option Length: Variable, depending on whether or not Parent Address is present. But the only variability I saw in the extension was whether the child address was 8 bytes or 16 bytes. It seems that if you are going to optimize this, you might as well also offer an option for the Child Address to be 2 bytes (the last two bytes). **** DAO I don't fundamentally see a reason why DAO is used. I guess it has the right properties, but I think that a new message type could be defined equally well (as well as a new ACK), even if it just replicates the exact DAO structure. It seems that the ACK is mandatory (K=1). I would prefer that DAOs always flow towards the root, and DIOs away. It would make analysis of what is going on easier. These DAOs in some way flow towards a node with root-like storing-like abilities, so I can see why it was elegant to reuse DAO for this. **** incremental deployment Use of a new MOP makes deployment of this a flag day. I don't think that this is necessary, although some niggling doubt going back to the mixed storing/non-storing discussion of 2011 remains... I think that the DAOs that come from nodes that are able to act as Route Projection nodes could indicate that capability, and furthermore, indicate the number of routing slots they currently have free. It would be advantageous perhaps to explicitely number the routing slots. My initial thought is that would permit the subsequent DAOs to perhaps include a count of how many times the Projected route was used: once the DODAG root pushes traffic away from the root with these projected routes, it can no longer count how much traffic is occuring, so it should get reports "from the field" so that it can decide whether to keep those routes. Explicitely numbering the routing slots could be problematic I agree, but it would allow the DODAG to manage them directly rather than the implicit process that the VIA option's Path Sequence is doing. The Path Sequence processing needs an example, btw. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVZfg1ICLcPvd0N1lAQIl7wf/e7wNvwyx59FuYZUY2RMdzilVt8UXGGSn l/ZW+X2RGSno5nWrDSt+Rkc8qzINu+2UKGEvAZUuw2kju3d2hJE9qgdBIcjAuQIJ SE8gHBxSSlEQSG/UNK1zpkeGEXO6n8Iljb/lkaawQ3F8goC58XKyeO4b/pzRI8hN 1Vpxg0WE4rawDaA2zVFBWKH3LtpoG+mS405tOaHN7U9kGw7/YY2VKmdS30CgywWD dQ0CpmK6azztEF+bxZWynRs5VW4kVjH8lZUZfGhxTKQ9X7ECMAkojiDEajCpiu5+ dFzzBfZgzCppBXpjSvM5OZJMJtjUs5Oqvimq6P9bZfVBiol1Q+ll7A== =HOt/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 4 13:28:35 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6525C1A005B for ; Sat, 4 Jul 2015 13:28:33 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMgkCmDGHdoE for ; Sat, 4 Jul 2015 13:28:31 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567D11A0062 for ; Sat, 4 Jul 2015 13:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5156; q=dns/txt; s=iport; t=1436041711; x=1437251311; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nvZ3nWM1V4UadBKlTF+LV1ti1QjBd0tvwhy8XzLe4uw=; b=FvHkGnIEA8bJ/PMwvDYiSDjvKpjJo8JU6qFBao6MNqO1qt4mvZuO7VQR mhamE9VvKxoLHxdb01tgxLT/aZeDTQq5I1RqVW5+1UxtAB9n3RPRho4dq PI1zTRnLJwoxhQ17WnlGSVtq+bg01YV0NGrXobUHOfuKmhzQJ8r6CZ3HI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AlBAAkQZhV/5BdJa1cgxJUYL1KCYFkCoJDgzQCgR04FAEBAQEBAQGBCoQkAQEDAQEBASRHEAsCAQhGJwslAgQTiCcIDcYXAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLS4RTCDICgxWBFAWMGTiEYIJkAYtngTqHJIwbg10mggkfgVNvgksBAQE X-IronPort-AV: E=Sophos;i="5.15,407,1432598400"; d="scan'208";a="12649979" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jul 2015 20:28:30 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t64KSUnn005156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 4 Jul 2015 20:28:30 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.112]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Sat, 4 Jul 2015 15:28:29 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] some comments on draft-thubert-dao-projection-00.txt Thread-Index: AQHQtl4uhnM3ZZux4UKM8k7V/iC9hJ3Lwz3s Date: Sat, 4 Jul 2015 20:28:29 +0000 Message-ID: References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> , <10398.1436016852@sandelman.ca> In-Reply-To: <10398.1436016852@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 20:28:33 -0000 Fantastic Michael! I'll answer in the list but many thanks already! Pascal > Le 4 juil. 2015 =E0 15:34, Michael Richardson a = =E9crit : >=20 >=20 > >=20 > Pascal, thank you for this document. > I especially appreciated your figure 2, the way that you numbered the nod= es > with their gross rank as the the tens part. >=20 > You write on page 8: > The root sends the DAO directly to the last node in the segment, > which is expected to be able to route to the targets on its own. >=20 > It would be good to make it clear which direction one counts the "segment= " > to know which one is last. I don't like "segment" here, I think it's > a routing path... Could you define segment if you think it's the most > natural term to use. > (There are also some articles like "the" missing in places, btw) >=20 > Then you write: > The node strips the last Via Information option which corresponds to > self, and uses it as source address for the DAO to the predecessor. >=20 > I think that what is described, to use the numbering in your example, > is that the root would send a message to 41, with a target=3D51, > list of VIAs:11,22,31,41 and *then* 41 would send a DAO to 31, > with a list of VIAs 11,22,31, etc. >=20 > It's the "then" above part that I *think* is a critical part of the proto= col, > and is perhaps not clearly spelled out. I wasn't entirely sure if I > read it correctly. >=20 > In the case where nodes have different downstream and upstream addresses > (because, for instance they had different radios), then there might be > some confusion and maybe both hops should be listed. I recall I posted a > thread asking about that a year or so ago, but I don't recall what the > conclusion was. >=20 > But, then in the example on page 9, after sending these Via-DAOs to > 45 and 46, it says: > The root > may then send a DAO to node 35 indicating targets 55 and 56 a Via > segment (13, 24, 35) to fully optimize that path. >=20 > While the root had initially optimized the 45/46 out the routing > header with the first set of Via-DOAs (do you have a name for these messa= ges? > Projected-DAOs? maybe), couldn't that set of DOAs have included 13,24 > in the list as well? >=20 > Alternatively, could the root have sent a single Via-DOA with destination > *35* to 24, with the route 13,24? That would have resulted in a routing > header like: > ROOT -> 35 > since 13 and 24 should be able to reach 35 in a loose source route, > and 35 would know how to reach 55 and 56? >=20 > **** >=20 > in section 3.1, the description of the VIA extension, you write: >=20 > Option Length: Variable, depending on whether or not Parent Address > is present. >=20 > But the only variability I saw in the extension was whether the child > address was 8 bytes or 16 bytes. It seems that if you are going to > optimize this, you might as well also offer an option for the Child > Address to be 2 bytes (the last two bytes). >=20 > **** DAO >=20 > I don't fundamentally see a reason why DAO is used. I guess it has the > right properties, but I think that a new message type could be defined > equally well (as well as a new ACK), even if it just replicates the exact= DAO > structure. It seems that the ACK is mandatory (K=3D1). >=20 > I would prefer that DAOs always flow towards the root, and DIOs away. > It would make analysis of what is going on easier. > These DAOs in some way flow towards a node with root-like storing-like > abilities, so I can see why it was elegant to reuse DAO for this. >=20 > **** incremental deployment >=20 > Use of a new MOP makes deployment of this a flag day. > I don't think that this is necessary, although some niggling doubt going = back > to the mixed storing/non-storing discussion of 2011 remains... >=20 > I think that the DAOs that come from nodes that are able to act as Route > Projection nodes could indicate that capability, and furthermore, indicat= e > the number of routing slots they currently have free. >=20 > It would be advantageous perhaps to explicitely number the routing slots. > My initial thought is that would permit the subsequent DAOs to perhaps > include a count of how many times the Projected route was used: once the > DODAG root pushes traffic away from the root with these projected routes, > it can no longer count how much traffic is occuring, so it should get > reports "from the field" so that it can decide whether to keep those rout= es. >=20 > Explicitely numbering the routing slots could be problematic I agree, > but it would allow the DODAG to manage them directly rather than the impl= icit > process that the VIA option's Path Sequence is doing. >=20 > The Path Sequence processing needs an example, btw. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Sat Jul 4 14:23:13 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16B1A1A31 for ; Sat, 4 Jul 2015 14:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9os5aoPhGb4v for ; Sat, 4 Jul 2015 14:23:10 -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 D7BE91A1A2C for ; Sat, 4 Jul 2015 14:23:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2A65920012 for ; Sat, 4 Jul 2015 17:38:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D022063B10; Sat, 4 Jul 2015 17:23:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B0E6D63AE8 for ; Sat, 4 Jul 2015 17:23:07 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: [Roll] direction of draft-robles-roll-useofrplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 21:23:12 -0000 --=-=-= Content-Type: text/plain You will recall that the ROLL WG was rechartered back in March to include two new work items: Work Items: - Details about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation. - Details about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context (from https://datatracker.ietf.org/wg/roll/charter/ ) Noting a certain lack of enthusiasm to get item one started, yet knowing that we need to get it very clear, Ines and I wrote draft-robles-roll-useof-rplinfo. The document is now at: https://drive.google.com/file/d/0B8TIw964rTlfcnNpb3pBc2VsSTg/view?usp=sharing (you can comment) https://github.com/ietf-roll/useofrplinfo (fork it and send pull request) We anticipate asking the WG to adopt it; we would also like to have help editing this document, but regardless we should diverge slightly to talk about conflicts. As both of your WG chairs are authors, on the advice of a routing AD, we will be seeking another party to judge consensus, and we will also need a document shepherd. Now about, the document, from the table of contents: 3. Sample/reference topology 4. Example flow from leaf to root . . 5. Example flow from leaf to Internet 6. Example flow from leaf to leaf . . 7. Example flow from Internet to leaf 8. Example flow from root to leaf . . The first thing is that I think we will adopt the numbering for the nodes that Pascal's document had. The purpose of having these example flows is to make precise what node inserts what header, where the headers are removed (and potentially re-added), and what headers are either modified or untouched during the flow. Pessimistically, we need all the various headers (RPI, RH3 and IPIP) on every packet, but actually, that may not always be true. Getting the rules well established is important if we are going to be able to compress things well. Additionally, each flow has potential changes between storing and non-storing mode. Questions: 1) Are the situations where it is okay for RPI information to flow out to the Internet? For instance, in an P2MP situation (such as AMI) where the collection point is RPL aware, could we drop the IPIP header (5. example), given that the leaf node will insert the RPI, and on upwards flows we do not need RH3 headers (for both storing and non-storing). 2) Are there situations, such as leaf to leaf in a non-storing situation, where the originating leaf can avoid an IPIP header having to be inserted by the Root, by inserting the RH3 header (empty) itself? i.e. set Segments Left = 0, but reserve space for them using the ext header len. Then the root could fill them in. 3) Are there additional situations in which we can or should dispense with one or more of these headers? -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVZhOuICLcPvd0N1lAQIwkAf+N59Z7ko0VC7wKsIB0UINQKmNdAyyQzuU +bXcT1T7X15MvZrWQW9kQ1VO3ameodta625tdVUmRwnkMQot+rUljNq1fxoh4C46 65eaePWPjgMXWZ+QKpvKRklo8ScRuvl5oE8IveVnwkhVkLzHlewqupe1brRCoez3 SZTKDYF7bGhob/psCmBC6bAkHHQWQVJURvV5BkRmV1n1bZ55uIuvSwubmz5W9eq4 R+w+Opuwr0/F/YRCM0KIiIShu40azK+mlmzvhnZjQZULsB2pgVBXY9AhjV//fQ7R VzVz47BFLFHAVW5t+5t+33G/xshDWUfp0pLm+BAQknpA4CL4sXSyuA== =aPYQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 4 14:33:06 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBB31A1AA9 for ; Sat, 4 Jul 2015 14:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaI-vBDQViho for ; Sat, 4 Jul 2015 14:33:04 -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 DF1021A1AA8 for ; Sat, 4 Jul 2015 14:33:03 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 474062002A; Sat, 4 Jul 2015 17:48:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 22EE463AEC; Sat, 4 Jul 2015 17:33:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0455263AE8; Sat, 4 Jul 2015 17:33:03 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] Thomas' remarks on draft-robles-roll-useofrplinfo-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 21:33:05 -0000 --=-=-= Content-Type: text/plain Ines Robles wrote: > 2. Terminology and Requirements Language TW> you're actually not using any of this language in the draft. if you TW> keep it that way, and since the draft is informational I would TW> recommend to remove this section We are not using any of this language ... *YET* I'm not sure it's going to be Informational... the charter is not specific. I think it may wind up as standards track, and it may Update 6553/6554. I don't think it will update 6550. -- ] 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 [ > Robles & Richardson Expires December 29, 2015 [Page 9] > _______________________________________________ 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 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVZhRC4CLcPvd0N1lAQIcPwf/ftVIZGGOx2gJyXTxcHvnHfIo/FfOKJxq cKKGo+zqPnKtrIPsfeyzsSc1oyyV7DinyoqPT+Op0+JPwoGCDPwEysAg+W26EfwP vUYal3ACvqmq/Vq3Y1ETov5cn9lQplUDntvvolh2HOATkpd/4xlE8jaJ72SQ31hy 3XhkUFCC1vbKr7BbauLGoi6mRXp57f7lmvInxBkUXWeWdEcUebpaFAtcDmhnND00 rdDUmhjTZnWWZowLsKeyGXlhtXCvCo+luUDaEhknqH3XmZyB+HMnUuMuhpdKJAg0 EzFBt4f/BB3jT7l0h9YfwlqsQVdff4jxaTDUmi8BkHE0+9QJc/z3hQ== =Xp+u -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 4 14:35:42 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021FE1A1AB8 for ; Sat, 4 Jul 2015 14:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUbwkLvlWkVU for ; Sat, 4 Jul 2015 14:35:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A331A1AA8 for ; Sat, 4 Jul 2015 14:35:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3F7A62002A for ; Sat, 4 Jul 2015 17:51:24 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id DD4DB63AEC; Sat, 4 Jul 2015 17:35:37 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 816D863AE8 for ; Sat, 4 Jul 2015 17:35:37 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: , X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] [6tisch] Thomas' remarks on draft-robles-roll-useofrplinfo-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 21:35:40 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > On the side Ines I m willing to contribute with formats in the > compressed form from the 6LoRH draft if it is successful at 6lo. > Would you want that in? Depending upon timing and process it could all be a single document, or it could be two documents. I'd say to write up what you suggest as a seperate document (leave out all the motherhood preamble...)... -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVZhRpoCLcPvd0N1lAQKqgQf7B42Ebn63SROD07B394MwcDwFDv93T6sH wmbp6qWpjDtvqlHkIypAEwh2OdGP6uVEdtPkB+MqpJMwUepAcRN7l1TwIHbrTbO6 8kno0AE2sJgBUzvlPUn8vvvqcJJGZNmNPKFxn6tWM+EkH70/Bt/TR3r9qDDnY6k/ xsAazaQspg0JrEplm7azjWg61D01RQepkJ/soJTnjF+p2jhxHifPsoGTuTKgASgA tBQf0ghV8N09GASrmmiAf1NDRWJI6BCk3suIoCULL8LKAa8Y6zDl4Jb7DvayY1s4 MRU5clOyfHsjQAuVpgMkuVjtiUXOEOim+ovjh0WfFshWfZDesRJKzA== =UCI1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 5 13:25:04 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919091ACD50 for ; Sun, 5 Jul 2015 13:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfiihKF4Ajml for ; Sun, 5 Jul 2015 13:25:02 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 E2C201ACD0C for ; Sun, 5 Jul 2015 13:25:01 -0700 (PDT) Received: by wiwl6 with SMTP id l6so267701860wiw.0 for ; Sun, 05 Jul 2015 13:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5wPK58rDUGEVkTIAhTZNQ5kn06JBdj2xvndB9BV//Bo=; b=vebD2CbMBn+/EiWvdEpX4qy8VFslnR8aF2HR9NsKbGbv9O/ueOON5kN2gEV+kixVjE uNSdLBzpfgIvIBMj97C61DXFnR41oE37NujiYFDscDHvSnn6kh5PqYHI668GoQKRuY05 y3iuGM6cfVS77/2xeyLXcRPjG1D97/JUXwj5Ml4oTUiGfZ1X29UlEPCAOsrU7+SAO9wn 1degploPEiCnYHcTeuH9oZbOlO6L8MsHa9HUoR98ySplOsSgqGRvZrssX2Y7eKv4PWai ZNGyP6jfp95lASlChgUsd2qeX7Xkk7jGkj3vVqy5VpYnXN2WWlxpvK7pjfm0ZENjsBSR iI4A== X-Received: by 10.180.87.199 with SMTP id ba7mr49240319wib.81.1436127900678; Sun, 05 Jul 2015 13:25:00 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.28.134.146 with HTTP; Sun, 5 Jul 2015 13:24:40 -0700 (PDT) In-Reply-To: <13381.1436045583@sandelman.ca> References: <13381.1436045583@sandelman.ca> From: Thomas Watteyne Date: Sun, 5 Jul 2015 22:24:40 +0200 X-Google-Sender-Auth: FHdlf2OZtk-nUXwt4UHVEiwNd7M Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=f46d0444e9395f3d3e051a269503 Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] Thomas' remarks on draft-robles-roll-useofrplinfo-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 20:25:03 -0000 --f46d0444e9395f3d3e051a269503 Content-Type: text/plain; charset=UTF-8 Michael, This makes sense. Thomas On Sat, Jul 4, 2015 at 11:33 PM, Michael Richardson wrote: > > Ines Robles wrote: > > 2. Terminology and Requirements Language > > > TW> you're actually not using any of this language in the draft. if > you > TW> keep it that way, and since the draft is informational I would > TW> recommend to remove this section > > > We are not using any of this language ... *YET* > I'm not sure it's going to be Informational... the charter is not specific. > > I think it may wind up as standards track, and it may Update 6553/6554. > I don't think it will update 6550. > > -- > ] 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 [ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Robles & Richardson Expires December 29, 2015 [Page 9] > > > > > _______________________________________________ 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 > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --f46d0444e9395f3d3e051a269503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,
This makes sense.
Thomas

On Sat, Jul 4, 2= 015 at 11:33 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Ines=C2=A0 Robles <mar= iainesrobles@googlemail.com> wrote:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A02. Terminology and Requirements Langu= age


=C2=A0 =C2=A0 TW> you're actually not using any of this langu= age in the draft.=C2=A0 if you
=C2=A0 =C2=A0 TW> keep it that way, and since the draft is informational= I would
=C2=A0 =C2=A0 TW> recommend to remove this section


We are not using any of this language ... *YET*
I'm not sure it's going to be Informational... the charter is not s= pecific.

I think it may wind up as standards track, and it may Update 6553/6554.
I don't think it will update 6550.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 | network architect=C2=A0 [
]=C2=A0 =C2=A0 =C2=A0mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0ruby on rails=C2=A0 =C2=A0 [






























































=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Robles & Richardson Expires Decem= ber 29, 2015 [Page 9]



=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0_____________________________________= __________ Roll mailing list
=C2=A0 =C2=A0 > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll




=C2=A0 =C2=A0 > _______________________________________________ Roll mai= ling list
=C2=A0 =C2=A0 > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll

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




--f46d0444e9395f3d3e051a269503-- From nobody Sun Jul 5 17:07:38 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0C01B29AC for ; Sun, 5 Jul 2015 17:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pL7GCSlDCkP for ; Sun, 5 Jul 2015 17:07:36 -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 0C4121B29AB for ; Sun, 5 Jul 2015 17:07:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7BFD420012 for ; Sun, 5 Jul 2015 20:23:24 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 910C363AEC; Sun, 5 Jul 2015 20:07:34 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7BDB663AE8 for ; Sun, 5 Jul 2015 20:07:34 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> , <10398.1436016852@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 00:07:37 -0000 --=-=-= Content-Type: text/plain > It would be good to make it clear which direction one counts the "segment" > to know which one is last. I don't like "segment" here, I think it's > a routing path... Could you define segment if you think it's the most > natural term to use. > (There are also some articles like "the" missing in places, btw) I also realized yesterday that 6554/RH3, uses the term segment. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVZnGxoCLcPvd0N1lAQJAjggAu2W90+ETCkwMP2KAk1oCGkIzwdAQQ3RP WxM97GXVJbCpQszCoUY+MNVjO/c90EF0atp5xFdOaJseuizwguxKyvKsv+jItHtv 7emdRS5JrrFLeQ0Ttlz8VRhJrPwNV++6l5HVcEpcCnQNL3CmGJXfHD2HM06oS8Xl JWz1eqaSFTFcoPgbjaqZo0qjm+S33iU0aCTvEUPVdulTGAO2fF9Y/Ha2JgKyjdoW PWcE8HFPe7z0hZjaCTrAI1PssITz75hsxYoY0r7L1I22iLFv3Ce6wNl9Jouzj/xx G0EeJJOePN8UgKtl8FNeCRwjHOgMYv6VDNYr2bN/VBsvNnl5nV++6w== =3COw -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 6 01:36:25 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1321A908E for ; Mon, 6 Jul 2015 01:36:20 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVJMS5Hu6u9L for ; Mon, 6 Jul 2015 01:36:17 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006671A90EC for ; Mon, 6 Jul 2015 01:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1459; q=dns/txt; s=iport; t=1436171775; x=1437381375; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sybHDRk9nczCI6UKAjuyQ4yIvIPjbYn61KALXKJ0bgc=; b=FGwPiM36ONmUfkf/U8UMgHLP5MhVoZC/UuiOMLk57cQ7evU6QYhCTN36 Nzthsg9hzn8yA3vjQRM0q6sJVMPs/woM8WTd6J4hTmINDVOdUwQGKe/dS MgvbHpphS63JGMm3Z6swUwCAleXp1UFNW5UAlln1MpgTQ+QBFJSA/XEGN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DMAwBbPZpV/5FdJa1cgxKBNAa9TgmEMYM0AoEpOBQBAQEBAQEBgQqEIwEBAQQ6SwQCAQgRBAEBCxQJBzIUCQgCBBMIiCfIEAEBAQEBAQEBAQEBAQEBAQEBAQEBGItLhDceOAaDEYEUBZQVAYtomFUmg3tvgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,413,1432598400"; d="scan'208";a="165711525" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 06 Jul 2015 08:36:14 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t668aEtV005370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Jul 2015 08:36:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.136]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 03:36:14 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] some comments on draft-thubert-dao-projection-00.txt Thread-Index: AQHQtl4uhnM3ZZux4UKM8k7V/iC9hJ3Lwz3sgAIjXACAADXbMA== Date: Mon, 6 Jul 2015 08:36:13 +0000 Deferred-Delivery: Mon, 6 Jul 2015 08:35:37 +0000 Message-ID: References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> , <10398.1436016852@sandelman.ca> <26399.1436141254@sandelman.ca> In-Reply-To: <26399.1436141254@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 08:36:21 -0000 Hello Michael: The draft indicates that the root knows some topological information from t= he non-storing DAO (it knows all about the DODAG). Per RFC 6550, a path constructed by storing-mode DAO messages is directiona= l, packets flow parent to child, and we do not want to introduce confusion= by changing any of that. Thus the segment that is constructed from the segment egress to the ingress= .=20 It results that the segment is directional but not that it is necessarily f= lowing down the DADOG, this depends on how much information is available to= the root or whatever PCE is used as a helper. Cheers, Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: lundi 6 juillet 2015 02:08 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt >=20 >=20 > > It would be good to make it clear which direction one counts the > "segment" > > to know which one is last. I don't like "segment" here, I think it's > > a routing path... Could you define segment if you think it's the most > > natural term to use. > > (There are also some articles like "the" missing in places, btw) >=20 > I also realized yesterday that 6554/RH3, uses the term segment. >=20 > -- > Michael Richardson , Sandelman Software > Works -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Mon Jul 6 07:40:54 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4483C1ACECB for ; Mon, 6 Jul 2015 07:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HeoFKFs4tZp for ; Mon, 6 Jul 2015 07:40:49 -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 1E3CF1AD0AC for ; Mon, 6 Jul 2015 07:40:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D3F9020012 for ; Mon, 6 Jul 2015 10:56:37 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7114B63AEC; Mon, 6 Jul 2015 10:40:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5A58B63751 for ; Mon, 6 Jul 2015 10:40:45 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> , <10398.1436016852@sandelman.ca> <26399.1436141254@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:40:52 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > The draft indicates that the root knows some topological information > from the non-storing DAO (it knows all about the DODAG). yes... > Per RFC 6550, a path constructed by storing-mode DAO messages is > directional, packets flow parent to child, and we do not want to > introduce confusion by changing any of that. Thus the segment that is > constructed from the segment egress to the ingress. I don't think I understand what this is an alternative to. I.e. what would the way to do it wrong be? Why are you suddendly talking about storing-mode DAO messages. > It results that the segment is directional but not that it is > necessarily flowing down the DADOG, this depends on how much > information is available to the root or whatever PCE is used as a > helper. This seems to imply that traffic could flow across the mesh... i.e. hop From=20branch to branch. How would the DODAG root know that this was poss= ible using pure RPL? I think that it couldn't without 6top or something. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVZqTbYCLcPvd0N1lAQKpFAf7BDP07BKGyxpQQ62a7wpZBvtU5/pDfQ2C c+uc9ML3MJ20fpm7ybteMejO03LUIu7jcZ9IAms5QqNXcychgmE9fSg3ofbC5vwP 63UFOGDiRI62PIeAcPCK68MP3rPUSZJnGL2EyVbg71AZwjpVTMr1YujyUmur53GX 2lLxuL4EByjnGsOTwI0HuGKKoN8gm1PuN28dmsF6w38os9BffrQuOhIilyJvS6QJ zQiOYVlGatOl9eQ5d8H+6JvZAZ62s+zvWN3sjW75BfQ6xlPlR3R7MjDo4fgn4iT4 TPANDTpHjJ35qCSBX3QvKZrjomxeotd5422waaxnSlxl6yYS9xTqfQ== =F2xF -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 7 02:19:39 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 388561A9128; Mon, 6 Jul 2015 23:36:47 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FE81A901C for ; Mon, 6 Jul 2015 23:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teiikSxDBaGn for ; Mon, 6 Jul 2015 23:36:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CDE1A9127 for ; Mon, 6 Jul 2015 23:36:45 -0700 (PDT) Received: from mail-wi0-x232.google.com ([2a00:1450:400c:c05::232]:33601) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCMUl-0001eO-Ha for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Mon, 06 Jul 2015 23:36:45 -0700 Received: by wiwl6 with SMTP id l6so304346044wiw.0 for ; Mon, 06 Jul 2015 23:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=K4wqPxFm80FC9gT5A9BXclZmsHpOM8kF+SP2RFdIm20=; b=HKRtEJImfxMhvjkP0i6epNYsPamInWUjAyw4Cd2tYfhdswA3YmkBIbGY6j0qXafk7k aHv8Jfo9R4JMCt+3bS78QNUvxCMrzMRA1pFfxn7P94qltZnCXd7m+mwHG6XholUNEKib l1yOJVRcUnCMuKaQrvcxKUEv9jg5UxAq/ZF+pxAjZd6y7CXNf22+ccqMBB6uc4Ch1POR k4J605GMDnw0FTcC+Mzty8ybzQmFUEOFz9y6Pi6K5wDfuL11pqLUuGfWF1BVyVKXLa8a pdzuo68Ay1S3IZiWd9PNjZrU7blKyUS7+zhqQ/KY6SeHT5uMBV9PWOrLZRojZ8Wztu/k HH7w== MIME-Version: 1.0 X-Received: by 10.180.73.244 with SMTP id o20mr61645901wiv.31.1436250994311; Mon, 06 Jul 2015 23:36:34 -0700 (PDT) Received: by 10.28.30.14 with HTTP; Mon, 6 Jul 2015 23:36:34 -0700 (PDT) Date: Tue, 7 Jul 2015 09:36:34 +0300 Message-ID: From: =?UTF-8?B?157XoNeX150g15PXldeT15In?= To: ops-dir@ietf.org, draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org, Benoit Claise Content-Type: multipart/alternative; boundary=f46d0435c06a5307ea051a433ef1 X-SA-Exim-Connect-IP: 2a00:1450:400c:c05::232 X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org X-SA-Exim-Mail-From: menachemdodge1@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org Resent-Message-Id: <20150707063645.48CDE1A9127@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 23:36:45 -0700 (PDT) Resent-From: menachemdodge1@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Jul 2015 02:19:37 -0700 Subject: [Roll] [OPS-DIR] OPS-DIR Review of draft-ietf-roll-mpl-parameter-configuration-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 06:36:47 -0000 --f46d0435c06a5307ea051a433ef1 Content-Type: text/plain; charset=UTF-8 Hello, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document is for the Standards Track. This document defines a DHCPv6 option that will allow a network to be configured with a single set of "Multicast Protocol for Low power and Lossy Networks" (MPL) parameters easily. This is needed because MPL has a set of parameters to control its behavior which need to be identical for each MPL forwarder in the MPL domain. The MPL is defined in I-D ietf-roll-trickle-mcast The document is quite readable. Section 2.1 could be improved if for each parameter defined a reference would be given to indicate where the parameter is defined. I found most of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not sure what the Proactive_Forwarding flag is used for. Section 4 discusses Security Considerations but I think that some phrases in the paragraph are too general. Example: "other methods for security should be applied" does not indicate what these methods are or where to look for them. Another Example: "To protect attacks from outside of the network, unneccessary DHCPv6 packets should be filtered on the border router between the ROLL network and the Internet" - what is meant by "unnecessary DHCPv6 packets"? NITS ==== Section 2.3 First Paragraph Second Sentence - Remove 'is' OLD ==> Note that there may be cases in which a node may fail is to join a domain SUGGEST ==> Note that there may be cases in which a node may fail to join a domain Section 2.3 Last Paragraph is not clear. Perhaps the last sentence should read "In this case" (instead of "In the case"). Section 2.6 - First Sentence - Not Clear Is the update rate not to be more than twice the Information Refresh Time? Not clear to me how many updates are allowed in an Information Refresh Time. Should the word 'of' be replaced by 'the'. "more often than twice *the* Information Refresh Time". Suggest rephrasing this paragraph. Otherwise I have no other issues with teh document. Thank you kindly, Menachem --f46d0435c06a5307ea051a433ef1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
He= llo,

I have reviewed this document as part of the Ope= rational directorate's ongoing effort to review all IETF documents bein= g processed by the IESG.=C2=A0 These comments were written with the intent = of improving the operational aspects of the IETF drafts. Comments that are = not addressed in last call may be included in AD reviews during the IESG re= view.=C2=A0 Document editors and WG chairs should treat these comments just= like any other last call comments.

This document is for the Standards Track.

This document def= ines a DHCPv6 option that will allow a network to be configured with a sing= le set of "Multicast Protocol for Low power and Lossy Networks" (= MPL) parameters easily. This is needed because MPL has a set of parameters = to control its behavior which need to be identical for each MPL forwarder i= n the MPL domain.

The MPL is defined in I-D ietf-roll-trickle-mcast


The document is quite reada= ble.


Section 2.1 could be improved if for each paramet= er defined a reference would be given to indicate where the parameter is de= fined. I found most of them in:=C2=A0draft-ietf-roll-trickle-mcast-12 but f= or example, I'm not sure what the Proactive_Forwarding flag is used for= .

Section 4 discusses Security Considerations but = I think that some phrases in the paragraph are too general.
Examp= le: =C2=A0"other methods for security should be applied" does not= indicate what these methods are or where to look for them.
Anoth= er Example: "To protect attacks from outside of
the network, unneccessary DHCPv6 packets should be filtered on the=
border router between the ROLL network and the Inter= net" =C2=A0- what is meant by "unnecessary DHCPv6 packets"?<= /div>

<= br>
NITS=C2=A0
=3D=3D=3D=3D

Section 2.3 First Paragraph Second Sen= tence - Remove 'is'

OLD =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =3D=3D> Note that there may be cases in which a node may fail is to join= a domain
SUGGEST =3D=3D>=C2=A0Note that there may be cas= es in which a node may fail to join a domain

Section 2.3 Last Paragra= ph is not clear.

Perhaps the last sentence should read "In this = case" (instead of "In the case").


Section 2.6 - First Sentence - Not Clear

Is th= e update rate not to be more than twice the Information Refresh Time? Not c= lear to me how many updates are allowed in an Information Refresh Time.

Should the word 'of' be replaced = by 'the'.

"= ;more often than twice the=C2=A0Informati= on Refresh Time".

= Suggest rephrasing this paragraph.


Otherwise I have no other issues with teh document.

Thank you kindly,
Menachem


<= /span>

--f46d0435c06a5307ea051a433ef1-- From nobody Tue Jul 7 02:52:50 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E961A877D; Tue, 7 Jul 2015 02:52:47 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIaggXPJMexg; Tue, 7 Jul 2015 02:52:46 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D391A8776; Tue, 7 Jul 2015 02:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4742; q=dns/txt; s=iport; t=1436262765; x=1437472365; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=edbwWr70gN7O1bt+5Ptf2H8NfOnetzs304MjytdVsVU=; b=Vk/rLQrXkTnUS/KYUQPhkNPf7LvqUkOoTdE52FHLrb+GI20MfyiLuUTe VqWu8I1Ed2ImlX4f4BXEbCKc3KEaMwlBVj8mPtRbeBLU3gOUWAeAWGUVC xkyuXKsQqbqe70djMTfRdosS5XZe5KErTfROsp9/FS0DAa/Xo+NX3I+t0 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfBQCkoJtV/5BdJa1cgxJUYAaDGrxChXUCHIExOxEBAQEBAQEBgQqEIwEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQBEgiIJg2zLJZ+AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiiqEVTgGgmIvgRQFjByHfAGEYYcIgTlFg1KTCCaDe28BgUaBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,422,1432598400"; d="scan'208";a="9501272" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jul 2015 09:52:44 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t679qjAS025932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 09:52:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.136]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 04:52:44 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt Thread-Index: AQHQs1XApl1qaVb6L0KeY9/7tpYI8J3PzNEg Date: Tue, 7 Jul 2015 09:52:44 +0000 Deferred-Delivery: Tue, 7 Jul 2015 09:51:48 +0000 Message-ID: References: <20150630165644.26795.43642.idtracker@ietfa.amsl.com> In-Reply-To: <20150630165644.26795.43642.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Roll] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 09:52:47 -0000 RGVhciBhbGw6DQoNCldlIGFyZSBzdGlsbCBub3QgdGhlcmUgeWV0IGZvciB0aGUgY29tcHJlc3Np b24gb2YgUlBMIGFydGlmYWN0cyEgQnV0IGdvb2QgcHJvZ3Jlc3Mgd2FzIG1hZGUuDQpXZSBoYXZl IG1vc3Qgb2YgdGhlIGNvbXByZXNzaW9uIGRvbmUsIHdoYXQncyBsZWZ0IGlzIHRoZSBkaXNwYXRj aCBnYW1lLg0KDQpUaGlzIHZlcnNpb24gb2YgZXRoIGRyYWZ0IHByb3Bvc2VzIDMgd2F5cyB0byBh ZGFwdCA2TG9XUEFOIHdoaWxlIG1haW50YWluaW5nIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0 aCBSRkM0OTQ0LCBhbmQgb3VyIGhvcGUgaXMgdGhhdCB3ZSBzZWxlY3Qgb25lIGluIFByYWd1ZSBz byB3ZSBjYW4gc2hpcCB0aGUgZHJhZnQuIE9wdGlvbiAxIGlzIHdoYXQgd2UgcHJvcG9zZWQgYXQg dGhlIGxhc3QgSUVURiwgd2l0aCBhbiBhbHQgdHdpc3QgaW4gaXQuIE9wdGlvbiAyIGFuZCAzIGFy ZSBuZXcuIA0KDQpQbGVhc2UgY29uc2lkZXIgdGhvc2Ugb3B0aW9ucywgYW5kIGNvbWUgZGlzY3Vz cyB0aGVtIGF0IDZMbzoNCg0KICAgICAgT3B0aW9uIDEgY29uc2lkZXJzIHRoYXQgYSBuZXR3b3Jr IHdoZXJlIHRoaXMgc3BlY2lmaWNhdGlvbiBhcHBsaWVzDQogICAgICBpcyBwaHlzaWNhbGx5IHNl cGFyYXRlIGZyb20gYSBuZXR3b3JrIHdoZXJlIHRoZSBNZXNoIEhlYWRlcg0KICAgICAgZGVmaW5l ZCBpbiBbUkZDNDk0NF0gaXMgdXNlZC4gIFdpdGggdGhhdCBhc3N1bXB0aW9uLCB0aGUgTWVzaA0K ICAgICAgSGVhZGVyIGRpc3BhdGNoIHNwYWNlIGNhbiBiZSByZXVzZWQuICBBIHZhcmlhdGlvbiBp cyBwcm9wb3NlZA0KICAgICAgd2hlcmVieSB0aGUgTkFMUCBwYXR0ZXJuIDAweHh4eHh4IGlzIHJl dXNlZCBpbnN0ZWFkIG9mIHRoZSBNZXNoDQogICAgICBIZWFkZXIgcGF0dGVybi4NCg0KICAgICAg T3B0aW9uIDIgZGVmaW5lcyBhIG5ldyBTZXBhcmF0b3IgRGlzcGF0Y2ggdmFsdWUgdGhhdCBpbmRp Y2F0ZXMNCiAgICAgIHRoYXQgbm8gTWVzaCBIZWFkZXIgaXMgcHJlc2VudCBpbiB0aGUgcmVtYWlu ZGVyIG9mIHRoZSBwYWNrZXQuICBJZg0KICAgICAgdGhlIDEweHh4eHh4IHBhdHRlcm4gaXMgZm91 bmQgaW4gdGhlIHBhY2tldCBhZnRlciB0aGlzIG5ldw0KICAgICAgU2VwYXJhdG9yIERpc3BhdGNo LCB0aGVuIHRoaXMgc3BlY2lmaWNhdGlvbiBhcHBsaWVzLiAgSXQgaXMNCiAgICAgIHN1Z2dlc3Rl ZCB0aGF0IHRoZSBuZXcgU2VwYXJhdG9yIERpc3BhdGNoIHdvdWxkIGFsc28gZW5hYmxlIHRvDQog ICAgICByZXVzZSBwYXR0ZXJucyAwMHh4eHh4eCBhbmQgMTF4eHh4eHggaW4gdGhlIGZ1dHVyZS4N Cg0KICAgICAgT3B0aW9uIDMgdXNlcyB2YWx1ZXMgaW4gcGF0dGVybiAxMXh4eHh4eCB0aGF0IGFy ZSBmcmVlIHRvIHRoaXMNCiAgICAgIGRhdGUsIGF2b2lkaW5nIHBhdHRlcm5zIDExMDAweHh4IGFu ZCAxMTEwMHh4eCB0aGF0IGFyZSB1c2VkIGZvcg0KICAgICAgdGhlIEZyYWdtZW50YXRpb24gSGVh ZGVyIGFzIGRlZmluZWQgaW4gW1JGQzQ5NDRdLg0KDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogbWFyZGkgMzAganVpbiAy MDE1IDE4OjU3DQpUbzogUm9iZXJ0IENyYWdpZTsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsg UGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgTGF1cmVudCBUb3V0YWluOyBDYXJzdGVuIEJvcm1h bm47IExhdXJlbnQgVG91dGFpbjsgRHIuIENhcnN0ZW4gQm9ybWFubjsgUm9iZXJ0IENyYWdpZQ0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10aHViZXJ0LTZsby1y b3V0aW5nLWRpc3BhdGNoLTA0LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10 aHViZXJ0LTZsby1yb3V0aW5nLWRpc3BhdGNoLTA0LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z aXRvcnkuDQoNCk5hbWU6CQlkcmFmdC10aHViZXJ0LTZsby1yb3V0aW5nLWRpc3BhdGNoDQpSZXZp c2lvbjoJMDQNClRpdGxlOgkJQSBSb3V0aW5nIEhlYWRlciBEaXNwYXRjaCBmb3IgNkxvV1BBTg0K RG9jdW1lbnQgZGF0ZToJMjAxNS0wNi0zMA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24N ClBhZ2VzOgkJMjMNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtdGh1YmVydC02bG8tcm91dGluZy1kaXNwYXRjaC0wNC50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aHViZXJ0 LTZsby1yb3V0aW5nLWRpc3BhdGNoLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LTZsby1yb3V0aW5nLWRpc3BhdGNoLTA0DQpEaWZmOiAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRodWJlcnQt NmxvLXJvdXRpbmctZGlzcGF0Y2gtMDQNCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmljYXRp b24gcHJvdmlkZXMgYSBuZXcgNkxvV1BBTiBkaXNwYXRjaCB0eXBlIGZvciB1c2UgaW4NCiAgIFJv dXRlLW92ZXIgYW5kIG1peGVkIE1lc2gtdW5kZXIgYW5kIFJvdXRlLW92ZXIgdG9wb2xvZ2llcywg dGhhdA0KICAgcmV1c2VzIHRoZSBlbmNvZGluZyBvZiB0aGUgbWVzaCB0eXBlIGRlZmluZWQgaW4g UkZDIDQ5NDQgZm9yIHB1cmUNCiAgIE1lc2gtdW5kZXIgdG9wb2xvZ2llcy4gIFRoaXMgc3BlY2lm aWNhdGlvbiBhbHNvIGRlZmluZXMgYSBtZXRob2QgdG8NCiAgIGNvbXByZXNzIFJQTCBPcHRpb24g KFJGQzY1NTMpIGluZm9ybWF0aW9uIGFuZCBSb3V0aW5nIEhlYWRlciB0eXBlIDMNCiAgIChSRkM2 NTU0KSwgYW4gZWZmaWNpZW50IElQLWluLUlQIHRlY2huaXF1ZSBhbmQgb3BlbnMgdGhlIHdheSBm b3INCiAgIGZ1cnRoZXIgcm91dGluZyB0ZWNobmlxdWVzLiAgVGhpcyBleHRlbmRzIDZMb1dQQU4g VHJhbnNtaXNzaW9uIG9mDQogICBJUHY2IFBhY2tldHMgKFJGQzQ5NDQpLCBhbmQgaXMgYXBwbGlj YWJsZSB0byBuZXcgbGluay1sYXllciB0eXBlcw0KICAgd2hlcmUgNkxvV1BBTiBpcyBiZWluZyBk ZWZpbmVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Jul 7 11:18:07 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A221A19F8; Tue, 7 Jul 2015 11:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5ZlYRYYr0cn; Tue, 7 Jul 2015 11:18:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ADF1A07BD; Tue, 7 Jul 2015 11:18:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150707181803.6403.35920.idtracker@ietfa.amsl.com> Date: Tue, 07 Jul 2015 11:18:03 -0700 Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: [Roll] Barry Leiba's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 18:18:05 -0000 Barry Leiba has entered the following ballot position for draft-ietf-roll-mpl-parameter-configuration-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be a very easy discussion to resolve: -- Section 2.3 -- A node SHOULD leave an MPL domain if it receives an updated MPL Parameter Configuration Option without a configuration for the MPL domain, unless it has overriding manual configuration on the MPL domain. In other words, if a node is configured to work as a MPL Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY stay on the MPL domain even if it receives an MPL Parameter Configuration Option without configuration for the MPL domain. I'm confused by this, because it appears to contradict itself. Some questions might help he understand: If I receive an updated MPL PCO that lacks a config for the MPL domain, then there are two possible situations: Case 1: I do *not* have an overriding manual config for the domain. In this case, the text says that I SHOULD leave the domain. Is that correct? Is it OK in this case for me to decide to stay on the domain anyway, even if I have no manual configuration for it? Case 2: I *do* have an overriding manual config for the domain. In this case, the text seems to say that it's entirely my choice ("MAY") whether or not I stay on the domain or leave it. Is that correct? Please discuss this with me, so I can suggest how to make the text clearer, depending upon the answers to those questions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 2.1 -- option_len: Length of the option. It SHOULD be 16 (without MPL domain address) or 32 (with MPL domain address). "SHOULD", really? What else *can* it be, and still be valid? Is there any legitimate reason I might make it something else? Or should this just say this?: NEW? option_len: Length of the option, which is 16 if no MPL domain address is present, or 32 if there is an MPL domain address. END From nobody Tue Jul 7 14:01:09 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900501A90B6; Tue, 7 Jul 2015 14:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CempQlKuOAjc; Tue, 7 Jul 2015 14:01:04 -0700 (PDT) Received: from mail.saloits.com (saloits.com [208.42.140.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752E91A90DD; Tue, 7 Jul 2015 14:01:04 -0700 (PDT) Received: from [192.168.63.62] (173-11-44-141-Minnesota.hfc.comcastbusiness.net [173.11.44.141]) by mail.saloits.com (8.14.4/8.14.3) with ESMTP id t67L11Ue017694; Tue, 7 Jul 2015 16:01:02 -0500 Message-ID: <559C3E04.40702@saloits.com> Date: Tue, 07 Jul 2015 16:00:52 -0500 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org> References: <20150630165644.26795.43642.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 21:01:06 -0000 > Please consider those options, and come discuss them at 6Lo: > > Option 1 considers that a network where this specification applies > is physically separate from a network where the Mesh Header > defined in [RFC4944] is used. With that assumption, the Mesh > Header dispatch space can be reused. How is this configured? Does it require manual configuration? Or, can it be reliably detected automatically? -tjs From nobody Tue Jul 7 19:35:53 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C8E1B2D59; Tue, 7 Jul 2015 19:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bFZdaC1IG5J; Tue, 7 Jul 2015 19:35:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DE41B2D54; Tue, 7 Jul 2015 19:35:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708023549.15347.9780.idtracker@ietfa.amsl.com> Date: Tue, 07 Jul 2015 19:35:49 -0700 Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: [Roll] Ben Campbell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 02:35:51 -0000 Ben Campbell has entered the following ballot position for draft-ietf-roll-mpl-parameter-configuration-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- section 2.6, 1st sentence :" A parameter set for an MPL domain SHOULD NOT be updated more often than twice of Information Refresh Time" The preposition "of" is incorrect. Normally I would say leave that for the RFC editor, but it's not clear to me if this means "twice the information refresh time" or "twice during an information refresh time (interval)". (I assume the former, but it could be more clear.) From nobody Tue Jul 7 22:27:10 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378081B30A8 for ; Tue, 7 Jul 2015 22:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsEQGrTPMd80 for ; Tue, 7 Jul 2015 22:27:07 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E741B30A6 for ; Tue, 7 Jul 2015 22:27:07 -0700 (PDT) Received: by lbbpo10 with SMTP id po10so49211579lbb.3 for ; Tue, 07 Jul 2015 22:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6CA0xckUvwyr0KABpusfnyW7zEMDANJ+Q5oHvKyetiQ=; b=jGKTHRT8J0BiX1ftoVhcySQbB7iKWeFy/glqXjEXLteGPsQkbF7Rl6ktYIofkRurpd iP1vLNl2aw3J8qwQzbQVXgMBMvmPUcApHXDpUaEozRMrEGwWtlhkfIoltvKb7NqtQf7g Nrfe+dHtzv8bx9VINiELLuAeTOgcE7p7+1RQvqqCONDfKB3hKwc6Lks9IvHOAgdTF/av UMOiR1AcVRLi6EmSWeDaGVz4H6ESKrZ0tZELmlTynuK+dC1D7niZBhprImRdXbh1yvmI 8yqpA/RwdtNjZmM5pu6wkFfxioiWwtu/sf6rhqhx9XjrgFqynBWiYQWuwu/UBM3Cpkou T1cg== MIME-Version: 1.0 X-Received: by 10.112.168.165 with SMTP id zx5mr7265382lbb.111.1436333225550; Tue, 07 Jul 2015 22:27:05 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Tue, 7 Jul 2015 22:27:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Jul 2015 08:27:05 +0300 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=001a11c23452b02c00051a566364 Archived-At: Subject: Re: [Roll] [6tisch] Thomas' remarks on draft-robles-roll-useofrplinfo-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 05:27:08 -0000 --001a11c23452b02c00051a566364 Content-Type: text/plain; charset=UTF-8 It would be great, Thanks Pascal! 2015-07-04 13:58 GMT+03:00 Pascal Thubert (pthubert) : > On the side Ines I m willing to contribute with formats in the > compressed form from the 6LoRH draft if it is successful at 6lo. > > Would you want that in? > > Pascal > > --001a11c23452b02c00051a566364 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It would be great, Thanks Pascal!

2015-07-04 13:58 GMT+03:00 Pascal Thubert = (pthubert) <pthubert@cisco.com>:
On the side Ines I m willing to contribute =C2=A0with formats in the c= ompressed form from the 6LoRH draft if it is successful at 6lo.

Would you want that in?=

Pascal

--001a11c23452b02c00051a566364-- From nobody Tue Jul 7 22:52:37 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 918F41B30EB; Tue, 7 Jul 2015 22:51:47 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755D41B30E3 for ; Tue, 7 Jul 2015 22:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable 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 zgButSYEJiwn for ; Tue, 7 Jul 2015 22:51:46 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31::14]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7682C1B30E1 for ; Tue, 7 Jul 2015 22:51:46 -0700 (PDT) Received: from p3plsmtpa09-04.prod.phx3.secureserver.net ([173.201.193.233]:37812) by merlot.tools.ietf.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZCiGl-0002ZK-C6 for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Wed, 08 Jul 2015 07:51:44 +0200 Received: from spectre ([173.8.184.78]) by p3plsmtpa09-04.prod.phx3.secureserver.net with id phr11q0021huGat01hr1Bq; Tue, 07 Jul 2015 22:51:03 -0700 From: "Peter Yee" To: Date: Tue, 7 Jul 2015 22:51:05 -0700 Message-ID: <005301d0b942$15b778b0$41266a10$@akayla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC5QfhJj+rFIRDQR6aeB9bnDfx/Pg== Content-Language: en-us X-SA-Exim-Connect-IP: 173.201.193.233 X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org X-SA-Exim-Mail-From: peter@akayla.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org Resent-Message-Id: <20150708055146.7682C1B30E1@ietfa.amsl.com> Resent-Date: Tue, 7 Jul 2015 22:51:46 -0700 (PDT) Resent-From: peter@akayla.com Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Jul 2015 22:52:36 -0700 Cc: gen-art@ietf.org, ietf@ietf.org Subject: [Roll] Gen-ART Telechat review for draft-ietf-roll-mpl-parameter-configuration-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 05:51:47 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-roll-mpl-parameter-configuration-06 Reviewer: Peter Yee Review Date: Jul-07-2015 IETF LC End Date: Jun-30-2015 IESG Telechat date: Jul-09-2015 Summary: This draft is basically ready for publication as Standards Track RFC. [Ready.] The update from draft -04 to -06 handles my comments from the Last Call review. Thank you! This draft describes a DHCPv6 option used to request MPL configuration parameter sets. Major Issues: None. Minor Issues: None. Nits: None that I care to raise. From nobody Wed Jul 8 01:04:48 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4DE1B324F; Wed, 8 Jul 2015 01:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L63o95uG6Jcu; Wed, 8 Jul 2015 01:04:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC261B324B; Wed, 8 Jul 2015 01:04:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708080446.7700.80046.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 01:04:46 -0700 Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 08:04:48 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-roll-mpl-parameter-configuration-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I don't get the update model - if all MPL forwarders have to use the same parameters but they don't all do DHCPv6 at the same time, then won't new parameter settings take a while to propagate to most of the network? And won't that cause a problem? Don't you need a "start using this set of parameters in N seconds" field in the dhcp option to handle that? This is not a DISCUSS as I think it relats to Barry's so please try address this when addressing that. - please do not pretend rfc 3315 is a solution for anything unless you mean it and I don't think you do. 3315 is I think the canonical example for mythical security:-( From nobody Wed Jul 8 06:16:52 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F32C1B3528; Wed, 8 Jul 2015 06:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OBXcoQYJTI8; Wed, 8 Jul 2015 06:16:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 123C61A92B2; Wed, 8 Jul 2015 06:16:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708131648.13510.47968.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 06:16:48 -0700 Archived-At: Cc: menachemdodge1@gmail.com, roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: [Roll] Benoit Claise's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 13:16:49 -0000 Benoit Claise has entered the following ballot position for draft-ietf-roll-mpl-parameter-configuration-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From the OPS-DIR review done by Menachem: The document is quite readable. Section 2.1 could be improved if for each parameter defined a reference would be given to indicate where the parameter is defined. I found most of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not sure what the Proactive_Forwarding flag is used for. Section 4 discusses Security Considerations but I think that some phrases in the paragraph are too general. Example: "other methods for security should be applied" does not indicate what these methods are or where to look for them. Another Example: "To protect attacks from outside of the network, unneccessary DHCPv6 packets should be filtered on the border router between the ROLL network and the Internet" - what is meant by "unnecessary DHCPv6 packets"? NITS ==== Section 2.3 First Paragraph Second Sentence - Remove 'is' OLD ==> Note that there may be cases in which a node may fail is to join a domain SUGGEST ==> Note that there may be cases in which a node may fail to join a domain Section 2.3 Last Paragraph is not clear. Perhaps the last sentence should read "In this case" (instead of "In the case"). Section 2.6 - First Sentence - Not Clear Is the update rate not to be more than twice the Information Refresh Time? Not clear to me how many updates are allowed in an Information Refresh Time. Should the word 'of' be replaced by 'the'. "more often than twice the Information Refresh Time". Suggest rephrasing this paragraph. From nobody Wed Jul 8 07:24:40 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2334F1B36D6; Wed, 8 Jul 2015 07:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90e0lUwboEBm; Wed, 8 Jul 2015 07:24:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF311B377D; Wed, 8 Jul 2015 07:15:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708141537.17660.50617.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 07:15:37 -0700 Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 14:24:39 -0000 Brian Haberman has entered the following ballot position for draft-ietf-roll-mpl-parameter-configuration-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Some of these points come from Bernie Volz's INT-Dir review... 1. This is one of the few options that is not a singleton, as defined in section 16 of RFC 7227. While the use of multiple options seems appropriate here, it would be best to clarify that clients (section 2.2) and servers (section 2.4) must be able to support multiple instances of this option. Given the discussion around supporting multiple MPL domains in draft-ietf-roll-trickle-mcast, I would expect there to be situations where the option appears multiple times. 2. In section 2.3 (MPL Forwarder Behavior), there should be a brief discussion of the role of the MPL Domain Address and include a reference to [I-D.ietf-roll-trickle-mcast]. 3. In section 2.6 (Operational Considerations), the text is a bit odd. Why should a parameter set not be updated more often than twice the Information Refresh Time? How does the failure to refresh the option play with text in section 2.3 that indicates a missing option means the node should leave the MPL domain? Perhaps defining what "failure to refresh" means (i.e., I think it refers to lack of a DHCPv6 server response to a Renew or Information Request). Note also that Information Refresh Time is only applicable to Information-Request messages (see RFC 4242) so work may be needed as to how this this sections relate to Renew/Rebind operations? I am also not sure why 2.6 is a standalone section when it appears to be only applicable to clients and should be in either section 2.2 or 2.3. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. I support Barry's DISCUSS on the lack of an option potentially forcing a node to leave an MPL domain. 2. Why is the text in Appendix B not in the Operational Considerations section? 3. Please be consistent with the use of MUSTs and SHALLs. Pick one. 4. In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph - why would a client discard the option if the reserved bits are set? I would think you'd want to use a new option if you're changing things drastically? But it certainly is your choice as to whether you want to do that. Perhaps a better reason is if one of the not-permitted values is used (such as 0 and 'all-bits-set') where are clearly reserved? 0 in many of these case could be bad since that would yield 0 time values? This really is up to you, but do think about what you might want to do any maintain backwards compatibility. Adding a new flag bit to the reserved field is probably not going to break things if existing implementations ignore the bit(s). From nobody Wed Jul 8 09:24:57 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5487E1A03A1 for ; Wed, 8 Jul 2015 09:24:55 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpW5AeVc1s7C for ; Wed, 8 Jul 2015 09:24:54 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DEF1A03A0 for ; Wed, 8 Jul 2015 09:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1036; q=dns/txt; s=iport; t=1436372695; x=1437582295; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=V3G2jFiAzh9krJBAm4zXxgU+PRzbFAlq2RzFmn7Sdcc=; b=mDzKMErPb+1dMs9R1iVSi4m3EE2JMkFIYT5ZZgFXvU8eGglIQw6/3U46 IEiE7+PPFX/IrPmk6QWFtlvGwLt214g3LRNNol0Owy6IFgx88/uacu8uO X/pbiojkwSaT/MC3sPOx9d687YZAnOlj9g/erGOsBqPSY3JW6Mw/BW/pL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DrAwDDTZ1V/5FdJa1cgxKBNAa9SQmEMoM0AoFaOBQBAQEBAQEBgQqEIwEBAQQ6SwQCAQgRBAEBCxQJBzIUCQgCBBMIiCbNegEBAQEBAQEBAQEBAQEBAQEBAQEZi0uENx44BoMRgRQFlCMBi36YYSaDe2+BR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,432,1432598400"; d="scan'208";a="166736525" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 08 Jul 2015 16:24:54 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t68GOrR3024092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Jul 2015 16:24:53 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.136]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 11:24:53 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] some comments on draft-thubert-dao-projection-00.txt Thread-Index: AQHQtl4uhnM3ZZux4UKM8k7V/iC9hJ3Lwz3sgAIjXACAA+Ej4A== Date: Wed, 8 Jul 2015 16:24:52 +0000 Deferred-Delivery: Wed, 8 Jul 2015 16:24:03 +0000 Message-ID: References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> , <10398.1436016852@sandelman.ca> <26399.1436141254@sandelman.ca> In-Reply-To: <26399.1436141254@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 16:24:55 -0000 Yes,=20 segment is used a lot these days.=20 In RH that's usually one loose hop between 2 entries in the RH. Maybe projected route is better because it is more specific to what we are = doing? Cheers, Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: lundi 6 juillet 2015 02:08 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt >=20 >=20 > > It would be good to make it clear which direction one counts the > "segment" > > to know which one is last. I don't like "segment" here, I think it's > > a routing path... Could you define segment if you think it's the most > > natural term to use. > > (There are also some articles like "the" missing in places, btw) >=20 > I also realized yesterday that 6554/RH3, uses the term segment. >=20 > -- > Michael Richardson , Sandelman Software > Works -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Jul 8 09:27:06 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF9E1A066B for ; Wed, 8 Jul 2015 09:26:59 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYc4OYf22PJC for ; Wed, 8 Jul 2015 09:26:55 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CB51A0451 for ; Wed, 8 Jul 2015 09:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1417; q=dns/txt; s=iport; t=1436372814; x=1437582414; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jiT0SzMGQpaIqU+gRyxNZpmdq0j6C5ZSAXdDGcfwDV0=; b=jVugISqJttsVGZ5RTutqIGI85UQDUrcYEMePoFelGFvGwkrMH0ZjBmjy qUlBKqSWX7xJM2mOGRUJmcV3WOFjyW0PXAmPsj3Je5ywBjBbotDiLJHBP o/l/TRzMHnD7bpHv58KfGw90SCg96KpR3v7QjydAxfmNw6LtKowCes445 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7BACxTp1V/4kNJK1cgxKBOr1Sh2YCgVo6EgEBAQEBAQGBCoQjAQEBAwE6TwIBCCIUEDIlAgQbiB4IzX8BAQEBAQEBAwEBAQEBAQEbi0uEVTiDF4EUBZQjAYt+mGEmggwcgVOCNoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,432,1432598400"; d="scan'208";a="166783283" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2015 16:26:54 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t68GQspV019043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Jul 2015 16:26:54 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.136]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 11:26:53 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] some comments on draft-thubert-dao-projection-00.txt Thread-Index: AQHQtl4uhnM3ZZux4UKM8k7V/iC9hJ3Lwz3sgALDsbWAA0AvcA== Date: Wed, 8 Jul 2015 16:26:53 +0000 Deferred-Delivery: Wed, 8 Jul 2015 16:26:24 +0000 Message-ID: References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> , <10398.1436016852@sandelman.ca> <26399.1436141254@sandelman.ca> <16023.1436193645@sandelman.ca> In-Reply-To: <16023.1436193645@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 16:26:59 -0000 Hello Michael >=20 > > Per RFC 6550, a path constructed by storing-mode DAO messages is > > directional, packets flow parent to child, and we do not want to > > introduce confusion by changing any of that. Thus the segment that= is > > constructed from the segment egress to the ingress. >=20 > I don't think I understand what this is an alternative to. > I.e. what would the way to do it wrong be? Why are you suddenly talking > about storing-mode DAO messages. I did that because the signaling of the projected route being installed is = hop by hop using DAO in a fashion that extend storing mode. The DAO flow from egress to ingress of that projected route while the data = flow the other way.=20 >=20 > > It results that the segment is directional but not that it is > > necessarily flowing down the DADOG, this depends on how much > > information is available to the root or whatever PCE is used as a > > helper. >=20 > This seems to imply that traffic could flow across the mesh... i.e. hop > From branch to branch. How would the DODAG root know that this was > possible > using pure RPL? I think that it couldn't without 6top or something. Yes. DetNet may provide means for that. The draft does not say where the root could get more information but it doe= s not preclude the projecting routes across the mesh. Cheers,=20 Pascal From nobody Wed Jul 8 10:00:13 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83211A1A5B for ; Wed, 8 Jul 2015 10:00:11 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPd9SOOw1Du5 for ; Wed, 8 Jul 2015 10:00:10 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF17D1A1A4F for ; Wed, 8 Jul 2015 10:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6878; q=dns/txt; s=iport; t=1436374809; x=1437584409; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uuFLtGPo4P05+rwheEIkORngG9kQKYfmpaOr8xJB7KA=; b=TA0vCihjAN/j1AMcf/H12zTqoQNkvKGmWbOEw9UfbKrFfHXKeNK4qYYp GCH7dgYB7GBfI2m5WHIpH+OKL9t+6egXy36B7Y/i7Rp6l5j7pwAV0HHf6 U1VfgChRl38K6y4bVJGFBuIDL/0SjNFfikeoCiaufMKz8h8FOrg6t1FeI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DrAwDuVZ1V/5ldJa1cgxKBNAa9SQmEMoM0AoFbOBQBAQEBAQEBgQqEIwEBAQMBJxNEBwQCAQgRBAEBCxQJBzIUCQgCBBMIiB4IzX0BAQEBAQEBAQEBAQEBAQEBAQEBGYtLhFUGMgIEgxGBFAWMI4gAAYt+gTqHJ4whg18mggkfgVNvgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,432,1432598400"; d="scan'208";a="9974851" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jul 2015 17:00:08 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t68H084P028842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Jul 2015 17:00:08 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.136]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 12:00:08 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] some comments on draft-thubert-dao-projection-00.txt Thread-Index: AQHQtl4uhnM3ZZux4UKM8k7V/iC9hJ3R0MyA Date: Wed, 8 Jul 2015 17:00:08 +0000 Deferred-Delivery: Wed, 8 Jul 2015 16:59:04 +0000 Message-ID: References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> <10398.1436016852@sandelman.ca> In-Reply-To: <10398.1436016852@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 17:00:12 -0000 Hello Michael > I think that what is described, to use the numbering in your example, is = that the root would send a message to 41, with a target=3D51, list of VIAs:= 11,22,31,41 and *then* 41 would send a DAO to 31, with a list of VIAs 11,22= ,31, etc. > It's the "then" above part that I *think* is a critical part of the proto= col, and is perhaps not clearly spelled out. I wasn't entirely sure if I r= ead it correctly. That is correct, as shown in fig 2, but I agree we need to clarify > In the case where nodes have different downstream and upstream addresses = (because, for instance they had different radios), then there might be some= confusion and maybe both hops should be listed. I recall I posted a threa= d asking about that a year or so ago, but I don't recall what the conclusio= n was. The root indicates the sequence of next hop address. These are the add= resses that are available on the interface of the child that connects to th= e parent. The node uses that address as source of its own DAO, which indica= tes it on which interface to send the DAO. > Alternatively, could the root have sent a single Via-DOA with destination *35* to 24, with the route 13,24? That would have resulted in a routing header like: ROOT -> 35 since 13 and 24 should be able to reach 35 in a loose source route, and 35 = would know how to reach 55 and 56? PT> That is correct, assuming that this is an alternate to=20 " The root may then send a DAO to node 35 indicating targets 55 and 56 a Via segment (13, 24, 35) to fully optimize that path. " PT > Your other points well taken, I'll talk to James and we'll fix the dra= ft. All the best Pascal Cheers, Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: samedi 4 juillet 2015 15:34 > To: roll@ietf.org > Subject: [Roll] some comments on draft-thubert-dao-projection-00.txt >=20 >=20 > >=20 > Pascal, thank you for this document. > I especially appreciated your figure 2, the way that you numbered the nod= es > with their gross rank as the the tens part. >=20 > You write on page 8: > The root sends the DAO directly to the last node in the segment, > which is expected to be able to route to the targets on its own. >=20 > It would be good to make it clear which direction one counts the "segment= " > to know which one is last. I don't like "segment" here, I think it's a r= outing > path... Could you define segment if you think it's the most natural term= to > use. > (There are also some articles like "the" missing in places, btw) >=20 > Then you write: > The node strips the last Via Information option which corresponds to > self, and uses it as source address for the DAO to the predecessor. >=20 > I think that what is described, to use the numbering in your example, is = that > the root would send a message to 41, with a target=3D51, list of > VIAs:11,22,31,41 and *then* 41 would send a DAO to 31, with a list of VIA= s > 11,22,31, etc. >=20 > It's the "then" above part that I *think* is a critical part of the proto= col, and > is perhaps not clearly spelled out. I wasn't entirely sure if I read it = correctly. >=20 > In the case where nodes have different downstream and upstream > addresses (because, for instance they had different radios), then there > might be some confusion and maybe both hops should be listed. I recall I > posted a thread asking about that a year or so ago, but I don't recall wh= at > the conclusion was. >=20 > But, then in the example on page 9, after sending these Via-DAOs to > 45 and 46, it says: > The root > may then send a DAO to node 35 indicating targets 55 and 56 a Via > segment (13, 24, 35) to fully optimize that path. >=20 > While the root had initially optimized the 45/46 out the routing header > with the first set of Via-DOAs (do you have a name for these messages? > Projected-DAOs? maybe), couldn't that set of DOAs have included 13,24 in > the list as well? >=20 > Alternatively, could the root have sent a single Via-DOA with destination > *35* to 24, with the route 13,24? That would have resulted in a routing > header like: > ROOT -> 35 > since 13 and 24 should be able to reach 35 in a loose source route, and 3= 5 > would know how to reach 55 and 56? >=20 > **** >=20 > in section 3.1, the description of the VIA extension, you write: >=20 > Option Length: Variable, depending on whether or not Parent Address > is present. >=20 > But the only variability I saw in the extension was whether the child add= ress > was 8 bytes or 16 bytes. It seems that if you are going to optimize this= , you > might as well also offer an option for the Child Address to be 2 bytes (t= he > last two bytes). >=20 > **** DAO >=20 > I don't fundamentally see a reason why DAO is used. I guess it has the r= ight > properties, but I think that a new message type could be defined equally > well (as well as a new ACK), even if it just replicates the exact DAO str= ucture. > It seems that the ACK is mandatory (K=3D1). >=20 > I would prefer that DAOs always flow towards the root, and DIOs away. > It would make analysis of what is going on easier. > These DAOs in some way flow towards a node with root-like storing-like > abilities, so I can see why it was elegant to reuse DAO for this. >=20 > **** incremental deployment >=20 > Use of a new MOP makes deployment of this a flag day. > I don't think that this is necessary, although some niggling doubt going = back > to the mixed storing/non-storing discussion of 2011 remains... >=20 > I think that the DAOs that come from nodes that are able to act as Route > Projection nodes could indicate that capability, and furthermore, indicat= e > the number of routing slots they currently have free. >=20 > It would be advantageous perhaps to explicitely number the routing slots. > My initial thought is that would permit the subsequent DAOs to perhaps > include a count of how many times the Projected route was used: once the > DODAG root pushes traffic away from the root with these projected routes, > it can no longer count how much traffic is occuring, so it should get rep= orts > "from the field" so that it can decide whether to keep those routes. >=20 > Explicitely numbering the routing slots could be problematic I agree, but= it > would allow the DODAG to manage them directly rather than the implicit > process that the VIA option's Path Sequence is doing. >=20 > The Path Sequence processing needs an example, btw. >=20 >=20 > -- > Michael Richardson , Sandelman Software > Works -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Jul 8 12:57:37 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3A91A875D; Wed, 8 Jul 2015 12:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr-t-wSxh-AF; Wed, 8 Jul 2015 12:57:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3755A1A871A; Wed, 8 Jul 2015 12:57:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708195730.18658.96701.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 12:57:30 -0700 Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: [Roll] Alia Atlas' Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 19:57:33 -0000 Alia Atlas has entered the following ballot position for draft-ietf-roll-mpl-parameter-configuration-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In general, this draft is well-written and easy to understand. I do have a few points of technical clarity that I think are important. First, a minor point on the "Reserved" bits. In Sec 2.1, it says "Z (7 bits): Reserved. Should be 0." and then in Sec 2.2: " Clients MUST discard the MPL Parameter Configuration Option if it is invalid (e.g., it sets reserved bits)." Frequently, Reserved bits are available for future enhancements - so setting to zero on write and ignoring the value on read is a useful default. If these bits are really always going to be zero and interpreted as an error, then could you rename them to MBZ (Must Be Zero) and indicate in the field definition that a value other than zero is an error. Also, from what I read in the rest of the draft, if an invalid option is received, that could cause the client to be removed from the MPL region. Could you clarify in the document what the expected behavior is if an invalid option is discarded? Is that like having no option? Is that pretending that the client didn't get one and staying with the previous option? It seems like it would be pretty easy to remove a client from the MPL region by flipping a bit. I would also like to see better clarification of how an option is considered invalid; while it may seem obvious, it's these details that impact interoperability. In the write-up, I don't see any indications that there have been interoperable implementations yet? Second, given that the meaning of the *_IMAX values is based on RFC6206 (as indicated in the update history) and that the *_IMAX and *_IMIN are confusing values, PLEASE have a reference to RFC6206. To continue, it seems that DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX have different units - as is explained in RFC6206 where *_IMAX is the number of doublings and *_IMIN is the value in milliseconds. However, in draft-ietf-roll-trickle-mcast-12, Section 5.4, the definition of DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX and C_IMIN and C_IMAX are given as: " DATA_MESSAGE_IMIN The minimum Trickle timer interval, as defined in [RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMIN has a default value of 10 times the expected link-layer latency. DATA MESSAGE_IMAX The maximum Trickle timer interval, as defined in [RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN. CONTROL_MESSAGE_IMIN The minimum Trickle timer interval, as defined in [RFC6206], for MPL Control Message transmissions. CONTROL_MESSAGE_IMIN has a default value of 10 times the worst- case link-layer latency. CONTROL_MESSAGE_IMAX The maximum Trickle timer interval, as defined in [RFC6206], for MPL Control Message transmissions. CONTROL_MESSAGE_IMAX has a default value of 5 minutes. " Clearly, if DATA_MESSAGE_IMIN is a 16 bit value and DATA_MESSAGE_IMAX is only an 8-bit value, they are expected to have different ranges. Additionally, it's quite unclear which actually needs to be divided by TUNIT. The draft describes this as happening for DM_IMIN and C_IMIN, but then goes on to say " Note that all time values (Trickle timers and expiration periods) are in TUNIT milliseconds precision. For example, if TUNIT is 20 and the data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then DM_IMIN shall be set to 50." Unfortunately, the draft doesn't describe which parameters are time values and apparently draft-ietf-roll-trickle-mcast-12 has some confusion as well. For instance, CONTROL_MESSAGE_IMAX is defined as a time value (5 minutes). I suspect that the solution here is to clarify/fix draft-ietf-roll-trickle-mcast-12, add references in Sec 2 to where the parameters are defined, indicate which are considered "time values", and clean up the language in Sec 2.1. Thanks! It looks like a useful document to address an operational problem once these clarity issues are addressed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Sec 2.1, it says: "OPTION_MPL_PARAMETERS: DHCPv6 option identifier (not yet assigned)" Instead of "not yet assigned", it would be better to use TBD1 and then reference TBD1 in the IANA section. That makes it easy and clear how to update the draft as it is prepared to be an RFC. From nobody Wed Jul 8 15:04:10 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C7C1A8893; Wed, 8 Jul 2015 15:04:05 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hal4bGhUKvVH; Wed, 8 Jul 2015 15:04:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C992E1A888B; Wed, 8 Jul 2015 15:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1196; q=dns/txt; s=iport; t=1436393044; x=1437602644; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WiSPhkA0Ao61kM2lClT+DYXpbv3xSsVaFICSsfaOYgk=; b=LonnvJ2Fu3Ti6YaohPPbmSqiZ4gnK+en2HEiit1omc2EJQjW1x0DZDJ7 g9ydD3Kz75NdExVapi67ntPmv7moi2bM00vg7jPmArvxa3XjLHaUTO6bR p6rmk042goLOON15mbSZQXTsHFGqEMhYsPfYnduTalJux3jdMYOMqgVXx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CHAwClnZ1V/5xdJa1bgxKBNAa7EQmHZwKBWjgUAQEBAQEBAYEKhCQBAQR5EAIBCDsLMiUCBAENBYguzg0BAQEBAQEBAQEBAQEBAQEBAQEBARiLS4RTMweEKwEEhweFVIRigmYBi32BO5NIg18mY4FagT5vgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,434,1432598400"; d="scan'208";a="10049969" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 08 Jul 2015 22:04:03 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t68M43eu020358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jul 2015 22:04:03 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.203]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 17:04:02 -0500 From: "Alvaro Retana (aretana)" To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) Thread-Index: AQHQuOFFTOIJGEX5f02R8u7z2RFl7J3SMvsA Date: Wed, 8 Jul 2015 22:04:02 +0000 Message-ID: References: <20150707181803.6403.35920.idtracker@ietfa.amsl.com> In-Reply-To: <20150707181803.6403.35920.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.208.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5D8C399A9EBAF0459838523F7B4810FE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "roll-chairs@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration@ietf.org" , "roll@ietf.org" , "maria.ines.robles@ericsson.com" , "draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org" Subject: Re: [Roll] Barry Leiba's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 22:04:05 -0000 On 7/7/15, 3:18 PM, "Barry Leiba" wrote: Barry: Hi! >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >This should be a very easy discussion to resolve: > >-- Section 2.3 -- > > A node SHOULD leave an MPL domain if it receives an updated MPL > Parameter Configuration Option without a configuration for the MPL > domain, unless it has overriding manual configuration on the MPL > domain. In other words, if a node is configured to work as a MPL > Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY > stay on the MPL domain even if it receives an MPL Parameter > Configuration Option without configuration for the MPL domain. > >I'm confused by this, because it appears to contradict itself. Yes..I can see how this is confusing, and I think the fix is easy: remove the second sentence. This second sentence doesn=B9t add new information an= d it makes the text confusing by adding the =B3MAY=B2. I=B9ll let Yusuke confirm that this is ok (and address your other comment). Thanks! Alvaro. From nobody Wed Jul 8 15:08:01 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259B81A88AB; Wed, 8 Jul 2015 15:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.256 X-Spam-Level: X-Spam-Status: No, score=0.256 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ85g1_bRs4n; Wed, 8 Jul 2015 15:07:56 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 653391A889D; Wed, 8 Jul 2015 15:07:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BADB52D013; Thu, 9 Jul 2015 01:07:55 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-9rZhZIMIQb; Thu, 9 Jul 2015 01:07:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id A30322D00D; Thu, 9 Jul 2015 01:07:54 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9A953FA5-AAE3-4805-B2AA-F52D3F0DF111"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Jari Arkko In-Reply-To: <559503CC.7030409@toshiba.co.jp> Date: Thu, 9 Jul 2015 00:07:53 +0200 Message-Id: References: <01ea01d0af9c$de6319e0$9b294da0$@akayla.com> <559503CC.7030409@toshiba.co.jp> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: gen-art@ietf.org, draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org Subject: Re: [Roll] Gen-ART LC review for draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 22:07:58 -0000 --Apple-Mail=_9A953FA5-AAE3-4805-B2AA-F52D3F0DF111 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yusuke, Peter, thanks for detailed review and changes. Jari On 02 Jul 2015, at 11:26, Yusuke DOI wrote: > Dear Peter, >=20 > Thank you for review. I submitted -06 (-05 contains some nits) as a = revised version. >=20 > On 2015-06-26 08:15, Peter Yee wrote: >> Some of the parameters are described with their bit lengths, others = are not. >> Lengths are listed haphazardly. Be consistent in either including = them or >> not. Timer lengths are listed as n-bit integers, but this may be = confusing >> given that the document says "Short floating point format is used to >> describe the wide range of timer values". So, are the timer values = floating >> point or integer? Is the combined implication supposed to be that = the >> numbers are formatted as floating point (for greater range), but only = take >> on integer values? Given that the values in this document are all = given in >> reference to division by the value of TUNIT, it's possible that = values might >> not be integers. If that happens and only integers are desired, is = rounding >> or truncation preferred? Also note that Appendix A indicates that = "short >> unsigned floating point" was dropped. It's not completely clear if = that >> means that "short [signed?] floating point" was adopted in its stead = or >> whether actual short integers were preferred. >=20 > Short floating point is dropped but some texts have not removed (my = mistake). Thank you for pointing out. All values should be in integer. >=20 > Thank you again for your efforts on review (and sorry for lot of = nits...) >=20 > Yusuke >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_9A953FA5-AAE3-4805-B2AA-F52D3F0DF111 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVnZ85AAoJEM80gCTQU46qTwgQAK17SvenCLuaR8+IwMq3ma+d SraMb3CaL1PRJGwJa1AL8pRP9IBCip51H1oDPA0WYeEyDHAafGs4gLZsRJxsMGKV 9hKzI/Cs8AZSwHOkmqZxFejFACJMSCud49mLAX0X5Eqtm7VRVDhkJ0miGhDFDLzd 4LdUVXF2SImm8/mg2XGT/pyURxmefcuBkD35KS887/F7c15l+pZ0tpZEyB/MJDM6 AJT3tysFr/VOZ0ChE3M8wKUrTZp0JGoFr1iZj6PDqN+ffvi5DuhgtSk08Qejqs9h UL/UFxkC4zt1RMYUmjdCoGCGnZ1tSdU2IewOPHXlqkb+7o5IUvqiAMC05upqU94b 0JT9hP1DzAMaZURJKBIuXW/Wj6qXYNKnQ0Ix3btQqZSBohS3z3CK+Wa7aYLyyJYa rzhFN7xYr+YUcwTsb3IudRgl+/+IMB7nmEj5bNsZpkNIJoHFiRC4qf7yE8WHfXm/ hvER0E21BRps5YaGliwHLBPEEN+iMJmYKJOf+kgoo/hjRqffEAm+FyprLFkEoAHd JqL3mmgqcHlHEejoe9Vg842laZPqlv03QEa72l1pUa2uXxfL4FXHzO7OEIRNOxb/ Kb2dBNaw+3q/wGKfxaVSPb3hTdRT/0t/HvKQIgaKPvIhQZ/jy6PdHczY0nyEdX4m jJm0XMM8dSFCP5FCsFZS =pcAX -----END PGP SIGNATURE----- --Apple-Mail=_9A953FA5-AAE3-4805-B2AA-F52D3F0DF111-- From nobody Wed Jul 8 15:08:21 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 372D91A889D; Wed, 8 Jul 2015 15:08:20 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E6E1A889D for ; Wed, 8 Jul 2015 15:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.266 X-Spam-Level: X-Spam-Status: No, score=0.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6j18ZwRSu0M for ; Wed, 8 Jul 2015 15:08:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5481A88D6 for ; Wed, 8 Jul 2015 15:08:03 -0700 (PDT) Received: from p130.piuha.net ([2a00:1d50:2::130]:60129) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCxVa-0004GA-BU for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Wed, 08 Jul 2015 15:08:03 -0700 Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BADB52D013; Thu, 9 Jul 2015 01:07:55 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-9rZhZIMIQb; Thu, 9 Jul 2015 01:07:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id A30322D00D; Thu, 9 Jul 2015 01:07:54 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9A953FA5-AAE3-4805-B2AA-F52D3F0DF111"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Jari Arkko In-Reply-To: <559503CC.7030409@toshiba.co.jp> Date: Thu, 9 Jul 2015 00:07:53 +0200 Message-Id: References: <01ea01d0af9c$de6319e0$9b294da0$@akayla.com> <559503CC.7030409@toshiba.co.jp> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) X-SA-Exim-Connect-IP: 2a00:1d50:2::130 X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org X-SA-Exim-Mail-From: jari.arkko@piuha.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org Resent-Message-Id: <20150708220803.DB5481A88D6@ietfa.amsl.com> Resent-Date: Wed, 8 Jul 2015 15:08:03 -0700 (PDT) Resent-From: jari.arkko@piuha.net Archived-At: Archived-At: Cc: gen-art@ietf.org, draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org Subject: Re: [Roll] Gen-ART LC review for draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 22:08:20 -0000 --Apple-Mail=_9A953FA5-AAE3-4805-B2AA-F52D3F0DF111 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yusuke, Peter, thanks for detailed review and changes. Jari On 02 Jul 2015, at 11:26, Yusuke DOI wrote: > Dear Peter, >=20 > Thank you for review. I submitted -06 (-05 contains some nits) as a = revised version. >=20 > On 2015-06-26 08:15, Peter Yee wrote: >> Some of the parameters are described with their bit lengths, others = are not. >> Lengths are listed haphazardly. Be consistent in either including = them or >> not. Timer lengths are listed as n-bit integers, but this may be = confusing >> given that the document says "Short floating point format is used to >> describe the wide range of timer values". So, are the timer values = floating >> point or integer? Is the combined implication supposed to be that = the >> numbers are formatted as floating point (for greater range), but only = take >> on integer values? Given that the values in this document are all = given in >> reference to division by the value of TUNIT, it's possible that = values might >> not be integers. If that happens and only integers are desired, is = rounding >> or truncation preferred? Also note that Appendix A indicates that = "short >> unsigned floating point" was dropped. It's not completely clear if = that >> means that "short [signed?] floating point" was adopted in its stead = or >> whether actual short integers were preferred. >=20 > Short floating point is dropped but some texts have not removed (my = mistake). Thank you for pointing out. All values should be in integer. >=20 > Thank you again for your efforts on review (and sorry for lot of = nits...) >=20 > Yusuke >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_9A953FA5-AAE3-4805-B2AA-F52D3F0DF111 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVnZ85AAoJEM80gCTQU46qTwgQAK17SvenCLuaR8+IwMq3ma+d SraMb3CaL1PRJGwJa1AL8pRP9IBCip51H1oDPA0WYeEyDHAafGs4gLZsRJxsMGKV 9hKzI/Cs8AZSwHOkmqZxFejFACJMSCud49mLAX0X5Eqtm7VRVDhkJ0miGhDFDLzd 4LdUVXF2SImm8/mg2XGT/pyURxmefcuBkD35KS887/F7c15l+pZ0tpZEyB/MJDM6 AJT3tysFr/VOZ0ChE3M8wKUrTZp0JGoFr1iZj6PDqN+ffvi5DuhgtSk08Qejqs9h UL/UFxkC4zt1RMYUmjdCoGCGnZ1tSdU2IewOPHXlqkb+7o5IUvqiAMC05upqU94b 0JT9hP1DzAMaZURJKBIuXW/Wj6qXYNKnQ0Ix3btQqZSBohS3z3CK+Wa7aYLyyJYa rzhFN7xYr+YUcwTsb3IudRgl+/+IMB7nmEj5bNsZpkNIJoHFiRC4qf7yE8WHfXm/ hvER0E21BRps5YaGliwHLBPEEN+iMJmYKJOf+kgoo/hjRqffEAm+FyprLFkEoAHd JqL3mmgqcHlHEejoe9Vg842laZPqlv03QEa72l1pUa2uXxfL4FXHzO7OEIRNOxb/ Kb2dBNaw+3q/wGKfxaVSPb3hTdRT/0t/HvKQIgaKPvIhQZ/jy6PdHczY0nyEdX4m jJm0XMM8dSFCP5FCsFZS =pcAX -----END PGP SIGNATURE----- --Apple-Mail=_9A953FA5-AAE3-4805-B2AA-F52D3F0DF111-- From nobody Wed Jul 8 16:17:33 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BDE1A1A9B for ; Wed, 8 Jul 2015 16:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVgzK_0lZ6iU for ; Wed, 8 Jul 2015 16:17:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629F81A1A96 for ; Wed, 8 Jul 2015 16:17:30 -0700 (PDT) Received: from localhost ([::1]:37911 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCyak-0002yM-T8; Wed, 08 Jul 2015 16:17:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com X-Trac-Project: roll Date: Wed, 08 Jul 2015 23:17:26 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/171 Message-ID: <067.b198a4ddbebd62b063895145fb090313@trac.tools.ietf.org> X-Trac-Ticket-ID: 171 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: roll@ietf.org Subject: [Roll] [roll] #171 (draft-doi-roll-mpl-parameter-configuration): Int-Dir review of draft-ietf-roll-mpl-parameter-configuration-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 23:17:32 -0000 #171: Int-Dir review of draft-ietf-roll-mpl-parameter-configuration-06 Int-Dir review for draft-ietf-roll-mpl-parameter-configuration-06 from Bernie Volz Source: http://www.ietf.org/mail-archive/web/int-dir/current/msg00129.html "Hi: I am an assigned INT directorate reviewer for draft-ietf-roll-mpl- parameter-configuration-06. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. Disclaimer: I’m primarily reading this draft primarily from the DHCP perspective. Thus, in some cases my questions might seem odd to those that understand the MPL concepts and issues. I will admit that I have only minimally studied the MPLs drafts. Executive Summary: I do not feel the document is ready. While there are no significant issues, there are several medium issues that do require resolution and may require some rework of the document. The document does follow RFC 7227 guidelines. Significant Issues: · None. The document generally follows the requirements set forth in RFC 7227 for new DHCPv6 options and seems reasonably straight forward to implement from the DHCPv6 client and server perspective. Medium: · General - This is one of the few options that is not a singleton (see RFC 7227, section 16). The use of multiple options seems appropriate here. However, it would be best to clarify that clients (section 2.2) and servers (section 2.4) must be able to support multiple instances of this option. · In section 2.6 (Operational Considerations), the text is a bit odd. Why should a parameter set not be updated more often than twice the Information Refresh Time? Explain updated were (on the server by an administrator or ?). Also, how does the failure to refresh the option play with text in section 2.3 that indicates a missing option means to keep the previously communicated settings? Perhaps defining what “failure to refresh” means (i.e., I think it refers to lack of a DHCPv6 server response to a Renew or Information Request). Note also that Information Refresh Time is only applicable to Information-Request messages (see RFC 4242) so work may be needed as to how this this sections relate to Renew/Rebind operations? It would improve this section if it was clear as to WHOM the Operational Considerations listed apply? And, if these are mostly with respect to Client behavior, why not include in section 2.2 or 2.3? · In section 2.3 (MPL Forwarder Behavior), perhaps this is clear to people using this draft (and perhaps it should be added in 2.1 – see nit comment below) as to exactly what this MPL Domain Address is and how it matches something (does the receipt of an option with an MPL Domain Address cause the creation of a new domain or is this something that must have been previously configured via some other means). Perhaps this is discussed in [I-D.ietf-roll-trickle-mcast]; if so perhaps an appropriate reference is useful? · I assume Appendix A is intended to be dropped when published as an RFC? So: o I would recommend swapping appendix A and B as I assume B is intended to stay as part of the RFC. o I would recommend explicit instructions to the RFC editor to remove the appendix. If you didn’t intend the appendix to be dropped, you should! The RFC is the final product and how it got to be an RFC is a matter of other IETF archives and not generally retained in the document. · In section 4 (Security Considerations), would a reference to [I-D.ietf-roll-trickle-mcast]’s security considerations also be appropriate? Nits: · Abstract: Would “a network can easily be configured with a single set of MPL parameters.” be better? (Easily at the end is somewhat odd?) · While 2119 allows use of MUST and SHALL interchangeable, perhaps sticking to MUST is better? But not a big deal. · In section 2.1, I think it would be best to include “MPL Domain Address” in the list of fields and describe it here? · In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph – why would a client discard the option if the reserved bits are set? I would think you’d want to use a new option if you’re changing things drastically? But it certainly is your choice as to whether you want to do that. Perhaps a better reason is if one of the not-permitted values is used (such as 0 and ‘all-bits-set’) where are clearly reserved? 0 in many of these case could be bad since that would yield 0 time values? This really is up to you, but do think about what you might want to do any maintain backwards compatibility. Adding a new flag bit to the reserved field is probably not going to break things if existing implementations ignore the bit(s)? But it is always difficult to say what the future will hold? · In section 2.3: o In 1st paragraph, “a node may fail is to join” … I think “is” needs to be dropped? o In the last paragraph, “In the case,” … should be “In this case,”. · In Section 3 (IANA Considerations), please include the URL for the DHCPv6 registry (http://www.iana.org/assignments/dhcpv6-parameters). It just helps to reduce any possible chance of error. · In Appendix B, first sentence of 2nd paragraph, shouldn’t it be “sets” not set? Or something is odd about this sentence." -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | yusuke.doi@toshiba.co.jp Type: defect | Status: new Priority: major | Milestone: Component: draft-doi-roll-mpl- | Version: parameter-configuration | Keywords: Severity: In WG Last Call | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Wed Jul 8 16:26:11 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A6D1A1ABB; Wed, 8 Jul 2015 16:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80mKzn1r3j2H; Wed, 8 Jul 2015 16:26:04 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053271A1AB9; Wed, 8 Jul 2015 16:25:57 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t68NPumW026490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2015 08:25:56 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NPtEL006762; Thu, 9 Jul 2015 08:25:55 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 887; Thu, 9 Jul 2015 08:25:55 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NPtUd006759; Thu, 9 Jul 2015 08:25:55 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id t68NPt5U024470; Thu, 9 Jul 2015 08:25:55 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id JAA24469; Thu, 9 Jul 2015 08:25:55 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t68NPtX6025535; Thu, 9 Jul 2015 08:25:55 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t68NPtXY005611; Thu, 9 Jul 2015 08:25:55 +0900 (JST) Received: from [133.199.17.8] (ivpn-2-8.mobile.toshiba.co.jp [133.199.17.8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id D4D4218F4B6; Thu, 9 Jul 2015 08:25:53 +0900 (JST) Message-ID: <559D3EE0.4000904@toshiba.co.jp> Date: Thu, 09 Jul 2015 00:16:48 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150708080446.7700.80046.idtracker@ietfa.amsl.com> In-Reply-To: <20150708080446.7700.80046.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 23:26:07 -0000 Hi Stephen, Thank you very much for the review. On 2015-07-08 17:04, Stephen Farrell wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - I don't get the update model - if all MPL forwarders have > to use the same parameters but they don't all do DHCPv6 at > the same time, then won't new parameter settings take a > while to propagate to most of the network? And won't that > cause a problem? Don't you need a "start using this set of > parameters in N seconds" field in the dhcp option to handle > that? This is not a DISCUSS as I think it relats to Barry's > so please try address this when addressing that. I believe your question is beyond Barry's DISCUSS. Let me clarify it here. In general, all MPL Forwarders should have identical parameters to make a better load balance. However, the parameter synchronization is 'better to have' and even if there are mismatched parameter set it does not break interoperability or operation. Some forwarders would do more retransmission than others if the parameter is not identical. I consider this is acceptable behavior for MPL. To ease the unbalanced retransmission, I added some text to limit parameter update ratio per information refresh time. For join and leave on forwarders, some node may not be able to receive messages during transitive period (not all forwarders have joined). However, adding some delay on the configuration will not ease the case. It's up to application to send a multicast message after all nodes have acquired the newest configuration, or to send a message during constructing MPL domain if the message is good even for delivered to a fraction of nodes. > - please do not pretend rfc 3315 is a solution for anything > unless you mean it and I don't think you do. 3315 is I think > the canonical example for mythical security:-( To be honest, my situation is to go without DHCPv6 security and expects network-level security. We do strict node admission using RFC5191 and assumes no untrusted node in a network. I'm wondering how would I describe security consideration beyond my situation in the document, without relying on 3315. I appreciate if you give me some suggestion on this topic. Thanks, Yusuke From nobody Wed Jul 8 16:26:23 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C081A1B1F; Wed, 8 Jul 2015 16:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XidFxZgux7wG; Wed, 8 Jul 2015 16:26:07 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840081A1AB9; Wed, 8 Jul 2015 16:26:07 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t68NQ6sb026556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2015 08:26:06 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NQ5C8006897; Thu, 9 Jul 2015 08:26:05 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 96; Thu, 9 Jul 2015 08:26:05 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NQ5AQ006894; Thu, 9 Jul 2015 08:26:05 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id t68NQ5FA024560; Thu, 9 Jul 2015 08:26:05 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id JAA24554; Thu, 9 Jul 2015 08:26:05 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t68NQ4pS025597; Thu, 9 Jul 2015 08:26:05 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t68NQ4AL004419; Thu, 9 Jul 2015 08:26:04 +0900 (JST) Received: from [133.199.17.8] (ivpn-2-8.mobile.toshiba.co.jp [133.199.17.8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id E9BD918F4B6; Thu, 9 Jul 2015 08:26:02 +0900 (JST) Message-ID: <559D3F69.8040803@toshiba.co.jp> Date: Thu, 09 Jul 2015 00:19:05 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Campbell , The IESG References: <20150708023549.15347.9780.idtracker@ietfa.amsl.com> In-Reply-To: <20150708023549.15347.9780.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: Re: [Roll] Ben Campbell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 23:26:09 -0000 Ben, Thank you for the review! On 2015-07-08 11:35, Ben Campbell wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > -- section 2.6, 1st sentence :" A parameter set for an MPL domain SHOULD > NOT be updated more often > than twice of Information Refresh Time" > > The preposition "of" is incorrect. Normally I would say leave that for > the RFC editor, but it's not clear to me if this means "twice the > information refresh time" or "twice during an information refresh time > (interval)". (I assume the former, but it could be more clear.) Yes, the former is what I intended to ease unbalanced MPL domain due to use of different parameter set for nodes. Yusuke From nobody Wed Jul 8 16:26:33 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FECD1A1AD0; Wed, 8 Jul 2015 16:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.141 X-Spam-Level: ** X-Spam-Status: No, score=2.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsQsfOpzdsK5; Wed, 8 Jul 2015 16:26:16 -0700 (PDT) Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411F71A1AB9; Wed, 8 Jul 2015 16:26:16 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t68NQE8G020380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2015 08:26:14 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NQDKa032233; Thu, 9 Jul 2015 08:26:13 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 65; Thu, 9 Jul 2015 08:26:13 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NQDEJ032224; Thu, 9 Jul 2015 08:26:13 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t68NQDDg006896; Thu, 9 Jul 2015 08:26:13 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA06893; Thu, 9 Jul 2015 08:26:13 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t68NQDiH015972; Thu, 9 Jul 2015 08:26:13 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t68NQCfC004510; Thu, 9 Jul 2015 08:26:12 +0900 (JST) Received: from [133.199.17.8] (ivpn-2-8.mobile.toshiba.co.jp [133.199.17.8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 0993418F4B6; Thu, 9 Jul 2015 08:26:11 +0900 (JST) Message-ID: <559D4211.7050008@toshiba.co.jp> Date: Thu, 09 Jul 2015 00:30:25 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , ops-dir@ietf.org, draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org, Benoit Claise References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp id t68NQDEJ032224 Archived-At: Subject: Re: [Roll] [OPS-DIR] OPS-DIR Review of draft-ietf-roll-mpl-parameter-configuration-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 23:26:17 -0000 Hi Menachem, Thank you for the review! On 2015-07-07 15:36, =D7=9E=D7=A0=D7=97=D7=9D =D7=93=D7=95=D7=93=D7=92' w= rote: > Section 2.1 could be improved if for each parameter defined a reference > would be given to indicate where the parameter is defined. I found most > of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not > sure what the Proactive_Forwarding flag is used for. I would add reference. It's defined in section 5.4 of the MPL draft. > Section 4 discusses Security Considerations but I think that some > phrases in the paragraph are too general. > Example: "other methods for security should be applied" does not > indicate what these methods are or where to look for them. Is this clear?: "other method to protect integrity between DHCPv6=20 servers and clients" My intention is the next sentence on ZigBee IP is an example. > Another Example: "To protect attacks from outside of > the network, unneccessary DHCPv6 packets should be filtered on the > border router between the ROLL network and the Internet" - what is > meant by "unnecessary DHCPv6 packets"? I mean remote DHCPv6 server case. Is this clear?: "DHCPv6 packets SHOULD be filtered on the border router=20 between the ROLL network and the Internet, except for the packets=20 between the ROLL network and a remote DHCPv6 server or DHCPv6 relays=20 configured to manage the network" > NITS > =3D=3D=3D=3D Thanks, I would update and clarify the sentences on your review on the=20 next revision. Regards, Yusuke From nobody Wed Jul 8 16:27:08 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8D6B41A1B1F; Wed, 8 Jul 2015 16:27:07 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3C61A1AB9 for ; Wed, 8 Jul 2015 16:27:07 -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, SPF_FAIL=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXKQKRt0OFd3 for ; Wed, 8 Jul 2015 16:27:05 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31::14]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399511A1AD0 for ; Wed, 8 Jul 2015 16:27:05 -0700 (PDT) Received: from imx2.toshiba.co.jp ([106.186.93.51]:46461) by merlot.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZCyk0-00064y-VO for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Thu, 09 Jul 2015 01:27:03 +0200 Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t68NQE2M020386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Jul 2015 08:26:14 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NQEoS032236 for ; Thu, 9 Jul 2015 08:26:14 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 726 for ; Thu, 9 Jul 2015 08:26:14 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NQDPO032230 for ; Thu, 9 Jul 2015 08:26:13 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t68NQDkh006902 for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Thu, 9 Jul 2015 08:26:13 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA06901; Thu, 9 Jul 2015 08:26:13 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t68NQDB3015975 for ; Thu, 9 Jul 2015 08:26:13 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t68NQCcW005918; Thu, 9 Jul 2015 08:26:13 +0900 (JST) Received: from [133.199.17.8] (ivpn-2-8.mobile.toshiba.co.jp [133.199.17.8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 0993418F4B6; Thu, 9 Jul 2015 08:26:11 +0900 (JST) Message-ID: <559D4211.7050008@toshiba.co.jp> Date: Thu, 09 Jul 2015 00:30:25 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , ops-dir@ietf.org, draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org, Benoit Claise References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp id t68NQDPO032230 X-SA-Exim-Connect-IP: 106.186.93.51 X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org X-SA-Exim-Mail-From: yusuke.doi@toshiba.co.jp X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org Resent-Message-Id: <20150708232705.399511A1AD0@ietfa.amsl.com> Resent-Date: Wed, 8 Jul 2015 16:27:05 -0700 (PDT) Resent-From: yusuke.doi@toshiba.co.jp Archived-At: Archived-At: Subject: Re: [Roll] [OPS-DIR] OPS-DIR Review of draft-ietf-roll-mpl-parameter-configuration-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 23:27:07 -0000 Hi Menachem, Thank you for the review! On 2015-07-07 15:36, =D7=9E=D7=A0=D7=97=D7=9D =D7=93=D7=95=D7=93=D7=92' w= rote: > Section 2.1 could be improved if for each parameter defined a reference > would be given to indicate where the parameter is defined. I found most > of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not > sure what the Proactive_Forwarding flag is used for. I would add reference. It's defined in section 5.4 of the MPL draft. > Section 4 discusses Security Considerations but I think that some > phrases in the paragraph are too general. > Example: "other methods for security should be applied" does not > indicate what these methods are or where to look for them. Is this clear?: "other method to protect integrity between DHCPv6=20 servers and clients" My intention is the next sentence on ZigBee IP is an example. > Another Example: "To protect attacks from outside of > the network, unneccessary DHCPv6 packets should be filtered on the > border router between the ROLL network and the Internet" - what is > meant by "unnecessary DHCPv6 packets"? I mean remote DHCPv6 server case. Is this clear?: "DHCPv6 packets SHOULD be filtered on the border router=20 between the ROLL network and the Internet, except for the packets=20 between the ROLL network and a remote DHCPv6 server or DHCPv6 relays=20 configured to manage the network" > NITS > =3D=3D=3D=3D Thanks, I would update and clarify the sentences on your review on the=20 next revision. Regards, Yusuke From nobody Wed Jul 8 16:39:09 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157D21A1EF9; Wed, 8 Jul 2015 16:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnxaANmonLdJ; Wed, 8 Jul 2015 16:39:04 -0700 (PDT) Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058D01A1EF6; Wed, 8 Jul 2015 16:39:03 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t68Nd2XK025378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2015 08:39:02 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68Nd2xV026435; Thu, 9 Jul 2015 08:39:02 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 397; Thu, 9 Jul 2015 08:39:02 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68Nd2Ve026432; Thu, 9 Jul 2015 08:39:02 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t68Nd2V4017056; Thu, 9 Jul 2015 08:39:02 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA17055; Thu, 9 Jul 2015 08:39:02 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t68Nd2Am022039; Thu, 9 Jul 2015 08:39:02 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t68Nd2gJ015320; Thu, 9 Jul 2015 08:39:02 +0900 (JST) Received: from [133.199.17.8] (ivpn-2-8.mobile.toshiba.co.jp [133.199.17.8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 6CD4618F4B6; Thu, 9 Jul 2015 08:38:58 +0900 (JST) Message-ID: <559DB480.7080507@toshiba.co.jp> Date: Thu, 09 Jul 2015 08:38:40 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , Barry Leiba , The IESG References: <20150707181803.6403.35920.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp id t68Nd2Ve026432 Archived-At: Cc: "roll-chairs@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org" , "maria.ines.robles@ericsson.com" , "draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org" Subject: Re: [Roll] Barry Leiba's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 23:39:05 -0000 Hi Alvaro, On 2015-07-09 7:04, Alvaro Retana (aretana) wrote: > Yes..I can see how this is confusing, and I think the fix is easy: remo= ve > the second sentence. This second sentence doesn=B9t add new informatio= n and > it makes the text confusing by adding the =B3MAY=B2. > > I=B9ll let Yusuke confirm that this is ok (and address your other comme= nt). I agree with the fix. Thank you for suggestion. Yusuke From nobody Wed Jul 8 19:18:29 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2B51A89A2; Wed, 8 Jul 2015 19:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjfyy-esKF9p; Wed, 8 Jul 2015 19:18:24 -0700 (PDT) Received: from mail-vn0-x232.google.com (mail-vn0-x232.google.com [IPv6:2607:f8b0:400c:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5271A899E; Wed, 8 Jul 2015 19:18:24 -0700 (PDT) Received: by vnbf62 with SMTP id f62so33143122vnb.9; Wed, 08 Jul 2015 19:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=okxOhQ+wE1CLX8KmB+TZyELE2q7OGZOKLLPkIAhvBrA=; b=FZFpvfN0Ko9EKwPHffZ3aXkTX5t0LkJwBDlx0VtMFsN4bMuROgt9XY3pa51HnKwaBl YKR94Cq+/PJp1EV8k753DVf6QeOUTMu3mjcvda0TQfUHbVp3JokW6rVbTDrWIgJQwMrC 3SLnT+krfDr1csGtPRiG8n7GkZEanRxaAfPSqTXyU2ZDtN3Ll65+fP9L3eWqWims54Mj oumWCjYQjmZfyQBSD/ekaRvoDt5E2iCtNZOmPSTivGl46s401bRSDxrB4UhG9Fv21LxS 3YU5SIUnU5sivY+L1Hqgk5/tvu1cx23vNpgwvFpIBxHq9+Q5Or483htlwy1m9MlCCIHl kb7Q== MIME-Version: 1.0 X-Received: by 10.52.71.203 with SMTP id x11mr12965432vdu.48.1436408304012; Wed, 08 Jul 2015 19:18:24 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Wed, 8 Jul 2015 19:18:23 -0700 (PDT) In-Reply-To: <559DB480.7080507@toshiba.co.jp> References: <20150707181803.6403.35920.idtracker@ietfa.amsl.com> <559DB480.7080507@toshiba.co.jp> Date: Wed, 8 Jul 2015 22:18:23 -0400 X-Google-Sender-Auth: JV0ctdyz5MI0qHIYXV0OItI8XBU Message-ID: From: Barry Leiba To: Yusuke DOI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "roll-chairs@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration@ietf.org" , Routing Over Low power and Lossy networks , "draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org" , The IESG , "draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org" , "maria.ines.robles@ericsson.com" Subject: Re: [Roll] Barry Leiba's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 02:18:26 -0000 >>-- Section 2.3 -- >> >> A node SHOULD leave an MPL domain if it receives an updated MPL >> Parameter Configuration Option without a configuration for the MPL >> domain, unless it has overriding manual configuration on the MPL >> domain. In other words, if a node is configured to work as a MPL >> Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY >> stay on the MPL domain even if it receives an MPL Parameter >> Configuration Option without configuration for the MPL domain. ... >> Yes..I can see how this is confusing, and I think the fix is easy: remov= e >> the second sentence. This second sentence doesn=C2=B9t add new informat= ion and >> it makes the text confusing by adding the =C2=B3MAY=C2=B2. >> >> I=C2=B9ll let Yusuke confirm that this is ok (and address your other com= ment). > > I agree with the fix. Thank you for suggestion. That does correct the apparent contradiction, but it doesn't answer one question I had, which seems to leave things uncertain: Where the text says, "A node SHOULD leave an MPL domain if it receives an updated MPL Parameter Configuration Option without a configuration for the MPL domain, unless it has overriding manual configuration on the MPL domain," it's important to note that this still means that if you *don't* have an overriding manual configuration on the domain, you still SHOULD (not MUST) leave the domain. That still means that you could choose not to leave the domain. Is that OK? In other words: 1. You receive an updated MPL PCO without a config for the MPL domain. 1a. You *do* have an overriding manual configuration on the domain. What are your choices? I think you mean to say that your choices are to stay on the domain or to leave it, at your option. 1b. You *don't* have an overriding manual configuration on the domain. What are your choices? I don't know whether you mean to say that you MUST leave the domain in this case, or whether there might be other reasons you might choose to stay, and the SHOULD is appropriate. I'd still like an answer to those questions, so we can work out what text will make that explicitly clear, and avoid confusion. Do you see why I'm uncertain? Barry From nobody Thu Jul 9 01:06:41 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261C31ACCEA; Thu, 9 Jul 2015 01:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5rK7iUSbvMf; Thu, 9 Jul 2015 01:06:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB111ACCF9; Thu, 9 Jul 2015 01:06:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150709080636.26555.87095.idtracker@ietfa.amsl.com> Date: Thu, 09 Jul 2015 01:06:36 -0700 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 08:06:40 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ From nobody Thu Jul 9 01:15:21 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56881A21A2; Thu, 9 Jul 2015 01:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvhtcewvTuxH; Thu, 9 Jul 2015 01:15:14 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::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 D6A5C1A1A97; Thu, 9 Jul 2015 01:15:13 -0700 (PDT) Received: by wgov12 with SMTP id v12so31736120wgo.1; Thu, 09 Jul 2015 01:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gba2RihrbzZQ9L1p4XeiH5Z78+ZfOMOoKb4/6LlGJdc=; b=mwxVY4BICkOKKR7pPamLLpnehagpRYYvAXmB42IXjjoSF/T93tOWjS/Yx5dPkUe7Kd zQj6I0u6fVI20wJzLC3emOGUcbF/4tjXa0ukfnYSkUMTH8DRGMQdy7hv5aNTzW2OyKte 7FTKPelOWVoM58vcfcJtyFcmfUfQTNvDVGJuIGl0BBe2GpV+uzcyJoeb2IiSm4+T6FGj VPTB3vY1skVHUOUPHtAL5SKpM8XQSJ1hGLC7VopB0YUfMKDmjpfU3excQOCWtdTeljgs 4kfZp0eLBe3s3GuZmaKwUEQt92UMNIaHP66KKtc0yB4Ib1hi3wLBBshDU9zaQnmEKB/q NvXg== MIME-Version: 1.0 X-Received: by 10.194.118.197 with SMTP id ko5mr19217606wjb.58.1436429712550; Thu, 09 Jul 2015 01:15:12 -0700 (PDT) Received: by 10.28.30.14 with HTTP; Thu, 9 Jul 2015 01:15:12 -0700 (PDT) In-Reply-To: <559D4211.7050008@toshiba.co.jp> References: <559D4211.7050008@toshiba.co.jp> Date: Thu, 9 Jul 2015 11:15:12 +0300 Message-ID: From: =?UTF-8?B?157XoNeX150g15PXldeT15In?= To: Yusuke DOI Content-Type: multipart/alternative; boundary=089e0122aec8c2f0e5051a6cdaad Archived-At: Cc: Benoit Claise , Routing Over Low power and Lossy networks , draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org, ops-dir@ietf.org Subject: Re: [Roll] [OPS-DIR] OPS-DIR Review of draft-ietf-roll-mpl-parameter-configuration-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 08:15:15 -0000 --089e0122aec8c2f0e5051a6cdaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Yusuke, Yes, thank you kindly, your changes are fine, the meaning is clear. Best Regards, Menachem 2015-07-08 18:30 GMT+03:00 Yusuke DOI : > Hi Menachem, > > Thank you for the review! > > On 2015-07-07 15:36, =D7=9E=D7=A0=D7=97=D7=9D =D7=93=D7=95=D7=93=D7=92' w= rote: > >> Section 2.1 could be improved if for each parameter defined a reference >> would be given to indicate where the parameter is defined. I found most >> of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not >> sure what the Proactive_Forwarding flag is used for. >> > > I would add reference. It's defined in section 5.4 of the MPL draft. > > Section 4 discusses Security Considerations but I think that some >> phrases in the paragraph are too general. >> Example: "other methods for security should be applied" does not >> indicate what these methods are or where to look for them. >> > > Is this clear?: "other method to protect integrity between DHCPv6 servers > and clients" > My intention is the next sentence on ZigBee IP is an example. > > Another Example: "To protect attacks from outside of >> the network, unneccessary DHCPv6 packets should be filtered on the >> border router between the ROLL network and the Internet" - what is >> meant by "unnecessary DHCPv6 packets"? >> > > I mean remote DHCPv6 server case. > > Is this clear?: "DHCPv6 packets SHOULD be filtered on the border router > between the ROLL network and the Internet, except for the packets between > the ROLL network and a remote DHCPv6 server or DHCPv6 relays configured t= o > manage the network" > > > NITS >> =3D=3D=3D=3D >> > > Thanks, I would update and clarify the sentences on your review on the > next revision. > > Regards, > > Yusuke > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > --089e0122aec8c2f0e5051a6cdaad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Yusuke,

<= /div>
Yes, thank you kindly, your changes are fine, the mea= ning is clear.

Best Regard= s,
Menachem
2015-07-08 18:30 GMT+03:00 Yus= uke DOI <yusuke.doi@toshiba.co.jp>:
Hi Menachem,

Thank you for the review!

On 2015-07-07 15:36, =D7=9E=D7=A0=D7=97=D7=9D =D7=93=D7=95=D7=93=D7=92'= wrote:
Section 2.1 could be improved if for each parameter defined a reference
would be given to indicate where the parameter is defined. I found most
of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not sure what the Proactive_Forwarding flag is used for.

 I would add reference. It's defined in section 5.4 of the MPL draft.

Section 4 discusses Security Considerations but I think that some
phrases in the paragraph are too general.
Example:=C2=A0 "other methods for security should be applied" doe= s not
indicate what these methods are or where to look for them.

Is this clear?: "other method to protect integrity between DHCPv6 serv= ers and clients"
My intention is the next sentence on ZigBee IP is an example.

Another Example: "To protect attacks from outside of
the network, unneccessary DHCPv6 packets should be filtered on the
border router between the ROLL network and the Internet"=C2=A0 - what = is
meant by "unnecessary DHCPv6 packets"?

 I mean remote DHCPv6 server case.

Is this clear?: "DHCPv6 packets SHOULD be filtered on the border route= r between the ROLL network and the Internet, except for the packets between= the ROLL network and a remote DHCPv6 server or DHCPv6 relays configured to= manage the network"


NITS
=3D=3D=3D=3D

Thanks, I would update and clarify the sentences on your review on the next= revision.

Regards,

Yusuke

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org<= br> https://www.ietf.org/mailman/listinfo/ops-dir

--089e0122aec8c2f0e5051a6cdaad-- From nobody Thu Jul 9 01:15:35 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7B7571ACCF9; Thu, 9 Jul 2015 01:15:27 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4E31ACCF8 for ; Thu, 9 Jul 2015 01:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v8fp-bfloUP for ; Thu, 9 Jul 2015 01:15:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AB11AC43C for ; Thu, 9 Jul 2015 01:15:23 -0700 (PDT) Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:33221) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZD6zK-000207-Rr for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Thu, 09 Jul 2015 01:15:23 -0700 Received: by wgck11 with SMTP id k11so216555922wgc.0 for ; Thu, 09 Jul 2015 01:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gba2RihrbzZQ9L1p4XeiH5Z78+ZfOMOoKb4/6LlGJdc=; b=mwxVY4BICkOKKR7pPamLLpnehagpRYYvAXmB42IXjjoSF/T93tOWjS/Yx5dPkUe7Kd zQj6I0u6fVI20wJzLC3emOGUcbF/4tjXa0ukfnYSkUMTH8DRGMQdy7hv5aNTzW2OyKte 7FTKPelOWVoM58vcfcJtyFcmfUfQTNvDVGJuIGl0BBe2GpV+uzcyJoeb2IiSm4+T6FGj VPTB3vY1skVHUOUPHtAL5SKpM8XQSJ1hGLC7VopB0YUfMKDmjpfU3excQOCWtdTeljgs 4kfZp0eLBe3s3GuZmaKwUEQt92UMNIaHP66KKtc0yB4Ib1hi3wLBBshDU9zaQnmEKB/q NvXg== MIME-Version: 1.0 X-Received: by 10.194.118.197 with SMTP id ko5mr19217606wjb.58.1436429712550; Thu, 09 Jul 2015 01:15:12 -0700 (PDT) Received: by 10.28.30.14 with HTTP; Thu, 9 Jul 2015 01:15:12 -0700 (PDT) In-Reply-To: <559D4211.7050008@toshiba.co.jp> References: <559D4211.7050008@toshiba.co.jp> Date: Thu, 9 Jul 2015 11:15:12 +0300 Message-ID: From: =?UTF-8?B?157XoNeX150g15PXldeT15In?= To: Yusuke DOI Content-Type: multipart/alternative; boundary=089e0122aec8c2f0e5051a6cdaad X-SA-Exim-Connect-IP: 2a00:1450:400c:c00::22f X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org X-SA-Exim-Mail-From: menachemdodge1@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org Resent-Message-Id: <20150709081523.F1AB11AC43C@ietfa.amsl.com> Resent-Date: Thu, 9 Jul 2015 01:15:23 -0700 (PDT) Resent-From: menachemdodge1@gmail.com Archived-At: Archived-At: Cc: Benoit Claise , Routing Over Low power and Lossy networks , draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org, ops-dir@ietf.org Subject: Re: [Roll] [OPS-DIR] OPS-DIR Review of draft-ietf-roll-mpl-parameter-configuration-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 08:15:27 -0000 --089e0122aec8c2f0e5051a6cdaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Yusuke, Yes, thank you kindly, your changes are fine, the meaning is clear. Best Regards, Menachem 2015-07-08 18:30 GMT+03:00 Yusuke DOI : > Hi Menachem, > > Thank you for the review! > > On 2015-07-07 15:36, =D7=9E=D7=A0=D7=97=D7=9D =D7=93=D7=95=D7=93=D7=92' w= rote: > >> Section 2.1 could be improved if for each parameter defined a reference >> would be given to indicate where the parameter is defined. I found most >> of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not >> sure what the Proactive_Forwarding flag is used for. >> > > I would add reference. It's defined in section 5.4 of the MPL draft. > > Section 4 discusses Security Considerations but I think that some >> phrases in the paragraph are too general. >> Example: "other methods for security should be applied" does not >> indicate what these methods are or where to look for them. >> > > Is this clear?: "other method to protect integrity between DHCPv6 servers > and clients" > My intention is the next sentence on ZigBee IP is an example. > > Another Example: "To protect attacks from outside of >> the network, unneccessary DHCPv6 packets should be filtered on the >> border router between the ROLL network and the Internet" - what is >> meant by "unnecessary DHCPv6 packets"? >> > > I mean remote DHCPv6 server case. > > Is this clear?: "DHCPv6 packets SHOULD be filtered on the border router > between the ROLL network and the Internet, except for the packets between > the ROLL network and a remote DHCPv6 server or DHCPv6 relays configured t= o > manage the network" > > > NITS >> =3D=3D=3D=3D >> > > Thanks, I would update and clarify the sentences on your review on the > next revision. > > Regards, > > Yusuke > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > --089e0122aec8c2f0e5051a6cdaad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Yusuke,

<= /div>
Yes, thank you kindly, your changes are fine, the mea= ning is clear.

Best Regard= s,
Menachem
2015-07-08 18:30 GMT+03:00 Yus= uke DOI <yusuke.doi@toshiba.co.jp>:
Hi Menachem,

Thank you for the review!

On 2015-07-07 15:36, =D7=9E=D7=A0=D7=97=D7=9D =D7=93=D7=95=D7=93=D7=92'= wrote:
Section 2.1 could be improved if for each parameter defined a reference
would be given to indicate where the parameter is defined. I found most
of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not sure what the Proactive_Forwarding flag is used for.

 I would add reference. It's defined in section 5.4 of the MPL draft.

Section 4 discusses Security Considerations but I think that some
phrases in the paragraph are too general.
Example:=C2=A0 "other methods for security should be applied" doe= s not
indicate what these methods are or where to look for them.

Is this clear?: "other method to protect integrity between DHCPv6 serv= ers and clients"
My intention is the next sentence on ZigBee IP is an example.

Another Example: "To protect attacks from outside of
the network, unneccessary DHCPv6 packets should be filtered on the
border router between the ROLL network and the Internet"=C2=A0 - what = is
meant by "unnecessary DHCPv6 packets"?

 I mean remote DHCPv6 server case.

Is this clear?: "DHCPv6 packets SHOULD be filtered on the border route= r between the ROLL network and the Internet, except for the packets between= the ROLL network and a remote DHCPv6 server or DHCPv6 relays configured to= manage the network"


NITS
=3D=3D=3D=3D

Thanks, I would update and clarify the sentences on your review on the next= revision.

Regards,

Yusuke

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org<= br> https://www.ietf.org/mailman/listinfo/ops-dir

--089e0122aec8c2f0e5051a6cdaad-- From nobody Thu Jul 9 02:23:39 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8D11A8A3A; Thu, 9 Jul 2015 02:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTse0s7fA2dq; Thu, 9 Jul 2015 02:23:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938781A89F0; Thu, 9 Jul 2015 02:23:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 527A5BE54; Thu, 9 Jul 2015 10:23:35 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436433815; bh=8fF3FhsRmoKqpbnmQFNl7E6FnqXvOmXl1QB4UqCK4ko=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=Z9ON8wQ1QJq7xAtIuYaqjR5pLHnsGI1pv+DGUHD/7ZGPEl72Od42/TCuTzUaNIxTP VLMlMCVFjt+ESTkxfwZHuhxVfYiZlMqGCkUF1sbrZCsDMNUHtO0gR7hsX4o1klgNr4 52DnP4uHIlnC11T8zM6iaF6IYp3toQ3CY88gHuxU= Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3rcnoFqBz4Z; Thu, 9 Jul 2015 10:23:35 +0100 (IST) Received: from [134.226.63.24] (cswireless63-24.scss.tcd.ie [134.226.63.24]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 17E14BE50; Thu, 9 Jul 2015 10:23:35 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436433815; bh=8fF3FhsRmoKqpbnmQFNl7E6FnqXvOmXl1QB4UqCK4ko=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=Z9ON8wQ1QJq7xAtIuYaqjR5pLHnsGI1pv+DGUHD/7ZGPEl72Od42/TCuTzUaNIxTP VLMlMCVFjt+ESTkxfwZHuhxVfYiZlMqGCkUF1sbrZCsDMNUHtO0gR7hsX4o1klgNr4 52DnP4uHIlnC11T8zM6iaF6IYp3toQ3CY88gHuxU= Message-ID: <559E3D96.5050906@cs.tcd.ie> Date: Thu, 09 Jul 2015 10:23:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yusuke DOI , The IESG References: <20150708080446.7700.80046.idtracker@ietfa.amsl.com> <559D3EE0.4000904@toshiba.co.jp> In-Reply-To: <559D3EE0.4000904@toshiba.co.jp> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 09:23:38 -0000 Hiya, On 08/07/15 16:16, Yusuke DOI wrote: > Hi Stephen, > > Thank you very much for the review. > > On 2015-07-08 17:04, Stephen Farrell wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - I don't get the update model - if all MPL forwarders have >> to use the same parameters but they don't all do DHCPv6 at >> the same time, then won't new parameter settings take a >> while to propagate to most of the network? And won't that >> cause a problem? Don't you need a "start using this set of >> parameters in N seconds" field in the dhcp option to handle >> that? This is not a DISCUSS as I think it relats to Barry's >> so please try address this when addressing that. > > I believe your question is beyond Barry's DISCUSS. Let me clarify it here. > > In general, all MPL Forwarders should have identical parameters to make > a better load balance. However, the parameter synchronization is 'better > to have' and even if there are mismatched parameter set it does not > break interoperability or operation. Some forwarders would do more > retransmission than others if the parameter is not identical. I consider > this is acceptable behavior for MPL. To ease the unbalanced > retransmission, I added some text to limit parameter update ratio per > information refresh time. > > For join and leave on forwarders, some node may not be able to receive > messages during transitive period (not all forwarders have joined). > However, adding some delay on the configuration will not ease the case. > It's up to application to send a multicast message after all nodes have > acquired the newest configuration, or to send a message during > constructing MPL domain if the message is good even for delivered to a > fraction of nodes. Hmm. I think what you're saying is that having the same parameters is very nice but not absolutely needed. If that's the case then you probably want to modify the text you use to motivate this draft where you say that it's really needed. > >> - please do not pretend rfc 3315 is a solution for anything >> unless you mean it and I don't think you do. 3315 is I think >> the canonical example for mythical security:-( > > To be honest, my situation is to go without DHCPv6 security and expects > network-level security. We do strict node admission using RFC5191 and > assumes no untrusted node in a network. > > I'm wondering how would I describe security consideration beyond my > situation in the document, without relying on 3315. I appreciate if you > give me some suggestion on this topic. I'd say take out the reference to 3315 entirely and just point at some other RFC's security considerations text that says that we don't have any real security for DHCP that works and as a result this and that bad things can happen. If there are specific new bad things that can happen related to this particular option being sent without any crypto-security (which is what'll happen) then please note those. (Some folks are trying to work on DHCP security but it'll take time and in the meantime DHCP is just insecure.) Cheers, S. > > Thanks, > > Yusuke > > From nobody Thu Jul 9 02:35:03 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0E41A8923; Thu, 9 Jul 2015 02:34:58 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGlCcqLrrrdK; Thu, 9 Jul 2015 02:34:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14331A8961; Thu, 9 Jul 2015 02:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3053; q=dns/txt; s=iport; t=1436434497; x=1437644097; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hvCSKl1u/z7R5R/Co+NFWU03qhPcjkT+ncaMpYRtuvA=; b=WNjyJOMn9ehf8FyX9lfVoEl8A5uDsaYgGz2DPJlAkOeqAucjTNrnFmXk Atm9/8txPyTxqfQEzGaOk9nrlVOuSpEcTOxQMBzYJw9pF/IexW1ZkS+tu zvCwcdXRvthXr1GBeIxewNiKywUcj1Vr5qn5XwqyjqqdRlT63TM5WTzI1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABBQDMP55V/49dJa1bgxJUYAa9BgqFdwKBWzsRAQEBAQEBAYEKhCMBAQEEAQEBNzQJDgQCAQgRBAEBCxQJBycLFAgBCAIEARIIiCYNzX8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBItLhDceOAaDEYEUAQSMKogCAYwAgTuEGI8yg18mggwcFYE+b4EGJRyBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,439,1432598400"; d="scan'208";a="13920050" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP; 09 Jul 2015 09:33:33 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t699XXDl030834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 09:33:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.136]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 04:33:33 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [Roll] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt Thread-Index: AQHQuPgRmtFqvPNrqkuLEPE0AutfC53S3Kew Date: Thu, 9 Jul 2015 09:33:32 +0000 Deferred-Delivery: Thu, 9 Jul 2015 09:32:46 +0000 Message-ID: References: <20150630165644.26795.43642.idtracker@ietfa.amsl.com> <559C3E04.40702@saloits.com> In-Reply-To: <559C3E04.40702@saloits.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 09:34:58 -0000 Hello Timothy: The premise is that you do not get a stack to work with another by magic, a= nd an ISA100.11a implementation would not work with ZigBee IP even if both= claim 6loWPAN. There will soon be a fourth generation of 802.15.4 and you = know that there are many variations on what you do in there, including TSCH= , frame formats, you name it. One must have a clear definition of what to pick from the standards at all = layers to achieve interworking, and a conformance body is required that wil= l validate a given profile and provide a stamp that guarantees interop.=20 I saw opposition on option 1 from 2 camps, neither of which, I understand, = is compatible with RFC 4944 by the book or could interop with ZigBee IP, fo= r instance. Either they use Mesh header to put stuff that is not a MAC addr= ess, or they use escape encoding that was never standardized. All in all, t= hey would not be able to forward a packet from one another though they cert= ainly work perfectly fine if the subnet is a silo.=20 If we get rid of the fantasy that there's a single 6LoWPAN network, and tha= t all devices can plug into it, then we see that there will be multiple bod= ies like ZigBee IP defining profiles and ensuring connectivity of compliant= implementations. A device would be designed for one such profile, where th= e use of either legacy mesh or option 1 would be enforced. Or a device coul= d be compliant with multiple such profiles in which case there would be a n= eed for configuration or discovery. To your question, I do not think that the particular use of the dispatch wo= uld be discovered on the fly, but rather imposed in the beacons. If we take= that path we could define ways to do that. But there's a more complex opposition against option 1, more difficult to d= ebate technically, and that is the political side, having to go and defend = the case against other bodies outside the IETF. So the authors were asked t= o provide additional options, which are additions to the protocol. Do you h= ave any advice on them? Cheers, Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Timothy J. Salo > Sent: mardi 7 juillet 2015 23:01 > To: Routing Over Low power and Lossy networks; 6tisch@ietf.org > Subject: Re: [Roll] FW: New Version Notification for draft-thubert-6lo- > routing-dispatch-04.txt >=20 > > Please consider those options, and come discuss them at 6Lo: > > > > Option 1 considers that a network where this specification appli= es > > is physically separate from a network where the Mesh Header > > defined in [RFC4944] is used. With that assumption, the Mesh > > Header dispatch space can be reused. >=20 > How is this configured? Does it require manual configuration? > Or, can it be reliably detected automatically? >=20 > -tjs >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Jul 9 13:40:37 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A911A016B; Thu, 9 Jul 2015 13:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqjOHQKDR411; Thu, 9 Jul 2015 13:40:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EDD1A017D; Thu, 9 Jul 2015 13:40:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150709204032.14002.31939.idtracker@ietfa.amsl.com> Date: Thu, 09 Jul 2015 13:40:32 -0700 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 20:40:35 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ From nobody Thu Jul 9 13:48:31 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C611A017E for ; Thu, 9 Jul 2015 13:48:27 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoWB0WhO0QqX for ; Thu, 9 Jul 2015 13:48:26 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 2D4A91A0092 for ; Thu, 9 Jul 2015 13:48:26 -0700 (PDT) Received: by igrv9 with SMTP id v9so202665606igr.1 for ; Thu, 09 Jul 2015 13:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4HrcgDX6EV7kQJVOYVhCIk6ehzCOVMmNbebugxgJy2I=; b=E81m5rIFLHmh6Nv7n1uCH9EqClv6StiNy8CrHbm74Jj629nC5TaxjkYhO+HQRtYW+Z gaNp7/iq2IITi5W1jC/3gjCtd8fpOos+LtN6j4xIkJVfNFSprkHtSKD42pZ013RUzu17 xu0mm4MhmYkR4pQJ+lMufPtgXzTlCVrXjUlng= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4HrcgDX6EV7kQJVOYVhCIk6ehzCOVMmNbebugxgJy2I=; b=mLiw8oQFx7XSK+wH47dXXR4f0W5ol+s+d4fqesG+vv5Py9IOM2dlxxznlkflo70cRv CYGYXt2BZXM302COiYuivF3JLxURIspcTGtY6T4UQKKdUOo5x8P1jwifdxbYdc1NLx0r YCoC45H8pwOaTXsoFliTM8JduvIGl/BO2rNW6ax7C0Sk2H8hcbSVzA24V0eBf9uoDKEG bD0J2Rm4lrwRH0MQ8wTklSp/lJZvUwU/rk6CptsqvrhPxKnR+ELE4o+TigRABWkZoCfb z/NkoQksaOSR9J8/7vGZy6iFnymAPHNvJG/B25oR0hkX803rLBoiJgFjrdiN7DGHUj6h xktw== X-Gm-Message-State: ALoCoQmj26kEmR2gvTl9sz6wNPDeRdUl7YFQDLJTNjbldVSBDDHM+d5OqN9qfyr2H1oc1TqQnkhY X-Received: by 10.50.79.196 with SMTP id l4mr101256027igx.48.1436474905530; Thu, 09 Jul 2015 13:48:25 -0700 (PDT) Received: from ?IPv6:2620:15c:1:101:542e:718a:374e:a427? ([2620:15c:1:101:542e:718a:374e:a427]) by smtp.gmail.com with ESMTPSA id kk9sm17328381igb.7.2015.07.09.13.48.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jul 2015 13:48:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6180432A-0F04-4395-BC5B-04D00B5F6518" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: james woodyatt In-Reply-To: Date: Thu, 9 Jul 2015 13:48:29 -0700 Message-Id: <967B342A-A21C-4E18-983F-2C5D316553FC@nestlabs.com> References: <20150630165644.26795.43642.idtracker@ietfa.amsl.com> <559C3E04.40702@saloits.com> To: "6lo@ietf.org" <6lo@ietf.org> X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 20:48:27 -0000 --Apple-Mail=_6180432A-0F04-4395-BC5B-04D00B5F6518 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 9, 2015, at 02:33, Pascal Thubert (pthubert) = wrote: >=20 > If we get rid of the fantasy that there's a single 6LoWPAN network, = and that all devices can plug into it, then we see that there will be = multiple bodies like ZigBee IP defining profiles and ensuring = connectivity of compliant implementations. I don=E2=80=99t remember ever adopting this fantasy, yet I still have = concerns about proceeding with this draft. > A device would be designed for one such profile, where the use of = either legacy mesh or option 1 would be enforced. I can see this happening under the terms of the current draft. I think = it=E2=80=99s important to consider what =E2=80=9Cdevice=E2=80=9D likely = means in this context. We=E2=80=99re talking about commodity = implementation modules. When you design a finished product, you choose = the commodity implementation module that implements the specific profile = of 6LoWPAN for which it was certified to interoperate. > Or a device could be compliant with multiple such profiles in which = case there would be a need for configuration or discovery. If am deeply skeptical that this assertion will be proven if we proceed = with this draft. I expect it to be much more likely that one or two = specific profiles will be implemented as commodity modules, and devices = that use them will be forced in hardware to use exactly one profile at = all times. =E2=80=94james= --Apple-Mail=_6180432A-0F04-4395-BC5B-04D00B5F6518 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 9, 2015, at 02:33, Pascal Thubert (pthubert) <pthubert@cisco.com> = wrote:

If we get rid of the fantasy that there's a = single 6LoWPAN network, and that all devices can plug into it, then we = see that there will be multiple bodies like ZigBee IP defining profiles = and ensuring connectivity of compliant = implementations.

I= don=E2=80=99t remember ever adopting this fantasy, yet I still have = concerns about proceeding with this draft.

A device would be designed for one such profile, = where the use of either legacy mesh or option 1 would be = enforced.

I can = see this happening under the terms of the current draft. I think it=E2=80=99= s important to consider what =E2=80=9Cdevice=E2=80=9D likely means in = this context. We=E2=80=99re talking about commodity implementation = modules. When you design a finished product, you choose the commodity = implementation module that implements the specific profile of 6LoWPAN = for which it was certified to interoperate.

Or a device could be compliant with multiple = such profiles in which case there would be a need for configuration or = discovery.

If am deeply skeptical that this assertion will be proven if = we proceed with this draft. I expect it to be much more likely that one = or two specific profiles will be implemented as commodity modules, and = devices that use them will be forced in hardware to use exactly one = profile at all times.

=E2=80=94james
= --Apple-Mail=_6180432A-0F04-4395-BC5B-04D00B5F6518-- From nobody Thu Jul 9 21:27:11 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1921A8862; Thu, 9 Jul 2015 21:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Fs_Bid8sudi; Thu, 9 Jul 2015 21:27:07 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF4E1A8860; Thu, 9 Jul 2015 21:27:07 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t6A4R5p9011111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2015 13:27:05 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t6A4R3Ht010749; Fri, 10 Jul 2015 13:27:03 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 463; Fri, 10 Jul 2015 13:27:03 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t6A4R3fj010745; Fri, 10 Jul 2015 13:27:03 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id t6A4R3FD001218; Fri, 10 Jul 2015 13:27:03 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id PAA01217; Fri, 10 Jul 2015 13:27:03 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t6A4R3JZ007491; Fri, 10 Jul 2015 13:27:03 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t6A4R2Ds003665; Fri, 10 Jul 2015 13:27:02 +0900 (JST) Received: from [133.199.17.57] (ivpn-2-57.mobile.toshiba.co.jp [133.199.17.57]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id E956218F4BB; Fri, 10 Jul 2015 13:27:00 +0900 (JST) Message-ID: <559D3A07.1050909@toshiba.co.jp> Date: Wed, 08 Jul 2015 23:56:07 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150707181803.6403.35920.idtracker@ietfa.amsl.com> In-Reply-To: <20150707181803.6403.35920.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: Re: [Roll] Barry Leiba's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 04:27:10 -0000 Hi Barry, Thank you very much for kind review. On 2015-07-08 3:18, Barry Leiba wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This should be a very easy discussion to resolve: > > -- Section 2.3 -- > > A node SHOULD leave an MPL domain if it receives an updated MPL > Parameter Configuration Option without a configuration for the MPL > domain, unless it has overriding manual configuration on the MPL > domain. In other words, if a node is configured to work as a MPL > Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY > stay on the MPL domain even if it receives an MPL Parameter > Configuration Option without configuration for the MPL domain. > > I'm confused by this, because it appears to contradict itself. > > Some questions might help he understand: > > If I receive an updated MPL PCO that lacks a config for the MPL domain, > then there are two possible situations: > > Case 1: I do *not* have an overriding manual config for the domain. In > this case, the text says that I SHOULD leave the domain. Is that > correct? Is it OK in this case for me to decide to stay on the domain > anyway, even if I have no manual configuration for it? Yes, a device SHOULD not stay on the domain if current domain is not present in the MPL configuration update. However, even if it stays it does not break interoperability (just waste of resource). Thus I considered it's okay to stay on the domain if an implementation has strong reason to do so (the reason is beyond my imagination). > Case 2: I *do* have an overriding manual config for the domain. In this > case, the text seems to say that it's entirely my choice ("MAY") whether > or not I stay on the domain or leave it. Is that correct? A device SHOULD stay on domains that are manually configured. I think it's better to change the MAY to SHOULD. > "SHOULD", really? What else *can* it be, and still be valid? Is there > any legitimate reason I might make it something else? Or should this > just say this?: > > NEW? > option_len: Length of the option, which is 16 if no MPL domain > address is present, or 32 if there is an MPL domain address. Oops, thank you for pointing this out. there are no other choice. Yusuke From nobody Fri Jul 10 06:00:27 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF7A1AC39E for ; Fri, 10 Jul 2015 06:00:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DW4m6d0AuGL4 for ; Fri, 10 Jul 2015 06:00:14 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2761ABD3C for ; Fri, 10 Jul 2015 06:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22656; q=dns/txt; s=iport; t=1436533214; x=1437742814; h=from:to:subject:date:message-id:mime-version; bh=WL1T+ES7r+uUl0X8rdr+VD2d2zs1Nz2/wNHH9FpdtqI=; b=K4W0vDlJrU32pHpUiZlwWDl6jw/e6CbvkRydjvgGALNbViy4lNkPhZAE d6H4yZmxw6HTCANN/5Aws8BeKuRWqI/wZCDVaBlmdqEMnYHKG4Gb0zFda cY4m0u7tfhUrzMfG9doQWS4/qZ0XhMezSz8Sfh4kdHbNuGzRI52EuMTCs w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D9BABfwZ9V/5FdJa1bgkVNVGAGuzaHaAKBUDoSAQEBAQEBAYEKhCQBAQQnBl4BCCIdORQSAQQTCIgmqTOmKQEBAQEBBQEBAQEBAQEbi0uEVQYHKgODFYEUBYwshRyCaQGNQocnjCaDXyaCCR+BU2+BR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,446,1432598400"; d="scan'208,217";a="167459616" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 13:00:13 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6AD0C7e008181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 10 Jul 2015 13:00:12 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.142]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 10 Jul 2015 08:00:12 -0500 From: "James Pylakutty (mundenma)" To: Routing Over Low power and Lossy networks Thread-Topic: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt Thread-Index: AdC7EFnlk8dtoIh7RpCB9ghtz+IoHw== Date: Fri, 10 Jul 2015 13:00:11 +0000 Message-ID: <49574B656376894588ABCFC130023CB837962798@xmb-aln-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.110.232] Content-Type: multipart/alternative; boundary="_000_49574B656376894588ABCFC130023CB837962798xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 13:00:24 -0000 --_000_49574B656376894588ABCFC130023CB837962798xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, Thanks a lot for the comments. See my responses below. Thanks -james Michael Richardson >, w= rote: Pascal, thank you for this document. I especially appreciated your figure 2, the way that you numbered the nodes= with their gross rank as the tens part. You write on page 8: The root sends the DAO directly to the last node in the segment, which is expected to be able to route to the targets on its own. It would be good to make it clear which direction one counts the "segment" to know which one is last. I don't like "segment" here, I think it's a rou= ting path... Could you define segment if you think it's the most natural t= erm to use. (There are also some articles like "the" missing in places, btw) JP> The term segment may be overloaded, it will be good to use more specifi= c name like 'projected route' instead. We can also use the terms "egress no= de" and "ingress node", rephrasing the "last node" as "egress node". The ro= ot sends the projected DAO to the egress node of the projected route. The D= AG root knows that the egress node has route to the target(s), either beca= use it is a parent in the non-storing DAO received from the targets, or bec= ause another projected route was installed by the root from that point, or = by some other unspecified means. JP> The projected route information is then signaled hop by hop upward (lik= e the storing mode DAO) through the nodes of projected route listed in the = Via information. The ingress node of the projected route is the node that f= inally sends the positive DAO-ACK to the root. JP> The projected DAO is what DAG root sends to egress node, non-storing DA= O is what a node sends to DAG root, and storing mode DAO is what gets relay= ed hop by hop upwards. Then you write: The node strips the last Via Information option which corresponds to self, and uses it as source address for the DAO to the predecessor. I think that what is described, to use the numbering in your example, is th= at the root would send a message to 41, with a target=3D51, list of VIAs:11= ,22,31,41 and *then* 41 would send a DAO to 31, with a list of VIAs 11,22,3= 1, etc. It's the "then" above part that I *think* is a critical part of the protoco= l, and is perhaps not clearly spelled out. I wasn't entirely sure if I rea= d it correctly. JP> That is correct, as shown in fig 2, but I agree we need to clarify. In the case where nodes have different downstream and upstream addresses (b= ecause, for instance they had different radios), then there might be some c= onfusion and maybe both hops should be listed. I recall I posted a thread = asking about that a year or so ago, but I don't recall what the conclusion = was. JP> The root indicates the sequence of next hop address. These are the addr= esses that are available on the interface of the child that connects to the= parent. The node uses that address as source of its own DAO, which indicat= es it on which interface to send the DAO. But, then in the example on page 9, after sending these Via-DAOs to 45 and 46, it says: The root may then send a DAO to node 35 indicating targets 55 and 56 a Via segment (13, 24, 35) to fully optimize that path. While the root had initially optimized the 45/46 out the routing header wit= h the first set of Via-DOAs (do you have a name for these messages? Projected-DAOs? maybe), couldn't that set of DOAs have included 13,24 in th= e list as well? JP> Yes, that is what is described in the very next paragraph. Let us use t= he term 'Projected-DAO" for the DAO root sends to egress node of the projec= ted route. Alternatively, could the root have sent a single Via-DOA with destination *35* to 24, with the route 13,24? That would have resulted in a routing header like: ROOT -> 35 since 13 and 24 should be able to reach 35 in a loose source route, and 35 = would know how to reach 55 and 56? JP> That is correct. **** in section 3.1, the description of the VIA extension, you write: Option Length: Variable, depending on whether or not Parent Address is present. JP> Needs to be corrected as "Option Length: Variable, depending on the le= ngth of Child Address field". But the only variability I saw in the extension was whether the child addre= ss was 8 bytes or 16 bytes. It seems that if you are going to optimize thi= s, you might as well also offer an option for the Child Address to be 2 byt= es (the last two bytes). JP> Yes, we could. Let us look at proposing 6LoPAN compression (RFC 6282) i= n this case. If it is necessary to integrate 6LoPAN compressed addresses, = we can do that. **** DAO I don't fundamentally see a reason why DAO is used. I guess it has the rig= ht properties, but I think that a new message type could be defined equally= well (as well as a new ACK), even if it just replicates the exact DAO stru= cture. It seems that the ACK is mandatory (K=3D1). I would prefer that DAOs always flow towards the root, and DIOs away. It would make analysis of what is going on easier. These DAOs in some way flow towards a node with root-like storing-like abil= ities, so I can see why it was elegant to reuse DAO for this. JP: The positive ACK for projected DAO goes from ingress node of the projec= ted route to the DAG root. It is possible we could use a non-storing mode D= AO itself for this ACK purpose. Negative ACK for projected DAO goes from eg= ress node/via node/ingress node to root. As such the mechanism is different= from K=3D1. When K is set to 1, the recipient sends the ACK to the sender = of the DAO, which may be different from what we want here. **** incremental deployment Use of a new MOP makes deployment of this a flag day. I don't think that this is necessary, although some niggling doubt going ba= ck to the mixed storing/non-storing discussion of 2011 remains... I think that the DAOs that come from nodes that are able to act as Route Pr= ojection nodes could indicate that capability, and furthermore, indicate th= e number of routing slots they currently have free. It would be advantageous perhaps to explicitly number the routing slots. My initial thought is that would permit the subsequent DAOs to perhaps incl= ude a count of how many times the Projected route was used: once the DODAG = root pushes traffic away from the root with these projected routes, it can = no longer count how much traffic is occurring, so it should get reports "fr= om the field" so that it can decide whether to keep those routes. Explicitly numbering the routing slots could be problematic I agree, but it= would allow the DODAG to manage them directly rather than the implicit pro= cess that the VIA option's Path Sequence is doing. The Path Sequence processing needs an example, btw. JP: It appears that making use of capability is better than defining a new = MOP. Possibly we can add an option to the non-storing DAO which can be used= by a node to announce the projected DAO capability and to announce the max= number of projected routes that can be supported. Thanks -james --_000_49574B656376894588ABCFC130023CB837962798xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

Thanks a lot for the comments. =

 

See my responses below.

Thanks

-james

Michael Richardson <mcr+IETF@sandelman.ca>, wrote:

 

<Chair hat off>

 

Pascal, thank you for this document.

I especially appreciated your figure 2, the way t= hat you numbered the nodes with their gross rank as the tens part.

 

You write on page 8:

   The root sends the DAO directly to t= he last node in the segment,

   which is expected to be able to rout= e to the targets on its own.

 

It would be good to make it clear which direction= one counts the "segment"

to know which one is last.  I don't like &qu= ot;segment" here, I think it's a routing path...  Could you defin= e segment if you think it's the most natural term to use.

(There are also some articles like "the"= ; missing in places, btw)

 

JP> The term segment may be overloaded, it = will be good to use more specific name like ‘projected route’ i= nstead. We can also use the terms “egress node” and “ingr= ess node”, rephrasing the "last node" as "egress node&= quot;. The root sends the projected DAO to the egress node of the projected route. The DAG root knows that the egress node has  route to the target(s), e= ither because it is a parent in the non-storing DAO received from the targe= ts, or because another projected route was installed by the root from that = point, or by some other unspecified means.

JP> The proje= cted route information is then signaled hop by hop upward (like the storing= mode DAO) through the nodes of projected route listed in the Via informati= on. The ingress node of the projected route is the node that finally sends the positive DAO-ACK to the root.  

JP> The proje= cted DAO is what DAG root sends to egress node, non-storing DAO is what a n= ode sends to DAG root, and storing mode DAO is what gets relayed hop by hop= upwards.

 

Then you write:

   The node strips the last Via Informa= tion option which corresponds to

   self, and uses it as source address = for the DAO to the predecessor.

 

 

I think that what is described, to use the number= ing in your example, is that the root would send a message to 41, with a ta= rget=3D51, list of VIAs:11,22,31,41 and *then* 41 would send a DAO to 31, w= ith a list of VIAs 11,22,31, etc.

 

It's the "then" above part that I *thin= k* is a critical part of the protocol, and is perhaps not clearly spelled o= ut.  I wasn't entirely sure if I read it correctly.

 

JP> That is corr= ect, as shown in fig 2, but I agree we need to clarify.

 

In the case where nodes have different downstream= and upstream addresses (because, for instance they had different radios), = then there might be some confusion and maybe both hops should be listed.&nb= sp; I recall I posted a thread asking about that a year or so ago, but I don't recall what the conclusion was.

 

JP> The root ind= icates the sequence of next hop address. These are the addresses that are a= vailable on the interface of the child that connects to the parent. The nod= e uses that address as source of its own DAO, which indicates it on which interface to send the DAO.

 

But, then in the example on page 9, after sending= these Via-DAOs to

45 and 46, it says:

   The root

   may then send a DAO to node 35 indic= ating targets 55 and 56 a Via

   segment (13, 24, 35) to fully optimi= ze that path.

 

While the root had initially optimized the 45/46 = out the routing header with the first set of Via-DOAs (do you have a name f= or these messages?

Projected-DAOs? maybe), couldn't that set of DOAs= have included 13,24 in the list as well?

 

JP> Yes, that is what is described in the v= ery next paragraph. Let us use the term 'Projected-DAO" for the DAO ro= ot sends to egress node of the projected route.

 

Alternatively, could the root have sent a single = Via-DOA with destination

*35* to 24, with the route 13,24?   Tha= t would have resulted in a routing

header like:

       ROOT -> 3= 5

since 13 and 24 should be able to reach 35 in a l= oose source route, and 35 would know how to reach 55 and 56?

 

JP> That is correct= .

 

****

 

in section 3.1, the description of the VIA extens= ion, you write:

 

Option Length:  Variable, depending on wheth= er or not Parent Address

         = is present.

 

JP> Needs to be corrected as "Option L= ength:  Variable, depending on the length of Child Address field"= .

 

 

But the only variability I saw in the extension w= as whether the child address was 8 bytes or 16 bytes.  It seems that i= f you are going to optimize this, you might as well also offer an option fo= r the Child Address to be 2 bytes (the last two bytes).

 

JP> Yes, we could. Let us look at proposing= 6LoPAN compression (RFC 6282) in this case.  If it is necessary to in= tegrate 6LoPAN compressed addresses, we can do that.

 

**** DAO

 

I don't fundamentally see a reason why DAO is use= d.  I guess it has the right properties, but I think that a new messag= e type could be defined equally well (as well as a new ACK), even if it jus= t replicates the exact DAO structure.  It seems that the ACK is mandatory (K=3D1).

 

I would prefer that DAOs always flow towards the = root, and DIOs away.

It would make analysis of what is going on easier= .

These DAOs in some way flow towards a node with r= oot-like storing-like abilities, so I can see why it was elegant to reuse D= AO for this.

 

JP: The positive ACK for projected DAO goes fr= om ingress node of the projected route to the DAG root. It is possible we c= ould use a non-storing mode DAO itself for this ACK purpose. Negative ACK f= or projected DAO goes from egress node/via node/ingress node to root. As such the mechanism is different fro= m K=3D1. When K is set to 1, the recipient sends the ACK to the sender of t= he DAO, which may be different from what we want here.

 

**** incremental deployment

 

Use of a new MOP makes deployment of this a flag = day.

I don't think that this is necessary, although so= me niggling doubt going back to the mixed storing/non-storing discussion of= 2011 remains...

 

I think that the DAOs that come from nodes that a= re able to act as Route Projection nodes could indicate that capability, an= d furthermore, indicate the number of routing slots they currently have fre= e.

 

It would be advantageous perhaps to explicitly nu= mber the routing slots.

My initial thought is that would permit the subse= quent DAOs to perhaps include a count of how many times the Projected route= was used: once the DODAG root pushes traffic away from the root with these= projected routes, it can no longer count how much traffic is occurring, so it should get reports "from t= he field" so that it can decide whether to keep those routes.

 

Explicitly numbering the routing slots could be p= roblematic I agree, but it would allow the DODAG to manage them directly ra= ther than the implicit process that the VIA option's Path Sequence is doing= .

 

The Path Sequence processing needs an example, bt= w.

 

JP: It appears that making use of capability i= s better than defining a new MOP. Possibly we can add an option to the non-= storing DAO which can be used by a node to announce the projected DAO capab= ility and to announce the max number of projected routes that can be supported.  

Thanks

-james

 

 

--_000_49574B656376894588ABCFC130023CB837962798xmbalnx01ciscoc_-- From nobody Fri Jul 10 08:13:43 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EC81A924A for ; Fri, 10 Jul 2015 08:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMRenPIrYV-5 for ; Fri, 10 Jul 2015 08:13:41 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D30F1A923E for ; Fri, 10 Jul 2015 08:13:41 -0700 (PDT) Received: by lbnk3 with SMTP id k3so94347710lbn.1 for ; Fri, 10 Jul 2015 08:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=SeGxiYTwUdyYxqheGXUfgl+eBZTfEEpGxivYH0vX5D0=; b=ntjHxBSNjP/h3hYgY48Aol8vdMMFozZoTMYSNNXGjBOLcNWJncTtn0CWp99UfF7YZU v/kjvD2uLKxjTCYFRC7F2GLy/MdzxapPO9z568ij2ggxkltIBywUtSP87dxmP1PFxGnk fLrlrbDBx8NxFMz0dIIMKBf4Nt/wn5NOK6a6Wb56jbQkW73seODj149Vr5evQnO+HBJn HFyywZ/BiVmi4mzh/k58dVV3wB8rNzWSF8VEWAXJhbD0w4NY3EXjxS8dnds9nenvVa4Z piJG48IWJXkUtA9FWuLVA2GsQqPiHzVl/1Ub8FHMfq1qAm5tqg+jrvctahJZzJNL+3GZ X8Uw== MIME-Version: 1.0 X-Received: by 10.112.47.73 with SMTP id b9mr20318536lbn.46.1436541219638; Fri, 10 Jul 2015 08:13:39 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Fri, 10 Jul 2015 08:13:39 -0700 (PDT) Date: Fri, 10 Jul 2015 18:13:39 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=001a1134612c1a1529051a86d1e0 Archived-At: Cc: Michael Richardson Subject: [Roll] Agenda ROLL - IETF 93 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:13:42 -0000 --001a1134612c1a1529051a86d1e0 Content-Type: text/plain; charset=UTF-8 Hi, Please find our agenda for IETF 93 https://www.ietf.org/proceedings/93/agenda/agenda-93-roll Any comments are very welcome, Thanks, Michael and Ines --001a1134612c1a1529051a86d1e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find our agenda for IETF 93<= /div>


Any comments are very welcome,

Thanks,

Michael and Ines
--001a1134612c1a1529051a86d1e0-- From nobody Fri Jul 10 12:10:21 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9AC1B2A7E for ; Fri, 10 Jul 2015 12:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIBbes7Tl4eW for ; Fri, 10 Jul 2015 12:10:18 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 522E71B2A70 for ; Fri, 10 Jul 2015 12:10:18 -0700 (PDT) Received: by ykeo3 with SMTP id o3so150218955yke.0 for ; Fri, 10 Jul 2015 12:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zHfMsXg16pF8C53bI5bj7USxOAfEX456ba/JbqsOmRM=; b=Yes0I1uEof6ZvrxGPsCEspyNezud+eE83ejfOM5+Fqe5nZHSENeL0k4g33fjzKo1iy 4/Nne12g9E0oiZgeSOrREqujcQhI8wKX5hUw/YDjrclZM8xK2BwSnvMe2IV5NG3a5Six URKucMLQuBK4bSIgO72fKVpilsYlV+RapbKcI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zHfMsXg16pF8C53bI5bj7USxOAfEX456ba/JbqsOmRM=; b=MPwF/pdAEcf6jUVFnCSGUedafVgziKxRli+JJWarQExV3UB1lXDQzNUIU4aE6WIVJM vfvEG/05oWmKyMqQcCCuJ6qsLj4QGsv0rDJXmW1KwZRj9HZEkpT27IRESSh29QV4L5Hi gIc7L+aRiJhzaWvI/CeN22QHu+vsLsY6rieXtcxvR2lXm88mF7ku89nnXSeHVh1RFXQm qy/+3ovCVGPYxClDRxP4vBiCMBngbGz4An2tiaBrGkWwUPSMZ02qPSz0LOYEcgEjregn Ew/hX2j10iElLL2kudfgxTh98lIfNUbWIAfSAnQ3JG387D2izIJwhHIJzPTSect2VuBd sCxg== X-Gm-Message-State: ALoCoQkq4XzvbtmrNrsfnzq1mrN6m1c7Bw8p7VA4s6zgqAd28XvQ++pQUVuQ+GDFvactSEtYQGB8 MIME-Version: 1.0 X-Received: by 10.170.131.193 with SMTP id x184mr11981952ykb.42.1436555417704; Fri, 10 Jul 2015 12:10:17 -0700 (PDT) Received: by 10.37.207.75 with HTTP; Fri, 10 Jul 2015 12:10:17 -0700 (PDT) In-Reply-To: References: <20150630165644.26795.43642.idtracker@ietfa.amsl.com> Date: Fri, 10 Jul 2015 12:10:17 -0700 Message-ID: From: Jonathan Hui To: Gabriel Montenegro Content-Type: multipart/alternative; boundary=001a11396dee5f8f68051a8a1f29 Archived-At: Cc: Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 19:10:20 -0000 --001a11396dee5f8f68051a8a1f29 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 12:09 PM, Gabriel Montenegro < Gabriel.Montenegro@microsoft.com> wrote: > Thanks, Pascal. > > I see that options 1 and 2 reuse the mesh header. And option 3 reuses > NALP. All three of these reuse previously assigned values. > My reading of Option 3 in Section 3.3 is that it uses bit patterns that have not been assigned yet. In particular, bit patterns of the form 11x1xxxx. I was under the impression that one of the options was going to use a new > type out of the ESC+ space. Sure, as you mention in the new draft > revision, that is not defined clearly yet (though there is something being > prepared), but neither is any of the stuff in the draft. > That is certainly another option to consider. The point is that it would be good to have at least one option that does > not reuse anything previously assigned (other than ESC, which is there for > that purpose and is in our control to further define). > I agree that we should strongly consider encodings that allow both existing assigned bit patterns and the TBD bit patterns to co-exist in the same 6LoWPAN frame. If we can, we should avoid straight up reuse of bit-patterns without any way to distinguish how to interpret between the old and new. Oh, and request noted. It would definitely be good to discuss this in > Prague. > Agree. -- Jonathan Hui --001a11396dee5f8f68051a8a1f29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Jun 30, 2015 at 12:09 PM, Gabriel Montenegro <= Gabri= el.Montenegro@microsoft.com> wrote:
Thanks, Pascal.

I see that options 1 and 2 reuse the mesh header. And option 3 reuses NALP.= All three of these reuse previously assigned values.
=
My reading of Option 3 in Section 3.3 is that it uses bit pa= tterns that have not been assigned yet.=C2=A0 In particular, bit patterns o= f the form 11x1xxxx.

I was under the impression that one of the options was going to use a new t= ype out of the ESC+<type> space. Sure, as you mention in the new draf= t revision, that is not defined clearly yet (though there is something bein= g prepared), but neither is any of the stuff in the draft.
=

That is certainly another option to consider.

The point is that it would be good to have at least one option that does no= t reuse anything previously assigned (other than ESC, which is there for th= at purpose and is in our control to further define).
<= br>
I agree that we should strongly consider encodings that allow= both existing assigned bit patterns and the TBD bit patterns to co-exist i= n the same 6LoWPAN frame.=C2=A0 If we can, we should avoid straight up reus= e of bit-patterns without any way to distinguish how to interpret between t= he old and new.

Oh, and request noted. It would definitely be good to discuss this in Pragu= e.

Agree.

--
Jonathan Hui

--001a11396dee5f8f68051a8a1f29-- From nobody Mon Jul 13 14:54:36 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C841A1EED; Mon, 13 Jul 2015 14:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b3N4Z5sDegM; Mon, 13 Jul 2015 14:54:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3F81A1BDB; Mon, 13 Jul 2015 14:54:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150713215425.24718.94967.idtracker@ietfa.amsl.com> Date: Mon, 13 Jul 2015 14:54:25 -0700 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-11: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 21:54:32 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-roll-applicability-home-building-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the discussion so far and for the changes to the document. I think (modulo comments) we're mostly done with the blocking discuss stuff but I do two more question at that level. 1) This could be my ignorance of zigbee, but how can we use layer 2 security for only some network nodes? (In other words, I don't see how 4.1.8.2 works.) 2) Just checking - this depends on the zigbeeip authentication mechanism, with which I'm also not familiar, sorry. Does using that mean that this entire applicability statement only covers use of RPL where zigbee radios are in use? Or can that authentication scheme be used independently of the radio technology used? (I mean used in practice there, not in theory.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- First two comments are about text that's new in -11: - 4.1.8: "MUST be present" is ambiguous - do you mean it must be used? I think you do. - 4.1.8: "MUST be distributed or established in a secure fashion" isn't really a protocol requirement. Do you really just mean "see 4.1.8.1" ? OLD COMMENTS FOR -10 below, I didn't check if you'd made any related changes. - I don't get how there's an IPR disclosure for this, but whatever. - The non-security parts of this were quite a good read. - 4.1.8: 1st sentence makes no sense. It says RPL does X or not-X in order to Y. There is no choice but for RPL to do X or not-X. - 4.1.8 seems to me to imply that link layer security is always needed since there can always be some node that will send an unsecured RPL messsage. If you agree, then I think that should be made more clear. If you disagree, I'd like to understand how. - 4.1.8, I am surprised not to see a recommendation that separate group keys SHOULD be used for different applications in the same bulding network. But that may be too fine grained a recommendation for this document perhaps. - 5.1.2.1, I think it'd be clearer to say Imin should be between 10 and 50 ms. The "10 - 50 ms" notation can be confusing. (Same elsewhere.) - section 7, 3rd para, "can rely on" is sales language, please strike that or s/rely on/depend upon/ - section 7, 3rd para, last sentence: this is sales language and should be deleted. Or perhaps s/is/SHOULD be/ would turn it back into a piece of specification language. - 7.1 - this is odd text to see in a proposed standard, but I think it's accurately describing the level of interop to expect in RPL security, so is probably the right thing to say. I'd argue that it'd be even better to bluntly admit/say that there is currently no interoperable automated key management for RPL. (Same for 7.3) Or, and better, to fix that lack. (See my discuss point.) - 7.2, 1st sentence: this is meaningless as I read it - what are you trying to say? - 7.2, when a node is stolen, the chances are that any keys contained in the node are at significant risk of being leaked. - 7.3, I do not believe that [I-D.keoh-dice-multicast-security] is necessarily going to proceed via the DICE WG. Depending on it would be fairly high-risk in any case. - 7.4, last sentence: more sales talk - 7.5, what is this specifying? I don't get it. Does 7416 set out what to implement to get interop? (I didn't think so, but nor does this seem to.) From nobody Tue Jul 14 15:17:44 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1011B2E76; Tue, 14 Jul 2015 15:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sws9meJpzcox; Tue, 14 Jul 2015 15:17:37 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 7ADCC1B2E77; Tue, 14 Jul 2015 15:17:37 -0700 (PDT) Received: by qkcl188 with SMTP id l188so16459180qkc.1; Tue, 14 Jul 2015 15:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ng82KcwdLzOgCHDLX9G4K2YwiexL4OFNyc8SzxIeuaM=; b=hUhG/QUyh3dnklxKmhIwI6UDgRD4BadsL8EyNBYoHNa/nzRTGZe3rZQvROMYPeBAqh k+dWPOVT4QOH6Y+7FfHlyssRZ6Rs9SO+FL5xhT1R8cIlw8egCsy0zK70GX/V6xIlWM02 1KcxtJA4VW4RSoT/7u0L1IGiCXgKU3Ybh8FHlZ5rGD7Qel4al4tsXUHp8q9DtlEpxzE3 zdWvRz07mlgjfqPdl71O+pDcoz3BG7pFyxEIP50Vg2iryxJ3RociRgsYQa/4C6sQVWyM KLksnMtPGSa0LfsYpoTBeyoG69MLU8ODRsWs793lg9JpOSNSLD2MulxP1GGhniFtHYyv 5VSg== MIME-Version: 1.0 X-Received: by 10.55.15.129 with SMTP id 1mr1854256qkp.29.1436912256805; Tue, 14 Jul 2015 15:17:36 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.140.108.182 with HTTP; Tue, 14 Jul 2015 15:17:36 -0700 (PDT) In-Reply-To: <20150713215425.24718.94967.idtracker@ietfa.amsl.com> References: <20150713215425.24718.94967.idtracker@ietfa.amsl.com> Date: Tue, 14 Jul 2015 23:17:36 +0100 X-Google-Sender-Auth: 0r1YOgVsYpA6vIio-nsWLDS7Seg Message-ID: From: Robert Cragie To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a1146f100a3f296051add34bf Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building@ietf.org, Yvonne-Anne Pignolet , draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-11: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 22:17:40 -0000 --001a1146f100a3f296051add34bf Content-Type: text/plain; charset=UTF-8 Hi Stephen, Thanks for your further review. Answers and comments inline, bracketed by Robert 1) This could be my ignorance of zigbee, but how can we > use layer 2 security for only some network nodes? (In > other words, I don't see how 4.1.8.2 works.) > All network nodes use L2 security once they have joined the network. Prior to that, they communicate using an authentication protocol which is unsecured at L2. Enforcement points police unsecured traffic to ensure it is only related to authentication, thus preventing data or other control plane traffic unsecured at L2 from being allowed into the network. So, to your point, the only traffic allowed unsecured at L2 is authentication traffic and those nodes are not yet participating in the network. > > 2) Just checking - this depends on the zigbeeip > authentication mechanism, with which I'm also not > familiar, sorry. Does using that mean that this entire > applicability statement only covers use of RPL where > zigbee radios are in use? Or can that authentication > scheme be used independently of the radio technology > used? (I mean used in practice there, not in theory.) > The authentication scheme is independent of the radio technology as it is based on UDP/IP and therefore could be use with a number of different radio technologies or indeed other MAC/PHY technologies - 4.1.8: "MUST be present" is ambiguous - do you mean > it must be used? I think you do. > Yes - 4.1.8: "MUST be distributed or established in a > secure fashion" isn't really a protocol requirement. > Do you really just mean "see 4.1.8.1" ? > Yes. It was meant more as an introductory statement but is redundant really OLD COMMENTS FOR -10 below, I didn't check if you'd made > any related changes. > These seem to apply more to -09. Some of these were fixed in -10, some in -11 > - I don't get how there's an IPR disclosure for this, but > whatever. > Not from me, so I can't comment on that - The non-security parts of this were quite a good read. > > - 4.1.8: 1st sentence makes no sense. It says RPL does X or > not-X in order to Y. There is no choice but for RPL to do X or > not-X. > > - 4.1.8 seems to me to imply that link layer security is > always needed since there can always be some node that will > send an unsecured RPL messsage. If you agree, then I think > that should be made more clear. If you disagree, I'd like to > understand how. > > - 4.1.8, I am surprised not to see a recommendation that > separate group keys SHOULD be used for different applications > in the same bulding network. But that may be too fine grained > a recommendation for this document perhaps. > No longer applicable as 4.1.8 has been completely rewritten. > > - 5.1.2.1, I think it'd be clearer to say Imin should be > between 10 and 50 ms. The "10 - 50 ms" notation can be > confusing. (Same elsewhere.) > Used "to" instead of "-" > > - section 7, 3rd para, "can rely on" is sales language, please > strike that or s/rely on/depend upon/ > > - section 7, 3rd para, last sentence: this is sales language > and should be deleted. Or perhaps s/is/SHOULD be/ would turn > it back into a piece of specification language. > Paragraph has been rewritten > > - 7.1 - this is odd text to see in a proposed standard, but I > think it's accurately describing the level of interop to > expect in RPL security, so is probably the right thing to say. > I'd argue that it'd be even better to bluntly admit/say that > there is currently no interoperable automated key management > for RPL. (Same for 7.3) Or, and better, to fix that lack. (See > my discuss point.) > Section has been rewritten > > - 7.2, 1st sentence: this is meaningless as I read it - what > are you trying to say? > Section has been rewritten > > - 7.2, when a node is stolen, the chances are that any keys > contained in the node are at significant risk of being leaked. > The text has been changed but probably doesn't meet your requirements regarding this point. I would say nodes have to be re-keyed at L2 and MAY need to have additional measures taken depending on the other credentials they have and how the confidential information is stored. e.g. certificate revocation.. > > - 7.3, I do not believe that [I-D.keoh-dice-multicast-security] > is necessarily going to proceed via the DICE WG. Depending > on it would be fairly high-risk in any case. > Has been removed > > - 7.4, last sentence: more sales talk > I'm not sure we even need a section on MPL; MPL has nothing to do with RPL. Assuming we do, this is still outstanding, so I suggest replacing "The application of security measures for the specification of the multicast addresses assures that the routing of MPL packets is secured." with something like "For secure dissemination of MPL packets, layer 2 security SHOULD be used and the configuration of multicast addresses MUST be secure." > > - 7.5, what is this specifying? I don't get it. Does 7416 set > out what to implement to get interop? (I didn't think so, but > nor does this seem to.) > This is still outstanding. I think it is OK to briefly highlight the steps being taken to mitigate against the threats outlined in RFC 7416. The statement "Key management discussed in section 7.4, "Key Management" of [RFC7416], is not standardized and discussions continue." is now not relevant as there is now a proposal in this document. I will work with Peter to produce some new text on this. --001a1146f100a3f296051add34bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thanks for your further rev= iew. Answers and comments inline, bracketed by <RCC></RCC>

Robert

=
1) This could be my ignorance o= f zigbee, but how can we
use layer 2 security for only some network nodes?=C2=A0 (In
other words, I don't see how 4.1.8.2 works.)

<= /div>
<RCC>All network nodes use L2 security once they have joine= d the network. Prior to that, they communicate using an authentication prot= ocol which is unsecured at L2. Enforcement points police unsecured traffic = to ensure it is only related to authentication, thus preventing data or oth= er control plane traffic unsecured at L2 from being allowed into the networ= k. So, to your point, the only traffic allowed unsecured at L2 is authentic= ation traffic and those nodes are not yet participating in the network.<= /RCC> =C2=A0=C2=A0

2) Just checking - this depends on the zigbeeip
authentication mechanism, with which I'm also not
familiar, sorry. Does using that mean that this entire
applicability statement only covers use of RPL where
zigbee radios are in use? Or can that authentication
scheme be used independently of the radio technology
used? (I mean used in practice there, not in theory.)
= =C2=A0
<RCC>The authentication scheme is independent of the= radio technology as it is based on UDP/IP and therefore could be use with = a number of different radio technologies or indeed other MAC/PHY technologi= es</RCC>

- 4.1.8: "MUST be= present" is ambiguous - do you mean
it must be used? I think you do.

<RC= C>Yes</RCC>

- 4.1.8: "MU= ST be distributed or established in a
secure fashion" isn't really a protocol requirement.
Do you really just mean "see 4.1.8.1" ?

=
<RCC>Yes. It was meant more as an introductory statement b= ut is redundant really</RCC>=C2=A0

OLD COMMENTS FOR -10 below, I didn't check if you'd made
any related changes.

<RCC>These s= eem to apply more to -09. Some of these were fixed in -10, some in -11 <= /RCC>


- I don't get how there's an IPR disclosure for this, but
whatever.

<RCC>Not from me, so I = can't comment on that</RCC>=C2=A0

- The non-security parts of this were quite a good read.

- 4.1.8: 1st sentence makes no sense. It says RPL does X or
not-X in order to Y. There is no choice but for RPL to do X or
not-X.

- 4.1.8 seems to me to imply that link layer security is
always needed since there can always be some node that will
send an unsecured RPL messsage. If you agree, then I think
that should be made more clear. If you disagree, I'd like to
understand how.

- 4.1.8, I am surprised not to see a recommendation that
separate group keys SHOULD be used for different applications
in the same bulding network. But that may be too fine grained
a recommendation for this document perhaps.

=
<RCC>No longer applicable as 4.1.8 has been completely rewritten= .</RCC>
=C2=A0

- 5.1.2.1, I think it'd be clearer to say Imin should be
between 10 and 50 ms. The "10 - 50 ms" notation can be
confusing. (Same elsewhere.)

<RCC>= ;Used "to" instead of "-"</RCC>=C2=A0

- section 7, 3rd para, "can rely on" is sales language, please strike that or s/rely on/depend upon/

- section 7, 3rd para, last sentence: this is sales language
and should be deleted. Or perhaps s/is/SHOULD be/ would turn
it back into a piece of specification language.

<RCC>Paragraph has been rewritten</RCC>=C2=A0

- 7.1 - this is odd text to see in a proposed standard, but I
think it's accurately describing the level of interop to
expect in RPL security, so is probably the right thing to say.
I'd argue that it'd be even better to bluntly admit/say that
there is currently no interoperable automated key management
for RPL. (Same for 7.3) Or, and better, to fix that lack. (See
my discuss point.)

<RCC>Section h= as been rewritten</RCC>=C2=A0

- 7.2, 1st sentence: this is meaningless as I read it - what
are you trying to say?

<RCC>Secti= on has been rewritten</RCC> =C2=A0

- 7.2, when a node is stolen, the chances are that any keys
contained in the node are at significant risk of being leaked.

<RCC>The text has been changed but probably d= oesn't meet your requirements regarding this point. I would say nodes h= ave to be re-keyed at L2 and MAY need to have additional measures taken dep= ending on the other credentials they have and how the confidential informat= ion is stored. e.g. certificate revocation..</RCC>=C2=A0

- 7.3, I do not believe that [I-D.keoh-dice-multicast-security]
is necessarily going to proceed via the DICE WG. Depending
on it would be fairly high-risk in any case.

<RCC>Has been removed</RCC>=C2=A0

- 7.4, last sentence: more sales talk

&= lt;RCC>I'm not sure we even need a section on MPL; MPL has nothing t= o do with RPL. Assuming we do, this is still outstanding, so I suggest repl= acing=C2=A0"The application of security measures for the specification= of the multicast addresses assures that the routing of MPL packets is secu= red." with something like "For secure dissemination of MPL packet= s, layer 2 security SHOULD be used and the configuration of multicast addre= sses MUST be secure."

- 7.5, what is this specifying? I don't get it. Does 7416 set
out what to implement to get interop? (I didn't think so, but
nor does this seem to.)

<RCC>This= is still outstanding. I think it is OK to briefly highlight the steps bein= g taken to mitigate against the threats outlined in RFC 7416. The statement= "Key management discussed in section 7.4, "Key Management" = of [RFC7416], is not standardized and discussions continue." is now no= t relevant as there is now a proposal in this document. I will work with Pe= ter to produce some new text on this.</RCC>=C2=A0

--001a1146f100a3f296051add34bf-- From nobody Tue Jul 14 15:36:49 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2A41B2EBC; Tue, 14 Jul 2015 15:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWhI1G1es4oa; Tue, 14 Jul 2015 15:36:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC1C1B2EB2; Tue, 14 Jul 2015 15:36:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D3C43BE53; Tue, 14 Jul 2015 23:36:39 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pno0oe0sjhVA; Tue, 14 Jul 2015 23:36:37 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.158]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8C632BE4D; Tue, 14 Jul 2015 23:36:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436913397; bh=Y6jl837AuspAyBZwQJ87UrS8ftKD+g9FcysapjMvitY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=NPWhCemwLP8ALdbF6dvBclxXfbUFk+eKxJUjnwaNZRb0proE5C0SRGMNAxz6bftR+ TRfaxQmRgvpB5nt1yePw9X1ntujAl0hya4fG6BTMfX++FCd8a2iTQ/0PEz7+StU9DL K0vAqwkMzaLbTuZBakGffhF0n0geBCPNU/TyvvUU= Message-ID: <55A58EF4.9020700@cs.tcd.ie> Date: Tue, 14 Jul 2015 23:36:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks References: <20150713215425.24718.94967.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building@ietf.org, Yvonne-Anne Pignolet , draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-11: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 22:36:45 -0000 Hiya, On 14/07/15 23:17, Robert Cragie wrote: > Hi Stephen, > > Thanks for your further review. Answers and comments inline, bracketed by > > > Robert > > 1) This could be my ignorance of zigbee, but how can we >> use layer 2 security for only some network nodes? (In >> other words, I don't see how 4.1.8.2 works.) >> > > All network nodes use L2 security once they have joined the network. > Prior to that, they communicate using an authentication protocol which is > unsecured at L2. Enforcement points police unsecured traffic to ensure it > is only related to authentication, thus preventing data or other control > plane traffic unsecured at L2 from being allowed into the network. So, to > your point, the only traffic allowed unsecured at L2 is authentication > traffic and those nodes are not yet participating in the network. Right, that's what I thought. So I can't see how the text that implies that only a subset of nodes on the network are using l2 security works which seems to be implied by the bullet just before the start of 4.1.8.2. All the stuff below is fine, so we're just down to the above in terms of clearing the discuss. Cheers, S. > >> >> 2) Just checking - this depends on the zigbeeip >> authentication mechanism, with which I'm also not >> familiar, sorry. Does using that mean that this entire >> applicability statement only covers use of RPL where >> zigbee radios are in use? Or can that authentication >> scheme be used independently of the radio technology >> used? (I mean used in practice there, not in theory.) >> > > The authentication scheme is independent of the radio technology as it > is based on UDP/IP and therefore could be use with a number of different > radio technologies or indeed other MAC/PHY technologies > > - 4.1.8: "MUST be present" is ambiguous - do you mean >> it must be used? I think you do. >> > > Yes > > - 4.1.8: "MUST be distributed or established in a >> secure fashion" isn't really a protocol requirement. >> Do you really just mean "see 4.1.8.1" ? >> > > Yes. It was meant more as an introductory statement but is redundant > really > > OLD COMMENTS FOR -10 below, I didn't check if you'd made >> any related changes. >> > > These seem to apply more to -09. Some of these were fixed in -10, some > in -11 > > >> - I don't get how there's an IPR disclosure for this, but >> whatever. >> > > Not from me, so I can't comment on that > > - The non-security parts of this were quite a good read. >> >> - 4.1.8: 1st sentence makes no sense. It says RPL does X or >> not-X in order to Y. There is no choice but for RPL to do X or >> not-X. >> >> - 4.1.8 seems to me to imply that link layer security is >> always needed since there can always be some node that will >> send an unsecured RPL messsage. If you agree, then I think >> that should be made more clear. If you disagree, I'd like to >> understand how. >> >> - 4.1.8, I am surprised not to see a recommendation that >> separate group keys SHOULD be used for different applications >> in the same bulding network. But that may be too fine grained >> a recommendation for this document perhaps. >> > > No longer applicable as 4.1.8 has been completely rewritten. > > >> >> - 5.1.2.1, I think it'd be clearer to say Imin should be >> between 10 and 50 ms. The "10 - 50 ms" notation can be >> confusing. (Same elsewhere.) >> > > Used "to" instead of "-" > >> >> - section 7, 3rd para, "can rely on" is sales language, please >> strike that or s/rely on/depend upon/ >> >> - section 7, 3rd para, last sentence: this is sales language >> and should be deleted. Or perhaps s/is/SHOULD be/ would turn >> it back into a piece of specification language. >> > > Paragraph has been rewritten > >> >> - 7.1 - this is odd text to see in a proposed standard, but I >> think it's accurately describing the level of interop to >> expect in RPL security, so is probably the right thing to say. >> I'd argue that it'd be even better to bluntly admit/say that >> there is currently no interoperable automated key management >> for RPL. (Same for 7.3) Or, and better, to fix that lack. (See >> my discuss point.) >> > > Section has been rewritten > >> >> - 7.2, 1st sentence: this is meaningless as I read it - what >> are you trying to say? >> > > Section has been rewritten > >> >> - 7.2, when a node is stolen, the chances are that any keys >> contained in the node are at significant risk of being leaked. >> > > The text has been changed but probably doesn't meet your requirements > regarding this point. I would say nodes have to be re-keyed at L2 and MAY > need to have additional measures taken depending on the other credentials > they have and how the confidential information is stored. e.g. certificate > revocation.. > >> >> - 7.3, I do not believe that [I-D.keoh-dice-multicast-security] >> is necessarily going to proceed via the DICE WG. Depending >> on it would be fairly high-risk in any case. >> > > Has been removed > >> >> - 7.4, last sentence: more sales talk >> > > I'm not sure we even need a section on MPL; MPL has nothing to do with > RPL. Assuming we do, this is still outstanding, so I suggest replacing "The > application of security measures for the specification of the multicast > addresses assures that the routing of MPL packets is secured." with > something like "For secure dissemination of MPL packets, layer 2 security > SHOULD be used and the configuration of multicast addresses MUST be secure." > >> >> - 7.5, what is this specifying? I don't get it. Does 7416 set >> out what to implement to get interop? (I didn't think so, but >> nor does this seem to.) >> > > This is still outstanding. I think it is OK to briefly highlight the > steps being taken to mitigate against the threats outlined in RFC 7416. The > statement "Key management discussed in section 7.4, "Key Management" of > [RFC7416], is not standardized and discussions continue." is now not > relevant as there is now a proposal in this document. I will work with > Peter to produce some new text on this. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Wed Jul 15 02:23:46 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A131A010F; Wed, 15 Jul 2015 02:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAgwsNQt3Pgl; Wed, 15 Jul 2015 02:23:40 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF84E1A010D; Wed, 15 Jul 2015 02:23:39 -0700 (PDT) Received: by qgef3 with SMTP id f3so15358176qge.0; Wed, 15 Jul 2015 02:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rwPN0az/vC+DcSwcbPl5vHdWqX39m5Hss9X/AUa35Yk=; b=LDJDEVLuqdcl+iVg02ycqsUsYVlmhsOoPV/yD+6m80xtdkheBTOQOgDlWLc4LZKsyZ L4q9pc1CCZ6P6NN1GJJbZ6ic+jU/qyzYnbAh3xGLC3zmq5u1f6tSD1cUA1TVb67bxCfe C4DYIn37ohKA7CBHCXBc+4WZDuDlg8bGsXPYnkZRP1AmCg1od98zObeSeZ5mqacdpbyO rt3W/CzHSfTmPml2jlABsqiL5IzW4koHSpRaOhgDrDf/8KTHq1+nxkBqHlSr9X0nTjr1 IoRtSHVcalBbcNlPzGnxbbwqTKGpbjdyPYOklH07+blA8WiTviNaNlGFWT2YnlyxNps3 gXew== MIME-Version: 1.0 X-Received: by 10.140.93.43 with SMTP id c40mr6732074qge.54.1436952219144; Wed, 15 Jul 2015 02:23:39 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.140.108.182 with HTTP; Wed, 15 Jul 2015 02:23:39 -0700 (PDT) In-Reply-To: <55A58EF4.9020700@cs.tcd.ie> References: <20150713215425.24718.94967.idtracker@ietfa.amsl.com> <55A58EF4.9020700@cs.tcd.ie> Date: Wed, 15 Jul 2015 10:23:39 +0100 X-Google-Sender-Auth: w4CIDHsbEeh9AWFcp3GAbiCB2_A Message-ID: From: Robert Cragie To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113abd6094dd3a051ae68274 Archived-At: Cc: roll-chairs@ietf.org, Routing Over Low power and Lossy networks , draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, The IESG , Yvonne-Anne Pignolet , draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-11: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 09:23:41 -0000 --001a113abd6094dd3a051ae68274 Content-Type: text/plain; charset=UTF-8 On 14 Jul 2015 23:36, "Stephen Farrell" wrote: Hi Stephen, The text before 4.1.8.2 doesn't imply that some nodes are not using security, it only implies that symmetric key scope used by nodes may be less than the whole network. I will add clarification regarding this point. Robert > > Hiya, > > On 14/07/15 23:17, Robert Cragie wrote: > > Hi Stephen, > > > > Thanks for your further review. Answers and comments inline, bracketed by > > > > > > Robert > > > > 1) This could be my ignorance of zigbee, but how can we > >> use layer 2 security for only some network nodes? (In > >> other words, I don't see how 4.1.8.2 works.) > >> > > > > All network nodes use L2 security once they have joined the network. > > Prior to that, they communicate using an authentication protocol which is > > unsecured at L2. Enforcement points police unsecured traffic to ensure it > > is only related to authentication, thus preventing data or other control > > plane traffic unsecured at L2 from being allowed into the network. So, to > > your point, the only traffic allowed unsecured at L2 is authentication > > traffic and those nodes are not yet participating in the network. > > Right, that's what I thought. So I can't see how the text that > implies that only a subset of nodes on the network are using l2 > security works which seems to be implied by the bullet just > before the start of 4.1.8.2. > > [snip] > > --001a113abd6094dd3a051ae68274 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 14 Jul 2015 23:36, "Stephen Farrell= " <s= tephen.farrell@cs.tcd.ie> wrote:

Hi Stephen,

The tex= t before 4.1.8.2 doesn't imply that some nodes are not using security, = it only implies that symmetric key scope used by nodes may be less than the= whole network. I will add clarification regarding this point.

Ro= bert


Hiya,

On 14/07/15 23:17, Robert Cragie wrote:
> Hi Stephen,
>
> Thanks for your further review. Answers and comments inline, bracketed= by
> <RCC></RCC>
>
> Robert
>
> 1) This could be my ignorance of zigbee, but how can we
>> use layer 2 security for only some network nodes?=C2=A0 (In
>> other words, I don't see how 4.1.8.2 works.)
>>
>
> <RCC>All network nodes use L2 security once they have joined the= network.
> Prior to that, they communicate using an authentication protocol which= is
> unsecured at L2. Enforcement points police unsecured traffic to ensure= it
> is only related to authentication, thus preventing data or other contr= ol
> plane traffic unsecured at L2 from being allowed into the network. So,= to
> your point, the only traffic allowed unsecured at L2 is authentication=
> traffic and those nodes are not yet participating in the network.</= RCC>

Right, that's what I thought. So I can't see how the text that
implies that only a subset of nodes on the network are using l2
security works which seems to be implied by the bullet just
before the start of 4.1.8.2.

[snip]
=C2=A0

--001a113abd6094dd3a051ae68274-- From nobody Wed Jul 15 02:52:04 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C92E1A0248; Wed, 15 Jul 2015 02:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7TSm_xjtaiB; Wed, 15 Jul 2015 02:51:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23DF1A017F; Wed, 15 Jul 2015 02:51:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EF843BE32; Wed, 15 Jul 2015 10:51:55 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3scune8pw-rz; Wed, 15 Jul 2015 10:51:55 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A3304BDF9; Wed, 15 Jul 2015 10:51:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436953915; bh=/TW20FV48PbVGZOlIwKBmPc3KSPlNioYfHLS35koJe0=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=ESVXvGk9GPwatXnUqLyQVM2q79TUKkVq9iRkyEwyz1gA8xDIzJzegk+4ISVLZEIRU D8N2Y/K7Fee76KPuOFZcpB92azBn8zjAKHEBxGDOIhPrW0zXtuH9LHP+RRGIbMokxo LxZXSTlT0FSq6d3OOZmKns4bOjpPh6kUwzJ6/s1g= Message-ID: <55A62D3B.7070002@cs.tcd.ie> Date: Wed, 15 Jul 2015 10:51:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <20150713215425.24718.94967.idtracker@ietfa.amsl.com> <55A58EF4.9020700@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, Routing Over Low power and Lossy networks , draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, draft-ietf-roll-applicability-home-building.shepherd@ietf.org, Yvonne-Anne Pignolet , The IESG Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-11: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 09:52:03 -0000 Hiya, On 15/07/15 10:23, Robert Cragie wrote: > On 14 Jul 2015 23:36, "Stephen Farrell" wrote: > > Hi Stephen, > > The text before 4.1.8.2 doesn't imply that some nodes are not using > security, it only implies that symmetric key scope used by nodes may be > less than the whole network. Well, I'm still not getting it sorry;-) Unless you mean that the n/w might accept/use >1 group symmetric key? If that's it then just saying it that way would be good. > I will add clarification regarding this point. Grand - I'm sure clarification is all that's needed. Cheers, S. > > Robert > >> >> Hiya, >> >> On 14/07/15 23:17, Robert Cragie wrote: >>> Hi Stephen, >>> >>> Thanks for your further review. Answers and comments inline, bracketed by >>> >>> >>> Robert >>> >>> 1) This could be my ignorance of zigbee, but how can we >>>> use layer 2 security for only some network nodes? (In >>>> other words, I don't see how 4.1.8.2 works.) >>>> >>> >>> All network nodes use L2 security once they have joined the network. >>> Prior to that, they communicate using an authentication protocol which is >>> unsecured at L2. Enforcement points police unsecured traffic to ensure it >>> is only related to authentication, thus preventing data or other control >>> plane traffic unsecured at L2 from being allowed into the network. So, to >>> your point, the only traffic allowed unsecured at L2 is authentication >>> traffic and those nodes are not yet participating in the network. >> >> Right, that's what I thought. So I can't see how the text that >> implies that only a subset of nodes on the network are using l2 >> security works which seems to be implied by the bullet just >> before the start of 4.1.8.2. >> >> [snip] > > >> >> > From nobody Thu Jul 16 04:11:32 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9441B39BC for ; Thu, 16 Jul 2015 04:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L8NJUW-YyL2 for ; Thu, 16 Jul 2015 04:11:30 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4127B1B39B6 for ; Thu, 16 Jul 2015 04:11:30 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so41582656lbb.1 for ; Thu, 16 Jul 2015 04:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=JcuttNo9aswFRjowTUSikykJ3vfWWcXz2+eT1W9yS9E=; b=kicohWkCfNJLa294AVlum3hQCTL1Rd2MQ1Fx8tjaVqW4MmY/33WDgPVOAiSvmFa6/c /aejSi60PjBZEM4Ugy335ScqcCeRjCmg3xnAXO0f4/etuldWbTShWggN4itaadQh3sHp zupLf0t6ipWxFAqcnE2vT2CGSwd2UwHzIWFdHPHX1jompbKAXkkXLK4z2zXrAdC8u3El 05ODoklMlcjDomR/ciW1GqsxT+A8QbQtFBNshd3N5fYGAYq1l5F6wi8jDfs1PfFPv5kq JTeEwMHK/CQ4HsJFsT3co02h3kRphZaI45s1h5IVHK3wDQJ5zcDEo09S8mYazHy1DQQ5 WLoQ== MIME-Version: 1.0 X-Received: by 10.152.88.42 with SMTP id bd10mr4780080lab.112.1437045088608; Thu, 16 Jul 2015 04:11:28 -0700 (PDT) Received: by 10.25.140.8 with HTTP; Thu, 16 Jul 2015 04:11:28 -0700 (PDT) Date: Thu, 16 Jul 2015 14:11:28 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=001a11c35098086a57051afc2271 Archived-At: Cc: Michael Richardson Subject: [Roll] Slides - IETF 93 - Available X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 11:11:31 -0000 --001a11c35098086a57051afc2271 Content-Type: text/plain; charset=UTF-8 Dear all, Please find a preliminary version of the slides. https://www.ietf.org/proceedings/93/slides/slides-93-roll-0.pdf Please let us know if something should be changed before next Tuesday. Thank you, Michael and Ines --001a11c35098086a57051afc2271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Please find a preliminary ver= sion of the slides.


Please = let us know if something should be changed before next Tuesday.
<= br>
Thank you,

Michael and Ines
--001a11c35098086a57051afc2271-- From nobody Sun Jul 19 14:33:53 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A845B1B2D82 for ; Sun, 19 Jul 2015 14:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ssa58CkkQ5M for ; Sun, 19 Jul 2015 14:33:48 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F3D1B2D6E for ; Sun, 19 Jul 2015 14:33:47 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-6e-55ac17b92a86 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EE.6F.12828.9B71CA55; Sun, 19 Jul 2015 23:33:45 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Sun, 19 Jul 2015 23:33:45 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E166E110073; Mon, 20 Jul 2015 00:33:44 +0300 (EEST) Message-ID: <55AC1842.5000000@ericsson.com> Date: Mon, 20 Jul 2015 00:36:02 +0300 From: Ines Robles User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: , Michael Richardson References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------070008010300090404030402" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje5O8TWhBmteWFn0HOpnt2i6LODA 5LFkyU8mj5Y5e5gDmKK4bFJSczLLUov07RK4Mo7dWsNa8O0dY0X7g78sDYyz9zB2MXJySAiY SHx8+4wZwhaTuHBvPVsXIxeHkMBRRombbTtZIJwNjBJzrr5gh3DWMUr0nT4A5HBw8ApoS9y+ GAzSzSKgKrG27SrYVDYBI4mzH36ygdiiAiESE9d/B7N5BQQlTs58wgJiiwjYS3xcd4AJxBYW MJDYc2kBmC0k4CvR33UArJ5TwE+idUELC8R1kRLnn/1lBFnLLBAmMWWOJkS5tsT0ufdZJjAK zkKyYRZCFUiYWcBCYub884wQtrxE89bZzBC2hkTrnLnsyOILGNlWMYoWpxYX56YbGeulFmUm Fxfn5+nlpZZsYgSG/cEtv3V3MK5+7XiIUYCDUYmHdwHL6lAh1sSy4srcQ4zSHCxK4rwzNueF CgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC0SDaKNs+eoehcNefKu4hpW9bo+ocoLjj0/BnX pY/Xf22V5BOapLanfvLb00dTblxeF37uX8SjTascZOfMyJj3MD/n00UeYYPPb06fdy9d+aGP g/Gb7//jqWen/zzdm1YrzL6uWWrygWW7UnKvXM1auTD+ko3WBlWVsL76l2o/l25jWd41Icu4 VYmlOCPRUIu5qDgRAD2glphcAgAA Archived-At: Subject: [Roll] Liaison from ITU-T SG15 to ROLL and 6Lo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 21:33:51 -0000 --------------070008010300090404030402 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Dear all, We would like to have your opinion before this friday (24 July) about this liaison "ITU-T SG15 liaison to ROLL and 6Lo". Many Thanks, Michael and Ines. Source: https://datatracker.ietf.org/liaison/1415/ ITU-T Study Group 15 has been designated as the lead study group for communications-related aspects of Smart Grid. Question 15 (Q15/15) is responsible for Recommendations ITU-T G.9903 (Narrow-band OFDM power line communication transceivers for G3-PLC networks – approved in 02/2014) and ITU-T G.9905 (Centralized Metric based Source Routing – approved in 07/2013). These two Recommendations normatively reference 6loWPAN (RFC 4944) and its header compression mechanism (RFC6282). We would like to bring to your attention that on-going discussion in IETF 6lo and ROLL WGs on reusing the ESC and MESH dispatch headers for route-over and mixed operations may lead IETF to deprecate the possibility of using RFC4944 and/or RFC6282 in pure mesh-under networks. This deprecation would create a conflict with Recommendation ITU-T G.9903 and possibly also other standards. Below we give details on how ITU-T G.9903 uses the ESC and MESH dispatch headers, confirming how important the stability of the 6LoWPAN standard and related IANA allocations are for ITU-T G.9903: 1. ITU-T G.9903 provides native mesh-under functionalities (the LOADng protocol, which is described in Annex D) while not prohibiting the use of other mesh-under (e.g. CMSR specified in ITU-T G.9905) or route-over routing protocols. If other routing protocols are used, then the native mesh-under LOADng protocol can be disabled. a. The first octet corresponds to the ESC Dispatch Header as specified in RFC 6282, i.e. 0b10 000 000. b. The second octet corresponds to the command ID. As specified in Table 9-35/G.9903, three possible commands are currently specified (additional commands can be specified to support other routing protocols): i. o LOADng command frame ii. o loWPAN bootstrapping command frame iii. o CMSR command frame (see ITU-T G.9905). c. The rest of the frame carries the payload for the relevant command frame. 2. The ESC Dispatch Header is used by ITU-T G.9903 exclusively for command frames. A command frame is built as follows (see Figure 9-12/ G.9903): 3. During the bootstrapping phase, the 6LOWPAN_IPHC and ESC headers are present in the same frame. The ESC dispatch header is placed after the 6LOWPAN_IPHC header. 4. The MESH Header as specified in RFC 4944 is used for data frames only and contains vital information for the correct delivery of G.9903 data frames when the mesh-under LOADng routing protocol is used. As of today, Japan and France have already started deployment of ITU-T G.9903 smart meters (in France smart meters will represent a total of 32 million ITU-T G.9903 smart meters – 100% national coverage − by 2021). There are also deployed wireless technologies for smart metering (e.g., based on 802.15.4) that support layer 2 mesh routing as well. Furthermore, interest in such technologies transcends smart metering applications and includes a broader set of Smart Grid applications and beyond, making ITU-T G.9903 an important enabler also for IoT applications. As several existing standards/products rely on using the Dispatch ESC Header for exchanging mesh-under routing and bootstrapping command messages, we would like to bring to your attention that deprecating this feature would have detrimental effects on Smart Grid plans of several countries and utilities: • Planned deployments would have to be delayed until a viable alternative is found, standardized, and tested in the field. This would make several utilities in the world inevitably incur high costs. • Future deployments based on the above alternative would be non-interoperable with the currently installed base of devices that rely on the availability of the Dispatch ESC Header. • Any delay would put at risk complying with deadlines set by regulators of several countries. One notable example is the 2008 Directive from the European Union which mandates EU countries to deploy 80% of smart meters by 2020. ITU encourages IETF to: • Avoid deprecation of the ESC and MESH dispatch headers and look for alternative solutions that do not create conflict with existing standards and products. • Work in cooperation with Q15/15 to find alternate solutions that do not create conflicts with ITU-T Recommendations. Q15/15 looks forward to continued cooperation with IETF. --------------070008010300090404030402 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Dear all,

We would like to have your opinion before this friday (24 July) about this liaison "ITU-T SG15 liaison to ROLL and 6Lo".

Many Thanks,

Michael and Ines.

Source: https://datatracker.ietf.org/liaison/1415/

ITU-T Study Group 15 has been designated as the lead study group for

communications-related aspects of Smart Grid. Question 15 (Q15/15) is

responsible for Recommendations ITU-T G.9903 (Narrow-band OFDM power line

communication transceivers for G3-PLC networks – approved in 02/2014) and

ITU-T G.9905 (Centralized Metric based Source Routing – approved in 07/2013).

These two Recommendations normatively reference 6loWPAN (RFC 4944) and its

header compression mechanism (RFC6282).

 

We would like to bring to your attention that on-going discussion in IETF 6lo

and ROLL WGs on reusing the ESC and MESH dispatch headers for route-over and

mixed operations may lead IETF to deprecate the possibility of using RFC4944

and/or RFC6282 in pure mesh-under networks. This deprecation would create a

conflict with Recommendation ITU-T G.9903 and possibly also other standards.

 

Below we give details on how ITU-T G.9903 uses the ESC and MESH dispatch

headers, confirming how important the stability of the 6LoWPAN standard and

related IANA allocations are for ITU-T G.9903:

 

1.      ITU-T G.9903 provides native mesh-under functionalities (the LOADng

protocol, which is described in Annex D) while not prohibiting the use of

other mesh-under (e.g. CMSR specified in ITU-T G.9905) or route-over routing

protocols. If other routing protocols are used, then the native mesh-under

LOADng protocol can be disabled.

a.      The first octet corresponds to the ESC Dispatch Header as specified in RFC

6282, i.e. 0b10 000 000.

b.      The second octet corresponds to the command ID. As specified in Table

9-35/G.9903, three possible commands are currently specified (additional

commands can be specified to support other routing protocols):

i.      o LOADng command frame

ii.     o loWPAN bootstrapping command frame

iii.    o CMSR command frame (see ITU-T G.9905).

 

c.      The rest of the frame carries the payload for the relevant command frame.

 

 

2.      The ESC Dispatch Header is used by ITU-T G.9903 exclusively for command

frames. A command frame is built as follows (see Figure 9-12/ G.9903):

 

3.      During the bootstrapping phase, the 6LOWPAN_IPHC and ESC headers are

present in the same frame. The ESC dispatch header is placed after the

6LOWPAN_IPHC header.

4.      The MESH Header as specified in RFC 4944 is used for data frames only and

contains vital information for the correct delivery of G.9903 data frames when

the mesh-under LOADng routing protocol is used.

 

As of today, Japan and France have already started deployment of ITU-T G.9903

smart meters (in France smart meters will represent a total of 32 million

ITU-T G.9903 smart meters – 100% national coverage − by 2021). There are also

deployed wireless technologies for smart metering (e.g., based on 802.15.4)

that support layer 2 mesh routing as well. Furthermore, interest in such

technologies transcends smart metering applications and includes a broader set

of Smart Grid applications and beyond, making ITU-T G.9903 an important

enabler also for IoT applications.

 

As several existing standards/products rely on using the Dispatch ESC Header

for exchanging mesh-under routing and bootstrapping command messages, we would

like to bring to your attention that deprecating this feature would have

detrimental effects on Smart Grid plans of several countries and utilities:

•       Planned deployments would have to be delayed until a viable alternative is

found, standardized, and tested in the field. This would make several

utilities in the world inevitably incur high costs.

•       Future deployments based on the above alternative would be non-interoperable

with the currently installed base of devices that rely on the availability of

the Dispatch ESC Header.

•       Any delay would put at risk complying with deadlines set by regulators of

several countries. One notable example is the 2008 Directive from the European

Union which mandates EU countries to deploy 80% of smart meters by 2020.

ITU encourages IETF to:

•       Avoid deprecation of the ESC and MESH dispatch headers and look for

alternative solutions that do not create conflict with existing standards and

products.

•       Work in cooperation with Q15/15 to find alternate solutions that do not

create conflicts with ITU-T Recommendations.

Q15/15 looks forward to continued cooperation with IETF.

 

 

 


--------------070008010300090404030402-- From nobody Sun Jul 19 15:56:24 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18291B2DFE for ; Sun, 19 Jul 2015 15:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIXa5GyAr6AL for ; Sun, 19 Jul 2015 15:56:21 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468E81AD362 for ; Sun, 19 Jul 2015 15:56:21 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so86039435lbb.1 for ; Sun, 19 Jul 2015 15:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NLn4vSZmSgrWBjLkxMwpLMvUx8roXguQBaDAyagWfc0=; b=vgkb+4fN20Tv/CcJaAx8eZxkxD8Yg4rort3MT5LrcauekRnLVuYOcYK8lKfw8150BQ 7/WnsF7DDRaZ1aRUz2JFzWe/HBqqDIRPDurlWBIPhatdRU7VC1tfgggMnNcjzR3tu/S5 10KPw0KEkkz0siSEUOoO9iF4s/bnfvuQjltAFUbOsyDLPe9/PjhQLD5fdiXd/by3vRIo s3GR8qeLqLFd5YRev68kYoZ+VC88UBWAmSrU3yZ+6xGxWlYdtwIPyrd0EhxIVelu88Cd 7dz43HN0mqB4Blznl5RgPzQwO4q8HFsXxHxJsRVw8hCvBNnh/m/XIidyi5rqXI3AdJBw 4opA== MIME-Version: 1.0 X-Received: by 10.112.73.33 with SMTP id i1mr25284059lbv.31.1437346579778; Sun, 19 Jul 2015 15:56:19 -0700 (PDT) Received: by 10.25.140.8 with HTTP; Sun, 19 Jul 2015 15:56:19 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2015 01:56:19 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=001a11c33c024e94e6051b4254da Archived-At: Cc: Michael Richardson Subject: Re: [Roll] Slides - IETF 93 - Available X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 22:56:22 -0000 --001a11c33c024e94e6051b4254da Content-Type: text/plain; charset=UTF-8 Dear all, Please find an updated version of the slides https://www.ietf.org/proceedings/93/slides/slides-93-roll-2.pdf Thanks, Michael and Ines 2015-07-16 14:11 GMT+03:00 Ines Robles : > Dear all, > > Please find a preliminary version of the slides. > > https://www.ietf.org/proceedings/93/slides/slides-93-roll-0.pdf > > Please let us know if something should be changed before next Tuesday. > > Thank you, > > Michael and Ines > --001a11c33c024e94e6051b4254da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Please find an updated versio= n of the slides


Thanks,

Michael and Ines

2015-07-16 14:11 GMT+03:00 Ines Robles <mariainesrobles@googlemail.com>:
Dear all,

Please fin= d a preliminary version of the slides.


Please let us know if something should be cha= nged before next Tuesday.

Thank you,
Michael and Ines

--001a11c33c024e94e6051b4254da-- From nobody Tue Jul 21 03:06:26 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D691A6F2A; Tue, 21 Jul 2015 03:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwyjvFL1gqyX; Tue, 21 Jul 2015 03:06:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 476641A6F33; Tue, 21 Jul 2015 03:06:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150721100617.12889.98784.idtracker@ietfa.amsl.com> Date: Tue, 21 Jul 2015 03:06:17 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-12.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 10:06:23 -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 Working Group of the IETF. Title : Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control Authors : Anders Brandt Emmanuel Baccelli Robert Cragie Peter van der Stok Filename : draft-ietf-roll-applicability-home-building-12.txt Pages : 37 Date : 2015-07-21 Abstract: The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 21 03:09:48 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8521A6F2B; Tue, 21 Jul 2015 03:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apNU0Vu6P5_2; Tue, 21 Jul 2015 03:09:43 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF02D1A6F2A; Tue, 21 Jul 2015 03:09:42 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.215]) by smtp-cloud3.xs4all.net with ESMTP id uy9g1q0094eRkWy01y9gHh; Tue, 21 Jul 2015 12:09:40 +0200 Received: from [2001:67c:370:136:e5:cbd4:6866:71e6] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 21 Jul 2015 12:09:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 Jul 2015 12:09:40 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <55A58EF4.9020700@cs.tcd.ie> References: <20150713215425.24718.94967.idtracker@ietfa.amsl.com> <55A58EF4.9020700@cs.tcd.ie> Message-ID: X-Sender: stokcons@xs4all.nl (SujF2ahLYV0vbiRlB0yOI7M3HjHb/pSq) User-Agent: XS4ALL Webmail Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building.shepherd@ietf.org, Yvonne-Anne Pignolet , draft-ietf-roll-applicability-home-building@ietf.org Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-11: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 10:09:47 -0000 Hi Stephen, We have submitted a new version 12 of the applicability draft with text as discussed below. Many thanks for your comments and thoughts. Looking forward to your comments, Greetings, Robert and Peter ________________________________________________________________________________________________________________ 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 Working Group of the IETF. Title : Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control Authors : Anders Brandt Emmanuel Baccelli Robert Cragie Peter van der Stok Filename : draft-ietf-roll-applicability-home-building-12.txt Pages : 37 Date : 2015-07-21 Abstract: The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _____________________________________________ Stephen Farrell schreef op 2015-07-15 00:36: > Hiya, > > On 14/07/15 23:17, Robert Cragie wrote: >> Hi Stephen, >> >> Thanks for your further review. Answers and comments inline, bracketed >> by >> >> >> Robert >> >> 1) This could be my ignorance of zigbee, but how can we >>> use layer 2 security for only some network nodes? (In >>> other words, I don't see how 4.1.8.2 works.) >>> >> >> All network nodes use L2 security once they have joined the >> network. >> Prior to that, they communicate using an authentication protocol which >> is >> unsecured at L2. Enforcement points police unsecured traffic to ensure >> it >> is only related to authentication, thus preventing data or other >> control >> plane traffic unsecured at L2 from being allowed into the network. So, >> to >> your point, the only traffic allowed unsecured at L2 is authentication >> traffic and those nodes are not yet participating in the >> network. > > Right, that's what I thought. So I can't see how the text that > implies that only a subset of nodes on the network are using l2 > security works which seems to be implied by the bullet just > before the start of 4.1.8.2. > > All the stuff below is fine, so we're just down to the above in > terms of clearing the discuss. > > Cheers, > S. > >> >>> >>> 2) Just checking - this depends on the zigbeeip >>> authentication mechanism, with which I'm also not >>> familiar, sorry. Does using that mean that this entire >>> applicability statement only covers use of RPL where >>> zigbee radios are in use? Or can that authentication >>> scheme be used independently of the radio technology >>> used? (I mean used in practice there, not in theory.) >>> >> >> The authentication scheme is independent of the radio technology >> as it >> is based on UDP/IP and therefore could be use with a number of >> different >> radio technologies or indeed other MAC/PHY technologies >> >> - 4.1.8: "MUST be present" is ambiguous - do you mean >>> it must be used? I think you do. >>> >> >> Yes >> >> - 4.1.8: "MUST be distributed or established in a >>> secure fashion" isn't really a protocol requirement. >>> Do you really just mean "see 4.1.8.1" ? >>> >> >> Yes. It was meant more as an introductory statement but is >> redundant >> really >> >> OLD COMMENTS FOR -10 below, I didn't check if you'd made >>> any related changes. >>> >> >> These seem to apply more to -09. Some of these were fixed in -10, >> some >> in -11 >> >> >>> - I don't get how there's an IPR disclosure for this, but >>> whatever. >>> >> >> Not from me, so I can't comment on that >> >> - The non-security parts of this were quite a good read. >>> >>> - 4.1.8: 1st sentence makes no sense. It says RPL does X or >>> not-X in order to Y. There is no choice but for RPL to do X or >>> not-X. >>> >>> - 4.1.8 seems to me to imply that link layer security is >>> always needed since there can always be some node that will >>> send an unsecured RPL messsage. If you agree, then I think >>> that should be made more clear. If you disagree, I'd like to >>> understand how. >>> >>> - 4.1.8, I am surprised not to see a recommendation that >>> separate group keys SHOULD be used for different applications >>> in the same bulding network. But that may be too fine grained >>> a recommendation for this document perhaps. >>> >> >> No longer applicable as 4.1.8 has been completely >> rewritten. >> >> >>> >>> - 5.1.2.1, I think it'd be clearer to say Imin should be >>> between 10 and 50 ms. The "10 - 50 ms" notation can be >>> confusing. (Same elsewhere.) >>> >> >> Used "to" instead of "-" >> >>> >>> - section 7, 3rd para, "can rely on" is sales language, please >>> strike that or s/rely on/depend upon/ >>> >>> - section 7, 3rd para, last sentence: this is sales language >>> and should be deleted. Or perhaps s/is/SHOULD be/ would turn >>> it back into a piece of specification language. >>> >> >> Paragraph has been rewritten >> >>> >>> - 7.1 - this is odd text to see in a proposed standard, but I >>> think it's accurately describing the level of interop to >>> expect in RPL security, so is probably the right thing to say. >>> I'd argue that it'd be even better to bluntly admit/say that >>> there is currently no interoperable automated key management >>> for RPL. (Same for 7.3) Or, and better, to fix that lack. (See >>> my discuss point.) >>> >> >> Section has been rewritten >> >>> >>> - 7.2, 1st sentence: this is meaningless as I read it - what >>> are you trying to say? >>> >> >> Section has been rewritten >> >>> >>> - 7.2, when a node is stolen, the chances are that any keys >>> contained in the node are at significant risk of being leaked. >>> >> >> The text has been changed but probably doesn't meet your >> requirements >> regarding this point. I would say nodes have to be re-keyed at L2 and >> MAY >> need to have additional measures taken depending on the other >> credentials >> they have and how the confidential information is stored. e.g. >> certificate >> revocation.. >> >>> >>> - 7.3, I do not believe that [I-D.keoh-dice-multicast-security] >>> is necessarily going to proceed via the DICE WG. Depending >>> on it would be fairly high-risk in any case. >>> >> >> Has been removed >> >>> >>> - 7.4, last sentence: more sales talk >>> >> >> I'm not sure we even need a section on MPL; MPL has nothing to do >> with >> RPL. Assuming we do, this is still outstanding, so I suggest replacing >> "The >> application of security measures for the specification of the >> multicast >> addresses assures that the routing of MPL packets is secured." with >> something like "For secure dissemination of MPL packets, layer 2 >> security >> SHOULD be used and the configuration of multicast addresses MUST be >> secure." >> >>> >>> - 7.5, what is this specifying? I don't get it. Does 7416 set >>> out what to implement to get interop? (I didn't think so, but >>> nor does this seem to.) >>> >> >> This is still outstanding. I think it is OK to briefly highlight >> the >> steps being taken to mitigate against the threats outlined in RFC >> 7416. The >> statement "Key management discussed in section 7.4, "Key Management" >> of >> [RFC7416], is not standardized and discussions continue." is now not >> relevant as there is now a proposal in this document. I will work with >> Peter to produce some new text on this. >> >> >> >> _______________________________________________ >> 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 From nobody Tue Jul 21 07:17:20 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635D41A8857 for ; Tue, 21 Jul 2015 07:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NuqNhoQ9XGT for ; Tue, 21 Jul 2015 07:17:18 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897701A8859 for ; Tue, 21 Jul 2015 07:17:17 -0700 (PDT) Received: by lahh5 with SMTP id h5so118759741lah.2 for ; Tue, 21 Jul 2015 07:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=44K+r9NTIHgp+4qdP75kluOrxKTgZ4nlgM6h01l643w=; b=rjz3uiGDIKCkLNtsM3kssniHLn69MgIXlF6TxuTaklV/rPGzloUhewGnps2zMFa+69 rUrthqITRCsmjiSJo0YNxurnSVWl8I2+R8mdJ4aqD2TBbXbQ93prt1VNQ4uCjQvZMRPW sNo2q0JisNWycg+CBeNmGalUtQDM80418VvEARupvOXvA+luTzAqQDtMi6f0wHNYe0kc LBjESem1dDjRqvppXNlUqb21k98V17C8Gaw+Vm8Yl7jCmhwU9x93hk3PsC8txX4wMzPx CLaZcgusa/wNVPQZt5Y64Pipm2qshJ11BJt+f4YWtWUj93ItOt87Rm8HdkalFwRz3Yz2 NAGw== MIME-Version: 1.0 X-Received: by 10.112.142.232 with SMTP id rz8mr32274842lbb.74.1437488236145; Tue, 21 Jul 2015 07:17:16 -0700 (PDT) Received: by 10.25.140.8 with HTTP; Tue, 21 Jul 2015 07:17:16 -0700 (PDT) Date: Tue, 21 Jul 2015 17:17:16 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=089e0112cdfeaf322f051b634fb8 Archived-At: Subject: [Roll] Final version of slides - IETF 93 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:17:19 -0000 --089e0112cdfeaf322f051b634fb8 Content-Type: text/plain; charset=UTF-8 Hi, Please find the final version of slides for today https://www.ietf.org/proceedings/93/slides/slides-93-roll-3.pdf Thanks, Michael and Ines. --089e0112cdfeaf322f051b634fb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find the final version of sl= ides for today


Thanks,

Michael and Ines.
--089e0112cdfeaf322f051b634fb8-- From nobody Tue Jul 21 08:16:35 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C0E1B2F35 for ; Tue, 21 Jul 2015 08:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_c3vH0GEPdS for ; Tue, 21 Jul 2015 08:16:32 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (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 64F7D1B2F21 for ; Tue, 21 Jul 2015 08:16:30 -0700 (PDT) Received: by wgkl9 with SMTP id l9so159200083wgk.1 for ; Tue, 21 Jul 2015 08:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=Yrv8+Ymji1lowyObGZEoKMcUKjuisUm7tJXCuJ9QvAU=; b=P9FZsXHsKsHY1YtNhhl8jqbuaqDcpGwoknGxhJ9w1IImzhS0YE3XcVpB+n+YKsFGvS IdaUOuI+h/aorDHTwvlwhM+lb2UY4P29ILdPIaLugMA/7dyV/EHiLOezoDYNrzkbGs33 qwgB3445t90/M7D7mRgRbk9xFQQ29pLk/0b16e2gnIGrp8XLUsQ62nRKKDenhV41kaM/ +qPR7UfZceqwwALRndnhfh0z3FqxR5UGPwvBlekCtImaWfZ5caC3MzxgssEfepILHxXq zWKg//QOqODQZtrko43aMNcpvPnJjZ1pSO3ktPc5rV7YltA4ZhqaaXfKPvsR7ItN+pqu wqeQ== X-Received: by 10.180.72.35 with SMTP id a3mr31388220wiv.21.1437491789172; Tue, 21 Jul 2015 08:16:29 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.28.37.7 with HTTP; Tue, 21 Jul 2015 08:16:09 -0700 (PDT) From: Thomas Watteyne Date: Tue, 21 Jul 2015 17:16:09 +0200 X-Google-Sender-Auth: Wk2TsF-iuM2jjAQZSfgpKeNZlCw Message-ID: To: IETF ROLL Content-Type: multipart/alternative; boundary=001a11c2403e76156f051b6423fb Archived-At: Subject: [Roll] Etherpad for ROLL meeting. Second minute taker, please. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 15:16:33 -0000 --001a11c2403e76156f051b6423fb Content-Type: text/plain; charset=UTF-8 I was asked to take minutes for the ROLL WG meeting in 25min. I plan to take notes at http://etherpad.tools.ietf.org:9000/p/notes-ietf-93-roll, and would appreciate help from at least one other person. If you can help, please enter your name to the upper right hand corner of the Etherpad. Thomas --001a11c2403e76156f051b6423fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was asked to take minutes for the ROLL WG meeting in 25m= in.

I plan to take notes at http://etherpad.= tools.ietf.org:9000/p/notes-ietf-93-roll, and would appreciate help fro= m at least one other person.

If you can help, plea= se enter your name to the upper right hand corner of the Etherpad.

Thomas
--001a11c2403e76156f051b6423fb-- From nobody Tue Jul 21 08:29:15 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3179D1A8A05 for ; Tue, 21 Jul 2015 08:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdP_1zkfvYUq for ; Tue, 21 Jul 2015 08:29:12 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94ECD1A89F9 for ; Tue, 21 Jul 2015 08:29:11 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so38046812lbb.3 for ; Tue, 21 Jul 2015 08:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kM3oRDeLmYcjY2Ryo245WGIw6/T2mz6iV4diSoZiuIs=; b=HPtfF00kAEvfStJM+l5YmijReXqjBxhyBWVkpDz0SR/RWFJoQTxJcDvTOKgTqEkddc cBHJQV9pLfJDzSpqJLjY7CaapyV1tlhtDYLa86MSAHqxHBFuMlcn2yy+n7CMCpmhrjVl NwOtEwBSyPPet3A/qrXANac2OodSiaI5qcBp2PMAiiF9c6RbP/Amu1xSPkuwn5ZySNv3 35qhuvHlAK4F7FvgDyfc5zFChGW+BFK0vxprrxY2o3ZlV0TCPGPkzPNvB8vaSAfdYs3z wBVGgtyIvXQuxkA5HDkWHTIUTHzS2G/G0EJN9Eoj9BpPfv+7YgsDCL8/HI3byrdj8O4c xz9w== MIME-Version: 1.0 X-Received: by 10.152.25.228 with SMTP id f4mr1711832lag.112.1437492550155; Tue, 21 Jul 2015 08:29:10 -0700 (PDT) Received: by 10.25.140.8 with HTTP; Tue, 21 Jul 2015 08:29:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Jul 2015 18:29:10 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=089e0158af84d1c3b4051b6450de Archived-At: Subject: Re: [Roll] Final version of slides - IETF 93 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 15:29:13 -0000 --089e0158af84d1c3b4051b6450de Content-Type: text/plain; charset=UTF-8 Few updates https://www.ietf.org/proceedings/93/slides/slides-93-roll-5.pdf 2015-07-21 17:17 GMT+03:00 Ines Robles : > Hi, > > Please find the final version of slides for today > > https://www.ietf.org/proceedings/93/slides/slides-93-roll-3.pdf > > Thanks, > > Michael and Ines. > --089e0158af84d1c3b4051b6450de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2015-07-21 17:17 GMT+03:00 Ines Ro= bles <mariainesrobles@googlemail.com>:
Hi,

Please fi= nd the final version of slides for today


Thanks,

Michael = and Ines.

--089e0158af84d1c3b4051b6450de-- From nobody Tue Jul 21 09:05:29 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E8E1A8AC8 for ; Tue, 21 Jul 2015 09:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 121_vtpL4hXo for ; Tue, 21 Jul 2015 09:05:27 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0BE1A898F for ; Tue, 21 Jul 2015 09:05:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LG5OVZ007339; Tue, 21 Jul 2015 18:05:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B2E03202355; Tue, 21 Jul 2015 18:08:58 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9D05420228D; Tue, 21 Jul 2015 18:08:58 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LG5NRt027409; Tue, 21 Jul 2015 18:05:24 +0200 To: ROLL WG From: Alexandru Petrescu Message-ID: <55AE6DC2.1080500@gmail.com> Date: Tue, 21 Jul 2015 18:05:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Roll] what is the value for the IPv6 Base Header in IANA registry? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:05:28 -0000 Whaty is the value for the IPv6 Base Header in the IANA Registry? http://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml Alex From nobody Tue Jul 21 09:06:59 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CC01B2F87 for ; Tue, 21 Jul 2015 09:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esTHFN1aHADE for ; Tue, 21 Jul 2015 09:06:57 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 3E2341A8BBF for ; Tue, 21 Jul 2015 09:06:57 -0700 (PDT) Received: by ykax123 with SMTP id x123so170033151yka.1 for ; Tue, 21 Jul 2015 09:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2wTlOaCIj6GrmT5iNE29IZfw+2Snq7yq2VtaehZbLgw=; b=H8e7FHyW7C5M+5AZmjAz0EKmhCVYnf7fu6AaOVjrPP8sO7yzmuAkOkdyDD3fb/DO9i gfc8mbuI/qGzIH80f0DMyjMkUdM0nr+ot/3FEayGdzFUDGJGd7hNRgRLDIsbWc3zpCzf FlCYLEyv31XLNlba6zr+3GhwbREnp1qvGaMnI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2wTlOaCIj6GrmT5iNE29IZfw+2Snq7yq2VtaehZbLgw=; b=Qh4TiXPT2z+p+0pd/Kc2ULSZx1Lt5D2W2SJZpxwrKsYe8l/5N/WHEc4/NTlqOU6iTr vZol1ipYDZFg/LK8BnzdUeazEC+qfDq9Vg6+ai1dOq2BNMl9+w+s5DuBsmTp6SscTgxs krk21/Lw48pxs0uQ6RFBdg8LsDvg3TDwr2PAbgjknGGKXHwLM0gLG+CX56eAEAkWPDXf rifnk5X/jR+b56t73jLVmHk2ngVjvXyCHWDPMkQ/QYvKlNmin11fWabNz8GC8NcCgg+K EepnF3R4POFauxMLtSQQ25rhZJUUzbm4BOmYfdAQEADf92k0MO/ECzBvLq17JjmYu46J Jc8g== X-Gm-Message-State: ALoCoQk0+c1zHSHDLGA+5QxPJFPGLbbHrKZuIAtRHfVAKrFkp9tfBpjHdMKeDi33RHixthMyNMti MIME-Version: 1.0 X-Received: by 10.129.77.213 with SMTP id a204mr35346022ywb.40.1437494816586; Tue, 21 Jul 2015 09:06:56 -0700 (PDT) Received: by 10.37.207.75 with HTTP; Tue, 21 Jul 2015 09:06:56 -0700 (PDT) In-Reply-To: <55AE6DC2.1080500@gmail.com> References: <55AE6DC2.1080500@gmail.com> Date: Tue, 21 Jul 2015 09:06:56 -0700 Message-ID: From: Jonathan Hui To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001a1140c552e8f4dd051b64d755 Archived-At: Cc: ROLL WG Subject: Re: [Roll] what is the value for the IPv6 Base Header in IANA registry? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:06:58 -0000 --001a1140c552e8f4dd051b64d755 Content-Type: text/plain; charset=UTF-8 01 000001 IPv6 - uncompressed IPv6 Addresses [RFC4944] The code point as defined in RFC 4944: IPv6: Specifies that the following header is an uncompressed IPv6 header [RFC2460]. -- Jonathan Hui On Tue, Jul 21, 2015 at 9:05 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Whaty is the value for the IPv6 Base Header in the IANA Registry? > > > http://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml > > Alex > > --001a1140c552e8f4dd051b64d755 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
01 000001 IPv6 - uncompressed IPv6 Addresses [RFC4944]

The code point as defined in R= FC 4944:

=C2=A0 =C2=A0IPv6: =C2=A0Specifies that t= he following header is an uncompressed IPv6
=C2=A0 =C2=A0 =C2=A0 = header [RFC2460].

--
Jonathan Hui
<= div>

On Tue, Jul 21, 2015 at 9:05 AM, Alexandru Petrescu &l= t;alexand= ru.petrescu@gmail.com> wrote:
Whaty is the value for the IPv6 Base Header in the IANA Registry?

http://www.iana.org/ass= ignments/_6lowpan-parameters/_6lowpan-parameters.xhtml

Alex


--001a1140c552e8f4dd051b64d755-- From nobody Tue Jul 21 09:17:51 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAACF1A8AAB for ; Tue, 21 Jul 2015 09:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rafm0DhrkG-v for ; Tue, 21 Jul 2015 09:17:48 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF8C1B2FA8 for ; Tue, 21 Jul 2015 09:17:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LGHiqt031519; Tue, 21 Jul 2015 18:17:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 24058200CCD; Tue, 21 Jul 2015 18:21:18 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0D51520251D; Tue, 21 Jul 2015 18:21:18 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LGHgKO002697; Tue, 21 Jul 2015 18:17:43 +0200 To: Jonathan Hui References: <55AE6DC2.1080500@gmail.com> From: Alexandru Petrescu Message-ID: <55AE70A6.9040705@gmail.com> Date: Tue, 21 Jul 2015 18:17:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ROLL WG Subject: Re: [Roll] what is the value for the IPv6 Base Header in IANA registry? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:17:50 -0000 I dont understand. The entry says: 01 000001 - IPv6 - uncompressed IPv6 Addresses - RFC4944 I am asking for an "IPv6 Header" [RFC2460], not "IPv6 - uncompressed IPv6 Addresses". Maybe it's just a matter of terminology. Alex Le 21/07/2015 18:06, Jonathan Hui a écrit : > 01 000001IPv6 - uncompressed IPv6 Addresses[RFC4944] > > The code point as defined in RFC 4944: > > IPv6: Specifies that the following header is an uncompressed IPv6 > header [RFC2460]. > > -- > Jonathan Hui > > > On Tue, Jul 21, 2015 at 9:05 AM, Alexandru Petrescu > > wrote: > > Whaty is the value for the IPv6 Base Header in the IANA Registry? > > http://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml > > Alex > > From nobody Tue Jul 21 09:23:23 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9651B29C9 for ; Tue, 21 Jul 2015 09:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG0_G5ofbEes for ; Tue, 21 Jul 2015 09:23:14 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (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 8C5A71A9034 for ; Tue, 21 Jul 2015 09:23:14 -0700 (PDT) Received: by ykax123 with SMTP id x123so170455739yka.1 for ; Tue, 21 Jul 2015 09:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wllXJ3MTJvninljN1uP4SgfKxVN4u5DP46EKeV5dE+U=; b=jJFX0BT+1NnzxgpUIbnGYlbUP+kl2Ssi9zZxN4ZIdh/46gEXS0lxwj2G+OaszlvmNo CXT7sBtdrgOuhZerUR0Le/Kf4GSP52q7wMNu4C5SdG6ZxBevy0mr32oPIoxnOpHj5s9R mwfcK4W8R+VMw/IeGB24s0Dlk7ggbz6Azf3Pg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wllXJ3MTJvninljN1uP4SgfKxVN4u5DP46EKeV5dE+U=; b=htnCYd93eeWL3EEPRbXZE0JSbpFhXZA5R+EMNkab3slWmfw4TYzbfvFG2UyUU4+JoM pfXhhODOVC5qTrTSBtq8WFX+in1wRmJ5PSjFwIOSen+mf6kiyps6z94h1h5y3+apJ3jH gLvXxoe6d9shskK3uZzqD6lSocTT6reMSH3jL6BkEf5wDfYM/ADRNMc1JwZHG9Yqhp6m 0pUXbKA2MCyKYlBRzQlElyL/nw4BZ/QH8GQpmbNeqJy8wwGli9evlkJ2hTeU+Gu9M5mU 6D7orbc+jUNDlScqeks07g13Sah7D7goNlNL1vlRmZ53phSAo7+Hy7AyY58iadOItR7s r/iA== X-Gm-Message-State: ALoCoQlADxLyQtbdcK2ao7K9CPViOgFujRWxA0szVoS/POB54AFAtIjcAEH3/qmpgh81tW1sX+Lq MIME-Version: 1.0 X-Received: by 10.170.229.133 with SMTP id v127mr34459153ykf.97.1437495793856; Tue, 21 Jul 2015 09:23:13 -0700 (PDT) Received: by 10.37.207.75 with HTTP; Tue, 21 Jul 2015 09:23:13 -0700 (PDT) In-Reply-To: <55AE70A6.9040705@gmail.com> References: <55AE6DC2.1080500@gmail.com> <55AE70A6.9040705@gmail.com> Date: Tue, 21 Jul 2015 09:23:13 -0700 Message-ID: From: Jonathan Hui To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001a113bbab828f092051b6512a2 Archived-At: Cc: ROLL WG Subject: Re: [Roll] what is the value for the IPv6 Base Header in IANA registry? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:23:16 -0000 --001a113bbab828f092051b6512a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The Header Type Name is what it is and probably could be improved. RFC 4944 normatively references RFC 2460 for that code point, so it should be clear enough. -- Jonathan Hui On Tue, Jul 21, 2015 at 9:17 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > I dont understand. > > The entry says: > 01 000001 - IPv6 - uncompressed IPv6 Addresses - RFC4944 > > I am asking for an "IPv6 Header" [RFC2460], not "IPv6 - uncompressed IPv6 > Addresses". > > Maybe it's just a matter of terminology. > > Alex > > Le 21/07/2015 18:06, Jonathan Hui a =C3=A9crit : > >> 01 000001IPv6 - uncompressed IPv6 Addresses[RFC4944] >> >> The code point as defined in RFC 4944: >> >> IPv6: Specifies that the following header is an uncompressed IPv6 >> header [RFC2460]. >> >> -- >> Jonathan Hui >> >> >> On Tue, Jul 21, 2015 at 9:05 AM, Alexandru Petrescu >> > >> wrote: >> >> Whaty is the value for the IPv6 Base Header in the IANA Registry? >> >> >> http://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.= xhtml >> >> Alex >> >> >> > --001a113bbab828f092051b6512a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The Header Type Name is what it is and probably could be i= mproved.

RFC 4944 normatively references RFC 2460 for th= at code point, so it should be clear enough.

--
Jonathan Hui

On Tue, Jul 21, 2015 at 9:17 AM, Alexandru Petrescu <a= lexandru.petrescu@gmail.com> wrote:
I dont understand.

The entry says:
01 000001 - IPv6 - uncompressed IPv6 Addresses - RFC4944

I am asking for an "IPv6 Header" [RFC2460], not "IPv6 - unco= mpressed IPv6 Addresses".

Maybe it's just a matter of terminology.

Alex

Le 21/07/2015 18:06, Jonathan Hui a =C3=A9crit :
01 000001IPv6 - uncompressed IPv6 Addresses[RFC4944]

The code point as defined in RFC 4944:

=C2=A0 =C2=A0 IPv6:=C2=A0 Specifies that the following header is an uncompr= essed IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0header [RFC2460].

--
Jonathan Hui


On Tue, Jul 21, 2015 at 9:05 AM, Alexandru Petrescu
 <alexa= ndru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>> wrot= e:

=C2=A0 =C2=A0 Whaty is the value for the IPv6 Base Header in the IANA Regis= try?

=C2=A0 =C2=A0 http://ww= w.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml
=C2=A0 =C2=A0 Alex




--001a113bbab828f092051b6512a2-- From nobody Tue Jul 21 09:28:46 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9725D1B2FB8 for ; Tue, 21 Jul 2015 09:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYspfIdA_AQX for ; Tue, 21 Jul 2015 09:28:44 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92B31B2F8B for ; Tue, 21 Jul 2015 09:28:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LGSf8x013046; Tue, 21 Jul 2015 18:28:41 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D3BF220242A; Tue, 21 Jul 2015 18:32:15 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C87D22010E6; Tue, 21 Jul 2015 18:32:15 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LGSeO9009460; Tue, 21 Jul 2015 18:28:41 +0200 To: Jonathan Hui References: <55AE6DC2.1080500@gmail.com> <55AE70A6.9040705@gmail.com> From: Alexandru Petrescu Message-ID: <55AE7338.7000801@gmail.com> Date: Tue, 21 Jul 2015 18:28:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ROLL WG Subject: Re: [Roll] what is the value for the IPv6 Base Header in IANA registry? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:28:45 -0000 Le 21/07/2015 18:23, Jonathan Hui a écrit : > The Header Type Name is what it is and probably could be improved. I suggest we request modification to the IANA registry to clarify that is a Header, and not addresses. > RFC 4944 normatively references RFC 2460 for that code point, so it > should be clear enough. No, it is not clear enough. Because RFC494 has two types in it, and only one of them is the IPv6 Header (the other is lowpan). This is ambiguous. Alex > > -- > Jonathan Hui > > On Tue, Jul 21, 2015 at 9:17 AM, Alexandru Petrescu > > wrote: > > I dont understand. > > The entry says: > 01 000001 - IPv6 - uncompressed IPv6 Addresses - RFC4944 > > I am asking for an "IPv6 Header" [RFC2460], not "IPv6 - uncompressed > IPv6 Addresses". > > Maybe it's just a matter of terminology. > > Alex > > Le 21/07/2015 18:06, Jonathan Hui a écrit : > > 01 000001IPv6 - uncompressed IPv6 Addresses[RFC4944] > > The code point as defined in RFC 4944: > > IPv6: Specifies that the following header is an > uncompressed IPv6 > header [RFC2460]. > > -- > Jonathan Hui > > > On Tue, Jul 21, 2015 at 9:05 AM, Alexandru Petrescu > > >> wrote: > > Whaty is the value for the IPv6 Base Header in the IANA > Registry? > > http://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml > > Alex > > > > From nobody Wed Jul 22 09:54:19 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C468D1A8AF0 for ; Wed, 22 Jul 2015 09:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hB6t4jkYIgjK for ; Wed, 22 Jul 2015 09:54:16 -0700 (PDT) Received: from smtpdg4.aruba.it (smtpweb131.aruba.it [62.149.158.131]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFC51A8A9A for ; Wed, 22 Jul 2015 09:54:16 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd04.ad.aruba.it with bizsmtp id vUtk1q00H2NEPrz01Utmpc; Wed, 22 Jul 2015 18:53:46 +0200 Date: Wed, 22 Jul 2015 18:53:46 +0200 (CEST) From: Meetecho Team To: roll@ietf.org Message-ID: <1315968767.1.1437584026226.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_1756201167.1437584026186" Archived-At: Subject: [Roll] Meetecho recordings of ROLL WG session X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:54:17 -0000 ------=_Part_0_1756201167.1437584026186 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the ROLL WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#ROLL In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_0_1756201167.1437584026186-- From nobody Sat Jul 25 07:08:44 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F1B1B3109; Sat, 25 Jul 2015 07:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHZGANf7EeuN; Sat, 25 Jul 2015 07:08:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D461B3104; Sat, 25 Jul 2015 07:08:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> Date: Sat, 25 Jul 2015 07:08:40 -0700 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-home-building-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 14:08:42 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-roll-applicability-home-building-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the discussion about security. I didn't check if the comments below were handled in -12, happy to chat about that if you want. First two comments are about text that's new in -11: - 4.1.8: "MUST be present" is ambiguous - do you mean it must be used? I think you do. - 4.1.8: "MUST be distributed or established in a secure fashion" isn't really a protocol requirement. Do you really just mean "see 4.1.8.1" ? OLD COMMENTS FOR -10 below, I didn't check if you'd made any related changes. - I don't get how there's an IPR disclosure for this, but whatever. - The non-security parts of this were quite a good read. - 4.1.8: 1st sentence makes no sense. It says RPL does X or not-X in order to Y. There is no choice but for RPL to do X or not-X. - 4.1.8 seems to me to imply that link layer security is always needed since there can always be some node that will send an unsecured RPL messsage. If you agree, then I think that should be made more clear. If you disagree, I'd like to understand how. - 4.1.8, I am surprised not to see a recommendation that separate group keys SHOULD be used for different applications in the same bulding network. But that may be too fine grained a recommendation for this document perhaps. - 5.1.2.1, I think it'd be clearer to say Imin should be between 10 and 50 ms. The "10 - 50 ms" notation can be confusing. (Same elsewhere.) - section 7, 3rd para, "can rely on" is sales language, please strike that or s/rely on/depend upon/ - section 7, 3rd para, last sentence: this is sales language and should be deleted. Or perhaps s/is/SHOULD be/ would turn it back into a piece of specification language. - 7.1 - this is odd text to see in a proposed standard, but I think it's accurately describing the level of interop to expect in RPL security, so is probably the right thing to say. I'd argue that it'd be even better to bluntly admit/say that there is currently no interoperable automated key management for RPL. (Same for 7.3) Or, and better, to fix that lack. (See my discuss point.) - 7.2, 1st sentence: this is meaningless as I read it - what are you trying to say? - 7.2, when a node is stolen, the chances are that any keys contained in the node are at significant risk of being leaked. - 7.3, I do not believe that [I-D.keoh-dice-multicast-security] is necessarily going to proceed via the DICE WG. Depending on it would be fairly high-risk in any case. - 7.4, last sentence: more sales talk - 7.5, what is this specifying? I don't get it. Does 7416 set out what to implement to get interop? (I didn't think so, but nor does this seem to.) From nobody Tue Jul 28 00:49:02 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2341A7025; Tue, 28 Jul 2015 00:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWWr6TGOpuTE; Tue, 28 Jul 2015 00:48:58 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB081A702B; Tue, 28 Jul 2015 00:48:56 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud3.xs4all.net with ESMTP id xjou1q00G4h15BW01joucB; Tue, 28 Jul 2015 09:48:54 +0200 Received: from [2001:983:a264:1:3948:5a3f:df60:1149] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 28 Jul 2015 09:48:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 28 Jul 2015 09:48:54 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> References: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> Message-ID: <8e6002eac4e0ae5d25522626fb066585@xs4all.nl> X-Sender: stokcons@xs4all.nl (ILay9q94+zd42i+vbosjna52Tfc222k+) User-Agent: XS4ALL Webmail Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-home-building-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 07:49:01 -0000 Hi Stephen, thanks for your reaction. Below a recap of the past discussions, copied from earlier e_mail exchanges. Actual text changes in the draft after the comment answers below are not reproduced here, but can be checked in version 12. Peter Stephen Farrell schreef op 2015-07-25 16:08: > Stephen Farrell has entered the following ballot position for > draft-ietf-roll-applicability-home-building-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Thanks for the discussion about security. I didn't check > if the comments below were handled in -12, happy to > chat about that if you want. > > First two comments are about text that's new in -11: > > - 4.1.8: "MUST be present" is ambiguous - do you mean > it must be used? I think you do. done > > - 4.1.8: "MUST be distributed or established in a > secure fashion" isn't really a protocol requirement. > Do you really just mean "see 4.1.8.1" ? The symmetric key distributions has a scope (4.1.8.1) and MUST follow a mechanism (4.1.8.2). > > > OLD COMMENTS FOR -10 below, I didn't check if you'd made > any related changes. > > - I don't get how there's an IPR disclosure for this, but > whatever. This refers to 5.1.1 and in particular the rt-layer that is proposed to reduce delays and losses under overload. > > - The non-security parts of this were quite a good read. > > - 4.1.8: 1st sentence makes no sense. It says RPL does X or > not-X in order to Y. There is no choice but for RPL to do X or > not-X. The aim is to say: "In order to support low-cost devices and devices running on a battery, RPL MAY use either unsecured messages or secured messages" The omitted subtext is probably "..., not just secured messages" as that is what is being emphasised here, i.e. a greater choice and thus implied security policy choice. Would the following make more sense?: "In order to support low-cost devices and devices running on a battery, there are two security policies applicable to RPL; one where RPL uses unsecured messages and another where RPL uses secured messages" > > - 4.1.8 seems to me to imply that link layer security is > always needed since there can always be some node that will > send an unsecured RPL messsage. If you agree, then I think > that should be made more clear. If you disagree, I'd like to > understand how. If the security policy option where RPL uses unsecured messages applies, then link layer security will always be needed. It is a policy choice applicable to the deployed network > > - 4.1.8, I am surprised not to see a recommendation that > separate group keys SHOULD be used for different applications > in the same bulding network. But that may be too fine grained > a recommendation for this document perhaps. That is a separate issue from securing RPL messages, which is what this section is about > > - 5.1.2.1, I think it'd be clearer to say Imin should be > between 10 and 50 ms. The "10 - 50 ms" notation can be > confusing. (Same elsewhere.) Agree suggestion is clearer > > - section 7, 3rd para, "can rely on" is sales language, please > strike that or s/rely on/depend upon/ Rephrase as: "The following mechanisms MAY be used: (i) pre-installation using an out-of-band method, (ii) secure delivery when a device is introduced into the network or (iii) secure delivery by a trusted neighbouring device." > > - section 7, 3rd para, last sentence: this is sales language > and should be deleted. Or perhaps s/is/SHOULD be/ would turn > it back into a piece of specification language. Agree with suggested change > > - 7.1 - this is odd text to see in a proposed standard, but I > think it's accurately describing the level of interop to > expect in RPL security, so is probably the right thing to say. > I'd argue that it'd be even better to bluntly admit/say that > there is currently no interoperable automated key management > for RPL. (Same for 7.3) Or, and better, to fix that lack. (See > my discuss point.) There are many ways to achieve key distribution and in some respects it would be nice to see one single way to do it. However, this is unlikely to ever happen. The main reason is that a deployment standard is a complex animal of which RPL is typically one small part. The key management is also just a part and in itself typically is a conglomeration of various RFCs and applicability statements, irrespective of what routing protocol is chosen for said deployment. ZigBee IP is a good example of a full interoperable deployment and there is an extensive list of 43 RFCs and IDs directly referenced, not to mention the further indirect references from those. We chose which protocols to use for key management and set security policy and see text in 4.1.8 following DISCUSS > > - 7.2, 1st sentence: this is meaningless as I read it - what > are you trying to say? Has been rephrased with two cases: (1) addition of nodes during operation (2) node is compromised > > - 7.2, when a node is stolen, the chances are that any keys > contained in the node are at significant risk of being leaked. see above > > - 7.3, I do not believe that [I-D.keoh-dice-multicast-security] > is necessarily going to proceed via the DICE WG. Depending > on it would be fairly high-risk in any case. 7.3 severely reduced to 1 phrase > > - 7.4, last sentence: more sales talk removed > > - 7.5, what is this specifying? I don't get it. Does 7416 set > out what to implement to get interop? (I didn't think so, but > nor does this seem to.) > adapted to summary section, explaining relation to RFC7416 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Jul 28 01:19:06 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5031A0197; Tue, 28 Jul 2015 01:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO3HQbo6FH-o; Tue, 28 Jul 2015 01:18:58 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6A91A0169; Tue, 28 Jul 2015 01:18:57 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so69476201lbb.1; Tue, 28 Jul 2015 01:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uonvIi/bkvd4kleA2VBRzHNnY5nWHqHcvkCrKiixdsE=; b=bBCvjoCrGo6wV2YirnbJhkfQto6ijCK833DNcozVLIH/9cdW/FTn1D1QxWAwPbdU6B W8jdUaYv0LfhO/wsdYhOypl/0IrZunPBd7TBSytTHMeExCoJ/dgB7BI25xtJrPoVvltX jIl4kErvHYzow7pX46UXCEMwWTlzze6d1O9UFFl4JTqy0a19vxK7/jzEyNEKbPQyZFEp UtViDQtI/lQWm9O3VmxWiMAubyjFePtc7mvp6VE6A1OLgbOkjN9K6zVIbL8XDvL9jOHd wx0wocJdKDclc9b4X/c1+I9ZZJbBfUbUUGp0Ato4+c10UuSqItwmSx11RARvreyBykfK Y1vg== MIME-Version: 1.0 X-Received: by 10.112.63.137 with SMTP id g9mr31271042lbs.121.1438071536125; Tue, 28 Jul 2015 01:18:56 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.25.31.75 with HTTP; Tue, 28 Jul 2015 01:18:56 -0700 (PDT) In-Reply-To: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> References: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> Date: Tue, 28 Jul 2015 09:18:56 +0100 X-Google-Sender-Auth: pkhsgny5HDrUpFByNOmvGd9Otzg Message-ID: From: Robert Cragie To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1133d004128cd3051beb1fe6 Archived-At: Cc: roll-chairs@ietf.org, "roll@ietf.org WG" , draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building@ietf.org, Yvonne-Anne Pignolet , draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-home-building-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 08:19:00 -0000 --001a1133d004128cd3051beb1fe6 Content-Type: text/plain; charset=UTF-8 Hi Stephen, Please see inline for specific responses. Regarding the old comments: We have tried to respond to these issues in previous follow up e-mails and modify the document in accordance with the responses. Repeating these old comments suggests that neither those responses nor the updated text have been read yet. Please can you read the responses and updated text before simply repeating these comments? Otherwise I can't see how we can make any progress on this. Robert On 25 July 2015 at 15:08, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-roll-applicability-home-building-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Thanks for the discussion about security. I didn't check > if the comments below were handled in -12, happy to > chat about that if you want. > > First two comments are about text that's new in -11: > > - 4.1.8: "MUST be present" is ambiguous - do you mean > it must be used? I think you do. > This has been changed to "MUST be used on all nodes" in -12 > > - 4.1.8: "MUST be distributed or established in a > secure fashion" isn't really a protocol requirement. > Do you really just mean "see 4.1.8.1" ? > As mentioned before, this is just introductory. I suggest removing the sentence to close the comment. --001a1133d004128cd3051beb1fe6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Please see inlin= e for specific responses.

Regarding the old commen= ts: We have tried to respond to these issues in previous follow up e-mails = and modify the document in accordance with the responses. Repeating these o= ld comments suggests that neither those responses nor the updated text have= been read yet. Please can you read the responses and updated text before s= imply repeating these comments? Otherwise I can't see how we can make a= ny progress on this.

Robert


On 25 July 2015 at = 15:08, Stephen Farrell <stephen.farrell@cs.tcd.ie> w= rote:
Stephen Farrell has entered the fol= lowing ballot position for
draft-ietf-roll-applicability-home-building-12: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.iet= f.org/doc/draft-ietf-roll-applicability-home-building/



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


Thanks for the discussion about security. I didn't check
if the comments below were handled in -12, happy to
chat about that if you want.

First two comments are about text that's new in -11:

- 4.1.8: "MUST be present" is ambiguous - do you mean
it must be used? I think you do.

<RC= C>This has been changed to "MUST be used on all nodes" in -12&= lt;/RCC>
=C2=A0

- 4.1.8: "MUST be distributed or established in a
secure fashion" isn't really a protocol requirement.
Do you really just mean "see 4.1.8.1" ?

=
<RCC>As mentioned before, this is just introductory. I sug= gest removing the sentence to close the comment.</RCC>

=
--001a1133d004128cd3051beb1fe6-- From nobody Tue Jul 28 01:23:39 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B051A0218 for ; Tue, 28 Jul 2015 01:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-nlZu1noQ-X for ; Tue, 28 Jul 2015 01:23:36 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0805E1A020A for ; Tue, 28 Jul 2015 01:23:35 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud3.xs4all.net with ESMTP id xkPa1q0084h15BW01kPaLW; Tue, 28 Jul 2015 10:23:34 +0200 Received: from [2001:983:a264:1:3948:5a3f:df60:1149] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 28 Jul 2015 10:23:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 28 Jul 2015 10:23:34 +0200 From: peter van der Stok To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> Message-ID: <1d2ab82d41646127afc4b7748166208b@xs4all.nl> X-Sender: stokcons@xs4all.nl (8nqqavAppstduFBK1qPrPFUwhoEeYugA) User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-home-building-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 08:23:38 -0000 Hi Robert, was this a response to my answer; or did our answers cross? My intentions was to pass over the old comments quickly; Peter Robert Cragie schreef op 2015-07-28 10:18: > Hi Stephen, > > Please see inline for specific responses. > > Regarding the old comments: We have tried to respond to these issues > in previous follow up e-mails and modify the document in accordance > with the responses. Repeating these old comments suggests that neither > those responses nor the updated text have been read yet. Please can > you read the responses and updated text before simply repeating these > comments? Otherwise I can't see how we can make any progress on this. > > Robert > > On 25 July 2015 at 15:08, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-roll-applicability-home-building-12: No Objection >> >> When responding, please keep the subject line intact and reply to >> all >> email addresses included in the To and CC lines. (Feel free to cut >> this >> introductory paragraph, however.) >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ >> >> > ---------------------------------------------------------------------- >> COMMENT: >> > ---------------------------------------------------------------------- >> >> Thanks for the discussion about security. I didn't check >> if the comments below were handled in -12, happy to >> chat about that if you want. >> >> First two comments are about text that's new in -11: >> >> - 4.1.8: "MUST be present" is ambiguous - do you mean >> it must be used? I think you do. > > This has been changed to "MUST be used on all nodes" in -12 > >> - 4.1.8: "MUST be distributed or established in a >> secure fashion" isn't really a protocol requirement. >> Do you really just mean "see 4.1.8.1" ? > > As mentioned before, this is just introductory. I suggest > removing the sentence to close the comment. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Jul 28 02:50:44 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150BB1A8839; Tue, 28 Jul 2015 02:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttiP6UPR-Eni; Tue, 28 Jul 2015 02:50:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7BB1A883C; Tue, 28 Jul 2015 02:50:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C381DBE38; Tue, 28 Jul 2015 10:50:34 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqYmSNK5NrVm; Tue, 28 Jul 2015 10:50:34 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8ED0DBE35; Tue, 28 Jul 2015 10:50:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438077034; bh=mXjqDYrGFTpHtlA1aMn7Ek1okBYrk7IfXp3Mu/NC9G4=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=y7enSp1ATJlfQpXFacnjhyiWyfy3rmMo/nQRZsufPEuLuCBDH3Us9qpUFUfO8q7QF eRqC7jpMzNf5bKxz5Evl40N4CJLDplGFv9aHkGv7rmvHBsoeiNPUUbQG0dxyDfj2cD t9PeFQxOsiKeZVbNjqxoUCbg00m82aVu5BqJw+G0= Message-ID: <55B7506A.9040004@cs.tcd.ie> Date: Tue, 28 Jul 2015 10:50:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, "roll@ietf.org WG" , draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building.shepherd@ietf.org, Yvonne-Anne Pignolet , draft-ietf-roll-applicability-home-building@ietf.org Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-home-building-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 09:50:40 -0000 Hiya, On 28/07/15 09:18, Robert Cragie wrote: > Hi Stephen, > > Please see inline for specific responses. > > Regarding the old comments: We have tried to respond to these issues in > previous follow up e-mails and modify the document in accordance with the > responses. Repeating these old comments suggests that neither those > responses nor the updated text have been read yet. Please can you read the > responses and updated text before simply repeating these comments? > Otherwise I can't see how we can make any progress on this. Sorry, we're talking past one another. The old comments are present in the tracker and get attached to the email unless I go through them and delete them manually. And since they are not blocking I don't spend much time tracking if they have/haven't been addressed. And mostly I forget once sufficient time has elapsed;-) In other words, it's up to you and your AD if you want to consider them or not, I don't mind. So you can make progress on this in various ways. One is to just ignore the comments. Another is to say "yeah, we know it's not blocking but we'd actually like to chat about comment." Your chairs/AD may have more ideas. But the main thing is that a "No Objection" ballot is just that, I don't object to this moving ahead. So I'd say if there are any of the comments where you think it is interesting to continue to chat, please just mail me about that but there is no need to address each one in blow-by-blow fashion. If you and your AD think there's no need for more chat, then we're done already. Hope that helps, S. > > Robert > > > On 25 July 2015 at 15:08, Stephen Farrell wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-roll-applicability-home-building-12: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> >> https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Thanks for the discussion about security. I didn't check >> if the comments below were handled in -12, happy to >> chat about that if you want. >> >> First two comments are about text that's new in -11: >> >> - 4.1.8: "MUST be present" is ambiguous - do you mean >> it must be used? I think you do. >> > > This has been changed to "MUST be used on all nodes" in -12 > > >> >> - 4.1.8: "MUST be distributed or established in a >> secure fashion" isn't really a protocol requirement. >> Do you really just mean "see 4.1.8.1" ? >> > > As mentioned before, this is just introductory. I suggest removing the > sentence to close the comment. > From nobody Tue Jul 28 02:58:38 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FCB1A883F; Tue, 28 Jul 2015 02:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjaick0S2kSs; Tue, 28 Jul 2015 02:58:32 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DD31A7007; Tue, 28 Jul 2015 02:58:32 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so71069926lbb.0; Tue, 28 Jul 2015 02:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GYvFsFTXpIYjdJNzFDwRAT4hXBP+8A/bPQkBlHGZZWQ=; b=RuXhopXSFs52UxNjzw1XF/XjGHq59To0hifg3auVcQ6jlW7DnYZHDYuXHAM3gNHeUC k7uRqJP7w+Lx1crqTeoqSdPPNF8HM0Gw1Z9AQOyKCrXZN4jbIHwJySnHKJbANcSctwQ9 ZCiA6uA1NXCbMDXewEIMToGnH8AMHLx1snfgM+AF4/s9gbXlaXmNRYkunBzbGrtFgP6O xcAXxsLou8lejOp6xq5NJYV4XWm4kS19IoTMAJA6oIGmxexIlKxK55o5AcAoj05SVWLQ bLu6071pUhyNgvaHyCtCHvq95A+61mUxRajxUSMCqnCjM1TEkoKdLc7wN1cRqSQiyVrz owDQ== MIME-Version: 1.0 X-Received: by 10.112.198.74 with SMTP id ja10mr31720281lbc.19.1438077510882; Tue, 28 Jul 2015 02:58:30 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.25.31.75 with HTTP; Tue, 28 Jul 2015 02:58:30 -0700 (PDT) In-Reply-To: <55B7506A.9040004@cs.tcd.ie> References: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> <55B7506A.9040004@cs.tcd.ie> Date: Tue, 28 Jul 2015 10:58:30 +0100 X-Google-Sender-Auth: Jd3L4XFRXXuRd3n_VpIG-CNX0zA Message-ID: From: Robert Cragie To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c2b8e6321d47051bec83ba Archived-At: Cc: roll-chairs@ietf.org, "roll@ietf.org WG" , draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building.shepherd@ietf.org, Yvonne-Anne Pignolet , draft-ietf-roll-applicability-home-building@ietf.org Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-home-building-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 09:58:34 -0000 --001a11c2b8e6321d47051bec83ba Content-Type: text/plain; charset=UTF-8 Hi Stephen, Understood - thanks for the clarification. As mentioned, we did go through the comments and respond and make changes so will be happy to show these to the chairs/AD if required. Robert On 28 July 2015 at 10:50, Stephen Farrell wrote: > > Hiya, > > On 28/07/15 09:18, Robert Cragie wrote: > > Hi Stephen, > > > > Please see inline for specific responses. > > > > Regarding the old comments: We have tried to respond to these issues in > > previous follow up e-mails and modify the document in accordance with the > > responses. Repeating these old comments suggests that neither those > > responses nor the updated text have been read yet. Please can you read > the > > responses and updated text before simply repeating these comments? > > Otherwise I can't see how we can make any progress on this. > > Sorry, we're talking past one another. The old comments are present in > the tracker and get attached to the email unless I go through them and > delete them manually. And since they are not blocking I don't spend > much time tracking if they have/haven't been addressed. And mostly I > forget once sufficient time has elapsed;-) In other words, it's up to > you and your AD if you want to consider them or not, I don't mind. > > So you can make progress on this in various ways. One is to just ignore > the comments. Another is to say "yeah, we know it's not blocking but > we'd actually like to chat about comment." Your chairs/AD may > have more ideas. > > But the main thing is that a "No Objection" ballot is just that, I > don't object to this moving ahead. > > So I'd say if there are any of the comments where you think it is > interesting to continue to chat, please just mail me about that but > there is no need to address each one in blow-by-blow fashion. If > you and your AD think there's no need for more chat, then we're done > already. > > Hope that helps, > S. > > > > > > Robert > > > > > > On 25 July 2015 at 15:08, Stephen Farrell > wrote: > > > >> Stephen Farrell has entered the following ballot position for > >> draft-ietf-roll-applicability-home-building-12: No Objection > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> > >> > https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> > >> Thanks for the discussion about security. I didn't check > >> if the comments below were handled in -12, happy to > >> chat about that if you want. > >> > >> First two comments are about text that's new in -11: > >> > >> - 4.1.8: "MUST be present" is ambiguous - do you mean > >> it must be used? I think you do. > >> > > > > This has been changed to "MUST be used on all nodes" in -12 > > > > > >> > >> - 4.1.8: "MUST be distributed or established in a > >> secure fashion" isn't really a protocol requirement. > >> Do you really just mean "see 4.1.8.1" ? > >> > > > > As mentioned before, this is just introductory. I suggest removing > the > > sentence to close the comment. > > > --001a11c2b8e6321d47051bec83ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Understood - thanks for the= clarification. As mentioned, we did go through the comments and respond an= d make changes so will be happy to show these to the chairs/AD if required.=

Robert

=
On 28 July 2015 at 10:50, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 28/07/15 09:18, Robert Cragie wrote:
> Hi Stephen,
>
> Please see inline for specific responses.
>
> Regarding the old comments: We have tried to respond to these issues i= n
> previous follow up e-mails and modify the document in accordance with = the
> responses. Repeating these old comments suggests that neither those > responses nor the updated text have been read yet. Please can you read= the
> responses and updated text before simply repeating these comments?
> Otherwise I can't see how we can make any progress on this.

Sorry, we're talking past one another. The old comments are pres= ent in
the tracker and get attached to the email unless I go through them and
delete them manually. And since they are not blocking I don't spend
much time tracking if they have/haven't been addressed. And mostly I forget once sufficient time has elapsed;-) In other words, it's up to you and your AD if you want to consider them or not, I don't mind.

So you can make progress on this in various ways. One is to just ignore
the comments. Another is to say "yeah, we know it's not blocking b= ut
we'd actually like to chat about <this> comment." Your chair= s/AD may
have more ideas.

But the main thing is that a "No Objection" ballot is just that, = I
don't object to this moving ahead.

So I'd say if there are any of the comments where you think it is
interesting to continue to chat, please just mail me about that but
there is no need to address each one in blow-by-blow fashion. If
you and your AD think there's no need for more chat, then we're don= e
already.

Hope that helps,
S.


>
> Robert
>
>
> On 25 July 2015 at 15:08, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-roll-applicability-home-building-12: No Objection
>>
>> When responding, please keep the subject line intact and reply to = all
>> email addresses included in the To and CC lines. (Feel free to cut= this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
>> for more information about IESG D= ISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here= :
>>
>> https://datatr= acker.ietf.org/doc/draft-ietf-roll-applicability-home-building/
>>
>>
>>
>> -------------------= ---------------------------------------------------
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>>
>> Thanks for the discussion about security. I didn't check
>> if the comments below were handled in -12, happy to
>> chat about that if you want.
>>
>> First two comments are about text that's new in -11:
>>
>> - 4.1.8: "MUST be present" is ambiguous - do you mean >> it must be used? I think you do.
>>
>
> <RCC>This has been changed to "MUST be used on all nodes&qu= ot; in -12</RCC>
>
>
>>
>> - 4.1.8: "MUST be distributed or established in a
>> secure fashion" isn't really a protocol requirement.
>> Do you really just mean "see 4.1.8.1" ?
>>
>
> <RCC>As mentioned before, this is just introductory. I suggest r= emoving the
> sentence to close the comment.</RCC>
>

--001a11c2b8e6321d47051bec83ba-- From nobody Tue Jul 28 05:00:18 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC891A89AF; Tue, 28 Jul 2015 05:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eakwdLxopW6h; Tue, 28 Jul 2015 05:00:14 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 E984D1A89FE; Tue, 28 Jul 2015 05:00:04 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so72961550lbb.1; Tue, 28 Jul 2015 05:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VYT1HXAzX+wCfaQEGw8ySQ3yBnvHm13iapqZl7u4cwk=; b=H9s8ZX0d8xyxtPUzHR3tBOOdm+dsIFKTIw/aWx4FXD3JTNF7WDNy7+wX2wFRGogF2L 74y2I9KMlWqZhv+isQ0HgvMJJpkBXbCUIYdHSv3Gt6DI4lAJHWoX0mpdA0DvvZ2//478 y3VytpRsDF0aFm8uLJcGbueRshzCNdX/UE0JOotRwCgv5d4/fGNP7BEN1x4dw23lVigW 2RKNmJVW15fX2oSth++pt1/q0YP2ggvOo1xUp0Nc65X5V3A6LqXCjPN4FhZeVogDKdJC f1Nyz0QwPmpqbCC0j+IRQokZzQFvKcTQyfC1inIMWL5N+BB+I9New71prGZ392p8gaeL MxxA== MIME-Version: 1.0 X-Received: by 10.112.159.226 with SMTP id xf2mr28280270lbb.74.1438084803294; Tue, 28 Jul 2015 05:00:03 -0700 (PDT) Received: by 10.25.140.8 with HTTP; Tue, 28 Jul 2015 05:00:03 -0700 (PDT) In-Reply-To: References: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> <55B7506A.9040004@cs.tcd.ie> Date: Tue, 28 Jul 2015 15:00:03 +0300 Message-ID: From: Ines Robles To: Robert Cragie , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c3c636db7b9a051bee3526 Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building@ietf.org, Yvonne-Anne Pignolet , draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-home-building-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 12:00:17 -0000 --001a11c3c636db7b9a051bee3526 Content-Type: text/plain; charset=UTF-8 Hi, First two comments from ballotage [4] from v11: - 4.1.8: "MUST be present" is ambiguous - do you mean it must be used? I think you do. Addressed: changed to " security MUST be used on all nodes" - 4.1.8: "MUST be distributed or established in a secure fashion" isn't really a protocol requirement. Do you really just mean "see 4.1.8.1" ? In [1] states "Yes. It was meant more as an introductory statement but is redundant really". For this sentence more clarification was added in 12: "A symmetric key is used to secure a RPL message using either RPL message security or link-layer security. The symmetric key MUST be distributed or established in a secure fashion. There may be more than one symmetric key in use by any node at any one time. The same symmetric key MUST NOT be used for both RPL message security and link-layer security between two peer nodes." In [2] is suggested to remove the sentence, so it could be done by the RFC Editor. Do you agree with that? The other comments (v10) from ballotage are addressed as states in [3] [1] http://www.ietf.org/mail-archive/web/roll/current/msg09368.html [2] http://www.ietf.org/mail-archive/web/roll/current/msg09388.html [3] http://www.ietf.org/mail-archive/web/roll/current/msg09376.html [4] https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ballot/ I believe that the document is ready to go forward. Thank you very much for your hard work on this, Ines 2015-07-28 12:58 GMT+03:00 Robert Cragie : > Hi Stephen, > > Understood - thanks for the clarification. As mentioned, we did go through > the comments and respond and make changes so will be happy to show these to > the chairs/AD if required. > > Robert > > On 28 July 2015 at 10:50, Stephen Farrell > wrote: > >> >> Hiya, >> >> On 28/07/15 09:18, Robert Cragie wrote: >> > Hi Stephen, >> > >> > Please see inline for specific responses. >> > >> > Regarding the old comments: We have tried to respond to these issues in >> > previous follow up e-mails and modify the document in accordance with >> the >> > responses. Repeating these old comments suggests that neither those >> > responses nor the updated text have been read yet. Please can you read >> the >> > responses and updated text before simply repeating these comments? >> > Otherwise I can't see how we can make any progress on this. >> >> Sorry, we're talking past one another. The old comments are present in >> the tracker and get attached to the email unless I go through them and >> delete them manually. And since they are not blocking I don't spend >> much time tracking if they have/haven't been addressed. And mostly I >> forget once sufficient time has elapsed;-) In other words, it's up to >> you and your AD if you want to consider them or not, I don't mind. >> >> So you can make progress on this in various ways. One is to just ignore >> the comments. Another is to say "yeah, we know it's not blocking but >> we'd actually like to chat about comment." Your chairs/AD may >> have more ideas. >> >> But the main thing is that a "No Objection" ballot is just that, I >> don't object to this moving ahead. >> >> So I'd say if there are any of the comments where you think it is >> interesting to continue to chat, please just mail me about that but >> there is no need to address each one in blow-by-blow fashion. If >> you and your AD think there's no need for more chat, then we're done >> already. >> >> Hope that helps, >> S. >> >> >> > >> > Robert >> > >> > >> > On 25 July 2015 at 15:08, Stephen Farrell >> wrote: >> > >> >> Stephen Farrell has entered the following ballot position for >> >> draft-ietf-roll-applicability-home-building-12: No Objection >> >> >> >> When responding, please keep the subject line intact and reply to all >> >> email addresses included in the To and CC lines. (Feel free to cut this >> >> introductory paragraph, however.) >> >> >> >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> >> >> The document, along with other ballot positions, can be found here: >> >> >> >> >> https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> COMMENT: >> >> ---------------------------------------------------------------------- >> >> >> >> >> >> Thanks for the discussion about security. I didn't check >> >> if the comments below were handled in -12, happy to >> >> chat about that if you want. >> >> >> >> First two comments are about text that's new in -11: >> >> >> >> - 4.1.8: "MUST be present" is ambiguous - do you mean >> >> it must be used? I think you do. >> >> >> > >> > This has been changed to "MUST be used on all nodes" in -12 >> > >> > >> >> >> >> - 4.1.8: "MUST be distributed or established in a >> >> secure fashion" isn't really a protocol requirement. >> >> Do you really just mean "see 4.1.8.1" ? >> >> >> > >> > As mentioned before, this is just introductory. I suggest removing >> the >> > sentence to close the comment. >> > >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001a11c3c636db7b9a051bee3526 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

First two comments from ballot= age [4] from v11:

- 4.1.8: "MUST be present&q= uot; is ambiguous - do you mean
it must be used? I think you do.<= /div>

Addressed: changed to " security MUST be used= on all nodes"

- 4.1.8: "MUST be distrib= uted or established in a
secure fashion" isn't really a = protocol requirement.
Do you really just mean "see 4.1.8.1&q= uot; ?


In [1] states "Yes. It = was meant more as an introductory statement but is redundant really".<= /div>

For this sentence more clarification was added in = 12:=C2=A0

"A symmetric key is used to secure = a RPL message using either RPL
message security or link-layer security.=C2= =A0 The symmetric key MUST be
distributed or established in a secure fashio= n.=C2=A0 There may be more
than one symmetric key in use by any node at any= one time.=C2=A0 The same
symmetric key MUST NOT be used for both RPL messa= ge security and
link-layer security between two peer nodes."

In [2] is suggested to remove the sentence, so it could be = done by the RFC Editor. Do you agree with that?

The other comments =C2=A0(v10) from ballotage are addressed as= states in [3]


I believe that the do= cument is ready to go forward.

Thank you very much= for your hard work on this,

Ines

2015-07-28 12:58= GMT+03:00 Robert Cragie <robert.cragie@gridmerge.com>:
Hi Stephen,
Understood - thanks for the clarification. As mentioned, we di= d go through the comments and respond and make changes so will be happy to = show these to the chairs/AD if required.

Robert

On 28 July 2015 at 10:50, Stephen Farrell = <stephen.= farrell@cs.tcd.ie> wrote:

Hiya,

On 28/07/15 09:18, Robert Cragie wrote:
> Hi Stephen,
>
> Please see inline for specific responses.
>
> Regarding the old comments: We have tried to respond to these issues i= n
> previous follow up e-mails and modify the document in accordance with = the
> responses. Repeating these old comments suggests that neither those > responses nor the updated text have been read yet. Please can you read= the
> responses and updated text before simply repeating these comments?
> Otherwise I can't see how we can make any progress on this.

Sorry, we're talking past one another. The old comments are pres= ent in
the tracker and get attached to the email unless I go through them and
delete them manually. And since they are not blocking I don't spend
much time tracking if they have/haven't been addressed. And mostly I forget once sufficient time has elapsed;-) In other words, it's up to you and your AD if you want to consider them or not, I don't mind.

So you can make progress on this in various ways. One is to just ignore
the comments. Another is to say "yeah, we know it's not blocking b= ut
we'd actually like to chat about <this> comment." Your chair= s/AD may
have more ideas.

But the main thing is that a "No Objection" ballot is just that, = I
don't object to this moving ahead.

So I'd say if there are any of the comments where you think it is
interesting to continue to chat, please just mail me about that but
there is no need to address each one in blow-by-blow fashion. If
you and your AD think there's no need for more chat, then we're don= e
already.

Hope that helps,
S.


>
> Robert
>
>
> On 25 July 2015 at 15:08, Stephen Farrell <stephen.farrell@cs.tcd.ie> wr= ote:
>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-roll-applicability-home-building-12: No Objection
>>
>> When responding, please keep the subject line intact and reply to = all
>> email addresses included in the To and CC lines. (Feel free to cut= this
>> introductory paragraph, however.)
>>
>>
 >> Please refer to https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
>> for more information about IESG DISC= USS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here= :
>>
 >> https://datatr= acker.ietf.org/doc/draft-ietf-roll-applicability-home-building/
>>
>>
>>
>> --------------------------------= --------------------------------------
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>>
>> Thanks for the discussion about security. I didn't check
>> if the comments below were handled in -12, happy to
>> chat about that if you want.
>>
>> First two comments are about text that's new in -11:
>>
>> - 4.1.8: "MUST be present" is ambiguous - do you mean >> it must be used? I think you do.
>>
>
> <RCC>This has been changed to "MUST be used on all nodes&qu= ot; in -12</RCC>
>
>
>>
>> - 4.1.8: "MUST be distributed or established in a
>> secure fashion" isn't really a protocol requirement.
>> Do you really just mean "see 4.1.8.1" ?
>>
>
> <RCC>As mentioned before, this is just introductory. I suggest r= emoving the
> sentence to close the comment.</RCC>
>


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


--001a11c3c636db7b9a051bee3526-- From nobody Tue Jul 28 05:04:31 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7D21A8A0F; Tue, 28 Jul 2015 05:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sMWr6mVyAKU; Tue, 28 Jul 2015 05:04:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E08A1A8A03; Tue, 28 Jul 2015 05:04:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C6C70BE5D; Tue, 28 Jul 2015 13:04:25 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT4I2iXq2f7I; Tue, 28 Jul 2015 13:04:25 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5BA81BE51; Tue, 28 Jul 2015 13:04:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438085065; bh=SW6i2ZE1/8vVmqHKIaRoBZLrIQLItrPHOiQs1mk4zPA=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=S2mffNSVc4ceO3nc4ZfUbmK+KvolWtHVsHVhOLku0k1n0Yz5h5TvoLCt/JDusiRjz DNo/1HSt6w0zl7IqOtetXRJoItVkwnqN/gHthduvsN0Job7MywRrxI/6a/Fwl96Iqu fXEd+LviwFBupO3NJ+Z2FjXRorMbPNwfC3Lwiwh0= Message-ID: <55B76FC9.2080203@cs.tcd.ie> Date: Tue, 28 Jul 2015 13:04:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Ines Robles , Robert Cragie , Routing Over Low power and Lossy networks References: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> <55B7506A.9040004@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, draft-ietf-roll-applicability-home-building.shepherd@ietf.org, Yvonne-Anne Pignolet , The IESG Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-home-building-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 12:04:29 -0000 (Just in case it helps...) On 28/07/15 13:00, Ines Robles wrote: > I believe that the document is ready to go forward. The comment resolutions you suggest seem fine to me. Thanks, S. From nobody Tue Jul 28 05:20:36 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABDD1A8A46 for ; Tue, 28 Jul 2015 05:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WErwe8UlU3PQ for ; Tue, 28 Jul 2015 05:20:29 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946A11A89A9 for ; Tue, 28 Jul 2015 05:20:28 -0700 (PDT) Received: by lahh5 with SMTP id h5so67278161lah.2 for ; Tue, 28 Jul 2015 05:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=DzAVJWWlnP2h1mJGRjyDgMsrw+BKHyZoEU17MP8QL0E=; b=aARMV+6T16Nf4YPRZU8Ux3EF8fCJWeuvzRpgR0NCtdXUQ/tNWRwNpPuiCB4WwFF+lB jMvU4DjQWBMcBW2owPxC6V7n/vjMrrTHTllhj2P7iDmmSnY8KknX7d0quaqnyKJZ13uj mRJDu2nFOd63aYhxz1keLSOcwM82SqYT4xv2xvE82nid018DfMNwwscw/IIp2C1RKama STQVJZBtRedkmJ+ehfJWaMUfqfbiP8RdafJ/UxqhD/rm0zz5V7PYAM/ReMVFb76xIAC0 lvApDnrgeK5JFvaAFhlw0o3at/WSPkuXAGXUWksDBU28McHDDZj1jymeO/rFbEaadv/W cMpw== MIME-Version: 1.0 X-Received: by 10.153.7.137 with SMTP id dc9mr31875624lad.16.1438086027057; Tue, 28 Jul 2015 05:20:27 -0700 (PDT) Received: by 10.25.140.8 with HTTP; Tue, 28 Jul 2015 05:20:27 -0700 (PDT) Date: Tue, 28 Jul 2015 15:20:27 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=001a113462a4cc9eab051bee7e84 Archived-At: Cc: Michael Richardson Subject: [Roll] Minute - IETF 93 - draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 12:20:34 -0000 --001a113462a4cc9eab051bee7e84 Content-Type: text/plain; charset=UTF-8 Hi, First of all, million thanks to Thomas, Dominique and Diego for taking the minute during IETF. Please find a draft of the minute here https://www.ietf.org/proceedings/93/minutes/minutes-93-roll We accept modifications until 08-08-2015 Thank you, Michael and Ines --001a113462a4cc9eab051bee7e84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

First of all, million thanks to Tho= mas, Dominique and Diego for taking the minute during IETF.

<= /div>

We accept modif= ications until 08-08-2015

Thank you,
Michael and Ines
--001a113462a4cc9eab051bee7e84-- From nobody Tue Jul 28 06:50:35 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D371A9085; Tue, 28 Jul 2015 06:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYebsTc7MAJr; Tue, 28 Jul 2015 06:50:26 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114F81A9044; Tue, 28 Jul 2015 06:50:26 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so75118383lbb.0; Tue, 28 Jul 2015 06:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j3VWQdhcHrHOuBoA7y881s1WBVGKme4OGLrH/EmYytI=; b=bLHQz2WpRNk5/AXqp+lzyLo6VW/YmlLTE3zBbH4YQePj/V7NncvI9gpp3aNGZu0c+k YHVy8HPTsWMqggLCKv3A4DbL4Ia6MIks62Lw2Slhzg3SswoqUDPIlgHP8GlvZ2SFgoyn gP6C5W76lqM46ZoGR7F5lTd8juVnOZIsqZIg38GAS5eq1mh+6hgIlHgOpn2Cg5JGqhDI 2cl2HTJRfDqvzUZQVSeDweFKi6JgPnzhrmMS550bGMwVYQYb9tb/nYCKznpUcRnTyL9o cWvCxk01y0E/ajujiAVN/yu8O53/baHzpTOYkowpZxY4UFu0lMDGSPKGN8PT8dr+s+8t HvMw== MIME-Version: 1.0 X-Received: by 10.152.36.102 with SMTP id p6mr32885999laj.19.1438091424491; Tue, 28 Jul 2015 06:50:24 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.25.31.75 with HTTP; Tue, 28 Jul 2015 06:50:24 -0700 (PDT) In-Reply-To: References: <20150725140840.20611.18415.idtracker@ietfa.amsl.com> <55B7506A.9040004@cs.tcd.ie> Date: Tue, 28 Jul 2015 14:50:24 +0100 X-Google-Sender-Auth: VyPK0TaF7ZEUh4VlPiV9PDvDKlQ Message-ID: From: Robert Cragie To: Ines Robles Content-Type: multipart/alternative; boundary=089e0158b7a482f371051befc013 Archived-At: Cc: roll-chairs@ietf.org, Routing Over Low power and Lossy networks , draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building@ietf.org, Yvonne-Anne Pignolet , draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-home-building-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 13:50:29 -0000 --089e0158b7a482f371051befc013 Content-Type: text/plain; charset=UTF-8 Ines - sounds good to me. Robert On 28 July 2015 at 13:00, Ines Robles wrote: > Hi, > > First two comments from ballotage [4] from v11: > > - 4.1.8: "MUST be present" is ambiguous - do you mean > it must be used? I think you do. > > Addressed: changed to " security MUST be used on all nodes" > > - 4.1.8: "MUST be distributed or established in a > secure fashion" isn't really a protocol requirement. > Do you really just mean "see 4.1.8.1" ? > > > In [1] states "Yes. It was meant more as an introductory statement but is > redundant really". > > For this sentence more clarification was added in 12: > > "A symmetric key is used to secure a RPL message using either RPL > message security or link-layer security. The symmetric key MUST be > distributed or established in a secure fashion. There may be more > than one symmetric key in use by any node at any one time. The same > symmetric key MUST NOT be used for both RPL message security and > link-layer security between two peer nodes." > > In [2] is suggested to remove the sentence, so it could be done by the RFC > Editor. Do you agree with that? > > > The other comments (v10) from ballotage are addressed as states in [3] > > [1] http://www.ietf.org/mail-archive/web/roll/current/msg09368.html > [2] http://www.ietf.org/mail-archive/web/roll/current/msg09388.html > [3] http://www.ietf.org/mail-archive/web/roll/current/msg09376.html > [4] > https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ballot/ > > I believe that the document is ready to go forward. > > Thank you very much for your hard work on this, > > Ines > > 2015-07-28 12:58 GMT+03:00 Robert Cragie : > >> Hi Stephen, >> >> Understood - thanks for the clarification. As mentioned, we did go >> through the comments and respond and make changes so will be happy to show >> these to the chairs/AD if required. >> >> Robert >> >> On 28 July 2015 at 10:50, Stephen Farrell >> wrote: >> >>> >>> Hiya, >>> >>> On 28/07/15 09:18, Robert Cragie wrote: >>> > Hi Stephen, >>> > >>> > Please see inline for specific responses. >>> > >>> > Regarding the old comments: We have tried to respond to these issues in >>> > previous follow up e-mails and modify the document in accordance with >>> the >>> > responses. Repeating these old comments suggests that neither those >>> > responses nor the updated text have been read yet. Please can you read >>> the >>> > responses and updated text before simply repeating these comments? >>> > Otherwise I can't see how we can make any progress on this. >>> >>> Sorry, we're talking past one another. The old comments are present in >>> the tracker and get attached to the email unless I go through them and >>> delete them manually. And since they are not blocking I don't spend >>> much time tracking if they have/haven't been addressed. And mostly I >>> forget once sufficient time has elapsed;-) In other words, it's up to >>> you and your AD if you want to consider them or not, I don't mind. >>> >>> So you can make progress on this in various ways. One is to just ignore >>> the comments. Another is to say "yeah, we know it's not blocking but >>> we'd actually like to chat about comment." Your chairs/AD may >>> have more ideas. >>> >>> But the main thing is that a "No Objection" ballot is just that, I >>> don't object to this moving ahead. >>> >>> So I'd say if there are any of the comments where you think it is >>> interesting to continue to chat, please just mail me about that but >>> there is no need to address each one in blow-by-blow fashion. If >>> you and your AD think there's no need for more chat, then we're done >>> already. >>> >>> Hope that helps, >>> S. >>> >>> >>> > >>> > Robert >>> > >>> > >>> > On 25 July 2015 at 15:08, Stephen Farrell >>> wrote: >>> > >>> >> Stephen Farrell has entered the following ballot position for >>> >> draft-ietf-roll-applicability-home-building-12: No Objection >>> >> >>> >> When responding, please keep the subject line intact and reply to all >>> >> email addresses included in the To and CC lines. (Feel free to cut >>> this >>> >> introductory paragraph, however.) >>> >> >>> >> >>> >> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> >> for more information about IESG DISCUSS and COMMENT positions. >>> >> >>> >> >>> >> The document, along with other ballot positions, can be found here: >>> >> >>> >> >>> https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ >>> >> >>> >> >>> >> >>> >> ---------------------------------------------------------------------- >>> >> COMMENT: >>> >> ---------------------------------------------------------------------- >>> >> >>> >> >>> >> Thanks for the discussion about security. I didn't check >>> >> if the comments below were handled in -12, happy to >>> >> chat about that if you want. >>> >> >>> >> First two comments are about text that's new in -11: >>> >> >>> >> - 4.1.8: "MUST be present" is ambiguous - do you mean >>> >> it must be used? I think you do. >>> >> >>> > >>> > This has been changed to "MUST be used on all nodes" in -12 >>> > >>> > >>> >> >>> >> - 4.1.8: "MUST be distributed or established in a >>> >> secure fashion" isn't really a protocol requirement. >>> >> Do you really just mean "see 4.1.8.1" ? >>> >> >>> > >>> > As mentioned before, this is just introductory. I suggest >>> removing the >>> > sentence to close the comment. >>> > >>> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > --089e0158b7a482f371051befc013 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ines - sounds good to me.

Robert
<= /div>

On 28 July 2= 015 at 13:00, Ines Robles <mariainesrobles@googlemail.com> wrote:
Hi,<= div>
First two comments from ballotage [4] from v11:

- 4.1.8: "MUST be present"= is ambiguous - do you mean
it must be used? I think you do.

Addressed: changed to " security MUST be u= sed on all nodes"

- 4.1.8: &= quot;MUST be distributed or established in a
secure fashion"= isn't really a protocol requirement.
Do you really just mean= "see 4.1.8.1" ?


I= n [1] states "Yes. It was meant more as an introductory statement but = is redundant really".

For this sentence more = clarification was added in 12:=C2=A0

"A symme= tric key is used to secure a RPL message using either RPL
message security or link-layer securi= ty.=C2=A0 The symmetric key MUST be
distributed or established in a secure fashion.=C2=A0 There= may be more
than on= e symmetric key in use by any node at any one time.=C2=A0 The same
symmetric key MUST NOT be us= ed for both RPL message security and <= /span>
link-layer security between two peer nodes."

In [2] is suggested to remove the sentence, so it could be= done by the RFC Editor. Do you agree with that?

<= br>
The other comments =C2=A0(v10) from ballotage are addressed a= s states in [3]


I believe that the docu= ment is ready to go forward.

Thank you very much f= or your hard work on this,

Ines
<= div class=3D"gmail_extra">
2015-07-28 12:58 GMT+03:00 Robert Cragie <robert.cragie@gri= dmerge.com>:
Hi Stephen,

Unders= tood - thanks for the clarification. As mentioned, we did go through the co= mments and respond and make changes so will be happy to show these to the c= hairs/AD if required.

Robert

On 28 July 2015 a= t 10:50, Stephen Farrell <stephen.farrell@cs.tcd.ie>= wrote:

Hiya,

On 28/07/15 09:18, Robert Cragie wrote:
> Hi Stephen,
>
> Please see inline for specific responses.
>
> Regarding the old comments: We have tried to respond to these issues i= n
> previous follow up e-mails and modify the document in accordance with = the
> responses. Repeating these old comments suggests that neither those > responses nor the updated text have been read yet. Please can you read= the
> responses and updated text before simply repeating these comments?
> Otherwise I can't see how we can make any progress on this.

Sorry, we're talking past one another. The old comments are pres= ent in
the tracker and get attached to the email unless I go through them and
delete them manually. And since they are not blocking I don't spend
much time tracking if they have/haven't been addressed. And mostly I forget once sufficient time has elapsed;-) In other words, it's up to you and your AD if you want to consider them or not, I don't mind.

So you can make progress on this in various ways. One is to just ignore
the comments. Another is to say "yeah, we know it's not blocking b= ut
we'd actually like to chat about <this> comment." Your chair= s/AD may
have more ideas.

But the main thing is that a "No Objection" ballot is just that, = I
don't object to this moving ahead.

So I'd say if there are any of the comments where you think it is
interesting to continue to chat, please just mail me about that but
there is no need to address each one in blow-by-blow fashion. If
you and your AD think there's no need for more chat, then we're don= e
already.

Hope that helps,
S.


>
> Robert
>
>
> On 25 July 2015 at 15:08, Stephen Farrell <stephen.farrell@cs.tcd.ie> wr= ote:
>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-roll-applicability-home-building-12: No Objection
>>
>> When responding, please keep the subject line intact and reply to = all
>> email addresses included in the To and CC lines. (Feel free to cut= this
>> introductory paragraph, however.)
>>
>>
 >> Please refer to https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COM= MENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here= :
>>
 >> https://datatr= acker.ietf.org/doc/draft-ietf-roll-applicability-home-building/
>>
>>
>>
>> -------------------------------------------= ---------------------------
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>>
>> Thanks for the discussion about security. I didn't check
>> if the comments below were handled in -12, happy to
>> chat about that if you want.
>>
>> First two comments are about text that's new in -11:
>>
>> - 4.1.8: "MUST be present" is ambiguous - do you mean >> it must be used? I think you do.
>>
>
> <RCC>This has been changed to "MUST be used on all nodes&qu= ot; in -12</RCC>
>
>
>>
>> - 4.1.8: "MUST be distributed or established in a
>> secure fashion" isn't really a protocol requirement.
>> Do you really just mean "see 4.1.8.1" ?
>>
>
> <RCC>As mentioned before, this is just introductory. I suggest r= emoving the
> sentence to close the comment.</RCC>
>


__________________________________________= _____
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll



--089e0158b7a482f371051befc013-- From nobody Wed Jul 29 13:13:20 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4620A1B2C29; Wed, 29 Jul 2015 10:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYbUPhRQM443; Wed, 29 Jul 2015 10:45:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 510351A906F; Wed, 29 Jul 2015 10:45:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: X-Test-IDTracker: no X-IETF-IDTracker: 6.2.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150729174543.21912.25744.idtracker@ietfa.amsl.com> Date: Wed, 29 Jul 2015 10:45:43 -0700 Archived-At: X-Mailman-Approved-At: Wed, 29 Jul 2015 13:13:19 -0700 Cc: rdroms@cisco.com, Deborah Brungard , Michael Richardson , Routing Over Low power and Lossy networks Discussion List , Alia Atlas , Ines Robles , scott.mansfield@ericsson.com Subject: [Roll] New Liaison Statement, "Response to LS on concerns on the deprecation of dispatch type in 6loWPAN and its header compression mechanism to roll" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 17:45:45 -0000 Title: Response to LS on concerns on the deprecation of dispatch type in 6loWPAN and its header compression mechanism to roll Submission Date: 2015-07-29 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1426/ From: Routing Over Low power and Lossy networks (Scott Mansfield ) To: ITU-T SG 15 (tsbsg15@itu.int) Cc: John Drake ,Scott Mansfield ,Ines Robles ,Michael Richardson ,Alia Atlas ,Alvaro Retana ,Deborah Brungard ,Routing Over Low power and Lossy networks Discussion List Response Contact: scott.mansfield@ericsson.com Technical Contact: rdroms@cisco.com Purpose: In response Referenced liaison: LS on concerns on the deprecation of dispatch type in 6loWPAN and its header compression mechanism to roll (https://datatracker.ietf.org/liaison/1415/) Body: The IETF will not change the definitions of the code points specified in RFC 4944 and RFC 6282, as published in IANA registry "IPv6 Low Power Personal Area Network Parameters" , in such a way as to affect the ITU-T G.9903 (02/2014: Table 9-35 - Command frame header identifier) and G.9905 (08/2013: Table 7-1 - Command ID used in ADP layer and Table 7-1a - Message type) specifications. The IETF 6lo working group offers to collaborate with ITU-T SG15 in establishing a new registry maintained by IANA for the code points following the ESC dispatch code. This new registry will be populated at the time of its establishment with the Command ID values as already defined in G.9903 and G.9905. We welcome experts also active in SG15 to participate in our next meeting: IETF 6lo and ROLL Working Groups meeting, 1 - 6 November 2015, Yokohama (http://ietf.org/meeting/94/index.html) Scott Mansfield Ericsson Inc. +1 724 931 9316 Attachments: No document has been attached