[Sending this to the whole group at Michael's request.]
Michael - Re-reading this carefully I had some questions about this
document.
* In section 3.2 you refer to kelsey-intrarea-mesh-link-establishment a
couple of times as a way to do key exchange. Reading that document
it seems to me like it gives me a way to exchange parameters, but
doesn't define anything with regard to key exchange, yes?
* 3.4 Was there a final decision on End to End? Do you have a strong
opinion? It seems to me that DAO is the right answer.
* 6.1.8 I feel like I'm missing how the JN or JA or LBR figures out who
the JCE is.
* 12.2 jamming: "what prevents a node from transmitting when it is
not their turn" nothing, unfortunately.
* 12.2 "can a node successfully communicate with a peer at a time
when not supposed to" this is up to us to some extent. The MAC is
certainly capable of strictly enforcing the schedule, so in an RX slot
from A it can (and will, in the products that Dust ships) reject a packet
from B even if it has the right MIC. Doesn't help in aloha slots of
course.
At a high level, it seems like you are leaving open the possibility
that the
joining network and the production network might be physically the same
devices but with different DODAG, L2 resources, etc? I'm trying to figure
out why I need the new LDevID. Won't I need to go through essentially
the same process again with the production network? I feel like I'm missing
something.
ksjp
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
