Thanks, Qin.
(1) Timeout in nodeA can be triggered either by failure in
nodeA=>nodeB request process and by failure in nodeB=>nodeA response
process (i.e the process in above example). nodeA cannot tell exact
reason for a event of Timeout by itself. In another word, nodeA
cannot tell there is a
Dear all,
I am wondering if there is any policy on when 6P reservations request and
responses (the “6P transaction”) should be sent (when e.g. doing
neighbor-to-neighbor scheduling). In the 6TiSCH minimal configuration there is
not really a need for this because of the static schedule (the one
Hi Yasuyuki,
(1) Timeout in nodeA can be triggered either by failure in nodeA=>nodeB request
process and by failure in nodeB=>nodeA response process (i.e the process in
above example). nodeA cannot tell exact reason for a event of Timeout by
itself. In another word, nodeA cannot tell there is a
Hi Peter,
Yes, that is correct, we propose to use OSCOAP for communication between JN and
JCE. In the model, JA is a CoAP proxy so the choice of OSCOAP and EDHOC was
quite natural. We use CBOR/COSE to transport the keys and the short 15.4
address. Certificate enrollment belongs to Phase 1, and
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
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
