[6tisch] Magnus Westerlund's No Objection on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with COMMENT)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-6tisch-enrollment-enhanced-beacon-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Martin Duke (Incoming TSV AD) provided the below comments and proposals that
could improve the document, please consider them:

First, Section 1 is an excellent description of the motivation for the document.

Sec 1.2. "synchronization of ^the^ Absolute Slot Number..."
"carrying ^the^ timeslot template identifier..."
at the end of section, the acronym for Router Advertisements is incorrectly
given as (RS).

Sec 1.3. Proposed rewording for the second paragraph:
"However, while a unicast RS transmitted in response [RFC6775] reduces the
amount..." s/RAs or RS./RAs or RSes. In reason #3, please provide some sense of
order of magnitude instead of "a very long time"

Section 2. Please expand the following acronyms on first use: 6L$, RPL, PAN,
JRC.

"rank priority" definition: s/willing/willingness

Proposed rewording of 4th paragraph in "rank priority":
"Pledges MUST ignore this value. It helps enrolled devices to compare
connection points."

"pan priority" definition, last paragraph: insert comma after "observed PANID
in the Beacon"

"Join Proxy Interface ID" definition:
This field communicates the Interface ID bits that should be used
      for this node's layer-3 address, if it should not be derived from
      the layer-2 address.  Communication with the Join Proxy occurs in
      the clear. This field avoids the need for an additional service
      discovery process .."

"network ID": s/convenience/convenient, s/identifing/identifying

last paragraph: "...the it will be an opaque, seemingly random value, and will
reveal nothing by itself."

Finally, throughout Section 2 the draft mentions potential information leakage
to attackers. Two comments on this: - I believe "proxy priority" creates a
similar exposure, but doesn't mention it. - It might be good to summarize these
issues in the Security Considerations as well.