From nobody Sat May 2 15:24:54 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821E11A90CD for ; Sat, 2 May 2015 15:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-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 rXXBUlbYKds3 for ; Sat, 2 May 2015 15:24:48 -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 A90721A90CA for ; Sat, 2 May 2015 15:24:48 -0700 (PDT) Received: from localhost ([::1]:60488 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yofq4-000368-6i; Sat, 02 May 2015 15:24:48 -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-richardson-roll-applicability-template@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Sat, 02 May 2015 22:24:48 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/170 Message-ID: <067.bf7a20b9a1ceaac448e3cdfe1e424b75@trac.tools.ietf.org> X-Trac-Ticket-ID: 170 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: <20150502222448.A90721A90CA@ietfa.amsl.com> Resent-Date: Sat, 2 May 2015 15:24:48 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Archived-At: Cc: roll@ietf.org Subject: [Roll] [roll] #170 (draft-richardson-roll-applicability-template): Use of ESC Dispatch value in new IETF header compression 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: Sat, 02 May 2015 22:24:53 -0000 #170: Use of ESC Dispatch value in new IETF header compression Comment by R.D.: Any use of the ESC Dispatch Type in new IETF header compression methods must avoid conflicts with the use specified in G.9903. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-richardson-roll- mariainesrobles@gmail.com | applicability- Type: task | template@tools.ietf.org Priority: major | Status: new Component: draft-richardson-roll- | Milestone: applicability-template | Version: Severity: Candidate WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Mon May 11 08:15: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 8C6201A8A8B; Mon, 11 May 2015 08:15: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 pbvI782G_cNy; Mon, 11 May 2015 08:15:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCCC1A8AD9; Mon, 11 May 2015 08:15: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.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511151507.20504.16024.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 08:15:07 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-template-07.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, 11 May 2015 15:15: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 : ROLL Applicability Statement Template Author : Michael C. Richardson Filename : draft-ietf-roll-applicability-template-07.txt Pages : 10 Date : 2015-05-11 Abstract: This document is a template applicability statement for the Routing over Low-power and Lossy Networks (ROLL) WG. This document is not for publication, but rather is to be used as a template. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-applicability-template-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-template-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 11 08:43: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 C74D51ACD93 for ; Mon, 11 May 2015 08:43:16 -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 8NWxHb8zc-Vw for ; Mon, 11 May 2015 08:43:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE751ACD8E for ; Mon, 11 May 2015 08:42:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D13942002A for ; Mon, 11 May 2015 11:55:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 55A1863B88; Mon, 11 May 2015 11:42:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3D50F63B86 for ; Mon, 11 May 2015 11:42:54 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <20150511151507.20504.16024.idtracker@ietfa.amsl.com> References: <20150511151507.20504.16024.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] I-D Action: draft-ietf-roll-applicability-template-07.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, 11 May 2015 15:43:16 -0000 --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > Filename : draft-ietf-roll-applicability-template-07.txt There are no changes from 06. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVVDN/oCLcPvd0N1lAQI7+Af/R8P7AqRWgD07BINDjwLY9/enpDUJMiHQ 0tUesj50FXpLy1nwER72UG2xygXG8yEzEWiPAfLAcI11YpO/vRm7tUnDtR8lnnLc vaj+lbZOWvqYVJ7a3M8AhLIXhbGraYuD0fqdq92Cp4tXnMb2e2T6LiD9lH37rFCG b4EN6jGoopBIFJVJmK6wLkjHRDi0i8jBLeAXLwi7Ti9oy8VoTl6f5o0wYAISeikF S7m+jM/l+zSxsCuBYkF+5XkNZZHaN8zgVYUeoRXPCichDWJBzxHrHeosJePb7iwT yIJYJR/GSYUQCnfN+QNfKyxCny0jdqOotApirAMFmwaPWSau90kBSQ== =I8dT -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 13 00:28: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 29B6E1A1A36 for ; Wed, 13 May 2015 00:28: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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcs12KGa56Cb for ; Wed, 13 May 2015 00:28:33 -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 EFE541A1A1C for ; Wed, 13 May 2015 00:28:32 -0700 (PDT) Received: from roundcube.xs4all.nl ([194.109.20.206]) by smtp-cloud6.xs4all.net with ESMTP id TKUU1q00D4SmhUa01KUUWD; Wed, 13 May 2015 09:28:30 +0200 Received: from AMontpellier-654-1-51-59.w86-202.abo.wanadoo.fr ([86.202.66.59]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 13 May 2015 09:28:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 May 2015 09:28:28 +0200 From: peter van der Stok To: stephen.farrell@cs.tcd.ie Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <4b7fa589766fa21d12403ee8cc49262e@xs4all.nl> References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> <0b35569a80c62337655b16c7010a84da@xs4all.nl> <12442.1429113740@sandelman.ca> <32c66dc3bb9f396188b90a178ff767d9@xs4all.nl> <15944.1429209784@sandelman.ca> <4b7fa589766fa21d12403ee8cc49262e@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (Mzb9Xv1+QQxvj7+uqwLBpZ1WwaHj4ifk) User-Agent: XS4ALL Webmail Archived-At: Cc: Roll , anders Brandt , Michael Richardson 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, 13 May 2015 07:28:35 -0000 Hi Stephen, About 2 weeks ago we submitted a new applicability home building draft 010. 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. However I am not sure that it addresses your original concern: " why is this not the ROLL WG draft where we finally get to specify AKM for RPL?" Looking forward to your reaction, 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 Sun May 17 05:36:19 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFB91A9034; Sun, 17 May 2015 03:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 kb9sdXZ-zmK4; Sun, 17 May 2015 03:39:57 -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 59F2E1A9037; Sun, 17 May 2015 03:39:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 83377BE97; Sun, 17 May 2015 11:39:54 +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 4B6h66Gx-ILL; Sun, 17 May 2015 11:39:52 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.109]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8ED93BEFD; Sun, 17 May 2015 11:39:52 +0100 (IST) Message-ID: <55586FF8.5060908@cs.tcd.ie> Date: Sun, 17 May 2015 11:39:52 +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 , Michael Richardson References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> <0b35569a80c62337655b16c7010a84da@xs4all.nl> <12442.1429113740@sandelman.ca> <32c66dc3bb9f396188b90a178ff767d9@xs4all.nl> <15944.1429209784@sandelman.ca> <4b7fa589766fa21d12403ee8cc49262e@xs4all.nl> In-Reply-To: <4b7fa589766fa21d12403ee8cc49262e@xs4all.nl> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 17 May 2015 05:36:19 -0700 Cc: mcr@sandelman.ca, 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: Sun, 17 May 2015 10:40:00 -0000 Hi all, and apologies for the slow response... On 27/04/15 08:05, peter van der Stok wrote: > 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. I'm sorry to say I don't think we're there yet. I just read the current draft and I think we still have significant issues for this DISCUSS. - If the way in which we are achieving interoperable security is via layer2-only then I would argue that that has to be more clearly stated up front (for truth-in-advertising reasons) as otherwise people may implement/deploy assuming the opposite. - I really seriously question the proposition that layer2-only security is sufficient for more complex building requirements. If that is true, then this document needs to say when it is safe and when it is unsafe to use RPL in such networks. (I can accept that layer2-only is ok for simple buildings and homes, at least for the next few years.) - The "MUST be present" at the start of 4.1.8 is not quite right. If the plan here is layer2-only then you need to say something more like that all RPL packets MUST be sent using the layer2 mechanisms and MUST be verified as having been received using the layer2 mechanisms. That (I guess) could require some code if a node can ever emit/receive an insecure message. - 7.1 remains a collection of references that will not IMO give us interop when multiple vendors are involved. Can you explain to me why I'm wrong? (And I don't mean the multicast bit, but the stuff about unicast.) Again, apologies for being a barrier to progress here, but I guess we're paying the price now for us collectively not having addressed this issue back at the start of the ROLL WG's work. I do think though that we need to ensure that we don't send out a set of specifications that might put quite a number of networks at risk because of our omissions, even if that means we need to address some technically and politically tricky issues. Cheers, S. PS: Sorry to say I'll be travelling for the next few days so responses will continue to be slow. Maybe we should try setup a concall on this in a week or so? If that helps, I'm very happy to do that. > 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 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue May 19 04:17: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 B560B1A7D80; Tue, 19 May 2015 03:27:28 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkXWbJGLUWYe; Tue, 19 May 2015 03:27:26 -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 192C71A702E; Tue, 19 May 2015 03:27:24 -0700 (PDT) Received: from roundcube.xs4all.nl ([194.109.20.208]) by smtp-cloud3.xs4all.net with ESMTP id VmTD1q0094VN29601mTDmr; Tue, 19 May 2015 12:27:21 +0200 Received: from AMontpellier-654-1-255-78.w92-133.abo.wanadoo.fr ([92.133.146.78]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 19 May 2015 12:27:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 19 May 2015 12:27:13 +0200 From: peter van der Stok To: Stephen Farrell Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <55586FF8.5060908@cs.tcd.ie> References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> <0b35569a80c62337655b16c7010a84da@xs4all.nl> <12442.1429113740@sandelman.ca> <32c66dc3bb9f396188b90a178ff767d9@xs4all.nl> <15944.1429209784@sandelman.ca> <4b7fa589766fa21d12403ee8cc49262e@xs4all.nl> <55586FF8.5060908@cs.tcd.ie> Message-ID: X-Sender: stokcons@xs4all.nl (gH/7nV35qDxTJarJ9k5P2kBhl7VSuZFb) User-Agent: XS4ALL Webmail Archived-At: X-Mailman-Approved-At: Tue, 19 May 2015 04:17:24 -0700 Cc: mcr@sandelman.ca, roll-chairs@ietf.org, Michael Richardson , Routing Over Low power and Lossy networks , draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 10:27:28 -0000 Hi Stephen, thanks for continuing the discussion. I respond between the lines below. It is possible that my co-authors want to improve on my comments. Stephen Farrell schreef op 2015-05-17 12:39: > Hi all, and apologies for the slow response... > > On 27/04/15 08:05, peter van der Stok wrote: >> 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. > > I'm sorry to say I don't think we're there yet. I just read the > current draft and I think we still have significant issues for > this DISCUSS. > > - If the way in which we are achieving interoperable security is > via layer2-only then I would argue that that has to be more clearly > stated up front (for truth-in-advertising reasons) as otherwise > people may implement/deploy assuming the opposite. > > - I really seriously question the proposition that layer2-only > security is sufficient for more complex building requirements. > If that is true, then this document needs to say when it is safe > and when it is unsafe to use RPL in such networks. (I can accept > that layer2-only is ok for simple buildings and homes, at least > for the next few years.) The interpretation that layer-2 security is sufficient for building control is not meant. Point to point security is certainly recommended and is a MUST when client and server are separated by a border router (They reside on different network segments) I suggest the following phrase at the end of 4.1.8: The use of security measures at layer 3 or higher is RECOMMENDED. When two communicating nodes are separated by a border router, the nodes MUST use use security measures at layer 3 or higher. For example, a client and server that use CoAP MUST use DTLS as specified in RFC7252. Actually, I am not sure if this text addresses your point. > > - The "MUST be present" at the start of 4.1.8 is not quite right. > If the plan here is layer2-only then you need to say something > more like that all RPL packets MUST be sent using the layer2 > mechanisms and MUST be verified as having been received using > the layer2 mechanisms. That (I guess) could require some code > if a node can ever emit/receive an insecure message. I will rephrase as you suggest and refer to IEEE 802.15.4 security specification. Your suggestion is clearer, but should not imply layer-2 security only as clarified above. > > - 7.1 remains a collection of references that will not IMO give > us interop when multiple vendors are involved. Can you explain > to me why I'm wrong? (And I don't mean the multicast bit, but > the stuff about unicast.) I think from interop point of view, the use of a layer-2 security initialization protocol is different from using DTLS or CoAP protocols. The initialization happens on a given installation that is subject to installation specific constraints. Manufacturers organize themselves in alliances which select the IETF protocols which best fit the boundary conditions of their installations. In analogy section 7.1 refers to ZigBee/IP which recommends PANA with EAP/TLS and japanese ECHONET which recommends PANA with EAP/PSK. Further, L2 key management is not defined in the basic spec of L2 and other standards have created different key management methodologies, including IEEE which is creating a framework(IEEE 802.15.9). We see that other key management protocols are specified in the IETF currently, with progressing insight in the installation needs. Therefore, I think that specifying a layer-2 initial deployment beyond what is done in 7.1 does not bring much more interop, given the ongoing progress in different organizations including IETF, and given its limited scope to a given installation. > > Again, apologies for being a barrier to progress here, but I > guess we're paying the price now for us collectively not having > addressed this issue back at the start of the ROLL WG's work. I > do think though that we need to ensure that we don't send out a > set of specifications that might put quite a number of networks > at risk because of our omissions, even if that means we need to > address some technically and politically tricky issues. I hope the issues become tractable with the ongoing discussion. > > Cheers, > S. > > PS: Sorry to say I'll be travelling for the next few days so > responses will continue to be slow. Maybe we should try setup a > concall on this in a week or so? If that helps, I'm very happy > to do that. If my responses above add to the confusion, I think that a telconf will help. However, I should very much like that Robert Cragie and/or Michael Richardson assist as well. Their experience will clearly contribute to arrive at a satisfying conclusion. Greetings, Peter > >> 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 >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From nobody Sun May 24 16:55:16 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 5D58A1A891F; Wed, 20 May 2015 09:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, 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 mNgaXmHwZnDj; Wed, 20 May 2015 09:01:24 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698361A8927; Wed, 20 May 2015 09:01:23 -0700 (PDT) Received: by labbd9 with SMTP id bd9so81437291lab.2; Wed, 20 May 2015 09:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8bzqmd88D4/gRj1cOhmHvoSI4MM77bMJ+rfr4ycJgjE=; b=MGxhhTRLvoDgfJhVZ9CR+7ODmlXS3rAvjvDoLVPLa+njzUgW3D5P/5efA+WQGhVDOY w/bv7pcKjY5Bbd5G3WWy/+ZXXiJKhCP8aYJZ5wIgNcwC60PveuO/61g4Wd91+6q+4+Np DMd3ErWiWPr2RQT63dqewncRXnl6t8d1W9dSazF4JWisZZVFzNkyXkje2A16VTOTU492 f7+x1sLxUK9XB/tmQSDVO6wu6Zt+7YQHLo097wDL090s7ZA1lUSEwooQVnMMbr9igAcw tj4sf3LOxLSGISJvgmU49Rad2JW9Cr/794O9D4kI1FQAWWgS9thn7Ha8ca0swohkfSut BWpQ== MIME-Version: 1.0 X-Received: by 10.152.43.37 with SMTP id t5mr18598270lal.96.1432137681870; Wed, 20 May 2015 09:01:21 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.25.155.8 with HTTP; Wed, 20 May 2015 09:01:21 -0700 (PDT) In-Reply-To: <555C043A.50904@cs.tcd.ie> References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> <0b35569a80c62337655b16c7010a84da@xs4all.nl> <12442.1429113740@sandelman.ca> <32c66dc3bb9f396188b90a178ff767d9@xs4all.nl> <15944.1429209784@sandelman.ca> <4b7fa589766fa21d12403ee8cc49262e@xs4all.nl> <55586FF8.5060908@cs.tcd.ie> <555C043A.50904@cs.tcd.ie> Date: Wed, 20 May 2015 17:01:21 +0100 X-Google-Sender-Auth: 5GQEBKc0pH6R-R71CZ1Cgv2J-1I Message-ID: From: Robert Cragie To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c34eb4cc23ec051685897e Archived-At: X-Mailman-Approved-At: Sun, 24 May 2015 16:55:13 -0700 Cc: Michael Richardson , roll-chairs@ietf.org, Michael Richardson , Routing Over Low power and Lossy networks , draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:01:26 -0000 --001a11c34eb4cc23ec051685897e Content-Type: text/plain; charset=UTF-8 Sorry for the very late reply on this. Firstly, here are my responses to Stephen's original comments. I will look at the later e-mails and respond accordingly. Robert ---------------------------------------------------------------------- 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. The aim is to say: "In order to support low-cost devices and devices running on a battery, RPL MAY use either unsecured messages or secured messages" The omitted subtext is probably "..., not just secured messages" as that is what is being emphasised here, i.e. a greater choice and thus implied security policy choice. Would the following make more sense?: "In order to support low-cost devices and devices running on a battery, there are two security policies applicable to RPL; one where RPL uses unsecured messages and another where RPL uses secured messages" - 4.1.8 seems to me to imply that link layer security is always needed since there can always be some node that will send an unsecured RPL messsage. If you agree, then I think that should be made more clear. If you disagree, I'd like to understand how. If the security policy option where RPL uses unsecured messages applies, then link layer security will always be needed. It is a policy choice applicable to the deployed network - 4.1.8, I am surprised not to see a recommendation that separate group keys SHOULD be used for different applications in the same bulding network. But that may be too fine grained a recommendation for this document perhaps. That is a separate issue from securing RPL messages, which is what this section is about - 5.1.2.1, I think it'd be clearer to say Imin should be between 10 and 50 ms. The "10 - 50 ms" notation can be confusing. (Same elsewhere.) Agree suggestion is clearer - section 7, 3rd para, "can rely on" is sales language, please strike that or s/rely on/depend upon/ Rephrase as: "The following mechanisms MAY be used: (i) pre-installation using an out-of-band method, (ii) secure delivery when a device is introduced into the network or (iii) secure delivery by a trusted neighbouring device." - section 7, 3rd para, last sentence: this is sales language and should be deleted. Or perhaps s/is/SHOULD be/ would turn it back into a piece of specification language. Agree with suggested change - 7.1 - this is odd text to see in a proposed standard, but I think it's accurately describing the level of interop to expect in RPL security, so is probably the right thing to say. I'd argue that it'd be even better to bluntly admit/say that there is currently no interoperable automated key management for RPL. (Same for 7.3) Or, and better, to fix that lack. (See my discuss point.) There are many ways to achieve key distribution and in some respects it would be nice to see one single way to do it. However, this is unlikely to ever happen. The main reason is that a deployment standard is a complex animal of which RPL is typically one small part. The key management is also just a part and in itself typically is a conglomeration of various RFCs and applicability statements, irrespective of what routing protocol is chosen for said deployment. ZigBee IP is a good example of a full interoperable deployment and there is an extensive list of 43 RFCs and IDs directly referenced, not to mention the further indirect references from those. We chose which protocols to use for key management and set security policy - 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. To be honest, I never quite understood the need for this section. Peter wanted this in - 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 would remove the last sentence. It doesn't add anything - 7.4, last sentence: more sales talk I would remove the last sentence. It doesn't add anything - 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.) It seems to be just a summary section On 20 May 2015 at 04:49, Stephen Farrell wrote: > > Thanks Peter, > > On 19/05/15 11:27, peter van der Stok wrote: > >> >> If my responses above add to the confusion, I think that a telconf will >> help. >> > Well I do confess to continuing confusion (not caused by you > though) about how we get secure interop,in general here so > maybe we ought think about it. > >> However, I should very much like that Robert Cragie and/or Michael >> Richardson assist as well. >> Their experience will clearly contribute to arrive at a satisfying >> conclusion. >> > Good idea to do that first, yes. > > Cheers, > S > > -- Robert Cragie Gridmerge Ltd. 8 Racecourse View, Cottenham, Cambridge, CB24 8AL, UK +44 7919 620526 http://www.gridmerge.com --001a11c34eb4cc23ec051685897e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for the very late reply on this. Firstly, here are m= y responses to Stephen's original comments. I will look at the later e-= mails and respond accordingly.

Robert

=
-----------------------------------------------------------------= -----
COMMENT:
----------------------------------------= ------------------------------


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

- 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 b= ut for RPL to do X or
not-X.

<RCC>=
The aim is to say:

"In order to su= pport low-cost devices and devices running on a battery, RPL MAY use either= unsecured messages or secured messages"

The = omitted subtext is probably "..., not just secured messages" as t= hat is what is being emphasised here, i.e. a greater choice and thus implie= d security policy choice.

Would the following make= more sense?:

"In order to support low-cost d= evices and devices running on a battery, there are two security policies ap= plicable to RPL; one where RPL uses unsecured messages and another where RP= L uses secured messages"
<RCC>

- 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 uns= ecured RPL messsage. If you agree, then I think
that should be ma= de more clear. If you disagree, I'd like to
understand how.

<RCC>If the security policy option where RPL = uses unsecured messages applies, then link layer security will always be ne= eded. It is a policy choice applicable to the deployed network</RCC><= /div>

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

=
<RCC>That is a separate issue from securing RPL messages, which = is what this section is about</RCC>

- 5.1.2.= 1, I think it'd be clearer to say Imin should be
between 10 a= nd 50 ms. The "10 - 50 ms" notation can be
confusing. (= Same elsewhere.)

<RCC>Agree suggestion is cl= earer</RCC>

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

<RCC>
Rephrase as:

"The following mechanisms MAY be used: (i) pre= -installation using an out-of-band method, (ii) secure delivery when a devi= ce is introduced into the network or (iii) secure delivery by a trusted nei= ghbouring device."
</RCC>

- s= ection 7, 3rd para, last sentence: this is sales language
and sho= uld be deleted. Or perhaps s/is/SHOULD be/ would turn
it back int= o a piece of specification language.

<RCC>Ag= ree with suggested change</RCC>

- 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 secur= ity, so is probably the right thing to say.
I'd argue that it= 'd be even better to bluntly admit/say that
there is currentl= y no interoperable automated key management
for RPL. (Same for 7.= 3) Or, and better, to fix that lack. (See
my discuss point.)

<RCC>There are many ways to achieve key distribu= tion and in some respects it would be nice to see one single way to do it. = However, this is unlikely to ever happen. The main reason is that a deploym= ent standard is a complex animal of which RPL is typically one small part. = The key management is also just a part and in itself typically is a conglom= eration of various RFCs and applicability statements, irrespective of what = routing protocol is chosen for said deployment. ZigBee IP is a good example= of a full interoperable deployment and there is an extensive list of 43 RF= Cs and IDs directly referenced, not to mention the further indirect referen= ces from those. We chose which protocols to use for key management and set = security policy </RCC>

- 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 a= ny keys
contained in the node are at significant risk of being le= aked.

<RCC>To be honest, I never quite under= stood the need for this section. Peter wanted this in</RCC>

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

<= div><RCC>I would remove the last sentence. It doesn't add anythin= g</RCC>

- 7.4, last sentence: more sales tal= k

<RCC>I would remove the last sentence. It = doesn't add anything</RCC>

- 7.5, what i= s 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 th= is seem to.)

