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

Suhas Nandakumar <suhasietf@gmail.com> Mon, 07 June 2021 15:19 UTC

Return-Path: <suhasietf@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D423A1A23; Mon, 7 Jun 2021 08:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 12YLW0XlsxSY; Mon, 7 Jun 2021 08:19:06 -0700 (PDT)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9003A1A09; Mon, 7 Jun 2021 08:19:05 -0700 (PDT)
Received: by mail-vs1-xe2f.google.com with SMTP id b1so7380816vsh.7; Mon, 07 Jun 2021 08:19:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q1dI3HNLwKFOraJzn4J1fdXTpP/4rz2qsLBSL+NLz4s=; b=S9o7wXrFakbh2gfQdcLqcRDU+PxD0RXVzSh4hHn9ifaL+zHkW7XeVMH7YSUmZNviK9 AZ7ZCtmMAGjuif37f71Uc2hlbEPrC/L6IThp+UY+JcfzAPuX6IGyRGX5QmfzM0cptXwJ lglhMWmi1hGk+AkxL4/3zjzrE4lHWAYgQ/aM+7UoUxx7kng10pTI8KcBexL/W5kiBcSM LHiL25JH3+j3uQzzq3uiqJeu3YRO3WKaMWnwLB1A1v22ev2l+V2aFhROAVB3Xqalj2Q0 7l3t9Uq3nbomiNzflhxJvMyY2Tw+qR+wycJBG0fyO4n6EeE4ezjOSs22+WSH/WDa/SmR kdRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q1dI3HNLwKFOraJzn4J1fdXTpP/4rz2qsLBSL+NLz4s=; b=a7Q2rW6fxi8WtCfIz6uYGJIVsZ6HIXb55SYngvYOhtgqSvUTJrL6RKlfyrEuKWNxUO 47H+8XfLa6uab1svY9o2ya8UPu13j1n9eTYFvFT8A9blt+KW6t6OH6HMqH3a+JiHefC7 OkYix/SXY7fEFHMZ4iGWbiXTWEkclvIOUnbjWei6Z+dT71b7XTBcZze5PlgeMTpK2rTa mmPc13/Y5zrtFszPgR1eIb9UfPbjlSo3Z86RWPdI0yABq48rhl8M9r7Pfk4ozFVKEagW ajgVJ/7HvU8HkwgNFUncwWfj30Fww6r/+/D8mN9gLCkhzpT56ZjNGzqniQXAZFvSjSYI p/0Q==
X-Gm-Message-State: AOAM532dUjv0ewxomPja1h7QIqHagMr+OVCqegW/9J2mwHwUtWQfM3Tv yC3+00QXj5Z7JGL9ylFp/McV1GkDL5yiy3hMVyQ=
X-Google-Smtp-Source: ABdhPJz+7+DyKtRWILGnQXy5m32FanRuLqPpPxZkJybizzLb5ulSZXalKpi5E4kJ9lsoeujcdauGqmt33TSdci7RICg=
X-Received: by 2002:a67:6ec6:: with SMTP id j189mr9299641vsc.32.1623079143659; Mon, 07 Jun 2021 08:19:03 -0700 (PDT)
MIME-Version: 1.0
References: <162304640334.30281.17125627583762005846@ietfa.amsl.com> <20210607084926.GA30724@nic.fr>
In-Reply-To: <20210607084926.GA30724@nic.fr>
From: Suhas Nandakumar <suhasietf@gmail.com>
Date: Mon, 07 Jun 2021 08:18:52 -0700
Message-ID: <CAMRcRGTQuZExJws66tNCL6y85bnhWxE2qc4F=+1Xb-cA26eUHA@mail.gmail.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Cc: gen-art@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-rfc7816bis.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ccdcab05c42e8fa9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/sB7Y0ALFU5NswFqcnJEB1iffAVM>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-dnsop-rfc7816bis-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 07 Jun 2021 15:19:19 -0000

Hello Stephane

please see my responses inline. thanks

On Mon, Jun 7, 2021 at 1:49 AM Stephane Bortzmeyer <bortzmeyer@nic.fr>
wrote:

> On Sun, Jun 06, 2021 at 11:13:23PM -0700,
>  Suhas Nandakumar via Datatracker <noreply@ietf.org> 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?
>

[suhas] agree with the framing here and it makes it clearer about the
objectives

>
> > Section 4.
> > The section starts with query for "foo.bar.baz.example" and walk through
> refers
> > to a.b.example.org  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
> foo.bar.baz.example and one afterwards ("Here are more detailed
> examples") for a.b.example.org. In the first one, ns1.nic.example is
> indeed used.
>
> Should we use the same QNAME for both?
>

[suhas] I will let you make a final call on this one. I was able to read
and understand but the intent wasn't
clear with 2 different Qnames on the first read.

>
> > 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.
>
[suhas] This helps thanks