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.
- [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully re… Paul Hoffman
- Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefull… Tony Finch
- Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefull… Stephane Bortzmeyer
- Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefull… Ralph Dolmans
- Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefull… Tony Finch
- Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefull… Tony Finch
- Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefull… Ralph Dolmans
- Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefull… Dave Lawrence
- Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefull… Tony Finch
- Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefull… Brian Dickson