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

Martin Duke via Datatracker <noreply@ietf.org> Tue, 02 January 2024 19:44 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E92C15199D; Tue, 2 Jan 2024 11:44:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-avoid-fragmentation@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, benno@NLnetLabs.nl, swoolf@pir.org, tjw.ietf@gmail.com, tjw.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <170422464991.2095.8106947965519322565@ietfa.amsl.com>
Date: Tue, 02 Jan 2024 11:44:09 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sgoSHMc_boOWxpIcx1YfnoDS5xk>
Subject: [DNSOP] Martin Duke's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jan 2024 19:44:10 -0000

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?