Magnus Westerlund via Datatracker <[email protected]> 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.
> 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).
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
> order of magnitude instead of "a very long time"
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.
> "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."
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 protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
