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

From: [email-masked]
Date: Fri, 20 Jul 2018 17:00:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG of the IETF.

        Title           : IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information
        Authors         : Diego Dujovne (editor)
                          Michael Richardson
	Filename        : draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt
	Pages           : 8
	Date            : 2018-07-16

Abstract:
   In TSCH mode of IEEE802.15.4, as described by [RFC8180],
   opportunities for broadcasts are limited to specific times and
   specific channels.  Nodes in a TSCH network typically frequently send
   Enhanced Beacon (EB) frames to announce the presence of the network.
   This document provides a mechanism by which small details critical
   for new nodes (pledges) and long sleeping nodes may be carried within
   the Enhanced Beacon.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6tisch-enrollment-enhanced-beacon-00
https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-enrollment-enhanced-beacon-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 21 Jul 2018 00:10:28 +0000

Hello Michael:

I added the replacement tag to point on your earlier draft. 
Also it appears that this draft aims artproposed standard rather than info, doesn't it?

Cheers

Pascal

> -----Original Message-----
> From: 6tisch <[email-masked]> On Behalf Of [email-masked]
> Sent: vendredi 20 juillet 2018 20:01
> To: [email-masked]
> Cc: [email-masked]
> Subject: [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-
> 00.txt
> 
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Michael Richardson <[email-masked]>
Date: Sat, 21 Jul 2018 17:37:50 -0400

> Also it appears that this draft aims artproposed standard rather than

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Randy Turner <[email-masked]>
Date: Sun, 22 Jul 2018 19:42:21 -0400

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 <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Jul 2018 09:45:47 -0400

Randy Turner <[email-masked]> 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

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.

    > 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  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [