Re: [6tisch] xxx-bootstrap

peter van der Stok <> Wed, 30 November 2016 10:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47D55129E86 for <>; Wed, 30 Nov 2016 02:10:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UHLKbZLLqVXd for <>; Wed, 30 Nov 2016 02:10:53 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACFA5129E95 for <>; Wed, 30 Nov 2016 02:08:02 -0800 (PST)
Received: from ([]) by with ESMTP id EA7z1u00f4QBLo201A7zMg; Wed, 30 Nov 2016 11:07:59 +0100
Received: from ([]) by with HTTP (HTTP/1.1 POST); Wed, 30 Nov 2016 11:07:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Wed, 30 Nov 2016 11:07:59 +0100
From: peter van der Stok <>
To: Mališa Vučinić <>
Organization: vanderstok consultancy
In-Reply-To: <>
References: <> <>
Message-ID: <>
X-Sender: (xP/kpQrQjankzHjIkT3eAz66ZwmiIGRw)
User-Agent: XS4ALL Webmail
Archived-At: <>
Cc: 6tisch <>, sandeep kumar <>,
Subject: Re: [6tisch] xxx-bootstrap
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Nov 2016 10:10:55 -0000

Hi Malisa,

thanks for the answer. I am happy to read that there is a shared concern 
about reuse.

My concern is the communication between joining node and central node.

Did I understand correctly that you propose to use oscoap for the 
communication between joning node and central node?
what content-formats do you propose to transport between joining node 
and central node? Will those be different in phase 1 and 2?
What contents do you propose to transport? certificates, YANG/CBOR 
documents, keys?
How should I see the co-existence between phase 1 and phase 2? Will 
phase 2 be an extension of the transported contents of phase 1?
Apologies for the naivety of my questions, but the number of discussed 
possibilities at this moment are quite overwhelming.

I just like to get clear how the bootstrap can be composed of different 
standardized parts and where the future evolution is.
Identifying and describing those parts will be a nice step forward.


Mališa Vučinić schreef op 2016-11-30 10:22:
> Hello Peter,
> My understanding of the IETF 97 meeting outcome is that Phase 1
> solution will be anima-compatible i.e., it will provide zero-touch
> bootstrapping with manufacturer-installed certificate as the start
> state and locally relevant credential as the end state. At the moment,
> I believe that Michael’s proposal for Phase 1 is quite 6tisch agnostic
> and it can be used in other scenarios.
> However, the end state of Phase 2 are 6tisch-specific key(s) (cf.
> minimal draft) and temporary network identifiers that we tackle in the
> minimal-security draft. This builds upon existing work in 6tisch and
> will be needed no matter what common bootstrapping approach is used.
> Mališa
>> On 30 Nov 2016, at 09:06, peter van der Stok <> 
>> wrote:
>> Hi 6tisch bootstrap followers,
>> Curently, we live in a confusing world wih many bootstrap proposals.
>> They all seem to have in common; a joining node, an assistant, a 
>> central authority, and Michael Richardson.
>> While each bootstrap proposal seems to have a different naming 
>> history.
>> Joking apart, I like to plead for a commmon bootstrap approach in 
>> 6tisch, and anima to share parts of the bootstrap protocols.
>> I suspect that the discovery and the push- or pull start will be 
>> technology and context dependent.
>> My concern is with the number of protocols that the central authority 
>> has to support.
>> When there are too many bootstrap approaches, we may end up with as 
>> many protocol converters as there are bootstrap protocols.
>> The anima bootstrap team has recognized the importance of low resource 
>> devices by supporting the use of coap.
>> The drafts "EST over coaps" demonstrate that the support of two 
>> protocols (coap and http based) in the cental authority is realistic.
>> My plea is that we find a common protocol that replaces EST for the 
>> coap nodes.
>> I understand that after the bad experience with CoMI, the 6tisch 
>> people do not want to be dalayed again by waiting for a common 
>> approach.
>> Nevertheless, I think it is worthwhile to explore this avenue.
>> Any comments?
>> Peter
>> --
>> Peter van der Stok
>> _______________________________________________
>> 6tisch mailing list