Re: [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt

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+ietf@sandelman.ca> wrote:
> 
> 
> Pascal Thubert (pthubert) <pthubert@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+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch