Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7816bis

"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 05 November 2020 16:27 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5C33A17F1 for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2020 08:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 xxuZH1LddcM1 for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2020 08:27:48 -0800 (PST)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 D3AC23A1349 for <dnsop@ietf.org>; Thu, 5 Nov 2020 08:27:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2882; q=dns/txt; s=VRSN; t=1604593668; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=QL7HKxiQzG9hJ/drK1f9RWydd8Uf+B4yiovG3fP67mI=; b=RW8xEilvMpmItSbfU/9umJdBrexg87G3c05WT6sbyl3qSWIwB3LmhdS0 tkEk7S1AUTjwhEcxHUmJRNZLJxXgzohumyMMJ/a6Wiq1/8lTvNagMywwg bGwYqDgZDgepVYu/+W/EAr13IAycWr+IRWJmaDVgAE5C6aROKbJqxHRi9 by3AFkGyHJ6uOp3Vgqr5ZKVmYHZGlQ8ZoNQ+i+wLZcwBDy8hYCTXxzjbr Yd2WNvKBiTrX5LYJRdgHOAaQPfvK6Z1FDmZhXWvsJPkpTSn3CoIi3cpGk Ow2VUFxFmzMMF+uAJH2xsbBvK18QxRYHDss9whbCoqK15MxfaYUxP7Tr0 A==;
IronPort-SDR: hBiENOh0AdOEpCJi0C+MFRFZhoyebCKBSqcXwE3U3+Wvk8DbCN0mRsCs3khI7gaLG+lw9QwPce ao9Vilqi7WsEdr+fylSWK0/3jtIMdKCwwgqN6LX27UQJyFp0Yv6ajDAXf3wFniLeIDfwdsPDNr gvLaYqJ+vcJP6Fd8xFjgm0PbRmviHWGkPofa/YpTTvZtP2SgL5ZKAFG3q/DZxy8F3Lzrda9lpS OI4qZbIDDL6fChyzkgn9skOEYujQs4beHGgZzKr297eR4hY7yvlefWcBJKq6O8ajDKIVyJi4Pp eNM=
X-IronPort-AV: E=Sophos;i="5.77,453,1596499200"; d="scan'208";a="3095441"
IronPort-PHdr: 9a23:u0lcIBGmXwQvbmCw0OOON51GYnF86YWxBRYc798ds5kLTJ7yp86wAkXT6L1XgUPTWs2DsrQY0rWQ6vi/EjFYqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjWwba5wIRmssAndqssbjYRiJ6ot1xDEvmZGd+NKyG1yOFmdhQz85sC+/J5i9yRfpfcs/NNeXKv5Yqo1U6VWACwpPG4p6sLrswLDTRaU6XsHTmoWiBtIDBPb4xz8Q5z8rzH1tut52CmdIM32UbU5Uims4qt3VBPljjoMOjgk+2/Vl8NwlrpWrhK/qRJi347aboKbNPR8caPcYdwUSmVOU91NVyNaAIOwc5cDA/YDMOtesoLzp0EOrRy7BQS0Cu/hyDhIhnvy3aIk1eQuCh/J0xAjH94WrX/ascn6NKAOUeCpwqXD0DLOb+hW2Tf67IjIdg4uofeXUr1ubcXRylIiFx3bgVWKqIzlJDKV1usLs2SB8+VgUuevhnchpgpsrTeh2t0ihZPVhoIJ1F/E7yN5zZ46K9CkVEN3fMKpHpRNui2HOYZ7XswvTmN0tSsk1rEKpJ+2cDYKxpkoyBDTdf6Kf5WW7x/+W+ufITZ1iXx7db++gRu57EuuyvXkW8WpzFpGtDdJn9vCu3wXyhDe6saKRuFy80qlwTqDyhzf5vtZLU02iabXMYMtz7Ezm5YJrEjOHSn7k1jsgqCMbEUr4O2o5vziYrXhu5CTKZd5ihr7MqQygsy/Bvk4MhQWU2ib5+u80Lrj8FXkTbtWlvM6j6nWvojVK8sauqK1HRVZ0pg/5Ba4FTemyM4UkmMaI15fZhKHlZPpO1fULP/kCve/hkygkDZtx//YIr3sGojBImTZnLv8f7tw5VRQxBczwN1R/Z5ZBbUMLOr2WkDrtdzYChE5Mxazw+biENh9zYMeWWWLAq+dLqzSt0SH6fwzLOmPf4IVpijyK+Ik5/71jH85llkdcbO10psQbXC0Bu5mLFmBYXrwntcBFn8HsRc4TOzxj12CSSVeZ3esUKIg6DE3EoWmDZ3MRtPlvLvUliu9BZpOTmFLFl7KFm3nPc3QV/EXbzq6I8J9nHoDT7f3GKE70hT7/i/9z75qKODZ8S5c/ano08RpraWHjhE18Th5Cc6Q2GKlUWxun3gJSDlw16d69x8ugmyf2LR11qQLXedY4OlEB183
X-IPAS-Result: A2E7BAB2J6Rf/zGZrQpigQmBT4RahDOrTYF8CwEBAQEBAQEBAQgBExwEAQGESgIXgXkmNgcOAgMBAQsBAQEFAQEBAQEGAwEBAQKGTwuCNyKDdwYdBgQNVQIBCBoCJgICAjAVEAIEG7Z5fzOFV4RwgQ4qhmOGcoFCPoQjPodVgl8EkDWDK6RBAweCbZsAK4MYj16Od5NNoEQCBAIEBQIVgVsKggFwgzpPFwINnGiBLAIGAQkBAQMJjTeBEQEB
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 5 Nov 2020 11:27:46 -0500
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.2106.002; Thu, 5 Nov 2020 11:27:46 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7816bis
Thread-Index: AQHWrMHpTdRBcM5UikSU/bIaAgJjHqm5v6lg
Date: Thu, 05 Nov 2020 16:27:46 +0000
Message-ID: <e5b569c1d30143f99d030c18862d6fe7@verisign.com>
References: <CADyWQ+H1cGN4abNXzr_=E2s-HKf9n4zbx7SESo1OFLSmBKK3Zw@mail.gmail.com>
In-Reply-To: <CADyWQ+H1cGN4abNXzr_=E2s-HKf9n4zbx7SESo1OFLSmBKK3Zw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/V8mz3qEjc3lUF2OZapKAL7-71zI>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7816bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2020 16:27:50 -0000

