Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

"Wessels, Duane" <> Fri, 05 November 2021 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 235C63A104A; Fri, 5 Nov 2021 14:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yBhQ5_iybrjM; Fri, 5 Nov 2021 14:52:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABEEC3A1049; Fri, 5 Nov 2021 14:52:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; l=3684; q=dns/txt; s=VRSN; t=1636149144; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=TYwBvaLTLstSCHfqB8hM9jp3AIVW9FfXbSNIxLYrZEQ=; b=GGTG/vYKnxNPGATlmrSEWVe2sVXTT2dtN7h/+nWf+NIuiNo3pY3SfHP8 1usFpql1ugE8CDwv5hCPOT98su7t6zyO2ngTshE6Wc3X9cORYN8yf0LPW hIV/CHf0ZwfDAdz38ZRfzdRyV+yBSGdW6kwpwWe+NR6roUiFqzxUwRbiq NopojCeld4fwmRJeXI/yL9Mkgnrh7k65IdITuOOlClnslhM09ghQl3VwA /+Vh0K6jJ4p/8/h9YIdlgPXmjqz8Ld7rmRPerBDHsdhoUc6ZjswyLvNvp Uv60tB6VHKJUmmf6FvDJr8ndrpVMrMq+LgrPrrafodmHabk+UnPB6CS2t A==;
IronPort-SDR: +rEuLD79sIyomRMiTNU3vz8KL/fXWGAP3ZSIlaiCFC/UsVNroKJPy2XM17dhVf2YntY4d9RJLN 9Bm+z2xbwsfXD3nta9iNeBSh5W6LEE7MNB3dELqvT4lUDn5zEzJcrBev9COQfMSN7m/xRNKihf 7eMdEC+6snkQYC4HDicxN+veIE207CpqaIL6yraZvR8eA6BjSIUMK2keixB6Iq40ozpyuOKmU1 FsuqKJvI+yC5hu/h7EaVDVfHWj6m/GEYZBV+jCbq4wmJZkbdtvy3jleUUWIcZxdKH+fIGK8r1k g+4=
IronPort-Data: A9a23:tkikv6uVdotOyPLD11Q/fYRV8OfnVE5fMUV32f8akzHdYApBsoF/q tZmKT3Vb/aLNmagLd90Pt/jpBgFv5fSx4RjHFQ//iA1HyJA9ZOVVN+UEBz9bniYRiHhoOKLz Cm/hv3odp1coqr0/0/1WlTZQPoVOZigHtIQMsadUsxKbVIiGHhJZS5LwbZj29cx2YXhWGthh PupyyHhEA79s9JLGj9Mg06zgEsHUCPa4W5wUvQWPJinjXeG/5UnJMt3yZKZdhMUdrJp8tuSH I4v+l0ZElTxpH/BAvv9+lryWhNSHu6KZWBigFIOM0SpqkAqSiDfTs/XnRfTAKtao2zhojx/9 DlCnZm1RBs5FJTGpLUyXEVCPis9N/BN8ZaSdBBTseTLp6HHW1HW5axRKmwGZdRe5O1wG3kI/ PBeNioWaFaIgOfeLLCTE7Eq35t4apC2Z8VD6hmMzhmAZRoiaZzcTr7R6NtD9Ck9nMFVHPnYI cEebFKDaTyZOkUVZgdHU/rSms+xrVenbiF2+Wi5oKwTzXXy4xBX85XyZY+9ltuiAJ89clyjj mDJ5Ez7HxcbLNGFjzyI7hqEh+LUkgv6VZ4cUrqi+ZZCjEeayHBWCRAKWx63p+K+kguyXckaN 0cMvzAjtLUz7kGuQ9/hRDW5rWKK+BkGVLJ4H+sh7xnIward4hyCLmkJUjAHb8Yp3Oc6Qyctz neIks/nQzt1v9W9Um+P6bCOqT+tOCQYBWAHbC4ACwAC5rHeTJobhAjJF8llHb7t15juByu2x jGR6SI5wb8Ji5dNyb+g+xbMhDfESoX1czPZLz7/BgqNhj6Vrqb8D2B0wTA3Ncp9Ebs=
IronPort-HdrOrdr: A9a23:mgGRca4nb+pZQOAG8gPXwBXXdLJyesId70hD6qkXc20xTiX4rb HNoB1173/JYVoqNk3I+uruBEDoexq1yXcf2/hzAV7NZmjbkVrtAo1k4ZDr3jHsXwbvn9Qw6Y 5QN4xzEsf5A1Q/r8rriTPTL/8QhP2K6rqhi+ub9WpqVg0CUcxdxh10ERmWCXd7QwR6BZ40fa D22vZ6
X-IronPort-AV: E=Sophos;i="5.87,212,1631592000"; d="scan'208";a="11024883"
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 5 Nov 2021 17:52:20 -0400
Received: from ([fe80::a89b:32d6:b967:337d]) by ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2308.015; Fri, 5 Nov 2021 17:52:20 -0400
From: "Wessels, Duane" <>
To: John Scudder <>
CC: The IESG <>, "" <>, "" <>, "" <>, Suzanne Woolf <>
Thread-Topic: [EXTERNAL] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
Thread-Index: AQHX0o9oJd38z9whoUypNUe/PKFNvg==
Date: Fri, 05 Nov 2021 21:52:20 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3608.
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Nov 2021 21:52:28 -0000

John, thanks for the review.

> On Oct 28, 2021, at 6:42 AM, John Scudder via Datatracker <> wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks for the well-written document!
> A few comments --
> 1. I have similar concerns to Ben's regarding the use of BCP as a vehicle to
> update the Standards Track documents in question. If I had a better option to
> offer at this stage in the document's history, I would, but under the
> circumstances I don't. If we had it to do over again, my preference would have
> been to progress a small PS to update the Standards Track documents, and a BCP
> to provide all the rest of the content. In addition to the points Ben made, my
> discomfort also stems from the fact that the advice regarding implementations
> has inherently short shelf life (relatively speaking) whereas the updates are
> forever (or at least until the updated documents are bis'd).
>   I'm not requesting any change with this observation, just putting it out
>   there for discussion (without making it a DISCUSS...).
> 2. In Section 3, another +1 to Ben's comment. In particular the "lastly" part
> seemed especially loosy-goosy to me as written, as to what precisely is updated
> in RFC 1536. The flow of the prose is nice, but the conclusion is less than
> clear. I do think some rewrite of this section would be helpful.

Here’s how this part reads now:

   Lastly, Section 1 of [RFC1536] is updated to eliminate the
   misconception that TCP is only useful for zone transfers:


      DNS implements the classic request-response scheme of client-
      server interaction.  UDP is, therefore, the chosen protocol for
      communication though TCP is used for zone transfers.


      DNS implements the classic request-response scheme of client-
      server interaction.

> 3. Section 6 says applications should perform “full TCP segment reassembly”.
> What does that mean? A quick google search doesn’t suggest it’s a well-known
> term of art. I'm guessing that what you mean is that the applications should
> capture (and log, etc) the bytestream that was segmented and transmitted by TCP?

This has been updated as follows:

   that capture network packets (e.g., with libpcap [libpcap]) SHOULD
   implement and perform full TCP stream reassembly and analyze the
   reassembled stream instead of the individual packets.  Otherwise,
   they are vulnerable to network evasion attacks [phrack].