Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

Tim Wicinski <tjw.ietf@gmail.com> Mon, 23 November 2015 14:01 UTC

Return-Path: <tjw.ietf@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2771B3990; Mon, 23 Nov 2015 06:01:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 xOEc_KQ79gTv; Mon, 23 Nov 2015 06:01:16 -0800 (PST)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E79A1B3999; Mon, 23 Nov 2015 06:01:15 -0800 (PST)
Received: by igcmv3 with SMTP id mv3so28967437igc.0; Mon, 23 Nov 2015 06:01:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=IoVCRMfu5xnG3Lbbsxx12k2EiOqxqzNMTawAAlgNhy0=; b=aua1umsEMtGMdgYiifpshtJTb0UVmie7tWO6+iI9V+NTce0ElQxAFwAZTWnMn/dtZo mZGCXWeWGNuz5kLYvwhqlWPzfKNwlSZLCFLC/ZplR5aEtoZKgfmsUPszbwj7QYQjkjln g9+54qtV5V6iTRh9TGC6iPQQzsMK7Eo13ZGzfOQgrlcpVh9HCAA+rud4WsQTxx48d0It ZJgVYmg1LtC5FsJCeibXLmLNyycEv5jurCZlbzgpE94Y41XusHQyLpBDsSb83YZ/42+8 x3CfW3ULl3aC9H1lrFRx36u+PjELVx1cz2bicingTxxWE4KQrEcJZXbbVja51mY3WBEJ nSxw==
X-Received: by 10.50.112.234 with SMTP id it10mr10653326igb.86.1448287274601; Mon, 23 Nov 2015 06:01:14 -0800 (PST)
Received: from still.local ([184.13.114.26]) by smtp.googlemail.com with ESMTPSA id k66sm5110550ioi.43.2015.11.23.06.01.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Nov 2015 06:01:13 -0800 (PST)
To: "Ralph Droms (rdroms)" <rdroms@cisco.com>, "draft-ietf-dnsop-qname-minimisation.all@ietf.org" <draft-ietf-dnsop-qname-minimisation.all@ietf.org>
References: <08FE1449-1077-49CE-9E13-00A686EBCECC@cisco.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Message-ID: <56531C28.6030309@gmail.com>
Date: Mon, 23 Nov 2015 09:01:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0a2
MIME-Version: 1.0
In-Reply-To: <08FE1449-1077-49CE-9E13-00A686EBCECC@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/OjbNRJKHDfs6RfefdzIrqT13pxU>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Nov 2015 14:01:17 -0000

Ralph

Thanks for the detailed review. Commeinline

On 11/20/15 11:22 AM, Ralph Droms (rdroms) wrote:
>
> I am the assigned Gen-ART reviewer for draft-ietf-dnsop-qname-minimisation-07.txt.
>
> For background on Gen-ART, please see the FAQ at <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>
> Please resolve these comments along with any other Last Call comments you may receive.
>
>
> Document: draft-ietf-dnsop-qname-minimisation-07
> Reviewer: Ralph Droms
> Review Date: 2015-11-20
> IETF LC End Date: 2015-11-23
> IESG Telechat date: unknown
>
> Summary:
>
> This draft is on the right track but has open issues, described in the review.
>
> Major issues:
>
> The document is well-written and easy to understand.  Thank you.
>
> Has the working group considered publishing this document as "Informational" rather than "Experimental"?  If the document is published as "Experimental", is the intention to publish a subsequent proposed standard or BCP?
>

The WG has considered several options. I believe we settled on 
"Experimental" because passing the entire QNAME all the way to the root 
servers has always existed, and it was unclear what unintended 
consequences would happen if this was deployed.

We do plan  on producing a Standards Track document.

> In my opinion, the document needs a little more work if it is to be published as "Experimental", especially if the intention is to publish a proposed standard based on the results of experiments with the techniques described in this document.  I found the descriptions in the document understandable, but not quite detailed enough to build an interoperable implementation.
>

Do you have anything in particular on details?  I can revisit with the 
authors on this.

> Is Appendix A intended as the specification for the QNAME minimization techniques described in this document?  The appendix is titled "An algorithm to find the zone cut" and the introductory text indicates the algorithm is intended for locating the zone cut.  However, as I read the algorithm, it finds and traverses all zone cuts until the original QNAME can be resolved.
>
> If Appendix A is not the specification for the QNAME minimization techniques, then I don't know exactly what specific behavior or algorithm is referred to by "minimising resolver" in this sentence from section 2:  "The minimising resolver works perfectly when it knows the zone cut [...]".
>
> My suggestion would be to include another algorithm description, similar to that in Appendix A, but that describes how to use knowledge of zone cuts.
>

OK

> Editorial
> ---------
>
> In section 2, is the phrase "closest known parent of the original QNAME" something that most DNS developers would understand?  Would the phrase "closest enclosing NS RRset" from Appendix A be more precise?
>

"closest enclosing NS RRset" may be more relevant.

> I wasn't sure at first whether "(section 6)" in the 4th paragraph of section 2 referred to section 6 of RFC 2181 or section 6 of this document.
>

This is RFC2181, so perhaps it can be reworded like this:

	The minimising resolver works perfectly when it knows the zone
	cut, as described in section 6 of [RFC2181].

thanks
tim