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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Wed, 19 Feb 2020 07:29:21 -0800

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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Feb 2020 19:00:33 +0100

Magnus Westerlund via Datatracker <[email-masked]> wrote:
    > Martin Duke (Incoming TSV AD) provided the below comments and proposals
    > that could improve the document, please consider them:

my address book does not have Martin's email, so I'll assume he can read the
iesg list.

    > 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).

Oops, thank you for these.

    > 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

Rewording. I feel that may have made it worse, please see:

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

done.

    > "rank priority" definition: s/willing/willingness

done.

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

done.

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

ok.

    > "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 .."

edited.

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

got it.

    > 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.

I asked the WG if they wanted the issues in the main body or the Security
Considerations, and there was a preference to put the description in with the
body next to each item, as that would be more likely to be read.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-