Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)

[Mališa Vučinić <[e-mail]>]

Dear Éric,

Many thanks for your review. You can find the responses to your comments inline and the overall diff following your review at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8e04a2e442cca81c18809b5d6e88ed0d01d012ea?at=minimal-security-14 <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8e04a2e442cca81c18809b5d6e88ed0d01d012ea?at=minimal-security-14>

Mališa

> On 31 Oct 2019, at 11:04, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-6tisch-minimal-security-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-minimal-security/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document. The document is easy to read. I
> have a couple of comments and nits. Feel free to ignore all of them.
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 1 --
> Please add reference to IEEE Std 802.15.4 at first mention.

done

> 
> -- Section 1 --
> It is unclear in this section whether the PSK is per pledge (then hitting a
> scalability issue) or shared by all pledge (then having huge security risk).
> Section 3 is clearer on this but the reader would benefit by knowing this in
> section 1.

-The configuration defined in this document assumes that the pledge and the JRC share a secret cryptographic key, called PSK (pre-shared key).
+The configuration defined in this document assumes that the pledge and the JRC share a unique symmetric cryptographic key, called PSK (pre-shared key).

> -- Section 2 --
> Please consider not using "secret key" and "symmetric key" interchangeably. Esp
> as "secret key" is often used in the context of asymmetric key.

I made the change throughout the document to use the term “symmetric key” exclusively.


> 
> -- Section 3 --
> Unsure whether the text about provisionning "Physically, ..." brings anything
> useful.

If there is no strong opinion here, I left this text for now as in our opinion it gives an idea to the reader on how the provisioning can be done.


> -- Section 3 --
> Please add references to DHCPv6, GRASP, mDNS.

done


> -- Section 4.2 --
> It is unclear whether duplicate address detection should be done.

Section 5.6 of RFC8505 that we reference is clear on this that DAD needs not be done for link-local addresses. I added the following sentence to clarify this in our draft:

+As per {{RFC8505}}, there is no need to perform duplicate address detection for the link-local address.

> 
> == NITS ==
> 
> -- Section 4 --
> Please expand L2 at first mention.

done

> 
> -- Section 6.1.2 --
> I am not a native English speaker but I wonder whether the word 'convergecast'
> is well-known.

rephrased to avoid the use of the term “convergecast”. 

-Due to the convergecast nature of the DODAG, the 6LBR links are often the most congested, and from that point down there is progressively less (or equal) congestion.
+The 6LBR links are often the most congested within a DODAG, and from that point down there is progressively less (or equal) congestion.