Hi Authors, Just a note/reminder that I am stepping down as an AD in March. I don’t think that I’ve seen any reply to my DISCUSS comments (perhaps the authors and/or WG are still discussing the resolution), but if you are able to speed this up at all so that I can clear my discuss before I step down that would be preferable. Actually, if you manage to clear all the DISCUSSes on this doc before March, so that Warren can approve it before the new IESG is seated, that would probably make both yours and Warren’s lives slightly easier at the transition.
Regards, Rob From: DNSOP <dnsop-boun...@ietf.org> on behalf of Robert Wilton via Datatracker <nore...@ietf.org> Date: Tuesday, 2 January 2024 at 15:41 To: The IESG <i...@ietf.org> Cc: draft-ietf-dnsop-avoid-fragmentat...@ietf.org <draft-ietf-dnsop-avoid-fragmentat...@ietf.org>, dnsop-cha...@ietf.org <dnsop-cha...@ietf.org>, dnsop@ietf.org <dnsop@ietf.org>, be...@nlnetlabs.nl <be...@nlnetlabs.nl>, swo...@pir.org <swo...@pir.org>, tjw.i...@gmail.com <tjw.i...@gmail.com>, tjw.i...@gmail.com <tjw.i...@gmail.com> Subject: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS) Robert Wilton has entered the following ballot position for draft-ietf-dnsop-avoid-fragmentation-16: 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-dnsop-avoid-fragmentation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, Thanks for this document. I'm echoing Paul's and the SECDIR review comments here on the use of MAY in recommendations (since everywhere you see MAY it is equally valid for an interpretation to treat it as "MAY NOT"), but I think that this makes the document, as a proposed BCP, unclear enough that I'm raising this to level of a DISCUSS. (1) p 3, sec 3.1. Recommendations for UDP responders At the time of writing, most DNS server software did not set the DF bit for IPv4, and many OS kernel constraints make it difficult to set the DF bit in all cases. Best Current Practice documents should not specify what is currently impossible, so R2, which is setting the DF bit, is "MAY" rather than "SHOULD". I think that this recommendation, particularly because it is using RFC 2119 language, is unclear. I would suggest rephasing this to something like: R2. Where supported, UDP responders SHOULD set IP "Don't Fragment flag (DF) bit" [RFC0791] on IPv4. (2) p 3, sec 3.2. Recommendations for UDP requestors R6. UDP requestors SHOULD limit the requestor's maximum UDP payload size to the RECOMMENDED size of 1400 or a smaller size. I find this recommendation to be unclear because it mixes both a "SHOULD" and "RECOMMENDED", i.e., I find it unclear as to what the "SHOULD" applies to. Is the recommendation (i) that UDP requestors should limit the maximum UDP payload. Or (ii) is the recommendation that a limit of 1400 be used, or (iii) perhaps both. Maybe rewording this to something like the following would help: R6. UDP requestors SHOULD limit the requestor's maximum UDP payload size to 1400 bytes, but MAY limit the maximum UDP payload size to a smaller size on small MTU (less than 1500 bytes) networks. or, R6. UDP requestors SHOULD limit the requestor's maximum UDP payload size. It is RECOMMENDED to use a limit of 1400 bytes, but a smaller limit MAY be used. (3) p 3, sec 3.2. Recommendations for UDP requestors R7. UDP requestors MAY drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks. As written, I don't think that this is really a recommendation. Either it is a just a statement or fact (in which case it is not a recommendation), or it should be upgraded to a SHOULD. (4) p 4, sec 3.2. Recommendations for UDP requestors R7. UDP requestors MAY drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks. R8. DNS responses may be dropped by IP fragmentation. Upon a timeout, to avoid resolution failures, UDP requestors MAY retry using TCP or UDP with a smaller EDNS requestor's maximum UDP payload size per local policy. Again, I think that this document would be clearer if this was a SHOULD rather than a MAY. Regards, Rob _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
