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

Stephane Bortzmeyer <bortzmeyer@nic.fr> Thu, 26 November 2015 12:54 UTC

Return-Path: <bortzmeyer@nic.fr>
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 9B09D1B2B7D; Thu, 26 Nov 2015 04:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Z27ksMdomVNk; Thu, 26 Nov 2015 04:54:50 -0800 (PST)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 A4EBF1B2B5C; Thu, 26 Nov 2015 04:54:50 -0800 (PST)
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id B465239A58; Thu, 26 Nov 2015 13:54:47 +0100 (CET)
Received: by tyrion (Postfix, from userid 1000) id E102DF00649; Thu, 26 Nov 2015 13:41:17 +0100 (CET)
Date: Thu, 26 Nov 2015 13:41:17 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: "Ralph Droms (rdroms)" <rdroms@cisco.com>
Message-ID: <20151126124117.GA7265@laperouse.bortzmeyer.org>
References: <08FE1449-1077-49CE-9E13-00A686EBCECC@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <08FE1449-1077-49CE-9E13-00A686EBCECC@cisco.com>
X-Transport: UUCP rules
X-Operating-System: Ubuntu 15.10 (wily)
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/VDOFt_pj0S12W0mD2BB2duvXVHQ>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-dnsop-qname-minimisation.all@ietf.org" <draft-ietf-dnsop-qname-minimisation.all@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: Thu, 26 Nov 2015 12:54:52 -0000

On Fri, Nov 20, 2015 at 04:22:21PM +0000,
 Ralph Droms (rdroms) <rdroms@cisco.com> wrote 
 a message of 97 lines which said:

> I am the assigned Gen-ART reviewer for
> draft-ietf-dnsop-qname-minimisation-07.txt.

Hello. Glad to have reviewers.

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

[See Tim's answer.]

> I found the descriptions in the document understandable, but not
> quite detailed enough to build an interoperable implementation.

There is something very important about qname minimisation: it is a
local technique, not a protocol. It works with unmodified authoritative
name servers. So "interoperability" is not a concern because it does
not change the DNS protocol. Consequence: each resolver MAY implement
it slightly differently (see appendix B).

> Is Appendix A intended as the specification for the QNAME
> minimization techniques described in this document?

No. That's why it's in an appendix. Most resolvers already can find
the zone cuts (they need it to do DNSSEC), this appendix is to give
ideas to developers of the other resolvers.

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

The title may be misleading. What about "An algorithm to perform QNAME
minimisation in presence of zone cuts?"

> In section 2, is the phrase "closest known parent of the original
> QNAME" something that most DNS developers would understand?

Well, "parent" could be misleading because it is rather "ancestor"
(the example in the draft show a grand-parent).

> Would the phrase "closest enclosing NS RRset" from Appendix A be
> more precise?

"Known" is very important here. What about "closest known enclosing NS
RRset"?

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

OK, fixed in my local copy.