Re: [DNSOP] Martin Duke's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS and COMMENT)

[Kazunori Fujiwara <[e-mail]>]

Sorry for too late reply.
Authors submitted -17 today.

> From: Martin Duke via Datatracker <[e-mail]>
> 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).

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.

> 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.")

  added (but, "SHOULD")

> ----------------------------------------------------------------------
> 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.

  Changed as
  "R2.  Where supported, UDP responders SHOULD set IP "Don't Fragment flag (DF) bit" [RFC0791] on IPv4.

> (2) Section 3.1, R1 says that responders SHOULD omit the fragment header. Under
> what circumstances would it be reasonable to keep it?

  Changed as "R1.  UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200]."

--
Kazunori Fujiwara, JPRS <[e-mail]>