Hi Éric, Thank you for your review. Answers in-line:
On 12/10/20 4:13 PM, Éric Vyncke via Datatracker wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-emu-eap-tls13-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-emu-eap-tls13/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. Improving EAP-TLS is indeed > welcome! BTW, I left the security review to the SEC Area Directors. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated), and some nits. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > -- Abstract -- > Should the abstract briefly talk about EAP? Good point. I have updated the draft in github: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/baaf9a03c5f282e9904da60700687e248bebe28c > > -- Section 1 -- > Should "ietf-tls-oldversions-deprecate" be normative ? I believe that informational is the correct choice. We are only informing readers and implementers of this draft that old versions of TLS (1.0 and 1.1) are being deprecated. They don't strictly need that information for implementing EAP-TLS with TLS 1.3. However, I don't have strong opinions and can reconsider. > > -- Section 2 -- > Nicely done to have kept the same sub-section numbers with respect to RFC > 5216. > Kudos ! Thank you for the positive feedback. > > -- Section 2.1.1 & 2.1.3 & 2.1.4 -- > I find "This section updates Section 2.1.1 of [RFC5216]." a little ambiguous > as > it the 'updated section' is not identified clearly. I.e., as the sections in > RFC 5216 are not too long, why not simply providing whole new sections ? You have a valid point. However, since this document updates and not obsoletes RFC 5216, we found it sub-optimal to repeat the text. We have written this document for a developer who already has an EAP-TLS implementation and wants to update it for use with TLS 1.3. Thankfully, large parts of the update complexity are actually handled by the underlying TLS library leaving only a small amount of change needed from an EAP-TLS developer. > > -- Section 5.9 -- > What is the added benefit of this section (pervasive monitoring) compared to > section 5.8 (privacy considerations)? Esp when I am afraid that pervasive > monitoring is deeper in the network rather than in the access network (happy > to > be corrected) > > == NITS == > > None of us are native English speaker, but "e.g." as "i.e." are usually > followed by a comma while "but" has usually no comma before ;-) Good point. I think I have added a comma after all instances now: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/7cbce9b8c3ad05a6406a8c48d5b1cbefe23faf47 --Mohit > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
