Martin Duke has entered the following ballot position for draft-ietf-dnsop-avoid-fragmentation-16: Discuss
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/ ---------------------------------------------------------------------- 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? 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. 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.") ---------------------------------------------------------------------- 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. (2) Section 3.1, R1 says that responders SHOULD omit the fragment header. Under what circumstances would it be reasonable to keep it? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
