IETF Logo Mail Archive

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

Kazunori Fujiwara <fujiwara@jprs.co.jp> Fri, 01 March 2024 05:33 UTC

Return-Path: <fujiwara@jprs.co.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1770EC14F6AA; Thu, 29 Feb 2024 21:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jprs.co.jp
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvJfoJ1uMWsV; Thu, 29 Feb 2024 21:33:09 -0800 (PST)
Received: from off-send41.tyo.jprs.co.jp (off-send41.tyo.jprs.co.jp [202.11.16.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03142C14F61C; Thu, 29 Feb 2024 21:33:08 -0800 (PST)
Received: from off-sendsmg31.osa.jprs.co.jp (off-sendsmg31.osa.jprs.co.jp [172.23.8.161]) by off-send41.tyo.jprs.co.jp (Postfix) with ESMTP id 7CD4F407E19; Fri, 1 Mar 2024 14:33:06 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jprs.co.jp; s=373623; t=1709271186; bh=wEa0lmszGu5vgCgeerJzurZXdD3AXpDOCCuGleJpHKI=; h=Date:To:Cc:Subject:From:In-Reply-To:References; b=NuzPJiGtY+KQKXWePho1h+8rbK6iySgn7i9LFRcZ3auik/hRdGg5+LG7XHK/7QZEF 4BGiyh5/KhXocc3wc7XEWc4De7j2sLdj83gE9kukYE1jM+MLLt+S+SOSijGDEOWuBW rlYKRozIZfy35/bJ/B9JQxFumYguArem+AWNx1Un27SbTtMPLVK7ai00nsWznK8Zy8 R05LiANUahTFzwtpyn/jK1byfR+zsVTh2u/CHk57uK12hVL96KYE5Lpm1QvqBMuCjp Nor7B0ggXaJ3OeHo7l5Fv+LYobzrPghkf3gnPelyVskXZoEydLOQeg1TvQD7+mtbXE d+yomTclnkeDg==
Received: from off-sendsmg31.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss91 (Postfix) with ESMTP id B9790602483A; Fri, 1 Mar 2024 14:33:05 +0900 (JST)
Received: from localhost (off-cpu08.osa.jprs.co.jp [172.23.4.18]) by off-sendsmg31.osa.jprs.co.jp (Postfix) with ESMTP id ADFDF6023B6D; Fri, 1 Mar 2024 14:33:05 +0900 (JST)
Date: Fri, 01 Mar 2024 14:33:05 +0900
Message-Id: <20240301.143305.194444310975613746.fujiwara@jprs.co.jp>
To: martin.h.duke@gmail.com
Cc: iesg@ietf.org, draft-ietf-dnsop-avoid-fragmentation@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, benno@NLnetLabs.nl, swoolf@pir.org, tjw.ietf@gmail.com
From: Kazunori Fujiwara <fujiwara@jprs.co.jp>
In-Reply-To: <20240301.142508.1794953986459211842.fujiwara@jprs.co.jp>
References: <170422464991.2095.8106947965519322565@ietfa.amsl.com> <20240301.142508.1794953986459211842.fujiwara@jprs.co.jp>
X-Mailer: Mew version 6.8 on Emacs 24.5.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSS-9.1.0.1373-9.0.0.1002-28224.005
X-TM-AS-Result: No--13.046-5.0-31-10
X-imss-scan-details: No--13.046-5.0-31-10
X-TMASE-Version: IMSS-9.1.0.1373-9.0.1002-28224.005
X-TMASE-Result: 10--13.046000-10.000000
X-TMASE-MatchedRID: hj0BWi2U9K5CXIGdsOwlUu5i6weAmSDKZggZX8gYmrXae6yRbje9OMWl hj9iHeVp5zCIVbVeggDJPE7IJv9FwjPpmmeZK64qLdBFrfY9r2lY3OxKDW3tXus/IVlBXKLmd28 7y76rWl3rME+4JvD76SHw8qdIxfOjXSJ4c3nT+QcrCLswi3NpjVY2HnZXjT21X30pMm+iz0iNrn 4VvmvKHxpSJNiZ/PIpf4phfqJ4sgGCOcl8jG3i6I4V8tCoXo/SjlRp8uau9oYdnGADWdSDoj2do 3jAGQv/n/kGpC5LADWZI8OviNkMURmN/Nnf4aCNh2VzUlo4HVMLFIl6UtG18BzlIYo2TUIbgRPV y4A/OEY0Yz4DltVB8JGTpe1iiCJqtD9qpBlNF8pGONWF/6P/CuunGEBqPil+pEmIv6Iva04Lbig RnpKlKSPzRlrdFGDwOLIKIW3146XIzhlXYBJJg51mzXmq1Pcd7zrNH6elWL9slyVBEDUtUw==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/M_yCpmBq-jfpveHNYyVB95By6MA>
Subject: Re: [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
Precedence: list
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: Fri, 01 Mar 2024 05:33:14 -0000

I made a mistake in my previous mail.

> From: Kazunori Fujiwara <fujiwara@jprs.co.jp>
> Sorry for too late reply.
> Authors submitted -17 today.
> 
>> From: Martin Duke via Datatracker <noreply@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 <fujiwara@jprs.co.jp>

v2.23.0 | Report a Bug | By Email