Encapsulation of 6TiSCH Join and Enrollment Information Elements
draft-ietf-6tisch-enrollment-enhanced-beacon-14

Thanks for addressing my previous DISCUSS and COMMENT points.

** Section 2.  network id.  With the hash truncation for the network ID, please consider if additional guidance is needed to clarify that any truncation will work.

[ Thank you for addressing my DISCUSS position, cleared ]

I found this document to be well written, and helpfully explained the background, issue, etc. Thank you! 

Question:
"Pledges which have not yet enrolled are unable to authenticate the beacons, and will be forced to temporarily take the contents on faith. After enrollment, a newly enrolled node will be able to return to the beacon and validate it."
Yes, this is true - a newly enrolled node will be able to do this -- but I don't see a suggestion / requirement that they actually *do* so. I'm perfectly capable of picking up my socks, but.... :-)

Nit:
"Although However, even in this case, a" - typo / redundancy.

Please also see Qin Wu's Opsdir review (https://datatracker.ietf.org/doc/review-ietf-6tisch-enrollment-enhanced-beacon-08-opsdir-lc-wu-2020-01-21/), which has some useful questions / nits.

Thank you for the work put into this document: it seems simple and easy :-)

Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
"announce the presence of the network" makes me wonder... Do nodes announce the network ? or do nodes announced THEIR presence in the network ? or do router nodes announce the network? or am I too unfamiliar with TSCH ?

-- Section 1.2 --
Please expand "ASN" at first use. I guess that this is not the usual AS Number ;-)

-- Section 1.3 --
Please add a reference for "broadcast aloha slot".

Isn't the word "IETF" in "defines a new IETF Information Element (IE)" redundant in an IETF document ?

-- Section 2 --
"that need addressing via unicast Router Solicitation messages" is unclear to me... Is to do SLAAC ? or look for an actual router?

Add a reference + acronym expansion to RPL at first use.

"This field provides the suffix (IID)" please expand interface ID and, on my side, I do not like naming the IID as a suffix.

-- Section 5 --
Reading and applying RFC 8126 (how to write IANA considerations) would be beneficial.

== NITS ==

-- Abstract --
Suggest to expand TSCH at first use.

-- Section 1.3 --
Unsure whether "reasons: First, there" should have a capitalized "First".

There are also many acronyms that should be expanded at first use (I stopped commenting about those).

Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.

Thank you for addressing my DISCUSS.

— Section 1.2 —

   The EB is used by nodes already part of a TSCH network to annouce its
   existence.

I can’t figure out the antecedent to “its”.  Can you rephrase this sentence to make it clearer?

   There is a limited number of timeslots designated as a broadcast slot
   by each router in the network.

While “a limited number” looks as if it should be singular, it is generally considered plural in usage and needs “are”, not “is” (and the plural “broadcast slots”).  This is a tricky one...

You should also get rid of the “/s” later in the paragraph.

— Section 1.3 —

   if a pledge node does not hear an
   RA, and decides to send a RS

You should be consistent in use of “a” or “an”, and I think “an” works better.

In the numbered list, each item is a complete sentence and should start with a capital letter.  You also should fix the sentence capitalization throughout Section 2.

   This document defines a new IETF IE subtype

Please expand “IE” here.

— Section 3 —

   The Enhanced Beagon

Typo...

   validate the beacon, providing them with a trusted

The end of that sentence is missing.

 + + + + + + + + + + + + + + + + + + + +

The following are comments from Murray Kucherawy, incoming ART AD.  Murray is getting an early start on doing reviews, and I’m including his comments into my ballots during the overlap period before he’s officially an Area Director.

 - - - - - - - - - - - - - - - - - - - -

Mostly minor things here since this is (currently) well outside my domain.

Every reference to "Enhanced Beacon" in this document parses to me as "Enhanced Bacon".

The nits from directorate reports seem to provide good editorial suggestions, though somehow none of them noticed that the second paragraph of Section 1.3 starts "Although However".  It looks kind of like the "although" should actually come after the second comma.

I don't know what to make sure of "(see {?RFC7554})".  Are they not sure about these references?  Or is this a new format thing?

