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
