Randy Turner <rtur...@amalfisystems.com> wrote:
> Looking at the enrollment-enhanced-beacon draft, I think some vendors
> already employ this technique to address the bandwidth issues you
> raise
> in the draft (advertisement slots, etc.)….so the rationale for this
> draft is probably well established. I had a couple of comments on this
> early text…
> - Section 2, “Network Name” - would this serve the same purpose as an
> 802.11 “SSID” ?
Yesish.
My intent is that this is not something that is selected, but rather
something that is easily calculated in a RPL network from the DIO.
> - It looks like a join assistant would be chosen based on examining
> “network id” first, then “PAN priority”, and then “proxy priority”.
> And the “rank priority” would somehow be passed across layers to RPL
> for subsequent parent selection. Is this correct?
As I understand the desire, there is a desire to balance between different
PANs, and to do some of this via RPL values. So, the rank priority would
influence which network to join. Parent selection would occur afterwards
as normal.
> - In section 1.3, there is text that says...
> if a pledge node does not hear an RA, and decides to
> send a RS (consuming a broadcast aloha slot with unencrypted
> traffic), many unicast RS may be sent in response.
That's about a node operating as a leaf (a host), rather than as a router.
> I *think* you mean to say “…many unicast RAs may be sent in response.”
I'm not sure what belongs here.
I was going to say, many->MAY, but I think the whole paragraph needs
adjustments.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
