Hello, On Tue, 2022-07-26 at 21:13 +0000, Suzanne Woolf wrote: > Dear colleagues, > > > This message starts the Working Group Last Call for > draft-ietf-dnsop-avoid-fragmentation > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). The > requested status is BCP. > > Since we're starting the Last Call during the IETF week, and many folks are > on holidays in the next few weeks, the WGLC will end in three weeks (instead > of the usual two), on August 16. > > Substantive comments to the list, please. It’s fine for minor edits to go > direct to the authors. We need to hear positive support to advance it, or > your comments on what still needs to be done.
Avoiding fragmentation is good. Putting that in a document is also good. But this document is not ready for publication. It also most definitely does not describe Best Current Practice; it also does not prescribe a Best Current Practice I can agree with or even really implement. I'll call out a few specific problems below, but this list is not complete. The (normative!) reference to RFC8900 is very vague. The IP_DONTFRAG reference (well, not really a reference) is handwavy and ill-defined. The discussion of socket options is also incomplete. (See also: Petr's email) > * If the UDP responder detects immediate error that the UDP packet > cannot be sent beyond the path MTU size (EMSGSIZE), the UDP > responder MAY recreate response packets fit in path MTU size, or > TC bit set. If an answer does not fit, there is often no legitimate smaller answer that will fit, as convincingly argued by draft-ietf-dnsop-glue-is-not- optional. Some additionals may be an exception to this. Furthermore, this situation (a responder receiving a message size error from the kernel) is extremely unlikely, unless there is a requester that talks to this responder a lot. (That said, the advice is good.) > * UDP responders MAY probe to discover the real MTU value per > destination. I have no clue how a responder would do this. If I'm wrong, and this is possible at all, the document should explain how this would be done. I assume section 3.2 means the EDNS bufsize in the request when it says "their payload size", but I am not sure. The text could be clearer on that. > * UDP requestors MAY probe to discover the real MTU value per > destination. How? > To avoid name resolution fails, UDP requestors need to retry using > TCP, or UDP with smaller maximum DNS/UDP payload size. This lacks 2119/8174 keywords. "need" sounds like SHOULD or MUST, but I do not think this behaviour should be mandated of implementations. Several resolver implementations currently do none of this, and they work fine on the existing Internet. We should not be adding code compensating for potential breakage we can imagine. So, I suggest this would at most be a MAY, or a lowercase "can retry using ...". > The proposed method supports incremental deployment. In its current shape, this document does not really propose a method for anything. If the document gets updated to provide implementable advice, it should get an Implementation Status section. Section 5 is solid advice. I also agree with the full text of Petr's response. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
