IETF Logo Mail Archive

Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

"Wessels, Duane" <dwessels@verisign.com> Fri, 29 October 2021 20:54 UTC

Return-Path: <dwessels@verisign.com>
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 5A38F3A1715; Fri, 29 Oct 2021 13:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r91Vmim_THtj; Fri, 29 Oct 2021 13:54:00 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195163A1711; Fri, 29 Oct 2021 13:53:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2033; q=dns/txt; s=VRSN; t=1635540842; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=1Ftwq2IClUp/UR855Jbr5FsT6d9WVWoQg7a8LvyCsp0=; b=YpFNZhMXxwlaaSlrwsur2vuPrAAYEsrUp7EWyUOksQPVSg8pRZF38m+s rTTF5Mk18ogBbm4SPK1dhnejp3iLww5YtnwZndVC86jvjFmXqlelFdNWl f27SbgTbUFE/khfdky7CaD/59UilOS1M+jYqj7CohNgqTCcFBu4lYfr+1 6K/ydmHrTQdfc/01fkIyy7quQa0kYN+WNqKQg1F7j5atIDPN/HN5XsNB/ Wocj27tGq1Vsz5uYkWCe82NYRtvZjCN/+rMNWhBoczQehZMOKwE2V67Ob BBNobFFNQ6lMmE5t/hBsFPMuBbpBIoh+tMuW77ksz6SbahHNphxZWP6Km Q==;
IronPort-SDR: SE4+zkEHhafTwCAnyFCpGaZHFaVx58QZ5RFfPMezlUngCr7jgWI8IkIZ7PgE0zRmfh4/DbdZlW Sw6GLEqy227/lB8l+YtbIsAWeiHgWTMUghMJAX1gICEQwXv6YYm9zLgk/+XxIYmezg+wwzVhpn 8YNzwb9EOIIvFMtE6V77LruqByI54o5jepv29gxZC61YHinoNVFUUxm57NPwziTF4JCq/u+4cH UJHd41p64A5kw5UFZa0Opf6IYRpNGkxjLrdzHU+b72E+qELBczIs65VODidlMxSP53yyIG7Sr2 Pwo=
IronPort-Data: A9a23:I7Nw+KjrjsTwqmiF7z0pzZG/X161eBEKZh0ujC45NGQN5FlHY01je htvXDqGP6mKa2Xycthwbt6/9U9Xu8SAytE2HFBsrCBnHnwW8JqUDtmndUqhZCn6wu8v7K5EA 2TyTvGacajYm1eF/k/F3oAMLhCQ7InQLlbGILes1htZGEk0F0/NtTo5w7Rg29Yy0IDja++wk YiaT/P3aQfNNwFcbzp8B5Kr8HuDa9yr5Vv0FnRnDRx6lAe2e0s9VfrzFonoR5fMebS4K8bhL wr1IBFVyUuCl/slIovNfr/TLBVWEuaKVeSEoiI+t6OK2nCuqsGuu0qS2TV1hUp/0l20c95NJ Npl9pGeWw4Mb4r3nc8Zb0FzTypsIId79+qSSZS/mZT7I0zuWUHKmspIIXFuZMsG8eFtGSdH+ boGMisLKBuEgopawpriEq812Z9ldZSwet9P0p1j5Wix4fIOTY/OWL7H4cRwwjoqh9tPEvCYb M0cAdZqRE2ZO0EQYQ5OYH44tOC4vV3wTTF/kW2QhoM+wHP69CBNibe4ZbI5ffTPH625hH2wo mvc5Ez0DR4XLsDZziCKmlqti/TAtSL2RIxUE6e3ntZmmlSd2ikSBQEYEFe9uv6hz0K4QJdDI FRR4Cc3sKko+UmmSMXmdxy1vHDCuQQTM/JcFfY98ESGyqPV+R2xB2UYQHhGctNOnMMwXjsy/ l6Eg92vAiZg2JWOVGCC8a2QoSyzNSU9ImoLZCtCRgwAi+QPu6k5lBSWUdBuAPbsy8brA3f1w ivPpi94ja8V1IgVzb69u1vAhlpAu6T0c+L83S2PNkrN0++zTNfNi1CAgbQD0ct9EQ==
IronPort-HdrOrdr: A9a23:ixXemawB3Fl0snpKLJhCKrPw8b1zdoMgy1knxilNoHtuA6mlfq GV7ZYmPHDP6Ar5NEtPpTniAsa9qBrnnPZICOIqTNSftWfd2VeAHcVN4Yzv2DX8FyC73f4178 tdWpk7LNHrF1B1gYLZ7BnQKbwd6ejC1Kyzn+/RwzNWUAdwZ8hbgjtREAqBDUFsfgVACKc4EJ b03KF6mwY=
X-IronPort-AV: E=Sophos;i="5.87,193,1631577600"; d="scan'208";a="11047311"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 29 Oct 2021 16:53:58 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2308.015; Fri, 29 Oct 2021 16:53:58 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Lars Eggert <lars@eggert.org>
CC: The IESG <iesg@ietf.org>, "draft-ietf-dnsop-dns-tcp-requirements@ietf.org" <draft-ietf-dnsop-dns-tcp-requirements@ietf.org>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Suzanne Woolf <suzworldwide@gmail.com>
Thread-Topic: [EXTERNAL] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
Thread-Index: AQHXzQcY1WHeYbA7FU2LSxLF5LNQ7Q==
Date: Fri, 29 Oct 2021 20:53:58 +0000
Message-ID: <8C43452C-4291-4C1A-AE8D-27546EAEA675@verisign.com>
References: <163524814397.6773.7925615506385048342@ietfa.amsl.com>
In-Reply-To: <163524814397.6773.7925615506385048342@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.7)
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4BA8942F4F6B83499C5E0F98A123CA3C@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WTR1Qkh7GiSG_4jVCs_2jsh38BU>
Subject: Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 29 Oct 2021 20:54:06 -0000

Lars, thank you for the review.  

Some of your easier comments and suggestions have been addressed, but for some of them will require more thought and attention.  I am waiting to coordinate with my coauthor, and possibly the WG chairs.

> On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker <noreply@ietf.org> wrote:
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 2.4. , paragraph 1, comment:
>> 2.4.  Fragmentation and Truncation
> 
> Fragmentation and IP fragments getting dropped is one reason for needing more
> retries with EDNS(0). But IIRC, a larger contributing factor is that EDNS(0)
> doesn't detect or recover from loss of any UDP packets making up the overall
> message. That means that a normal packet loss (due to congestion or other
> reasons) amplifies into loss of the entire DNS message.

How does this new paragraph look to you?

       <t>Note that a receiver is unable to differentiate between packets
       lost due to congestion and packets (fragments) intentionally
       dropped by firewalls or middleboxes.  Over network paths with
       non-trival amounts of packet loss, larger, fragmented DNS responses
       are more likely to never arrive and time out compared to smaller,
       unfragmented responses.  Clients might be misled into retrying
       queries with different EDNS(0) UDP packet size values for the
       wrong reason.</t>


> 
> 
> Found terminology that should be reviewed for inclusivity; see

Thanks, changed to primary and secondary.

> -------------------------------------------------------------------------------
> All comments below are about very minor potential issues that you may choose to
> address in some way - or ignore - as you see fit.

These have all been accepted, except for the cases where we do intentionally refer to obsoleted RFCs.

DW

v2.23.0 | Report a Bug | By Email