From nobody Wed Apr 1 07: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 21FD61A1A67 for ; Wed, 1 Apr 2015 07:48:31 -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 2wvv3dllSZ81 for ; Wed, 1 Apr 2015 07:48:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF0F1AC409 for ; Wed, 1 Apr 2015 07:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=279; q=dns/txt; s=iport; t=1427899710; x=1429109310; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=OJFa2yHfmFWtIxKxaE1zqDCHSTUUtmY9Y2MqomVEYGU=; b=EK70s8F4QebxYVqaRgjs5O1XSBprRBtAMKcGc9ehEPuI+N6zdE9oxdha wsE3LQAaJ5DC7xE+LEUg9ke+FYxgKgbg+c2jbUJ56C99S55M10mmu45W0 QgGtQS6bpo+Li1zWITYlFeDpi2oefYCe9sQNpXwgKC3edaT9XAf1N/W4C c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AFBQAYBRxV/4ENJK1cgwaBM80JTAEBAQEBAX2EGzpRAT5CJwSIQqV7qHsBAQEBBgEBAQEBAQEbkz+BFgWQY4l2lD4ig26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,504,1422921600"; d="scan'208";a="557635" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 01 Apr 2015 14:48:09 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t31Em9Tu010159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Apr 2015 14:48:09 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.86]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 1 Apr 2015 09:48:09 -0500 From: "Ralph Droms (rdroms)" To: Routing Over Low power and Lossy networks Thread-Topic: Looking for Linux implementation of RPL for interop testing Thread-Index: AQHQbIre4/FtDPIGg0SXIQND1/xNyw== Date: Wed, 1 Apr 2015 14:48:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.44] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Roll] Looking for Linux implementation of RPL for interop testing 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 Apr 2015 14:48:31 -0000 Can anyone point me at an implementation of RPL for Linux that provides non= -storing mode operation? I'm looking for both an LBR/DODAG root implementa= tion and an LR implementation. THe purpose is interoperability testing wit= h an independent implementation. - Ralph From nobody Thu Apr 2 00:53: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 6FF6B1A89FC; Thu, 2 Apr 2015 00:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, 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 vrQ8df48hhTI; Thu, 2 Apr 2015 00:53:22 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DF81A8997; Thu, 2 Apr 2015 00:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4065; q=dns/txt; s=iport; t=1427961202; x=1429170802; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2q7z1n5hDTgJ8BgbnX30l9wIyS2rcOy4KplVzoOAUMw=; b=bKwwCHSP2IYh3QbbI2WJfVA5xY292CZrirnQunMj+bThKBp8F/bO5VDC jI37exPNt8TYmSA+CtTCEJIfYf7LVI/C/37dWHRig21DuLDadTf8nuKkZ DS9NMI8y5W4O1y1Bs8VBvo1fX3bdKxgmmz96ZTYmJl72Zv2LbEG3qyrpC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DiBgBS9BxV/4YNJK1cgwiBLsMMiC8CgUBMAQEBAQEBfoQfAQEDAXkQAgEIDjgyJQIEDgWIJwjMdgEBAQEBAQEBAQEBAQEBAQEBAQEBAReKKn+EIQYBAQEcMweDF4EWBYpuhXaJdoEdj1yDSCKDbm+BAgEGAheBIQEBAQ X-IronPort-AV: E=Sophos;i="5.11,509,1422921600"; d="scan'208";a="775824" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 02 Apr 2015 07:53:22 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t327rLkA032175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 07:53:21 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 02:53:21 -0500 From: "Pascal Thubert (pthubert)" To: Juliusz Chroboczek Thread-Topic: [manet] Working group re-charter ideas (meeting summary) Thread-Index: AQHQaWOdwXJuyKRYmEO7ZSTTVbCP4p0yRRxBgAbFOQCAAFcQPQ== Date: Thu, 2 Apr 2015 07:53:20 +0000 Message-ID: References: , <87twwzzftz.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87twwzzftz.wl-jch@pps.univ-paris-diderot.fr> 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: Cc: ROLL WG , "manet@ietf.org" Subject: Re: [Roll] [manet] Working group re-charter ideas (meeting summary) 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 Apr 2015 07:53:24 -0000 I disagree with the terms in your mail pretty much as much as I agree with = your designs, Juliusz... There are literally hundreds of papers that reference RPL, from Google scho= lar. There are deployed networks of thousands of nodes, and they behave even bet= ter than expected. But what hurts even more is your misunderstanding of the technology: RPL inherits from the same roots as Babel, DSDV and DUAL/EIGRP, though RPL = adds technology to cope with harsher constraints and multiple types of link= s that neither Babel nor any of the common ancestry has. You do not seem to have fully realized how similar Babel is to RPL. Conside= r this: RPL's sequenced advertisement is called the iteration of an instanc= e; so the process of microloop avoidance in Babel is effectively the same a= s what RPL calls a global recovery. Both protocols inherit DUAL's feasibili= ty condition. But RPL adds the capability to make local repair which provid= es a service of freezing akin to the the diffusion algorithm but adapted to= LLN and MANET.=20 Even more, RPL adds a capability to stretch the rules, and a capability to = delay the repairs so as to reduce the control overhead in Lower Power and m= obile use cases. To enable these - arguably optional - features, RPL adds t= he capability to instrument packets beyond hop limit to detect loops and tr= igger repairs. Saying the RPL does not work in MANET environment is a gross misrepresentat= ion. RPL derives from early MANEMO work, which was MANET for NEMO, and it w= as fully demonstrated in that space. RPL works fine in MANET for the same r= easons Babel will. And RPL probably works a lot better because it can: - cope with all sorts of radios with objective functions=20 - allow a trade off of routing stretch vs control plane overhead=20 - address memory constraints=20 - natively support interconnection with LLNs - freeze a zone and perform local repairs - support multiple exits. RPL's instances avoid the need for source/destina= tion routing altogether All in all I remain to be convinced that Babel is much, much, anything. In = my view, it is a great approach but I will need more details to find novelt= y vs. an existing proposed std RFC that is RFC 6550. You will need to demon= strate that novelty to get a new work approved. We went through that in the= first phase of ROLL. And I would be interested in bringing back that novel= ty in RPL. On the side there are multiple implementations of RPL. Some on constrained = devices. 2 on Linux, one of them at least running on OpenWRT (Unstrung). We= even have one running on various network OS'es that Cisco ships in its big= irons, and applicable from gigE to virtual links. All in all, there's a lot of misconceptions that a discussion over a whiteb= oard could help clarify. I'm certainly willing to learn more from Babel and= I trust that you'd need some catching up on RPL before you can discuss it = decently, which sadly was not the case in this mail. I would be glad to meet anytime. We are almost next door... Cheers, Pascal Le 1 avr. 2015 =E0 23:41, Juliusz Chroboczek a =E9crit : >> Any contribution you'd want to make to ROLL? This is probably the place >> where the ideas you defend in Babel were most successful... >=20 > I hope you are not comparing RPL's proactive subset to Babel. Babel is > a much, much more refined and complete protocol. >=20 > Which is okay, since RPL's proactive subset is designed to work in > a stable network with a single DODAG. Babel is aimed at a completely > different space -- which is why it has redundant routing tables, attempts > stability in the presence of variable metrics, has strong loop avoidance > properties, and includes blackhole resolution. >=20 > By the way -- I've tried to find experimental data on RPL, and couldn't > find any (perhaps I haven't tried hard enough). Could you send me some > references, perhaps by private mail? >=20 > -- Juliusz From nobody Thu Apr 2 01:30: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 161D91A8A90; Thu, 2 Apr 2015 01:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, 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 Io_qlSjVRnVE; Thu, 2 Apr 2015 01:30:21 -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 EBEB81A8AA5; Thu, 2 Apr 2015 01:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10563; q=dns/txt; s=iport; t=1427963421; x=1429173021; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VDgAPhubo6DXqfgJGeCvSuYqx1ynLDTe4tWxay8lPtQ=; b=kEJlX+VRtpKKljAggDQw5bcGeRdBqXA3PwvoXV3uWn+qDzCuVG18Am0g UAKgE1KfJgHXtI/ZJ3qqZc3gusLIdo6MwmI3Nld4khDCe2lfia1wLSyWQ rCNjK2EuDNjxt2714y3vFej0MW7y4pon2RylgSANwgGgCBxqO/eztwldX U=; X-Files: smime.p7s : 3862 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGBQBo/RxV/5ldJa1cgwhSXAXFQQqFcwKBQEwBAQEBAQF+hB4BAQEDAQEBAWsLBQsCAQgOCi4CJQslAgQBDQUOiBkIDcxwAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKKn+EIQYBAQFPB4MXgRYFjlWCD4FsgTKCeoNegR2PXINIIoNub4ECAQYCFyJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,509,1422921600"; d="p7s'?scan'208";a="137614645" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 02 Apr 2015 08:30:20 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t328UJCF021018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 08:30:20 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.253]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 03:30:19 -0500 From: "JP Vasseur (jvasseur)" To: Juliusz Chroboczek , "Pascal Thubert (pthubert)" Thread-Topic: [manet] Working group re-charter ideas (meeting summary) Thread-Index: AQHQbR9AU18Lqg+AfE6rBUKLduipcg== Date: Thu, 2 Apr 2015 08:30:19 +0000 Message-ID: References: <,> <87twwzzftz.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.232] Content-Type: multipart/signed; boundary="Apple-Mail=_2D2B0045-47FF-4EAC-B143-7785BB9D41D1"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: ROLL WG , "manet@ietf.org" Subject: Re: [Roll] [manet] Working group re-charter ideas (meeting summary) 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 Apr 2015 08:30:23 -0000 --Apple-Mail=_2D2B0045-47FF-4EAC-B143-7785BB9D41D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Juliusz, Just chiming in here =85 since indeed you may want to have a deeper look = into the several RFC specifying RPL. Furthermore, beyond novelty, I would stress the fact that RPL has been = deployed in a NUMBER of networks,=20 at large scale (order of magnitude is millions) and showed outstanding = results in the field, remember what the IETF thinks about =93running code=94 =85 Thanks. JP. > On Apr 2, 2015, at 9:53 AM, Pascal Thubert (pthubert) = wrote: >=20 > I disagree with the terms in your mail pretty much as much as I agree = with your designs, Juliusz... >=20 > There are literally hundreds of papers that reference RPL, from Google = scholar. >=20 > There are deployed networks of thousands of nodes, and they behave = even better than expected. >=20 > But what hurts even more is your misunderstanding of the technology: >=20 > RPL inherits from the same roots as Babel, DSDV and DUAL/EIGRP, though = RPL adds technology to cope with harsher constraints and multiple types = of links that neither Babel nor any of the common ancestry has. >=20 > You do not seem to have fully realized how similar Babel is to RPL. = Consider this: RPL's sequenced advertisement is called the iteration of = an instance; so the process of microloop avoidance in Babel is = effectively the same as what RPL calls a global recovery. Both protocols = inherit DUAL's feasibility condition. But RPL adds the capability to = make local repair which provides a service of freezing akin to the the = diffusion algorithm but adapted to LLN and MANET.=20 >=20 > Even more, RPL adds a capability to stretch the rules, and a = capability to delay the repairs so as to reduce the control overhead in = Lower Power and mobile use cases. To enable these - arguably optional - = features, RPL adds the capability to instrument packets beyond hop limit = to detect loops and trigger repairs. >=20 > Saying the RPL does not work in MANET environment is a gross = misrepresentation. RPL derives from early MANEMO work, which was MANET = for NEMO, and it was fully demonstrated in that space. RPL works fine in = MANET for the same reasons Babel will. And RPL probably works a lot = better because it can: > - cope with all sorts of radios with objective functions=20 > - allow a trade off of routing stretch vs control plane overhead=20 > - address memory constraints=20 > - natively support interconnection with LLNs > - freeze a zone and perform local repairs > - support multiple exits. RPL's instances avoid the need for = source/destination routing altogether >=20 > All in all I remain to be convinced that Babel is much, much, = anything. In my view, it is a great approach but I will need more = details to find novelty vs. an existing proposed std RFC that is RFC = 6550. You will need to demonstrate that novelty to get a new work = approved. We went through that in the first phase of ROLL. And I would = be interested in bringing back that novelty in RPL. >=20 > On the side there are multiple implementations of RPL. Some on = constrained devices. 2 on Linux, one of them at least running on OpenWRT = (Unstrung). We even have one running on various network OS'es that Cisco = ships in its big irons, and applicable from gigE to virtual links. >=20 > All in all, there's a lot of misconceptions that a discussion over a = whiteboard could help clarify. I'm certainly willing to learn more from = Babel and I trust that you'd need some catching up on RPL before you can = discuss it decently, which sadly was not the case in this mail. >=20 > I would be glad to meet anytime. We are almost next door... >=20 > Cheers, >=20 > Pascal >=20 > Le 1 avr. 2015 =E0 23:41, Juliusz Chroboczek = a =E9crit : >=20 >>> Any contribution you'd want to make to ROLL? This is probably the = place >>> where the ideas you defend in Babel were most successful... >>=20 >> I hope you are not comparing RPL's proactive subset to Babel. Babel = is >> a much, much more refined and complete protocol. >>=20 >> Which is okay, since RPL's proactive subset is designed to work in >> a stable network with a single DODAG. Babel is aimed at a completely >> different space -- which is why it has redundant routing tables, = attempts >> stability in the presence of variable metrics, has strong loop = avoidance >> properties, and includes blackhole resolution. >>=20 >> By the way -- I've tried to find experimental data on RPL, and = couldn't >> find any (perhaps I haven't tried hard enough). Could you send me = some >> references, perhaps by private mail? >>=20 >> -- Juliusz >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_2D2B0045-47FF-4EAC-B143-7785BB9D41D1 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHjCCBTAw ggQYoAMCAQICEQDVs65XZh59t2IXVyBjHIr6MA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDExMjQwMDAwMDBaFw0xNTExMjQyMzU5NTla MCMxITAfBgkqhkiG9w0BCQEWEmp2YXNzZXVyQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMnOoDwgfyigTrGJQkL+oeRZ/jELtw6kVKr5mYh1odj7ez8u8cPbZVsgvuLu UKGl6qjUjPd0kYgUR49lQynBhdY98L6MGHLTCtp6GIn4Ux3Kfk5lZvU/hgDveiDYbQNkYvjL2B1m vrr+lM/0E1b1qLNxRhePGy3GT0pSgi3wKfhEmUwMXayHZ3Vly0ugYH4idrBPcsBL9WNBDi7BYVCE ntzv2QVuB6fLuddurd+HAvJs7HT7NFwkS8O3sGhAmAz94yXsml9XtJEePaI0EzgXueK3bYUnYvPF rg44+v20UlVaY1+6vQYecBOXjxlOsprD+YKtGqaKew/Q7LMl4q3B070CAwEAAaOCAegwggHkMB8G A1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBS6q/3WoBmfGTrzbfUh6da/ TnTZwDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB0GA1Ud EQQWMBSBEmp2YXNzZXVyQGNpc2NvLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAVU6J5QAmIVAp5ErX b2t86SQefahFFBTZOdnkl//UAqsyDrxaLBLGylM4Ve8sm1UwXO645rwT+UGPBYdOI6JSMAjYgDtd DUzfASU2za3L08OSrF0uaDWc2NpTNn80jGIH5CdP/IC8op6r2ee8P9vOOyFtqz57q4SIOT/qZmNR YA2XWO1mxl3kM6UVTf37lPxkJa3FBg5U8S702Cw9wyM1oUn3DUnmhf16hDdxYYaFzIaEmTQk9QRd 5xxwTcoBMaJufdhmwwoCdWW2RmWmrNUORzYkt6Fp/Lv5KjNsOK7PLuU1VnvFqOeMj1jzWi6twhJp RfAuAqj912Sj0ykTBvWtLjCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcN AQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8g UlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1 OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSR sivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66 nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCC ATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgw BgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9S U0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE88 7l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBx huhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77 zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fy adqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttN tjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzg kejL580ul+9hz9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydeh zuZutLbZdRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgk L3VYnwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YC AQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA1bOuV2Yefbdi F1cgYxyK+jAJBgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNTA0MDIwODMwMThaMCMGCSqGSIb3DQEJBDEWBBQr/VaH5EyGtTRT/LFVKMIHsE0C kzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9 MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIRANWzrldmHn23YhdXIGMcivowgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANWzrldmHn23YhdXIGMcivowDQYJKoZIhvcN AQEBBQAEggEAY9Nf87ysqjNeGbx/RgsiKw3s3PKzexAs2wOX1m7x/EbpR43g3G6xgp5PkOP3izyg 67scjvGPPTRtWu3O4Ugjb3Er6m5CLHWmVS+b+eHH3uJ1zwtPHiMyPh7m8kevqDidjARFWT3LUnAF 85l/sthcFVODcEbZmKU7+IfCphVgA+k1Lobs8OQxpkVtYxh3pDFDyB23BzhcsYI2HYdNA1+y6DoN qRNXEehC5b9oUoTMBhgK6g7M0ePV5rgTJIeAMJA9BfETDQ2piee3QwtqGevJ4epTLxsxZoDVEKeB sYa26ZP+eaWNTY09VtzcsEG0o7kKL1WMAPEQfke+WfUbYbCaJwAAAAAAAA== --Apple-Mail=_2D2B0045-47FF-4EAC-B143-7785BB9D41D1-- From nobody Thu Apr 2 02:20:30 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 53B251B2C29 for ; Thu, 2 Apr 2015 02:20:28 -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 pRgaViCWiSFO for ; Thu, 2 Apr 2015 02:20:24 -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 418501B2C26 for ; Thu, 2 Apr 2015 02:20:24 -0700 (PDT) Received: from localhost ([::1]:39989 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdbIQ-0008Hk-H3; Thu, 02 Apr 2015 02:20:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 02 Apr 2015 09:20:18 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/159#comment:3 Message-ID: <082.8d9ba208fa3921835ac558ae2d2ce582@trac.tools.ietf.org> References: <067.c7da094778f4c5d6eac57429dda91b84@trac.tools.ietf.org> X-Trac-Ticket-ID: 159 In-Reply-To: <067.c7da094778f4c5d6eac57429dda91b84@trac.tools.ietf.org> 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: Re: [Roll] [roll] #159 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Format to encode timers 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: Thu, 02 Apr 2015 09:20:28 -0000 #159: mpl-parameter-configuration-00 - Format to encode timers Changes (by mariainesrobles@gmail.com): * status: new => closed * resolution: => fixed Comment: Source: https://tools.ietf.org/html/draft-ietf-roll-mpl-parameter- configuration-03 Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll- mpl-configuration-02: o Short unsigned floating point is dropped (#159) o Packed value is removed and now every value has its own byte(s) (#159) -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | yusuke.doi@toshiba.co.jp Type: defect | Status: closed Priority: major | Milestone: Component: draft-doi-roll-mpl- | Version: parameter-configuration | Resolution: fixed Severity: Active WG Document | Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Apr 2 04:27: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 7ADC11B2C6D for ; Thu, 2 Apr 2015 04:27:45 -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=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 F5JT89yvu19o for ; Thu, 2 Apr 2015 04:27:44 -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 666411B2C6C for ; Thu, 2 Apr 2015 04:27:44 -0700 (PDT) Received: from localhost ([::1]:48262 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YddHg-00078E-3l; Thu, 02 Apr 2015 04:27:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 02 Apr 2015 11:27:39 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/157#comment:3 Message-ID: <082.7693d43be700ddc22a4a083f51e361e7@trac.tools.ietf.org> References: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> X-Trac-Ticket-ID: 157 In-Reply-To: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org, mariainesrobles@gmail.com, yusuke.doi@toshiba.co.jp, 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 Resent-To: draft-doi-roll-mpl-parameter-configuration@ietf.org Resent-Message-Id: <20150402112744.666411B2C6C@ietfa.amsl.com> Resent-Date: Thu, 2 Apr 2015 04:27:44 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Archived-At: Cc: roll@ietf.org Subject: Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes 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: Thu, 02 Apr 2015 11:27:45 -0000 #157: mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes Changes (by mariainesrobles@gmail.com): * status: new => closed * resolution: => fixed Comment: Source:http://tools.ietf.org/html/draft-ietf-roll-mpl-parameter- configuration-03 Updates on draft-ietf-roll-mpl-configuration-00 to draft-ietf-roll- mpl-configuration-01: o Operational considerations (normative) and appendix considerations (non-normative) are added (Issue #157) -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-doi-roll-mpl- mariainesrobles@gmail.com | parameter- Type: defect | configuration@tools.ietf.org Priority: major | Status: closed Component: draft-doi-roll-mpl- | Milestone: parameter-configuration | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Apr 2 04:30: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 4EAEB1B2C6D for ; Thu, 2 Apr 2015 04:30:05 -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 aC1ObVupS1Qg for ; Thu, 2 Apr 2015 04:30:04 -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 286AF1B2C69 for ; Thu, 2 Apr 2015 04:30:04 -0700 (PDT) Received: from localhost ([::1]:48363 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YddJU-0003jS-R7; Thu, 02 Apr 2015 04:30:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 02 Apr 2015 11:29:32 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/158#comment:4 Message-ID: <082.ca441ddb3c2a0d887da3293014902dcf@trac.tools.ietf.org> References: <067.fdecb6fad4434045459c5bca247c467e@trac.tools.ietf.org> X-Trac-Ticket-ID: 158 In-Reply-To: <067.fdecb6fad4434045459c5bca247c467e@trac.tools.ietf.org> 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: Re: [Roll] [roll] #158 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - new MPL domain 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: Thu, 02 Apr 2015 11:30:05 -0000 #158: mpl-parameter-configuration-00 - new MPL domain Changes (by mariainesrobles@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | yusuke.doi@toshiba.co.jp Type: defect | Status: closed Priority: major | Milestone: Component: draft-doi-roll-mpl- | Version: parameter-configuration | Resolution: fixed Severity: Active WG Document | Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Apr 2 04:30: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 7713F1B2C75 for ; Thu, 2 Apr 2015 04:30:11 -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 qJ7XWfIy8nxO for ; Thu, 2 Apr 2015 04:30:04 -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 514E71B2C6C for ; Thu, 2 Apr 2015 04:30:04 -0700 (PDT) Received: from localhost ([::1]:48333 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YddJ2-0002Wt-MT; Thu, 02 Apr 2015 04:29:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 02 Apr 2015 11:29:04 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/158#comment:3 Message-ID: <082.31292a0f2c44ac48675a62fcad418a56@trac.tools.ietf.org> References: <067.fdecb6fad4434045459c5bca247c467e@trac.tools.ietf.org> X-Trac-Ticket-ID: 158 In-Reply-To: <067.fdecb6fad4434045459c5bca247c467e@trac.tools.ietf.org> 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: Re: [Roll] [roll] #158 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - new MPL domain 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: Thu, 02 Apr 2015 11:30:11 -0000 #158: mpl-parameter-configuration-00 - new MPL domain Comment (by mariainesrobles@gmail.com): Source: http://tools.ietf.org/html/draft-ietf-roll-mpl-parameter- configuration-03 Updates on draft-ietf-roll-mpl-configuration-00 to draft-ietf-roll- mpl-configuration-01: o More control on nodes / allow constrained nodes to ignore the configuration: "the node s/SHOULD/MAY/ join the MPL domain given by the option" (Issue #158) -- -------------------------------------+------------------------------------- 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 | Resolution: Severity: Active WG Document | Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Apr 2 05:55: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 426251B2C9C; Thu, 2 Apr 2015 05:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] 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 D3pHLGnZDyxL; Thu, 2 Apr 2015 05:55:33 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BC11ACED6; Thu, 2 Apr 2015 05:55:16 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t32CtCHA004285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2015 14:55:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id t32CtCT0029133; Thu, 2 Apr 2015 14:55:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 6CDCE2A0C8D; Thu, 2 Apr 2015 14:55:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id tY0YslvWqjl5; Thu, 2 Apr 2015 14:55:10 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 901212A0C8C; Thu, 2 Apr 2015 14:55:10 +0200 (CEST) Date: Thu, 02 Apr 2015 14:55:24 +0200 Message-ID: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Pascal Thubert (pthubert)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 02 Apr 2015 14:55:12 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 02 Apr 2015 14:55:12 +0200 (CEST) X-Miltered: at korolev with ID 551D3C30.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 551D3C30.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551D3C30.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 551D3C30.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 551D3C30.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 551D3C30.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: ROLL WG , "manet@ietf.org" Subject: [Roll] Understanding RPL [was: Working group re-charter ideas] 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 Apr 2015 12:55:35 -0000 Thanks for your answer, Pascal. > There are literally hundreds of papers that reference RPL, Indeed. But I've made a half-serious attempt at a bibliography search, and couldn't find anything to satisfy my thirst for experimental data, especially for the proactive subset. Could you please give me a reference? > so the process of microloop avoidance in Babel is effectively the same > as what RPL calls a global recovery. Both protocols inherit DUAL's > feasibility condition. My perhaps mistaken understanding is that RPL uses a more primitive version of DSDV's feasibility condition (without the even-odd mechanism that avoids loops after a retraction). If RPL uses DUAL feasibility, then I completely fail to see the data structure that keeps the necessary history (the equivalent of Babel's source table). (Which makes sense for RPL -- you certainly don't want to multiply the data structures being held in a sensor. Babel and RPL play in different spaces, right?) > But RPL adds the capability to make local repair which provides > a service of freezing akin to the the diffusion algorithm but adapted to > LLN and MANET. Again, I may be confused, but I think the local repair mechanism is not specified in the RFC. There's an example mechanism given in Section 3.7.2, but that example is prone to loops in the presence of packet loss. As what RPL calls a "global repair", all I could find in the RFC is A DODAG root institutes a global repair operation by incrementing the DODAGVersionNumber. This initiates a new DODAG Version. However, there's nothing I see to say when a root decides to trigger a global repair (except for some vague mention of periodic updates, which the DSDV experiment has shown are not a good idea). This is very much unlike Babel (different spaces, remember?) which has a provably complete reactive mechanism for triggering seqno updates. > Even more, RPL adds a capability to stretch the rules, and a capability to > delay the repairs so as to reduce the control overhead in Lower Power and > mobile use cases. Yes. That's probably a very good feature in the space where RPL plays. Which is different from the space that Babel aims for. > All in all I remain to be convinced that Babel is much, much, anything. That citation belongs on the conclusion slide of the next talk I give ;-) -- Juliusz From nobody Thu Apr 2 06:30: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 498EA1A0161; Thu, 2 Apr 2015 06:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 ylZmyh0TlPur; Thu, 2 Apr 2015 06:30:00 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0605.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::605]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61AC1A8AD7; Thu, 2 Apr 2015 06:29:56 -0700 (PDT) Received: from DB4PR06MB047.eurprd06.prod.outlook.com (10.242.154.154) by DB4PR06MB048.eurprd06.prod.outlook.com (10.242.154.155) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 2 Apr 2015 13:11:59 +0000 Received: from DB4PR06MB047.eurprd06.prod.outlook.com ([169.254.14.105]) by DB4PR06MB047.eurprd06.prod.outlook.com ([169.254.14.105]) with mapi id 15.01.0125.002; Thu, 2 Apr 2015 13:11:59 +0000 From: Yvonne-Anne Pignolet To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" Thread-Topic: [Roll] Understanding RPL [was: Working group re-charter ideas] Thread-Index: AQHQbURbA3RRxwyg40O6DMQHrMeTkJ05sPmQ Date: Thu, 2 Apr 2015 13:11:59 +0000 Message-ID: References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.75.192.109] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB048; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(13464003)(76176999)(54356999)(15975445007)(19580395003)(2656002)(122556002)(87936001)(46102003)(19580405001)(2900100001)(77156002)(102836002)(62966003)(2950100001)(33656002)(86362001)(74316001)(50986999)(66066001)(106116001)(76576001)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR06MB048; H:DB4PR06MB047.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DB4PR06MB048; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB048; x-forefront-prvs: 0534947130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ch.abb.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 13:11:59.4325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 372ee9e0-9ce0-4033-a64a-c07073a91ecd X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB048 Archived-At: Cc: "manet@ietf.org" Subject: Re: [Roll] Understanding RPL [was: Working group re-charter ideas] 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 Apr 2015 13:30:03 -0000 Hi Juliusz Some papers dealing with the RPL repair and loop avoidance mechanisms (and = exlaining them) are for example - A Study of the RPL Repair Process Using ContikiRPL, http://link.springer.= com/chapter/10.1007%2F978-3-642-30633-4_8 - Efficiency of the RPL repair mechanisms for Low Power and Lossy Networks,= http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D6906339&url=3Dht= tp%3A%2F%2Fieeexplore.ieee.org%2Fiel7%2F6895209%2F6906315%2F06906339.pdf%3F= arnumber%3D6906339 - Doing it right - Recommendations for RPL in PLC-based networks for the Sm= art Grid, http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D7007= 688 - Recipes for faster failure recovery in Smart Grid communication networks,= http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D7007654&url=3Dht= tp%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D7007654 Regards Yvonne-Anne -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Juliusz Chroboczek Sent: Donnerstag, 2. April 2015 14:55 To: Pascal Thubert (pthubert) Cc: ROLL WG; manet@ietf.org Subject: [Roll] Understanding RPL [was: Working group re-charter ideas] Thanks for your answer, Pascal. > There are literally hundreds of papers that reference RPL, Indeed. But I've made a half-serious attempt at a bibliography search, and= couldn't find anything to satisfy my thirst for experimental data, especia= lly for the proactive subset. Could you please give me a reference? > so the process of microloop avoidance in Babel is effectively the same=20 > as what RPL calls a global recovery. Both protocols inherit DUAL's=20 > feasibility condition. My perhaps mistaken understanding is that RPL uses a more primitive version= of DSDV's feasibility condition (without the even-odd mechanism that avoid= s loops after a retraction). If RPL uses DUAL feasibility, then I complete= ly fail to see the data structure that keeps the necessary history (the equ= ivalent of Babel's source table). (Which makes sense for RPL -- you certainly don't want to multiply the data= structures being held in a sensor. Babel and RPL play in different spaces= , right?) > But RPL adds the capability to make local repair which provides a=20 > service of freezing akin to the the diffusion algorithm but adapted to=20 > LLN and MANET. Again, I may be confused, but I think the local repair mechanism is not spe= cified in the RFC. There's an example mechanism given in Section 3.7.2, bu= t that example is prone to loops in the presence of packet loss. As what RPL calls a "global repair", all I could find in the RFC is A DODAG root institutes a global repair operation by incrementing the DODAGVersionNumber. This initiates a new DODAG Version. However, there's nothing I see to say when a root decides to trigger a glob= al repair (except for some vague mention of periodic updates, which the DSD= V experiment has shown are not a good idea). This is very much unlike Babe= l (different spaces, remember?) which has a provably complete reactive mec= hanism for triggering seqno updates. > Even more, RPL adds a capability to stretch the rules, and a=20 > capability to delay the repairs so as to reduce the control overhead=20 > in Lower Power and mobile use cases. Yes. That's probably a very good feature in the space where RPL plays. Which is different from the space that Babel aims for. > All in all I remain to be convinced that Babel is much, much, anything. That citation belongs on the conclusion slide of the next talk I give ;-) -- Juliusz _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Thu Apr 2 07:46:17 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 AED361B2D1E; Thu, 2 Apr 2015 07:46:13 -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 UGmS6fa6yPzI; Thu, 2 Apr 2015 07:46:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494371B2D18; Thu, 2 Apr 2015 07:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9604; q=dns/txt; s=iport; t=1427985971; x=1429195571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RKdgYDY1gNFp6IXuUpFrx/M8nI3M9u42FMV9Tqqpx4A=; b=jdKP/GowO6D04JFhc5Nly7gUUI7n/cMi0nIkO4hTrAboHfH5NQLulGHu IoxVMNSy0RfL+HsDj5YJVhejcEsFx0Zk8OQjMQinybO1SFFr/IWubAynx jzLtpw0u26OAdZNIUkdqXngzyH647+seuOw4X8whTfTIF9i2hxqeSsJ6q 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AEDACEVR1V/5pdJa1cgwiBM8MehHKDQAKBREwBAQEBAQF+hB4BAQEDATo/BQsCAQgOFBQQMiUCBA4NEQGIDQjOAwEBAQEBAQEDAQEBAQEBAQEaiip/hCAKHjEHgxeBFgWQaooBgRyDNIwvg0giggIcgVCBcUJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,511,1422921600"; d="scan'208";a="408665361" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 02 Apr 2015 14:46:10 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t32EkAsu017248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 14:46:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 09:46:10 -0500 From: "Pascal Thubert (pthubert)" To: Juliusz Chroboczek Thread-Topic: Understanding RPL [was: Working group re-charter ideas] Thread-Index: AQHQbUREgfg7pDtvIkm1HF6A+WKgZJ05rtKQ Date: Thu, 2 Apr 2015 14:46:09 +0000 Deferred-Delivery: Thu, 2 Apr 2015 14:45:00 +0000 Message-ID: References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ROLL WG , "manet@ietf.org" Subject: Re: [Roll] Understanding RPL [was: Working group re-charter ideas] 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 Apr 2015 14:46:13 -0000 Hello Juliusz:=20 > Indeed. But I've made a half-serious attempt at a bibliography search, a= nd > couldn't find anything to satisfy my thirst for experimental data, especi= ally for > the proactive subset. Could you please give me a reference? >=20 The references I'm aware of do belong to the private space of companies whi= ch make a living selling RPL devices.=20 Maybe people in the list have academic links? > > so the process of microloop avoidance in Babel is effectively the same > > as what RPL calls a global recovery. Both protocols inherit DUAL's > > feasibility condition. >=20 > My perhaps mistaken understanding is that RPL uses a more primitive versi= on of > DSDV's feasibility condition (without the even-odd mechanism that avoids = loops > after a retraction). If RPL uses DUAL feasibility, then I completely fai= l to see the > data structure that keeps the necessary history (the equivalent of Babel'= s source > table). That's all this discussion around that value L which is the smallest Rank a= node has had in a given DODAG for a given version. A DODAG gets to a number of routes as indicates by the RIO option with (pfx= ,plen) in the DIO via a root which is your router id. The router needs to maintain it value L per DODAG it has participated to. A= ll set. But there's more fun. Let me explain what's behind the text below in RPL... " Let L be the lowest Rank within a DODAG Version that a given node has advertised... A node is allowed to join any DODAG Version that it has never been a prior member of without any restrictions, but if the node has been a prior member of the DODAG Version, then it must continue to observe the rule that it may not advertise a Rank higher than L+DAGMaxRankIncrease at any point in the life of the DODAG Version. " ... I'm pretty sure you will like it: =20 - One interesting difference with Babel is that RPL can route to all nodes = with a single DODAG to a single root, using MOP 2. This gives you the absol= ute minimum amount of state, but that has a potentially large stretch when = not routing to or from the root. At the other extreme, RPL can route optima= lly to all nodes by building one DODAG per destination, using MOP 0, in whi= ch case you get roughly the same behavior as Babel. And the cool thing is t= hat RPL can build as many DODAGs as wanted between these 2 extremes. With t= his, RPL fills one of the requirement discussed at Homenet, that is the cap= ability to save resources by selectively drop state. RPL simply does that b= y NOT building MOP 0 DODAG for all destinations, and routing along other MO= P 2 DODAGs with a stretch. IOW, one can use RPL to one or more MOP 2 instan= ces, say, rooted at the edges of a stadium, and as many MOP 0 as you like t= o optimize to particular sources and sinks. All this can be done with the c= urrent spec. - Another interesting difference is that if we have 2 roots, RPL partitions= the network in 2 DODAGs. This translates into the fact that if we have 2 r= outers that expose a same destination, RPL, as opposed to Babel, does not s= uffer from a routing loop. The rule above forces a router to maintain its l= owest rank per DODAG, and the feasibility condition applies on a per-DODAG = basis with a different value of L per DODAG. Which has yet the other conseq= uence that if a node has never been in a particular DODAG, then that is en= ough feasibility condition; it can jump in with no loop. That's divide and= conquer for you, quite a key feature if you want to scale your network. > (Which makes sense for RPL -- you certainly don't want to multiply the da= ta > structures being held in a sensor. Babel and RPL play in different space= s, right?) >=20 > > But RPL adds the capability to make local repair which provides a > > service of freezing akin to the the diffusion algorithm but adapted to > > LLN and MANET. >=20 > Again, I may be confused, but I think the local repair mechanism is not s= pecified > in the RFC. There's an example mechanism given in Section 3.7.2, but tha= t > example is prone to loops in the presence of packet loss. Oh, it is specified, most certainly. Local repair is in fact a mobility-fr= iendly freezing - which is intently not DUAL's diffusion because diffusion = would not work on a MANET where some nodes may go away before the distribut= ed algorithm is complete, which would cause DUAL to lock. Local repair is d= one by either poisoning or detaching, sections 8.2.2.5. Or 8.2.2.6. Because= mobility and radio interferences may cause repeated packet loss, neither p= oisoning nor detaching is a fool proof guarantee of freezing the whole imp= acted sub-dag. So there's all that discussion, which you'll find but scanni= ng the RFC for the word poisoning. That's when a set of simple ideas turn i= nto a lot of quasi-opaque text, to the great suffering of the editor, trust= me on that. On the side, poisoning is really inheriting from IGRP, not EIG= RP.=20 > As what RPL calls a "global repair", all I could find in the RFC is >=20 > A DODAG root institutes a global repair operation by incrementing the > DODAGVersionNumber. This initiates a new DODAG Version. >=20 > However, there's nothing I see to say when a root decides to trigger a gl= obal > repair (except for some vague mention of periodic updates, which the DSDV > experiment has shown are not a good idea). This is very much unlike Babe= l > (different spaces, remember?) which has a provably complete reactive > mechanism for triggering seqno updates. =20 We voluntarily left out the trigger for a new iteration, because that can b= e largely outside the scope of the routing protocol, and for the part that = belongs to the routing protocol, it is highly dependent of the use case, ho= w frequently and for which reason you want to fire a new iteration. As you = point out, if the network has large to infinite resources, a new iteration = can be fired on any event that causes a freeze somewhere. But you rapidly f= ind that you want to delay that to save control plane, in particular if the= frozen area is not transmitting any data to that destination anyway. Then = you start thinking in terms of OSPF throttling and may get quite far, depen= ding on how constrained your network is. We went as far as allowing a confi= gurable stretch in the feasibility condition, allowing to increase the Rank= by a limited extra, which may, if you are lucky, save the day, or, if you = are unlucky, count to a very tightly controlled infinity. Because RPL has local repair, it needs a lot less global repair, which in t= urn is a great news if a new iteration is indeed a relatively costly operat= ions vs. effective traffic in the network. Note well: The base RFC only incorporates what's common to all RPL cases, that's the c= ore DV operation. Anything too specific is left to an external plug-in that= is adapted to the use case, called an objective function (OF). The bare mi= nimum OF is RFC 6552. If a particular use case has a valid reason to trigge= r a new iteration, then the OF is the place to make that decision. Arguably= , we could have documented a vector to trigger this new iteration in RFC 65= 50, and we have not. There are a number of other things that we left out, i= n a search for the bare minimum, and yet we ended with 100+ pages. But that= does not reflect the footprint of the code, which can be quite small.. And then, there are the external sources of trigger, say, an event such as = an explosion that will disrupt the network and is detected outside of the r= outing protocol. The local repairs will fail and or at best consume lots of= resources. The reactive triggers will either no get there or too many will= , in which case there will be too many iterations, too close from one anoth= er. This is when an external source -an open loop between the events and th= e routing action - can be welcome. We certainly did not start discussing su= ch a thing in the RFC. All in all I do not buy the different spaces. RPL was explicitly designed f= or multiple spaces because, by design, we left out of RPL and into the OF e= verything that's specific. You have a different space, you figure a differ= ent way to use RPL (how many DODAGs, MOP x, etc...) and you design your own= objective function if need be, tying metrics and logic to feed your partic= ular needs. This has been tried from some the smallest to some of the large= st routers on this planet, quite successfully, if you ask me. I'd say that = a MANET or a HOMENET router stand peacefully in the middle ground between t= hese extremes. > > Even more, RPL adds a capability to stretch the rules, and a > > capability to delay the repairs so as to reduce the control overhead > > in Lower Power and mobile use cases. >=20 > Yes. That's probably a very good feature in the space where RPL plays. > Which is different from the space that Babel aims for. >=20 > > All in all I remain to be convinced that Babel is much, much, anything. >=20 > That citation belongs on the conclusion slide of the next talk I give ;-) Do I get an invite? I'll be a good citizen ; )=20 After this discussion, I'm tempted to start a "RPL for not so low power los= sy networks" spec that would probably no have to specify anything much but = mostly provide guidance on how to use RPL for wired, home and MANET deploym= ents. All the best, Pascal From nobody Thu Apr 2 08: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 D88B51AC420 for ; Thu, 2 Apr 2015 08:28:44 -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=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 QR-gC0qwpc_5 for ; Thu, 2 Apr 2015 08:28:44 -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 14F3F1AC405 for ; Thu, 2 Apr 2015 08:28:44 -0700 (PDT) Received: from localhost ([::1]:37176 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ydh2q-0004rF-UA; Thu, 02 Apr 2015 08:28:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, ncamwing@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 02 Apr 2015 15:28:36 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/137#comment:4 Message-ID: <082.cfc03c8a16b8122d145d3d8480f7451a@trac.tools.ietf.org> References: <067.e03655bb677c0fb217ee063fe7daaa4a@trac.tools.ietf.org> X-Trac-Ticket-ID: 137 In-Reply-To: <067.e03655bb677c0fb217ee063fe7daaa4a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, ncamwing@cisco.com, mcr@sandelman.ca, 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 Resent-To: draft-ietf-roll-applicability-ami.all@ietf.org Resent-Message-Id: <20150402152844.14F3F1AC405@ietfa.amsl.com> Resent-Date: Thu, 2 Apr 2015 08:28:44 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Archived-At: Cc: roll@ietf.org Subject: Re: [Roll] [roll] #137 (applicability-ami): - draft-ietf-roll-applicability-ami - Incorporate a model for initial and incremental deployments 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: Thu, 02 Apr 2015 15:28:45 -0000 #137: - draft-ietf-roll-applicability-ami - Incorporate a model for initial and incremental deployments Changes (by mcr@sandelman.ca): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: closed Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: fixed -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Apr 2 08:29: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 F38771AC410 for ; Thu, 2 Apr 2015 08:29:24 -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=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 sm7DxDIhH2Z5 for ; Thu, 2 Apr 2015 08:29: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 361A31ACC8F for ; Thu, 2 Apr 2015 08:29:13 -0700 (PDT) Received: from localhost ([::1]:37203 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ydh3O-0006l6-Lm; Thu, 02 Apr 2015 08:29:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 02 Apr 2015 15:29:10 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/136#comment:6 Message-ID: <082.ad37c99b9167d2a4fe7432429c766a7a@trac.tools.ietf.org> References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> X-Trac-Ticket-ID: 136 In-Reply-To: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, mcr@sandelman.ca, 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 Resent-To: draft-ietf-roll-applicability-ami.all@ietf.org Resent-Message-Id: <20150402152913.361A31ACC8F@ietfa.amsl.com> Resent-Date: Thu, 2 Apr 2015 08:29:13 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Archived-At: Cc: roll@ietf.org Subject: Re: [Roll] [roll] #136 (applicability-ami): - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used 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: Thu, 02 Apr 2015 15:29:25 -0000 #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used Changes (by mcr@sandelman.ca): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: closed Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: fixed -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Apr 2 08:29: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 C4A4D1ACCFF for ; Thu, 2 Apr 2015 08:29:34 -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=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 Fo94F01V9Tsa for ; Thu, 2 Apr 2015 08:29:34 -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 2DC561B2D00 for ; Thu, 2 Apr 2015 08:29:20 -0700 (PDT) Received: from localhost ([::1]:37213 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ydh3W-0007EI-68; Thu, 02 Apr 2015 08:29:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 02 Apr 2015 15:29:18 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/135#comment:2 Message-ID: <082.d198f5dc4307db604aaf2fb4ba53129f@trac.tools.ietf.org> References: <067.d2b714cc0ac70ebe3021413da1fe7ea3@trac.tools.ietf.org> X-Trac-Ticket-ID: 135 In-Reply-To: <067.d2b714cc0ac70ebe3021413da1fe7ea3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, mcr@sandelman.ca, 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 Resent-To: draft-ietf-roll-applicability-ami.all@ietf.org Resent-Message-Id: <20150402152920.2DC561B2D00@ietfa.amsl.com> Resent-Date: Thu, 2 Apr 2015 08:29:20 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Archived-At: Cc: roll@ietf.org Subject: Re: [Roll] [roll] #135 (applicability-ami): Point to the Security Considerations section of RFC 6550 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: Thu, 02 Apr 2015 15:29:34 -0000 #135: Point to the Security Considerations section of RFC 6550 Changes (by mcr@sandelman.ca): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: closed Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: fixed -------------------------------------+------------------------------------- Ticket URL: roll From nobody Thu Apr 2 08:59: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 261D71ACD92 for ; Thu, 2 Apr 2015 08:59:14 -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_20=-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 SUYKjmBXaTOb for ; Thu, 2 Apr 2015 08:59:12 -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 E35621ACD94 for ; Thu, 2 Apr 2015 08:59:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 39878E1BB; Thu, 2 Apr 2015 12:09:33 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3B19B63B76; Thu, 2 Apr 2015 11:59:10 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2560363731; Thu, 2 Apr 2015 11:59:10 -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: Cc: Nancy Cam-Winget , draft-ietf-roll-applicability-ami@tools.ietf.org Subject: [Roll] four minor things with roll-applicability-ami-10. 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 Apr 2015 15:59:14 -0000 --=-=-= Content-Type: text/plain Hi Nancy, I've done a final review of draft-ietf-roll-applicability-ami-10 as part of the Document Shepherd process, and a few questions came up. I'm sorry that I didn't catch these during the LC. 0) J.Hui author reference needs to be update, as he's now at Nestlabs. 1) can you update the reference to draft-ietf-roll-terminology to RFC7102. 2) can you add "NOT RECOMMENDED" to the list of 2119 keywords in section 1.1. 3) Does the reference to Experimental RFC: RFC 6997 ("Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks") need to be normative, or would informative suffice? (It's otherwise a hard to explain downref) 4) section 7.2.1 says: The maximum IEEE 1901.2 PHY frame payload is 512 bytes. The maximum IEEE 1901.2 MAC frame payload is 1280 bytes, which supports the IPv6 minimum MTU requirement. When there is a mistmatch between the PHY frame payload size and the size of a MAC frame carrying an IPv6 packet, IEEE 1901.2 specifies a MAC sub-layer segmentation and re-assembly mechanism that provides a reliable one-hop transfer of that MAC frame segments. is this sub-layer always used to get the 1280 bytes needed, or are there situations where the PHY payload is bigger. I don't think it matters, but kind stood out as a sore thumb. I think that section 7.2.2 means to invoke 6lowpan, but it doesn't do that. I'm also unclear how 16-bits addresses are assigned in this situation. In section 7.3.3, rather than a description of IEEE security features, I was hoping to get an actual list of what would be appropriate in AMI deployments. "The MAC can be either 4, 8, or 16 bytes long." --- okay, but which one is being used, and how is this being signaled? 7.3 says: However, since the link-layer MTU in both wireless and PLC links supports the transmission of a full IPv6 packet, the use of 6LowPAN fragmentation is NOT RECOMMENDED. okay, so I think I'm confused. I agree that 1901.2 and 802.15.4g links can deal with larger packets, does this spec exclude itself from applying to 802.15.4 links? That's okay if that was the intent, I'm just confused because I thought it included 127-byte 15.4 links. Given that the document has restricted itself to non-battery powered, and non-storing mode situations, would a pass through to remove references to MAYs about battery situations (such as DIOIntervalMin) be appropriate? I also think that 7.1.2 could be clearer that non-storing is relevant. I know that the document has sat on the fence for much of it's existence. I think that section 9.1 is saying that both certificates and session (link) keys are loaded at the factory. How would the maker of a new device know how to turn the link key into something useable by the MAC? Or alternatively, how would a utility tell a new manufacturer how they are managing the link keys? I'm thinking that a single reference here ought to suffice, perhaps to some IEEE document section. sorry to come up with a bunch of nits... -- 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) iQEVAwUBVR1nTYCLcPvd0N1lAQJQuQgAvwuHYu5uya21znxtWF//rQSfVpaKThXb zT6XQeB1wzmBRzpnUp0Sc7cDS1RDHdiXhXS4tH44owBZa7tyUjdQXvCFp6QwRgVk Clslq2Vrszr2xdw5oNkzagoQqF0uxGp68g2eu2psHNWPRCFZhi4S0AXYdAm1eDnb NPDNgyYzUE8S/5h3krGMHP3rgaQWqzgk5ifP5L1uqVbCscIbKNpCkyzwgTZbOALP dx4sVuhMEZIcxRzIL8RqPtVKkqOE//9yMqCbV6dsOGZNiRaOU03iIZ50MNHgs/JC OadeGrO+X2L1EfZivLE/Qv6gz7Ne5nF1vWQWjDzKiM6LEsa2gWIhrg== =4d9r -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 2 09:00: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 EB02A1ACD65 for ; Thu, 2 Apr 2015 09:00:00 -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 BcCfJWldvJWP for ; Thu, 2 Apr 2015 08:59:57 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAAE1ACD81 for ; Thu, 2 Apr 2015 08:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39054; q=dns/txt; s=iport; t=1427990396; x=1429199996; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vdnqtPTL1Ch+8yXw+4OknyZ18yIiUxi7W3asi3E9W2U=; b=RNqiAiz9ioOz59GUUgmQWJmBjYrCWlhed9Q7BkyCahnGHBy12b/JDEQe EsHDt7slyVxd9m2Y7Ymdwjx+HanguqO77V98utrihvUL2k5OzNxlvVhRk 6VR1YWV1sYvuVHTNRaUsP2mVMAOThiyifJHE++TBGR0DkgwL3eWYRj5K2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CiCQAnZh1V/5pdJa1cgkVDUlwFgxCyXY0xPIF5AQmFcwIcgStMAQEBAQEBfoQeAQEBAwEBAQEgCkELDAQCAQgRAQMBAQsWBwMCAgIlCxQDBggCBA4FCBOIDAgNtVqYLwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLKYQgCh4WFwQGAQaCYi+BFgWEV4wTg3WECoICgRw6gnqCXolRg0giggIcgVBvgQJCfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,511,1422921600"; d="scan'208,217";a="405617441" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 02 Apr 2015 15:59:55 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t32FxsrL010415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 15:59:55 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 10:59:54 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] proposed amendments to ROLL charter Thread-Index: AQHQa7xpZZoSrfhQFkejLG4omB8ViZ054Wlg Date: Thu, 2 Apr 2015 15:59:54 +0000 Deferred-Delivery: Thu, 2 Apr 2015 15:59:00 +0000 Message-ID: References: <30526.1427136071@sandelman.ca> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD849D98770xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson Subject: Re: [Roll] proposed amendments to ROLL charter 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 Apr 2015 16:00:01 -0000 --_000_E045AECD98228444A58C61C200AE1BD849D98770xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBmZXcgb3RoZXIgdGhpbmdzIEnigJlkIGxpa2UgdG8gc2VlLCBJbmVzOg0KDQotIE9uZSBpcyBh IE1PUCBiYXNlZCBvbiBCSUVSIGFuZC9vciBCbG9vbSBmaWx0ZXJzLCB3aGljaCBpcyBhIHdheSB0 byBjb21wcmVzcyBCSUVSIHdpdGggYSBjaGFuY2Ugb2YgZmFsc2UgcG9zaXRpdmUuIENhcnN0ZW4g aGFzIGEgZHJhZnQgdGhhdCBkZXRhaWxzIHRoZSB1c2Ugb2YgQmxvb20gZmlsdGVycyBmb3Igc291 cmNlIHJvdXRpbmcsIGJ1dCByZWFsbHkgYm90aCBCSUVSIGFuZCBCbG9vbSBjYW4gYXBwbHkgdG8g ZWl0aGVyIHN0b3JpbmcgYW5kIG5vbi1zdG9yaW5nLg0KLSBXb3JrIG9uIG1peGVkIHN0b3Jpbmcg YW5kIG5vbi1zdG9yaW5nLCBhbmQgYWxsIHNvcnQgb2Ygb3B0aW1pemF0aW9uIGZvciB0aGUgc3Rv cmluZyBtb2RlLiBJ4oCZbSBhd2FyZSBvZiBmZWFzaWJsZSBzb2x1dGlvbnMgaW4gdGhhdCBzcGFj ZSB0aGF0IHJlYWxseSBzaG91bGQgYmUgc2hhcmVkIGFuZCBtYWRlIGF2YWlsYWJsZSB0byBhbGwu DQotIFdvcmsgb24gYWRkaXRpb25hbCBjYXBhYmlsaXRpZXMgdGhhdCB3ZSBkaWQgbm90IGluaXRp YWxseSBpbmNsdWRlIGluIHRoZSBzcGVjOg0KLSBUaGUgY2FwYWJpbGl0eSB0byBraWxsIGEgcm91 dGUgZnJvbSB0aGUgcm9vdCwgZS5nLiBpZiBhIERBTyBzdGF0ZSBpcyBpbnN0YWxsZWQgYW5kIHNo b3VsZCBiZSBjbGVhbmVkIHVwLCBlLmcuIGlmIHRoZSByb290IHJlYWxpemVzIHRoYXQgdGhlIG5v ZGUgaXMgbm8gbW9yZSB0aGVyZSBvciB0aGVyZSBpcyBhIGR1cGxpY2F0aW9uIG9yIHdoYXQtZWxz ZS4NCi0gVGhlIGNhcGFiaWxpdHkgdG8gdHJpZ2dlciBhIERBTyBmcm9tIHRoZSByb290IGlmIGEg dGFyZ2V0IGlzIGV4cGVjdGVkIHRvIGJlIHByZXNlbnQgaW4gdGhlIG5ldHdvcmsgYnV0IHRoZXJl IGlzIG5vIERBTyBzdGF0ZSAobWF5YmUgdG8gc2F2ZSByZXNvdXJjZXMpDQotIFRoZSBjYXBhYmls aXR5IHRvIHJlcXVlc3QgdGhlIHRyaWdnZXJpbmcgb2YgYSBuZXcgaXRlcmF0aW9uIG9mIGEgRE9E QUcgZnJvbSBhIFJQTCBub2RlIG9yIGEgY29udHJvbGxpbmcgZWxlbWVudC4NCg0KVGhhbmtzIGZv ciBhc2tpbmcg4pi6DQoNClBhc2NhbA0KDQpGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSW5lcyBSb2JsZXMNClNlbnQ6IG1hcmRpIDMxIG1hcnMg MjAxNSAxNjoxMA0KVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtz DQpDYzogTWljaGFlbCBSaWNoYXJkc29uDQpTdWJqZWN0OiBSZTogW1JvbGxdIHByb3Bvc2VkIGFt ZW5kbWVudHMgdG8gUk9MTCBjaGFydGVyDQoNCkhpIFBhc2NhbCwNCg0KVGhhbmsgeW91IHZlcnkg bXVjaCBmb3IgeW91ciBjb21tZW50cywgd2UgYXJlIGdvaW5nIHRvIGluY2x1ZGUgdGhlbSBpbiBv dXIgbWVldGluZy4NCg0KVG8gYWxsLCBUaGVyZSBhcmUgYWRkaXRpb25hbCB0b3BpY3MgdGhhdCB5 b3Ugd291bGQgbGlrZSB0byBpbmNsdWRlIGluIHRoZSBjaGFydGVyPyBQbGVhc2UganVzdGlmeS4N Cg0KVGhhbmsgeW91IHZlcnkgbXVjaCwNCg0KTWljaGFlbCBhbmQgSW5lcw0KDQoyMDE1LTAzLTMx IDEzOjQ5IEdNVCswMzowMCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNj by5jb208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4+Og0KSGVsbG8gTWljaGFlbCAoYW5kIGFs bCk6DQoNCkkgZnVsbHkgc3VwcG9ydCB0aGUgYWRkaXRpb25zLiBTaW5jZSB5b3UgYXJlIGF0IGl0 LCBJIHdvdWxkIGxpa2UgdG8gZXhwbG9yZSBhIGRlZXBlciByZWFsaWdubWVudC4NCg0KUk9MTCBp cyBub3cgaW4gY2hhcmdlIG9mIHRoZSBtYWludGVuYW5jZSBvZiBSUEwsIGlzbid0IGl0Pw0KLSBJ IHRoaW5rIHRoYXQgdGhpcyBzaG91bGQgYmUgYSB3b3JrIGl0ZW0gaW4gdGhlIGNoYXJ0ZXIuDQot IHRoaXMgc2hvdWxkIHJlcGxhY2UgZWxlbWVudHMgdGhhdCB3ZXJlIG9yIGFyZSBiZWluZyBkZWxp dmVyZWQgc3VjaCBhcyBtZXRyaWNzLCBzZWN1cml0eSwgYW5kIFJQTCBpdHNlbGYNCg0KQW5kIGlm IHRoYXQncyBzbywgd291bGRuJ3QgaXQgbWFrZSBzZW5zZSB0byBzdHVkeSBob3cgUlBMIHdvcmtz IG91dHNpZGUgTExOcyBhbmQgaW4gbWl4ZWQgZW52aXJvbm1lbnRzPw0KLSBJJ2QgbGlrZSB0byBz ZWUgd29yayBvbiBSUEwgb3ZlciBmb28gd2hlcmUgZm9vIGlzIEV0aGVybmV0IG9yIFdpLUZpLiBB cHBsaWNhYmlsaXR5IG9mIFJQTCBpbiB2YXJpb3VzIGVudmlyb25tZW50cyBvdXRzaWRlIExMTiB3 b3VsZCBiZSBvZiBpbnRlcmVzdCwgZS5nLiB0byBidWlsZCBhIFdpLUZpIG1lc2ggb3IgYW4gdW5t YW5hZ2VkIG5ldHdvcmsuIEl0IHNlZW1zIHRoYXQgYSBEVCB3aWxsIGZvcm0gYXQgSE9NRU5FVCB0 byBzZWxlY3QgYSByb3V0aW5nIHByb3RvY29sLCBhbmQgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1l bnQgb2YgUlBMIGZvciB0aGF0IGNhc2Ugd291bGQgYmUgYSBnb29kIHJlYWQgaWYgd2UgY2FuIHBy b2R1Y2UgaXQgaW4gdGltZS4NCi0gRnJvbSBvdXIgZXhwZXJpZW5jZSBvZiBhY3R1YWxseSBkb2lu ZyBSUEwgb3ZlciBFdGhlcm5ldCwgaXQgaXMgbW9zdGx5IGEgbWF0dGVyIG9mICpub3QqIHVzaW5n IHRoZSBwYWNrZXQgYXJ0aWZhY3RzLCBwcm9iYWJseSBub3QgdXNpbmcgdGhlIHN0cmV0Y2ggaW4g bG9jYWwgcmVwYWlyLCBhbmQgcmVhY3RpbmcgaW1tZWRpYXRlbHkgdG8gY2hhbmdlcyBpbiBsaW5r IHN0YXRlLiBUaGlzIGlzIGEgdmVyeSBzbWFsbCBzcGVjIGluZGVlZCwgbW9zdGx5IGd1aWRhbmNl IG9uIHdoYXQgdG8gdXNlIGFuZCB3aGF0IG5vdCB0byB1c2UgZnJvbSBSRkMgNjU1MCwgaG93IHRv IHR1bmUgc29tZSBwYXJhbWV0ZXJzLCB3aGljaCBPRiB0byB1c2UgYW5kIGhvdy4NCi0gVGhlIHdv cmsgc2hvdWxkIGFsc28gZGV0YWlsIHRoZSBtb2RlIHdoZXJlIHRoZXJlIGlzIGEgYmFja2JvbmUg YW5kIGEgdmlydHVhbCByb290LiBJIHRoaW5rIHRoYXQgdGhlIGN1cnJlbnQgY2hhcnRlciBkb2Vz IG5vdCBjb3ZlciB3b3JrIG91dHNpZGUgTExOIGJ1dCBjb25zaWRlcmluZyB0aGF0IHdlIGFyZSB0 aGUgZ3JvdXAgdGhhdCBrbm93cyBSUEwgYmVzdCwgdGhhdCB3b3JrIHNob3VsZCBoYXBwZW4gaGVy ZS4NCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNClBhc2NhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9sbCBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE1pY2hhZWwgUmljaGFy ZHNvbg0KPiBTZW50OiBsdW5kaSAyMyBtYXJzIDIwMTUgMTk6NDENCj4gVG86IHJvbGxAaWV0Zi5v cmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtSb2xsXSBwcm9wb3NlZCBhbWVu ZG1lbnRzIHRvIFJPTEwgY2hhcnRlcg0KPg0KPg0KPiBUaGUgZm9sbG93aW5nIGNoYW5nZXMgYXJl IHByb3Bvc2VkIGZvciB0aGUgUk9MTCBjaGFydGVyIHRvIGluY2x1ZGUgdGhlIHdvcmsgdG8NCj4g cHJvZmlsZSA2NTUzLzY1NTQvSVBJUCwgYW5kIHRvIGNvbXByZXNzIGl0Lg0KPg0KPiBUbyB0aGUg cHJlLWFtYmxlOg0KPg0KPiBBZnRlcjoNCj4gIC0gSW4gbW9zdCBjYXNlcywgTExOcyB3aWxsIGJl IGVtcGxveWVkIG92ZXIgbGluayBsYXllcnMgd2l0aCByZXN0cmljdGVkDQo+ICAgIGZyYW1lLXNp emVzLCB0aHVzIGEgcm91dGluZyBwcm90b2NvbCBmb3IgTExOcyBzaG91bGQgYmUgc3BlY2lmaWNh bGx5DQo+ICAgIGFkYXB0ZWQgZm9yIHN1Y2ggbGluayBsYXllcnMuDQo+DQo+IEFkZDoNCj4gKy0g TExOIHJvdXRpbmcgcHJvdG9jb2xzIGhhdmUgdG8gYmUgdmVyeSBjYXJlZnVsIHdoZW4gdHJhZGlu ZyBvZmYNCj4gK2VmZmljaWVuY3kNCj4gKyAgZm9yIGdlbmVyYWxpdHk7IG1hbnkgTExOIG5vZGVz IGRvIG5vdCBoYXZlIHJlc291cmNlcyB0byB3YXN0ZS4NCj4NCj4gQWZ0ZXI6DQo+ICBUaGUgc29s dXRpb24gbXVzdCBpbmNsdWRlIHVuaWNhc3QgYW5kIG11bHRpY2FzdCBjb25zaWRlcmF0aW9ucy4N Cj4NCj4gQWRkOg0KPiArVGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBkb2N1bWVudCBob3cgbm9uLWNv bnRyb2wgcGFja2V0cyBhcmUgcm91dGVkIHdoZW4NCj4gK3RoZXkgY3Jvc3MgdGhlIExMTiwgYW5k IHdoZW4gdGhleSBlbnRlciBhbmQgZXhpdCB0aGUgTExOOiB0aGUNCj4gK2FwcHJvcHJpYXRlIHVz ZSBvZg0KPiArUkgzIChSRkM2NTUzKSwgUlBJIChSRkM2NTU0KSBhbmQgSVBJUCBlbmNhcHN1bGF0 aW9uIGluY2x1ZGluZyBob3cNCj4gK3JvdXRpbmcgbG9vcHMgYXJlIGRldGVjdGVkLiBJbiBjb25z dWx0YXRpb24gd2l0aCB0aGUgNmxvIFdHLCB0aGUNCj4gK1dvcmtpbmcgR3JvdXAgd2lsbCBkZXNp Z24gYSBtZXRob2QgdG8gdGhlc2Ugcm91dGluZyBoZWFkZXJzIGludG8gYQ0KPiArc2luZ2xlIGJs b2NrLiAgVGhlIHJlc3VsdCB3aWxsIGhhdmUgYSBzaGFyZWQgV0dMQyB3aXRoIDZsby4NCj4NCj4g VG8gIFdvcmsgSXRlbXMsIGFkZDoNCj4gKyAgICAgLSBBIGRvY3VtZW50IGRldGFpbGluZyB3aGVu IHRvIHVzZSBSRkM2NTUzLCBSRkM2NTU0IGFuZCBJUElQDQo+ICsgICAgICAgZW5jYXBzdWxhdGlv bi4NCj4gKw0KPiArICAgICAtIEEgZG9jdW1lbnQgZGV0YWlsaW5nIGhvdyB0byBjb21wcmVzcyBS RkM2NTUzLCBSRkM2NTU0IGFuZCBJUCBoZWFkZXJzDQo+ICsgICAgICAgaW4gdGhlIDZsb3dQQU4g SEMgY29udGV4dC4NCj4NCj4NCj4gVGhlIHJlc3VsdGluZyBjaGFydGVyIChhZnRlciByZWZvcm1h dHRpbmcgb2Ygc29tZSBvZiB0aGUgdWdseSB0ZXh0IHdyYXBwaW5nIG9uDQo+IHRoZSB3ZWIgc2l0 ZSkgaXM6DQo+DQo+IC0tLS0NCj4gTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAoTExOcykg YXJlIG1hZGUgdXAgb2YgbWFueSBlbWJlZGRlZCBkZXZpY2VzDQo+IHdpdGggbGltaXRlZCBwb3dl ciwgbWVtb3J5LCBhbmQgcHJvY2Vzc2luZyByZXNvdXJjZXMuIFRoZXkgYXJlIGludGVyY29ubmVj dGVkDQo+IGJ5IGEgdmFyaWV0eSBvZiBsaW5rcywgc3VjaCBhcyBJRUVFIDgwMi4xNS40LCBCbHVl dG9vdGgsIExvdyBQb3dlciBXaUZpLCB3aXJlZCBvcg0KPiBvdGhlciBsb3cgcG93ZXIgUExDIChQ b3dlcmxpbmUgQ29tbXVuaWNhdGlvbikgbGlua3MuIExMTnMgYXJlIHRyYW5zaXRpb25pbmcgdG8N Cj4gYW4gZW5kLXRvLWVuZCBJUC1iYXNlZCBzb2x1dGlvbiB0byBhdm9pZCB0aGUgcHJvYmxlbSBv ZiBub24taW50ZXJvcGVyYWJsZQ0KPiBuZXR3b3JrcyBpbnRlcmNvbm5lY3RlZCBieSBwcm90b2Nv bCB0cmFuc2xhdGlvbiBnYXRld2F5cyBhbmQgcHJveGllcy4NCj4NCj4gR2VuZXJhbGx5IHNwZWFr aW5nLCBMTE5zIGhhdmUgYXQgbGVhc3QgZml2ZSBkaXN0aW5ndWlzaGluZw0KPiBjaGFyYWN0ZXJp c3RpY3M6DQo+IC0gTExOcyBvcGVyYXRlIHdpdGggYSBoYXJkLCB2ZXJ5IHNtYWxsIGJvdW5kIG9u IHN0YXRlLg0KPiAtIEluIG1vc3QgY2FzZXMsIExMTiBvcHRpbWl6ZSBmb3Igc2F2aW5nIGVuZXJn eS4NCj4gLSBUeXBpY2FsIHRyYWZmaWMgcGF0dGVybnMgYXJlIG5vdCBzaW1wbHkgdW5pY2FzdCBm bG93cyAoZS5nLiBpbiBzb21lIGNhc2VzIG1vc3QgaWYNCj4gbm90IGFsbCB0cmFmZmljIGNhbiBi ZSBwb2ludCB0byBtdWx0aXBvaW50KS4NCj4gLSBJbiBtb3N0IGNhc2VzLCBMTE5zIHdpbGwgYmUg ZW1wbG95ZWQgb3ZlciBsaW5rIGxheWVycyB3aXRoIHJlc3RyaWN0ZWQNCj4gICBmcmFtZS1zaXpl cywgdGh1cyBhIHJvdXRpbmcgcHJvdG9jb2wgZm9yIExMTnMgc2hvdWxkIGJlIHNwZWNpZmljYWxs eQ0KPiAgIGFkYXB0ZWQgZm9yIHN1Y2ggbGluayBsYXllcnMuDQo+IC0gTExOIHJvdXRpbmcgcHJv dG9jb2xzIGhhdmUgdG8gYmUgdmVyeSBjYXJlZnVsIHdoZW4gdHJhZGluZyBvZmYgZWZmaWNpZW5j eQ0KPiAgIGZvciBnZW5lcmFsaXR5OyBtYW55IExMTiBub2RlcyBkbyBub3QgaGF2ZSByZXNvdXJj ZXMgdG8gd2FzdGUuDQo+DQo+IFRoZXNlIHNwZWNpZmljIHByb3BlcnRpZXMgY2F1c2UgTExOcyB0 byBoYXZlIHNwZWNpZmljIHJvdXRpbmcgcmVxdWlyZW1lbnRzLg0KPg0KPiBFeGlzdGluZyByb3V0 aW5nIHByb3RvY29scyBzdWNoIGFzIE9TUEYsIElTLUlTLCBBT0RWLCBhbmQgT0xTUiBoYXZlIGJl ZW4NCj4gZXZhbHVhdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwIGFuZCBoYXZlIGluIHRoZWlyIGN1 cnJlbnQgZm9ybSBiZWVuIGZvdW5kIHRvDQo+IG5vdCBzYXRpc2Z5IGFsbCBvZiB0aGVzZSBzcGVj aWZpYyByb3V0aW5nIHJlcXVpcmVtZW50cy4NCj4NCj4gVGhlIFdvcmtpbmcgR3JvdXAgaXMgZm9j dXNlZCBvbiByb3V0aW5nIGlzc3VlcyBmb3IgTExOLg0KPg0KPiBUaGVyZSBpcyBhIHdpZGUgc2Nv cGUgb2YgYXBwbGljYXRpb24gYXJlYXMgZm9yIExMTnMsIGluY2x1ZGluZyBpbmR1c3RyaWFsDQo+ IG1vbml0b3JpbmcsIGJ1aWxkaW5nIGF1dG9tYXRpb24gKEhWQUMsIGxpZ2h0aW5nLCBhY2Nlc3Mg Y29udHJvbCwgZmlyZSksDQo+IGNvbm5lY3RlZCBob21lcywgaGVhbHRoY2FyZSwgZW52aXJvbm1l bnRhbCBtb25pdG9yaW5nLCB1cmJhbiBzZW5zb3INCj4gbmV0d29ya3MgKGUuZy4gU21hcnQgR3Jp ZCksIGFzc2V0IHRyYWNraW5nLiBUaGUgV29ya2luZyBHcm91cCBmb2N1c2VzIG9uDQo+IHJvdXRp bmcgc29sdXRpb25zIGZvciBhIHN1YnNldCBvZiB0aGVzZTogaW5kdXN0cmlhbCwgY29ubmVjdGVk IGhvbWUsIGJ1aWxkaW5nIGFuZA0KPiB1cmJhbiBzZW5zb3IgbmV0d29ya3MgZm9yIHdoaWNoIHJv dXRpbmcgcmVxdWlyZW1lbnRzIGhhdmUgYmVlbiBzcGVjaWZpZWQuDQo+IFRoZXNlIGFwcGxpY2F0 aW9uLXNwZWNpZmljIHJvdXRpbmcgcmVxdWlyZW1lbnQgZG9jdW1lbnRzIHdpbGwgYmUgdXNlZCBm b3INCj4gcHJvdG9jb2wgZGVzaWduLg0KPg0KPiBUaGUgV29ya2luZyBHcm91cCBmb2N1c2VzIG9u bHkgb24gSVB2NiByb3V0aW5nIGFyY2hpdGVjdHVyYWwgZnJhbWV3b3JrIGZvcg0KPiB0aGVzZSBh cHBsaWNhdGlvbiBzY2VuYXJpb3MuIFRoZSBGcmFtZXdvcmsgd2lsbCB0YWtlIGludG8gY29uc2lk ZXJhdGlvbiB2YXJpb3VzDQo+IGFzcGVjdHMgaW5jbHVkaW5nIGhpZ2ggcmVsaWFiaWxpdHkgaW4g dGhlIHByZXNlbmNlIG9mIHRpbWUgdmFyeWluZyBsb3NzDQo+IGNoYXJhY3RlcmlzdGljcyBhbmQg Y29ubmVjdGl2aXR5IHdoaWxlIHBlcm1pdHRpbmcgbG93LXBvd2VyIG9wZXJhdGlvbiB3aXRoIHZl cnkNCj4gbW9kZXN0IG1lbW9yeSBhbmQgQ1BVIHByZXNzdXJlIGluIG5ldHdvcmtzIHBvdGVudGlh bGx5IGNvbXByaXNpbmcgYSB2ZXJ5DQo+IGxhcmdlIG51bWJlciAoc2V2ZXJhbCB0aG91c2FuZHMp IG9mIG5vZGVzLg0KPg0KPiBUaGUgV29ya2luZyBHcm91cCB3aWxsIHBheSBwYXJ0aWN1bGFyIGF0 dGVudGlvbiB0byByb3V0aW5nIHNlY3VyaXR5IGFuZA0KPiBtYW5hZ2VhYmlsaXR5IChlLmcuLCBz ZWxmIHJvdXRpbmcgY29uZmlndXJhdGlvbikgaXNzdWVzLiBJdCB3aWxsIGFsc28gbmVlZCB0bw0K PiBjb25zaWRlciB0aGUgdHJhbnNwb3J0IGNoYXJhY3RlcmlzdGljIHRoZSByb3V0aW5nIHByb3Rv Y29sIG1lc3NhZ2VzIHdpbGwNCj4gZXhwZXJpZW5jZS4gTWVjaGFuaXNtcyB0aGF0IHByb3RlY3Qg YW4gTExOIGZyb20gY29uZ2VzdGlvbiBjb2xsYXBzZSBvciB0aGF0DQo+IGVzdGFibGlzaCBzb21l IGRlZ3JlZSBvZiBmYWlybmVzcyBiZXR3ZWVuIGNvbmN1cnJlbnQgY29tbXVuaWNhdGlvbiBzZXNz aW9ucw0KPiBhcmUgb3V0IG9mIHNjb3BlIG9mIHRoZSBXb3JraW5nIEdyb3VwLiBJdCBpcyBleHBl Y3RlZCB0aGF0IHVwcGVyLWxheWVyDQo+IGFwcGxpY2F0aW9ucyB1dGlsaXppbmcgTExOcyBkZWZp bmUgYXBwcm9wcmlhdGUgbWVjaGFuaXNtcy4NCj4NCj4gVGhlIHNvbHV0aW9uIG11c3QgaW5jbHVk ZSB1bmljYXN0IGFuZCBtdWx0aWNhc3QgY29uc2lkZXJhdGlvbnMuDQo+DQo+IFRoZSBXb3JraW5n IEdyb3VwIHdpbGwgZG9jdW1lbnQgaG93IG5vbi1jb250cm9sIHBhY2tldHMgYXJlIHJvdXRlZCB3 aGVuDQo+IHRoZXkgY3Jvc3MgdGhlIExMTiwgYW5kIHdoZW4gdGhleSBlbnRlciBhbmQgZXhpdCB0 aGUgTExOOiB0aGUgYXBwcm9wcmlhdGUgdXNlIG9mDQo+IFJIMyAoUkZDNjU1MyksIFJQSSAoUkZD NjU1NCkgYW5kIElQSVAgZW5jYXBzdWxhdGlvbiBpbmNsdWRpbmcgaG93IHJvdXRpbmcNCj4gbG9v cHMgYXJlIGRldGVjdGVkLiBJbiBjb25zdWx0YXRpb24gd2l0aCB0aGUgNmxvIFdHLCB0aGUgV29y a2luZyBHcm91cCB3aWxsDQo+IGRlc2lnbiBhIG1ldGhvZCB0byB0aGVzZSByb3V0aW5nIGhlYWRl cnMgaW50byBhIHNpbmdsZSBibG9jay4gIFRoZSByZXN1bHQgd2lsbA0KPiBoYXZlIGEgc2hhcmVk IFdHTEMgd2l0aCA2bG8uDQo+DQo+IFdvcmsgSXRlbXM6DQo+DQo+ICAgICAgLSBTcGVjaWZpY2F0 aW9uIG9mIHJvdXRpbmcgbWV0cmljcyB1c2VkIGluIHBhdGggY2FsY3VsYXRpb24uIFRoaXMNCj4g ICAgICAgIGluY2x1ZGVzIHN0YXRpYyBhbmQgZHluYW1pYyBsaW5rL25vZGUgYXR0cmlidXRlcyBy ZXF1aXJlZCBmb3Igcm91dGluZyBpbg0KPiAgICAgICAgTExOcy4NCj4NCj4gICAgICAtIFByb3Zp ZGUgYW4gYXJjaGl0ZWN0dXJhbCBmcmFtZXdvcmsgZm9yIHJvdXRpbmcgYW5kIHBhdGggc2VsZWN0 aW9uIGF0DQo+ICAgICAgICBMYXllciAzIChSb3V0aW5nIGZvciBMTE4gQXJjaGl0ZWN0dXJlKSB0 aGF0IGFkZHJlc3NlcyBzdWNoIGlzc3VlcyBhcw0KPiAgICAgICAgd2hldGhlciBMTE4gcm91dGlu ZyByZXF1aXJlIGEgZGlzdHJpYnV0ZWQgYW5kL29yIGNlbnRyYWxpemVkIHBhdGgNCj4gICAgICAg IGNvbXB1dGF0aW9uIG1vZGVscywgd2hldGhlciBhZGRpdGlvbmFsIGhpZXJhcmNoeSBpcyBuZWNl c3NhcnkgYW5kIGhvdyBpdA0KPiAgICAgICAgaXMgYXBwbGllZC4NCj4NCj4gICAgICAgIE1hbmFn ZWFiaWxpdHkgd2lsbCBiZSBjb25zaWRlcmVkIHdpdGggZWFjaCBhcHByb2FjaCwgYWxvbmcgd2l0 aCB2YXJpb3VzDQo+ICAgICAgICB0cmFkZS1vZmZzIGZvciBtYWludGFpbmluZyBsb3cgcG93ZXIg b3BlcmF0aW9uLCBpbmNsdWRpbmcgdGhlIHByZXNlbmNlIG9mDQo+ICAgICAgICBub24tdHJpdmlh bCBsb3NzIGFuZCBuZXR3b3JrcyB3aXRoIGEgdmVyeSBsYXJnZSBudW1iZXIgb2Ygbm9kZXMuDQo+ DQo+ICAgICAgLSBQcm9kdWNlIGEgcm91dGluZyBzZWN1cml0eSBmcmFtZXdvcmsgZm9yIHJvdXRp bmcgaW4gTExOcy4NCj4NCj4gICAgICAtIFByb3RvY29sIHdvcms6IFRoZSBXb3JraW5nIEdyb3Vw IHdpbGwgY29uc2lkZXIgc3BlY2lmaWMgcm91dGluZw0KPiAgICAgICAgcmVxdWlyZW1lbnRzIGZy b20gdGhlIGZvdXIgYXBwbGljYXRpb24gZG9jdW1lbnRzIGNvbGxlY3RpdmVseSwgYW5kDQo+ICAg ICAgICBzcGVjaWZ5IGVpdGhlciBhIG5ldyBwcm90b2NvbCBvciBleHRlbmQgYW4gZXhpc3Rpbmcg cm91dGluZyBwcm90b2NvbA0KPiAgICAgICAgaW4gY29vcGVyYXRpb24gd2l0aCB0aGUgcmVsZXZh bnQgV29ya2luZyBHcm91cC4NCj4gICAgICAgIElmIHJlcXVpcmVtZW50cyBmcm9tIHRoZSBmb3Vy IHRhcmdldCBhcHBsaWNhdGlvbiBhcmVhcyBjYW5ub3QgYmUgbWV0DQo+ICAgICAgICB3aXRoIGEg c2luZ2xlIHByb3RvY29sLCB0aGUgV0cgbWF5IGNob29zZSB0byBzcGVjaWZ5IG9yIGV4dGVuZCBt b3JlIHRoYW4NCj4gICAgICAgIG9uZSBwcm90b2NvbCAodGhpcyB3aWxsIHJlcXVpcmUgYSByZWNo YXJ0ZXIgb2YgdGhlIFdHKS4NCj4NCj4gICAgICAtIERvY3VtZW50YXRpb24gb2YgYXBwbGljYWJp bGl0eSBzdGF0ZW1lbnQgb2YgUk9MTCByb3V0aW5nIHByb3RvY29scy4NCj4NCj4gICAgICAtIEEg ZG9jdW1lbnQgZGV0YWlsaW5nIHdoZW4gdG8gdXNlIFJGQzY1NTMsIFJGQzY1NTQgYW5kIElQSVAN Cj4gICAgICAgIGVuY2Fwc3VsYXRpb24uDQo+DQo+ICAgICAgLSBBIGRvY3VtZW50IGRldGFpbGlu ZyBob3cgdG8gY29tcHJlc3MgUkZDNjU1MywgUkZDNjU1NCBhbmQgSVAgaGVhZGVycw0KPiAgICAg ICAgaW4gdGhlIDZsb3dQQU4gSEMgY29udGV4dC4NCj4NCj4NCj4NCj4gJElkOiBjaGFydGVyLnR4 dCx2IDEuMyAyMDE1LzAzLzIzIDE4OjMzOjM4IG1jciBFeHAgJA0KPg0KPg0KPg0KPiAtLQ0KPiBN aWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYTxtYWlsdG86bWNyJTJCSUVU RkBzYW5kZWxtYW4uY2E+PiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQo+IElFVEYgUk9MTCBX RyBjby1jaGFpci4gICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3JvbGwvY2hhcnRl ci8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xs IG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZzxtYWlsdG86Um9sbEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KDQo= --_000_E045AECD98228444A58C61C200AE1BD849D98770xmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QSBmZXcgb3RoZXIgdGhpbmdzIEnigJlkIGxpa2UgdG8g c2VlLCBJbmVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+LSBPbmUgaXMgYSBNT1AgYmFzZWQgb24gQklFUiBhbmQvb3Ig Qmxvb20gZmlsdGVycywgd2hpY2ggaXMgYSB3YXkgdG8gY29tcHJlc3MgQklFUiB3aXRoIGEgY2hh bmNlIG9mIGZhbHNlIHBvc2l0aXZlLiBDYXJzdGVuIGhhcyBhIGRyYWZ0IHRoYXQgZGV0YWlscyB0 aGUgdXNlDQogb2YgQmxvb20gZmlsdGVycyBmb3Igc291cmNlIHJvdXRpbmcsIGJ1dCByZWFsbHkg Ym90aCBCSUVSIGFuZCBCbG9vbSBjYW4gYXBwbHkgdG8gZWl0aGVyIHN0b3JpbmcgYW5kIG5vbi1z dG9yaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tIFdvcmsgb24gbWl4ZWQgc3Rv cmluZyBhbmQgbm9uLXN0b3JpbmcsIGFuZCBhbGwgc29ydCBvZiBvcHRpbWl6YXRpb24gZm9yIHRo ZSBzdG9yaW5nIG1vZGUuIEnigJltIGF3YXJlIG9mIGZlYXNpYmxlIHNvbHV0aW9ucyBpbiB0aGF0 IHNwYWNlIHRoYXQgcmVhbGx5IHNob3VsZA0KIGJlIHNoYXJlZCBhbmQgbWFkZSBhdmFpbGFibGUg dG8gYWxsLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LSBXb3JrIG9uIGFkZGl0aW9u YWwgY2FwYWJpbGl0aWVzIHRoYXQgd2UgZGlkIG5vdCBpbml0aWFsbHkgaW5jbHVkZSBpbiB0aGUg c3BlYzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1pbmRlbnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+LSBUaGUgY2FwYWJpbGl0eSB0byBraWxsIGEgcm91dGUgZnJvbSB0aGUgcm9vdCwgZS5n LiBpZiBhIERBTyBzdGF0ZSBpcyBpbnN0YWxsZWQgYW5kIHNob3VsZCBiZSBjbGVhbmVkIHVwLCBl LmcuIGlmIHRoZSByb290IHJlYWxpemVzDQogdGhhdCB0aGUgbm9kZSBpcyBubyBtb3JlIHRoZXJl IG9yIHRoZXJlIGlzIGEgZHVwbGljYXRpb24gb3Igd2hhdC1lbHNlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozNi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tIFRoZSBjYXBhYmlsaXR5 IHRvIHRyaWdnZXIgYSBEQU8gZnJvbSB0aGUgcm9vdCBpZiBhIHRhcmdldCBpcyBleHBlY3RlZCB0 byBiZSBwcmVzZW50IGluIHRoZSBuZXR3b3JrIGJ1dCB0aGVyZSBpcyBubyBEQU8gc3RhdGUgKG1h eWJlDQogdG8gc2F2ZSByZXNvdXJjZXMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gVGhlIGNhcGFiaWxpdHkgdG8gcmVxdWVzdCB0aGUg dHJpZ2dlcmluZyBvZiBhIG5ldyBpdGVyYXRpb24gb2YgYSBET0RBRyBmcm9tIGEgUlBMIG5vZGUg b3IgYSBjb250cm9sbGluZyBlbGVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciBhc2tpbmcNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7 Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXNjYWw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9sbCBbbWFpbHRv OnJvbGwtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SW5lcyBSb2JsZXM8 YnI+DQo8Yj5TZW50OjwvYj4gbWFyZGkgMzEgbWFycyAyMDE1IDE2OjEwPGJyPg0KPGI+VG86PC9i PiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3Jrczxicj4NCjxiPkNjOjwv Yj4gTWljaGFlbCBSaWNoYXJkc29uPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUm9sbF0gcHJv cG9zZWQgYW1lbmRtZW50cyB0byBST0xMIGNoYXJ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUGFzY2FsLDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91 ciBjb21tZW50cywgd2UgYXJlIGdvaW5nIHRvIGluY2x1ZGUgdGhlbSBpbiBvdXIgbWVldGluZy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VG8gYWxsLCBUaGVyZSBhcmUgYWRkaXRpb25hbCB0b3BpY3MgdGhhdCB5b3Ugd291bGQgbGlr ZSB0byBpbmNsdWRlIGluIHRoZSBjaGFydGVyPyBQbGVhc2UganVzdGlmeS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IHZlcnkg bXVjaCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TWljaGFlbCBhbmQgSW5lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MjAxNS0wMy0zMSAxMzo0OSBHTVQmIzQzOzAzOjAwIFBhc2NhbCBUaHViZXJ0IChw dGh1YmVydCkgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIj5wdGh1YmVydEBjaXNjby5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhlbGxvIE1pY2hhZWwgKGFuZCBhbGwpOjxicj4NCjxicj4NCkkgZnVs bHkgc3VwcG9ydCB0aGUgYWRkaXRpb25zLiBTaW5jZSB5b3UgYXJlIGF0IGl0LCBJIHdvdWxkIGxp a2UgdG8gZXhwbG9yZSBhIGRlZXBlciByZWFsaWdubWVudC48YnI+DQo8YnI+DQpST0xMIGlzIG5v dyBpbiBjaGFyZ2Ugb2YgdGhlIG1haW50ZW5hbmNlIG9mIFJQTCwgaXNuJ3QgaXQ/PGJyPg0KLSBJ IHRoaW5rIHRoYXQgdGhpcyBzaG91bGQgYmUgYSB3b3JrIGl0ZW0gaW4gdGhlIGNoYXJ0ZXIuPGJy Pg0KLSB0aGlzIHNob3VsZCByZXBsYWNlIGVsZW1lbnRzIHRoYXQgd2VyZSBvciBhcmUgYmVpbmcg ZGVsaXZlcmVkIHN1Y2ggYXMgbWV0cmljcywgc2VjdXJpdHksIGFuZCBSUEwgaXRzZWxmPGJyPg0K PGJyPg0KQW5kIGlmIHRoYXQncyBzbywgd291bGRuJ3QgaXQgbWFrZSBzZW5zZSB0byBzdHVkeSBo b3cgUlBMIHdvcmtzIG91dHNpZGUgTExOcyBhbmQgaW4gbWl4ZWQgZW52aXJvbm1lbnRzPzxicj4N Ci0gSSdkIGxpa2UgdG8gc2VlIHdvcmsgb24gUlBMIG92ZXIgZm9vIHdoZXJlIGZvbyBpcyBFdGhl cm5ldCBvciBXaS1GaS4gQXBwbGljYWJpbGl0eSBvZiBSUEwgaW4gdmFyaW91cyBlbnZpcm9ubWVu dHMgb3V0c2lkZSBMTE4gd291bGQgYmUgb2YgaW50ZXJlc3QsIGUuZy4gdG8gYnVpbGQgYSBXaS1G aSBtZXNoIG9yIGFuIHVubWFuYWdlZCBuZXR3b3JrLiBJdCBzZWVtcyB0aGF0IGEgRFQgd2lsbCBm b3JtIGF0IEhPTUVORVQgdG8gc2VsZWN0IGEgcm91dGluZw0KIHByb3RvY29sLCBhbmQgYW4gYXBw bGljYWJpbGl0eSBzdGF0ZW1lbnQgb2YgUlBMIGZvciB0aGF0IGNhc2Ugd291bGQgYmUgYSBnb29k IHJlYWQgaWYgd2UgY2FuIHByb2R1Y2UgaXQgaW4gdGltZS48YnI+DQotIEZyb20gb3VyIGV4cGVy aWVuY2Ugb2YgYWN0dWFsbHkgZG9pbmcgUlBMIG92ZXIgRXRoZXJuZXQsIGl0IGlzIG1vc3RseSBh IG1hdHRlciBvZiAqbm90KiB1c2luZyB0aGUgcGFja2V0IGFydGlmYWN0cywgcHJvYmFibHkgbm90 IHVzaW5nIHRoZSBzdHJldGNoIGluIGxvY2FsIHJlcGFpciwgYW5kIHJlYWN0aW5nIGltbWVkaWF0 ZWx5IHRvIGNoYW5nZXMgaW4gbGluayBzdGF0ZS4gVGhpcyBpcyBhIHZlcnkgc21hbGwgc3BlYyBp bmRlZWQsIG1vc3RseQ0KIGd1aWRhbmNlIG9uIHdoYXQgdG8gdXNlIGFuZCB3aGF0IG5vdCB0byB1 c2UgZnJvbSBSRkMgNjU1MCwgaG93IHRvIHR1bmUgc29tZSBwYXJhbWV0ZXJzLCB3aGljaCBPRiB0 byB1c2UgYW5kIGhvdy48YnI+DQotIFRoZSB3b3JrIHNob3VsZCBhbHNvIGRldGFpbCB0aGUgbW9k ZSB3aGVyZSB0aGVyZSBpcyBhIGJhY2tib25lIGFuZCBhIHZpcnR1YWwgcm9vdC4gSSB0aGluayB0 aGF0IHRoZSBjdXJyZW50IGNoYXJ0ZXIgZG9lcyBub3QgY292ZXIgd29yayBvdXRzaWRlIExMTiBi dXQgY29uc2lkZXJpbmcgdGhhdCB3ZSBhcmUgdGhlIGdyb3VwIHRoYXQga25vd3MgUlBMIGJlc3Qs IHRoYXQgd29yayBzaG91bGQgaGFwcGVuIGhlcmUuPGJyPg0KPGJyPg0KV2hhdCBkbyB5b3UgdGhp bms/PGJyPg0KPGJyPg0KUGFzY2FsPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogUm9sbCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmciPnJvbGwtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl aGFsZiBPZiBNaWNoYWVsIFJpY2hhcmRzb248YnI+DQomZ3Q7IFNlbnQ6IGx1bmRpIDIzIG1hcnMg MjAxNSAxOTo0MTxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5y b2xsQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogW1JvbGxdIHByb3Bvc2VkIGFtZW5k bWVudHMgdG8gUk9MTCBjaGFydGVyPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBm b2xsb3dpbmcgY2hhbmdlcyBhcmUgcHJvcG9zZWQgZm9yIHRoZSBST0xMIGNoYXJ0ZXIgdG8gaW5j bHVkZSB0aGUgd29yayB0bzxicj4NCiZndDsgcHJvZmlsZSA2NTUzLzY1NTQvSVBJUCwgYW5kIHRv IGNvbXByZXNzIGl0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRvIHRoZSBwcmUtYW1ibGU6PGJyPg0K Jmd0Ozxicj4NCiZndDsgQWZ0ZXI6PGJyPg0KJmd0OyZuYnNwOyAtIEluIG1vc3QgY2FzZXMsIExM TnMgd2lsbCBiZSBlbXBsb3llZCBvdmVyIGxpbmsgbGF5ZXJzIHdpdGggcmVzdHJpY3RlZDxicj4N CiZndDsmbmJzcDsgJm5ic3A7IGZyYW1lLXNpemVzLCB0aHVzIGEgcm91dGluZyBwcm90b2NvbCBm b3IgTExOcyBzaG91bGQgYmUgc3BlY2lmaWNhbGx5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgYWRh cHRlZCBmb3Igc3VjaCBsaW5rIGxheWVycy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBZGQ6PGJyPg0K Jmd0OyAmIzQzOy0gTExOIHJvdXRpbmcgcHJvdG9jb2xzIGhhdmUgdG8gYmUgdmVyeSBjYXJlZnVs IHdoZW4gdHJhZGluZyBvZmY8YnI+DQomZ3Q7ICYjNDM7ZWZmaWNpZW5jeTxicj4NCiZndDsgJiM0 MzsmbmJzcDsgZm9yIGdlbmVyYWxpdHk7IG1hbnkgTExOIG5vZGVzIGRvIG5vdCBoYXZlIHJlc291 cmNlcyB0byB3YXN0ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBZnRlcjo8YnI+DQomZ3Q7Jm5ic3A7 IFRoZSBzb2x1dGlvbiBtdXN0IGluY2x1ZGUgdW5pY2FzdCBhbmQgbXVsdGljYXN0IGNvbnNpZGVy YXRpb25zLjxicj4NCiZndDs8YnI+DQomZ3Q7IEFkZDo8YnI+DQomZ3Q7ICYjNDM7VGhlIFdvcmtp bmcgR3JvdXAgd2lsbCBkb2N1bWVudCBob3cgbm9uLWNvbnRyb2wgcGFja2V0cyBhcmUgcm91dGVk IHdoZW48YnI+DQomZ3Q7ICYjNDM7dGhleSBjcm9zcyB0aGUgTExOLCBhbmQgd2hlbiB0aGV5IGVu dGVyIGFuZCBleGl0IHRoZSBMTE46IHRoZTxicj4NCiZndDsgJiM0MzthcHByb3ByaWF0ZSB1c2Ug b2Y8YnI+DQomZ3Q7ICYjNDM7UkgzIChSRkM2NTUzKSwgUlBJIChSRkM2NTU0KSBhbmQgSVBJUCBl bmNhcHN1bGF0aW9uIGluY2x1ZGluZyBob3c8YnI+DQomZ3Q7ICYjNDM7cm91dGluZyBsb29wcyBh cmUgZGV0ZWN0ZWQuIEluIGNvbnN1bHRhdGlvbiB3aXRoIHRoZSA2bG8gV0csIHRoZTxicj4NCiZn dDsgJiM0MztXb3JraW5nIEdyb3VwIHdpbGwgZGVzaWduIGEgbWV0aG9kIHRvIHRoZXNlIHJvdXRp bmcgaGVhZGVycyBpbnRvIGE8YnI+DQomZ3Q7ICYjNDM7c2luZ2xlIGJsb2NrLiZuYnNwOyBUaGUg cmVzdWx0IHdpbGwgaGF2ZSBhIHNoYXJlZCBXR0xDIHdpdGggNmxvLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPiZndDs8YnI+DQomZ3Q7IFRvJm5ic3A7IFdvcmsgSXRlbXMsIGFkZDo8YnI+DQomZ3Q7 ICYjNDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDstIEEgZG9jdW1lbnQgZGV0YWlsaW5nIHdoZW4gdG8g dXNlIFJGQzY1NTMsIFJGQzY1NTQgYW5kIElQSVA8YnI+DQomZ3Q7ICYjNDM7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZW5jYXBzdWxhdGlvbi48YnI+DQomZ3Q7ICYjNDM7PGJyPg0KJmd0OyAm IzQzOyZuYnNwOyAmbmJzcDsgJm5ic3A7LSBBIGRvY3VtZW50IGRldGFpbGluZyBob3cgdG8gY29t cHJlc3MgUkZDNjU1MywgUkZDNjU1NCBhbmQgSVAgaGVhZGVyczxicj4NCiZndDsgJiM0MzsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbiB0aGUgNmxvd1BBTiBIQyBjb250ZXh0Ljxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgcmVzdWx0aW5nIGNoYXJ0ZXIgKGFmdGVyIHJlZm9y bWF0dGluZyBvZiBzb21lIG9mIHRoZSB1Z2x5IHRleHQgd3JhcHBpbmcgb248YnI+DQomZ3Q7IHRo ZSB3ZWIgc2l0ZSkgaXM6PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLTxicj4NCiZndDsgTG93IHBv d2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAoTExOcykgYXJlIG1hZGUgdXAgb2YgbWFueSBlbWJlZGRl ZCBkZXZpY2VzPGJyPg0KJmd0OyB3aXRoIGxpbWl0ZWQgcG93ZXIsIG1lbW9yeSwgYW5kIHByb2Nl c3NpbmcgcmVzb3VyY2VzLiBUaGV5IGFyZSBpbnRlcmNvbm5lY3RlZDxicj4NCiZndDsgYnkgYSB2 YXJpZXR5IG9mIGxpbmtzLCBzdWNoIGFzIElFRUUgODAyLjE1LjQsIEJsdWV0b290aCwgTG93IFBv d2VyIFdpRmksIHdpcmVkIG9yPGJyPg0KJmd0OyBvdGhlciBsb3cgcG93ZXIgUExDIChQb3dlcmxp bmUgQ29tbXVuaWNhdGlvbikgbGlua3MuIExMTnMgYXJlIHRyYW5zaXRpb25pbmcgdG88YnI+DQom Z3Q7IGFuIGVuZC10by1lbmQgSVAtYmFzZWQgc29sdXRpb24gdG8gYXZvaWQgdGhlIHByb2JsZW0g b2Ygbm9uLWludGVyb3BlcmFibGU8YnI+DQomZ3Q7IG5ldHdvcmtzIGludGVyY29ubmVjdGVkIGJ5 IHByb3RvY29sIHRyYW5zbGF0aW9uIGdhdGV3YXlzIGFuZCBwcm94aWVzLjxicj4NCiZndDs8YnI+ DQomZ3Q7IEdlbmVyYWxseSBzcGVha2luZywgTExOcyBoYXZlIGF0IGxlYXN0IGZpdmUgZGlzdGlu Z3Vpc2hpbmc8YnI+DQomZ3Q7IGNoYXJhY3RlcmlzdGljczo8YnI+DQomZ3Q7IC0gTExOcyBvcGVy YXRlIHdpdGggYSBoYXJkLCB2ZXJ5IHNtYWxsIGJvdW5kIG9uIHN0YXRlLjxicj4NCiZndDsgLSBJ biBtb3N0IGNhc2VzLCBMTE4gb3B0aW1pemUgZm9yIHNhdmluZyBlbmVyZ3kuPGJyPg0KJmd0OyAt IFR5cGljYWwgdHJhZmZpYyBwYXR0ZXJucyBhcmUgbm90IHNpbXBseSB1bmljYXN0IGZsb3dzIChl LmcuIGluIHNvbWUgY2FzZXMgbW9zdCBpZjxicj4NCiZndDsgbm90IGFsbCB0cmFmZmljIGNhbiBi ZSBwb2ludCB0byBtdWx0aXBvaW50KS48YnI+DQomZ3Q7IC0gSW4gbW9zdCBjYXNlcywgTExOcyB3 aWxsIGJlIGVtcGxveWVkIG92ZXIgbGluayBsYXllcnMgd2l0aCByZXN0cmljdGVkPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDtmcmFtZS1zaXplcywgdGh1cyBhIHJvdXRpbmcgcHJvdG9jb2wgZm9yIExM TnMgc2hvdWxkIGJlIHNwZWNpZmljYWxseTxicj4NCiZndDsmbmJzcDsgJm5ic3A7YWRhcHRlZCBm b3Igc3VjaCBsaW5rIGxheWVycy48YnI+DQomZ3Q7IC0gTExOIHJvdXRpbmcgcHJvdG9jb2xzIGhh dmUgdG8gYmUgdmVyeSBjYXJlZnVsIHdoZW4gdHJhZGluZyBvZmYgZWZmaWNpZW5jeTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7Zm9yIGdlbmVyYWxpdHk7IG1hbnkgTExOIG5vZGVzIGRvIG5vdCBoYXZl IHJlc291cmNlcyB0byB3YXN0ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVzZSBzcGVjaWZpYyBw cm9wZXJ0aWVzIGNhdXNlIExMTnMgdG8gaGF2ZSBzcGVjaWZpYyByb3V0aW5nIHJlcXVpcmVtZW50 cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBFeGlzdGluZyByb3V0aW5nIHByb3RvY29scyBzdWNoIGFz IE9TUEYsIElTLUlTLCBBT0RWLCBhbmQgT0xTUiBoYXZlIGJlZW48YnI+DQomZ3Q7IGV2YWx1YXRl ZCBieSB0aGUgd29ya2luZyBncm91cCBhbmQgaGF2ZSBpbiB0aGVpciBjdXJyZW50IGZvcm0gYmVl biBmb3VuZCB0bzxicj4NCiZndDsgbm90IHNhdGlzZnkgYWxsIG9mIHRoZXNlIHNwZWNpZmljIHJv dXRpbmcgcmVxdWlyZW1lbnRzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBXb3JraW5nIEdyb3Vw IGlzIGZvY3VzZWQgb24gcm91dGluZyBpc3N1ZXMgZm9yIExMTi48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBUaGVyZSBpcyBhIHdpZGUgc2NvcGUgb2YgYXBwbGljYXRpb24gYXJlYXMgZm9yIExMTnMsIGlu Y2x1ZGluZyBpbmR1c3RyaWFsPGJyPg0KJmd0OyBtb25pdG9yaW5nLCBidWlsZGluZyBhdXRvbWF0 aW9uIChIVkFDLCBsaWdodGluZywgYWNjZXNzIGNvbnRyb2wsIGZpcmUpLDxicj4NCiZndDsgY29u bmVjdGVkIGhvbWVzLCBoZWFsdGhjYXJlLCBlbnZpcm9ubWVudGFsIG1vbml0b3JpbmcsIHVyYmFu IHNlbnNvcjxicj4NCiZndDsgbmV0d29ya3MgKGUuZy4gU21hcnQgR3JpZCksIGFzc2V0IHRyYWNr aW5nLiBUaGUgV29ya2luZyBHcm91cCBmb2N1c2VzIG9uPGJyPg0KJmd0OyByb3V0aW5nIHNvbHV0 aW9ucyBmb3IgYSBzdWJzZXQgb2YgdGhlc2U6IGluZHVzdHJpYWwsIGNvbm5lY3RlZCBob21lLCBi dWlsZGluZyBhbmQ8YnI+DQomZ3Q7IHVyYmFuIHNlbnNvciBuZXR3b3JrcyBmb3Igd2hpY2ggcm91 dGluZyByZXF1aXJlbWVudHMgaGF2ZSBiZWVuIHNwZWNpZmllZC48YnI+DQomZ3Q7IFRoZXNlIGFw cGxpY2F0aW9uLXNwZWNpZmljIHJvdXRpbmcgcmVxdWlyZW1lbnQgZG9jdW1lbnRzIHdpbGwgYmUg dXNlZCBmb3I8YnI+DQomZ3Q7IHByb3RvY29sIGRlc2lnbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBU aGUgV29ya2luZyBHcm91cCBmb2N1c2VzIG9ubHkgb24gSVB2NiByb3V0aW5nIGFyY2hpdGVjdHVy YWwgZnJhbWV3b3JrIGZvcjxicj4NCiZndDsgdGhlc2UgYXBwbGljYXRpb24gc2NlbmFyaW9zLiBU aGUgRnJhbWV3b3JrIHdpbGwgdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24gdmFyaW91czxicj4NCiZn dDsgYXNwZWN0cyBpbmNsdWRpbmcgaGlnaCByZWxpYWJpbGl0eSBpbiB0aGUgcHJlc2VuY2Ugb2Yg dGltZSB2YXJ5aW5nIGxvc3M8YnI+DQomZ3Q7IGNoYXJhY3RlcmlzdGljcyBhbmQgY29ubmVjdGl2 aXR5IHdoaWxlIHBlcm1pdHRpbmcgbG93LXBvd2VyIG9wZXJhdGlvbiB3aXRoIHZlcnk8YnI+DQom Z3Q7IG1vZGVzdCBtZW1vcnkgYW5kIENQVSBwcmVzc3VyZSBpbiBuZXR3b3JrcyBwb3RlbnRpYWxs eSBjb21wcmlzaW5nIGEgdmVyeTxicj4NCiZndDsgbGFyZ2UgbnVtYmVyIChzZXZlcmFsIHRob3Vz YW5kcykgb2Ygbm9kZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIFdvcmtpbmcgR3JvdXAgd2ls bCBwYXkgcGFydGljdWxhciBhdHRlbnRpb24gdG8gcm91dGluZyBzZWN1cml0eSBhbmQ8YnI+DQom Z3Q7IG1hbmFnZWFiaWxpdHkgKGUuZy4sIHNlbGYgcm91dGluZyBjb25maWd1cmF0aW9uKSBpc3N1 ZXMuIEl0IHdpbGwgYWxzbyBuZWVkIHRvPGJyPg0KJmd0OyBjb25zaWRlciB0aGUgdHJhbnNwb3J0 IGNoYXJhY3RlcmlzdGljIHRoZSByb3V0aW5nIHByb3RvY29sIG1lc3NhZ2VzIHdpbGw8YnI+DQom Z3Q7IGV4cGVyaWVuY2UuIE1lY2hhbmlzbXMgdGhhdCBwcm90ZWN0IGFuIExMTiBmcm9tIGNvbmdl c3Rpb24gY29sbGFwc2Ugb3IgdGhhdDxicj4NCiZndDsgZXN0YWJsaXNoIHNvbWUgZGVncmVlIG9m IGZhaXJuZXNzIGJldHdlZW4gY29uY3VycmVudCBjb21tdW5pY2F0aW9uIHNlc3Npb25zPGJyPg0K Jmd0OyBhcmUgb3V0IG9mIHNjb3BlIG9mIHRoZSBXb3JraW5nIEdyb3VwLiBJdCBpcyBleHBlY3Rl ZCB0aGF0IHVwcGVyLWxheWVyPGJyPg0KJmd0OyBhcHBsaWNhdGlvbnMgdXRpbGl6aW5nIExMTnMg ZGVmaW5lIGFwcHJvcHJpYXRlIG1lY2hhbmlzbXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHNv bHV0aW9uIG11c3QgaW5jbHVkZSB1bmljYXN0IGFuZCBtdWx0aWNhc3QgY29uc2lkZXJhdGlvbnMu PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBkb2N1bWVudCBob3cg bm9uLWNvbnRyb2wgcGFja2V0cyBhcmUgcm91dGVkIHdoZW48YnI+DQomZ3Q7IHRoZXkgY3Jvc3Mg dGhlIExMTiwgYW5kIHdoZW4gdGhleSBlbnRlciBhbmQgZXhpdCB0aGUgTExOOiB0aGUgYXBwcm9w cmlhdGUgdXNlIG9mPGJyPg0KJmd0OyBSSDMgKFJGQzY1NTMpLCBSUEkgKFJGQzY1NTQpIGFuZCBJ UElQIGVuY2Fwc3VsYXRpb24gaW5jbHVkaW5nIGhvdyByb3V0aW5nPGJyPg0KJmd0OyBsb29wcyBh cmUgZGV0ZWN0ZWQuIEluIGNvbnN1bHRhdGlvbiB3aXRoIHRoZSA2bG8gV0csIHRoZSBXb3JraW5n IEdyb3VwIHdpbGw8YnI+DQomZ3Q7IGRlc2lnbiBhIG1ldGhvZCB0byB0aGVzZSByb3V0aW5nIGhl YWRlcnMgaW50byBhIHNpbmdsZSBibG9jay4mbmJzcDsgVGhlIHJlc3VsdCB3aWxsPGJyPg0KJmd0 OyBoYXZlIGEgc2hhcmVkIFdHTEMgd2l0aCA2bG8uPGJyPg0KJmd0Ozxicj4NCiZndDsgV29yayBJ dGVtczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IC0gU3BlY2lmaWNh dGlvbiBvZiByb3V0aW5nIG1ldHJpY3MgdXNlZCBpbiBwYXRoIGNhbGN1bGF0aW9uLiBUaGlzPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmNsdWRlcyBzdGF0aWMgYW5kIGR5 bmFtaWMgbGluay9ub2RlIGF0dHJpYnV0ZXMgcmVxdWlyZWQgZm9yIHJvdXRpbmcgaW48YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IExMTnMuPGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAtIFByb3ZpZGUgYW4gYXJjaGl0ZWN0dXJhbCBmcmFtZXdvcmsg Zm9yIHJvdXRpbmcgYW5kIHBhdGggc2VsZWN0aW9uIGF0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBMYXllciAzIChSb3V0aW5nIGZvciBMTE4gQXJjaGl0ZWN0dXJlKSB0aGF0 IGFkZHJlc3NlcyBzdWNoIGlzc3VlcyBhczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgd2hldGhlciBMTE4gcm91dGluZyByZXF1aXJlIGEgZGlzdHJpYnV0ZWQgYW5kL29yIGNl bnRyYWxpemVkIHBhdGg8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbXB1 dGF0aW9uIG1vZGVscywgd2hldGhlciBhZGRpdGlvbmFsIGhpZXJhcmNoeSBpcyBuZWNlc3Nhcnkg YW5kIGhvdyBpdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXMgYXBwbGll ZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNYW5hZ2Vh YmlsaXR5IHdpbGwgYmUgY29uc2lkZXJlZCB3aXRoIGVhY2ggYXBwcm9hY2gsIGFsb25nIHdpdGgg dmFyaW91czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhZGUtb2ZmcyBm b3IgbWFpbnRhaW5pbmcgbG93IHBvd2VyIG9wZXJhdGlvbiwgaW5jbHVkaW5nIHRoZSBwcmVzZW5j ZSBvZjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbm9uLXRyaXZpYWwgbG9z cyBhbmQgbmV0d29ya3Mgd2l0aCBhIHZlcnkgbGFyZ2UgbnVtYmVyIG9mIG5vZGVzLjxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLSBQcm9kdWNlIGEgcm91dGluZyBzZWN1 cml0eSBmcmFtZXdvcmsgZm9yIHJvdXRpbmcgaW4gTExOcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7IC0gUHJvdG9jb2wgd29yazogVGhlIFdvcmtpbmcgR3JvdXAgd2ls bCBjb25zaWRlciBzcGVjaWZpYyByb3V0aW5nPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyByZXF1aXJlbWVudHMgZnJvbSB0aGUgZm91ciBhcHBsaWNhdGlvbiBkb2N1bWVudHMg Y29sbGVjdGl2ZWx5LCBhbmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNw ZWNpZnkgZWl0aGVyIGEgbmV3IHByb3RvY29sIG9yIGV4dGVuZCBhbiBleGlzdGluZyByb3V0aW5n IHByb3RvY29sPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbiBjb29wZXJh dGlvbiB3aXRoIHRoZSByZWxldmFudCBXb3JraW5nIEdyb3VwLjxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgSWYgcmVxdWlyZW1lbnRzIGZyb20gdGhlIGZvdXIgdGFyZ2V0IGFw cGxpY2F0aW9uIGFyZWFzIGNhbm5vdCBiZSBtZXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHdpdGggYSBzaW5nbGUgcHJvdG9jb2wsIHRoZSBXRyBtYXkgY2hvb3NlIHRvIHNw ZWNpZnkgb3IgZXh0ZW5kIG1vcmUgdGhhbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgb25lIHByb3RvY29sICh0aGlzIHdpbGwgcmVxdWlyZSBhIHJlY2hhcnRlciBvZiB0aGUg V0cpLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLSBEb2N1bWVudGF0 aW9uIG9mIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IG9mIFJPTEwgcm91dGluZyBwcm90b2NvbHMu PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIEEgZG9jdW1lbnQgZGV0 YWlsaW5nIHdoZW4gdG8gdXNlIFJGQzY1NTMsIFJGQzY1NTQgYW5kIElQSVA8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVuY2Fwc3VsYXRpb24uPGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIEEgZG9jdW1lbnQgZGV0YWlsaW5nIGhvdyB0byBjb21w cmVzcyBSRkM2NTUzLCBSRkM2NTU0IGFuZCBJUCBoZWFkZXJzPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBpbiB0aGUgNmxvd1BBTiBIQyBjb250ZXh0Ljxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJElkOiBjaGFydGVyLnR4dCx2IDEuMyAyMDE1LzAz LzIzIDE4OjMzOjM4IG1jciBFeHAgJDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgLS08YnI+DQomZ3Q7IE1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1jciUyQklFVEZAc2FuZGVsbWFuLmNhIj5tY3ImIzQzO0lFVEZAc2FuZGVsbWFuLmNhPC9hPiZn dDssIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrczxicj4NCiZndDsgSUVURiBST0xMIFdHIGNvLWNo YWlyLiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dn L3JvbGwvY2hhcnRlci8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy93Zy9yb2xsL2NoYXJ0ZXIvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpSb2xsIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIj5Sb2xsQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_E045AECD98228444A58C61C200AE1BD849D98770xmbrcdx01ciscoc_-- From nobody Thu Apr 2 09:17: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 784C11ACEE4 for ; Thu, 2 Apr 2015 09:17:05 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 YdADeKwDPjzw for ; Thu, 2 Apr 2015 09:17:00 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86BE1B2D30 for ; Thu, 2 Apr 2015 09:16:59 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0429.eurprd01.prod.exchangelabs.com (10.242.221.20) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 2 Apr 2015 16:16:54 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.01.0118.022; Thu, 2 Apr 2015 16:16:54 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] proposed amendments to ROLL charter Thread-Index: AQHQZZj1v7J7klL7k0mqWWPDm9kW/502daSAgAA37ACAA0NcAIAABMAG Date: Thu, 2 Apr 2015 16:16:54 +0000 Message-ID: References: <30526.1427136071@sandelman.ca> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.193.172.255] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0429; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(24454002)(13464003)(479174004)(51444003)(377424004)(52604005)(51704005)(377454003)(2950100001)(54356999)(19625215002)(66066001)(19580395003)(19580405001)(36756003)(2656002)(102836002)(16297215004)(33656002)(16236675004)(76176999)(19617315012)(77096005)(110136001)(122556002)(82746002)(15975445007)(92566002)(86362001)(62966003)(50986999)(106116001)(93886004)(46102003)(87936001)(83716003)(5890100001)(2900100001)(77156002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0429; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DB4PR01MB0429; BCL:0; PCL:0; RULEID:; SRVR:DB4PR01MB0429; x-forefront-prvs: 0534947130 Content-Type: multipart/alternative; boundary="_000_A3EFBECDA46B4312A52FD702EA84A8BElandisgyrcom_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 16:16:54.4677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR01MB0429 Archived-At: Cc: Michael Richardson Subject: Re: [Roll] proposed amendments to ROLL charter 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 Apr 2015 16:17:05 -0000 --_000_A3EFBECDA46B4312A52FD702EA84A8BElandisgyrcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Pascal Routing table entries usually have lifetimes. Wouldn't that clean up dead r= outes at the root? Randy On Apr 2, 2015, at 12:00 PM, Pascal Thubert (pthubert) > wrote: A few other things I=92d like to see, Ines: - One is a MOP based on BIER and/or Bloom filters, which is a way to compre= ss BIER with a chance of false positive. Carsten has a draft that details t= he use of Bloom filters for source routing, but really both BIER and Bloom = can apply to either storing and non-storing. - Work on mixed storing and non-storing, and all sort of optimization for t= he storing mode. I=92m aware of feasible solutions in that space that reall= y should be shared and made available to all. - Work on additional capabilities that we did not initially include in the = spec: - The capability to kill a route from the root, e.g. if a DAO state is inst= alled and should be cleaned up, e.g. if the root realizes that the node is = no more there or there is a duplication or what-else. - The capability to trigger a DAO from the root if a target is expected to = be present in the network but there is no DAO state (maybe to save resource= s) - The capability to request the triggering of a new iteration of a DODAG fr= om a RPL node or a controlling element. Thanks for asking :) Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Ines Robles Sent: mardi 31 mars 2015 16:10 To: Routing Over Low power and Lossy networks Cc: Michael Richardson Subject: Re: [Roll] proposed amendments to ROLL charter Hi Pascal, Thank you very much for your comments, we are going to include them in our = meeting. To all, There are additional topics that you would like to include in the c= harter? Please justify. Thank you very much, Michael and Ines 2015-03-31 13:49 GMT+03:00 Pascal Thubert (pthubert) >: Hello Michael (and all): I fully support the additions. Since you are at it, I would like to explore= a deeper realignment. ROLL is now in charge of the maintenance of RPL, isn't it? - I think that this should be a work item in the charter. - this should replace elements that were or are being delivered such as met= rics, security, and RPL itself And if that's so, wouldn't it make sense to study how RPL works outside LLN= s and in mixed environments? - I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. Appl= icability of RPL in various environments outside LLN would be of interest, = e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that a DT will= form at HOMENET to select a routing protocol, and an applicability stateme= nt of RPL for that case would be a good read if we can produce it in time. - From our experience of actually doing RPL over Ethernet, it is mostly a m= atter of *not* using the packet artifacts, probably not using the stretch i= n local repair, and reacting immediately to changes in link state. This is = a very small spec indeed, mostly guidance on what to use and what not to us= e from RFC 6550, how to tune some parameters, which OF to use and how. - The work should also detail the mode where there is a backbone and a virt= ual root. I think that the current charter does not cover work outside LLN = but considering that we are the group that knows RPL best, that work should= happen here. What do you think? Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] O= n Behalf Of Michael Richardson > Sent: lundi 23 mars 2015 19:41 > To: roll@ietf.org > Subject: [Roll] proposed amendments to ROLL charter > > > The following changes are proposed for the ROLL charter to include the wo= rk to > profile 6553/6554/IPIP, and to compress it. > > To the pre-amble: > > After: > - In most cases, LLNs will be employed over link layers with restricted > frame-sizes, thus a routing protocol for LLNs should be specifically > adapted for such link layers. > > Add: > +- LLN routing protocols have to be very careful when trading off > +efficiency > + for generality; many LLN nodes do not have resources to waste. > > After: > The solution must include unicast and multicast considerations. > > Add: > +The Working Group will document how non-control packets are routed when > +they cross the LLN, and when they enter and exit the LLN: the > +appropriate use of > +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how > +routing loops are detected. In consultation with the 6lo WG, the > +Working Group will design a method to these routing headers into a > +single block. The result will have a shared WGLC with 6lo. > > To Work Items, add: > + - A document detailing when to use RFC6553, RFC6554 and IPIP > + encapsulation. > + > + - A document detailing how to compress RFC6553, RFC6554 and IP head= ers > + in the 6lowPAN HC context. > > > The resulting charter (after reformatting of some of the ugly text wrappi= ng on > the web site) is: > > ---- > Low power and Lossy networks (LLNs) are made up of many embedded devices > with limited power, memory, and processing resources. They are interconne= cted > by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, = wired or > other low power PLC (Powerline Communication) links. LLNs are transitioni= ng to > an end-to-end IP-based solution to avoid the problem of non-interoperable > networks interconnected by protocol translation gateways and proxies. > > Generally speaking, LLNs have at least five distinguishing > characteristics: > - LLNs operate with a hard, very small bound on state. > - In most cases, LLN optimize for saving energy. > - Typical traffic patterns are not simply unicast flows (e.g. in some cas= es most if > not all traffic can be point to multipoint). > - In most cases, LLNs will be employed over link layers with restricted > frame-sizes, thus a routing protocol for LLNs should be specifically > adapted for such link layers. > - LLN routing protocols have to be very careful when trading off efficien= cy > for generality; many LLN nodes do not have resources to waste. > > These specific properties cause LLNs to have specific routing requirement= s. > > Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been > evaluated by the working group and have in their current form been found = to > not satisfy all of these specific routing requirements. > > The Working Group is focused on routing issues for LLN. > > There is a wide scope of application areas for LLNs, including industrial > monitoring, building automation (HVAC, lighting, access control, fire), > connected homes, healthcare, environmental monitoring, urban sensor > networks (e.g. Smart Grid), asset tracking. The Working Group focuses on > routing solutions for a subset of these: industrial, connected home, buil= ding and > urban sensor networks for which routing requirements have been specified. > These application-specific routing requirement documents will be used for > protocol design. > > The Working Group focuses only on IPv6 routing architectural framework fo= r > these application scenarios. The Framework will take into consideration v= arious > aspects including high reliability in the presence of time varying loss > characteristics and connectivity while permitting low-power operation wit= h very > modest memory and CPU pressure in networks potentially comprising a very > large number (several thousands) of nodes. > > The Working Group will pay particular attention to routing security and > manageability (e.g., self routing configuration) issues. It will also nee= d to > consider the transport characteristic the routing protocol messages will > experience. Mechanisms that protect an LLN from congestion collapse or th= at > establish some degree of fairness between concurrent communication sessio= ns > are out of scope of the Working Group. It is expected that upper-layer > applications utilizing LLNs define appropriate mechanisms. > > The solution must include unicast and multicast considerations. > > The Working Group will document how non-control packets are routed when > they cross the LLN, and when they enter and exit the LLN: the appropriate= use of > RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing > loops are detected. In consultation with the 6lo WG, the Working Group wi= ll > design a method to these routing headers into a single block. The result= will > have a shared WGLC with 6lo. > > Work Items: > > - Specification of routing metrics used in path calculation. This > includes static and dynamic link/node attributes required for rout= ing in > LLNs. > > - Provide an architectural framework for routing and path selection = at > Layer 3 (Routing for LLN Architecture) that addresses such issues = as > whether LLN routing require a distributed and/or centralized path > computation models, whether additional hierarchy is necessary and = how it > is applied. > > Manageability will be considered with each approach, along with va= rious > trade-offs for maintaining low power operation, including the pres= ence of > non-trivial loss and networks with a very large number of nodes. > > - Produce a routing security framework for routing in LLNs. > > - Protocol work: The Working Group will consider specific routing > requirements from the four application documents collectively, and > specify either a new protocol or extend an existing routing protoc= ol > in cooperation with the relevant Working Group. > If requirements from the four target application areas cannot be m= et > with a single protocol, the WG may choose to specify or extend mor= e than > one protocol (this will require a recharter of the WG). > > - Documentation of applicability statement of ROLL routing protocols= . > > - A document detailing when to use RFC6553, RFC6554 and IPIP > encapsulation. > > - A document detailing how to compress RFC6553, RFC6554 and IP heade= rs > in the 6lowPAN HC context. > > > > $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $ > > > > -- > Michael Richardson = >, Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ 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 P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_A3EFBECDA46B4312A52FD702EA84A8BElandisgyrcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Pascal

Routing table entries usually have lifetimes. Wouldn't that clean up d= ead routes at the root?

Randy


On Apr 2, 2015, at 12:00 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

A few other things I=92d = like to see, Ines:

 <= /p>

- One is a MOP based on B= IER and/or Bloom filters, which is a way to compress BIER with a chance of = false positive. Carsten has a draft that details the use of Bloom filters for source routing, but really both BIER and Bloom can ap= ply to either storing and non-storing.

- Work on mixed storing a= nd non-storing, and all sort of optimization for the storing mode. I=92m aw= are of feasible solutions in that space that really should be shared and made available to all.

- Work on additional capa= bilities that we did not initially include in the spec:

- The capability to kill a route from the root, e.g. if a DAO state is = installed and should be cleaned up, e.g. if the root realizes that the node is no more there or there is a duplication or what-else.

- The capability to trigger a DAO from the root if a target is expected= to be present in the network but there is no DAO state (maybe to save resources)

- The capability to request the triggering of a new iteration of a DODA= G from a RPL node or a controlling element.

 <= /p>

Thanks for asking J

 

Pascal

 <= /p>

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Ines Robles
Sent: mardi 31 mars 2015 16:10
To: Routing Over Low power and Lossy networks
Cc: Michael Richardson
Subject: Re: [Roll] proposed amendments to ROLL charter

 

Hi Pascal,

 

Thank you very much for your comments, we are going = to include them in our meeting. 

 

To all, There are additional topics that you would l= ike to include in the charter? Please justify.

 

Thank you very much,

 

Michael and Ines

 

2015-03-31 13:49 GMT+03:00 Pascal Thubert (pthub= ert) <pthubert@c= isco.com>:

Hello Michael (and all):

I fully support the additions. Since you are at it, I would like to explore= a deeper realignment.

ROLL is now in charge of the maintenance of RPL, isn't it?
- I think that this should be a work item in the charter.
- this should replace elements that were or are being delivered such as met= rics, security, and RPL itself

And if that's so, wouldn't it make sense to study how RPL works outside LLN= s and in mixed environments?
- I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. Appl= icability of RPL in various environments outside LLN would be of interest, = e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that a DT will= form at HOMENET to select a routing protocol, and an applicability statement of RPL for that case would be a g= ood read if we can produce it in time.
- From our experience of actually doing RPL over Ethernet, it is mostly a m= atter of *not* using the packet artifacts, probably not using the stretch i= n local repair, and reacting immediately to changes in link state. This is = a very small spec indeed, mostly guidance on what to use and what not to use from RFC 6550, how to tune som= e parameters, which OF to use and how.
- The work should also detail the mode where there is a backbone and a virt= ual root. I think that the current charter does not cover work outside LLN = but considering that we are the group that knows RPL best, that work should= happen here.

What do you think?

Pascal


> -----Original Message-----
> From: Roll [mailto:roll-bounc= es@ietf.org] On Behalf Of Michael Richardson
> Sent: lundi 23 mars 2015 19:41
> To: roll@ietf.org
> Subject: [Roll] proposed amendments to ROLL charter
>
>
> The following changes are proposed for the ROLL charter to include the= work to
> profile 6553/6554/IPIP, and to compress it.
>
> To the pre-amble:
>
> After:
>  - In most cases, LLNs will be employed over link layers with res= tricted
>    frame-sizes, thus a routing protocol for LLNs should be s= pecifically
>    adapted for such link layers.
>
> Add:
> +- LLN routing protocols have to be very careful when trading off<= br> > +efficiency
> +  for generality; many LLN nodes do not have resources to wa= ste.
>
> After:
>  The solution must include unicast and multicast considerations.<= br> >
> Add:
> +The Working Group will document how non-control packets are route= d when
> +they cross the LLN, and when they enter and exit the LLN: the
> +appropriate use of
> +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how=
> +routing loops are detected. In consultation with the 6lo WG, the<= br> > +Working Group will design a method to these routing headers into = a
> +single block.  The result will have a shared WGLC with 6lo.<= o:p>

>
> To  Work Items, add:
> +     - A document detailing when to use RFC6553, R= FC6554 and IPIP
> +       encapsulation.
> +
> +     - A document detailing how to compress RFC655= 3, RFC6554 and IP headers
> +       in the 6lowPAN HC context.
>
>
> The resulting charter (after reformatting of some of the ugly text wra= pping on
> the web site) is:
>
> ----
> Low power and Lossy networks (LLNs) are made up of many embedded devic= es
> with limited power, memory, and processing resources. They are interco= nnected
> by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiF= i, wired or
> other low power PLC (Powerline Communication) links. LLNs are transiti= oning to
> an end-to-end IP-based solution to avoid the problem of non-interopera= ble
> networks interconnected by protocol translation gateways and proxies.<= br> >
> Generally speaking, LLNs have at least five distinguishing
> characteristics:
> - LLNs operate with a hard, very small bound on state.
> - In most cases, LLN optimize for saving energy.
> - Typical traffic patterns are not simply unicast flows (e.g. in some = cases most if
> not all traffic can be point to multipoint).
> - In most cases, LLNs will be employed over link layers with restricte= d
>   frame-sizes, thus a routing protocol for LLNs should be sp= ecifically
>   adapted for such link layers.
> - LLN routing protocols have to be very careful when trading off effic= iency
>   for generality; many LLN nodes do not have resources to wa= ste.
>
> These specific properties cause LLNs to have specific routing requirem= ents.
>
> Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have be= en
> evaluated by the working group and have in their current form been fou= nd to
> not satisfy all of these specific routing requirements.
>
> The Working Group is focused on routing issues for LLN.
>
> There is a wide scope of application areas for LLNs, including industr= ial
> monitoring, building automation (HVAC, lighting, access control, fire)= ,
> connected homes, healthcare, environmental monitoring, urban sensor > networks (e.g. Smart Grid), asset tracking. The Working Group focuses = on
> routing solutions for a subset of these: industrial, connected home, b= uilding and
> urban sensor networks for which routing requirements have been specifi= ed.
> These application-specific routing requirement documents will be used = for
> protocol design.
>
> The Working Group focuses only on IPv6 routing architectural framework= for
> these application scenarios. The Framework will take into consideratio= n various
> aspects including high reliability in the presence of time varying los= s
> characteristics and connectivity while permitting low-power operation = with very
> modest memory and CPU pressure in networks potentially comprising a ve= ry
> large number (several thousands) of nodes.
>
> The Working Group will pay particular attention to routing security an= d
> manageability (e.g., self routing configuration) issues. It will also = need to
> consider the transport characteristic the routing protocol messages wi= ll
> experience. Mechanisms that protect an LLN from congestion collapse or= that
> establish some degree of fairness between concurrent communication ses= sions
> are out of scope of the Working Group. It is expected that upper-layer=
> applications utilizing LLNs define appropriate mechanisms.
>
> The solution must include unicast and multicast considerations.
>
> The Working Group will document how non-control packets are routed whe= n
> they cross the LLN, and when they enter and exit the LLN: the appropri= ate use of
> RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how rout= ing
> loops are detected. In consultation with the 6lo WG, the Working Group= will
> design a method to these routing headers into a single block.  Th= e result will
> have a shared WGLC with 6lo.
>
> Work Items:
>
>      - Specification of routing metrics used in path ca= lculation. This
>        includes static and dynamic link/node attri= butes required for routing in
>        LLNs.
>
>      - Provide an architectural framework for routing a= nd path selection at
>        Layer 3 (Routing for LLN Architecture) that= addresses such issues as
>        whether LLN routing require a distributed a= nd/or centralized path
>        computation models, whether additional hier= archy is necessary and how it
>        is applied.
>
>        Manageability will be considered with each = approach, along with various
>        trade-offs for maintaining low power operat= ion, including the presence of
>        non-trivial loss and networks with a very l= arge number of nodes.
>
>      - Produce a routing security framework for routing= in LLNs.
>
>      - Protocol work: The Working Group will consider s= pecific routing
>        requirements from the four application docu= ments collectively, and
>        specify either a new protocol or extend an = existing routing protocol
>        in cooperation with the relevant Working Gr= oup.
>        If requirements from the four target applic= ation areas cannot be met
>        with a single protocol, the WG may choose t= o specify or extend more than
>        one protocol (this will require a recharter= of the WG).
>
>      - Documentation of applicability statement of ROLL= routing protocols.
>
>      - A document detailing when to use RFC6553, RFC655= 4 and IPIP
>        encapsulation.
>
>      - A document detailing how to compress RFC6553, RF= C6554 and IP headers
>        in the 6lowPAN HC context.
>
>
>
> $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $
>
>
>
> --
> Michael Richardson <mcr&= #43;IETF@sandelman.ca>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

 

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

P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_A3EFBECDA46B4312A52FD702EA84A8BElandisgyrcom_-- From nobody Thu Apr 2 09:41: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 05B7D1ACE2B; Thu, 2 Apr 2015 09:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] 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 kn3WyqSVuP0H; Thu, 2 Apr 2015 09:41:38 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB9E1B2D77; Thu, 2 Apr 2015 09:41:13 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t32GfCni009769; Thu, 2 Apr 2015 18:41:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 6CD382A0C75; Thu, 2 Apr 2015 18:41:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id rO0xPPGH0Xld; Thu, 2 Apr 2015 18:41:10 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D3C0A2A0C6D; Thu, 2 Apr 2015 18:41:10 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.84) (envelope-from ) id 1YdiB4-0002Q5-Hw; Thu, 02 Apr 2015 18:41:10 +0200 Date: Thu, 02 Apr 2015 18:41:10 +0200 Message-ID: <7ipp7m7aah.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Routing Over Low power and Lossy networks In-Reply-To: References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 02 Apr 2015 18:41:12 +0200 (CEST) X-Miltered: at korolev with ID 551D7128.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551D7128.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 551D7128.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: "manet@ietf.org" Subject: Re: [Roll] Understanding RPL [was: Working group re-charter ideas] 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 Apr 2015 16:41:40 -0000 > Some papers dealing with the RPL repair and loop avoidance mechanisms > (and exlaining them) are for example Thanks for the references, Yvonne-Anne. I'll have a look as soon as I find out whether we still have access to IEEE-paywalled articles (budget cuts, so I'm no longer sure we do). However -- some of the abstracts are not entirely clear, but it looks like it's all simulation work. Do you have any experimental data? -- Juliusz From nobody Thu Apr 2 10:17: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 E93561ACEC0 for ; Thu, 2 Apr 2015 10:17:55 -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 wBdqkMz7P7qp for ; Thu, 2 Apr 2015 10:17:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310521ACE24 for ; Thu, 2 Apr 2015 10:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37238; q=dns/txt; s=iport; t=1427995069; x=1429204669; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ogu7I1Jase6JHOijqZB9EjQN9eQgA8OEY+PxtfKr8dw=; b=IJ2ahDO4e/vsw3aQaoeAb07WwR6hBDxW6j2A+NgVz6sG6bAh3TjcQvU9 Li5FzMWJVr5nBolx2sg0IssRocepXKr33KUxzBUIJJ7MHKwLImZ7VMR9m 6XYEKFkmG07I1KHL5sk2G4cUsoOiaLzAhU4vNgikDYrfX7lLtpA3Ciueq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CgCQCQeB1V/4cNJK1cgkVDUlwFtW2NMTyBYBkBCYVzAoFKTAEBAQEBAX6EHgEBAQMBAQEBFxNBCwwEAgEIEQEDAQELFgEGBycLFAMGCAIEDgUIE4gMCA3OGwEBAQEBAQEBAQEBAQEBAQEBAQEBAReKKn+EFgoHAQIeLAEEBgEGgxGBFgWEV4wTg3WECoICgRw6gnqCXolRg0giggIcgVBvgQIJFyJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,512,1422921600"; d="scan'208,217";a="408754064" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 02 Apr 2015 17:17:47 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t32HHkYu031305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 17:17:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 12:17:46 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] proposed amendments to ROLL charter Thread-Index: AQHQZZj1v7J7klL7k0mqWWPDm9kW/502daSAgAA37ACAA0NcAIAABMAGgAAPXwA= Date: Thu, 2 Apr 2015 17:17:46 +0000 Deferred-Delivery: Thu, 2 Apr 2015 17:17:00 +0000 Message-ID: References: <30526.1427136071@sandelman.ca> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD849D98EB8xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson Subject: Re: [Roll] proposed amendments to ROLL charter 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 Apr 2015 17:17:56 -0000 --_000_E045AECD98228444A58C61C200AE1BD849D98EB8xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Randy Sure, Randy, but stale routes will send packets to black holes till they el= apse, cutting some communication. This is not a big issue is most WSNs so w= e have not addressed it in the main spec. One case I have in mind is multiple DODAGs. The root learns from some routi= ng protocol over the backbone that a node moved to another DODAG. But the root and all nodes down the path where that node used to be still h= ave an DAO entry, for potentially a long time. The root can discard its own state but it cannot cleanup down the dodag, le= ading to a local blackholing for packets issued in that affected zone. Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Turner, Randy Sent: jeudi 2 avril 2015 18:17 To: Routing Over Low power and Lossy networks Cc: Michael Richardson Subject: Re: [Roll] proposed amendments to ROLL charter Hi Pascal Routing table entries usually have lifetimes. Wouldn't that clean up dead r= outes at the root? Randy On Apr 2, 2015, at 12:00 PM, Pascal Thubert (pthubert) > wrote: A few other things I'd like to see, Ines: - One is a MOP based on BIER and/or Bloom filters, which is a way to compre= ss BIER with a chance of false positive. Carsten has a draft that details t= he use of Bloom filters for source routing, but really both BIER and Bloom = can apply to either storing and non-storing. - Work on mixed storing and non-storing, and all sort of optimization for t= he storing mode. I'm aware of feasible solutions in that space that really = should be shared and made available to all. - Work on additional capabilities that we did not initially include in the = spec: - The capability to kill a route from the root, e.g. if a DAO state is inst= alled and should be cleaned up, e.g. if the root realizes that the node is = no more there or there is a duplication or what-else. - The capability to trigger a DAO from the root if a target is expected to = be present in the network but there is no DAO state (maybe to save resource= s) - The capability to request the triggering of a new iteration of a DODAG fr= om a RPL node or a controlling element. Thanks for asking :) Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Ines Robles Sent: mardi 31 mars 2015 16:10 To: Routing Over Low power and Lossy networks Cc: Michael Richardson Subject: Re: [Roll] proposed amendments to ROLL charter Hi Pascal, Thank you very much for your comments, we are going to include them in our = meeting. To all, There are additional topics that you would like to include in the c= harter? Please justify. Thank you very much, Michael and Ines 2015-03-31 13:49 GMT+03:00 Pascal Thubert (pthubert) >: Hello Michael (and all): I fully support the additions. Since you are at it, I would like to explore= a deeper realignment. ROLL is now in charge of the maintenance of RPL, isn't it? - I think that this should be a work item in the charter. - this should replace elements that were or are being delivered such as met= rics, security, and RPL itself And if that's so, wouldn't it make sense to study how RPL works outside LLN= s and in mixed environments? - I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. Appl= icability of RPL in various environments outside LLN would be of interest, = e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that a DT will= form at HOMENET to select a routing protocol, and an applicability stateme= nt of RPL for that case would be a good read if we can produce it in time. - From our experience of actually doing RPL over Ethernet, it is mostly a m= atter of *not* using the packet artifacts, probably not using the stretch i= n local repair, and reacting immediately to changes in link state. This is = a very small spec indeed, mostly guidance on what to use and what not to us= e from RFC 6550, how to tune some parameters, which OF to use and how. - The work should also detail the mode where there is a backbone and a virt= ual root. I think that the current charter does not cover work outside LLN = but considering that we are the group that knows RPL best, that work should= happen here. What do you think? Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] O= n Behalf Of Michael Richardson > Sent: lundi 23 mars 2015 19:41 > To: roll@ietf.org > Subject: [Roll] proposed amendments to ROLL charter > > > The following changes are proposed for the ROLL charter to include the wo= rk to > profile 6553/6554/IPIP, and to compress it. > > To the pre-amble: > > After: > - In most cases, LLNs will be employed over link layers with restricted > frame-sizes, thus a routing protocol for LLNs should be specifically > adapted for such link layers. > > Add: > +- LLN routing protocols have to be very careful when trading off > +efficiency > + for generality; many LLN nodes do not have resources to waste. > > After: > The solution must include unicast and multicast considerations. > > Add: > +The Working Group will document how non-control packets are routed when > +they cross the LLN, and when they enter and exit the LLN: the > +appropriate use of > +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how > +routing loops are detected. In consultation with the 6lo WG, the > +Working Group will design a method to these routing headers into a > +single block. The result will have a shared WGLC with 6lo. > > To Work Items, add: > + - A document detailing when to use RFC6553, RFC6554 and IPIP > + encapsulation. > + > + - A document detailing how to compress RFC6553, RFC6554 and IP head= ers > + in the 6lowPAN HC context. > > > The resulting charter (after reformatting of some of the ugly text wrappi= ng on > the web site) is: > > ---- > Low power and Lossy networks (LLNs) are made up of many embedded devices > with limited power, memory, and processing resources. They are interconne= cted > by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, = wired or > other low power PLC (Powerline Communication) links. LLNs are transitioni= ng to > an end-to-end IP-based solution to avoid the problem of non-interoperable > networks interconnected by protocol translation gateways and proxies. > > Generally speaking, LLNs have at least five distinguishing > characteristics: > - LLNs operate with a hard, very small bound on state. > - In most cases, LLN optimize for saving energy. > - Typical traffic patterns are not simply unicast flows (e.g. in some cas= es most if > not all traffic can be point to multipoint). > - In most cases, LLNs will be employed over link layers with restricted > frame-sizes, thus a routing protocol for LLNs should be specifically > adapted for such link layers. > - LLN routing protocols have to be very careful when trading off efficien= cy > for generality; many LLN nodes do not have resources to waste. > > These specific properties cause LLNs to have specific routing requirement= s. > > Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been > evaluated by the working group and have in their current form been found = to > not satisfy all of these specific routing requirements. > > The Working Group is focused on routing issues for LLN. > > There is a wide scope of application areas for LLNs, including industrial > monitoring, building automation (HVAC, lighting, access control, fire), > connected homes, healthcare, environmental monitoring, urban sensor > networks (e.g. Smart Grid), asset tracking. The Working Group focuses on > routing solutions for a subset of these: industrial, connected home, buil= ding and > urban sensor networks for which routing requirements have been specified. > These application-specific routing requirement documents will be used for > protocol design. > > The Working Group focuses only on IPv6 routing architectural framework fo= r > these application scenarios. The Framework will take into consideration v= arious > aspects including high reliability in the presence of time varying loss > characteristics and connectivity while permitting low-power operation wit= h very > modest memory and CPU pressure in networks potentially comprising a very > large number (several thousands) of nodes. > > The Working Group will pay particular attention to routing security and > manageability (e.g., self routing configuration) issues. It will also nee= d to > consider the transport characteristic the routing protocol messages will > experience. Mechanisms that protect an LLN from congestion collapse or th= at > establish some degree of fairness between concurrent communication sessio= ns > are out of scope of the Working Group. It is expected that upper-layer > applications utilizing LLNs define appropriate mechanisms. > > The solution must include unicast and multicast considerations. > > The Working Group will document how non-control packets are routed when > they cross the LLN, and when they enter and exit the LLN: the appropriate= use of > RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing > loops are detected. In consultation with the 6lo WG, the Working Group wi= ll > design a method to these routing headers into a single block. The result= will > have a shared WGLC with 6lo. > > Work Items: > > - Specification of routing metrics used in path calculation. This > includes static and dynamic link/node attributes required for rout= ing in > LLNs. > > - Provide an architectural framework for routing and path selection = at > Layer 3 (Routing for LLN Architecture) that addresses such issues = as > whether LLN routing require a distributed and/or centralized path > computation models, whether additional hierarchy is necessary and = how it > is applied. > > Manageability will be considered with each approach, along with va= rious > trade-offs for maintaining low power operation, including the pres= ence of > non-trivial loss and networks with a very large number of nodes. > > - Produce a routing security framework for routing in LLNs. > > - Protocol work: The Working Group will consider specific routing > requirements from the four application documents collectively, and > specify either a new protocol or extend an existing routing protoc= ol > in cooperation with the relevant Working Group. > If requirements from the four target application areas cannot be m= et > with a single protocol, the WG may choose to specify or extend mor= e than > one protocol (this will require a recharter of the WG). > > - Documentation of applicability statement of ROLL routing protocols= . > > - A document detailing when to use RFC6553, RFC6554 and IPIP > encapsulation. > > - A document detailing how to compress RFC6553, RFC6554 and IP heade= rs > in the 6lowPAN HC context. > > > > $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $ > > > > -- > Michael Richardson = >, Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ 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 P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_E045AECD98228444A58C61C200AE1BD849D98EB8xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Randy

 <= /p>

Sure, Randy, but stale ro= utes will send packets to black holes till they elapse, cutting some commun= ication. This is not a big issue is most WSNs so we have not addressed it in the main spec.

One case I have in mind i= s multiple DODAGs. The root learns from some routing protocol over the back= bone that a node moved to another DODAG.

But the root and all node= s down the path where that node used to be still have an DAO entry, for pot= entially a long time.

The root can discard its = own state but it cannot cleanup down the dodag, leading to a local blackhol= ing for packets issued in that affected zone.

 <= /p>

Cheers,=

 <= /p>

Pascal<= /p>

 <= /p>

From: Roll [ma= ilto:roll-bounces@ietf.org] On Behalf Of Turner, Randy
Sent: jeudi 2 avril 2015 18:17
To: Routing Over Low power and Lossy networks
Cc: Michael Richardson
Subject: Re: [Roll] proposed amendments to ROLL charter

 

Hi Pascal

 

Routing table entries usually have lifetimes. Wouldn= 't that clean up dead routes at the root?

 

Randy


On Apr 2, 2015, at 12:00 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

A few other things I̵= 7;d like to see, Ines:

 <= /p>

- One is a MOP based on B= IER and/or Bloom filters, which is a way to compress BIER with a chance of = false positive. Carsten has a draft that details the use of Bloom filters for source routing, but really both BIER and Bloom can ap= ply to either storing and non-storing.

- Work on mixed storing a= nd non-storing, and all sort of optimization for the storing mode. I’= m aware of feasible solutions in that space that really should be shared and made available to all.

- Work on additional capa= bilities that we did not initially include in the spec:

- The capability to kill a route from the root, e.g. if a DAO state is = installed and should be cleaned up, e.g. if the root realizes that the node is no more there or there is a duplication or what-else.

- The capability to trigger a DAO from the root if a target is expected= to be present in the network but there is no DAO state (maybe to save resources)

- The capability to request the triggering of a new iteration of a DODA= G from a RPL node or a controlling element.

 <= /p>

Thanks for asking J

 =

Pascal=

 <= /p>

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Ines Robles
Sent: mardi 31 mars 2015 16:10
To: Routing Over Low power and Lossy networks
Cc: Michael Richardson
Subject: Re: [Roll] proposed amendments to ROLL charter<= /o:p>

 

Hi Pascal,

 

Thank you very much for your comments, we are going = to include them in our meeting. 

 

To all, There are additional topics that you would l= ike to include in the charter? Please justify.

 

Thank you very much,

 

Michael and Ines

 

2015-03-31 13:49 GMT+03:00 Pascal Thubert (pthub= ert) <pthubert@c= isco.com>:

Hello Michael (and all):

I fully support the additions. Since you are at it, I would like to explore= a deeper realignment.

ROLL is now in charge of the maintenance of RPL, isn't it?
- I think that this should be a work item in the charter.
- this should replace elements that were or are being delivered such as met= rics, security, and RPL itself

And if that's so, wouldn't it make sense to study how RPL works outside LLN= s and in mixed environments?
- I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. Appl= icability of RPL in various environments outside LLN would be of interest, = e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that a DT will= form at HOMENET to select a routing protocol, and an applicability statement of RPL for that case would be a g= ood read if we can produce it in time.
- From our experience of actually doing RPL over Ethernet, it is mostly a m= atter of *not* using the packet artifacts, probably not using the stretch i= n local repair, and reacting immediately to changes in link state. This is = a very small spec indeed, mostly guidance on what to use and what not to use from RFC 6550, how to tune som= e parameters, which OF to use and how.
- The work should also detail the mode where there is a backbone and a virt= ual root. I think that the current charter does not cover work outside LLN = but considering that we are the group that knows RPL best, that work should= happen here.

What do you think?

Pascal


> -----Original Message-----
> From: Roll [mailto:roll-bounc= es@ietf.org] On Behalf Of Michael Richardson
> Sent: lundi 23 mars 2015 19:41
> To: roll@ietf.org
> Subject: [Roll] proposed amendments to ROLL charter
>
>
> The following changes are proposed for the ROLL charter to include the= work to
> profile 6553/6554/IPIP, and to compress it.
>
> To the pre-amble:
>
> After:
>  - In most cases, LLNs will be employed over link layers with res= tricted
>    frame-sizes, thus a routing protocol for LLNs should be s= pecifically
>    adapted for such link layers.
>
> Add:
> +- LLN routing protocols have to be very careful when trading off<= br> > +efficiency
> +  for generality; many LLN nodes do not have resources to wa= ste.
>
> After:
>  The solution must include unicast and multicast considerations.<= br> >
> Add:
> +The Working Group will document how non-control packets are route= d when
> +they cross the LLN, and when they enter and exit the LLN: the
> +appropriate use of
> +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how=
> +routing loops are detected. In consultation with the 6lo WG, the<= br> > +Working Group will design a method to these routing headers into = a
> +single block.  The result will have a shared WGLC with 6lo.<= o:p>

>
> To  Work Items, add:
> +     - A document detailing when to use RFC6553, R= FC6554 and IPIP
> +       encapsulation.
> +
> +     - A document detailing how to compress RFC655= 3, RFC6554 and IP headers
> +       in the 6lowPAN HC context.
>
>
> The resulting charter (after reformatting of some of the ugly text wra= pping on
> the web site) is:
>
> ----
> Low power and Lossy networks (LLNs) are made up of many embedded devic= es
> with limited power, memory, and processing resources. They are interco= nnected
> by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiF= i, wired or
> other low power PLC (Powerline Communication) links. LLNs are transiti= oning to
> an end-to-end IP-based solution to avoid the problem of non-interopera= ble
> networks interconnected by protocol translation gateways and proxies.<= br> >
> Generally speaking, LLNs have at least five distinguishing
> characteristics:
> - LLNs operate with a hard, very small bound on state.
> - In most cases, LLN optimize for saving energy.
> - Typical traffic patterns are not simply unicast flows (e.g. in some = cases most if
> not all traffic can be point to multipoint).
> - In most cases, LLNs will be employed over link layers with restricte= d
>   frame-sizes, thus a routing protocol for LLNs should be sp= ecifically
>   adapted for such link layers.
> - LLN routing protocols have to be very careful when trading off effic= iency
>   for generality; many LLN nodes do not have resources to wa= ste.
>
> These specific properties cause LLNs to have specific routing requirem= ents.
>
> Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have be= en
> evaluated by the working group and have in their current form been fou= nd to
> not satisfy all of these specific routing requirements.
>
> The Working Group is focused on routing issues for LLN.
>
> There is a wide scope of application areas for LLNs, including industr= ial
> monitoring, building automation (HVAC, lighting, access control, fire)= ,
> connected homes, healthcare, environmental monitoring, urban sensor > networks (e.g. Smart Grid), asset tracking. The Working Group focuses = on
> routing solutions for a subset of these: industrial, connected home, b= uilding and
> urban sensor networks for which routing requirements have been specifi= ed.
> These application-specific routing requirement documents will be used = for
> protocol design.
>
> The Working Group focuses only on IPv6 routing architectural framework= for
> these application scenarios. The Framework will take into consideratio= n various
> aspects including high reliability in the presence of time varying los= s
> characteristics and connectivity while permitting low-power operation = with very
> modest memory and CPU pressure in networks potentially comprising a ve= ry
> large number (several thousands) of nodes.
>
> The Working Group will pay particular attention to routing security an= d
> manageability (e.g., self routing configuration) issues. It will also = need to
> consider the transport characteristic the routing protocol messages wi= ll
> experience. Mechanisms that protect an LLN from congestion collapse or= that
> establish some degree of fairness between concurrent communication ses= sions
> are out of scope of the Working Group. It is expected that upper-layer=
> applications utilizing LLNs define appropriate mechanisms.
>
> The solution must include unicast and multicast considerations.
>
> The Working Group will document how non-control packets are routed whe= n
> they cross the LLN, and when they enter and exit the LLN: the appropri= ate use of
> RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how rout= ing
> loops are detected. In consultation with the 6lo WG, the Working Group= will
> design a method to these routing headers into a single block.  Th= e result will
> have a shared WGLC with 6lo.
>
> Work Items:
>
>      - Specification of routing metrics used in path ca= lculation. This
>        includes static and dynamic link/node attri= butes required for routing in
>        LLNs.
>
>      - Provide an architectural framework for routing a= nd path selection at
>        Layer 3 (Routing for LLN Architecture) that= addresses such issues as
>        whether LLN routing require a distributed a= nd/or centralized path
>        computation models, whether additional hier= archy is necessary and how it
>        is applied.
>
>        Manageability will be considered with each = approach, along with various
>        trade-offs for maintaining low power operat= ion, including the presence of
>        non-trivial loss and networks with a very l= arge number of nodes.
>
>      - Produce a routing security framework for routing= in LLNs.
>
>      - Protocol work: The Working Group will consider s= pecific routing
>        requirements from the four application docu= ments collectively, and
>        specify either a new protocol or extend an = existing routing protocol
>        in cooperation with the relevant Working Gr= oup.
>        If requirements from the four target applic= ation areas cannot be met
>        with a single protocol, the WG may choose t= o specify or extend more than
>        one protocol (this will require a recharter= of the WG).
>
>      - Documentation of applicability statement of ROLL= routing protocols.
>
>      - A document detailing when to use RFC6553, RFC655= 4 and IPIP
>        encapsulation.
>
>      - A document detailing how to compress RFC6553, RF= C6554 and IP headers
>        in the 6lowPAN HC context.
>
>
>
> $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $
>
>
>
> --
> Michael Richardson <mcr&= #43;IETF@sandelman.ca>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

 

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

 

P PLEASE CO= NSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) = is confidential and may be legally privileged. If you are not an intended r= ecipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the info= rmation in this e-mail or its attachments. If you have received this e-mail= in error, please notify the sender immediately by return e-mail and delete= all copies of this message and any attachments. Thank you.

--_000_E045AECD98228444A58C61C200AE1BD849D98EB8xmbrcdx01ciscoc_-- From nobody Thu Apr 2 11:40: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 098871A0263 for ; Thu, 2 Apr 2015 11:40:45 -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 VPUNBB8S2gLz for ; Thu, 2 Apr 2015 11:40:43 -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 510441A0191 for ; Thu, 2 Apr 2015 11:40:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 17953E1BC for ; Thu, 2 Apr 2015 14:51:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id AAF8A63B76; Thu, 2 Apr 2015 14:40:41 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 97EE763731 for ; Thu, 2 Apr 2015 14:40:41 -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] Looking for Linux implementation of RPL for interop testing 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 Apr 2015 18:40:45 -0000 --=-=-= Content-Type: text/plain Ralph Droms (rdroms) wrote: > Can anyone point me at an implementation of RPL for Linux that provides > non-storing mode operation? I'm looking for both an LBR/DODAG root > implementation and an LR implementation. THe purpose is > interoperability testing with an independent implementation. No, I can't point you at this, but I thought I'd answer about why we aren't seeing this yet. A non-storing mode implementation would require kernel implementation of the RH3 header in order to make work (particularly as DODAG root), and at this point, I'm unaware of anyone who has done that work, and it certainly isn't in the mainstream kernel. Perhaps someone out there is already working on it, and has patches. -- 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) iQEVAwUBVR2NKYCLcPvd0N1lAQLEUAf/blZ9yG6DFGiTkrsvX718HqtzK84hWLcu p5hssoIKqxtUyLpBv7S1/XAg5oE7sjjWW/DVUYfBtzUft21R5As7ii9OV9X9KUpW ebJf60KX+r8sjancYwTjOFkRoDiHvOusWKhgsfGWOcGqD3scxJ4iai1sbt8VO1zf CoIJhRmpOo1MnwPnQD4BAQgXQXwkK9GcNTSWG/QOxwMlpsYYTTkAr9LUpJ45LYqJ RNOjhyDZaF/Idp4cr/Td8hKCkA5bl4L+Pg4vBjNIjg3cbltJYTIotjhVRfpKJY2Y 3X2Fln74K+R5YbVqxLq3N+YZ/HMS5o+n7BIaHwT17g2gzwnPIsTjlA== =XmtW -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 2 12:25: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 1600F1A1A98 for ; Thu, 2 Apr 2015 12:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 cZxIe72rOxs4 for ; Thu, 2 Apr 2015 12:25:17 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1740C1A883A for ; Thu, 2 Apr 2015 12:25:17 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0430.eurprd01.prod.exchangelabs.com (10.242.221.21) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 2 Apr 2015 18:45:29 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.01.0118.022; Thu, 2 Apr 2015 18:45:29 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Looking for Linux implementation of RPL for interop testing Thread-Index: AQHQbXSK0aDT6+3bFk++S75im6y+BJ06D3fP Date: Thu, 2 Apr 2015 18:45:28 +0000 Message-ID: References: , <21995.1428000041@sandelman.ca> In-Reply-To: <21995.1428000041@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.193.172.255] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0430; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(24454002)(77096005)(2900100001)(82746002)(2656002)(450100001)(62966003)(46102003)(19580405001)(77156002)(19580395003)(33656002)(92566002)(87936001)(107886001)(110136001)(102836002)(66066001)(54356999)(2950100001)(106116001)(76176999)(36756003)(86362001)(5890100001)(15975445007)(122556002)(83716003)(50986999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0430; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DB4PR01MB0430; BCL:0; PCL:0; RULEID:; SRVR:DB4PR01MB0430; x-forefront-prvs: 0534947130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 18:45:28.7016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR01MB0430 Archived-At: Subject: Re: [Roll] Looking for Linux implementation of RPL for interop testing 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 Apr 2015 19:25:21 -0000 I agree with Michael, we are looking into Linux mods for RPL as well, espec= ially how to get RPL options outbound with every packet bound to a low pan = interface - Randy > On Apr 2, 2015, at 2:40 PM, Michael Richardson wr= ote: > > Ralph Droms (rdroms) wrote: >> Can anyone point me at an implementation of RPL for Linux that provides >> non-storing mode operation? I'm looking for both an LBR/DODAG root >> implementation and an LR implementation. THe purpose is >> interoperability testing with an independent implementation. > > No, I can't point you at this, but I thought I'd answer about why we aren= 't > seeing this yet. > > A non-storing mode implementation would require kernel implementation of = the > RH3 header in order to make work (particularly as DODAG root), and at thi= s > point, I'm unaware of anyone who has done that work, and it certainly isn= 't > in the mainstream kernel. > > Perhaps someone out there is already working on it, and has patches. > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. From alex.aring@gmail.com Thu Apr 2 13:34: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 A87221A1A6E for ; Thu, 2 Apr 2015 13:34:31 -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, FREEMAIL_FROM=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 8B7ThKxjN5c5 for ; Thu, 2 Apr 2015 13:34:26 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 6B5F61A1A6A for ; Thu, 2 Apr 2015 13:34:26 -0700 (PDT) Received: by wiaa2 with SMTP id a2so118795802wia.0 for ; Thu, 02 Apr 2015 13:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SvrV2Z57OfYqrpi1iGX5RjcVon9L6EUhxUimknNwFB4=; b=nlxE8ZhyYLqRLqFUdcdN7zraIwcwABi/jXsfimq5BlkPe7sENtgRXzgHikHbyGF/M9 aqwOnb3SwPPDCU9XhDF8N1ZAVVPVo4a9NeAl1EZTWp7q+KMMWtlS4dFdK7SQQ910mo7A JXZD/BH+bh5Q8vFk6GK3y2Z+X3KIXWbafpo80MdK6xl4ICxcGxG258zexPdatQZDbmhl yV9fPdhgPett7z1VBAGI5djdRF1LI3V6+kwj5sYQ+d0BbuNPK8ER2I6ophdWZ9rACMQk 2jXDvn9STSUhWUj56U+ihRX6wWm3HGVJaC/FzCemTXOqyekyghwyYRZ3kMTQrOrwLeHH ln1Q== X-Received: by 10.194.94.164 with SMTP id dd4mr99317076wjb.56.1428006865238; Thu, 02 Apr 2015 13:34:25 -0700 (PDT) Received: from omega (p20030064A926F21CE2CB4EFFFE1BB546.dip0.t-ipconnect.de. [2003:64:a926:f21c:e2cb:4eff:fe1b:b546]) by mx.google.com with ESMTPSA id ew5sm31499292wic.14.2015.04.02.13.34.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 13:34:24 -0700 (PDT) Date: Thu, 2 Apr 2015 22:34:19 +0200 From: Alexander Aring To: Routing Over Low power and Lossy networks Message-ID: <20150402203416.GA18697@omega> References: <21995.1428000041@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <21995.1428000041@sandelman.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Roll] Looking for Linux implementation of RPL for interop testing 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 Apr 2015 20:39:34 -0000 Hi Ralph and Michael, On Thu, Apr 02, 2015 at 02:40:41PM -0400, Michael Richardson wrote: > Ralph Droms (rdroms) wrote: > > Can anyone point me at an implementation of RPL for Linux that provides > > non-storing mode operation? I'm looking for both an LBR/DODAG root > > implementation and an LR implementation. THe purpose is > > interoperability testing with an independent implementation. > > No, I can't point you at this, but I thought I'd answer about why we aren't > seeing this yet. > > A non-storing mode implementation would require kernel implementation of the > RH3 header in order to make work (particularly as DODAG root), and at this > point, I'm unaware of anyone who has done that work, and it certainly isn't > in the mainstream kernel. > > Perhaps someone out there is already working on it, and has patches. I know three 3 RPL implementation for linux, all of them has limitations: One kernelspace and two userspace implementations, I can't say much about these limitations because I doesn't looked deeper into these implementations and I have no idea about RPL stuff (currently). :-) The kernelspace one: - Known as linux-rpl [0]. In my opinion there is still much stuff to do there for bringing this stuff mainline. There is a blog article [1] about somebody who tested it with contiki nodes and it "seems" basically to work with limitations. The userspace implementations: - SimpleRPL [2]. Prototype implementation in python. - unstrung [3]. I think the most people on this mailinglist knows about this implementation. For using these implementation with current mainline: NOTE: We changed in linux the ARPHRD (the uapi type for a netdev) from ARPHRD_IEEE802154 to ARPHRD_6LOWPAN for the 802.15.4 6LoWPAN interface. The reason was before the 802.15.4 and 802.15.4 6LoWPAN interface used the same ARPHRD type, this situation occurs several troubles. Now BTLE 6LoWPAN and 802.15.4 6LoWPAN uses the same ARPHRD type which is ARPHRD_6LOWPAN. On ARPHRD_6LOWPAN you will have a IPv6 view without L2 information, the ARPHRD_IEEE802154 wpan interface has 802.15.4 frames view. I mostly saw that userspace applications evaluates the ARPHRD value for checking on an EUI64 mac address length, which is the same for BTLE 6LoWPAN and 802.15.4 6LoWPAN. I notice this because some applications still evaluates the old ARPHRD value (I noticed this about another mail on mailinglist at [4]). So you will have trouble to run current implementations with current mainline if you don't this behaviour. - Alex [0] https://github.com/joaopedrotaveira/linux-rpl [1] http://sixpinetrees.blogspot.de/2014/11/linux-rpl-router.html [2] https://github.com/tcheneau/simpleRPL [3] http://unstrung.sandelman.ca/ [4] http://lists.sandelman.ca/pipermail/unstrung-hackers/2015-March/000014.html From nobody Thu Apr 2 14:50:56 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 4A2C61A7023 for ; Thu, 2 Apr 2015 14:50:55 -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, FREEMAIL_FROM=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 l8qWk3PIlBqz for ; Thu, 2 Apr 2015 14:50:50 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9DE1A702B for ; Thu, 2 Apr 2015 14:50:50 -0700 (PDT) Received: by qcay5 with SMTP id y5so77800086qca.1 for ; Thu, 02 Apr 2015 14:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=MgTijG50vI8S/lQHEJ0TfkaEVIYILSUS1UvNnQj87jM=; b=SmcatvQy7rN5frcjJtW5/1IhQYfAs6l4uzCfjqsSPylupy+d5QIgf8uM0awghm4D/S 1QeHdWG5ySA4RiQmIP21ddqyHjiUKCkJgaIWdRgkZT8K5D5YmPbMzEUa3VRltwyp8ySz Yw4V58znCH/kgwzST5Y/HS7PBNBrbFfFvEeIZXipgSIFK6QLfhBZaqwriFA+1+dV5VUH vcKkmUP7rJb7679UBv08PLBUaZqfCoXAhPmX8Rsa/pvjU32HMBc+OCLixe9qfOMVfICu eHgoRcHnnOxWa4w2IDVcrPrGnQmGTE7AAkmtyZ9iVjJutsmChJF3mHal90HL/Cv9iFtU 4RAA== X-Received: by 10.55.56.77 with SMTP id f74mr41516704qka.33.1428011449448; Thu, 02 Apr 2015 14:50:49 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1004::174? ([2001:420:c0c4:1004::174]) by mx.google.com with ESMTPSA id 91sm4356232qkw.13.2015.04.02.14.50.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 14:50:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms In-Reply-To: <20150402203416.GA18697@omega> Date: Thu, 2 Apr 2015 17:50:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <557AE653-44F3-49E9-887E-7C55CE8295B9@gmail.com> References: <21995.1428000041@sandelman.ca> <20150402203416.GA18697@omega> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [Roll] Looking for Linux implementation of RPL for interop testing 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 Apr 2015 21:50:55 -0000 Thanks, Alex - your response is *very* helpful... Anyone have a suggestion about other ways to do interop testing, = especially with a non-storing mode LBR/DODAG root? - Ralph > On Apr 2, 2015, at 4:34 PM 4/2/15, Alexander Aring = wrote: >=20 > Hi Ralph and Michael, >=20 > On Thu, Apr 02, 2015 at 02:40:41PM -0400, Michael Richardson wrote: >> Ralph Droms (rdroms) wrote: >>> Can anyone point me at an implementation of RPL for Linux that = provides >>> non-storing mode operation? I'm looking for both an LBR/DODAG root >>> implementation and an LR implementation. THe purpose is >>> interoperability testing with an independent implementation. >>=20 >> No, I can't point you at this, but I thought I'd answer about why we = aren't >> seeing this yet. >>=20 >> A non-storing mode implementation would require kernel implementation = of the >> RH3 header in order to make work (particularly as DODAG root), and at = this >> point, I'm unaware of anyone who has done that work, and it certainly = isn't >> in the mainstream kernel. >>=20 >> Perhaps someone out there is already working on it, and has patches. >=20 > I know three 3 RPL implementation for linux, all of them has = limitations: >=20 > One kernelspace and two userspace implementations, I can't say much > about these limitations because I doesn't looked deeper into these > implementations and I have no idea about RPL stuff (currently). :-) >=20 > The kernelspace one: >=20 > - Known as linux-rpl [0]. > In my opinion there is still much stuff to do there for bringing = this > stuff mainline. There is a blog article [1] about somebody who = tested it > with contiki nodes and it "seems" basically to work with = limitations. >=20 > The userspace implementations: >=20 > - SimpleRPL [2]. > Prototype implementation in python. >=20 > - unstrung [3]. > I think the most people on this mailinglist knows about this > implementation. >=20 >=20 >=20 > For using these implementation with current mainline: >=20 > NOTE: We changed in linux the ARPHRD (the uapi type for a netdev) from > ARPHRD_IEEE802154 to ARPHRD_6LOWPAN for the 802.15.4 6LoWPAN = interface. >=20 > The reason was before the 802.15.4 and 802.15.4 6LoWPAN interface used > the same ARPHRD type, this situation occurs several troubles. Now BTLE > 6LoWPAN and 802.15.4 6LoWPAN uses the same ARPHRD type which is > ARPHRD_6LOWPAN. On ARPHRD_6LOWPAN you will have a IPv6 view without L2 > information, the ARPHRD_IEEE802154 wpan interface has 802.15.4 frames = view. >=20 >=20 > I mostly saw that userspace applications evaluates the ARPHRD value = for > checking on an EUI64 mac address length, which is the same for BTLE > 6LoWPAN and 802.15.4 6LoWPAN. >=20 > I notice this because some applications still evaluates the old ARPHRD > value (I noticed this about another mail on mailinglist at [4]). So = you > will have trouble to run current implementations with current mainline > if you don't this behaviour. >=20 > - Alex >=20 > [0] https://github.com/joaopedrotaveira/linux-rpl > [1] http://sixpinetrees.blogspot.de/2014/11/linux-rpl-router.html > [2] https://github.com/tcheneau/simpleRPL > [3] http://unstrung.sandelman.ca/ > [4] = http://lists.sandelman.ca/pipermail/unstrung-hackers/2015-March/000014.htm= l >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Apr 2 16:41: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 9EB381A885C; Thu, 2 Apr 2015 16:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] 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 6OcZdPCGPujD; Thu, 2 Apr 2015 16:41:47 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87ECF1A8855; Thu, 2 Apr 2015 16:41:47 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t32Nff9X020767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 01:41:41 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id t32Nfff0002820; Fri, 3 Apr 2015 01:41:41 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 127492A0C5D; Fri, 3 Apr 2015 01:41:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id x2lbq997fUqd; Fri, 3 Apr 2015 01:41:39 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C10982A0C00; Fri, 3 Apr 2015 01:41:38 +0200 (CEST) Date: Fri, 03 Apr 2015 01:41:53 +0200 Message-ID: <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Pascal Thubert (pthubert)" In-Reply-To: References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 03 Apr 2015 01:41:41 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 03 Apr 2015 01:41:41 +0200 (CEST) X-Miltered: at korolev with ID 551DD3B5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 551DD3B5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551DD3B5.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 551DD3B5.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 551DD3B5.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 551DD3B5.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: ROLL WG , "manet@ietf.org" Subject: Re: [Roll] [manet] Understanding RPL [was: Working group re-charter ideas] 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 Apr 2015 23:41:55 -0000 Thanks a lot for the lengthy explanation, Pascal, I feel that I understand RPL somewhat better now. >> My perhaps mistaken understanding is that RPL uses a more primitive >> version of DSDV's feasibility condition > That's all this discussion around that value L Ah, I see. Section 8.2.2.4.3. (I'm not apologising for missing it -- it is well hidden.) Yes, that looks like DUAL-feasibility, but weakened so that loops of diameter DAGMaxRankIncrease or less are allowed, right? Why the weakening? Is that to compensate for the fact that you don't have a mechanism to resolve blackholes in a timely manner? > A node is allowed to join any DODAG Version that it has never been a > prior member of without any restrictions, but if the node has been a > prior member of the DODAG Version, then it must continue to observe > the rule that it may not advertise a Rank higher than > L+DAGMaxRankIncrease at any point in the life of the DODAG Version. Yeah, that's pretty clear. The same is true of Babel. > One interesting difference with Babel is that RPL can route to all nodes > with a single DODAG to a single root, using MOP 2. Yes, I've noticed this mechanism before. I think that's a smart mechanism (I much prefer it to MOP 1), and I trust you've evaluated its performance carefully, at least for some OF. However, that's definitely not something I'd ever consider adding to Babel -- I have a very strong desire to keep the base protocol small, and to make sure that all extended variants can interoperate as long as they implement the base protocol correctly. You see -- once again, we're aiming at two different application spaces. You're thinking of sensor networks, where it is reasonable to require that all nodes in a given network implement MOP 2. Babel is aimed at home and hybrid networks (cash-starved networks with some meshy bits), which tend to grow organically, with routers that never get reflashed, and therefore contain different variants of the protocol. > Another interesting difference is that if we have 2 roots, RPL > partitions the network in 2 DODAGs. Sorry if I'm being slow, but I don't see how that can be true. If you have R1 R2 /\ / \ A B and there is instability in the network, so that simultaneously A switches to B as parent, and B switches to R2 while its retraction ("poison") gets lost, what prevents A from having B as parent while believing it's still in R1's DODAG? > Local repair is done by either poisoning or detaching, sections > 8.2.2.5. I don't see how that can be implemented. Suppose A is B's parent. A advertises INFINITE_RANK. A's retraction ("poison") is lost. B has no reason to change parents, so B has a parent with infinite rank. Oops, B is just violating the MUST NOT in 8.2.2.5.2. Are you assuming the network is reliable? Or am I missing some mechanism that prevents that from happening? > Or 8.2.2.6. That's just a variant of the above but advertising DIO instead of a retraction, right? > On the side, poisoning is really inheriting from IGRP, It's been a long time since I looked at IGRP, but I seem to recall that it avoids the issue I describe above by imposing a silent time after a metric increase. This causes temporary blackholes, of course, of up to 3 minutes if memory serves. > We voluntarily left out the trigger for a new iteration, because that > can be largely outside the scope of the routing protocol, I disagree with that, at least in the space for which Babel is aiming. > All in all I do not buy the different spaces. RPL was explicitly > designed for multiple spaces because, by design, we left out of RPL and > into the OF everything that's specific. Well, the space Babel aims for requires that implementations from different vendors interoperate. That requires putting a provably complete set of "must implement" mechanisms in the base spec. I don't believe that RPL has that property. > Do I get an invite? Sure, I'll try to remember to send you a note when I next give a seminar. -- Juliusz From nobody Thu Apr 2 23:15: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 A41D31A90EA; Thu, 2 Apr 2015 23:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 y8tNgyey4n-K; Thu, 2 Apr 2015 23:15:00 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EABD1A90E6; Thu, 2 Apr 2015 23:15:00 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so129778057wib.1; Thu, 02 Apr 2015 23:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=D33FOWdMqLNR5MnDvAqflPy3nbeS3WTG5xZ/g/vC94g=; b=ZLwUVljpz0xyqOBgymDlKwFpG0I/pcBe+ixTSpbp4zBBr9sNJZNwwZyZam0FrF6LI3 CaXPS40kpphMBuAUq9kC0XWifEVZk568Xk4eyRjZUcSwCikJnunYqelHG96Hm3Hz6orn CjltpkDBGz3dpxU6VZxF7wxK9+mGFAWZTMra5eWBe4z8xx08vo5b+pkV2VY1kja6Z9V9 2B+Bx4KPmnUDbVgSoj4iJK3+kbKnLMqo8drtNgNj3iV4sEkZDlAA7sZhI6DDOkKGm1lh L6ykLFVqtqUy2boVeS1ht8lYxDF+PSMs755t3SSpl6kQqVFca0sbrOY7LTk2qYgD2oOj kNzA== X-Received: by 10.194.123.67 with SMTP id ly3mr1729498wjb.105.1428041699243; Thu, 02 Apr 2015 23:14:59 -0700 (PDT) Received: from [192.168.1.58] ([95.91.215.14]) by mx.google.com with ESMTPSA id ga8sm1363330wib.11.2015.04.02.23.14.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 23:14:58 -0700 (PDT) Message-ID: <551E2FE1.4000509@gmail.com> Date: Fri, 03 Apr 2015 08:14:57 +0200 From: =?windows-1252?Q?Cenk_G=FCndogan?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Juliusz Chroboczek References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr> Content-Type: multipart/alternative; boundary="------------090302050807060109070603" Archived-At: Cc: Routing Over Low power and Lossy networks , "manet@ietf.org" Subject: Re: [Roll] [manet] Understanding RPL [was: Working group re-charter ideas] 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 Apr 2015 06:15:08 -0000 This is a multi-part message in MIME format. --------------090302050807060109070603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello Juliusz, On 03.04.2015 01:41, Juliusz Chroboczek wrote: >> Local repair is done by either poisoning or detaching, sections >> 8.2.2.5. > I don't see how that can be implemented. > > Suppose A is B's parent. A advertises INFINITE_RANK. A's retraction > ("poison") is lost. B has no reason to change parents, so B has a parent > with infinite rank. Oops, B is just violating the MUST NOT in 8.2.2.5.2. > > Are you assuming the network is reliable? Or am I missing some mechanism > that prevents that from happening? I also did struggle with this scenario for quite some time. However, there are several places in the RFC that specifically deal (directly or indirectly) with this issue. 8.2.2.5 . Poisoning 1. A node poisons routes by advertising a Rank of INFINITE_RANK. 2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in its parent set. My interpretation of these bullet points is that DIOs advertising INFINITE_RANK are sent out periodically (probably in a decaying fashion via Trickle), in order to reduce the chance that these DIOs stay unnoticed. However, this might not be a complete solution, as all DIOs from A to B can become lost thus leading to the same problem, but then the RFC states that links should be guaranteed to be symmetric anyways, e.g. by using NUD [1] or other alternatives. Something else I want to mention is that RPL utilizes a few lifetime counters (e.g. for the dodag or route), which would also help in this scenario (We wouldn't refresh the lifetime of a node with INFINITE_RANK, would we?), but admittedly, depending on the specified lifetime values, in a very sluggish way. At last, it is important to remember that RPL uses data-path validation to reduce the chattiness of control packets, described in [2] and most likely realized by using [3]. In that case A can reset its Trickle timer when encountering inconsistencies and start e.g. another poisoning routine by sending out another set of INFINITE_RANK DIOs. Best, Cenk [1] Neighbor Unreachability Detection (https://tools.ietf.org/html/rfc2461#page-66) [2] https://tools.ietf.org/html/rfc6550#section-3.2.7 [3] https://tools.ietf.org/html/rfc6553 --------------090302050807060109070603 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Hello Juliusz,

On 03.04.2015 01:41, Juliusz Chroboczek wrote:
Local repair is done by either poisoning or detaching, sections
8.2.2.5.

I don't see how that can be implemented.

Suppose A is B's parent.  A advertises INFINITE_RANK.  A's retraction
("poison") is lost.  B has no reason to change parents, so B has a parent
with infinite rank.  Oops, B is just violating the MUST NOT in 8.2.2.5.2.

Are you assuming the network is reliable?  Or am I missing some mechanism
that prevents that from happening?

I also did struggle with this scenario for quite some time.
However, there are several places in the RFC that specifically deal (directly or indirectly) with this issue.

8.2.2.5.  Poisoning


   1.  A node poisons routes by advertising a Rank of INFINITE_RANK.

   2.  A node MUST NOT have any nodes with a Rank of INFINITE_RANK in
       its parent set.

My interpretation of these bullet points is that DIOs advertising INFINITE_RANK are sent out periodically
(probably in a decaying fashion via Trickle), in order to reduce the chance that these DIOs stay unnoticed.
However, this might not be a complete solution, as all DIOs from A to B can become lost thus leading to the same problem,
but then the RFC states that links should be guaranteed to be symmetric anyways, e.g. by using NUD [1] or other alternatives.

Something else I want to mention is that RPL utilizes a few lifetime counters (e.g. for the dodag or route),
which would also help in this scenario (We wouldn't refresh the lifetime of a node with INFINITE_RANK, would we?),
but admittedly, depending on the specified lifetime values, in a very sluggish way.

At last, it is important to remember that RPL uses data-path validation to reduce the chattiness of control packets,
described in [2] and most likely realized by using [3].
In that case A can reset its Trickle timer when encountering inconsistencies and start e.g. another poisoning routine
by sending out another set of INFINITE_RANK DIOs.

Best,
Cenk

[1] Neighbor Unreachability Detection (https://tools.ietf.org/html/rfc2461#page-66)
[2] https://tools.ietf.org/html/rfc6550#section-3.2.7
[3] https://tools.ietf.org/html/rfc6553
--------------090302050807060109070603-- From nobody Fri Apr 3 01:51:14 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 1AF661A1A97; Fri, 3 Apr 2015 01:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.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, MIME_8BIT_HEADER=0.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 uzZiZCJI0zEq; Fri, 3 Apr 2015 01:51:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083B51A1AB8; Fri, 3 Apr 2015 01:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13668; q=dns/txt; s=iport; t=1428051067; x=1429260667; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wgzVv6AkODcB2nvkvxfhuUF7r7KJeKnPxWq7pTrMkV0=; b=hwMk3xW8u7DHzSj3fcTB4wOI2EZrNjxytlT9wgFu+SseI9barXCvJWlo W+QY7Kwaiu+IxqyUREdiBJkXjYBphgab/VAjpDZsVowE4fs3D1xnCN7Aa 2sU342URqHabHxTiJ1IEwXSxCOZTZNDvJNM5PVx5qdFvyrMEi3XXsW40c E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B3CADIUx5V/5tdJa1cgwtSXMMwgjYBCYV9AoErTAEBAQEBAX6EHwEBBAEBAWsLEAIBCD8HIQYLFBECBA4FG4gAAxENxwcNhTIBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIoqf4JHgi4EB4MXgRYFinGFeYN1gQdhP4IXgU2BHYYVhmqGLyKCAxyBUG8BAQGBASSBGwEBAQ X-IronPort-AV: E=Sophos;i="5.11,516,1422921600"; d="scan'208,217";a="408921930" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 03 Apr 2015 08:51:06 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t338p5Nq009789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Apr 2015 08:51:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 3 Apr 2015 03:51:04 -0500 From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?Cenk_G=FCndogan?= Thread-Topic: [manet] [Roll] Understanding RPL [was: Working group re-charter ideas] Thread-Index: AQHQbdWN0AgUGz00DUugxuEkjZWsNZ06+vex Date: Fri, 3 Apr 2015 08:51:04 +0000 Message-ID: <7F8D39C7-E757-43F2-BD04-AB2B602B133D@cisco.com> References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr>,<551E2FE1.4000509@gmail.com> In-Reply-To: <551E2FE1.4000509@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7F8D39C7E75743F2BD04AB2B602B133Dciscocom_" MIME-Version: 1.0 Archived-At: Cc: Routing Over Low power and Lossy networks , "manet@ietf.org" Subject: Re: [Roll] [manet] Understanding RPL [was: Working group re-charter ideas] 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 Apr 2015 08:51:11 -0000 --_000_7F8D39C7E75743F2BD04AB2B602B133Dciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You pretty much have it all, Cenk, I thank you for this great explanation. Let me observe a few things: One is that poisoning gives you only half of the value of detaching since d= etaching maintains connectivity within the detached DODAG, which is a usefu= l consideration in A MANET situation. This mode is an inheritance from MANE= MO where we were looking for the minimal topological awareness so as to ens= ure maximum resilience to swarming in a highly mobile situation. Second is that both RPL methods derive from the desire of getting a similar= service as the diffusion algorithm in DUAL/EIGRP, but in a MANET situatio= n where connectivity is uncertain and the real diffusion algorithm is doome= d to fail. We had to adapt to the real world and its statistical behavior, and had to = cover for the exception, which RPL does as you describe. So DUAL was replac= ed with a trickle-based diffusion, and the packets were instrumented beyond= hop count to detect and fix the anomalies. There was ample simulation work that showed the value for traffic continuit= y vs. plain black holing (till the next sequence is advertised). Same goes = for the stretch to the feasibility condition. Now if you disable those functionalities - arguably in a rather fast and st= able network - , and you make one mop0 DODAG per router in one instance, yo= u get something that is highly similar to BABEL - and that is no magic. And= in that, BABEL is less than EIGRP, but arguably, for that same reason, EIG= RP is not applicable to MANET. If you make that 2 instances, you can select the Homenet multi homed GW wit= hout the need for source/destination routing. If you add the option of P2P RPL you probably get a reactive DV in the clos= e family of AODV. RPL aggregated the quintessence of classical DV with the best knowledge of = people applying DV to mobility (MANEMO/ NINA), and of those applying it to = sensors (such as CTP and multiple proprietary solutions from WSN vendors). At the same time, RPL kept out anything specific to a particular type of us= e case - metrics, logic, policies. One really creates a solution by choosin= g his own objective function. It can be said that RFC 6550 is generic and t= hat the application of an OF creates an instance which is the real routing = protocol. The text is arguably hard to read. Part of that came from the aggregation process over 19 rounds of the draft.= I'm afraid that if we pass the BABEL RFC through the WG process, one will = hardly recognize it in the end, even if we manage to preserve the basic ope= rations. Another reason is that we had to strip all the why's and focus on specifyin= g observable behaviors. That is certainly not how one would write a book or= a paper. I'm afraid that what makes BABEL such a great read today will be = lost if the same process is applied. Cheers, Pascal Le 3 avr. 2015 =E0 08:15, Cenk G=FCndogan > a =E9crit : Hello Juliusz, On 03.04.2015 01:41, Juliusz Chroboczek wrote: Local repair is done by either poisoning or detaching, sections 8.2.2.5. I don't see how that can be implemented. Suppose A is B's parent. A advertises INFINITE_RANK. A's retraction ("poison") is lost. B has no reason to change parents, so B has a parent with infinite rank. Oops, B is just violating the MUST NOT in 8.2.2.5.2. Are you assuming the network is reliable? Or am I missing some mechanism that prevents that from happening? I also did struggle with this scenario for quite some time. However, there are several places in the RFC that specifically deal (direct= ly or indirectly) with this issue. 8.2.2.5. Poisoning 1. A node poisons routes by advertising a Rank of INFINITE_RANK. 2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in its parent set. My interpretation of these bullet points is that DIOs advertising INFINITE_= RANK are sent out periodically (probably in a decaying fashion via Trickle), in order to reduce the chance= that these DIOs stay unnoticed. However, this might not be a complete solution, as all DIOs from A to B can= become lost thus leading to the same problem, but then the RFC states that links should be guaranteed to be symmetric any= ways, e.g. by using NUD [1] or other alternatives. Something else I want to mention is that RPL utilizes a few lifetime counte= rs (e.g. for the dodag or route), which would also help in this scenario (We wouldn't refresh the lifetime of= a node with INFINITE_RANK, would we?), but admittedly, depending on the specified lifetime values, in a very slugg= ish way. At last, it is important to remember that RPL uses data-path validation to = reduce the chattiness of control packets, described in [2] and most likely realized by using [3]. In that case A can reset its Trickle timer when encountering inconsistencie= s and start e.g. another poisoning routine by sending out another set of INFINITE_RANK DIOs. Best, Cenk [1] Neighbor Unreachability Detection (https://tools.ietf.org/html/rfc2461#= page-66) [2] https://tools.ietf.org/html/rfc6550#section-3.2.7 [3] https://tools.ietf.org/html/rfc6553 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_7F8D39C7E75743F2BD04AB2B602B133Dciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You pretty much have it all, Cenk, I thank you for this great explanat= ion.

Let me observe a few things:

One is that poisoning gives you only half of the value of detaching si= nce detaching maintains connectivity within the detached DODAG, which is a = useful consideration in A MANET situation. This mode is an inheritance from= MANEMO where we were looking for the minimal topological awareness so as to ensure maximum resilience to sw= arming in a highly mobile situation.

Second is that both RPL methods derive from the desire of getting a si= milar service as the diffusion algorithm  in DUAL/EIGRP, but in a MANE= T situation where connectivity is uncertain and the real diffusion algorith= m is doomed to fail. 

We had to adapt to the real world and its statistical behavior, and ha= d to cover for the exception, which RPL does as you describe. So DUAL was r= eplaced with a trickle-based diffusion, and the packets were instrumented b= eyond hop count to detect and fix the anomalies. 

There was ample simulation work that showed the value for traffic cont= inuity vs. plain black holing (till the next sequence is advertised). Same = goes for the stretch to the feasibility condition.

Now if you disable those functionalities - arguably in a rather fast a= nd stable network - , and you make one mop0 DODAG per router in one instanc= e, you get something that is highly similar to BABEL - and that is no magic= . And in that, BABEL is less than EIGRP, but arguably, for that same reason, EIGRP is not applicable to MANE= T.

If you make that 2 instances, you can select the Homenet multi homed G= W without the need for source/destination routing.

If you add the option of P2P RPL you probably get a reactive DV in the clos= e family of AODV.

RPL aggregated the quintessence of classical DV with the best knowledg= e of people applying DV to mobility (MANEMO/ NINA), and of those applying i= t to sensors (such as CTP and multiple proprietary solutions from WSN vendo= rs).

At the same time, RPL kept out anything specific to a particular type = of use case - metrics, logic, policies. One really creates a solution by ch= oosing his own objective function. It can be said that RFC 6550 is generic = and that the application of an OF creates an instance which is the real routing protocol.

The text is arguably hard to read.

Part of that came from the aggregation process over 19 rounds of the d= raft. I'm afraid that if we pass the BABEL RFC through the WG process, one = will hardly recognize it in the end, even if we manage to preserve the basi= c operations. 

Another reason is that we had to strip all the why's and focus on spec= ifying observable behaviors. That is certainly not how one would write a bo= ok or a paper. I'm afraid that what makes BABEL such a great read today wil= l be lost if the same process is applied.

Cheers,

Pascal

Le 3 avr. 2015 =E0 08:15, Cenk G=FCndogan <cnkgndgn@gmail.com> a =E9crit :

Hello Juliusz,

On 03.04.2015 01:41, Juliusz Chroboczek wrot= e:
Local repair is done by either poisoning or detaching, secti=
ons
8.2.2.5.

I don't see how that can be implemented.

Suppose A is B's parent.  A advertises INFINITE_RANK.  A's retraction
("poison") is lost.  B has no reason to change parents, so B has =
a parent
with infinite rank.  Oops, B is just violating the MUST NOT in 8.2.2.5.2.

Are you assuming the network is reliable?  Or am I missing some mechanism
that prevents that from happening?

I also did struggle with this scenario for quite some time.
However, there are several places in the RFC that specifically deal (direct= ly or indirectly) with this issue.

8.2.2.5.  Poisoning

   1.  A node poisons routes by advertising a Rank of INFINITE_RANK.

   2.  A node MUST NOT have any nodes with a Rank of INFINITE_RANK in
       its parent set.

My interpretation of these bullet points is that DIOs advertising INFINITE_= RANK are sent out periodically
(probably in a decaying fashion via Trickle), in order to reduce the chance= that these DIOs stay unnoticed.
However, this might not be a complete solution, as all DIOs from A to B can= become lost thus leading to the same problem,
but then the RFC states that links should be guaranteed to be symmetric any= ways, e.g. by using NUD [1] or other alternatives.

Something else I want to mention is that RPL utilizes a few lifetime counte= rs (e.g. for the dodag or route),
which would also help in this scenario (We wouldn't refresh the lifetime of= a node with INFINITE_RANK, would we?),
but admittedly, depending on the specified lifetime values, in a very slugg= ish way.

At last, it is important to remember that RPL uses data-path validation to = reduce the chattiness of control packets,
described in [2] and most likely realized by using [3].
In that case A can reset its Trickle timer when encountering inconsistencie= s and start e.g. another poisoning routine
by sending out another set of INFINITE_RANK DIOs.

Best,
Cenk

[1] Neighbor Unreachability Detection (https://tools.ietf.org/= html/rfc2461#page-66)
[2] https://tools.ietf.org/html/rfc6550#section-3.2.7
[3] https://tools.ietf.org/html/rfc6553
_______________________________________________
manet mailing list
manet@ietf.org
https://www.i= etf.org/mailman/listinfo/manet
--_000_7F8D39C7E75743F2BD04AB2B602B133Dciscocom_-- From nobody Fri Apr 3 02:59: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 950A51A6F13; Fri, 3 Apr 2015 02:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 do8GuCX7hqvD; Fri, 3 Apr 2015 02:59:24 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66431A6F5D; Fri, 3 Apr 2015 02:59:23 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t339xL5f014106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 11:59:21 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id t339xLCR000350; Fri, 3 Apr 2015 11:59:21 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 802B92A0C60; Fri, 3 Apr 2015 11:59:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id L2zuLz0HTkDe; Fri, 3 Apr 2015 11:59:20 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E7B202A0C02; Fri, 3 Apr 2015 11:59:19 +0200 (CEST) Date: Fri, 03 Apr 2015 11:59:34 +0200 Message-ID: <87ego1zg55.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Cenk =?ISO-8859-1?Q?G=FCndogan?= In-Reply-To: <551E2FE1.4000509@gmail.com> References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr> <551E2FE1.4000509@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 03 Apr 2015 11:59:21 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 03 Apr 2015 11:59:21 +0200 (CEST) X-Miltered: at korolev with ID 551E6479.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 551E6479.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551E6479.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 551E6479.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 551E6479.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 551E6479.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Routing Over Low power and Lossy networks , "manet@ietf.org" Subject: Re: [Roll] [manet] Understanding RPL [was: Working group re-charter ideas] 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 Apr 2015 09:59:24 -0000 >>> Local repair is done by either poisoning or detaching, section 8.2.2.5. >> I don't see how that can be implemented. >> >> Suppose A is B's parent. A advertises INFINITE_RANK. A's retraction >> ("poison") is lost. B has no reason to change parents, so B has a parent >> with infinite rank. Oops, B is just violating the MUST NOT in 8.2.2.5.2. > I also did struggle with this scenario for quite some time. > However, there are several places in the RFC that specifically deal > (directly or indirectly) with this issue. I'm afraid I don't understand your answer. Could you please tell me exactly what happens in the scenario I've described above? -- Juliusz From nobody Fri Apr 3 11:46: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 28A391ACF57 for ; Fri, 3 Apr 2015 11:46:56 -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 hwPTB_GyViD3 for ; Fri, 3 Apr 2015 11:46:54 -0700 (PDT) Received: from mail.coslabs.com (mail.coslabs.com [199.233.92.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B8C1ACF58 for ; Fri, 3 Apr 2015 11:46:54 -0700 (PDT) Received: from [199.233.92.4] (unknown [199.233.92.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.coslabs.com (Postfix) with ESMTPSA id A2DCA1F8D9 for ; Fri, 3 Apr 2015 12:46:51 -0600 (MDT) Message-ID: <551EE01C.6010506@mulligan.com> Date: Fri, 03 Apr 2015 12:46:52 -0600 From: Geoff Mulligan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks References: <21995.1428000041@sandelman.ca> <20150402203416.GA18697@omega> <557AE653-44F3-49E9-887E-7C55CE8295B9@gmail.com> In-Reply-To: <557AE653-44F3-49E9-887E-7C55CE8295B9@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Looking for Linux implementation of RPL for interop testing 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 Apr 2015 18:46:56 -0000 Yes - pick a decent protocol :-) On 04/02/2015 03:50 PM, Ralph Droms wrote: > Thanks, Alex - your response is *very* helpful... > > Anyone have a suggestion about other ways to do interop testing, especially with a non-storing mode LBR/DODAG root? > > - Ralph > >> On Apr 2, 2015, at 4:34 PM 4/2/15, Alexander Aring wrote: >> >> Hi Ralph and Michael, >> >> On Thu, Apr 02, 2015 at 02:40:41PM -0400, Michael Richardson wrote: >>> Ralph Droms (rdroms) wrote: >>>> Can anyone point me at an implementation of RPL for Linux that provides >>>> non-storing mode operation? I'm looking for both an LBR/DODAG root >>>> implementation and an LR implementation. THe purpose is >>>> interoperability testing with an independent implementation. >>> No, I can't point you at this, but I thought I'd answer about why we aren't >>> seeing this yet. >>> >>> A non-storing mode implementation would require kernel implementation of the >>> RH3 header in order to make work (particularly as DODAG root), and at this >>> point, I'm unaware of anyone who has done that work, and it certainly isn't >>> in the mainstream kernel. >>> >>> Perhaps someone out there is already working on it, and has patches. >> I know three 3 RPL implementation for linux, all of them has limitations: >> >> One kernelspace and two userspace implementations, I can't say much >> about these limitations because I doesn't looked deeper into these >> implementations and I have no idea about RPL stuff (currently). :-) >> >> The kernelspace one: >> >> - Known as linux-rpl [0]. >> In my opinion there is still much stuff to do there for bringing this >> stuff mainline. There is a blog article [1] about somebody who tested it >> with contiki nodes and it "seems" basically to work with limitations. >> >> The userspace implementations: >> >> - SimpleRPL [2]. >> Prototype implementation in python. >> >> - unstrung [3]. >> I think the most people on this mailinglist knows about this >> implementation. >> >> >> >> For using these implementation with current mainline: >> >> NOTE: We changed in linux the ARPHRD (the uapi type for a netdev) from >> ARPHRD_IEEE802154 to ARPHRD_6LOWPAN for the 802.15.4 6LoWPAN interface. >> >> The reason was before the 802.15.4 and 802.15.4 6LoWPAN interface used >> the same ARPHRD type, this situation occurs several troubles. Now BTLE >> 6LoWPAN and 802.15.4 6LoWPAN uses the same ARPHRD type which is >> ARPHRD_6LOWPAN. On ARPHRD_6LOWPAN you will have a IPv6 view without L2 >> information, the ARPHRD_IEEE802154 wpan interface has 802.15.4 frames view. >> >> >> I mostly saw that userspace applications evaluates the ARPHRD value for >> checking on an EUI64 mac address length, which is the same for BTLE >> 6LoWPAN and 802.15.4 6LoWPAN. >> >> I notice this because some applications still evaluates the old ARPHRD >> value (I noticed this about another mail on mailinglist at [4]). So you >> will have trouble to run current implementations with current mainline >> if you don't this behaviour. >> >> - Alex >> >> [0] https://github.com/joaopedrotaveira/linux-rpl >> [1] http://sixpinetrees.blogspot.de/2014/11/linux-rpl-router.html >> [2] https://github.com/tcheneau/simpleRPL >> [3] http://unstrung.sandelman.ca/ >> [4] http://lists.sandelman.ca/pipermail/unstrung-hackers/2015-March/000014.html >> >> _______________________________________________ >> 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 Fri Apr 3 11:48: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 6ADD21ACF5D for ; Fri, 3 Apr 2015 11:48:33 -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 jgtUWYOfUSIg for ; Fri, 3 Apr 2015 11:48:31 -0700 (PDT) Received: from mail.coslabs.com (mail.coslabs.com [199.233.92.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8DB1ACF5B for ; Fri, 3 Apr 2015 11:48:31 -0700 (PDT) Received: from [199.233.92.4] (unknown [199.233.92.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.coslabs.com (Postfix) with ESMTPSA id CB5E01F8D9 for ; Fri, 3 Apr 2015 12:48:30 -0600 (MDT) Message-ID: <551EE07F.8030909@mulligan.com> Date: Fri, 03 Apr 2015 12:48:31 -0600 From: Geoff Mulligan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks References: <21995.1428000041@sandelman.ca> <20150402203416.GA18697@omega> <557AE653-44F3-49E9-887E-7C55CE8295B9@gmail.com> In-Reply-To: <557AE653-44F3-49E9-887E-7C55CE8295B9@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Looking for Linux implementation of RPL for interop testing 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 Apr 2015 18:48:33 -0000 sorry - meant to send that to ralph. frustration with implementing some kernel software. Geoff On 04/02/2015 03:50 PM, Ralph Droms wrote: > Thanks, Alex - your response is *very* helpful... > > Anyone have a suggestion about other ways to do interop testing, especially with a non-storing mode LBR/DODAG root? > > - Ralph > >> On Apr 2, 2015, at 4:34 PM 4/2/15, Alexander Aring wrote: >> >> Hi Ralph and Michael, >> >> On Thu, Apr 02, 2015 at 02:40:41PM -0400, Michael Richardson wrote: >>> Ralph Droms (rdroms) wrote: >>>> Can anyone point me at an implementation of RPL for Linux that provides >>>> non-storing mode operation? I'm looking for both an LBR/DODAG root >>>> implementation and an LR implementation. THe purpose is >>>> interoperability testing with an independent implementation. >>> No, I can't point you at this, but I thought I'd answer about why we aren't >>> seeing this yet. >>> >>> A non-storing mode implementation would require kernel implementation of the >>> RH3 header in order to make work (particularly as DODAG root), and at this >>> point, I'm unaware of anyone who has done that work, and it certainly isn't >>> in the mainstream kernel. >>> >>> Perhaps someone out there is already working on it, and has patches. >> I know three 3 RPL implementation for linux, all of them has limitations: >> >> One kernelspace and two userspace implementations, I can't say much >> about these limitations because I doesn't looked deeper into these >> implementations and I have no idea about RPL stuff (currently). :-) >> >> The kernelspace one: >> >> - Known as linux-rpl [0]. >> In my opinion there is still much stuff to do there for bringing this >> stuff mainline. There is a blog article [1] about somebody who tested it >> with contiki nodes and it "seems" basically to work with limitations. >> >> The userspace implementations: >> >> - SimpleRPL [2]. >> Prototype implementation in python. >> >> - unstrung [3]. >> I think the most people on this mailinglist knows about this >> implementation. >> >> >> >> For using these implementation with current mainline: >> >> NOTE: We changed in linux the ARPHRD (the uapi type for a netdev) from >> ARPHRD_IEEE802154 to ARPHRD_6LOWPAN for the 802.15.4 6LoWPAN interface. >> >> The reason was before the 802.15.4 and 802.15.4 6LoWPAN interface used >> the same ARPHRD type, this situation occurs several troubles. Now BTLE >> 6LoWPAN and 802.15.4 6LoWPAN uses the same ARPHRD type which is >> ARPHRD_6LOWPAN. On ARPHRD_6LOWPAN you will have a IPv6 view without L2 >> information, the ARPHRD_IEEE802154 wpan interface has 802.15.4 frames view. >> >> >> I mostly saw that userspace applications evaluates the ARPHRD value for >> checking on an EUI64 mac address length, which is the same for BTLE >> 6LoWPAN and 802.15.4 6LoWPAN. >> >> I notice this because some applications still evaluates the old ARPHRD >> value (I noticed this about another mail on mailinglist at [4]). So you >> will have trouble to run current implementations with current mainline >> if you don't this behaviour. >> >> - Alex >> >> [0] https://github.com/joaopedrotaveira/linux-rpl >> [1] http://sixpinetrees.blogspot.de/2014/11/linux-rpl-router.html >> [2] https://github.com/tcheneau/simpleRPL >> [3] http://unstrung.sandelman.ca/ >> [4] http://lists.sandelman.ca/pipermail/unstrung-hackers/2015-March/000014.html >> >> _______________________________________________ >> 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 Mon Apr 6 03:14:47 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 AB2481A702F for ; Mon, 6 Apr 2015 03:14:46 -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 9p7E7LrH3ykR for ; Mon, 6 Apr 2015 03:14:41 -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 C18EE1A7023 for ; Mon, 6 Apr 2015 03:14:41 -0700 (PDT) Received: from localhost ([::1]:39391 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yf43F-0003fZ-23; Mon, 06 Apr 2015 03:14:41 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-richardson-roll-applicability-template@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 06 Apr 2015 10:14:41 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/169 Message-ID: <067.820b527e86b1f7925fabfdf4ce3ebe71@trac.tools.ietf.org> X-Trac-Ticket-ID: 169 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-richardson-roll-applicability-template@tools.ietf.org, 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 Resent-To: draft-richardson-roll-applicability-template@ietf.org Resent-Message-Id: <20150406101441.C18EE1A7023@ietfa.amsl.com> Resent-Date: Mon, 6 Apr 2015 03:14:41 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Archived-At: Cc: roll@ietf.org Subject: [Roll] [roll] #169 (draft-richardson-roll-applicability-template): Work Item Proposals 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: Mon, 06 Apr 2015 10:14:46 -0000 #169: Work Item Proposals Source: http://www.ietf.org/mail-archive/web/roll/current/msg09217.html From: "Pascal Thubert (pthubert)" - Thu, 2 Apr 2015 - One is a MOP based on BIER and/or Bloom filters, which is a way to compress BIER with a chance of false positive. Carsten has a draft that details the use of Bloom filters for source routing, but really both BIER and Bloom can apply to either storing and non-storing. - Work on mixed storing and non-storing, and all sort of optimization for the storing mode. I’m aware of feasible solutions in that space that really should be shared and made available to all. - Work on additional capabilities that we did not initially include in the spec: - The capability to kill a route from the root, e.g. if a DAO state is installed and should be cleaned up, e.g. if the root realizes that the node is no more there or there is a duplication or what-else. - The capability to trigger a DAO from the root if a target is expected to be present in the network but there is no DAO state (maybe to save resources) - The capability to request the triggering of a new iteration of a DODAG from a RPL node or a controlling element. ------ 2015-03-31 - Pascal Thubert: - How RPL works outside LLNs and in mixed environments? - I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. Applicability of RPL in various environments outside LLN would be of interest, e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that a DT will form at HOMENET to select a routing protocol, and an applicability statement of RPL for that case would be a good read if we can produce it in time. - From our experience of actually doing RPL over Ethernet, it is mostly a matter of *not* using the packet artifacts, probably not using the stretch in local repair, and reacting immediately to changes in link state. This is a very small spec indeed, mostly guidance on what to use and what not to use from RFC 6550, how to tune some parameters, which OF to use and how. - The work should also detail the mode where there is a backbone and a virtual root. I think that the current charter does not cover work outside LLN but considering that we are the group that knows RPL best, that work should happen here. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-richardson-roll- mariainesrobles@gmail.com | applicability- Type: task | template@tools.ietf.org Priority: minor | Status: new Component: draft-richardson-roll- | Milestone: applicability-template | Version: Severity: Candidate WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Mon Apr 6 03:19: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 06FF71A702F for ; Mon, 6 Apr 2015 03:19:49 -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 0MECXX9p3wjZ for ; Mon, 6 Apr 2015 03:19:47 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 55C3D1A702B for ; Mon, 6 Apr 2015 03:19:47 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so8262293lbb.3 for ; Mon, 06 Apr 2015 03:19:45 -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=IbBYyGw+BKvCwrFxd/S5QJwinOcuT8LysAWcnxcaxHE=; b=yWk8jGoedAiMtw61BcluT7VqKHOh+j6itP7xav6CF/fAPd92EoAfh9TqNxOZmO7R6B RQXGjYKCXEaJN6NngG9INUa4nusFlnLWkUIgr/m+r143PQezDuDVRea/5Wic/huw5mHa NsHMYd41t8oDpJ5oLIa24Sc+XGnheafuU19u1yM/Pbm2sMmMXYRisiitCBPhnIMuwOuk NMMsbuolwM7WNsTv6Huo177ahyeU8T7lOGpA+JU82d/Ofc2TQvfbpV0d4xUtUki0GjWt RV7/l6Vb/78dGmBNU+pB4PB/eCrOFKKpKtW8YapyFKc31hv0FUgCElejElZX0gKAaQpC Mryw== MIME-Version: 1.0 X-Received: by 10.112.188.194 with SMTP id gc2mr3542292lbc.25.1428315585887; Mon, 06 Apr 2015 03:19:45 -0700 (PDT) Received: by 10.25.89.4 with HTTP; Mon, 6 Apr 2015 03:19:45 -0700 (PDT) In-Reply-To: <551A4FDF.4040000@gridmerge.com> References: <30526.1427136071@sandelman.ca> <10807.1427243740@sandelman.ca> <11436.1427750888@sandelman.ca> <551A4FDF.4040000@gridmerge.com> Date: Mon, 6 Apr 2015 13:19:45 +0300 Message-ID: From: Ines Robles To: robert cragie , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c37ac01fc10005130ba30a Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter 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 Apr 2015 10:19:49 -0000 --001a11c37ac01fc10005130ba30a Content-Type: text/plain; charset=UTF-8 Thank you very much Robert, your suggestions were included. Cheers, Michael and Ines. 2015-03-31 10:42 GMT+03:00 Robert Cragie : > Hope I'm not too late... > > I support the charter update. Just a couple of suggestions: > > * Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation" as also > suggested by Thomas. AFAICT "IPIP" is not widely used and when it is, it > refers more to IPv4. > * Change "in the 6lowpan HC context" to "in the 6LoWPAN adaptation layer > context". This generalises it to include dispatch-based solutions as well, > otherwise it could be read as only looking at NHC-based variants. > > Robert > > > On 30/03/2015 22:28, Michael Richardson wrote: > > Michael Richardson wrote: > > The charter discussion will remain open until March 30. This will put > > it on the telechat for April 9. > > Last change to say something + or - about this charter update. > > > > > > _______________________________________________ > Roll mailing listRoll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001a11c37ac01fc10005130ba30a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you very much Robert, your suggestions were included= .

Cheers,

Michael and Ines.

2015-03-31 10:4= 2 GMT+03:00 Robert Cragie <robert.cragie@gridmerge.com>:
=20 =20 =20
Hope I'm not too late...

I support the charter update. Just a couple of suggestions:

* Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsula= tion" as also suggested by Thomas. AFAICT "IPIP" is not widely used an= d when it is, it refers more to IPv4.
* Change "in the 6lowpan HC context" to "in the 6LoWPAN = adaptation layer context". This generalises it to include dispatch-based solutions as well, otherwise it could be read as only looking at NHC-based variants.

Robert


On 30/03/2015 22:28, Michael Richardson wrote:
Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > The charter discussion will remain open until March 30. This will =
put
    > it on the telechat for April 9.

Last change to say something + or - about this charter update.





________________________________________=
_______
Roll mailing list
Roll@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/roll


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--001a11c37ac01fc10005130ba30a-- From nobody Mon Apr 6 03:26: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 5B9481A86DD for ; Mon, 6 Apr 2015 03:26:35 -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 pXT3c2t6FWn3 for ; Mon, 6 Apr 2015 03:26:31 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::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 DE8DD1A8034 for ; Mon, 6 Apr 2015 03:26:30 -0700 (PDT) Received: by lagv1 with SMTP id v1so16951463lag.3 for ; Mon, 06 Apr 2015 03:26:29 -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=6VadsWpDdqnCtC33rw8ExeodrHNpGwzfhAq6P1K3Esc=; b=wuErv3hdv3xiLATnwkJzlIgtVjVFeO4B1sMZ6rGUdGEsj0kqPPT0RkcBJnMLBpLigz nOZHPbEzNQMMrzUi321FHHWfAc+Fwiy/cDP3INGNb/DbKkEXmoSx0TU11Ah994C6PplG w2vSHRizKtnjjlvarswsxo0Rmir+Zl2weSSCpQCpszAiaWxp5JByuQX4bT0Y3oZiTvxe GqfzEWt+Kw2v6Kz3ZC8G2aZmdMcxu5+zEajI+rw0fJEpKsQaY3MEDuSc37n3jj39WDVU DiUr2Q1CfwQJNmFXNqKioTGZpcw7/G9hHQxxMAU+62wXjGwr3GwVowIF0TLAfTlzsdg/ WcHg== MIME-Version: 1.0 X-Received: by 10.112.8.101 with SMTP id q5mr13109697lba.19.1428315989297; Mon, 06 Apr 2015 03:26:29 -0700 (PDT) Received: by 10.25.89.4 with HTTP; Mon, 6 Apr 2015 03:26:29 -0700 (PDT) In-Reply-To: References: <30526.1427136071@sandelman.ca> Date: Mon, 6 Apr 2015 13:26:29 +0300 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a1134df962b511105130bbb12 Archived-At: Cc: Michael Richardson Subject: Re: [Roll] proposed amendments to ROLL charter 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 Apr 2015 10:26:35 -0000 --001a1134df962b511105130bbb12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Ticket #169 [http://trac.tools.ietf.org/wg/roll/trac/ticket/169] was created to tack these items. Thank you, Michael and Ines. 2015-04-02 18:59 GMT+03:00 Pascal Thubert (pthubert) : > A few other things I=E2=80=99d like to see, Ines: > > > > - One is a MOP based on BIER and/or Bloom filters, which is a way to > compress BIER with a chance of false positive. Carsten has a draft that > details the use of Bloom filters for source routing, but really both BIER > and Bloom can apply to either storing and non-storing. > > - Work on mixed storing and non-storing, and all sort of optimization for > the storing mode. I=E2=80=99m aware of feasible solutions in that space t= hat really > should be shared and made available to all. > > - Work on additional capabilities that we did not initially include in th= e > spec: > > - The capability to kill a route from the root, e.g. if a DAO state is > installed and should be cleaned up, e.g. if the root realizes that the no= de > is no more there or there is a duplication or what-else. > > - The capability to trigger a DAO from the root if a target is expected t= o > be present in the network but there is no DAO state (maybe to save > resources) > > - The capability to request the triggering of a new iteration of a DODAG > from a RPL node or a controlling element. > > > > Thanks for asking J > > > > Pascal > > > > *From:* Roll [mailto:roll-bounces@ietf.org] *On Behalf Of *Ines Robles > *Sent:* mardi 31 mars 2015 16:10 > *To:* Routing Over Low power and Lossy networks > *Cc:* Michael Richardson > *Subject:* Re: [Roll] proposed amendments to ROLL charter > > > > Hi Pascal, > > > > Thank you very much for your comments, we are going to include them in ou= r > meeting. > > > > To all, There are additional topics that you would like to include in the > charter? Please justify. > > > > Thank you very much, > > > > Michael and Ines > > > > 2015-03-31 13:49 GMT+03:00 Pascal Thubert (pthubert) = : > > Hello Michael (and all): > > I fully support the additions. Since you are at it, I would like to > explore a deeper realignment. > > ROLL is now in charge of the maintenance of RPL, isn't it? > - I think that this should be a work item in the charter. > - this should replace elements that were or are being delivered such as > metrics, security, and RPL itself > > And if that's so, wouldn't it make sense to study how RPL works outside > LLNs and in mixed environments? > - I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. > Applicability of RPL in various environments outside LLN would be of > interest, e.g. to build a Wi-Fi mesh or an unmanaged network. It seems th= at > a DT will form at HOMENET to select a routing protocol, and an > applicability statement of RPL for that case would be a good read if we c= an > produce it in time. > - From our experience of actually doing RPL over Ethernet, it is mostly a > matter of *not* using the packet artifacts, probably not using the stretc= h > in local repair, and reacting immediately to changes in link state. This = is > a very small spec indeed, mostly guidance on what to use and what not to > use from RFC 6550, how to tune some parameters, which OF to use and how. > - The work should also detail the mode where there is a backbone and a > virtual root. I think that the current charter does not cover work outsid= e > LLN but considering that we are the group that knows RPL best, that work > should happen here. > > What do you think? > > Pascal > > > > -----Original Message----- > > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael > Richardson > > Sent: lundi 23 mars 2015 19:41 > > To: roll@ietf.org > > Subject: [Roll] proposed amendments to ROLL charter > > > > > > The following changes are proposed for the ROLL charter to include the > work to > > profile 6553/6554/IPIP, and to compress it. > > > > To the pre-amble: > > > > After: > > - In most cases, LLNs will be employed over link layers with restricte= d > > frame-sizes, thus a routing protocol for LLNs should be specifically > > adapted for such link layers. > > > > Add: > > +- LLN routing protocols have to be very careful when trading off > > +efficiency > > + for generality; many LLN nodes do not have resources to waste. > > > > After: > > The solution must include unicast and multicast considerations. > > > > Add: > > +The Working Group will document how non-control packets are routed whe= n > > +they cross the LLN, and when they enter and exit the LLN: the > > +appropriate use of > > +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how > > +routing loops are detected. In consultation with the 6lo WG, the > > +Working Group will design a method to these routing headers into a > > +single block. The result will have a shared WGLC with 6lo. > > > > > To Work Items, add: > > + - A document detailing when to use RFC6553, RFC6554 and IPIP > > + encapsulation. > > + > > + - A document detailing how to compress RFC6553, RFC6554 and IP > headers > > + in the 6lowPAN HC context. > > > > > > The resulting charter (after reformatting of some of the ugly text > wrapping on > > the web site) is: > > > > ---- > > Low power and Lossy networks (LLNs) are made up of many embedded device= s > > with limited power, memory, and processing resources. They are > interconnected > > by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi= , > wired or > > other low power PLC (Powerline Communication) links. LLNs are > transitioning to > > an end-to-end IP-based solution to avoid the problem of non-interoperab= le > > networks interconnected by protocol translation gateways and proxies. > > > > Generally speaking, LLNs have at least five distinguishing > > characteristics: > > - LLNs operate with a hard, very small bound on state. > > - In most cases, LLN optimize for saving energy. > > - Typical traffic patterns are not simply unicast flows (e.g. in some > cases most if > > not all traffic can be point to multipoint). > > - In most cases, LLNs will be employed over link layers with restricted > > frame-sizes, thus a routing protocol for LLNs should be specifically > > adapted for such link layers. > > - LLN routing protocols have to be very careful when trading off > efficiency > > for generality; many LLN nodes do not have resources to waste. > > > > These specific properties cause LLNs to have specific routing > requirements. > > > > Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have bee= n > > evaluated by the working group and have in their current form been foun= d > to > > not satisfy all of these specific routing requirements. > > > > The Working Group is focused on routing issues for LLN. > > > > There is a wide scope of application areas for LLNs, including industri= al > > monitoring, building automation (HVAC, lighting, access control, fire), > > connected homes, healthcare, environmental monitoring, urban sensor > > networks (e.g. Smart Grid), asset tracking. The Working Group focuses o= n > > routing solutions for a subset of these: industrial, connected home, > building and > > urban sensor networks for which routing requirements have been specifie= d. > > These application-specific routing requirement documents will be used f= or > > protocol design. > > > > The Working Group focuses only on IPv6 routing architectural framework > for > > these application scenarios. The Framework will take into consideration > various > > aspects including high reliability in the presence of time varying loss > > characteristics and connectivity while permitting low-power operation > with very > > modest memory and CPU pressure in networks potentially comprising a ver= y > > large number (several thousands) of nodes. > > > > The Working Group will pay particular attention to routing security and > > manageability (e.g., self routing configuration) issues. It will also > need to > > consider the transport characteristic the routing protocol messages wil= l > > experience. Mechanisms that protect an LLN from congestion collapse or > that > > establish some degree of fairness between concurrent communication > sessions > > are out of scope of the Working Group. It is expected that upper-layer > > applications utilizing LLNs define appropriate mechanisms. > > > > The solution must include unicast and multicast considerations. > > > > The Working Group will document how non-control packets are routed when > > they cross the LLN, and when they enter and exit the LLN: the > appropriate use of > > RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routi= ng > > loops are detected. In consultation with the 6lo WG, the Working Group > will > > design a method to these routing headers into a single block. The > result will > > have a shared WGLC with 6lo. > > > > Work Items: > > > > - Specification of routing metrics used in path calculation. This > > includes static and dynamic link/node attributes required for > routing in > > LLNs. > > > > - Provide an architectural framework for routing and path selectio= n > at > > Layer 3 (Routing for LLN Architecture) that addresses such issue= s > as > > whether LLN routing require a distributed and/or centralized pat= h > > computation models, whether additional hierarchy is necessary an= d > how it > > is applied. > > > > Manageability will be considered with each approach, along with > various > > trade-offs for maintaining low power operation, including the > presence of > > non-trivial loss and networks with a very large number of nodes. > > > > - Produce a routing security framework for routing in LLNs. > > > > - Protocol work: The Working Group will consider specific routing > > requirements from the four application documents collectively, a= nd > > specify either a new protocol or extend an existing routing > protocol > > in cooperation with the relevant Working Group. > > If requirements from the four target application areas cannot be > met > > with a single protocol, the WG may choose to specify or extend > more than > > one protocol (this will require a recharter of the WG). > > > > - Documentation of applicability statement of ROLL routing > protocols. > > > > - A document detailing when to use RFC6553, RFC6554 and IPIP > > encapsulation. > > > > - A document detailing how to compress RFC6553, RFC6554 and IP > headers > > in the 6lowPAN HC context. > > > > > > > > $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $ > > > > > > > > -- > > Michael Richardson , Sandelman Software Works > > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > _______________________________________________ > 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 > > --001a1134df962b511105130bbb12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Ticket #169 [http://trac.tools.ietf.org/wg/roll= /trac/ticket/169] was created to tack these items.

=
Thank you,

Michael and Ines.

2015-04-02 18:59 GMT+03:= 00 Pascal Thubert (pthubert) <pthubert@cisco.com>:

A few other things I=E2= =80=99d like to see, Ines:

=C2=A0

- One is a MOP based on B= IER and/or Bloom filters, which is a way to compress BIER with a chance of = false positive. Carsten has a draft that details the use of Bloom filters for source routing, but really both BIER and Bloom can ap= ply to either storing and non-storing.

- Work on mixed storing a= nd non-storing, and all sort of optimization for the storing mode. I=E2=80= =99m aware of feasible solutions in that space that really should be shared and made available to all.

- Work on additional capa= bilities that we did not initially include in the spec:

- The capability to kill a route from the root, e.g. if a DAO state is = installed and should be cleaned up, e.g. if the root realizes that the node is no more there or there is a duplication or what-else.<= /u>

- The capability to trigger a DAO from the root if a target is expected= to be present in the network but there is no DAO state (maybe to save resources)

- The capability to request the triggering of a new iteration of a DODA= G from a RPL node or a controlling element.

=C2=A0

Thanks for asking J

=C2=A0=

Pascal=

=C2=A0

From: Roll [ma= ilto:roll-bounce= s@ietf.org] On Behalf Of Ines Robles
Sent: mardi 31 mars 2015 16:10
To: Routing Over Low power and Lossy networks
Cc: Michael Richardson
Subject: Re: [Roll] proposed amendments to ROLL charter

=C2=A0

Hi Pascal,

=C2=A0

Thank you very much for your comments, we are going = to include them in our meeting.=C2=A0

=C2=A0

To all, There are additional topics that you would l= ike to include in the charter? Please justify.

=C2=A0

Thank you very much,

=C2=A0

Michael and Ines

=C2=A0

2015-03-31 13:49 GMT+03:00 Pascal Thubert (pthubert)= <pthubert@cisco= .com>:

Hello Michael (and all):

I fully support the additions. Since you are at it, I would like to explore= a deeper realignment.

ROLL is now in charge of the maintenance of RPL, isn't it?
- I think that this should be a work item in the charter.
- this should replace elements that were or are being delivered such as met= rics, security, and RPL itself

And if that's so, wouldn't it make sense to study how RPL works out= side LLNs and in mixed environments?
- I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. = Applicability of RPL in various environments outside LLN would be of intere= st, e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that a DT = will form at HOMENET to select a routing protocol, and an applicability statement of RPL for that case would be a g= ood read if we can produce it in time.
- From our experience of actually doing RPL over Ethernet, it is mostly a m= atter of *not* using the packet artifacts, probably not using the stretch i= n local repair, and reacting immediately to changes in link state. This is = a very small spec indeed, mostly guidance on what to use and what not to use from RFC 6550, how to tune som= e parameters, which OF to use and how.
- The work should also detail the mode where there is a backbone and a virt= ual root. I think that the current charter does not cover work outside LLN = but considering that we are the group that knows RPL best, that work should= happen here.

What do you think?

Pascal


> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson
> Sent: lundi 23 mars 2015 19:41
> To: roll@ietf.org
> Subject: [Roll] proposed amendments to ROLL charter
>
>
> The following changes are proposed for the ROLL charter to include the= work to
> profile 6553/6554/IPIP, and to compress it.
>
> To the pre-amble:
>
> After:
>=C2=A0 - In most cases, LLNs will be employed over link layers with res= tricted
>=C2=A0 =C2=A0 frame-sizes, thus a routing protocol for LLNs should be s= pecifically
>=C2=A0 =C2=A0 adapted for such link layers.
>
> Add:
> +- LLN routing protocols have to be very careful when trading off
> +efficiency
> +=C2=A0 for generality; many LLN nodes do not have resources to waste.=
>
> After:
>=C2=A0 The solution must include unicast and multicast considerations.<= br> >
> Add:
> +The Working Group will document how non-control packets are routed wh= en
> +they cross the LLN, and when they enter and exit the LLN: the
> +appropriate use of
> +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how
> +routing loops are detected. In consultation with the 6lo WG, the
> +Working Group will design a method to these routing headers into a > +single block.=C2=A0 The result will have a shared WGLC with 6lo.

>
> To=C2=A0 Work Items, add:
> +=C2=A0 =C2=A0 =C2=A0- A document detailing when to use RFC6553, RFC65= 54 and IPIP
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0encapsulation.
> +
> +=C2=A0 =C2=A0 =C2=A0- A document detailing how to compress RFC6553, R= FC6554 and IP headers
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0in the 6lowPAN HC context.
>
>
> The resulting charter (after reformatting of some of the ugly text wra= pping on
> the web site) is:
>
> ----
> Low power and Lossy networks (LLNs) are made up of many embedded devic= es
> with limited power, memory, and processing resources. They are interco= nnected
> by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiF= i, wired or
> other low power PLC (Powerline Communication) links. LLNs are transiti= oning to
> an end-to-end IP-based solution to avoid the problem of non-interopera= ble
> networks interconnected by protocol translation gateways and proxies.<= br> >
> Generally speaking, LLNs have at least five distinguishing
> characteristics:
> - LLNs operate with a hard, very small bound on state.
> - In most cases, LLN optimize for saving energy.
> - Typical traffic patterns are not simply unicast flows (e.g. in some = cases most if
> not all traffic can be point to multipoint).
> - In most cases, LLNs will be employed over link layers with restricte= d
>=C2=A0 =C2=A0frame-sizes, thus a routing protocol for LLNs should be sp= ecifically
>=C2=A0 =C2=A0adapted for such link layers.
> - LLN routing protocols have to be very careful when trading off effic= iency
>=C2=A0 =C2=A0for generality; many LLN nodes do not have resources to wa= ste.
>
> These specific properties cause LLNs to have specific routing requirem= ents.
>
> Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have be= en
> evaluated by the working group and have in their current form been fou= nd to
> not satisfy all of these specific routing requirements.
>
> The Working Group is focused on routing issues for LLN.
>
> There is a wide scope of application areas for LLNs, including industr= ial
> monitoring, building automation (HVAC, lighting, access control, fire)= ,
> connected homes, healthcare, environmental monitoring, urban sensor > networks (e.g. Smart Grid), asset tracking. The Working Group focuses = on
> routing solutions for a subset of these: industrial, connected home, b= uilding and
> urban sensor networks for which routing requirements have been specifi= ed.
> These application-specific routing requirement documents will be used = for
> protocol design.
>
> The Working Group focuses only on IPv6 routing architectural framework= for
> these application scenarios. The Framework will take into consideratio= n various
> aspects including high reliability in the presence of time varying los= s
> characteristics and connectivity while permitting low-power operation = with very
> modest memory and CPU pressure in networks potentially comprising a ve= ry
> large number (several thousands) of nodes.
>
> The Working Group will pay particular attention to routing security an= d
> manageability (e.g., self routing configuration) issues. It will also = need to
> consider the transport characteristic the routing protocol messages wi= ll
> experience. Mechanisms that protect an LLN from congestion collapse or= that
> establish some degree of fairness between concurrent communication ses= sions
> are out of scope of the Working Group. It is expected that upper-layer=
> applications utilizing LLNs define appropriate mechanisms.
>
> The solution must include unicast and multicast considerations.
>
> The Working Group will document how non-control packets are routed whe= n
> they cross the LLN, and when they enter and exit the LLN: the appropri= ate use of
> RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how rout= ing
> loops are detected. In consultation with the 6lo WG, the Working Group= will
> design a method to these routing headers into a single block.=C2=A0 Th= e result will
> have a shared WGLC with 6lo.
>
> Work Items:
>
>=C2=A0 =C2=A0 =C2=A0 - Specification of routing metrics used in path ca= lculation. This
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 includes static and dynamic link/node attri= butes required for routing in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 LLNs.
>
>=C2=A0 =C2=A0 =C2=A0 - Provide an architectural framework for routing a= nd path selection at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Layer 3 (Routing for LLN Architecture) that= addresses such issues as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 whether LLN routing require a distributed a= nd/or centralized path
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 computation models, whether additional hier= archy is necessary and how it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 is applied.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Manageability will be considered with each = approach, along with various
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 trade-offs for maintaining low power operat= ion, including the presence of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 non-trivial loss and networks with a very l= arge number of nodes.
>
>=C2=A0 =C2=A0 =C2=A0 - Produce a routing security framework for routing= in LLNs.
>
>=C2=A0 =C2=A0 =C2=A0 - Protocol work: The Working Group will consider s= pecific routing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 requirements from the four application docu= ments collectively, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 specify either a new protocol or extend an = existing routing protocol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 in cooperation with the relevant Working Gr= oup.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If requirements from the four target applic= ation areas cannot be met
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 with a single protocol, the WG may choose t= o specify or extend more than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 one protocol (this will require a recharter= of the WG).
>
>=C2=A0 =C2=A0 =C2=A0 - Documentation of applicability statement of ROLL= routing protocols.
>
>=C2=A0 =C2=A0 =C2=A0 - A document detailing when to use RFC6553, RFC655= 4 and IPIP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 encapsulation.
>
>=C2=A0 =C2=A0 =C2=A0 - A document detailing how to compress RFC6553, RF= C6554 and IP headers
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 in the 6lowPAN HC context.
>
>
>
> $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $
>
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> IETF ROLL WG co-chair.=C2=A0 =C2=A0 http://datatracker.ietf.org/wg/roll/charter/

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

=C2=A0


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--001a1134df962b511105130bbb12-- From nobody Mon Apr 6 13:57: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 949681A92B5; Mon, 6 Apr 2015 13:56:39 -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, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 zXpzO1K-t85M; Mon, 6 Apr 2015 13:56:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4B11A92B8; Mon, 6 Apr 2015 13:56:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150406205637.16494.53243.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 13:56:37 -0700 Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 13:57:52 -0700 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] Kathleen Moriarty's No Objection on draft-ietf-roll-applicability-home-building-09: (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: Mon, 06 Apr 2015 20:56:39 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-roll-applicability-home-building-09: 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The draft looks good, thank you for your work on it. I see privacy isn't mentioned, but think that's okay as I can't think of a scenario where privacy isn't covered by the security already provided (through confidentiality protections) since the scope is within a network - home or office. I'm just mentioning this here in case someone else does think of a scenario that may be necessary to note in the draft. From nobody Mon Apr 6 14:36:55 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9A8261AC439; Mon, 6 Apr 2015 14:33:05 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799701AC438; Mon, 6 Apr 2015 14:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 Fbby2dRQymxR; Mon, 6 Apr 2015 14:33:03 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F481AC437; Mon, 6 Apr 2015 14:33:03 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t36LX24A011142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2015 17:33:02 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_968C6142-35F7-43CC-B10C-FAC73C9E6D30" Date: Mon, 6 Apr 2015 17:33:02 -0400 Message-Id: <50AF625A-F94C-431D-A91A-C14876FC6DD4@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 14:36:54 -0700 Cc: Catherine Meadows Subject: [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 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 Apr 2015 21:33:05 -0000 --Apple-Mail=_968C6142-35F7-43CC-B10C-FAC73C9E6D30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document gives recommendations for the use of RPL in home = automation and building control, that typically provide support such things as climate and lighting = control. I reviewed a much earlier version of this document, and I think this version is much improved in = the way it scopes out the problem and handles the security implications. The Security Considerations = section in particular is very thorough. There are a few improvements I would recommend, however: Section 4.1.8 Security You should give justifications for these choices of parameters as you = give justifications for the other parameters described in this draft. Section 7.1 Security considerations during initial deployment New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assume a partial ordering of the nodes, such that unsecured nodes are added sequentially with the restriction that a path between two secured nodes exists which passes through secured nodes only. I found this a little hard to understand. When does a node pass from = being unsecured to secured? Or does an unsecured node remain unsecured? = If there is a succinct way of saying this, it could go here. Since this is only = describing new approaches that could potentially be applied, you would = not want to go into a lot of detail.=20 In the home, nodes can be visually inspected by the home owner and simple measures like pushing buttons simultaneously on joint and joining devices is probably sufficient. I think this definitely needs to be clarified! You need to say what is = being accomplished by pushing the buttons (device pairing)? 7.2 When nodes are lost, no additional security measures are needed, the network remains secure as before by not allowing the addition of new nodes. I=92m not sure what this means. Does it mean that if a node is lost, = then it is treated as a =93new node=94 if it reappears, and is not = allowed to rejoin the network? New nodes can be added by using the same protocols used for initial deployment. This came right after the sentence beginning =93When nodes are lost=94 = which said that new nodes are not added. That contradiction needs to be reconciled. I=92m also not sure what =93using the same protocol=94 = means. Does it mean rerunning the protocol and rekeying all the nodes, = or does it mean using the features that protocol has for adding nodes? Nits: Section 1.1=20 This applicability statement recommends more light weight security solutions and specify the conditions under which these solutions are appropriate. Should be =93specifies=94 instead of =93specify=94. I=92m also not sure = what is meant by =93conditions under which these solutions are = appropriate.=94 Do you mean light-weight as opposed to no security, or light-weight as = opposed to heavy-weight. Or are you talking about conditions under which different light-weight solutions are appropriate? =46rom = reading the rest of the draft, I would assume the last is what you mean. I consider this document ready with issues. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail=_968C6142-35F7-43CC-B10C-FAC73C9E6D30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I have = reviewed this document as part of the security = directorate's 
ongoing effort to review all IETF documents being = processed by the 
IESG.  These comments were written = primarily for the benefit of the 
security area directors. =  Document editors and WG chairs should treat 
these = comments just like any other last call comments.

This = document gives recommendations for the use of RPL in home automation and = building control,
that typically provide support such things = as climate and lighting control.  I reviewed a much = earlier
version of this document, and I think this version is = much improved in the way it scopes out the problem
and handles = the security implications.  The Security Considerations section in = particular is very
thorough.  There are a few = improvements I would recommend, = however:

Section 4.1.8   = Security

You should  give justifications = for these choices of parameters as you give justifications for = the
other parameters described in this = draft.

Section 7.1 Security considerations = during initial deployment

New approaches = to initial security deployment are being developed in
  =  [I-D.kumar-dice-dtls-relay] and
  =  [I-D.richardson-6tisch--security-6top].  They assume a = partial
   ordering of the nodes, such that = unsecured nodes are added
   sequentially with the = restriction that a path between two secured
   nodes = exists which passes through secured nodes = only.

I found this a little hard to = understand.  When does a node pass from being unsecured to secured? =  Or does an unsecured node remain unsecured? If there = is
a succinct way of saying this, it could go here. =  Since this is only describing new approaches that could = potentially be applied, you would not
want to go into a lot of = detail. 

In the home, nodes can be = visually inspected by the home owner
   and simple = measures like pushing buttons simultaneously on joint = and
   joining devices is probably = sufficient.

I think this definitely needs = to be clarified!  You need to say what is being accomplished by = pushing the buttons (device = pairing)?

7.2

When = nodes are lost, no additional security measures are needed, = the
   network remains secure as before by not allowing the = addition of new
   nodes.

I=92m = not sure what this means.  Does it mean that if a node is lost, = then it is treated as a =93new node=94 if it reappears, and is not = allowed
to rejoin the = network?

New nodes can be added by using = the same protocols used for
   initial = deployment.

This came right after the = sentence beginning =93When nodes are lost=94 which said that new nodes = are not added.  That contradiction needs to
be = reconciled.  I=92m also not sure what =93using the same protocol=94 = means.  Does it mean rerunning the protocol and rekeying all the = nodes, or does
it mean using the features that protocol has = for adding = nodes?


Nits:

<= div>Section 1.1 

This applicability = statement
   recommends more light weight security = solutions and specify the
   conditions under which = these solutions are appropriate.

Should be = =93specifies=94 instead of =93specify=94.  I=92m also not sure what = is meant by =93conditions under which these solutions are appropriate.=94 =  Do
you mean light-weight as opposed to no security, or = light-weight as opposed to heavy-weight.  Or are you talking about = conditions
under which different light-weight solutions are = appropriate? =46rom reading the rest of the draft, I would assume the = last is what you mean.


I = consider this document  ready with = issues.


Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

= --Apple-Mail=_968C6142-35F7-43CC-B10C-FAC73C9E6D30-- From nobody Mon Apr 6 14:55:20 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6664E1ACC8B; Mon, 6 Apr 2015 14:38:00 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4925F1ACC82 for ; Mon, 6 Apr 2015 14:38:00 -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, HTML_MESSAGE=0.001] 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 7mgKPaf7Gaw2 for ; Mon, 6 Apr 2015 14:37:57 -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 A129D1ACCD8 for ; Mon, 6 Apr 2015 14:37:56 -0700 (PDT) Received: from mx0.ccs.nrl.navy.mil ([2001:480:20:118:118::211]:57723 helo=ccs.nrl.navy.mil) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfEiP-0008WV-Og for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Mon, 06 Apr 2015 14:37:56 -0700 Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t36LbgEw014314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2015 17:37:42 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_990CEB30-E296-4D3E-B5E9-CB3F898FC618" Date: Mon, 6 Apr 2015 17:37:42 -0400 Message-Id: To: secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email X-Helo-Check-Failed: Verification failed for HELO ccs.nrl.navy.mil X-SA-Exim-Connect-IP: 2001:480:20:118:118::211 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-SA-Exim-Mail-From: catherine.meadows@nrl.navy.mil 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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150406213756.A129D1ACCD8@ietfa.amsl.com> Resent-Date: Mon, 6 Apr 2015 14:37:56 -0700 (PDT) Resent-From: catherine.meadows@nrl.navy.mil Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 14:55:19 -0700 Cc: Catherine Meadows Subject: [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend) 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 Apr 2015 21:38:00 -0000 --Apple-Mail=_990CEB30-E296-4D3E-B5E9-CB3F898FC618 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I had the draft authors=92 email address wrong on my last message, so I = am resending it. I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document gives recommendations for the use of RPL in home = automation and building control, that typically provide support such things as climate and lighting = control. I reviewed a much earlier version of this document, and I think this version is much improved in = the way it scopes out the problem and handles the security implications. The Security Considerations = section in particular is very thorough. There are a few improvements I would recommend, however: Section 4.1.8 Security You should give justifications for these choices of parameters as you = give justifications for the other parameters described in this draft. Section 7.1 Security considerations during initial deployment New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assume a partial ordering of the nodes, such that unsecured nodes are added sequentially with the restriction that a path between two secured nodes exists which passes through secured nodes only. I found this a little hard to understand. When does a node pass from = being unsecured to secured? Or does an unsecured node remain unsecured? = If there is a succinct way of saying this, it could go here. Since this is only = describing new approaches that could potentially be applied, you would = not want to go into a lot of detail.=20 In the home, nodes can be visually inspected by the home owner and simple measures like pushing buttons simultaneously on joint and joining devices is probably sufficient. I think this definitely needs to be clarified! You need to say what is = being accomplished by pushing the buttons (device pairing)? 7.2 When nodes are lost, no additional security measures are needed, the network remains secure as before by not allowing the addition of new nodes. I=92m not sure what this means. Does it mean that if a node is lost, = then it is treated as a =93new node=94 if it reappears, and is not = allowed to rejoin the network? New nodes can be added by using the same protocols used for initial deployment. This came right after the sentence beginning =93When nodes are lost=94 = which said that new nodes are not added. That contradiction needs to be reconciled. I=92m also not sure what =93using the same protocol=94 = means. Does it mean rerunning the protocol and rekeying all the nodes, = or does it mean using the features that protocol has for adding nodes? Nits: Section 1.1=20 This applicability statement recommends more light weight security solutions and specify the conditions under which these solutions are appropriate. Should be =93specifies=94 instead of =93specify=94. I=92m also not sure = what is meant by =93conditions under which these solutions are = appropriate.=94 Do you mean light-weight as opposed to no security, or light-weight as = opposed to heavy-weight. Or are you talking about conditions under which different light-weight solutions are appropriate? =46rom = reading the rest of the draft, I would assume the last is what you mean. I consider this document ready with issues. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail=_990CEB30-E296-4D3E-B5E9-CB3F898FC618 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I had = the draft authors=92 email address wrong on my last message, so I am = resending it.

I have reviewed this document as part = of the security directorate's 
ongoing effort to review all IETF = documents being processed by the 
IESG.  These comments = were written primarily for the benefit of the 
security area = directors.  Document editors and WG chairs should = treat 
these comments just like any other last call = comments.

This document gives recommendations for the use of RPL = in home automation and building control,
that typically provide = support such things as climate and lighting control.  I reviewed a = much earlier
version of this document, and I think this version is = much improved in the way it scopes out the problem
and handles the = security implications.  The Security Considerations section in = particular is very
thorough.  There are a few improvements I = would recommend, however:

Section 4.1.8   = Security

You should  give justifications for these choices = of parameters as you give justifications for the
other parameters = described in this draft.

Section 7.1 Security considerations = during initial deployment

New approaches to initial security = deployment are being developed in
  =  [I-D.kumar-dice-dtls-relay] and
  =  [I-D.richardson-6tisch--security-6top].  They assume a = partial
   ordering of the nodes, such that unsecured nodes = are added
   sequentially with the restriction that a path = between two secured
   nodes exists which passes through = secured nodes only.

I found this a little hard to understand. =  When does a node pass from being unsecured to secured?  Or = does an unsecured node remain unsecured? If there is
a succinct way = of saying this, it could go here.  Since this is only describing = new approaches that could potentially be applied, you would not
want = to go into a lot of detail. 

In the home, nodes can be = visually inspected by the home owner
   and simple measures = like pushing buttons simultaneously on joint and
   joining = devices is probably sufficient.

I think this definitely needs to = be clarified!  You need to say what is being accomplished by = pushing the buttons (device pairing)?

7.2

When nodes are = lost, no additional security measures are needed, the
  =  network remains secure as before by not allowing the addition of = new
   nodes.

I=92m not sure what this means. =  Does it mean that if a node is lost, then it is treated as a =93new = node=94 if it reappears, and is not allowed
to rejoin the = network?

New nodes can be added by using the same protocols used = for
   initial deployment.

This came right after the = sentence beginning =93When nodes are lost=94 which said that new nodes = are not added.  That contradiction needs to
be reconciled. =  I=92m also not sure what =93using the same protocol=94 means. =  Does it mean rerunning the protocol and rekeying all the nodes, or = does
it mean using the features that protocol has for adding = nodes?


Nits:

Section 1.1 

This = applicability statement
   recommends more light weight = security solutions and specify the
   conditions under = which these solutions are appropriate.

Should be =93specifies=94 = instead of =93specify=94.  I=92m also not sure what is meant by = =93conditions under which these solutions are appropriate.=94 =  Do
you mean light-weight as opposed to no security, or = light-weight as opposed to heavy-weight.  Or are you talking about = conditions
under which different light-weight solutions are = appropriate? =46rom reading the rest of the draft, I would assume the = last is what you mean.


I consider this document  ready = with issues.

Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

= --Apple-Mail=_990CEB30-E296-4D3E-B5E9-CB3F898FC618-- From nobody Mon Apr 6 14: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 9CEEA1ACD6B; Mon, 6 Apr 2015 14:54:08 -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, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 oIscniVb6aDF; Mon, 6 Apr 2015 14:54:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F293E1ACD68; Mon, 6 Apr 2015 14:54:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150406215406.10033.73300.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 14:54:06 -0700 Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 14:55:19 -0700 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] Kathleen Moriarty's No Objection on draft-ietf-roll-applicability-home-building-09: (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: Mon, 06 Apr 2015 21:54:08 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-roll-applicability-home-building-09: 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The draft looks good, thank you for your work on it. I see privacy isn't mentioned, but think that's okay as I can't think of a scenario where privacy isn't covered by the security already provided (through confidentiality protections) since the scope is within a network - home or office. I'm just mentioning this here in case someone else does think of a scenario that may be necessary to note in the draft. The SecDir review had some requests for clarification in the text. In my read, I understood what was intended, but in seeing her questions, I think it would be good to consider rewording the text she points out so it is clear to all readers. This is non-blocking and just something to consider as I understood the intent of the current text, but that doesn't mean it can't be improved :-) http://www.ietf.org/mail-archive/web/secdir/current/msg05589.html From nobody Tue Apr 7 03:03: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 0C6241A1C02; Tue, 7 Apr 2015 03:02: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 SN41rcop2Lfc; Tue, 7 Apr 2015 03:02:53 -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 6AD2D1A1BF6; Tue, 7 Apr 2015 03:02:52 -0700 (PDT) Received: from roundcube.xs4all.nl ([194.109.20.207]) by smtp-cloud3.xs4all.net with ESMTP id Cy2m1q00W4U4Moq01y2mxz; Tue, 07 Apr 2015 12:02:50 +0200 Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 07 Apr 2015 12:02:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 07 Apr 2015 12:02:48 +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: References: Message-ID: X-Sender: stokcons@xs4all.nl (KHqKdo85l6i8RT+HxnE6e+lTyi+pbyzT) User-Agent: XS4ALL Webmail Archived-At: Cc: Catherine Meadows , draft-ietf-roll-applicability-home-building.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend) 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, 07 Apr 2015 10:02:59 -0000 Hi Catherine, thanks for pointing out sources of misunderstanding. Below some suggestions for new text. Considering the values of section 4.1.8; I will look for an RFC that explains in more detail and cite that. @Robert, can you recommend a RFC? > New approaches to initial security deployment are being developed in > [I-D.kumar-dice-dtls-relay] and > [I-D.richardson-6tisch--security-6top]. They assume a partial > ordering of the nodes, such that unsecured nodes are added > sequentially with the restriction that a path between two secured > nodes exists which passes through secured nodes only. New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. In these drafts an already secured node assists in securing an unsecured 1-hop neighbour node. Like an onion, a new layer of unsecured nodes is secured by a former layer of already secured nodes until all selected nodes are secured. > In the home, nodes can be visually inspected by the home owner > and simple measures like pushing buttons simultaneously on joint and > joining devices is probably sufficient. In the home, nodes can be visually inspected by the home owner and simple measures like pushing buttons simultaneously on joint and joining devices are probably sufficient to guarantee that keys are exchanged between the two nodes without major risks of security breaches. > When nodes are lost, no additional security measures are needed, the > network remains secure as before by not allowing the addition of new > nodes. When nodes are lost, no additional security measures are needed, the network remains secure as before by considering the lost nodes as new nodes which have to pass through the join process. Thanks for finding the NIT. I hope the new text above clarifies the obscure points you found. Greetings, Peter Catherine Meadows schreef op 2015-04-06 23:37: > I had the draft authors’ email address wrong on my last message, so > I am resending it. > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document gives recommendations for the use of RPL in home > automation and building control, > that typically provide support such things as climate and lighting > control. I reviewed a much earlier > version of this document, and I think this version is much improved in > the way it scopes out the problem > and handles the security implications. The Security Considerations > section in particular is very > thorough. There are a few improvements I would recommend, however: > > Section 4.1.8 Security > > You should give justifications for these choices of parameters as you > give justifications for the > other parameters described in this draft. > > Section 7.1 Security considerations during initial deployment > > New approaches to initial security deployment are being developed in > [I-D.kumar-dice-dtls-relay] and > [I-D.richardson-6tisch--security-6top]. They assume a partial > ordering of the nodes, such that unsecured nodes are added > sequentially with the restriction that a path between two secured > nodes exists which passes through secured nodes only. > > I found this a little hard to understand. When does a node pass from > being unsecured to secured? Or does an unsecured node remain > unsecured? If there is > a succinct way of saying this, it could go here. Since this is only > describing new approaches that could potentially be applied, you would > not > want to go into a lot of detail. > > In the home, nodes can be visually inspected by the home owner > and simple measures like pushing buttons simultaneously on joint and > joining devices is probably sufficient. > > I think this definitely needs to be clarified! You need to say what is > being accomplished by pushing the buttons (device pairing)? > > 7.2 > > When nodes are lost, no additional security measures are needed, the > network remains secure as before by not allowing the addition of new > nodes. > > I’m not sure what this means. Does it mean that if a node is lost, > then it is treated as a “new node” if it reappears, and is not > allowed > to rejoin the network? > > New nodes can be added by using the same protocols used for > initial deployment. > > This came right after the sentence beginning “When nodes are lost” > which said that new nodes are not added. That contradiction needs to > be reconciled. I’m also not sure what “using the same protocol” > means. Does it mean rerunning the protocol and rekeying all the nodes, > or does > it mean using the features that protocol has for adding nodes? > > Nits: > > Section 1.1 > > This applicability statement > recommends more light weight security solutions and specify the > conditions under which these solutions are appropriate. > > Should be “specifies” instead of “specify”. I’m also not > sure what is meant by “conditions under which these solutions are > appropriate.” Do > you mean light-weight as opposed to no security, or light-weight as > opposed to heavy-weight. Or are you talking about conditions > under which different light-weight solutions are appropriate? From > reading the rest of the draft, I would assume the last is what you > mean. > > I consider this document ready with issues. > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Apr 7 03:03:41 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 39BE41A1EF5; Tue, 7 Apr 2015 03:03:30 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116891A1EEA for ; Tue, 7 Apr 2015 03:03:30 -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 JeEOP1_KfDvA for ; Tue, 7 Apr 2015 03:03:28 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31::14]) (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 090861A1BF6 for ; Tue, 7 Apr 2015 03:03:26 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net ([194.109.24.26]:35120) by merlot.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84) (envelope-from ) id 1YfQLo-0005bZ-Lx for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Tue, 07 Apr 2015 12:03:23 +0200 Received: from roundcube.xs4all.nl ([194.109.20.207]) by smtp-cloud3.xs4all.net with ESMTP id Cy2m1q00W4U4Moq01y2mxz; Tue, 07 Apr 2015 12:02:50 +0200 Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 07 Apr 2015 12:02:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 07 Apr 2015 12:02:48 +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: References: Message-ID: X-Sender: stokcons@xs4all.nl (KHqKdo85l6i8RT+HxnE6e+lTyi+pbyzT) User-Agent: XS4ALL Webmail X-SA-Exim-Connect-IP: 194.109.24.26 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-SA-Exim-Mail-From: stokcons@xs4all.nl 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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150407100326.090861A1BF6@ietfa.amsl.com> Resent-Date: Tue, 7 Apr 2015 03:03:26 -0700 (PDT) Resent-From: stokcons@xs4all.nl Archived-At: Archived-At: Cc: Catherine Meadows , draft-ietf-roll-applicability-home-building.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend) 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, 07 Apr 2015 10:03:30 -0000 Hi Catherine, thanks for pointing out sources of misunderstanding. Below some suggestions for new text. Considering the values of section 4.1.8; I will look for an RFC that explains in more detail and cite that. @Robert, can you recommend a RFC? > New approaches to initial security deployment are being developed in > [I-D.kumar-dice-dtls-relay] and > [I-D.richardson-6tisch--security-6top]. They assume a partial > ordering of the nodes, such that unsecured nodes are added > sequentially with the restriction that a path between two secured > nodes exists which passes through secured nodes only. New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. In these drafts an already secured node assists in securing an unsecured 1-hop neighbour node. Like an onion, a new layer of unsecured nodes is secured by a former layer of already secured nodes until all selected nodes are secured. > In the home, nodes can be visually inspected by the home owner > and simple measures like pushing buttons simultaneously on joint and > joining devices is probably sufficient. In the home, nodes can be visually inspected by the home owner and simple measures like pushing buttons simultaneously on joint and joining devices are probably sufficient to guarantee that keys are exchanged between the two nodes without major risks of security breaches. > When nodes are lost, no additional security measures are needed, the > network remains secure as before by not allowing the addition of new > nodes. When nodes are lost, no additional security measures are needed, the network remains secure as before by considering the lost nodes as new nodes which have to pass through the join process. Thanks for finding the NIT. I hope the new text above clarifies the obscure points you found. Greetings, Peter Catherine Meadows schreef op 2015-04-06 23:37: > I had the draft authors’ email address wrong on my last message, so > I am resending it. > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document gives recommendations for the use of RPL in home > automation and building control, > that typically provide support such things as climate and lighting > control. I reviewed a much earlier > version of this document, and I think this version is much improved in > the way it scopes out the problem > and handles the security implications. The Security Considerations > section in particular is very > thorough. There are a few improvements I would recommend, however: > > Section 4.1.8 Security > > You should give justifications for these choices of parameters as you > give justifications for the > other parameters described in this draft. > > Section 7.1 Security considerations during initial deployment > > New approaches to initial security deployment are being developed in > [I-D.kumar-dice-dtls-relay] and > [I-D.richardson-6tisch--security-6top]. They assume a partial > ordering of the nodes, such that unsecured nodes are added > sequentially with the restriction that a path between two secured > nodes exists which passes through secured nodes only. > > I found this a little hard to understand. When does a node pass from > being unsecured to secured? Or does an unsecured node remain > unsecured? If there is > a succinct way of saying this, it could go here. Since this is only > describing new approaches that could potentially be applied, you would > not > want to go into a lot of detail. > > In the home, nodes can be visually inspected by the home owner > and simple measures like pushing buttons simultaneously on joint and > joining devices is probably sufficient. > > I think this definitely needs to be clarified! You need to say what is > being accomplished by pushing the buttons (device pairing)? > > 7.2 > > When nodes are lost, no additional security measures are needed, the > network remains secure as before by not allowing the addition of new > nodes. > > I’m not sure what this means. Does it mean that if a node is lost, > then it is treated as a “new node” if it reappears, and is not > allowed > to rejoin the network? > > New nodes can be added by using the same protocols used for > initial deployment. > > This came right after the sentence beginning “When nodes are lost” > which said that new nodes are not added. That contradiction needs to > be reconciled. I’m also not sure what “using the same protocol” > means. Does it mean rerunning the protocol and rekeying all the nodes, > or does > it mean using the features that protocol has for adding nodes? > > Nits: > > Section 1.1 > > This applicability statement > recommends more light weight security solutions and specify the > conditions under which these solutions are appropriate. > > Should be “specifies” instead of “specify”. I’m also not > sure what is meant by “conditions under which these solutions are > appropriate.” Do > you mean light-weight as opposed to no security, or light-weight as > opposed to heavy-weight. Or are you talking about conditions > under which different light-weight solutions are appropriate? From > reading the rest of the draft, I would assume the last is what you > mean. > > I consider this document ready with issues. > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Apr 7 07:42:02 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7FD3A1B3667; Tue, 7 Apr 2015 07:42:01 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D221B3665 for ; Tue, 7 Apr 2015 07:42:01 -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, HTML_MESSAGE=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 makPKBMayyE2 for ; Tue, 7 Apr 2015 07:41:57 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31::14]) (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 D10BC1B3662 for ; Tue, 7 Apr 2015 07:41:54 -0700 (PDT) Received: from mailscan39.extendcp.co.uk ([176.32.230.33]:47511 helo=mailscan1.extendcp.co.uk) by merlot.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84) (envelope-from ) id 1YfUhH-0002ua-Ov for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Tue, 07 Apr 2015 16:41:52 +0200 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.hi.local) by mailscan-g74.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YfUgk-0007bn-2G; Tue, 07 Apr 2015 15:41:14 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1YfUgi-0006UG-Cw; Tue, 07 Apr 2015 15:41:14 +0100 Received: from host86-156-208-9.range86-156.btcentralplus.com ([86.156.208.9] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1YfUgQ-0007KV-7F; Tue, 07 Apr 2015 15:40:54 +0100 Message-ID: <5523EC71.1020701@gridmerge.com> Date: Tue, 07 Apr 2015 15:40:49 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.all@tools.ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030903090900070502060301" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout X-SA-Exim-Connect-IP: 176.32.230.33 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-SA-Exim-Mail-From: robert.cragie@gridmerge.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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150407144154.D10BC1B3662@ietfa.amsl.com> Resent-Date: Tue, 7 Apr 2015 07:41:54 -0700 (PDT) Resent-From: robert.cragie@gridmerge.com Archived-At: Archived-At: Cc: Catherine Meadows Subject: Re: [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend) 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, 07 Apr 2015 14:42:01 -0000 This is a cryptographically signed message in MIME format. --------------ms030903090900070502060301 Content-Type: multipart/alternative; boundary="------------070408000005020808070301" This is a multi-part message in MIME format. --------------070408000005020808070301 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Catherine, In addition to Peter's comments, here are my comments inline, bracketed=20 by Robert On 06/04/2015 22:37, Catherine Meadows wrote: > I had the draft authors=E2=80=99 email address wrong on my last message= , so I=20 > am resending it. > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document gives recommendations for the use of RPL in home=20 > automation and building control, > that typically provide support such things as climate and lighting=20 > control. I reviewed a much earlier > version of this document, and I think this version is much improved in = > the way it scopes out the problem > and handles the security implications. The Security Considerations=20 > section in particular is very > thorough. There are a few improvements I would recommend, however: > > Section 4.1.8 Security > > You should give justifications for these choices of parameters as you = > give justifications for the > other parameters described in this draft. The parameters are in RFC 6550. Some explanation could be added, for=20 example: If RPL is used with secured messages, the following RPL security=20 parameter values are recommended to provide a basic level of security: o Counter Time Flag: T =3D '0': Do not use timestamp in the Counter = Field. Counters based on timestamps are typically more applicable to=20 industrial networks where strict timing synchronization between nodes is = often implemented. Home and building networks typically do not implement = such strict timing synchronization therefore a monotonically increasing=20 counter is more appropriate. o Algorithm =3D '0': Use Counter with Cipher Block Chaining Message = Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption=20 Standard (AES)-128. This is the only assigned mode at present. o Key Identifier Mode; KIM =3D '10': Use group key, Key Source=20 present, Key Index present. Given the relatively confined perimeter of a = home or building network, a group key is usually sufficient to protect=20 RPL messages sent between nodes. The use of the Key Source field allows=20 multiple group keys to be used within the network. o Security Level; LVL =3D 0: Use MAC-32. This is recommended as=20 integrity protection for RPL messages is the basic requirement.=20 Encryption is unlikely to be necessary given the relatively=20 non-confidential nature of RPL message payloads. > > Section 7.1 Security considerations during initial deployment > > New approaches to initial security deployment are being developed in > [I-D.kumar-dice-dtls-relay] and > [I-D.richardson-6tisch--security-6top]. They assume a partial > ordering of the nodes, such that unsecured nodes are added > sequentially with the restriction that a path between two secured > nodes exists which passes through secured nodes only. > > I found this a little hard to understand. When does a node pass from=20 > being unsecured to secured? Or does an unsecured node remain=20 > unsecured? If there is > a succinct way of saying this, it could go here. Since this is only=20 > describing new approaches that could potentially be applied, you would = not > want to go into a lot of detail. I would clarify as follows, in addition to Peter's suggestion: New approaches to initial security deployment are being developed in=20 [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top].=20 They assume a partial ordering of the nodes, such that unsecured nodes=20 are added sequentially with the restriction that a path between two=20 secured nodes exists which passes through secured nodes only. New approaches to initial security deployment are being developed in=20 [I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In = these drafts an already secured node at the perimeter of the network,=20 which is one hop away from an unsecured node wishing to access the=20 network, assists in transporting security and configuration traffic=20 between the unsecured node and the authenticator/commissioner. Once=20 secured and configured, the new node extends the perimeter of the=20 network in an "onion ring" fashion until all nodes have been secured and = configured. > > In the home, nodes can be visually inspected by the home owner > and simple measures like pushing buttons simultaneously on joint and= > joining devices is probably sufficient. > > I think this definitely needs to be clarified! You need to say what=20 > is being accomplished by pushing the buttons (device pairing)? I would clarify as follows, in addition to Peter's suggestion: In the home, nodes can be visually inspected by the home owner and=20 simple measures like pushing buttons simultaneously on joint and joining = devices is probably sufficient. In the home, nodes can be visually inspected by the home owner and a=20 simple procedure, e.g. pushing buttons simultaneously on an already=20 secured device and an unsecured joining device is usually sufficient to=20 ensure that the unsecured joining device is authenticated and configured = securely, and paired appropriately. > > 7.2 > > When nodes are lost, no additional security measures are needed, the > network remains secure as before by not allowing the addition of new= > nodes. > > I=E2=80=99m not sure what this means. Does it mean that if a node is l= ost,=20 > then it is treated as a =E2=80=9Cnew node=E2=80=9D if it reappears, and= is not allowed > to rejoin the network? > > New nodes can be added by using the same protocols used for > initial deployment. > > This came right after the sentence beginning =E2=80=9CWhen nodes are lo= st=E2=80=9D=20 > which said that new nodes are not added. That contradiction needs to > be reconciled. I=E2=80=99m also not sure what =E2=80=9Cusing the same = protocol=E2=80=9D=20 > means. Does it mean rerunning the protocol and rekeying all the=20 > nodes, or does > it mean using the features that protocol has for adding nodes? I would rewrite this somewhat as the intent is unclear. I believe the=20 intent is as follows: When nodes are lost, no additional security measures are needed, the=20 network remains secure as before by not allowing the addition of new=20 nodes. New nodes can be added by using the same protocols used for=20 initial deployment. Some protocols may need a state change to a subset=20 of the secured nodes, other protocols only need the presence of a=20 "trusted" installation node [RFC6345], [RFC5191], or=20 [I-D.kumar-dice-dtls-relay]. Normally, the network remains secure by not allowing the addition of new = nodes. If a new node needs to be added to the network, the network is=20 usually configured to allow the new node to join via an assisting node=20 in the manner described in Section 7.1. If an existing node becomes=20 lost, it is usually possible to re-key all other existing nodes to=20 isolate the lost node to ensure that, should it be found again, it has=20 to re-join as if it were a new node. > > > Nits: > > Section 1.1 > > This applicability statement > recommends more light weight security solutions and specify the > conditions under which these solutions are appropriate. > > Should be =E2=80=9Cspecifies=E2=80=9D instead of =E2=80=9Cspecify=E2=80= =9D. I=E2=80=99m also not sure what is=20 > meant by =E2=80=9Cconditions under which these solutions are appropriat= e.=E2=80=9D Do > you mean light-weight as opposed to no security, or light-weight as=20 > opposed to heavy-weight. Or are you talking about conditions > under which different light-weight solutions are appropriate? From=20 > reading the rest of the draft, I would assume the last is what you mean= =2E I would reword as follows: This applicability statement recommends more light weight security=20 solutions and specify the conditions under which these solutions are=20 appropriate. This applicability statement recommends lighter weight security=20 solutions appropriate for home and building environments and indicates=20 why these solutions are appropriate. > > > I consider this document ready with issues. > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil=20 > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------070408000005020808070301 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Catherine,

In addition to Peter's comments, here are my comments inline, bracketed by <RCC></RCC>

Robert

On 06/04/2015 22:37, Catherine Meadows= wrote:
I had the draft authors=E2=80=99 email address wrong on my last mes= sage, so I am resending it.

I have reviewed this document as part of the security directorate's=C2=A0
ongoing effort to review all IETF documents being processed by the=C2=A0
IESG. =C2=A0These comments were written primarily for the benefit= of the=C2=A0
security area directors. =C2=A0Document editors and WG chairs sho= uld treat=C2=A0
these comments just like any other last call comments.

This document gives recommendations for the use of RPL in home automation and building control,
that typically provide support such things as climate and lighting control. =C2=A0I reviewed a much earlier
version of this document, and I think this version is much improved in the way it scopes out the problem
and handles the security implications. =C2=A0The Security Considerations section in particular is very
thorough. =C2=A0There are a few improvements I would recommend, however:

Section 4.1.8 =C2=A0 Security

You should =C2=A0give justifications for these choices of paramet= ers as you give justifications for the
other parameters described in this draft.
<RCC>
The parameters are in RFC 6550. Some explanation could be added, for example:

<new>
If RPL is used with secured messages, the following RPL security parameter values are recommended to provide a basic level of security:

=C2=A0=C2=A0 o=C2=A0 Counter Time Flag: T =3D '0': Do not use timesta= mp in the Counter Field. Counters based on timestamps are typically more applicable to industrial networks where strict timing synchronization between nodes is often implemented. Home and building networks typically do not implement such strict timing synchronization therefore a monotonically increasing counter is more appropriate.

=C2=A0=C2=A0 o=C2=A0 Algorithm =3D '0': Use Counter with Cipher Block= Chaining Message Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption Standard (AES)-128. This is the only assigned mode at present.

=C2=A0=C2=A0 o=C2=A0 Key Identifier Mode; KIM =3D '10': Use group key= , Key Source present, Key Index present. Given the relatively confined perimeter of a home or building network, a group key is usually sufficient to protect RPL messages sent between nodes. The use of the Key Source field allows multiple group keys to be used within the network.

=C2=A0=C2=A0 o=C2=A0 Security Level; LVL =3D 0: Use MAC-32. This is r= ecommended as integrity protection for RPL messages is the basic requirement. Encryption is unlikely to be necessary given the relatively non-confidential nature of RPL message payloads.
</new>
</RCC>

Section 7.1 Security considerations during initial deployment
=
New approaches to initial security deployment are being developed in
=C2=A0 =C2=A0[I-D.kumar-dice-dtls-relay] and
=C2=A0 =C2=A0[I-D.richardson-6tisch--security-6top]. =C2=A0They a= ssume a partial
=C2=A0 =C2=A0ordering of the nodes, such that unsecured nodes are= added
=C2=A0 =C2=A0sequentially with the restriction that a path betwee= n two secured
=C2=A0 =C2=A0nodes exists which passes through secured nodes only= =2E

I found this a little hard to understand. =C2=A0When does a node = pass from being unsecured to secured? =C2=A0Or does an unsecured node remain unsecured? If there is
a succinct way of saying this, it could go here. =C2=A0Since this= is only describing new approaches that could potentially be applied, you would not
want to go into a lot of detail.
<RCC>
I would clarify as follows, in addition to Peter's suggestion:

<old>
New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assume a partial ordering of the nodes, such that unsecured nodes are added sequentially with the restriction that a path between two secured nodes exists which passes through secured nodes only.
</old>
<new>
New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In these drafts an already secured node at the perimeter of the network, which is one hop away from an unsecured node wishing to access the network, assists in transporting security and configuration traffic between the unsecured node and the authenticator/commissioner. Once secured and configured, the new node extends the perimeter of the network in an "onion ring" fashion until all nodes have been secured and configured.
</new>
</RCC>

In the home, nodes can be visually inspected by the home owner =C2=A0 =C2=A0and simple measures like pushing buttons simultaneou= sly on joint and
=C2=A0 =C2=A0joining devices is probably sufficient.

I think this definitely needs to be clarified! =C2=A0You need to = say what is being accomplished by pushing the buttons (device pairing)?
<RCC>
I would clarify as follows, in addition to Peter's suggestion:

<old>
In the home, nodes can be visually inspected by the home owner and simple measures like pushing buttons simultaneously on joint and joining devices is probably sufficient.
</old>
<new>
In the home, nodes can be visually inspected by the home owner and a simple procedure, e.g. pushing buttons simultaneously on an already secured device and an unsecured joining device is usually sufficient to ensure that the unsecured joining device is authenticated and configured securely, and paired appropriately.
</new>
</RCC>

7.2

When nodes are lost, no additional security measures are needed, the
=C2=A0 =C2=A0network remains secure as before by not allowing the= addition of new
=C2=A0 =C2=A0nodes.

I=E2=80=99m not sure what this means. =C2=A0Does it mean that if = a node is lost, then it is treated as a =E2=80=9Cnew node=E2=80=9D if it re= appears, and is not allowed
to rejoin the network?

New nodes can be added by using the same protocols used for
=C2=A0 =C2=A0initial deployment.

This came right after the sentence beginning =E2=80=9CWhen nodes = are lost=E2=80=9D which said that new nodes are not added. =C2=A0That= contradiction needs to
be reconciled. =C2=A0I=E2=80=99m also not sure what =E2=80=9Cusin= g the same protocol=E2=80=9D means. =C2=A0Does it mean rerunning the protocol and rekeying all= the nodes, or does
it mean using the features that protocol has for adding nodes?
<RCC>
I would rewrite this somewhat as the intent is unclear. I believe the intent is as follows:

<old>
When nodes are lost, no additional security measures are needed, the network remains secure as before by not allowing the addition of new nodes. New nodes can be added by using the same protocols used for initial deployment.=C2=A0 Some protocols may need a state change to a= subset of the secured nodes, other protocols only need the presence of a "trusted" installation node [RFC6345], [RFC5191], or [I-D.kumar-dice-dtls-relay].
</old>
<new>
Normally, the network remains secure by not allowing the addition of new nodes. If a new node needs to be added to the network, the network is usually configured to allow the new node to join via an assisting node in the manner described in Section 7.1. If an existing node becomes lost, it is usually possible to re-key all other existing nodes to isolate the lost node to ensure that, should it be found again, it has to re-join as if it were a new node.
</new>
</RCC>



Nits:

Section 1.1=C2=A0

This applicability statement
=C2=A0 =C2=A0recommends more light weight security solutions and = specify the
=C2=A0 =C2=A0conditions under which these solutions are appropria= te.

Should be =E2=80=9Cspecifies=E2=80=9D instead of =E2=80=9Cspecify= =E2=80=9D. =C2=A0I=E2=80=99m also not sure what is meant by =E2=80=9Cconditions under which these solutions = are appropriate.=E2=80=9D =C2=A0Do
you mean light-weight as opposed to no security, or light-weight as opposed to heavy-weight. =C2=A0Or are you talking about condit= ions
under which different light-weight solutions are appropriate? From reading the rest of the draft, I would assume the last is what you mean.
<RCC>
I would reword as follows:

<old>
This applicability statement recommends more light weight security solutions and specify the conditions under which these solutions are appropriate.
</old>
<new>
This applicability statement recommends lighter weight security solutions appropriate for home and building environments and indicates why these solutions are appropriate.
</new>
</RCC>


I consider this document =C2=A0ready with issues.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email:=C2=A0catherine.me= adows@nrl.navy.mil 



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

--------------070408000005020808070301-- --------------ms030903090900070502060301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTA0MDcxNDQwNDlaMCMGCSqGSIb3DQEJBDEWBBR+Q1hLI9LCIrWwAfbCTN0fLWG3uDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQBt3hcNOBALkdJ9R5Zmlmo27JlhQmKxY4bx Sj/zPOxQbbvyuIXuDMY8REDHPKNt2i/S+WizzW1M0UjPMlxj+9g442ed+llbPB9MtY21D14T MnTSMtQbZ23XYsHMDnTEXZ/fziiN6ewrHh3uKjJ2bfdiqtzZX6I5B9p6bD/MHGcY6vYxA9WC H6fN9+LG8dr7O8mFHHqugFHbgN0XJfAqAGv4ebSdFFzhANeLmernG3r1NW3r9/ZR/BjtDcT6 KooPdzNlxIbOwCC1H4fFTiOFw0X4pNWM32yiZ2fLXX587at9wqdlW37FN+VLY4TjGlcaTAbr tzIxi+jiSOFT/IwRggGaAAAAAAAA --------------ms030903090900070502060301-- From nobody Tue Apr 7 07:42:08 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 5E7391B366E; Tue, 7 Apr 2015 07:42: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 WVhV0nFlWts1; Tue, 7 Apr 2015 07:41:54 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan38.extendcp.co.uk [176.32.230.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA441B3660; Tue, 7 Apr 2015 07:41:54 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.hi.local) by mailscan-g74.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YfUgk-0007bn-2G; Tue, 07 Apr 2015 15:41:14 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1YfUgi-0006UG-Cw; Tue, 07 Apr 2015 15:41:14 +0100 Received: from host86-156-208-9.range86-156.btcentralplus.com ([86.156.208.9] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1YfUgQ-0007KV-7F; Tue, 07 Apr 2015 15:40:54 +0100 Message-ID: <5523EC71.1020701@gridmerge.com> Date: Tue, 07 Apr 2015 15:40:49 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.all@tools.ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030903090900070502060301" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: Cc: Catherine Meadows Subject: Re: [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend) 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, 07 Apr 2015 14:42:03 -0000 This is a cryptographically signed message in MIME format. --------------ms030903090900070502060301 Content-Type: multipart/alternative; boundary="------------070408000005020808070301" This is a multi-part message in MIME format. --------------070408000005020808070301 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Catherine, In addition to Peter's comments, here are my comments inline, bracketed=20 by Robert On 06/04/2015 22:37, Catherine Meadows wrote: > I had the draft authors=E2=80=99 email address wrong on my last message= , so I=20 > am resending it. > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document gives recommendations for the use of RPL in home=20 > automation and building control, > that typically provide support such things as climate and lighting=20 > control. I reviewed a much earlier > version of this document, and I think this version is much improved in = > the way it scopes out the problem > and handles the security implications. The Security Considerations=20 > section in particular is very > thorough. There are a few improvements I would recommend, however: > > Section 4.1.8 Security > > You should give justifications for these choices of parameters as you = > give justifications for the > other parameters described in this draft. The parameters are in RFC 6550. Some explanation could be added, for=20 example: If RPL is used with secured messages, the following RPL security=20 parameter values are recommended to provide a basic level of security: o Counter Time Flag: T =3D '0': Do not use timestamp in the Counter = Field. Counters based on timestamps are typically more applicable to=20 industrial networks where strict timing synchronization between nodes is = often implemented. Home and building networks typically do not implement = such strict timing synchronization therefore a monotonically increasing=20 counter is more appropriate. o Algorithm =3D '0': Use Counter with Cipher Block Chaining Message = Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption=20 Standard (AES)-128. This is the only assigned mode at present. o Key Identifier Mode; KIM =3D '10': Use group key, Key Source=20 present, Key Index present. Given the relatively confined perimeter of a = home or building network, a group key is usually sufficient to protect=20 RPL messages sent between nodes. The use of the Key Source field allows=20 multiple group keys to be used within the network. o Security Level; LVL =3D 0: Use MAC-32. This is recommended as=20 integrity protection for RPL messages is the basic requirement.=20 Encryption is unlikely to be necessary given the relatively=20 non-confidential nature of RPL message payloads. > > Section 7.1 Security considerations during initial deployment > > New approaches to initial security deployment are being developed in > [I-D.kumar-dice-dtls-relay] and > [I-D.richardson-6tisch--security-6top]. They assume a partial > ordering of the nodes, such that unsecured nodes are added > sequentially with the restriction that a path between two secured > nodes exists which passes through secured nodes only. > > I found this a little hard to understand. When does a node pass from=20 > being unsecured to secured? Or does an unsecured node remain=20 > unsecured? If there is > a succinct way of saying this, it could go here. Since this is only=20 > describing new approaches that could potentially be applied, you would = not > want to go into a lot of detail. I would clarify as follows, in addition to Peter's suggestion: New approaches to initial security deployment are being developed in=20 [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top].=20 They assume a partial ordering of the nodes, such that unsecured nodes=20 are added sequentially with the restriction that a path between two=20 secured nodes exists which passes through secured nodes only. New approaches to initial security deployment are being developed in=20 [I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In = these drafts an already secured node at the perimeter of the network,=20 which is one hop away from an unsecured node wishing to access the=20 network, assists in transporting security and configuration traffic=20 between the unsecured node and the authenticator/commissioner. Once=20 secured and configured, the new node extends the perimeter of the=20 network in an "onion ring" fashion until all nodes have been secured and = configured. > > In the home, nodes can be visually inspected by the home owner > and simple measures like pushing buttons simultaneously on joint and= > joining devices is probably sufficient. > > I think this definitely needs to be clarified! You need to say what=20 > is being accomplished by pushing the buttons (device pairing)? I would clarify as follows, in addition to Peter's suggestion: In the home, nodes can be visually inspected by the home owner and=20 simple measures like pushing buttons simultaneously on joint and joining = devices is probably sufficient. In the home, nodes can be visually inspected by the home owner and a=20 simple procedure, e.g. pushing buttons simultaneously on an already=20 secured device and an unsecured joining device is usually sufficient to=20 ensure that the unsecured joining device is authenticated and configured = securely, and paired appropriately. > > 7.2 > > When nodes are lost, no additional security measures are needed, the > network remains secure as before by not allowing the addition of new= > nodes. > > I=E2=80=99m not sure what this means. Does it mean that if a node is l= ost,=20 > then it is treated as a =E2=80=9Cnew node=E2=80=9D if it reappears, and= is not allowed > to rejoin the network? > > New nodes can be added by using the same protocols used for > initial deployment. > > This came right after the sentence beginning =E2=80=9CWhen nodes are lo= st=E2=80=9D=20 > which said that new nodes are not added. That contradiction needs to > be reconciled. I=E2=80=99m also not sure what =E2=80=9Cusing the same = protocol=E2=80=9D=20 > means. Does it mean rerunning the protocol and rekeying all the=20 > nodes, or does > it mean using the features that protocol has for adding nodes? I would rewrite this somewhat as the intent is unclear. I believe the=20 intent is as follows: When nodes are lost, no additional security measures are needed, the=20 network remains secure as before by not allowing the addition of new=20 nodes. New nodes can be added by using the same protocols used for=20 initial deployment. Some protocols may need a state change to a subset=20 of the secured nodes, other protocols only need the presence of a=20 "trusted" installation node [RFC6345], [RFC5191], or=20 [I-D.kumar-dice-dtls-relay]. Normally, the network remains secure by not allowing the addition of new = nodes. If a new node needs to be added to the network, the network is=20 usually configured to allow the new node to join via an assisting node=20 in the manner described in Section 7.1. If an existing node becomes=20 lost, it is usually possible to re-key all other existing nodes to=20 isolate the lost node to ensure that, should it be found again, it has=20 to re-join as if it were a new node. > > > Nits: > > Section 1.1 > > This applicability statement > recommends more light weight security solutions and specify the > conditions under which these solutions are appropriate. > > Should be =E2=80=9Cspecifies=E2=80=9D instead of =E2=80=9Cspecify=E2=80= =9D. I=E2=80=99m also not sure what is=20 > meant by =E2=80=9Cconditions under which these solutions are appropriat= e.=E2=80=9D Do > you mean light-weight as opposed to no security, or light-weight as=20 > opposed to heavy-weight. Or are you talking about conditions > under which different light-weight solutions are appropriate? From=20 > reading the rest of the draft, I would assume the last is what you mean= =2E I would reword as follows: This applicability statement recommends more light weight security=20 solutions and specify the conditions under which these solutions are=20 appropriate. This applicability statement recommends lighter weight security=20 solutions appropriate for home and building environments and indicates=20 why these solutions are appropriate. > > > I consider this document ready with issues. > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil=20 > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------070408000005020808070301 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Catherine,

In addition to Peter's comments, here are my comments inline, bracketed by <RCC></RCC>

Robert

On 06/04/2015 22:37, Catherine Meadows= wrote:
I had the draft authors=E2=80=99 email address wrong on my last mes= sage, so I am resending it.

I have reviewed this document as part of the security directorate's=C2=A0
ongoing effort to review all IETF documents being processed by the=C2=A0
IESG. =C2=A0These comments were written primarily for the benefit= of the=C2=A0
security area directors. =C2=A0Document editors and WG chairs sho= uld treat=C2=A0
these comments just like any other last call comments.

This document gives recommendations for the use of RPL in home automation and building control,
that typically provide support such things as climate and lighting control. =C2=A0I reviewed a much earlier
version of this document, and I think this version is much improved in the way it scopes out the problem
and handles the security implications. =C2=A0The Security Considerations section in particular is very
thorough. =C2=A0There are a few improvements I would recommend, however:

Section 4.1.8 =C2=A0 Security

You should =C2=A0give justifications for these choices of paramet= ers as you give justifications for the
other parameters described in this draft.
<RCC>
The parameters are in RFC 6550. Some explanation could be added, for example:

<new>
If RPL is used with secured messages, the following RPL security parameter values are recommended to provide a basic level of security:

=C2=A0=C2=A0 o=C2=A0 Counter Time Flag: T =3D '0': Do not use timesta= mp in the Counter Field. Counters based on timestamps are typically more applicable to industrial networks where strict timing synchronization between nodes is often implemented. Home and building networks typically do not implement such strict timing synchronization therefore a monotonically increasing counter is more appropriate.

=C2=A0=C2=A0 o=C2=A0 Algorithm =3D '0': Use Counter with Cipher Block= Chaining Message Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption Standard (AES)-128. This is the only assigned mode at present.

=C2=A0=C2=A0 o=C2=A0 Key Identifier Mode; KIM =3D '10': Use group key= , Key Source present, Key Index present. Given the relatively confined perimeter of a home or building network, a group key is usually sufficient to protect RPL messages sent between nodes. The use of the Key Source field allows multiple group keys to be used within the network.

=C2=A0=C2=A0 o=C2=A0 Security Level; LVL =3D 0: Use MAC-32. This is r= ecommended as integrity protection for RPL messages is the basic requirement. Encryption is unlikely to be necessary given the relatively non-confidential nature of RPL message payloads.
</new>
</RCC>

Section 7.1 Security considerations during initial deployment
=
New approaches to initial security deployment are being developed in
=C2=A0 =C2=A0[I-D.kumar-dice-dtls-relay] and
=C2=A0 =C2=A0[I-D.richardson-6tisch--security-6top]. =C2=A0They a= ssume a partial
=C2=A0 =C2=A0ordering of the nodes, such that unsecured nodes are= added
=C2=A0 =C2=A0sequentially with the restriction that a path betwee= n two secured
=C2=A0 =C2=A0nodes exists which passes through secured nodes only= =2E

I found this a little hard to understand. =C2=A0When does a node = pass from being unsecured to secured? =C2=A0Or does an unsecured node remain unsecured? If there is
a succinct way of saying this, it could go here. =C2=A0Since this= is only describing new approaches that could potentially be applied, you would not
want to go into a lot of detail.
<RCC>
I would clarify as follows, in addition to Peter's suggestion:

<old>
New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assume a partial ordering of the nodes, such that unsecured nodes are added sequentially with the restriction that a path between two secured nodes exists which passes through secured nodes only.
</old>
<new>
New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In these drafts an already secured node at the perimeter of the network, which is one hop away from an unsecured node wishing to access the network, assists in transporting security and configuration traffic between the unsecured node and the authenticator/commissioner. Once secured and configured, the new node extends the perimeter of the network in an "onion ring" fashion until all nodes have been secured and configured.
</new>
</RCC>

In the home, nodes can be visually inspected by the home owner =C2=A0 =C2=A0and simple measures like pushing buttons simultaneou= sly on joint and
=C2=A0 =C2=A0joining devices is probably sufficient.

I think this definitely needs to be clarified! =C2=A0You need to = say what is being accomplished by pushing the buttons (device pairing)?
<RCC>
I would clarify as follows, in addition to Peter's suggestion:

<old>
In the home, nodes can be visually inspected by the home owner and simple measures like pushing buttons simultaneously on joint and joining devices is probably sufficient.
</old>
<new>
In the home, nodes can be visually inspected by the home owner and a simple procedure, e.g. pushing buttons simultaneously on an already secured device and an unsecured joining device is usually sufficient to ensure that the unsecured joining device is authenticated and configured securely, and paired appropriately.
</new>
</RCC>

7.2

When nodes are lost, no additional security measures are needed, the
=C2=A0 =C2=A0network remains secure as before by not allowing the= addition of new
=C2=A0 =C2=A0nodes.

I=E2=80=99m not sure what this means. =C2=A0Does it mean that if = a node is lost, then it is treated as a =E2=80=9Cnew node=E2=80=9D if it re= appears, and is not allowed
to rejoin the network?

New nodes can be added by using the same protocols used for
=C2=A0 =C2=A0initial deployment.

This came right after the sentence beginning =E2=80=9CWhen nodes = are lost=E2=80=9D which said that new nodes are not added. =C2=A0That= contradiction needs to
be reconciled. =C2=A0I=E2=80=99m also not sure what =E2=80=9Cusin= g the same protocol=E2=80=9D means. =C2=A0Does it mean rerunning the protocol and rekeying all= the nodes, or does
it mean using the features that protocol has for adding nodes?
<RCC>
I would rewrite this somewhat as the intent is unclear. I believe the intent is as follows:

<old>
When nodes are lost, no additional security measures are needed, the network remains secure as before by not allowing the addition of new nodes. New nodes can be added by using the same protocols used for initial deployment.=C2=A0 Some protocols may need a state change to a= subset of the secured nodes, other protocols only need the presence of a "trusted" installation node [RFC6345], [RFC5191], or [I-D.kumar-dice-dtls-relay].
</old>
<new>
Normally, the network remains secure by not allowing the addition of new nodes. If a new node needs to be added to the network, the network is usually configured to allow the new node to join via an assisting node in the manner described in Section 7.1. If an existing node becomes lost, it is usually possible to re-key all other existing nodes to isolate the lost node to ensure that, should it be found again, it has to re-join as if it were a new node.
</new>
</RCC>



Nits:

Section 1.1=C2=A0

This applicability statement
=C2=A0 =C2=A0recommends more light weight security solutions and = specify the
=C2=A0 =C2=A0conditions under which these solutions are appropria= te.

Should be =E2=80=9Cspecifies=E2=80=9D instead of =E2=80=9Cspecify= =E2=80=9D. =C2=A0I=E2=80=99m also not sure what is meant by =E2=80=9Cconditions under which these solutions = are appropriate.=E2=80=9D =C2=A0Do
you mean light-weight as opposed to no security, or light-weight as opposed to heavy-weight. =C2=A0Or are you talking about condit= ions
under which different light-weight solutions are appropriate? From reading the rest of the draft, I would assume the last is what you mean.
<RCC>
I would reword as follows:

<old>
This applicability statement recommends more light weight security solutions and specify the conditions under which these solutions are appropriate.
</old>
<new>
This applicability statement recommends lighter weight security solutions appropriate for home and building environments and indicates why these solutions are appropriate.
</new>
</RCC>


I consider this document =C2=A0ready with issues.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email:=C2=A0catherine.me= adows@nrl.navy.mil 



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

--------------070408000005020808070301-- --------------ms030903090900070502060301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTA0MDcxNDQwNDlaMCMGCSqGSIb3DQEJBDEWBBR+Q1hLI9LCIrWwAfbCTN0fLWG3uDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQBt3hcNOBALkdJ9R5Zmlmo27JlhQmKxY4bx Sj/zPOxQbbvyuIXuDMY8REDHPKNt2i/S+WizzW1M0UjPMlxj+9g442ed+llbPB9MtY21D14T MnTSMtQbZ23XYsHMDnTEXZ/fziiN6ewrHh3uKjJ2bfdiqtzZX6I5B9p6bD/MHGcY6vYxA9WC H6fN9+LG8dr7O8mFHHqugFHbgN0XJfAqAGv4ebSdFFzhANeLmernG3r1NW3r9/ZR/BjtDcT6 KooPdzNlxIbOwCC1H4fFTiOFw0X4pNWM32yiZ2fLXX587at9wqdlW37FN+VLY4TjGlcaTAbr tzIxi+jiSOFT/IwRggGaAAAAAAAA --------------ms030903090900070502060301-- From nobody Tue Apr 7 14:53:56 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 32B661A92B1; Tue, 7 Apr 2015 14:53:55 -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 f9SPKwaIFgoQ; Tue, 7 Apr 2015 14:53:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F40471A92AA; Tue, 7 Apr 2015 14:53:53 -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: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407215353.13470.88674.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 14:53:53 -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] Barry Leiba's No Objection on draft-ietf-roll-applicability-home-building-09: (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: Tue, 07 Apr 2015 21:53:55 -0000 Barry Leiba has entered the following ballot position for draft-ietf-roll-applicability-home-building-09: 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I like this document a lot; thanks for the work on it. From nobody Wed Apr 8 16:34: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 F154E1ACD75; Wed, 8 Apr 2015 16:34:09 -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 5raHxR9BMDrk; Wed, 8 Apr 2015 16:34:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1761ACD41; Wed, 8 Apr 2015 16:34:08 -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: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 16:34:08 -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-09: (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 Apr 2015 23:34:10 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-roll-applicability-home-building-09: 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Please correct me if I'm getting this wrong, I honestly may have forgotten the plan. My understanding was that RPL and RFC 7416 etc. were approved on the basis that you needed to get to specific applications of RPL before you could sensibly specify interoperable security with automated key management (AKM) as is clearly required by BCP107 and as has been discussed between security ADs and the ROLL WG numerous times. This is going back to the 2010 discuss from Tim Polk that I inherited in 2011, hence me being uncertain if I remember the plan for sure;-) In any case it seems to me that this draft also doesn't get us to the point where we have a defined way to do AKM (Again, sigh.) I also have a set of comments on that below that I won't make into specific discuss points (at least until we figure out or re-discover the plan). So, with that context, and with real regrets for sounding like an old and broken record, the discuss point: why is this not the ROLL WG draft where we finally get to specify AKM for RPL? If your answer is that this is just an applicablilty statement then I'll ask why it's going for proposed standard, and when to finally expect the AKM spec for RPL (for this application). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 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 Thu Apr 9 01:42: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 EFCC61A8BB2; Thu, 9 Apr 2015 01:42:26 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 37S1bbquokGt; Thu, 9 Apr 2015 01:42:24 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAF21AD359; Thu, 9 Apr 2015 01:42:22 -0700 (PDT) Received: from roundcube.xs4all.nl ([194.109.20.204]) by smtp-cloud6.xs4all.net with ESMTP id DkiL1q0084QBLo201kiLx9; Thu, 09 Apr 2015 10:42:20 +0200 Received: from [2001:983:a264:1:f017:e82:631f:b88d] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 09 Apr 2015 10:42:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 09 Apr 2015 10:42:20 +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: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> Message-ID: X-Sender: stokcons@xs4all.nl (ZeSPPCO+q2E93otpI7pT97kYNQTuJ0o/) 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 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: Thu, 09 Apr 2015 08:42:27 -0000 Hi Stephen, thanks for the comments. There is one comment that I should like to react to before the others: > - 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. > I have the same fear. BUT multicast will be used and having a secure protocol is an urgent wish. I understand the reasons why the current draft will not make it. However, I know that other people are working on better sequels. I think this multicast security is important. Do you think I should add text to emphasize my opinion and encourage sequels to [I-D.keoh-dice-multicast-security] ? Peter Stephen Farrell schreef op 2015-04-09 01:34: > Stephen Farrell has entered the following ballot position for > draft-ietf-roll-applicability-home-building-09: 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 > http://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: > http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > Please correct me if I'm getting this wrong, I honestly may > have forgotten the plan. My understanding was that RPL and RFC > 7416 etc. were approved on the basis that you needed to get to > specific applications of RPL before you could sensibly specify > interoperable security with automated key management (AKM) as > is clearly required by BCP107 and as has been discussed > between security ADs and the ROLL WG numerous times. This is > going back to the 2010 discuss from Tim Polk that I inherited > in 2011, hence me being uncertain if I remember the plan for > sure;-) In any case it seems to me that this draft also > doesn't get us to the point where we have a defined way to do > AKM (Again, sigh.) I also have a set of comments on that below > that I won't make into specific discuss points (at least until > we figure out or re-discover the plan). > > So, with that context, and with real regrets for sounding like > an old and broken record, the discuss point: why is this not > the ROLL WG draft where we finally get to specify AKM for RPL? > If your answer is that this is just an applicablilty statement > then I'll ask why it's going for proposed standard, and when > to finally expect the AKM spec for RPL (for this application). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 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.) > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Apr 9 02:59: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 B15B81B2D7F; Thu, 9 Apr 2015 02:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ME5SgddViYmE; Thu, 9 Apr 2015 02:59:20 -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 4E7821B2D6B; Thu, 9 Apr 2015 02:59:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 175C7BEED; Thu, 9 Apr 2015 10:59:19 +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 2zE4RUVDtgNX; Thu, 9 Apr 2015 10:59:17 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ED075BEF6; Thu, 9 Apr 2015 10:59:12 +0100 (IST) Message-ID: <55264D70.60106@cs.tcd.ie> Date: Thu, 09 Apr 2015 10:59:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks References: <20150408233408.4123.3118.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, 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: 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 Apr 2015 09:59:22 -0000 Hiya, On 09/04/15 09:42, peter van der Stok wrote: > Hi Stephen, > > thanks for the comments. > There is one comment that I should like to react to before the others: > >> - 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. >> > > I have the same fear. BUT multicast will be used and having a secure > protocol is an urgent wish. That's clear. What's not clear is whether or not there is a way to meet that wish at the TLS layer. Seems that there may not be is my guess at the DICE WG current thinking. > I understand the reasons why the current draft will not make it. > However, I know that other people are working on better sequels. > I think this multicast security is important. > Do you think I should add text to emphasize my opinion and encourage > sequels to [I-D.keoh-dice-multicast-security] ? That could be fine, but if you do, please consider that the solution may need to use security primitives above the transport layer, e.g. perhaps in CoAP payload. Cheers, S. > > Peter > > > Stephen Farrell schreef op 2015-04-09 01:34: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-roll-applicability-home-building-09: 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 http://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: >> http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ >> >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> Please correct me if I'm getting this wrong, I honestly may >> have forgotten the plan. My understanding was that RPL and RFC >> 7416 etc. were approved on the basis that you needed to get to >> specific applications of RPL before you could sensibly specify >> interoperable security with automated key management (AKM) as >> is clearly required by BCP107 and as has been discussed >> between security ADs and the ROLL WG numerous times. This is >> going back to the 2010 discuss from Tim Polk that I inherited >> in 2011, hence me being uncertain if I remember the plan for >> sure;-) In any case it seems to me that this draft also >> doesn't get us to the point where we have a defined way to do >> AKM (Again, sigh.) I also have a set of comments on that below >> that I won't make into specific discuss points (at least until >> we figure out or re-discover the plan). >> >> So, with that context, and with real regrets for sounding like >> an old and broken record, the discuss point: why is this not >> the ROLL WG draft where we finally get to specify AKM for RPL? >> If your answer is that this is just an applicablilty statement >> then I'll ask why it's going for proposed standard, and when >> to finally expect the AKM spec for RPL (for this application). >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - 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.) >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From nobody Thu Apr 9 07:10: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 327651A9078; Wed, 8 Apr 2015 15:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 KdOKyd50Fq-9; Wed, 8 Apr 2015 15:29:37 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5B51A9076; Wed, 8 Apr 2015 15:29:36 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t38MTYpP025503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Apr 2015 18:29:35 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Catherine Meadows In-Reply-To: <5523EC71.1020701@gridmerge.com> Date: Wed, 8 Apr 2015 18:29:34 -0400 Message-Id: <29DD884A-AA96-4614-B81B-A8936FD5E6B5@nrl.navy.mil> References: <5523EC71.1020701@gridmerge.com> To: Routing Over Low power and Lossy networks , draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:10:40 -0700 Cc: Catherine Meadows , iesg@ietf.org, secdir@ietf.org Subject: Re: [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend) 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 Apr 2015 22:29:41 -0000 --Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks much, Robert and Peter! These make things much clearer. Cathy Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil On Apr 7, 2015, at 10:40 AM, Robert Cragie = wrote: > Hi Catherine, >=20 > In addition to Peter's comments, here are my comments inline, = bracketed by >=20 > Robert >=20 > On 06/04/2015 22:37, Catherine Meadows wrote: >> I had the draft authors=92 email address wrong on my last message, so = I am resending it. >>=20 >> I have reviewed this document as part of the security directorate's=20= >> ongoing effort to review all IETF documents being processed by the=20 >> IESG. These comments were written primarily for the benefit of the=20= >> security area directors. Document editors and WG chairs should treat=20= >> these comments just like any other last call comments. >>=20 >> This document gives recommendations for the use of RPL in home = automation and building control, >> that typically provide support such things as climate and lighting = control. I reviewed a much earlier >> version of this document, and I think this version is much improved = in the way it scopes out the problem >> and handles the security implications. The Security Considerations = section in particular is very >> thorough. There are a few improvements I would recommend, however: >>=20 >> Section 4.1.8 Security >>=20 >> You should give justifications for these choices of parameters as = you give justifications for the >> other parameters described in this draft. > > The parameters are in RFC 6550. Some explanation could be added, for = example: >=20 > > If RPL is used with secured messages, the following RPL security = parameter values are recommended to provide a basic level of security: >=20 > o Counter Time Flag: T =3D '0': Do not use timestamp in the = Counter Field. Counters based on timestamps are typically more = applicable to industrial networks where strict timing synchronization = between nodes is often implemented. Home and building networks typically = do not implement such strict timing synchronization therefore a = monotonically increasing counter is more appropriate. >=20 > o Algorithm =3D '0': Use Counter with Cipher Block Chaining = Message Authentication Code (CBC-MAC Mode) (CCM) with Advanced = Encryption Standard (AES)-128. This is the only assigned mode at = present. >=20 > o Key Identifier Mode; KIM =3D '10': Use group key, Key Source = present, Key Index present. Given the relatively confined perimeter of a = home or building network, a group key is usually sufficient to protect = RPL messages sent between nodes. The use of the Key Source field allows = multiple group keys to be used within the network. >=20 > o Security Level; LVL =3D 0: Use MAC-32. This is recommended as = integrity protection for RPL messages is the basic requirement. = Encryption is unlikely to be necessary given the relatively = non-confidential nature of RPL message payloads. > > >>=20 >> Section 7.1 Security considerations during initial deployment >>=20 >> New approaches to initial security deployment are being developed in >> [I-D.kumar-dice-dtls-relay] and >> [I-D.richardson-6tisch--security-6top]. They assume a partial >> ordering of the nodes, such that unsecured nodes are added >> sequentially with the restriction that a path between two secured >> nodes exists which passes through secured nodes only. >>=20 >> I found this a little hard to understand. When does a node pass from = being unsecured to secured? Or does an unsecured node remain unsecured? = If there is >> a succinct way of saying this, it could go here. Since this is only = describing new approaches that could potentially be applied, you would = not >> want to go into a lot of detail.=20 > > I would clarify as follows, in addition to Peter's suggestion: >=20 > > New approaches to initial security deployment are being developed in = [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. = They assume a partial ordering of the nodes, such that unsecured nodes = are added sequentially with the restriction that a path between two = secured nodes exists which passes through secured nodes only. > > > New approaches to initial security deployment are being developed in = [I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In = these drafts an already secured node at the perimeter of the network, = which is one hop away from an unsecured node wishing to access the = network, assists in transporting security and configuration traffic = between the unsecured node and the authenticator/commissioner. Once = secured and configured, the new node extends the perimeter of the = network in an "onion ring" fashion until all nodes have been secured and = configured. > > >>=20 >> In the home, nodes can be visually inspected by the home owner >> and simple measures like pushing buttons simultaneously on joint = and >> joining devices is probably sufficient. >>=20 >> I think this definitely needs to be clarified! You need to say what = is being accomplished by pushing the buttons (device pairing)? > > I would clarify as follows, in addition to Peter's suggestion: >=20 > > In the home, nodes can be visually inspected by the home owner and = simple measures like pushing buttons simultaneously on joint and joining = devices is probably sufficient.=20 > > > In the home, nodes can be visually inspected by the home owner and a = simple procedure, e.g. pushing buttons simultaneously on an already = secured device and an unsecured joining device is usually sufficient to = ensure that the unsecured joining device is authenticated and configured = securely, and paired appropriately. > =20 > >>=20 >> 7.2 >>=20 >> When nodes are lost, no additional security measures are needed, the >> network remains secure as before by not allowing the addition of = new >> nodes. >>=20 >> I=92m not sure what this means. Does it mean that if a node is lost, = then it is treated as a =93new node=94 if it reappears, and is not = allowed >> to rejoin the network? >>=20 >> New nodes can be added by using the same protocols used for >> initial deployment. >>=20 >> This came right after the sentence beginning =93When nodes are lost=94 = which said that new nodes are not added. That contradiction needs to >> be reconciled. I=92m also not sure what =93using the same protocol=94 = means. Does it mean rerunning the protocol and rekeying all the nodes, = or does >> it mean using the features that protocol has for adding nodes? > > I would rewrite this somewhat as the intent is unclear. I believe the = intent is as follows: >=20 > > When nodes are lost, no additional security measures are needed, the = network remains secure as before by not allowing the addition of new = nodes. New nodes can be added by using the same protocols used for = initial deployment. Some protocols may need a state change to a subset = of the secured nodes, other protocols only need the presence of a = "trusted" installation node [RFC6345], [RFC5191], or = [I-D.kumar-dice-dtls-relay]. > > > Normally, the network remains secure by not allowing the addition of = new nodes. If a new node needs to be added to the network, the network = is usually configured to allow the new node to join via an assisting = node in the manner described in Section 7.1. If an existing node becomes = lost, it is usually possible to re-key all other existing nodes to = isolate the lost node to ensure that, should it be found again, it has = to re-join as if it were a new node. > > >=20 >>=20 >>=20 >> Nits: >>=20 >> Section 1.1=20 >>=20 >> This applicability statement >> recommends more light weight security solutions and specify the >> conditions under which these solutions are appropriate. >>=20 >> Should be =93specifies=94 instead of =93specify=94. I=92m also not = sure what is meant by =93conditions under which these solutions are = appropriate.=94 Do >> you mean light-weight as opposed to no security, or light-weight as = opposed to heavy-weight. Or are you talking about conditions >> under which different light-weight solutions are appropriate? =46rom = reading the rest of the draft, I would assume the last is what you mean. > > I would reword as follows: >=20 > > This applicability statement recommends more light weight security = solutions and specify the conditions under which these solutions are = appropriate. > > > This applicability statement recommends lighter weight security = solutions appropriate for home and building environments and indicates = why these solutions are appropriate. > > >>=20 >>=20 >> I consider this document ready with issues. >>=20 >> Catherine Meadows >> Naval Research Laboratory >> Code 5543 >> 4555 Overlook Ave., S.W. >> Washington DC, 20375 >> phone: 202-767-3490 >> fax: 202-404-7942 >> email: catherine.meadows@nrl.navy.mil >>=20 >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 --Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks = much, Robert and Peter!

These make things much = clearer.

Cathy


Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

On Apr 7, 2015, at 10:40 AM, Robert Cragie <robert.cragie@gridmerge.com> wrote:

=20 =20
Hi Catherine,

In addition to Peter's comments, here are my comments inline, bracketed by <RCC></RCC>

Robert

On 06/04/2015 22:37, Catherine = Meadows wrote:
I had the draft authors=92 email address wrong on my last message, so I am resending it.

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the = benefit of the 
security area directors.  Document editors and WG chairs = should treat 
these comments just like any other last call comments.

This document gives recommendations for the use of RPL in home automation and building control,
that typically provide support such things as climate and lighting control.  I reviewed a much earlier
version of this document, and I think this version is much improved in the way it scopes out the problem
and handles the security implications.  The Security Considerations section in particular is very
thorough.  There are a few improvements I would recommend, however:

Section 4.1.8   Security

You should  give justifications for these choices of = parameters as you give justifications for the
other parameters described in this draft.
<RCC>
The parameters are in RFC 6550. Some explanation could be added, for example:

<new>
If RPL is used with secured messages, the following RPL security parameter values are recommended to provide a basic level of security:

   o  Counter Time Flag: T =3D '0': Do not use = timestamp in the Counter Field. Counters based on timestamps are typically more applicable to industrial networks where strict timing synchronization between nodes is often implemented. Home and building networks typically do not implement such strict timing synchronization therefore a monotonically increasing counter is more appropriate.

   o  Algorithm =3D '0': Use Counter with Cipher = Block Chaining Message Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption Standard (AES)-128. This is the only assigned mode at present.

   o  Key Identifier Mode; KIM =3D '10': Use group = key, Key Source present, Key Index present. Given the relatively confined perimeter of a home or building network, a group key is usually sufficient to protect RPL messages sent between nodes. The use of the Key Source field allows multiple group keys to be used within the network.

   o  Security Level; LVL =3D 0: Use MAC-32. This is = recommended as integrity protection for RPL messages is the basic requirement. Encryption is unlikely to be necessary given the relatively non-confidential nature of RPL message payloads.
</new>
</RCC>

Section 7.1 Security considerations during initial = deployment

New approaches to initial security deployment are being developed in
   [I-D.kumar-dice-dtls-relay] and
   [I-D.richardson-6tisch--security-6top].  They = assume a partial
   ordering of the nodes, such that unsecured nodes = are added
   sequentially with the restriction that a path = between two secured
   nodes exists which passes through secured nodes = only.

I found this a little hard to understand.  When does a node = pass from being unsecured to secured?  Or does an unsecured node remain unsecured? If there is
a succinct way of saying this, it could go here.  Since = this is only describing new approaches that could potentially be applied, you would not
want to go into a lot of detail.
<RCC>
I would clarify as follows, in addition to Peter's suggestion:

<old>
New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assume a partial ordering of the nodes, such that unsecured nodes are added sequentially with the restriction that a path between two secured nodes exists which passes through secured nodes only.
</old>
<new>
New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In these drafts an already secured node at the perimeter of the network, which is one hop away from an unsecured node wishing to access the network, assists in transporting security and configuration traffic between the unsecured node and the authenticator/commissioner. Once secured and configured, the new node extends the perimeter of the network in an "onion ring" fashion until all nodes have been secured and configured.
</new>
</RCC>

In the home, nodes can be visually inspected by the home = owner
   and simple measures like pushing buttons = simultaneously on joint and
   joining devices is probably sufficient.

I think this definitely needs to be clarified!  You need to = say what is being accomplished by pushing the buttons (device pairing)?
<RCC>
I would clarify as follows, in addition to Peter's suggestion:

<old>
In the home, nodes can be visually inspected by the home owner and simple measures like pushing buttons simultaneously on joint and joining devices is probably sufficient.
</old>
<new>
In the home, nodes can be visually inspected by the home owner and a simple procedure, e.g. pushing buttons simultaneously on an already secured device and an unsecured joining device is usually sufficient to ensure that the unsecured joining device is authenticated and configured securely, and paired appropriately.
</new>
</RCC>

7.2

When nodes are lost, no additional security measures are needed, the
   network remains secure as before by not allowing = the addition of new
   nodes.

I=92m not sure what this means.  Does it mean that if a = node is lost, then it is treated as a =93new node=94 if it reappears, = and is not allowed
to rejoin the network?

New nodes can be added by using the same protocols used for
   initial deployment.

This came right after the sentence beginning =93When nodes are lost=94 which said that new nodes are not added.  That contradiction needs to
be reconciled.  I=92m also not sure what =93using the same = protocol=94 means.  Does it mean rerunning the protocol and rekeying = all the nodes, or does
it mean using the features that protocol has for adding = nodes?
<RCC>
I would rewrite this somewhat as the intent is unclear. I believe the intent is as follows:

<old>
When nodes are lost, no additional security measures are needed, the network remains secure as before by not allowing the addition of new nodes. New nodes can be added by using the same protocols used for initial deployment.  Some protocols may need a state change to = a subset of the secured nodes, other protocols only need the presence of a "trusted" installation node [RFC6345], [RFC5191], or [I-D.kumar-dice-dtls-relay].
</old>
<new>
Normally, the network remains secure by not allowing the addition of new nodes. If a new node needs to be added to the network, the network is usually configured to allow the new node to join via an assisting node in the manner described in Section 7.1. If an existing node becomes lost, it is usually possible to re-key all other existing nodes to isolate the lost node to ensure that, should it be found again, it has to re-join as if it were a new node.
</new>
</RCC>



Nits:

Section 1.1 

This applicability statement
   recommends more light weight security solutions and = specify the
   conditions under which these solutions are = appropriate.

Should be =93specifies=94 instead of =93specify=94.  I=92m = also not sure what is meant by =93conditions under which these solutions are appropriate.=94  Do
you mean light-weight as opposed to no security, or light-weight as opposed to heavy-weight.  Or are you talking about = conditions
under which different light-weight solutions are appropriate? =46rom reading the rest of the draft, I would assume the last is what you mean.
<RCC>
I would reword as follows:

<old>
This applicability statement recommends more light weight security solutions and specify the conditions under which these solutions are appropriate.
</old>
<new>
This applicability statement recommends lighter weight security solutions appropriate for home and building environments and indicates why these solutions are appropriate.
</new>
</RCC>


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m=
ailman/listinfo/roll


= --Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618-- From nobody Thu Apr 9 07:10:42 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 679AA1A907D; Wed, 8 Apr 2015 15:30:22 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416321A907C for ; Wed, 8 Apr 2015 15:30:22 -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, HTML_MESSAGE=0.001] 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 B1L2L1bpaEez for ; Wed, 8 Apr 2015 15:30:18 -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 6B56F1A9078 for ; Wed, 8 Apr 2015 15:30:18 -0700 (PDT) Received: from mx0.ccs.nrl.navy.mil ([2001:480:20:118:118::211]:59736 helo=ccs.nrl.navy.mil) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfyUB-0002l1-Qr for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Wed, 08 Apr 2015 15:30:18 -0700 Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t38MTYpP025503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Apr 2015 18:29:35 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Catherine Meadows In-Reply-To: <5523EC71.1020701@gridmerge.com> Date: Wed, 8 Apr 2015 18:29:34 -0400 Message-Id: <29DD884A-AA96-4614-B81B-A8936FD5E6B5@nrl.navy.mil> References: <5523EC71.1020701@gridmerge.com> To: Routing Over Low power and Lossy networks , draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email X-Helo-Check-Failed: Verification failed for HELO ccs.nrl.navy.mil X-SA-Exim-Connect-IP: 2001:480:20:118:118::211 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-SA-Exim-Mail-From: catherine.meadows@nrl.navy.mil 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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150408223018.6B56F1A9078@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 15:30:18 -0700 (PDT) Resent-From: catherine.meadows@nrl.navy.mil Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:10:40 -0700 Cc: Catherine Meadows , iesg@ietf.org, secdir@ietf.org Subject: Re: [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend) 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 Apr 2015 22:30:22 -0000 --Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks much, Robert and Peter! These make things much clearer. Cathy Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil On Apr 7, 2015, at 10:40 AM, Robert Cragie = wrote: > Hi Catherine, >=20 > In addition to Peter's comments, here are my comments inline, = bracketed by >=20 > Robert >=20 > On 06/04/2015 22:37, Catherine Meadows wrote: >> I had the draft authors=92 email address wrong on my last message, so = I am resending it. >>=20 >> I have reviewed this document as part of the security directorate's=20= >> ongoing effort to review all IETF documents being processed by the=20 >> IESG. These comments were written primarily for the benefit of the=20= >> security area directors. Document editors and WG chairs should treat=20= >> these comments just like any other last call comments. >>=20 >> This document gives recommendations for the use of RPL in home = automation and building control, >> that typically provide support such things as climate and lighting = control. I reviewed a much earlier >> version of this document, and I think this version is much improved = in the way it scopes out the problem >> and handles the security implications. The Security Considerations = section in particular is very >> thorough. There are a few improvements I would recommend, however: >>=20 >> Section 4.1.8 Security >>=20 >> You should give justifications for these choices of parameters as = you give justifications for the >> other parameters described in this draft. > > The parameters are in RFC 6550. Some explanation could be added, for = example: >=20 > > If RPL is used with secured messages, the following RPL security = parameter values are recommended to provide a basic level of security: >=20 > o Counter Time Flag: T =3D '0': Do not use timestamp in the = Counter Field. Counters based on timestamps are typically more = applicable to industrial networks where strict timing synchronization = between nodes is often implemented. Home and building networks typically = do not implement such strict timing synchronization therefore a = monotonically increasing counter is more appropriate. >=20 > o Algorithm =3D '0': Use Counter with Cipher Block Chaining = Message Authentication Code (CBC-MAC Mode) (CCM) with Advanced = Encryption Standard (AES)-128. This is the only assigned mode at = present. >=20 > o Key Identifier Mode; KIM =3D '10': Use group key, Key Source = present, Key Index present. Given the relatively confined perimeter of a = home or building network, a group key is usually sufficient to protect = RPL messages sent between nodes. The use of the Key Source field allows = multiple group keys to be used within the network. >=20 > o Security Level; LVL =3D 0: Use MAC-32. This is recommended as = integrity protection for RPL messages is the basic requirement. = Encryption is unlikely to be necessary given the relatively = non-confidential nature of RPL message payloads. > > >>=20 >> Section 7.1 Security considerations during initial deployment >>=20 >> New approaches to initial security deployment are being developed in >> [I-D.kumar-dice-dtls-relay] and >> [I-D.richardson-6tisch--security-6top]. They assume a partial >> ordering of the nodes, such that unsecured nodes are added >> sequentially with the restriction that a path between two secured >> nodes exists which passes through secured nodes only. >>=20 >> I found this a little hard to understand. When does a node pass from = being unsecured to secured? Or does an unsecured node remain unsecured? = If there is >> a succinct way of saying this, it could go here. Since this is only = describing new approaches that could potentially be applied, you would = not >> want to go into a lot of detail.=20 > > I would clarify as follows, in addition to Peter's suggestion: >=20 > > New approaches to initial security deployment are being developed in = [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. = They assume a partial ordering of the nodes, such that unsecured nodes = are added sequentially with the restriction that a path between two = secured nodes exists which passes through secured nodes only. > > > New approaches to initial security deployment are being developed in = [I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In = these drafts an already secured node at the perimeter of the network, = which is one hop away from an unsecured node wishing to access the = network, assists in transporting security and configuration traffic = between the unsecured node and the authenticator/commissioner. Once = secured and configured, the new node extends the perimeter of the = network in an "onion ring" fashion until all nodes have been secured and = configured. > > >>=20 >> In the home, nodes can be visually inspected by the home owner >> and simple measures like pushing buttons simultaneously on joint = and >> joining devices is probably sufficient. >>=20 >> I think this definitely needs to be clarified! You need to say what = is being accomplished by pushing the buttons (device pairing)? > > I would clarify as follows, in addition to Peter's suggestion: >=20 > > In the home, nodes can be visually inspected by the home owner and = simple measures like pushing buttons simultaneously on joint and joining = devices is probably sufficient.=20 > > > In the home, nodes can be visually inspected by the home owner and a = simple procedure, e.g. pushing buttons simultaneously on an already = secured device and an unsecured joining device is usually sufficient to = ensure that the unsecured joining device is authenticated and configured = securely, and paired appropriately. > =20 > >>=20 >> 7.2 >>=20 >> When nodes are lost, no additional security measures are needed, the >> network remains secure as before by not allowing the addition of = new >> nodes. >>=20 >> I=92m not sure what this means. Does it mean that if a node is lost, = then it is treated as a =93new node=94 if it reappears, and is not = allowed >> to rejoin the network? >>=20 >> New nodes can be added by using the same protocols used for >> initial deployment. >>=20 >> This came right after the sentence beginning =93When nodes are lost=94 = which said that new nodes are not added. That contradiction needs to >> be reconciled. I=92m also not sure what =93using the same protocol=94 = means. Does it mean rerunning the protocol and rekeying all the nodes, = or does >> it mean using the features that protocol has for adding nodes? > > I would rewrite this somewhat as the intent is unclear. I believe the = intent is as follows: >=20 > > When nodes are lost, no additional security measures are needed, the = network remains secure as before by not allowing the addition of new = nodes. New nodes can be added by using the same protocols used for = initial deployment. Some protocols may need a state change to a subset = of the secured nodes, other protocols only need the presence of a = "trusted" installation node [RFC6345], [RFC5191], or = [I-D.kumar-dice-dtls-relay]. > > > Normally, the network remains secure by not allowing the addition of = new nodes. If a new node needs to be added to the network, the network = is usually configured to allow the new node to join via an assisting = node in the manner described in Section 7.1. If an existing node becomes = lost, it is usually possible to re-key all other existing nodes to = isolate the lost node to ensure that, should it be found again, it has = to re-join as if it were a new node. > > >=20 >>=20 >>=20 >> Nits: >>=20 >> Section 1.1=20 >>=20 >> This applicability statement >> recommends more light weight security solutions and specify the >> conditions under which these solutions are appropriate. >>=20 >> Should be =93specifies=94 instead of =93specify=94. I=92m also not = sure what is meant by =93conditions under which these solutions are = appropriate.=94 Do >> you mean light-weight as opposed to no security, or light-weight as = opposed to heavy-weight. Or are you talking about conditions >> under which different light-weight solutions are appropriate? =46rom = reading the rest of the draft, I would assume the last is what you mean. > > I would reword as follows: >=20 > > This applicability statement recommends more light weight security = solutions and specify the conditions under which these solutions are = appropriate. > > > This applicability statement recommends lighter weight security = solutions appropriate for home and building environments and indicates = why these solutions are appropriate. > > >>=20 >>=20 >> I consider this document ready with issues. >>=20 >> Catherine Meadows >> Naval Research Laboratory >> Code 5543 >> 4555 Overlook Ave., S.W. >> Washington DC, 20375 >> phone: 202-767-3490 >> fax: 202-404-7942 >> email: catherine.meadows@nrl.navy.mil >>=20 >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 --Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks = much, Robert and Peter!

These make things much = clearer.

Cathy


Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

On Apr 7, 2015, at 10:40 AM, Robert Cragie <robert.cragie@gridmerge.com> wrote:

=20 =20
Hi Catherine,

In addition to Peter's comments, here are my comments inline, bracketed by <RCC></RCC>

Robert

On 06/04/2015 22:37, Catherine = Meadows wrote:
I had the draft authors=92 email address wrong on my last message, so I am resending it.

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the = benefit of the 
security area directors.  Document editors and WG chairs = should treat 
these comments just like any other last call comments.

This document gives recommendations for the use of RPL in home automation and building control,
that typically provide support such things as climate and lighting control.  I reviewed a much earlier
version of this document, and I think this version is much improved in the way it scopes out the problem
and handles the security implications.  The Security Considerations section in particular is very
thorough.  There are a few improvements I would recommend, however:

Section 4.1.8   Security

You should  give justifications for these choices of = parameters as you give justifications for the
other parameters described in this draft.
<RCC>
The parameters are in RFC 6550. Some explanation could be added, for example:

<new>
If RPL is used with secured messages, the following RPL security parameter values are recommended to provide a basic level of security:

   o  Counter Time Flag: T =3D '0': Do not use = timestamp in the Counter Field. Counters based on timestamps are typically more applicable to industrial networks where strict timing synchronization between nodes is often implemented. Home and building networks typically do not implement such strict timing synchronization therefore a monotonically increasing counter is more appropriate.

   o  Algorithm =3D '0': Use Counter with Cipher = Block Chaining Message Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption Standard (AES)-128. This is the only assigned mode at present.

   o  Key Identifier Mode; KIM =3D '10': Use group = key, Key Source present, Key Index present. Given the relatively confined perimeter of a home or building network, a group key is usually sufficient to protect RPL messages sent between nodes. The use of the Key Source field allows multiple group keys to be used within the network.

   o  Security Level; LVL =3D 0: Use MAC-32. This is = recommended as integrity protection for RPL messages is the basic requirement. Encryption is unlikely to be necessary given the relatively non-confidential nature of RPL message payloads.
</new>
</RCC>

Section 7.1 Security considerations during initial = deployment

New approaches to initial security deployment are being developed in
   [I-D.kumar-dice-dtls-relay] and
   [I-D.richardson-6tisch--security-6top].  They = assume a partial
   ordering of the nodes, such that unsecured nodes = are added
   sequentially with the restriction that a path = between two secured
   nodes exists which passes through secured nodes = only.

I found this a little hard to understand.  When does a node = pass from being unsecured to secured?  Or does an unsecured node remain unsecured? If there is
a succinct way of saying this, it could go here.  Since = this is only describing new approaches that could potentially be applied, you would not
want to go into a lot of detail.
<RCC>
I would clarify as follows, in addition to Peter's suggestion:

<old>
New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assume a partial ordering of the nodes, such that unsecured nodes are added sequentially with the restriction that a path between two secured nodes exists which passes through secured nodes only.
</old>
<new>
New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In these drafts an already secured node at the perimeter of the network, which is one hop away from an unsecured node wishing to access the network, assists in transporting security and configuration traffic between the unsecured node and the authenticator/commissioner. Once secured and configured, the new node extends the perimeter of the network in an "onion ring" fashion until all nodes have been secured and configured.
</new>
</RCC>

In the home, nodes can be visually inspected by the home = owner
   and simple measures like pushing buttons = simultaneously on joint and
   joining devices is probably sufficient.

I think this definitely needs to be clarified!  You need to = say what is being accomplished by pushing the buttons (device pairing)?
<RCC>
I would clarify as follows, in addition to Peter's suggestion:

<old>
In the home, nodes can be visually inspected by the home owner and simple measures like pushing buttons simultaneously on joint and joining devices is probably sufficient.
</old>
<new>
In the home, nodes can be visually inspected by the home owner and a simple procedure, e.g. pushing buttons simultaneously on an already secured device and an unsecured joining device is usually sufficient to ensure that the unsecured joining device is authenticated and configured securely, and paired appropriately.
</new>
</RCC>

7.2

When nodes are lost, no additional security measures are needed, the
   network remains secure as before by not allowing = the addition of new
   nodes.

I=92m not sure what this means.  Does it mean that if a = node is lost, then it is treated as a =93new node=94 if it reappears, = and is not allowed
to rejoin the network?

New nodes can be added by using the same protocols used for
   initial deployment.

This came right after the sentence beginning =93When nodes are lost=94 which said that new nodes are not added.  That contradiction needs to
be reconciled.  I=92m also not sure what =93using the same = protocol=94 means.  Does it mean rerunning the protocol and rekeying = all the nodes, or does
it mean using the features that protocol has for adding = nodes?
<RCC>
I would rewrite this somewhat as the intent is unclear. I believe the intent is as follows:

<old>
When nodes are lost, no additional security measures are needed, the network remains secure as before by not allowing the addition of new nodes. New nodes can be added by using the same protocols used for initial deployment.  Some protocols may need a state change to = a subset of the secured nodes, other protocols only need the presence of a "trusted" installation node [RFC6345], [RFC5191], or [I-D.kumar-dice-dtls-relay].
</old>
<new>
Normally, the network remains secure by not allowing the addition of new nodes. If a new node needs to be added to the network, the network is usually configured to allow the new node to join via an assisting node in the manner described in Section 7.1. If an existing node becomes lost, it is usually possible to re-key all other existing nodes to isolate the lost node to ensure that, should it be found again, it has to re-join as if it were a new node.
</new>
</RCC>



Nits:

Section 1.1 

This applicability statement
   recommends more light weight security solutions and = specify the
   conditions under which these solutions are = appropriate.

Should be =93specifies=94 instead of =93specify=94.  I=92m = also not sure what is meant by =93conditions under which these solutions are appropriate.=94  Do
you mean light-weight as opposed to no security, or light-weight as opposed to heavy-weight.  Or are you talking about = conditions
under which different light-weight solutions are appropriate? =46rom reading the rest of the draft, I would assume the last is what you mean.
<RCC>
I would reword as follows:

<old>
This applicability statement recommends more light weight security solutions and specify the conditions under which these solutions are appropriate.
</old>
<new>
This applicability statement recommends lighter weight security solutions appropriate for home and building environments and indicates why these solutions are appropriate.
</new>
</RCC>


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m=
ailman/listinfo/roll


= --Apple-Mail=_D9F3BEFA-2C93-4312-B719-FA44558C3618-- From nobody Thu Apr 9 07:10:43 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0BAA71B2A49; Wed, 8 Apr 2015 22:04:33 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15981B2A46 for ; Wed, 8 Apr 2015 22:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 myzHlEO0oRuG for ; Wed, 8 Apr 2015 22:04:31 -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 1ABAA1B2A42 for ; Wed, 8 Apr 2015 22:04:13 -0700 (PDT) Received: from usevmg20.ericsson.net ([198.24.6.45]:49053) 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 1Yg4dQ-00019U-2b for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Wed, 08 Apr 2015 22:04:12 -0700 X-AuditID: c618062d-f79686d0000030a8-1b-5525b1bc904f Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A3.0C.12456.CB1B5255; Thu, 9 Apr 2015 00:54:52 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 9 Apr 2015 01:04:04 -0400 From: Meral Shirazipour To: "draft-ietf-roll-applicability-home-building.all@tools.ietf.org" , "gen-art@ietf.org" Thread-Topic: Gen-ART Telechat Call review of draft-ietf-roll-applicability-home-building-09 Thread-Index: AdBygmdlsWDLMSnSQ5mWLCOLETzW4Q== Date: Thu, 9 Apr 2015 05:04:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_ABCAA4EF18F17B4FB619EA93DEF7939A331909A2eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXSPn+6ejaqhBtf+GFhcPbyJ1eLqq88s DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAlfG24t/2QpOKlT8uLmarYGxQbaLkZNDQsBE 4srZG0wQtpjEhXvr2boYuTiEBI4ySjS8+88MkhASWMYosfBZJYjNJmAhsf33c1aQIhGBDYwS S88uAysSFoiUmH3/PyuILSIQJ/Hr4B9mCFtPYsXMk0AbODhYBFQkOv8agoR5BXwl9t35yghi MwIt/n5qDdgRzALiEreezIc6SEBiyZ7zzBC2qMTLx/9YIWwliTmvrzFD1OdLdK0/wgQxU1Di 5MwnLBMYhWYhGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSNHaXFqWW66 kcEmRmA0HJNg093BuOel5SFGAQ5GJR7eB0tUQ4VYE8uKK3MPMUpzsCiJ8y56cDBESCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA6NVtDGTpFny07I5r75OPB39Mm2tjeqfB8JKv5nOddwpXGG9 1ZXvXu+ZLLnZG99P0HQ+Gx1l/O3UjyPTHz17LvtDqVH2jWTEl4ubDdfptvt/nbv0AePdFUWJ YR6lflPtZcy0LC5WzrrS+HzFm7+P9s6s7DDLSS1S8mb89ZeN4Y5CtuF2/lptPX0lluKMREMt 5qLiRAD33Z1YZwIAAA== X-SA-Exim-Connect-IP: 198.24.6.45 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-SA-Exim-Mail-From: meral.shirazipour@ericsson.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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150409050413.1ABAA1B2A42@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 22:04:13 -0700 (PDT) Resent-From: meral.shirazipour@ericsson.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:10:40 -0700 Subject: [Roll] Gen-ART Telechat Call review of draft-ietf-roll-applicability-home-building-09 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 Apr 2015 05:04:33 -0000 --_000_ABCAA4EF18F17B4FB619EA93DEF7939A331909A2eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/Ge= nArtfaq>. Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Document: draft-ietf-roll-applicability-home-building-09 Reviewer: Meral Shirazipour Review Date: 2015-04-08 IETF LC End Date: 2015-03-23 IESG Telechat date: 2015-04-09 Summary: This draft is ready to be published as Standards Track RFC. Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com --_000_ABCAA4EF18F17B4FB619EA93DEF7939A331909A2eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am the assigned Gen-ART reviewer for this draft. F= or background on Gen-ART, please see the FAQ at < http://= wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

 

Please wait for direction from your document shepher= d or AD before posting a new version of the draft.

 

Document: draft-ietf-roll-applicability-home-buildin= g-09

Reviewer: Meral Shirazipour

Review Date: 2015-04-08

IETF LC End Date: 2015-03-23

IESG Telechat date: 2015-04-09

 

 

Summary: This draft is ready to be published as Stan= dards Track RFC.

 

 

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson

Research

www.ericsson.com

--_000_ABCAA4EF18F17B4FB619EA93DEF7939A331909A2eusaamb107erics_-- From nobody Thu Apr 9 07:10:45 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 518201B3439; Thu, 9 Apr 2015 04:07:24 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3241B3403 for ; Thu, 9 Apr 2015 04:07:24 -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 IQKuFhfCt2Xs for ; Thu, 9 Apr 2015 04:07:23 -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 377251B33F3 for ; Thu, 9 Apr 2015 04:07:23 -0700 (PDT) Received: from p130.piuha.net ([193.234.218.130]:53934) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgAIs-0000ix-DN for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Thu, 09 Apr 2015 04:07:23 -0700 Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 810672CC6F; Thu, 9 Apr 2015 14:07:16 +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 lQSCOLb1eqDz; Thu, 9 Apr 2015 14:07:14 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 6A2EA2CC5D; Thu, 9 Apr 2015 14:07:14 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_FEB807BE-61B8-43F5-8AAF-8A23D6FBCBA2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: Date: Thu, 9 Apr 2015 14:07:12 +0300 Message-Id: <1D7F11BE-F4A7-420A-A015-CA08622F4E24@piuha.net> References: To: Meral Shirazipour X-Mailer: Apple Mail (2.1878.6) X-SA-Exim-Connect-IP: 193.234.218.130 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150409110723.377251B33F3@ietfa.amsl.com> Resent-Date: Thu, 9 Apr 2015 04:07:23 -0700 (PDT) Resent-From: jari.arkko@piuha.net Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:10:40 -0700 Cc: "gen-art@ietf.org" , "draft-ietf-roll-applicability-home-building.all@tools.ietf.org" Subject: Re: [Roll] [Gen-art] Gen-ART Telechat Call review of draft-ietf-roll-applicability-home-building-09 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 Apr 2015 11:07:24 -0000 --Apple-Mail=_FEB807BE-61B8-43F5-8AAF-8A23D6FBCBA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for your review again, Meral! Jari On 09 Apr 2015, at 08:04, Meral Shirazipour = wrote: > I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at < = http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > =20 > Please wait for direction from your document shepherd or AD before = posting a new version of the draft. > =20 > Document: draft-ietf-roll-applicability-home-building-09 > Reviewer: Meral Shirazipour > Review Date: 2015-04-08 > IETF LC End Date: 2015-03-23 > IESG Telechat date: 2015-04-09 > =20 > =20 > Summary: This draft is ready to be published as Standards Track RFC. > =20 > =20 > =20 > Best Regards, > Meral > --- > Meral Shirazipour > Ericsson > Research > www.ericsson.com > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_FEB807BE-61B8-43F5-8AAF-8A23D6FBCBA2 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 iQIcBAEBCgAGBQJVJl1hAAoJEM80gCTQU46qinkQAIKa72tT8AGBKZS2IDPvyN5j vaFKnrvfDCDnzF3vif0noYaI+9V17g9eswx23AMutlRZsLrL1eYyRpypb0jLi00r 6SazvAwIyjJObscAbZ6HlJjcr0FTK1ITzhFmreZMlupfhOeqVoGtFeaH4ZuYJx/I xlTBLYa1p4/G7GF96vxE5nudnyom/HBtsoUQZE2wvkCNWKzKgIi6Dv8jeNjwuZ3l /7zBh1Uxq+CuOYwXiRRPhXtSgVMj13jlmSV1D6DgJigxUJ+cSIWZr6yzwZyGOj+a Jx1gREv7IohA6rNbmJwWlgTMXnv75Te0qweW1EjbQJCf0DLVeq3w2D4UFbqswxg2 JlwIesqMWyR4r4ULlbx4Z6t/goqHQeLosG38IRENme4RdEJJSMTRxsQF6XVS9KOx pyxadmX9qTaN7Jij99C35qpDtrRfY+VETD2ANf82jQq2RO9/hnzUKilcfAH06e6m wVnqvC8ll0lOui2uX3DYZCBg8Whe8x7uDLgSjVF2kkSLZGMhDszDEMRDhiYtRaiv Xkhz07MnH9GnWLBw0t/BZQ0+Gf32ZtD0Uh3o8ZCyszfKL3d2LRjqRgLEDiDXUwqD SWwAoIh26bgmPvZhpxyiOj4pen/OXffvFqSIfMIIH9OYYdSEiM9U18mniuB6s0kT HYG4ey79xauIJ+FViyoT =X250 -----END PGP SIGNATURE----- --Apple-Mail=_FEB807BE-61B8-43F5-8AAF-8A23D6FBCBA2-- From nobody Thu Apr 9 10:59: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 6E8081B303B; Thu, 9 Apr 2015 10:59:48 -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 szbxHlvbZWDE; Thu, 9 Apr 2015 10:59:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D414F1B3043; Thu, 9 Apr 2015 10:59:45 -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: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409175945.6488.76105.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 10:59:45 -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 Apr 2015 17:59:48 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ From nobody Fri Apr 10 09:04: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 188A81A7113; Fri, 10 Apr 2015 09:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 G9ZOh__WERZp; Fri, 10 Apr 2015 09:04:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAE51A82E2; Fri, 10 Apr 2015 09:04:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410160434.24576.51981.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 09:04:34 -0700 Archived-At: Cc: roll WG Subject: [Roll] WG Review: Routing Over Low power and Lossy networks (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: Fri, 10 Apr 2015 16:04:40 -0000 The Routing Over Low power and Lossy networks (roll) working group in the Routing Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-04-20. Routing Over Low power and Lossy networks (roll) ------------------------------------------------ Current Status: Active WG Chairs: Ines Robles Michael Richardson Technical advisors: Rene Struik Assigned Area Director: Alvaro Retana Mailing list Address: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Charter: Low power and Lossy Networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs have at least five distinguishing characteristics: LLNs operate with a hard, very small bound on state. In most cases, LLN optimize for saving energy. Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to not satisfy all of these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, health care, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents were used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. The solution must include unicast and multicast considerations. The Working Group will document how non-control packets are routed when they cross the LLN, and when they enter and exit the LLN: the appropriate use of RH3 (RFC6553), RPI (RFC6554) and IPv6-in-IPv6 encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will design a method to compress these routing headers into a single block. The WGLC on this work will be shared with 6lo. ROLL is responsible for maintenance of the protocols that is has developed, including RPL and MPL. AD approval is required for each new work item that is proposed. 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 Milestones: TBD From nobody Mon Apr 13 00:23: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 C065B1A0113; Mon, 13 Apr 2015 00:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 FdgWF2o9ygxE; Mon, 13 Apr 2015 00:23:27 -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 59EBD1A00ED; Mon, 13 Apr 2015 00:23:26 -0700 (PDT) Received: from roundcube.xs4all.nl ([194.109.20.206]) by smtp-cloud2.xs4all.net with ESMTP id FKPL1q0024SmhUa01KPLKd; Mon, 13 Apr 2015 09:23:20 +0200 Received: from [2001:983:a264:1:5815:b753:2294:f167] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 13 Apr 2015 09:23:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 13 Apr 2015 09:23:20 +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: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> Message-ID: X-Sender: stokcons@xs4all.nl (X5MjZCvHNbqg+Gx94kgkESVc5gphfPrz) 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 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: Mon, 13 Apr 2015 07:23:29 -0000 Hi Stephen, I leave the AKM discussion out in the reactions below. Michael intends to start it. My reactions below within I am sure Robert will improve on my suggestions. Greetings, Peter > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 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. thanks > > - 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. RPL MAY use unsecured messages to reduce message size. > > - 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 there is a single node that uses unsecured RPL messages, link-layer security MUST be present. > > - 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. What is an application? Different keys per group? But what about two overlapping groups of 5 nodes within a single home? I prefer to avoid these discussions. > > - 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.) done > > - section 7, 3rd para, "can rely on" is sales language, please > strike that or s/rely on/depend upon/ back to an earlier version: Both MAY be done using: > > - 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. returned to original specification language, as suggested > > - 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? fixed in earlier GEN Art e_mail exchange > > - 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. Concerning multicast security, the first light-weight attempt will probably be succeeded by more generally employable solutions. > > - 7.4, last sentence: more sales talk Remove it? It leaves the earlier phrase in the air > > - 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.) Specifies relation with 7416. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Apr 14 13:31:14 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 60BFC1B2A4D; Tue, 14 Apr 2015 13:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 34uNzg26H3qE; Tue, 14 Apr 2015 13:31:07 -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 E9D451AD35D; Tue, 14 Apr 2015 13:31:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E80A3E00B; Tue, 14 Apr 2015 16:42:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 95F4E63B76; Tue, 14 Apr 2015 16:31:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 81864636A2; Tue, 14 Apr 2015 16:31:05 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks , The IESG , roll-chairs@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 In-Reply-To: References: <20150408233408.4123.3118.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: 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: 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 Apr 2015 20:31:09 -0000 --=-=-= Content-Type: text/plain Stephen Farrell asked: > Please correct me if I'm getting this wrong, I honestly may have forgotten > the plan. My understanding was that RPL and RFC 7416 etc. were approved on > the basis that you needed to get to specific applications of RPL before you > could sensibly specify interoperable security with automated key management > (AKM) as is clearly required by BCP107 and as has been discussed between > security ADs and the ROLL WG numerous times. This is going back to the 2010 > discuss from Tim Polk that I inherited in 2011, hence me being uncertain if > I remember the plan for sure;-) In any case it seems to me that this draft > also doesn't get us to the point where we have a defined way to do AKM > (Again, sigh.) I also have a set of comments on that below that I won't > make into specific discuss points (at least until we figure out or > re-discover the plan). > So, with that context, and with real regrets for sounding like an old and > broken record, the discuss point: why is this not the ROLL WG draft where > we finally get to specify AKM for RPL? If your answer is that this is just > an applicablilty statement then I'll ask why it's going for proposed > standard, and when to finally expect the AKM spec for RPL (for this > application). BCP107 certainly does ask for automatic key management when keys are going to be used. The part of the plan that is perhaps not so clear is that we have yet to have anyone say that they intend to use layer-3 keying in for RPL. The intention of having the security being precisely specified in the applicability statements was so that we would know if layer-2 security was being used, or if there was a layer-3 security being used. If there is layer-3 security, then BCP107 would demand that we have an AKM for it. In reading section 7 again just now, I see how things went wrong... Some text seems to have snuck into section 7(.0) that tries to sit on the fence, so I propose to remove paragraphs 3 and 4 of that section and say instead: "This document mandates that a layer-2 mechanism be used during initial and incremental deployment. Please see the following sections." Section 7.1, is quite clear that PANA is being specified to carry EAP messages for a 1x bootstrap into layer-2 security. That this is the default position of this document. I have tried to persuade the authors to be clearer and less speculative. While I'm thrilled that they like the methods 6tisch is considering, I'd prefer to remove the paragraph "New approaches...". I would like prefer that this document was even more precisely about what kind of 15.4 security is being used, either directly profiling the relevant parts of the 802.15.4 specification, or by indirect reference to something that does. -- ] 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 [ -- 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) iQEVAwUBVS15CYCLcPvd0N1lAQJuoQgAgKb00tLn2t7jbAY2UaIQIv6gJmV+tHJU MGZEL3dUGnv6IPguDb/6UNQr2/JnVg7LL9G1Gg3RR2defBnAq4gqqjMICHq+qk8q uHtBdELZj4pQGWP32jJUfd+olQWXDJaUpzgxUcIa9BMxuyTbWLHPpl69Duvzn8BM EAgBOQa+EuphHuIajj5K76R1GW3JhIWrhViwpEaILrJTyRxHIVatpeVvvPW01Z8b Eat26u2zFEUNh8sYohM90EnLa3LNGedZz11YBZqIUFc9SSEjWFRlsK6JR4EwaZvS Ys4+hfvpH6imywTIUJGkaW3choVbsb2+LkN2OxRGt0uwP66nVK6qjw== =KCOk -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 14 16:04: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 5F13F1B3048; Tue, 14 Apr 2015 16:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cQd25Jlc2g_I; Tue, 14 Apr 2015 16:03:54 -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 175741B3044; Tue, 14 Apr 2015 16:03:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D43D6BF5A; Wed, 15 Apr 2015 00:03:52 +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 OgaWN_wnLkt3; Wed, 15 Apr 2015 00:03:50 +0100 (IST) Received: from [10.87.48.73] (unknown [86.41.51.113]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BD031BF25; Wed, 15 Apr 2015 00:03:50 +0100 (IST) Message-ID: <552D9CD3.7000101@cs.tcd.ie> Date: Wed, 15 Apr 2015 00:03:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , The IESG , roll-chairs@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 References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> In-Reply-To: <14934.1429043465@sandelman.ca> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kd7FOFohAtl2HiFDGfAwCFtkS5OlJQuVA" Archived-At: 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: 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 Apr 2015 23:03:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kd7FOFohAtl2HiFDGfAwCFtkS5OlJQuVA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/04/15 21:31, Michael Richardson wrote: >=20 > Stephen Farrell asked: >> Please correct me if I'm getting this wrong, I honestly may have forgo= tten >> the plan. My understanding was that RPL and RFC 7416 etc. were approve= d on >> the basis that you needed to get to specific applications of RPL befor= e you >> could sensibly specify interoperable security with automated key manag= ement >> (AKM) as is clearly required by BCP107 and as has been discussed betwe= en >> security ADs and the ROLL WG numerous times. This is going back to the= 2010 >> discuss from Tim Polk that I inherited in 2011, hence me being uncerta= in if >> I remember the plan for sure;-) In any case it seems to me that this d= raft >> also doesn't get us to the point where we have a defined way to do AKM= >> (Again, sigh.) I also have a set of comments on that below that I won'= t >> make into specific discuss points (at least until we figure out or >> re-discover the plan). >=20 >> So, with that context, and with real regrets for sounding like an old = and >> broken record, the discuss point: why is this not the ROLL WG draft wh= ere >> we finally get to specify AKM for RPL? If your answer is that this is = just >> an applicablilty statement then I'll ask why it's going for proposed >> standard, and when to finally expect the AKM spec for RPL (for this >> application). >=20 > BCP107 certainly does ask for automatic key management when keys are go= ing to > be used. The part of the plan that is perhaps not so clear is that we = have > yet to have anyone say that they intend to use layer-3 keying in for RP= L. >=20 > The intention of having the security being precisely specified in the > applicability statements was so that we would know if layer-2 security = was > being used, or if there was a layer-3 security being used. > If there is layer-3 security, then BCP107 would demand that we have an = AKM for it. >=20 > In reading section 7 again just now, I see how things went wrong... Som= e text > seems to have snuck into section 7(.0) that tries to sit on the fence, = so I > propose to remove paragraphs 3 and 4 of that section and say instead: > "This document mandates that a layer-2 mechanism be used during ini= tial > and incremental deployment. Please see the following sections." >=20 > Section 7.1, is quite clear that PANA is being specified to carry EAP > messages for a 1x bootstrap into layer-2 security. That this is the > default position of this document. I have tried to persuade the author= s to > be clearer and less speculative. While I'm thrilled that they like the > methods 6tisch is considering, I'd prefer to remove the paragraph "New > approaches...". >=20 > I would like prefer that this document was even more precisely about wh= at > kind of 15.4 security is being used, either directly profiling the rele= vant > parts of the 802.15.4 specification, or by indirect reference to someth= ing > that does. Thanks Michael. I agree that a profile or applicability statement can certainly go for all security "below" the IP layer in which case we don't have a direct application of BCP107. It does of course raise some other issues about interop (making precise refs as you say) and about how or whether you can authenticate RPL routers as such. I guess that latter is via PANA, which I'd need to read up on. Anyway, seems like the best thing here is for the fixes you've spotted above to be done along with any others from the IESG review and then for me to go over it again in the light of your mail. But do say if there's a better plan. Cheers, S. >=20 > -- > ] Never tell me the odds! | ipv6 mesh net= works [ > ] Michael Richardson, Sandelman Software Works | network archi= tect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rai= ls [ >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 --Kd7FOFohAtl2HiFDGfAwCFtkS5OlJQuVA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJVLZzWAAoJEC88hzaAX42iuq4H/0NCXcme4D9Il9oeNcqlg9qW Yjx8FnhNF7UibIgl6VXIvk4tWLn5zFo3AplLPNoBbkYRkl38TjETOGrBVpWXvH4P TiQVDI1EMDfPuDlYaL3FmxkKHl9JzKWBBbvaZJgwTE/cHtdJxLN3Q2ilCXlA/kV1 2zBxzgLf/n8IggYIAMrSOGOXrSv2X8NyXG4OPcw2/I+zYiSJUeePWujOgob/+7LC k/q237Kq2MHm7lM8iT0AgwEU0pP0oaUoLmRUK2MAN2dbRarZsDwtPzZZhhyUmaaS fVsAYD5vRDDyqT+cqQNmDrmCovajwm3QCVda2mzXl4rs6rSK9BmzDnMGVe3dKkQ= =jtf+ -----END PGP SIGNATURE----- --Kd7FOFohAtl2HiFDGfAwCFtkS5OlJQuVA-- From nobody Wed Apr 15 00:25: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 0F9AE1B3238; Wed, 15 Apr 2015 00:24:55 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 hdrW_qxGekDb; Wed, 15 Apr 2015 00:24:52 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFE81B3236; Wed, 15 Apr 2015 00:24:50 -0700 (PDT) Received: from roundcube.xs4all.nl ([194.109.20.203]) by smtp-cloud6.xs4all.net with ESMTP id G7Qp1q0074NtgTm017Qp2e; Wed, 15 Apr 2015 09:24:49 +0200 Received: from [2001:983:a264:1:3494:f3d8:36fd:66e8] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 15 Apr 2015 09:24:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 15 Apr 2015 09:24:48 +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: <14934.1429043465@sandelman.ca> References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> Message-ID: <0b35569a80c62337655b16c7010a84da@xs4all.nl> X-Sender: stokcons@xs4all.nl (e/jDYlEZC89xx1Xb1TYKdK6F7wXaIAbv) 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 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: Wed, 15 Apr 2015 07:24:55 -0000 HI Michael and Stephen, > In reading section 7 again just now, I see how things went wrong... > Some text > seems to have snuck into section 7(.0) that tries to sit on the fence, > so I > propose to remove paragraphs 3 and 4 of that section and say instead: > "This document mandates that a layer-2 mechanism be used during > initial > and incremental deployment. Please see the following sections." > > Section 7.1, is quite clear that PANA is being specified to carry EAP > messages for a 1x bootstrap into layer-2 security. That this is the > default position of this document. I have tried to persuade the > authors to > be clearer and less speculative. While I'm thrilled that they like the > methods 6tisch is considering, I'd prefer to remove the paragraph "New > approaches...". In principle the removal of paragraphs can be quite satisfactory because in the restraint one recognizes the master (my translation from German). But, it makes me wonder for whom we write this applicability draft. It is quite clear that protocols exist and are used for the initialization of the layer-2 security. On the other hand, many new protocols are suggested and not from an academic point of view but because there is a need. Removing the speculation means removing the recognition of this state of affairs. My suggestion is that with the removal of the speculation, a caveat is introduced that current text does not cover all known building and home deployment cases. Especially in connection to multicast I should like to indicate that work on multicast security is needed because far from solved. An alternative conclusion is that current state of affairs suggests an Information document. > > I would like prefer that this document was even more precisely about > what > kind of 15.4 security is being used, either directly profiling the > relevant > parts of the 802.15.4 specification, or by indirect reference to > something > that does. > The draft mentions ZigBee and Wi-SUN HAN. Any additional suggestions? Peter > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Apr 15 09:02: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 5FD741ACD44; Wed, 15 Apr 2015 09:02:23 -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 dstuCiVf3iwV; Wed, 15 Apr 2015 09:02:21 -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 7D1311ACCE0; Wed, 15 Apr 2015 09:02:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E08A2009E; Wed, 15 Apr 2015 12:13:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3BD2E63B76; Wed, 15 Apr 2015 12:02:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 29444636B6; Wed, 15 Apr 2015 12:02:20 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: <0b35569a80c62337655b16c7010a84da@xs4all.nl> References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> <0b35569a80c62337655b16c7010a84da@xs4all.nl> 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: 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.shepherd@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building@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: 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 Apr 2015 16:02:23 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable peter van der Stok wrote: > In principle the removal of paragraphs can be quite satisfactory > because in the restraint one recognizes the master (my translation fr= om > German). But, it makes me wonder for whom we write this applicability > draft. It's written for two entities: 1) people procuring networking (who write Requests For Proposals: RFP) 2) people who create networking solutions (who answer RFPs) You can't tell those groups that they need to specify some unknown, not yet defined protocol. It's actually against international trade agreements to do so! I realize at this point that it is rare to see an RFP like this, that mostly the RFP says something like: "please provide lights for our building", and that given that almost all solutions to date have been proprietary, that it's not the building owner's job to decide upon a standard... but that will change.=20 > It is quite clear that protocols exist and are used for the > initialization of the layer-2 security. On the other hand, many new > protocols are suggested and not from an academic point of view but > because there is a need. Removing the speculation means removing the > recognition of this state of affairs. Of course, we can revise the document to specify new things, but that means a new set of requirements. > My suggestion is that with the removal of the speculation, a caveat is > introduced that current text does not cover all known building and ho= me > deployment cases. Especially in connection to multicast I should like > to indicate that work on multicast security is needed because far from > solved. The document has to specify solutions that exist; that the current solutio= ns do not cover all deployment cases may be acceptable to document. In this specific case, we could write: "This document does not specify a multicast security solution. Networks deployed with this specification will depend upon layer-2 security to prevent outsiders from sending multicast traffic. It is recognized that this does not protect this control traffic from impersonation by already trusted devices. This is an area for a future specification." At least we recognize and document the limitations. > An alternative conclusion is that current state of affairs suggests an > Information document. >> I would like prefer that this document was even more precisely about >> what kind of 15.4 security is being used, either directly profiling >> the relevant parts of the 802.15.4 specification, or by indirect >> reference to something that does. >>=20 > The draft mentions ZigBee and Wi-SUN HAN. Any additional suggestions? Yes, it does. Can we specify them more clearly? I think that it would be either Zigbee IP (-2013? is it?) *OR* Wi-SUN HAN (I have no clue about this one). =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVS6Li4CLcPvd0N1lAQJZawgAmKe8+KmcgnnioKEq1e0vijOmSmxUwXL0 HVP9k4938kZ48uZSLyWLoEi1v9I/gV19vqT6JjqbSSa7cNpxHHflBX1WzbqoWIZQ jLDrmCE68vQjyYv+fJcSdeadEFRFQq8TOU+qh8W71rUAW7ZkkHzN2+lX1bkojDjo 1lM9YrvZBIj8X6F5zALDJ3+NzjjRmBR2Uyjh6rrcEvPJA8uN6mow5ruM0BsJegrx ZE0LirDgrDis+jqGzyO80Ws1hg78hHrg+ee0qai2ZzY6zGDDaf6mMoOnFm38ePVt HY1IkCB6fNrZMUs3Bks5OaXzdfSwK6SNlk8doy/Jf41M45FEGGoVVw== =UFsl -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 16 00:14: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 1D3EE1B2A73; Thu, 16 Apr 2015 00:01:37 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 MQ4eqG-RNbJ8; Thu, 16 Apr 2015 00:01:35 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D761B2A59; Thu, 16 Apr 2015 00:01:33 -0700 (PDT) Received: from roundcube.xs4all.nl ([194.109.20.203]) by smtp-cloud6.xs4all.net with ESMTP id GX1X1q00G4NtgTm01X1Xrk; Thu, 16 Apr 2015 09:01:32 +0200 Received: from [2001:983:a264:1:f92a:d77a:7105:f7da] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 16 Apr 2015 09:01:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 16 Apr 2015 09:01:31 +0200 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <12442.1429113740@sandelman.ca> References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> <0b35569a80c62337655b16c7010a84da@xs4all.nl> <12442.1429113740@sandelman.ca> Message-ID: <32c66dc3bb9f396188b90a178ff767d9@xs4all.nl> X-Sender: stokcons@xs4all.nl (3/jw3nPcLgS3E8HAJ+dWI+e4g0CWHes5) User-Agent: XS4ALL Webmail Archived-At: X-Mailman-Approved-At: Thu, 16 Apr 2015 00:13:58 -0700 Cc: mcr@sandelman.ca, 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.shepherd@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building@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: Thu, 16 Apr 2015 07:01:37 -0000 HI Michael, See below: > The document has to specify solutions that exist; that the current > solutions > do not cover all deployment cases may be acceptable to document. In > this > specific case, we could write: > "This document does not specify a multicast security solution. > Networks deployed with this specification will depend upon > layer-2 > security to prevent outsiders from sending multicast traffic. > It is recognized that this does not protect this control > traffic > from impersonation by already trusted devices. This is an > area > for a future specification." > > At least we recognize and document the limitations. OK, this is perfectly acceptable for multicast. When there are no other suggestions or objection, the draft is changed accordingly However, concerning alinea 3 in section 7.1 references to dtls-relay and security-6top are informational references and do not influence the specification part. On the mailing list there was at least support for mentioning dtls-relay. So, I like to keep them. > >> I would like prefer that this document was even more precisely > about > >> what kind of 15.4 security is being used, either directly > profiling > >> the relevant parts of the 802.15.4 specification, or by indirect > >> reference to something that does. > >> > > The draft mentions ZigBee and Wi-SUN HAN. Any additional > suggestions? > > Yes, it does. Can we specify them more clearly? I think that it would > be > either Zigbee IP (-2013? is it?) *OR* Wi-SUN HAN (I have no clue about > this > one). I don't understand what you mean. You want references to documents? Explaining the standards seems not really called for here. Peter From nobody Thu Apr 16 11:43: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 DC1E11B345E; Thu, 16 Apr 2015 11:43:08 -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 EiP6K8jDcpc5; Thu, 16 Apr 2015 11:43:07 -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 EE21F1B345F; Thu, 16 Apr 2015 11:43:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5B195200A7; Thu, 16 Apr 2015 14:54:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E213463B76; Thu, 16 Apr 2015 14:43:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CAAC0636B6; Thu, 16 Apr 2015 14:43:04 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: <32c66dc3bb9f396188b90a178ff767d9@xs4all.nl> References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> <0b35569a80c62337655b16c7010a84da@xs4all.nl> <12442.1429113740@sandelman.ca> <32c66dc3bb9f396188b90a178ff767d9@xs4all.nl> 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: 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.shepherd@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building@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: 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 Apr 2015 18:43:09 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable peter van der Stok wrote: >> >> I would like prefer that this document was even more precisely ab= out >> >> what kind of 15.4 security is being used, either directly profili= ng >> >> the relevant parts of the 802.15.4 specification, or by indirect >> >> reference to something that does. >> >> >> > The draft mentions ZigBee and Wi-SUN HAN. Any additional suggestio= ns? >> Yes, it does. Can we specify them more clearly? I think that it wo= uld be >> either Zigbee IP (-2013? is it?) *OR* Wi-SUN HAN (I have no clue abo= ut this >> one). > > I don't understand what you mean. > You want references to documents? Explaining the standards seems not = really > called for here. > I'm just suggesting a more definite, chapter/section, reference. =2D-=20 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) iQEVAwUBVTACuICLcPvd0N1lAQLs/wgAuwFimZG0gHEs6FSyibkbKtZdZtVEvTXU cgykGyosvXc+PhevFYS/GJ3gvViSmkDxOeQahnunqjo37oTj89C7Em8oJUCkaVO1 vC2A0dQ9En5dQXGU153WRVQO2bBfRlPgvIXA1XwmbECkbjN0q25Mpn4Xf6/+MHRy 7N7lIt66k80SqrbwkrD98fjqx2MdjY7fBCXTCBgcyyV861l//J9cDoHbxav6kCT3 ijjbAIupivJAET7IhGND1Q3oLb0Sc2i6DFFuf6XLedw0V9uTASu3XKslDaq+UfP9 KoICZoaNmAw52atDwLyMyAilrEU/Qv763YNfeu73MsK1vshP0XNp/Q== =TahM -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 17 07:59: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 9A47E1B2DC9 for ; Fri, 17 Apr 2015 07:59:06 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 sAnjhok4KLmq for ; Fri, 17 Apr 2015 07:59:04 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B201B2DB8 for ; Fri, 17 Apr 2015 07:59:03 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0432.eurprd01.prod.exchangelabs.com (10.242.221.23) with Microsoft SMTP Server (TLS) id 15.1.136.25; Fri, 17 Apr 2015 14:58:45 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.01.0118.022; Fri, 17 Apr 2015 14:58:46 +0000 From: "Turner, Randy" To: "roll@ietf.org" Thread-Topic: RPL DIO option Thread-Index: AdB5HqE854TcvEHOTSCe8spb23DJWg== Date: Fri, 17 Apr 2015 14:58:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [148.80.255.144] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0432; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(41574002)(53754006)(66066001)(450100001)(77096005)(54356999)(19580395003)(19300405004)(87936001)(40100003)(122556002)(50986999)(2656002)(15975445007)(102836002)(46102003)(110136001)(5890100001)(92566002)(229853001)(16236675004)(77156002)(2501003)(2900100001)(86362001)(62966003)(2351001)(74316001)(19625215002)(33656002)(107886001)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0432; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DB4PR01MB0432; BCL:0; PCL:0; RULEID:; SRVR:DB4PR01MB0432; x-forefront-prvs: 0549E6FD50 Content-Type: multipart/alternative; boundary="_000_DB4PR01MB0431DA95A983EDC9B1D48CF380E30DB4PR01MB0431eurp_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2015 14:58:45.8999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR01MB0432 Archived-At: Subject: [Roll] RPL DIO option 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, 17 Apr 2015 14:59:06 -0000 --_000_DB4PR01MB0431DA95A983EDC9B1D48CF380E30DB4PR01MB0431eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, What would be the process to propose a new DIO option for RPL? Internet-Dr= aft ? I'm assuming vendor priority options are not allowed... Thanks! Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_DB4PR01MB0431DA95A983EDC9B1D48CF380E30DB4PR01MB0431eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

What would be the process to propose a new DIO optio= n for RPL?  Internet-Draft ?

 

I’m assuming vendor priority options are not a= llowed…

 

Thanks!
Randy


P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_DB4PR01MB0431DA95A983EDC9B1D48CF380E30DB4PR01MB0431eurp_-- From nobody Fri Apr 17 08: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 11A091B2DD8 for ; Fri, 17 Apr 2015 08:00:16 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 B3KLVkTnkd_W for ; Fri, 17 Apr 2015 08:00:14 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57FB1B2DD1 for ; Fri, 17 Apr 2015 08:00:13 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 17 Apr 2015 14:59:55 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.01.0118.022; Fri, 17 Apr 2015 14:59:55 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: RPL DIO option Thread-Index: AdB5HqE854TcvEHOTSCe8spb23DJWgAAHr1g Date: Fri, 17 Apr 2015 14:59:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [148.80.255.144] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0431; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(53754006)(41574002)(122556002)(16236675004)(76176999)(50986999)(54356999)(46102003)(66066001)(19300405004)(74316001)(87936001)(2656002)(86362001)(15975445007)(77096005)(102836002)(62966003)(450100001)(77156002)(19580405001)(107886001)(5890100001)(40100003)(110136001)(33656002)(2900100001)(2950100001)(19580395003)(19625215002)(92566002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0431; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DB4PR01MB0431; BCL:0; PCL:0; RULEID:; SRVR:DB4PR01MB0431; x-forefront-prvs: 0549E6FD50 Content-Type: multipart/alternative; boundary="_000_DB4PR01MB04313C59E8F35EE380B2E31B80E30DB4PR01MB0431eurp_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2015 14:59:55.6530 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR01MB0431 Archived-At: Subject: Re: [Roll] RPL DIO option 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, 17 Apr 2015 15:00:16 -0000 --_000_DB4PR01MB04313C59E8F35EE380B2E31B80E30DB4PR01MB0431eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops, I meant vendor proprietary options in my previous email.... R. From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Turner, Randy Sent: Friday, April 17, 2015 10:59 AM To: roll@ietf.org Subject: [Roll] RPL DIO option Hi All, What would be the process to propose a new DIO option for RPL? Internet-Dr= aft ? I'm assuming vendor priority options are not allowed... Thanks! Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_DB4PR01MB04313C59E8F35EE380B2E31B80E30DB4PR01MB0431eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Oops, I meant vendor p= roprietary options in my previous email….

 

R.

 

From: Roll [ma= ilto:roll-bounces@ietf.org] On Behalf Of Turner, Randy
Sent: Friday, April 17, 2015 10:59 AM
To: roll@ietf.org
Subject: [Roll] RPL DIO option

 

Hi All,

 

What would be the process to propose a new DIO optio= n for RPL?  Internet-Draft ?

 

I’m assuming vendor priority options are not a= llowed…

 

Thanks!
Randy

 

P PLEASE CO= NSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) = is confidential and may be legally privileged. If you are not an intended r= ecipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the info= rmation in this e-mail or its attachments. If you have received this e-mail= in error, please notify the sender immediately by return e-mail and delete= all copies of this message and any attachments. Thank you.

--_000_DB4PR01MB04313C59E8F35EE380B2E31B80E30DB4PR01MB0431eurp_-- From nobody Fri Apr 17 13:57: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 2423B1A86EF for ; Fri, 17 Apr 2015 13:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.2 X-Spam-Level: X-Spam-Status: No, score=0.2 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 2VeiJO-lBjk9 for ; Fri, 17 Apr 2015 13:57:06 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A946D1A701A for ; Fri, 17 Apr 2015 13:57:05 -0700 (PDT) Received: by laat2 with SMTP id t2so89368575laa.1 for ; Fri, 17 Apr 2015 13:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=MtI6exMTdTdwRa0dg9kpm9Q6fJgAT9dnfdsq9DA9/UY=; b=zyvzWfIl/3zN9k6TnElUATygJrdZOEKrlrnB3zRwOLwS3pAedguzfvunhpPUlboceT a0bQWRvx0ESQ3E/eSm5iR4keqdVtz9T66hpE/KIfW+WzJBV9nX4VuvRLx+q+gL4zrt0b KvIoRImgwJwV+Su3LRopMMPCrjc2hEcG1xihPenwkFliI6iHCaAmupeT9j1vwgPG6lEL skcYBawiUwclvo/8v1H7QsfH3BL3aAucfPUgr6PP1P+bVxD7ZL6m/1f+psLKt1woOmgg qmvXKuHJE2IizpsoQ4cIEWGW//Vi0i+dTWGWxQypZfoaR/53kRmyRzF9SzEGjalKL4bN Rnmg== X-Received: by 10.112.8.101 with SMTP id q5mr5936697lba.19.1429304224132; Fri, 17 Apr 2015 13:57:04 -0700 (PDT) MIME-Version: 1.0 References: <21995.1428000041@sandelman.ca> <20150402203416.GA18697@omega> <557AE653-44F3-49E9-887E-7C55CE8295B9@gmail.com> <551EE07F.8030909@mulligan.com> In-Reply-To: <551EE07F.8030909@mulligan.com> From: =?UTF-8?Q?Jo=C3=A3o_Pedro_Taveira?= Date: Fri, 17 Apr 2015 20:57:03 +0000 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a1134df968e333c0513f1d2a6 Archived-At: Subject: Re: [Roll] Looking for Linux implementation of RPL for interop testing 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, 17 Apr 2015 20:57:08 -0000 --001a1134df968e333c0513f1d2a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi to all, I'm glad to know that there's some interested on my RPL linux implementation. Since september 2014, I had no opportunity to work on RPL on linux. When I started this implementation, I thought on possible roadmap: 1. RFC 6206 trickle 2. RFC 6550 RPL 3. RFC 6552 OF0 4. Root Node mode 5. Router Node mode 6. userland tools 7. OF0 Integration tests Linux/Linux 8. OF0 Integration tests with Linux/contiki 9. Tests with Linux/at86rf23x + contiki/atmega128rfa1 10. Tests with Linux/xbee + contiki/m1284p+xbee 11. RFC 6719 MRHOF 12. RFC 6551 Routing Metrics ... I also tested rpl linux implementation using CORE ( http://www.nrl.navy.mil/itd/ncs/products/core). Using kernel namespaces, it's easy to test the implementation. I stop on issues 11. and 12. I got stuck when I start to get MRHOF, ETX and metrics working. I had to dive on linux netstack to figure out how to get ETX without breaking (or breaking too much) abstraction layers on netstack. Since RPL Linux implementation worked very well with 0OF and contiki, I just tried to make some use of linux nodes with very basic network support on a small mesh with contiki and linux nodes. The results could be better. I faced too many basic issues, with very simple resolutions but that would require some free time to fix that I hadn't. Regarding to contiki, there's nothing to say since RPL it's quite solid. I simply needed more ram for the IP buffer since it was only 400bytes long (there wos no more free space). About RPL implementation, it took too long to react on mesh changes. At least, multi-hop worked. About linux nodes within the mesh, I tried to fly to high and I can say that ssh really want the minimum of ipv6 max MTU. Connecting one of the linux nodes to internet as gw, the network basic protocols seam to work without problems like DNS, ICMP6 and CoAP. Still on MRHOF, I contact linux-zigbee/linux-wpan group to get some information about roadmap about MAC802154 and I was told that it was too soon to know what and how things would be. I think there was a merge from linux zigbee to linux-wpan, but in the meanwhile, it was agreed between linux groups to merge wpan with bluetooth. As last resort on ETX and MRHOF on linux and to see it working, I just tried to use nd6 timers as indication on link quality on linux side. Basically, when some neighbour moved to state REACHABLE would count as a good packet delivered. When a neighbour moved to state FAILED would count as several non-acked packets. Assuming that nodes wouldn't send too many packets, neighbours would move frequently to IDLE state. On each packet exchange this would make state to move to REACHABLE and count as good packet. Using RPL linux as root, this metric would be more or less acceptable but I didn't like the idea of different metrics. Anyway, I was able to get correct behaviour from MRHOF from linux nodes (even with a strange metric). Since 4thQ 2014, I had no time available to work on this. I think I already know how to get ETX working. I'll see linux-wpan/linux-bluebooth current status and I hope to continue what I was doing back then. About the blog which talks about tests to RPL Linux implementation, I just want to say that I wasn't contact about it before the post. Best Regards, Jo=C3=A3o Pedro Taveira --001a1134df968e333c0513f1d2a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi to all,

I'm glad to k= now that there's some interested on my RPL linux implementation.
<= div>
Since september 2014, I had no opportunity to work on RP= L on linux.

When I started this implementation, I = thought on possible roadmap:
1. RFC 6206 trickle
2. RFC= 6550 RPL
3. RFC 6552 OF0
4. Root Node mode
5= . Router Node mode
6. userland tools
7. OF0 Integration= tests Linux/Linux
8. OF0 Integration tests with Linux/contiki
9. Tests with Linux/at86rf23x + contiki/atmega128rfa1
10.= Tests with Linux/xbee + contiki/m1284p+xbee
11. RFC 6719 MRHOF
12. RFC 6551 Routing Metrics
...

I also tested rpl linux implementation using CORE (http://www.nrl.navy.mil/itd/ncs/product= s/core). Using kernel namespaces, it's easy to test the implementat= ion.

I stop on issues 11. and 12. I got stuck when= I start to get MRHOF, ETX and metrics working. I had to dive on linux nets= tack to figure out how to get ETX without breaking (or breaking too much) a= bstraction layers on netstack.

Since RPL Linux imp= lementation worked very well with 0OF and contiki, I just tried to make som= e use of linux nodes with very basic network support on a small mesh with c= ontiki and linux nodes. The results could be better. I faced too many basic= issues, with very simple resolutions but that would require some free time= to fix that I hadn't.
Regarding to contiki, there's noth= ing to say since RPL it's quite solid. I simply needed more ram for the= IP buffer since it was only 400bytes long (there wos no more free space). = About RPL implementation, it took too long to react on mesh changes. At lea= st, multi-hop worked. About linux nodes within the mesh, I tried to fly to = high and I can say that ssh really want the minimum of ipv6 max MTU. Connec= ting one of the linux nodes to internet as gw, the network basic protocols = seam to work without problems like DNS, ICMP6 and CoAP.=C2=A0
Still on MRHOF, I contact linux-zigbee/linux-wpan group to get = some information about roadmap about MAC802154 and I was told that it was t= oo soon to know what and how things would be. I think there was a merge fro= m linux zigbee to linux-wpan, but in the meanwhile, it was agreed between l= inux groups to merge wpan with bluetooth.=C2=A0

As= last resort on ETX and MRHOF on linux and to see it working, I just tried = to use nd6 timers as indication on link quality on linux side. Basically, w= hen some neighbour moved to state REACHABLE would count as a good packet de= livered. When a neighbour moved to state FAILED would count as several non-= acked packets. Assuming that nodes wouldn't send too many packets, neig= hbours would move frequently to IDLE state. On each packet exchange this wo= uld make state to move to REACHABLE and count as good packet. Using RPL lin= ux as root, this metric would be more or less acceptable but I didn't l= ike the idea of different metrics. Anyway, I was able to get correct behavi= our from MRHOF from linux nodes (even with a strange metric).
Since 4thQ 2014, I had no time available to work on this. I thi= nk I already know how to get ETX working. I'll see linux-wpan/linux-blu= ebooth current status and I hope to continue what I was doing back then.

About the blog which talks about tests to RPL Linux = implementation, I just want to say that I wasn't contact about it befor= e the post.

Best Regards,
Jo=C3=A3o Pedr= o Taveira

--001a1134df968e333c0513f1d2a6-- From nobody Tue Apr 21 19:04: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 217071B304A; Tue, 21 Apr 2015 19:04:10 -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 gBhJn2nvjS_I; Tue, 21 Apr 2015 19:04:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 313C91B3051; Tue, 21 Apr 2015 19:04:07 -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.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422020407.29342.6325.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 19:04:07 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-04.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: Wed, 22 Apr 2015 02:04:10 -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-04.txt Pages : 9 Date : 2015-04-21 Abstract: This draft defines a way to configure a parameter set of MPL (Multicast Protocol for Low power and Lossy Networks) via 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 parameter 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: http://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 23 07:23: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 C27441A8AE4; Thu, 23 Apr 2015 07:23:58 -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, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 eE0qxq4E1Wpy; Thu, 23 Apr 2015 07:23:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 649841A8998; Thu, 23 Apr 2015 07:23:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150423142336.21816.77868.idtracker@ietfa.amsl.com> Date: Thu, 23 Apr 2015 07:23:36 -0700 Archived-At: Cc: roll@ietf.org, Rene Struik , Michael Richardson , Ines Robles Subject: [Roll] Spencer Dawkins' No Objection on charter-ietf-roll-03-01: (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: Thu, 23 Apr 2015 14:23:58 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-roll-03-01: 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.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-roll/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given this text: "It will also need to consider the transport characteristic the routing protocol messages will experience." you might consider adding a sentence about liaising with TSVWG on this (so the working group knows where to ask questions while considering). From nobody Thu Apr 23 07:46: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 5E75A1A9233; Thu, 23 Apr 2015 07:46:31 -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 k3FncMFgIR-L; Thu, 23 Apr 2015 07:46:30 -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 BA1E91A923D; Thu, 23 Apr 2015 07:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=573; q=dns/txt; s=iport; t=1429800385; x=1431009985; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D2yMmXQ8rRux39N7Z2stEaqDTAOWqlJZPi8OmFUaoE0=; b=XrRjBUgJwUSWZMUA3rD3lyVVCdhB91/wLh5q9AcfFfhm37Mzyej5kNzE uVb6rmAzRTFNCzk1PohA+VW6plYhzIBRDs4RceLDEAhA2BRSbq380NjGS 8Nv1CdLGKkC6Vpt3yiUb1nW0Ts8mxDM1F29JAsZrWao6DU3Oi5C35JuZN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaBQD9BDlV/49dJa1bgwyBLgXNewKBNkwBAQEBAQGBC4QhAQEEOj8QAgEINhAhESUCBAENBYgXAxHHOg2FEgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLN4JNgjcHhC0BBIY3iGqCIIhhgVCOcYZLI4Nzb4FEgQABAQE X-IronPort-AV: E=Sophos;i="5.11,631,1422921600"; d="scan'208";a="414194970" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP; 23 Apr 2015 14:46:25 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t3NEkOva015011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 14:46:25 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.76]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 09:46:24 -0500 From: "Alvaro Retana (aretana)" To: Spencer Dawkins , The IESG Thread-Topic: Spencer Dawkins' No Objection on charter-ietf-roll-03-01: (with COMMENT) Thread-Index: AQHQfdElarDpNUQMk0e8l4jKVz1htp1anB8A Date: Thu, 23 Apr 2015 14:46:24 +0000 Message-ID: References: <20150423142336.21816.77868.idtracker@ietfa.amsl.com> In-Reply-To: <20150423142336.21816.77868.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.115] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "roll@ietf.org" , Rene Struik , Michael Richardson , Ines Robles Subject: Re: [Roll] Spencer Dawkins' No Objection on charter-ietf-roll-03-01: (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, 23 Apr 2015 14:46:31 -0000 I updated the text. Thanks! Alvaro. On 4/23/15, 8:23 AM, "Spencer Dawkins" wrote: >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Given this text: > >"It will also need to consider the transport characteristic the routing >protocol messages will experience." > >you might consider adding a sentence about liaising with TSVWG on this >(so the working group knows where to ask questions while considering). > From nobody Fri Apr 24 08:37: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 889871B302B; Fri, 24 Apr 2015 08:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 joLwVZCSRY2f; Fri, 24 Apr 2015 08:37:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BCC1B3026; Fri, 24 Apr 2015 08:37:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150424153721.25156.5256.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 08:37:21 -0700 Archived-At: Cc: roll WG Subject: [Roll] WG Action: Rechartered Routing Over Low power and Lossy networks (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: Fri, 24 Apr 2015 15:37:23 -0000 The Routing Over Low power and Lossy networks (roll) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Routing Over Low power and Lossy networks (roll) ------------------------------------------------ Current Status: Active WG Chairs: Ines Robles Michael Richardson Technical advisors: Rene Struik Assigned Area Director: Alvaro Retana Mailing list Address: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Charter: Low power and Lossy Networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs have at least five distinguishing characteristics: LLNs operate with a hard, very small bound on state. In most cases, LLN optimize for saving energy. Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to not satisfy all of these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, health care, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents were used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. As needed, the Working Group will liaise with the TSVWG on transport-related topics. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. The solution must include unicast and multicast considerations. The Working Group will document how non-control packets are routed when they cross the LLN, and when they enter and exit the LLN: the appropriate use of RH3 (RFC6553), RPI (RFC6554) and IPv6-in-IPv6 encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will design a method to compress these routing headers into a single block. The WGLC on this work will be shared with 6lo. ROLL is responsible for maintenance of the protocols that is has developed, including RPL and MPL. AD approval is required for each new work item that is proposed. 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 Milestones: Aug 2015 - Submit draft about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation to the IESG. Nov 2015 - Submit draft about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context to the IESG. Nov 2015 - Evaluate WG progress, recharter or close From nobody Sun Apr 26 23:56: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 4EDEC1A0273; Sun, 26 Apr 2015 23:56: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 ADFacQB2uFg1; Sun, 26 Apr 2015 23:56:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F241A875B; Sun, 26 Apr 2015 23:56:14 -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.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150427065614.24827.70189.idtracker@ietfa.amsl.com> Date: Sun, 26 Apr 2015 23:56:14 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-10.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: Mon, 27 Apr 2015 06:56:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks 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-10.txt Pages : 32 Date : 2015-04-26 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: http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 27 00:08: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 0AD001A8784; Mon, 27 Apr 2015 00:05: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 G7zWo7R0DulW; Mon, 27 Apr 2015 00:05:29 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900F11A8795; Mon, 27 Apr 2015 00:05:27 -0700 (PDT) Received: from roundcube.xs4all.nl ([194.109.20.206]) by smtp-cloud6.xs4all.net with ESMTP id Lv5R1q0014SmhUa01v5R0W; Mon, 27 Apr 2015 09:05:25 +0200 Received: from [2001:983:a264:1:f5b8:b074:aedd:95a2] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 27 Apr 2015 09:05:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Apr 2015 09:05:24 +0200 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <15944.1429209784@sandelman.ca> 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> Message-ID: <4b7fa589766fa21d12403ee8cc49262e@xs4all.nl> X-Sender: stokcons@xs4all.nl (Q89EMQma6hPmok6r0Q113Y/VRTA6ifWJ) User-Agent: XS4ALL Webmail Archived-At: X-Mailman-Approved-At: Mon, 27 Apr 2015 00:08:45 -0700 Cc: mcr@sandelman.ca, 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.shepherd@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building@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: Mon, 27 Apr 2015 07:05:32 -0000 Dear all, This new draft includes the return to the RFC2119 text. It includes all comments answered during the security evaluation. It includes suggestions by Michael to answer the DISCUSS raised by Stephen Farrell. It maintains some of the text on the aspects of security in buildings that need additional work. Greetings, 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-10.txt Pages : 32 Date : 2015-04-26 2 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: http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Mon Apr 27 00:09: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 03E271A87D2 for ; Mon, 27 Apr 2015 00:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 jmmOhvsXmZ9j for ; Mon, 27 Apr 2015 00:09:03 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 253E21A8911 for ; Mon, 27 Apr 2015 00:09:03 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id BF34D63 for ; Mon, 27 Apr 2015 09:09:00 +0200 (CEST) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t3R790no019811 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 27 Apr 2015 09:09:00 +0200 Received: from [192.168.1.142] (h31n15-sbg-a11.ias.bredband.telia.com [195.67.245.31]) by norm.sics.se (Postfix) with ESMTPSA id 3093B279; Mon, 27 Apr 2015 09:09:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Joakim Eriksson In-Reply-To: <20150427065614.24827.70189.idtracker@ietfa.amsl.com> Date: Mon, 27 Apr 2015 09:09:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A7E9864-B64C-4DE1-A030-DFA4789DB09E@sics.se> References: <20150427065614.24827.70189.idtracker@ietfa.amsl.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.2098) X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: ip=195.67.245.31; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09OkT9024 - 9f93b96641bd - 20150427 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09OkT9024&m=9f93b96641bd&t=20150427&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09OkT9024&m=9f93b96641bd&t=20150427&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09OkT9024&m=9f93b96641bd&t=20150427&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 195.67.245.31 is neither permitted nor denied by domain joakime@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=195.67.245.31; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-10.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, 27 Apr 2015 07:09:06 -0000 Hi, Had a very brief read and have a quick question: "Packets from asymmetric and/or unstable channels SHOULD be deleted at = layer 2." Do we really mean channel here? asymmetric channel sounds strange - I = guess it should be asymmetric link and/or unstable (high in interference?) = channels? Otherwise I might have missed something in the terminology. And ETX as the recommended objective function is better than OF0 but ETX is not giving a good network topology in some cases and since this is aiming at control I do not think it is the best choice. Interactivity = needs less loss than the objective of being energy efficient. Best regards, =E2=80=94 Joakim Eriksson, SICS > On 27 Apr 2015, at 08:56, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > 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-10.txt > Pages : 32 > Date : 2015-04-26 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-buildi= ng/ >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-10 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-applicability-home-buil= ding-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Apr 29 00:26: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 D5D961ACD0D for ; Wed, 29 Apr 2015 00:26:51 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 xgkPEyULor87 for ; Wed, 29 Apr 2015 00:26:49 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BAB31A0123 for ; Wed, 29 Apr 2015 00:26:49 -0700 (PDT) Received: from roundcube.xs4all.nl ([194.109.20.203]) by smtp-cloud6.xs4all.net with ESMTP id MjSm1q0054NtgTm01jSmRj; Wed, 29 Apr 2015 09:26:46 +0200 Received: from [2001:983:a264:1:1d27:be7f:cf0c:3205] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 29 Apr 2015 09:26:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 29 Apr 2015 09:26:46 +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: <1A7E9864-B64C-4DE1-A030-DFA4789DB09E@sics.se> References: <20150427065614.24827.70189.idtracker@ietfa.amsl.com> <1A7E9864-B64C-4DE1-A030-DFA4789DB09E@sics.se> Message-ID: X-Sender: stokcons@xs4all.nl (E/1K/uhgSI1fNpxroX0Hxy+nEOiVvVbb) User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-10.txt 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: Wed, 29 Apr 2015 07:26:52 -0000 Hi Joakim, thanks for your remark. A channel models the transport through space of e/m waves between two interfaces. An asymmetric channel corresponds with asymmetric transport. I prefer channel over link, as link usually does not include the concept of transport. I agree that opinions may differ, but the text is clear as it is? Concerning ETX. The authors and other people generally recommend ETX. Do you have a better proposal backed up by evidence? I will be happy to hear about it. Greetings, peter Joakim Eriksson schreef op 2015-04-27 09:09: > Hi, > > Had a very brief read and have a quick question: > > "Packets from asymmetric and/or unstable channels SHOULD be deleted at > layer 2." > > Do we really mean channel here? asymmetric channel sounds strange - I > guess > it should be asymmetric link and/or unstable (high in interference?) > channels? > > Otherwise I might have missed something in the terminology. > > And ETX as the recommended objective function is better than OF0 but > ETX is not giving a good network topology in some cases and since this > is aiming at control I do not think it is the best choice. > Interactivity needs > less loss than the objective of being energy efficient. > > Best regards, > — Joakim Eriksson, SICS > > > >> On 27 Apr 2015, at 08:56, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Routing Over Low power and Lossy >> 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-10.txt >> Pages : 32 >> Date : 2015-04-26 >> >> 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: >> http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-10 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-10 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Apr 29 00:58: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 630A71B2C02 for ; Wed, 29 Apr 2015 00:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 56WONdinmKd5 for ; Wed, 29 Apr 2015 00:58:46 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8651B2C01 for ; Wed, 29 Apr 2015 00:58:46 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 4D2D81289; Wed, 29 Apr 2015 09:58:45 +0200 (CEST) Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t3T7wiEI001067 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Apr 2015 09:58:44 +0200 Received: from [172.16.135.137] (178-78-237-194.customers.ownit.se [178.78.237.194]) by norm.sics.se (Postfix) with ESMTPSA id B4028443; Wed, 29 Apr 2015 09:58:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Joakim Eriksson In-Reply-To: Date: Wed, 29 Apr 2015 09:58:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <04BDB8DC-4CFC-4F27-8578-38600AEB18FA@sics.se> References: <20150427065614.24827.70189.idtracker@ietfa.amsl.com> <1A7E9864-B64C-4DE1-A030-DFA4789DB09E@sics.se> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.2098) X-Bayes-Prob: 0.495 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem X-CanIt-Geo: ip=178.78.237.194; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09OlHWITG - 425cf451a4ae - 20150429 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09OlHWITG&m=425cf451a4ae&t=20150429&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09OlHWITG&m=425cf451a4ae&t=20150429&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09OlHWITG&m=425cf451a4ae&t=20150429&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 178.78.237.194 is neither permitted nor denied by domain joakime@sics.se) receiver=e-mailfilter01.sunet.se; client-ip=178.78.237.194; envelope-from=; helo=norm.sics.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-10.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, 29 Apr 2015 07:58:49 -0000 Hello! > On 29 Apr 2015, at 09:26, peter van der Stok = wrote: >=20 > Hi Joakim, >=20 > thanks for your remark. > A channel models the transport through space of e/m waves between two = interfaces. > An asymmetric channel corresponds with asymmetric transport. Sure, but most of the 6LoWPAN related RFC have been talking about = asymmetric links (look at RFC 6775 - 6LoWPAN-ND as an example). I would suggest keeping = the same terminology since that make things much easier for the reader. > I prefer channel over link, as link usually does not include the = concept of transport. > I agree that opinions may differ, but the text is clear as it is? Well replacing channel would make it a clear text ;-) > Concerning ETX. > The authors and other people generally recommend ETX. Do you have a = better proposal backed up by evidence? > I will be happy to hear about it. We have been doing some significant tests and got some good evidence = that indicates that picking based on ETX as is will sometimes cause nodes to pick parents that have crappy links = but good rank. We did some experiments that basically give higher values to retransmissions than transmissions and = that is significantly better. Something like LinkValue =3D 1 + retransmissions * 3=20 instead of 1 + retransmissions * 1. We have not yet made any RFC or publication on that yet - but we will = hopefully get the time to do that sooner or later (we have seen this in multiple separate projects). ETX = is all fine for data collection networks which is more or less was designed and evaluated for, but not for = interactive networks where users expect=20 low latency when trying to configure/switch things. Best regards, =E2=80=94 Joakim Eriksson, SICS > Greetings, >=20 > peter >=20 > Joakim Eriksson schreef op 2015-04-27 09:09: >> Hi, >> Had a very brief read and have a quick question: >> "Packets from asymmetric and/or unstable channels SHOULD be deleted = at layer 2." >> Do we really mean channel here? asymmetric channel sounds strange - I = guess >> it should be asymmetric link and/or unstable (high in interference?) = channels? >> Otherwise I might have missed something in the terminology. >> And ETX as the recommended objective function is better than OF0 but >> ETX is not giving a good network topology in some cases and since = this >> is aiming at control I do not think it is the best choice. = Interactivity needs >> less loss than the objective of being energy efficient. >> Best regards, >> =E2=80=94 Joakim Eriksson, SICS >>> On 27 Apr 2015, at 08:56, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Routing Over Low power and Lossy = 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-10.txt >>> Pages : 32 >>> Date : 2015-04-26 >>> 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-buildi= ng/ >>> There's also a htmlized version available at: >>> = http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-10 >>> A diff from the previous version is available at: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-applicability-home-buil= ding-10 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll