Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-mud-iot-dns-considerations-12: 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-iot-dns-considerations/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-iot-dns-considerations-12 Thank you for the work put into this document. It is a nice piece of work, clear and easy to read. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Henk Birkholz for the shepherd's detailed write-up including the WG consensus and the *very light* justification of the intended status. Please note that Dave Thaler is the IoT directorate reviewer (at my request) and you may want to consider this iot-dir review as well when it will be available (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/reviewrequest/19052/ You may also expect an Int-dir review as: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/reviewrequest/19051/ (not yet assigned though) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Absence of mDNS Is mDNS used in the context of MUD ? If so, then it should be mentioned here. ## Abstract Let's be positive s/This document details concerns /This document details considerations / ## Section 1 s/Some Enterprises do this already. /Some organisations do this already. / ? (e.g., governmental agencies, ...) Suggest to put the sentence `The first section of this document...` on its own 1-sentence paragraph. ## Section 3 Suggest to always use "DNS names" rather than plain "names". Applicable in several places in the document. Isn't the mapping from address to DNS names usually called "reverse mapping" ? E.g., section 3.1.3 uses `reverse names`. ## Section 3.1 Suggest to add "often" in the too assertive sentence `Attempts to map IP address to names in real time fails for a number of reasons`. ## Section 3.1.2 `They could determine when a home was occupied or not`: actually when I leave home to travel (e.g., to IETF-119) most of my IoT devices are still active as I want to 'control' my home from remote. ## Section 3.1.3 `Service providers` is rather vague in this context, is it the access/internet SP or a hosted-IoT-service ? ## Section 3.2 It seems indeed to be the most obvious technique. So obvious that it should be given a hint in the introduction. Is there a common use case where the MUD controller is changing location ? I.e., then having different forward DNS resolution answers ? I would also expect the authoritative geo-sensitve servers will use a short DNS TTL in their answers. ## Section 4 Thanks for pointing me to "antipatterns", I learned something :-) OTOH, I had to follow the link to understand the paragraph :-( ## Section 4.3 Unsure whether using a real case with Amazon is useful here... ## Section 5 Whether the MUD devices and the MUD controllers use the same recursive resolver is probably orthogonal to the use of DoT/DoH. ## Section 6 AFAIK, LLDP can also be used per RFC 8520 in addition to DHCP to retrieve the MUD string. ## Section 6.5 The section title is about `Prefer DNS servers learnt from DHCP/Route Advertisements` but the text is only about DHCP. Btw, the exact wording is "Route*r* Advertisement" and a reference to RFC 8106 could be useful. Which are the reasons in `There are a number of reasons to avoid this` ? ## Section 7 `The use of non-local DNS servers exposes the list of names resolved to a third party` even if the recursive resolution is done 'locally' (i.e., on a CPE) it will leak the MUD requests, we could argue that using a non-local recursive resolver will only expose the requests to this non-local server but not to the actual authoritative server. ## References Please note that DNR & DDR are published as RFC 9462 / 9463 (dated November 2023). _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