RFC 8137's IANA section seems especially spartan, but there's nothing to be done about that here.  (I discovered this by following a reference.)

In Section 2, "Values range" should be "Values range from".

Same section: "The exact process is a subject of significant research work."  Are we documenting a process we don't understand?  Are any references to said research appropriate here?

The sentence "This value MUST be ignored by pledges..." is a comma splice.

Under "pan priority", should "Acycling" be "Acyclic"?

"nodes'" should be "node's", I think.

Where is PAN/PANID defined?  I did not find it in RFC 6550, 8180, or
draft-ietf-6tisch-architecture, nor in the RFC Editor's list
(https://www.rfc-editor.org/materials/abbrev.expansion.txt).

Thank you for discussing the security considerations of each field
throughout!

Section 1.3

   Although However, even in this case, a unicast RS may be transmitted
   in response[RFC6775] reduces the amount of multicast necessary to do
   address resolution via Neighbor Solicitation (NS) messages, it still
   requires multicast of either RAs or RS.  This is an expensive

nits: two capitalized words in a row, also some further rewording is
needed (and maybe s/unicast RS/unicast RA/?).

Section 2

We should probably say something about the 'res' bits being reserved,
set to zero, and ignored by recipients.

      In most cases, every node sending a beacon will set this flag, and
      in a typical mesh, this will be every single node.  When this bit
      is not set, it indicates that this node may be under provisioned,
      or may have no additional slots for additional nodes.  This could
      make this node more interesting to an attacker.

nit: this phrasing suggests that the list is an exhaustive list of
reasons why the flag could be unset; I'd suggest "it might indicate"
instead.

      This value MUST be ignored by pledges, it is to help enrolled
      devices only to compare different connection points.

nit: comma splice.  Maybe also reword to "It is only to help enrolled
devices to compare different connection points"?

      This field communicates an Interface ID bits that should be used
      for this nodes' layer-3 address, if it should not be derived from

nit: singular/plural mistmatch in "an Interface ID bits"
nit: s/nodes'/node's/

      the layer-2 address.  Communication with the Join Proxy occurs in
      the clear, this field avoids the need for an additional service
      discovery process for the case where the L3 address is not derived
      from the L2 address.  An attacker will see both L2 and L3

nit: comma splice.  I'd also hyphenate "service-discovery".

      once.  That is just a suggestion for a default algorithm: it may
      be set in any convenience way that results in a non-identifing
      value.  In some LLNs where multiple PANIDs may lead to the same

nits: I suggest "Per [RFC6550], that is just a suggestion",
s/convenience/convenient/, and s/identifing/identifying/ (though what
exactly it is that is not being identified might be worth clarifying,
too).

      management device (the JRC), then a common value that is the same
      across all PANs MUST be configured so that pledges that attempt to

nit: I think "all the PANs" is more appropriate, since we only care
about the ones that lead to the same JRC (and there may be other PANIDs
in play).

      enroll do not waste time attempting multiple times with the same
      network that has multiple attachment points.

nit: I'd consider expanding (again) what is being attempted.

      If the network ID is derived as suggested, then it will an opaque,

nit: s/will/will be/

      seemingly random value, and will reveal nothing in of itself.  An

I suggest "will not directly reveal any information about the network".

Section 3

   The sensitivity of each field is describe within the description of
   each field.

nit: s/describe/described/

   visible.  Encrypting the schedule does not prevent an attacker from
   jamming, but rather increases the energy cost of doing that jamming.

Perhaps also the side effects/collateral damage of the jamming.

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.

One question: How is the proxy priority supposed to be calculated/set? Is there a default value?

Is also support points raised in Roman's discuss points. More clarification is needed.

Editorial comment:
I would recommend to repeat the abstract in the intro as, as stated in the RFC style guide RFC7322 section 4.3, "[...] an Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract."

Nit: sec 1.3: 
s/Although However/Although/ or s/Although However/However/ ?
s/a unicast RS may be transmitted in response[RFC6775] reduces the amount of.../a unicast RS that may be transmitted in response [RFC6775] reduces the amount of.../ ? (Also note missing space before [)