Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-mud-tls-15: 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-opsawg-mud-tls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-tls-15 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Thomas Fossati for the 18-month old shepherd's detailed write-up including the WG consensus and a *very light* justification of the intended status. Other thanks to Miek Gieben, the Internet directorate reviewer, please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-opsawg-mud-tls-15-dnsdir-telechat-gieben-2024-07-27/ (alas there is still no mention to RFC 7858 in this revision even after Tiru's 2024-07-29 email) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Section 12.2 Please fix this, there are 2 normative references listed for RFC 6234 & 5869 that are not used at all, i.e., remove all unused references (per idnits tool). ## Section 1 Like observed by Roman, using an 8-year old reference as the foundation of this document may indicate that this document may be useless in 2024. In `Specifically, malware may not use the DoH server provided by the local network` please add references to ADD RFC. Humm, I wonder why there is "mud" in the I-D title if the document contains `This is superior to the layers 3 and 4 ACLs of Manufacturer Usage Description Specification (MUD)` ;-) ## Section 3 "middlebox" is used but not specified in this document, suggest using the right MUD terminology. The ambiguous "middlebox" also appears in other sections. Is ` end-of-life of a device` linked to ` IoT manufacturer no longer supports the device`, I guess so but this is not clear at all. Please add a reference to "Slowloris". ## Section 5.2 As some IoT devices won't ever be updated, should the YANG module also support *obsoleted* TLS versions ? A very contentious decision of course but I would prefer to support it than ignoring old devices. # NITS (non-blocking / cosmetic) ## Section 7 The example includes `2019-18-06T` could it be refreshed to 2024 ? _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
