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

Ralph Dolmans <ralph@nlnetlabs.nl> Thu, 22 October 2020 11:49 UTC

Return-Path: <ralph@nlnetlabs.nl>
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 2F2693A0A64 for <dnsop@ietfa.amsl.com>; Thu, 22 Oct 2020 04:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_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=nlnetlabs.nl
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 h9aFS-oALYcu for <dnsop@ietfa.amsl.com>; Thu, 22 Oct 2020 04:49:16 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE083A0A60 for <dnsop@ietf.org>; Thu, 22 Oct 2020 04:49:16 -0700 (PDT)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id CDDBE60248 for <dnsop@ietf.org>; Thu, 22 Oct 2020 11:49:13 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1603367353; bh=Xp7YRm6NfkrLVEq6Xp5otpHvs34ySQp24bA3UOrYr24=; h=Subject:To:References:From:Date:In-Reply-To:From; b=hV6NmBtynHjpvZS6f+LCh+rDEWhuNjslXxJyqPs69xJ6fLDLRuTuBlWw6VMOipjIH wF8lejs4d9n1HdR9eeCyBzVlISWiNoVFukPMnEyclx71jWO+PQALcgu+QzQj5q0Ijd OlbjAYMZ+Jf9XTZirwfp1qh5bprYU6PTAOkyy9XIDGo7rXviXpsfBdeyvoA9YQPO7x wSa+3cepIuhmWq9e8tywHPAH/MplYBGQsK28CAt1tv5rgTgkWa3D678niqPPrWUwCa d+4Oq0tZ0hxLYT7kuER5qNV7CUCqQ1efW+3j8MYyiSHcsuRHQu3/sjelWJ8+Q1eFFs YPzl1vTgdRJQA==
To: dnsop@ietf.org
References: <C0C343BA-D0A6-46A0-90C8-053793BC5F40@icann.org> <alpine.DEB.2.20.2010141752020.8465@grey.csi.cam.ac.uk>
From: Ralph Dolmans <ralph@nlnetlabs.nl>
Message-ID: <e81e62a5-747a-201d-0892-f498ef89e7a0@nlnetlabs.nl>
Date: Thu, 22 Oct 2020 13:49:12 +0200
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.2010141752020.8465@grey.csi.cam.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/e8GmN6Ds_Rf7H8PFB0Z5kTTcuww>
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: Thu, 22 Oct 2020 11:49:18 -0000

Hi Tony,

Thanks for your feedback, appreciated!

On 14-10-2020 20:15, Tony Finch wrote:
> A few questions and suggestions:
> 
> Section 3, algorithm step 5: what is a "hidden QTYPE"?

The QTYPE in the incoming query. We made the text more consistent and
now always use "original 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".)

NOERROR can indeed be positive and negative, which is intentional. Also
when you have a positive cache result in this step you know that there
is no delegation at this level and therefore can add an extra label.

I'm ok with making it more clear by explicitly saying that it can be
both positive and negative.

> 
> 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.

The QTYPE selected by the resolver to do QNAME minimisation. We now
changed it to "selected QTYPE" to hopefully make it easier to understand.

> 
> 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.

Both cases indeed. Made that more explicit in the text.

> 
> 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.

Agree. And without RFC8020 support you should go back to step 3. Added
to the text.

> 
> 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 don't have a strong opinion on separating between rationale and
normative text. Adding subheadings is a good suggestion.

> 
> 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?

This is a leftover from an older version. There now is only one way to
do QNAME minimisation, so no need to name it. We removed the
"aggressive" references.

> 
> 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'm ok with moving the text from section 5 to a subsection of 2.

Thanks!
-- Ralph