Re: [6tisch] xxx-bootstrap

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.

Peter

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 <stokcons@xs4all.nl> 
>> 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
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch