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

Ralph Droms <> Mon, 23 November 2015 16:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8E3A1A8A5F; Mon, 23 Nov 2015 08:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tjFygBN5wFeV; Mon, 23 Nov 2015 08:30:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A33431A8A59; Mon, 23 Nov 2015 08:30:32 -0800 (PST)
Received: by qkfo3 with SMTP id o3so60506236qkf.1; Mon, 23 Nov 2015 08:30:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=xkWbYK4Whlh/VFjM/2ci+scMM+T+TSFtSiRgkiqh8BA=; b=x1rtvlSiQo/vSbc/zZOfvuK3m/BZIrhgVLDQXlYq5S+gcujyz6zgHPB2omZumLW5bp uCJA0Jz6rhwgJl8exUbhj8xx4Z91BjfKKV1kVF2CAlvyTnmBsMYFl8YhA+J7a/P56z4k 1ekg9PvbOWJtJ6bDz6N22xqlWRHirC2/DuPV1Vi0N1hvbRPwhkd0FFf140bF/HYrK1vB /8SsYTW/iaE7tgBCPCzTPy0cabO0Uga32oyV79OKxAoEFx8MIJvo3pitgg2J2wJLIPeR XyYrpGffxZC4GsnMSOF630OW/1LQy7wCNrWKey7uaN3a8C7NxsdvDDgbPYyXsUhfyftC bTZw==
X-Received: by with SMTP id d20mr28533837qkj.57.1448296231804; Mon, 23 Nov 2015 08:30:31 -0800 (PST)
Received: from ?IPv6:2001:420:2c8b:1300:18e6:dc2d:e21b:8558? ([2001:420:2c8b:1300:18e6:dc2d:e21b:8558]) by with ESMTPSA id a132sm3121329qhd.44.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Nov 2015 08:30:30 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
Content-Type: multipart/signed; boundary="Apple-Mail=_18C43F02-6986-4B66-9C2F-0067625D9004"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
From: Ralph Droms <>
In-Reply-To: <>
Date: Mon, 23 Nov 2015 11:30:29 -0500
Message-Id: <>
References: <> <>
To: Tim Wicinski <>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Nov 2015 16:30:35 -0000

> On Nov 23, 2015, at 9:01 AM 11/23/15, Tim Wicinski <> wrote:
> 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 <>.
>> 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.

OK, glad to hear the WG thought through the alternatives.
>> 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.

In my opinion, the document provides a collection of techniques but doesn't explicitly define a specific, testable mechanism to implement.  (continued below)

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

   Here is the text I would focus on if I were writing an implementation:

   A resolver which implements QNAME minimisation, [...],
   sends a request to the name
   server authoritative for the closest known parent of the original


   The minimising resolver works perfectly when it knows the zone cut
   [RFC2181] (section 6). [...] (Appendix A describes this algorithm
   in deeper details.)

As I wrote in my review, it appears to me that Appendix A gives a specification of the resolver behavior.  If that's the case, it would be helpful to make that explicit statement in section 2.

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

That wording would eliminate the confusion.

> thanks
> tim