Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call

Tony Finch <dot@dotat.at> Wed, 14 October 2020 18:15 UTC

Return-Path: <dot@dotat.at>
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 B1C033A0FC0 for <dnsop@ietfa.amsl.com>; Wed, 14 Oct 2020 11:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 T_g0fQs6cu4J for <dnsop@ietfa.amsl.com>; Wed, 14 Oct 2020 11:15:13 -0700 (PDT)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 1E4603A0B5F for <dnsop@ietf.org>; Wed, 14 Oct 2020 11:15:12 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:49370) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kSlIs-000s2e-gF (Exim 4.92.3) (return-path <dot@dotat.at>); Wed, 14 Oct 2020 19:15:10 +0100
Date: Wed, 14 Oct 2020 19:15:10 +0100
From: Tony Finch <dot@dotat.at>
To: Paul Hoffman <paul.hoffman@icann.org>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <C0C343BA-D0A6-46A0-90C8-053793BC5F40@icann.org>
Message-ID: <alpine.DEB.2.20.2010141752020.8465@grey.csi.cam.ac.uk>
References: <C0C343BA-D0A6-46A0-90C8-053793BC5F40@icann.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hb3v5yaLJNwH9KcF7nGQGvoC0TQ>
Subject: Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
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: Wed, 14 Oct 2020 18:15:15 -0000

A few questions and suggestions:

Section 3, algorithm step 5: what is a "hidden QTYPE"?

Also step 5, a NOERROR answer can be positive or negative, so I think it
should be made clear that this is about a non-NXDOMAIN negative cache
entry. (RFC 2308 calls these "NODATA".)

Step 6, what is the "minimised QTYPE"? The term is defined by implication
in section 2, but a reader can't find the definition by searching for the
term.

Step 6b, again NOERROR can be positive or negative. I think either this
needs to be more specific, or it should explicitly say it covers both
cases.

Step 6c, CHILD might not be the full original QNAME at this point, so it's
only correct to stop on NXDOMAIN here if the resolver is doing RFC 8020
strict NXDOMAIN.

Editorial suggestion: the wall of text in section 2 could do with some
subheadings or bullet points. It would be helpful to make a more clear
separation between rationale/discussion and normative text.

I'm not a fan of the term "aggressive" since it sounds unpleasantly
fighty. And I'm not sure how it helps a reader to understand this draft:
AIUI angry vs friendly is supposed to be about the QTYPE used for
truncated query names; the algorithm in section 3 does not depend on this
choice, so I don't know why it is specifically the nasty algorithm. And
section 2 seems to imply the existence of a nice algorithm but there isn't
a specification of it. And why is the choice of QTYPE emotional, but the
number of labels to add is not?

Both section 5 and section 6 seem to be about performance, the problems
and possible benefits, but only the possible benefits count as performance
considerations. I think the question of how many labels to add on each
iteration should be a core part of QNAME minimization, described in
section 2.


(I keep expecting the Oxford spelling "minimize"...)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Fitzroy: Northerly or northeasterly 3 to 5, becoming variable 4 or less in
west, then southerly 5 or 6 in northwest. Moderate, occasionally rough at
first in northeast. Showers. Good.