Éric Vyncke has entered the following ballot position for draft-ietf-uta-tls13-iot-profile-23: Discuss
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-uta-tls13-iot-profile/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke INT AD comments for draft-ietf-uta-tls13-iot-profile-23 CC @evyncke Thank you for the work put into this document. Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Other thanks to Mohit Sethi, the IoT directorate reviewer (at my request), please consider this recent iot-dir review: https://datatracker.ietf.org/doc/review-ietf-uta-tls13-iot-profile-23-iotdir-telechat-sethi-2026-08-02/ I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Section 2 Reference to draft-ietf-iotops-7228bis is normative per `IoT device-class terminology follows [RFC7228] and [I-D.ietf-iotops-7228bis]. ` ### Section 3 Why not a "MUST" in `For PSK use, endpoints SHOULD use (EC)DHE where possible; see Section 7` ? Or add the guidance required by the IESG statement https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ ### Section 7 Does the guidance for the 2nd "SHOULD" also applies to the first one in `For PSK use, endpoints SHOULD use (EC)DHE to achieve forward secrecy; PSK-only SHOULD be avoided unless the application can tolerate the loss of forward secrecy.` ? The text is unclear. ### Section 13 Please provide guidance for the use "SHOULD" in `Implementations in compliance with this specification MUST implement the RSL extension and SHOULD use it to indicate their RAM limitations.` ### Section 17.2.4 Another "SHOULD" without the required guidance in `The Key Usage extension SHOULD be set`. ### Section 17.4.1 Why not a "MUST" in `Environments that are concerned about such traffic analysis SHOULD use an enrollment protocol to migrate` or rephrase it to state that bypassing the SHOULD will expose the exchange to traffic analysis. ### IoT directorate review While Mohit's IoT-directorate review is fairly recent, please reply to Mohit's review as some points seem important to me: https://datatracker.ietf.org/doc/review-ietf-uta-tls13-iot-profile-23-iotdir-telechat-sethi-2026-08-02/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Section 17.1.5 Who is the "we" in `we advise the use of a device management solution` ? The authors ? The WG ? The IETF community ? Please avoid ambiguities. Possibly also in other places. Use "Coordinated Universal Time (UTC)" in `Values MUST be expressed in Greenwich Mean Time (Zulu) ` "Zulu" is an aviation term that has little value in an IETF document. _______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
