Hi there authors (and WG!), Thank you for this document, I found it clear, useful, and an easy read.
I do have a few comments/nits to (hopefully!) further improve the document; addressing these now should help the IETF LC and IESG evaluation go more smoothly. Please SHOUT LOUDLY once you've had a chance to address these, and I'll start IETF LC. Comments / questions: 1: Intro: "DNS (over UDP) is said to be the biggest user of IP fragmentation." Q: Is there a citation for this? (I'm sure it is true, but having a reference would be nice). 2: Recommendations for UDP responders "UDP responders SHOULD compose response packets fit in path MTU discovery results (if available) to measure path MTU discovery attacks, … " C: I'm not fully able to parse this. I think that this is saying that I should try make my packet fit within the discovered path MTU (if I've discovered a path MTU), but I get confused why this is being done "to measure path MTU discovery attacks". I suspect I'm missing something obvious here. Breaking this into two sentences might help. 3: Recommendations for UDP requestors 3.1: "UDP requestors SHOULD limit the requestor's maximum UDP payload size to 1400 or smaller size. [ UDP requestors MAY set the requestor's maximum UDP payload size as 1232. ]" I'm also having a hard time parsing this, especially the relationship between the sentences. The second sentence seems to be a subset of the first sentence (e.g: "Please choose a number between 1 and 10. You may choose 7…") I don't really understand what this is trying to say, but taking a guess, would this work: "The requestor's maximum UDP payload size SHOULD be to 1400 or less, with 1232 being the RECOMMENDED value"? 3.2: "UDP requestors MAY perform "Path MTU discovery" per destination to use the requestor's maximum UDP payload size larger than 1400. Then, calculate their requestors' maximum UDP payload size as …" I found this somewhat tricky to parse — would "In order to use UDP payload sizes larger than 1400, UDP requestors SHOULD perform per-destination Path MTU discovery"? (Note the change from MAY to SHOULD because of the reordering of the sentence; I *think* that this maintains the intent, but… ) Nits: 1: Abstract: O: "This document proposes to avoid IP fragmentation in DNS." P: "This document proposes techniques to avoid IP fragmentation in DNS." or "This document proposes avoiding IP fragmentation in DNS." C: Readability, and I think that the first option is better. 2: Intro: O: "This document proposes to set the "Don't Fragment flag (DF) bit" [RFC0791] on IPv4 and not to use "Fragment header" [RFC8200] ..." P: This document proposes that implementations set the "Don't Fragment (DF) bit" [RFC0791] on IPv4 and not using "Fragment header" [RFC8200] ..." C: Grammar. Also, I changed "Don't Fragment flag (DF) bit" to "Don't Fragment (DF) bit", but I think that "Don't Fragment (DF) flag" would also work. 3: Recommendations for UDP responders O: "UDP responders RECOMMENDED to set" P: "UDP responders are RECOMMENDED to set" C: Grammar 4: Request to zone operators and DNS server operators I think that this would be better as "Recommendations for zone operators and DNS server operators" or perhaps "Suggestions for…" (it is unclear who is "requesting" the change). 4.1: "Notably, the signature size of ECDSA or EdDSA is smaller than RSA." I think that this is better as "Notably, the signature sizes of ECDSA and EdDSA are smaller than than those for RSA." 5: Protocol compliance O: "In prior research ([Fujiwara2018] and dns-operations mailing list discussions), there are some authoritative …" P: "Prior research ([Fujiwara2018] and dns-operations mailing list discussions) has shown that some authoritative …" C: I'm not really sure that "and dns-operations mailing list discussions" is a useful citation. I think it might be better to either drop that, or provide links to specific messages. If you do keep it, I think that you should at least provide a reference to "dns-operations mailing list" ( perhaps https://lists.dns-oarc.net/mailman/listinfo/dns-operations ?). This is especially important because it is easy for readers to get confused between the DNS-OARC dns-operations list and the IETF DNS Operations WG mailing list… Thank you again; I know that making edits to address nits can be annoying, but we are expecting many people to read and review the document, and so having it polished is important and polite (also, once people start commenting on nits, they seem to continue :-) ) W
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
