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

"Ralph Droms (rdroms)" <> Tue, 01 December 2015 13:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 20D6C1AC436; Tue, 1 Dec 2015 05:55:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LIGxnJ26GuU0; Tue, 1 Dec 2015 05:55:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5ABFD1AC432; Tue, 1 Dec 2015 05:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4906; q=dns/txt; s=iport; t=1448978148; x=1450187748; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mxc8wqMqV7+CqfqXINGcAE19NC3IZyP7oPRZO6gbmsI=; b=K3sOjdMR9gZTtXI+AaIrXHrxiL9vfSUYViC9Yj/9NJZSJJ6onm8o1G3b qr88zV/NkQmEMhp+aUP6e8fIxMIrRkTrcYy5Qk1erji3MDRFNpO+OR2Nj 2AZ0Fk9axleoW6aphsNxV3cBiuMOLhpiBYv/PYw4mx66lFf26mmClaLzD A=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AgCopV1W/5tdJa1egztTbwa+Mg6BZ?= =?us-ascii?q?hcKhW4CgUA4FAEBAQEBAQGBCoQ0AQEBAwEBAQFrCwULAgEIGC4nCyUCBA4FDog?= =?us-ascii?q?YCA28SAEBAQEBAQEBAQEBAQEBAQEBAQEBAQ8FBIZUAYIPgm6IJIEVBY0ihU2Da?= =?us-ascii?q?AGCXYFiiHiBW4dokx0BHwFDghEdFoFAcoRqgQcBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,369,1444694400"; d="asc'?scan'208";a="212290839"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2015 13:55:47 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id tB1DtlWa012200 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2015 13:55:47 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Dec 2015 07:55:46 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Tue, 1 Dec 2015 07:55:46 -0600
From: "Ralph Droms (rdroms)" <>
To: Stephane Bortzmeyer <>
Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07
Thread-Index: AQHRI6+hHnL8PlWItUKh35YfrpCImw==
Date: Tue, 1 Dec 2015 13:55:46 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_6B55C8CD-070C-40BA-92BA-CB0D1B28164E"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
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: Tue, 01 Dec 2015 13:55:50 -0000

> On Nov 26, 2015, at 7:41 AM 11/26/15, Stephane Bortzmeyer <> wrote:
> On Fri, Nov 20, 2015 at 04:22:21PM +0000,
> Ralph Droms (rdroms) <> 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.

This document is well-written and easy to read.  It's a pleasure to do the review.

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

OK, I understand this is a local technique and does not represent a change to the DNS protocols.  Even so, in my opinion there are some details that are not provided in the document (see below).

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

Would you consider adding a little text somewhere to make it clear that the Appendix is intended as a guide to implementors?

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

Perhaps "unknown zone cuts"?  Otherwise, that title sounds good.

My recommendation to improve the document would be the inclusion of another appendix, describing the algorithm to use if zone cuts are known.  In my opinion, what's missing from the document for an inexperienced implementor is a summary of how to build the resolver you refer to in section 2: "The minimising resolver works perfectly when it knows the zone cut"

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

OK, that text would be good.

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


> _______________________________________________
> Gen-art mailing list