<RCC>It seems to be just a summ= ary section</RCC>
<= br>
On 20 May 2015 at 04:49, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Thanks Peter,

On 19/05/15 11:27, peter van der Stok wrote:

If my responses above add to the confusion, I think that a telconf will hel= p.
 Well I do confess to continuing confusion (not caused by you
though) about how we get secure interop,in general here so
maybe we ought think about it.
However, I should very much like that Robert Cragie and/or Michael Richards= on assist as well.
Their experience will clearly contribute to arrive at a satisfying conclusi= on.
 Good idea to do that first, yes.

Cheers,
S




--

Robert Cragie

Gridmerge Ltd.
8 Racecourse View,
Cottenham,
Cambridge, CB24 8AL, UK<= br style=3D"font-family:tahoma,sans-serif;font-size:12.8000001907349px">+44 7919 620526
htt= p://www.gridmerge.com

--001a11c34eb4cc23ec051685897e-- From nobody Sun May 24 16:55: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 5BE671B2D61; Tue, 19 May 2015 20:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_72=0.6, 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 E2z2uMwhyTdv; Tue, 19 May 2015 20:49:31 -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 4143E1B2DBE; Tue, 19 May 2015 20:49:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39256BEDC; Wed, 20 May 2015 04:49:28 +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 FGuEYXEMDQQ3; Wed, 20 May 2015 04:49:27 +0100 (IST) Received: from [192.168.48.65] (unknown [119.145.14.6]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3041DBED9; Wed, 20 May 2015 04:49:22 +0100 (IST) Message-ID: <555C043A.50904@cs.tcd.ie> Date: Wed, 20 May 2015 04:49:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: consultancy@vanderstok.org References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <14934.1429043465@sandelman.ca> <0b35569a80c62337655b16c7010a84da@xs4all.nl> <12442.1429113740@sandelman.ca> <32c66dc3bb9f396188b90a178ff767d9@xs4all.nl> <15944.1429209784@sandelman.ca> <4b7fa589766fa21d12403ee8cc49262e@xs4all.nl> <55586FF8.5060908@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 24 May 2015 16:55:13 -0700 Cc: mcr@sandelman.ca, roll-chairs@ietf.org, Michael Richardson , Routing Over Low power and Lossy networks , draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG , draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: 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, 20 May 2015 03:49:34 -0000 Thanks Peter, On 19/05/15 11:27, peter van der Stok wrote: > > If my responses above add to the confusion, I think that a telconf > will help. Well I do confess to continuing confusion (not caused by you though) about how we get secure interop,in general here so maybe we ought think about it. > However, I should very much like that Robert Cragie and/or Michael > Richardson assist as well. > Their experience will clearly contribute to arrive at a satisfying > conclusion. Good idea to do that first, yes. Cheers, S From nobody Sun May 24 16:55:19 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE5A1ACDFD; Sat, 23 May 2015 06:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.921 X-Spam-Level: X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FREEMAIL_DOC_PDF=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0h4KcAQII-e; Sat, 23 May 2015 06:10:33 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D46A1ACDFB; Sat, 23 May 2015 06:10:31 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so10559386wic.1; Sat, 23 May 2015 06:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:mime-version:content-type:subject:date:cc:to:message-id; bh=lNXtt3o27b/ZgEKcFZOwPv+y9uL74ah5p1GtCytOi3E=; b=E1uPDiCHhrIEbehWQgPjUGXI5AdgdJbIUapiWaINAKyh+J1t6FzQxIwkiBH9nLtCRC fL0C1H2m+3crrQ2mx8JfI6+kwfw+WClzYtLgmaJyHZoK53kFyLW76g3A8A9lsOBcEh5V XwvihBaQTTZbOKtzJBBrH1M3gdmhYEqMpqXCiiFGamXt/F/VnqlYwgEp5yREXiItmPh9 /coXP8HAObsMYt53Fx6vXzemmjRnJXV6PlDYrE0azlPcPH8AC8QerLxaJizIMtKCjIv2 XTCjrV80+nBjWGQd1F2KbL6Ipw1ojTAxfMBUgInUiIcCTFBRD1/hRtbqRrKlUneo2SIG H26A== X-Received: by 10.194.189.228 with SMTP id gl4mr24140628wjc.1.1432386629980; Sat, 23 May 2015 06:10:29 -0700 (PDT) Received: from [195.251.141.130] ([195.251.141.130]) by mx.google.com with ESMTPSA id gh3sm640469wjb.36.2015.05.23.06.10.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 May 2015 06:10:27 -0700 (PDT) From: Eleni Panagou Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-13-960357657 Date: Sat, 23 May 2015 16:10:07 +0300 X-Priority: 1 To: dtn@ietf.org Message-Id: X-Mailer: Apple Mail (2.1085) Archived-At: X-Mailman-Approved-At: Sun, 24 May 2015 16:55:12 -0700 Cc: roll@ietf.org, 88attendees@ietf.org Subject: [Roll] Enabling Web Search Information Architecture (IA) with a Fuzzy OWL API X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 13:10:35 -0000 --Apple-Mail-13-960357657 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear All,=20 Members of the DTN IETF (IRTF DTNRG), ROLL IETF and 88attendess IETF, I thought you might find interesting my recently selected publication = (2014) in a poster through the Research Data Alliance Organization (RDA = EUROPE), 4th Plenary Meeting, Amsterdam, The Nederlands. E. Panagou and D. A. Georgiou, =93Enabling Web Search Information = Architecture (IA) with a Fuzzy OWL API,=94 4th Plenary Meeting, Research = Data Alliance Organization (RDA), Amsterdam, The Netherlands, 22- 24 = September, 2014 (Poster format) Please, find the attachment below, while I was a researcher in Fuzzy = Systems at Democritus University of Thrace, Xanthi, Greece. I would be delighted to receive soon your valuable comments. Sincerely yours, Eleni Panagou Eleni Panagou MSc DIPL.- Inf. =09 Cultural Informatics & Communication of the University of The Aegean Independent Researcher in Web Information & Communication Systems for Next- Generation Computing Home Tel. +30 2410230889 Cellular Tel. +30 6975068299 Permanent Postal Address: 143 G. Seferi Str, 41221,=20 Larissa, GREECE Twitter -Social Media Microblogging Site:=20 Join me at https://www.twitter.com/epanagou or see my Science blog https://epanagou.wordpress.com Eleni Panagou MSc DIPL.- Inf. =09 Cultural Informatics & Communication of the University of The Aegean Independent Researcher in Web Information & Communication Systems for Next- Generation Computing Home Tel. +30 2410230889 Cellular Tel. +30 6975068299 Permanent Postal Address: 143 G. Seferi Str, 41221,=20 Larissa, GREECE Twitter -Social Media Microblogging Site:=20 Join me at https://www.twitter.com/epanagou or see my Science blog https://epanagou.wordpress.com --Apple-Mail-13-960357657 Content-Type: multipart/mixed; boundary=Apple-Mail-14-960357658 --Apple-Mail-14-960357658 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = All, 

Members of the DTN IETF (IRTF DTNRG), ROLL = IETF and 88attendess IETF,

I thought you = might find interesting my recently selected publication (2014) in a = poster through the Research Data Alliance Organization (RDA EUROPE), 4th = Plenary Meeting, Amsterdam, The Nederlands.


Please, = find the attachment below, while I was a researcher in Fuzzy Systems at = Democritus University of Thrace, Xanthi, = Greece.

I would be delighted to receive soon = your valuable comments.

Sincerely = yours,

Eleni = Panagou





Eleni Panagou MSc DIPL.- Inf. =
Cultural Informatics & Communication
of the University of The = AegeanIndependent Researcher in = Web
Information & = Communication
Systems for Next- Generation
Computing
Home Tel. +30 2410230889
Cellular Tel. +30 = 6975068299
=
143 G. Seferi = Str, = 41221, 
=
Larissa, = GREECE
Twitter -Social Media Microblogging = Site: 
<= span class=3D"Apple-style-span" style=3D"color: rgb(51, 51, 153); = font-family: Helvetica-Light; font-size: 13px; ">or see my Science = blog

Eleni Panagou MSc DIPL.- Inf. =
Cultural Informatics & Communication
of the University of The = AegeanIndependent Researcher in = Web
Information & = Communication
Systems for Next- Generation
Computing
Home Tel. +30 2410230889
Cellular Tel. +30 = 6975068299
=
143 G. Seferi = Str, = 41221, 
=
Larissa, = GREECE
Twitter -Social Media Microblogging = Site: 
<= span class=3D"Apple-style-span" style=3D"color: rgb(51, 51, 153); = font-family: Helvetica-Light; font-size: 13px; ">or see my Science = blog

= --Apple-Mail-14-960357658-- --Apple-Mail-13-960357657-- From nobody Fri May 29 14:47:33 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDFB1B2DCB; Fri, 29 May 2015 14:47:32 -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 82kl65Kf4GWk; Fri, 29 May 2015 14:47:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 582A41A8937; Fri, 29 May 2015 14:47:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529214730.27099.19148.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 14:47:30 -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: Fri, 29 May 2015 21:47:32 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/