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ć <[email protected]> Date: Thursday, 7 November 2019 at 17:23 To: Eric Vyncke <[email protected]> Cc: The IESG <[email protected]>, 6tisch-chairs <[email protected]>, Pascal Thubert <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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.
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
