I made a mistake in my previous mail. > From: Kazunori Fujiwara <fujiw...@jprs.co.jp> > Sorry for too late reply. > Authors submitted -17 today. > >> From: Martin Duke via Datatracker <nore...@ietf.org> >> Date: Tue, 02 Jan 2024 11:44:09 -0800 > >> 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. > > When there is a data corresponding to the query, > each DNS response contains one RRSet that matches query (qname, qtype, qcalss) > in the authority section. (Section 4.3.2 of RFC 1034). ^^^^^^^^^ answer
> If a domainname have multiple HTTPS/SVC RRs (that have complex ECH), > it is an RRSet. > > Many 'minimal-responses' implementations simply omit unnecessary RRs, > and the RRSet corresponding to the query responds as is. > > Some query types requires additional data in the additional section. > It is written in third paragraph of Appendix B. > > For example, > MX RR requests mail exchange's A/AAAA into the additional section. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop