Hi Michael,
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” ?
- 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?
- 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.
I *think* you mean to say “…many unicast RAs may be sent in response.”
Randy
> On Jul 21, 2018, at 5:37 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote:
>
>
> Pascal Thubert (pthubert) <pthub...@cisco.com> wrote:
>> Also it appears that this draft aims artproposed standard rather than
>> info, doesn't it?
>
> I agree that it needs to be proposed standard.
> The document says Informational, which I agree is wrong, and I'll fix it.
>
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
