Re: [Roll] home-building-requirements section 7.1

peter van der Stok <stokcons@xs4all.nl> Tue, 09 December 2014 07:55 UTC

Return-Path: <stokcons@xs4all.nl>
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 00A861A6EDB for <roll@ietfa.amsl.com>; Mon, 8 Dec 2014 23:55:37 -0800 (PST)
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 7HIUrRI4DvMl for <roll@ietfa.amsl.com>; Mon, 8 Dec 2014 23:55:34 -0800 (PST)
Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1E21A6EE6 for <roll@ietf.org>; Mon, 8 Dec 2014 23:55:33 -0800 (PST)
Received: from roundcube.xs4all.nl ([194.109.20.208]) by smtp-cloud3.xs4all.net with ESMTP id RKvX1p0074VN29601KvXlu; Tue, 09 Dec 2014 08:55:32 +0100
Received: from [2001:983:a264:1:d111:17bf:4c43:8d3a] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 09 Dec 2014 08:55:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 09 Dec 2014 08:55:31 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <8571.1418064454@sandelman.ca>
References: <30100.1416777372@sandelman.ca> <21fd36d565e1ecd9bd96f8f1465b3837@xs4all.nl> <8571.1418064454@sandelman.ca>
Message-ID: <6a448d30463f53ff4a1a508b995e8c26@xs4all.nl>
X-Sender: stokcons@xs4all.nl (zl5Vwylfn5Fmnh6Jw45KDu6j9+fv5aeU)
User-Agent: XS4ALL Webmail
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/uiP6qPWKyKGMIviMfdER839ZIiw
Cc: roll@ietf.org, mcr@sandelman.ca, Anders Brandt <abr@sdesigns.dk>
Subject: Re: [Roll] home-building-requirements section 7.1
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 <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 07:55:37 -0000

Probably we are not going the EAP-PANA route because EAP PANA imposes an 
order of joining determined by the network topology.
Today, that order will not, cannot, is unlikely to, be respected by the 
installation protocol.

Consequently, I like to keep the uncertainty in the document.



Michael Richardson schreef op 2014-12-08 19:47:
> You ask:     > What are enrollment tools?
> 
> By this, I mean that the combination of protocols and/or provisioning
> equipment that allows an installer to make a lightbulb join a 
> particular
> network.
> 
> That's why I want to know, if you are going the EAP-PANA route, that 
> one
> needs to know what EAP methods ought to be supported.
> 
> 
> peter van der Stok <stokcons@xs4all.nl> wrote:
>     > thanks for the encouragement.
>     > Concerning bootstrap and security in general. Many things are 
> going on and
>     > there are two approaches to this document:
>     > 1) a conservative one; restrict to what exists and is is proven 
> to work
>     > 2) leaving the doubt that exists today.
> 
>     > For the moment I like to leave the doubt, because in 5 years, 
> what is sure
>     > today will not be implemented is my conviction
> 
>     > Concerning switching on/off:
>     > That is SDO stuff; KNX , BACnet , etc... are preparing
> additional standards.
> 
>     > What are enrollment tools?
> 
>     > Peter
> 
> 
>     > Michael Richardson schreef op 2014-11-23 22:16:
>     >> I am very pleased with the document; I hope the WG is reading 
> it, and is
>     >> also happy with it.
>     >>
>     >> In secton 7.1 you mention use of PANA to secure new nodes.
>     >> The reference seems very hesistant, and the DTLS relay is just 
> kind of
>     >> thrown in.   Can you make this recommendation more concrete? Or
> remove it.
>     >>
>     >> If it's PANA, I assume EAP is involved, and so what what EAP
> methods should
>     >> be used?
>     >>
>     >> I think that, having read this document, I ought to be able to 
> create a
>     >> light-bulb or light switch --- I think that I can make it 
> function in the
>     >> network, but I don't think it will use the same enrollment tools 
> at all,
>     >> and
>     >> I'd sure like to change that.  I don't mind being really really 
> specific
>     >> here: I encourage it.
>     >>
>     >> I also don't know what protocol to use for turning lights 
> on/off, but I
>     >> acknowledge that is out of scope for the ROLL WG to specify.
> Perhaps there
>     >> is an informative reference I missed.
>     >>
>     >> I think that unless you have a specific way to use the DTLS 
> relay, you
>     >> should
>     >> remove the reference -- it doesn't help anyone trying to 
> implement an
>     >> interoperable device.