Éric Vyncke has entered the following ballot position for draft-ietf-dnsop-avoid-fragmentation-16: 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-dnsop-avoid-fragmentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document, DNS is so important for the global Internet that a BCP is welcome. I am afraid that for several reasons I was unable to review correctly this document on time, mainly relying on Vladimír Čunát's DNS-dir review at https://datatracker.ietf.org/doc/review-ietf-dnsop-avoid-fragmentation-16-dnsdir-telechat-cunat-2023-12-27/ . Nevertheless, I support Rob's DISCUSS about the use of MAY/SHOULD about the IPv4 DF-bit in section 3.1; also, an assertion like `many OS kernel constraints make it difficult to set the DF bit` should be backed by a reference. I also find 'light' to rely on TCP MSS as it is set by the end points only, i.e., it can also leads to IPv4 fragmentation in the path (or IPv6 fragmentation by the kernel at the source). Section 3, does `These recommendations are intended for nodes with global IP addresses on the Internet` also cover the use of NAT/NPT when the requestor uses RFC 1918 addresses or ULA? In section 3.1: - R1 why not simply stating that there should be no IPv6 fragmentation ? Atomic fragments are now discouraged for IPv6 - R3 where is the packet size of 1400 coming from ? Some reasoning would be welcome (e.g., based on some measurements over the global Internet). Put at least a forward reference to the appendix. In section 4, R9: where is `13 may be too large` coming from ? Appendix `the authors' recommendation` is it a recommendation by the authors or by the IETF in an IETF stream document? -éric _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop