Mahesh Jethanandani has entered the following ballot position for draft-ietf-tls-ecdhe-mlkem-03: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 7, paragraph 0 > This document requests/registers three new entries to the TLS > Supported Groups registry, according to the procedures in Section 6 > of [tlsiana]. These identifiers are to be used with the final, > ratified by NIST, version of ML-KEM which is specified in > [NIST-FIPS-203]. Thanks to Dale Worley for his GENART review. One of the questions he asks is about the Recommended value of N. He references the IANA section that says: If the "Recommended" column is set to "N", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. [...] To which the authors' response was that it was discussed on the mailing list and agreed that it should be kept N. However, the document does not seem to have captured what the discussion was and whether the three entries have limited applicability or are intended only for a specific use case, etc. No reference entries found for these items, which were mentioned in the text: [RFC7748]. Possible DOWNREF from this Standards Track doc to [NIST-FIPS-203]. If so, the IESG needs to approve it. Possible DOWNREF from this Standards Track doc to [NIST-SP-800-227]. If so, the IESG needs to approve it. Possible DOWNREF from this Standards Track doc to [KEYAGREEMENT]. If so, the IESG needs to approve it. Possible DOWNREF from this Standards Track doc to [NIST-SP-800-135]. If so, the IESG needs to approve it. Possible DOWNREF from this Standards Track doc to [NIST-SP-800-56C]. If so, the IESG needs to approve it. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread" ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Uncited references: [rfc7748]. Document references draft-ietf-tls-RFC8447bis, but that has been published as RFC9847. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
