[DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-avoid-fragmentation-16: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

É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