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 <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
