É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? -- Section 1 -- Should "ietf-tls-oldversions-deprecate" be normative ? -- Section 2 -- Nicely done to have kept the same sub-section numbers with respect to RFC 5216. Kudos ! -- 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 ? -- 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 ;-) _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
