Thanks Paul, this PR (and your responses) would resolve my DISCUSS. On Mon, Feb 5, 2024 at 8:16 AM Paul Wouters <paul.wout...@aiven.io> wrote:
> I don't think I saw any response to this from the authors or dnsop, so let > me reply to your DISCUSS points (as individual DNS enthousaist only): > > On Tue, Jan 2, 2024 at 2:44 PM Martin Duke via Datatracker < > nore...@ietf.org> wrote: > >> Martin Duke has entered the following ballot position for >> draft-ietf-dnsop-avoid-fragmentation-16: Discuss >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> 1) I'm unclear about Sec 4, R11 and Appendix B. When configured for >> minimal >> response, are responses to ALL requesters reduced in size, or only to >> those >> requesters that indicate a small MTU? >> > > Responses to all clients are reduced, but only for "gratuitous" NS record > from the authority section. > When queried with qtype=NS, it would still give the full response of > NS/A/AAAA records (and set TC if it did not fit). Although details might > vary per implementation, as there is no RFC definition of a minimal > response. So I think the actual change on the wire is pretty negligible. > > On top of that, there are proposals that could/would mitigate this by > explicitly signaling a query to ask for multiple qtypes at once, if this > would become a problem, eg > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-multi-qtypes-00 > > As DNS becomes a more important vehicle for various discovery protocols >> (e.g. >> ECH), I would hate for responders to globally invoke a policy that makes >> it >> hard to deploy those protocols. But I'm happy to discuss this. >> > > Note that a lot of those connections would be using DoT or DoH for privacy > reasons, and at that point minimal responses does not affect things because > those are meant mostly for UDP only. > > >> 2) In section 3.2, R8, please add RFC 8961 as a normative reference for >> how to >> set the timeout (e.g. "UDP requestors MUST observe [RFC8961] in setting >> their >> timeout.") >> > > A PR proposed for inclusion in the next draft added that reference: > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-avoid-fragmentation/pull/40 > > ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks to Mirja Kuhlewind for the TSVART review, and to the authors for >> responding. >> >> (1) I support Rob's DISCUSS (and Paul's comment) about SHOULD/MAY. "do it >> unless the OS makes it impossible" is a typical use of SHOULD. >> > > See same PR :) > > >> >> (2) Section 3.1, R1 says that responders SHOULD omit the fragment header. >> Under >> what circumstances would it be reasonable to keep it? >> > > I'll update the PR as Eric also commented on that line. The fragment > header should not be there ever because there should not be fragmentation. > > Paul > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
