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

"Ralph Droms (rdroms)" <rdroms@cisco.com> Fri, 20 November 2015 16:22 UTC

Return-Path: <rdroms@cisco.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 D53331B2C33; Fri, 20 Nov 2015 08:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.086
X-Spam-Level:
X-Spam-Status: No, score=-15.086 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 yWHUXC76KQ4t; Fri, 20 Nov 2015 08:22:23 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA6D1B2C31; Fri, 20 Nov 2015 08:22:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3845; q=dns/txt; s=iport; t=1448036542; x=1449246142; h=from:to:cc:subject:date:message-id:mime-version; bh=1p0DA7qMuAvkN/bGTkSD122XwpQ1QUsQ62uI1tWrLj0=; b=S4XZhqb1Y/GaQgM9TfY0OR6N+msglNd92MfPtX2lphTwPLw51xt/hTVv elC2jYq6q0AFnX9Sh6zfOPvdJdnkHQz5sl94CGMc6WQRf8OQaJxSeIShN 8i1sTAJ286qLd7+MEGt8DCDSSHuDKlV49u1Dk7eLfjKJ7JlK/JhXdbUw9 A=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CwAgALSE9W/5ldJa1egztTbwa/CQ6BZSGFboFIOBQBAQEBAQEBfwuENwR5EgEcZCcEDhOIIA3AewEBAQEBAQEBAQEBAQEBAQEUCYZUAYIPh2kSgxeBFQWWTAGCV4FhiHaBXYRAgyWTCQEfAUOEBHIBhCWBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.20,323,1444694400"; d="asc'?scan'208";a="210671503"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2015 16:22:22 +0000
Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAKGMLEQ014159 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Nov 2015 16:22:21 GMT
Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 20 Nov 2015 10:22:21 -0600
Received: from xch-aln-016.cisco.com ([173.36.7.26]) by XCH-ALN-016.cisco.com ([173.36.7.26]) with mapi id 15.00.1104.000; Fri, 20 Nov 2015 10:22:21 -0600
From: "Ralph Droms (rdroms)" <rdroms@cisco.com>
To: "draft-ietf-dnsop-qname-minimisation.all@ietf.org" <draft-ietf-dnsop-qname-minimisation.all@ietf.org>
Thread-Topic: Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07
Thread-Index: AQHRI6+hNkdLstiPgEeV5lNbmDNqdw==
Date: Fri, 20 Nov 2015 16:22:21 +0000
Message-ID: <08FE1449-1077-49CE-9E13-00A686EBCECC@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.118.56]
Content-Type: multipart/signed; boundary="Apple-Mail=_ED107C35-7764-4AD6-8319-55380CE17EB0"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/MaMuV3qPuHxbZTAy-C3xh4D3OeU>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>
Subject: [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: Fri, 20 Nov 2015 16:22:25 -0000

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?

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.

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.

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?

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.