I support publication of this document. I do have some "last call" feedback to share:

Section 2, paragraph 4 states that "A resolver that implements QNAME minimisation changes the QNAME and QTYPE in queries directed to an authoritative nameserver that is not known to be responsible for the original QNAME". This is true, except when the QNAME and/or QTYPE are already in the preferred form. For instance, if the resolver prefers to send QTYPE=A, and the client has requested QTYPE=A, then no change is needed.  For similar reasons, the change does not necessarily "hide" the QTYPE, but rather prevents an observer from distinguishing queries of one type from another.  Suggested changes:

"changes the QNAME and QTYPE" -> "obscures the QNAME and QTYPE"
"to hide the original QTYPE" -> "to obscure the original QTYPE"

Section 2.3, last paragraph: I believe the intent of this paragraph is to show how many labels to add during each iteration, but it would benefit from further precision.  These questions stand out:

"The number of QNAME minimization iterations is the difference between this closest nameserver and the incoming QNAME". This should read "… the delegation point for this closest nameserver", correct?  But this isn’t the number of iterations in any case, it’s the number of labels that are still not exposed. It’s only the number of iterations if it's less than or equal to MAX_MINIMIZE_COUNT.

"The number of labels that are not exposed yet now need to be divided over the iterations that are left (MAX_MINIMISE_COUNT – MINIMISE_ONE_LAB). The remainder of the division should be added to the last iteration". True, but this overlooks all the iterations in between.   Based on the example, I’m assuming the idea is to allocate the labels that are left proportionally to the remaining iterations, rounding down.

The text should also state whether the algorithm is mandatory or optional. 2119 key words would be helpful.

Minor edits:

Section 1.1, paragraph 1:  "publicaiton" -> "publication"
Section 2.3, last paragraph:  "handles" -> "handled"

Scott