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

["Eric Vyncke (evyncke)" <[e-mail]>]

Mališa thank you for replying to my comments. I appreciate it.

And thank you and the authors for your work

-éric

From: Mališa Vučinić <[e-mail]>
Date: Thursday, 7 November 2019 at 17:23
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, 6tisch-chairs <[e-mail]>, Pascal Thubert <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)

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

Mališa


On 31 Oct 2019, at 11:04, Éric Vyncke via Datatracker <[e-mail]<mailto:[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.