Re: [DNSOP] Genart last call review of draft-ietf-dnsop-rfc7816bis-09

Stephane Bortzmeyer <> Mon, 07 June 2021 08:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FF963A3D0A; Mon, 7 Jun 2021 01:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cAs-8FrJGgmO; Mon, 7 Jun 2021 01:49:33 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FD803A3D09; Mon, 7 Jun 2021 01:49:32 -0700 (PDT)
Received: from (localhost []) by (Postfix) with SMTP id 101E9280DD3; Mon, 7 Jun 2021 10:49:27 +0200 (CEST)
Received: by (Postfix, from userid 500) id 0891C281520; Mon, 7 Jun 2021 10:49:27 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 00A5F280DD3; Mon, 7 Jun 2021 10:49:27 +0200 (CEST)
Received: from ( [IPv6:2001:67c:1348:7::86:133]) by (Postfix) with ESMTP id F042C6071EA6; Mon, 7 Jun 2021 10:49:26 +0200 (CEST)
Received: by (Postfix, from userid 1000) id E205D3FF3C; Mon, 7 Jun 2021 10:49:26 +0200 (CEST)
Date: Mon, 07 Jun 2021 10:49:26 +0200
From: Stephane Bortzmeyer <>
To: Suhas Nandakumar <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-Operating-System: Debian GNU/Linux 10.9
X-Kernel: Linux 4.19.0-16-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2021.6.7.83316, AntiVirus-Engine: 5.83.0, AntiVirus-Data: 2021.6.6.5830001
Archived-At: <>
Subject: Re: [DNSOP] Genart last call review of draft-ietf-dnsop-rfc7816bis-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Jun 2021 08:49:38 -0000

On Sun, Jun 06, 2021 at 11:13:23PM -0700,
 Suhas Nandakumar via Datatracker <> wrote 
 a message of 72 lines which said:

> I am the assigned Gen-ART reviewer for this draft

Thanks for the review.

> Section 2.3
> 1. MAX_MINIMISE_COUNT and MINIMISE_ONE_LAB - are the values for these constants
> normatively defined or are they just recommendations ? Can the same be
> clarified in the document ?

The sentence "a good value is 10" seems to me indicating that it is
just a possible value. The important thing is to have a limit. Do we
think it should be rewritten with RFC 2119 words? MUST have a limit
and the RECOMMENDED value is 10?

> Section 4.
> The section starts with query for "" and walk through refers
> to  as query input.  Also no reference to ns1.nic.example seems
> to be appear in the detailed flows.
>  Can this be updated it to match overall ?

Actually, there are *two* independant requests. One for and one afterwards ("Here are more detailed
examples") for In the first one, ns1.nic.example is
indeed used.

Should we use the same QNAME for both?

> Section 5
> "QNAME minimisation may also improve lookup performance for TLD
>    operators.  For a TLD that is delegation-only, a two-label QNAME
>    query may be optimal for finding the delegation owner name, depending
>    on the way domain matching is implemented."
> This para doesn't clarify how the performance will be improved.  Can it
> be extended with some context around the same.

With QNAME minimisation, an authoritative name server MAY use exact
matching ("do I know foobar.example?") while without it, it MUST use
tree matching ("do I know thing.stuff.foobar.example or an ancestor of
it?") and tree matching is typically slower.