Dear AD, dnsop list; Thanks very much for your review.
Authors submitted -11. https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/11/ Details are inline. > From: Warren Kumari <war...@kumari.net> > 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). We cannot find good references. Changed. OLD: DNS (over UDP) is said to be the biggest user of IP fragmentation. NEW: DNS (over UDP) relies on on IP fragmentation when the EDNS buffer size is set to a value larger than the path MTU. > 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. Removed texts about path MTU discovery. Paul Vixie pointed that some servers use local MTU 9000 and internet MTU 1500. Added limiting 1400. OLD: UDP responders SHOULD compose response packets fit in path MTU discovery results (if available) to measure path MTU discovery attacks, interface MTU and the requestor's maximum UDP payload size [RFC6891]. NEW: UDP responders SHOULD compose response packets that fit in both the offered requestor's maximum UDP payload size [RFC6891], the interface MTU, and the RECOMMENDED maximum DNS/UDP payload size 1400. > 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"? Removed " [ UDP requestors MAY set the requestor's maximum UDP payload size as 1232. ]". > 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… ) Removed texts related to PATH MTU discovery. > 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. fixed as the first option. > 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. fixed as ""Don't Fragment (DF) bit" > 3: Recommendations for UDP responders > O: "UDP responders RECOMMENDED to set" > P: "UDP responders are RECOMMENDED to set" > C: Grammar fixed > 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). fixed as "Recommendations for" > 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." fixed. (with s/than than/than/) > 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… Removed "dns-operations mailing list" and changed as "Prior research [Fujiwara2018] has shown that some authoritative servers ignore the EDNS0 requestor's maximum UDP payload size, and return large UDP responses." Add new text in Introduction for future update. NEW A path MTU different from the recommended value could be obtained from static configuration, or server routing hints, or some future discovery protocol; that would be the subject of a future specification and is beyond our scope here. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
