Hi Michael,
I had the following comments after reading the secure-join-01 draft...apologies for any misinterpretations...I'm catching up after being away from this for awhile...
- Will this document “standalone” indefinitely ? Or will this get merged into the 6tisch core document as a “secure join” chapter ?
- Is the “cryptographic key material” identified in the definition of “imprint” the 802.1AR stuff? Or is the cryptographic key material obtained “using” the 802.1AR cert ?
- Section 1.3.2 “…some Aloha time…” should probably have a reference for “Aloha”
- Section 2.2.1 What about listening for a beacon on “all available channels” rather than “16” ?
- When mixing layer 3 information at layer 2, will there be an API (6top?, other?) that provides a way to move this information back and forth from L2/L3 ? Or would implementations do this in a proprietary fashion?
- If we are operating a network that doesn’t have a privacy issue with IIDs, can the JA avoid having to create the virtual insecure link-local address ? in other words, could this behavior be optional?
- Can I say that “An ‘insecure’ packet is any packet (L2 or L3) NOT secured by “K2” ?
- Section 1.3.1.1 “Perfert Forward Secrecy”
- Section 2.2.3 – is this section talking about DAD for link-local addresses? If so, is this necessary? Could this be optional?
- When a JN responds to a JA enhanced beacon with a unicast NS, I’m assuming the JN derives the NS destination IP address from the JA MAC address ?
- Section 3.1 For interoperability purposes, don’t we need to mandate at least one registrar discovery method ?
- Section 3.1 What’s an ASA ? Should this be defined or referenced prior to using this acronym in the document?
- Section 3.2 The IID in the ARO is based on the JN MAC Address ?
Interesting reading….thanks!
Randy
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
