Re: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

神明達哉 <jinmei@wide.ad.jp> Wed, 01 August 2018 18:25 UTC

Return-Path: <jinmei.tatuya@gmail.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 57671130DC8 for <dnsop@ietfa.amsl.com>; Wed, 1 Aug 2018 11:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level:
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 DdGkp-4ofUir for <dnsop@ietfa.amsl.com>; Wed, 1 Aug 2018 11:25:18 -0700 (PDT)
Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (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 94651130E00 for <dnsop@ietf.org>; Wed, 1 Aug 2018 11:25:17 -0700 (PDT)
Received: by mail-lf1-f46.google.com with SMTP id a4-v6so13998440lff.5 for <dnsop@ietf.org>; Wed, 01 Aug 2018 11:25:17 -0700 (PDT)
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=jSwoiPKZ2h2YgOP+/DP0lCALXeselwTs56EKe6raXQM=; b=WLlWbW2whHCplJs55kGVfS4lav6zPotk0DBDPhDhWd1O76cXNAwdtlCeQA1GRzz/sJ zUBMc66NLrFCmn7DHw78xTzDALlqC/hZwg/se5hGmXZKrNGZIYSrPD7DR8fy3bDI7+R/ DEtuuYQdMICpT+z4DagGV4YNJ1fZfwIEoaVdbviQOKNksV1n6fgaN5LJKEdfWLuGIpdr z8hvnEhdzRi9dw2Kk7dK83ock2kTEp79CjZrDWLCAABt/OFallJemV3ZnqBQV9i1UBzz qMeKKzov4SwMAul3CFlyiOA8lCTe9blBT+RjqJOZJ11fbxczK90Nqd/+jNzmcNcGOgDX 1x9w==
X-Gm-Message-State: AOUpUlEmSu59FZd63Lnbkq9BoHDkTmu2LoBUPi1fmnuRFnAh/tNMc/oa dnYKqwbCIHRz4L2FD1+IxUXF9wpillTz76V6Ai0=
X-Google-Smtp-Source: AAOMgpeUmkbYUKlHXLGLBbx/+ocgwY03SL4uXITsv5TRp55dBZXm2DrPDWkBlakbICS1Qq2K8MSZcBR/XdAOESYbfJ0=
X-Received: by 2002:a19:5418:: with SMTP id i24-v6mr15811939lfb.34.1533147915759; Wed, 01 Aug 2018 11:25:15 -0700 (PDT)
MIME-Version: 1.0
References: <CADyWQ+GtnmGruu=X2=Bs-NDLdt5TiYui4qk=AW7rG5jc9-MWKg@mail.gmail.com>
In-Reply-To: <CADyWQ+GtnmGruu=X2=Bs-NDLdt5TiYui4qk=AW7rG5jc9-MWKg@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Wed, 01 Aug 2018 11:25:04 -0700
Message-ID: <CAJE_bqcjOMBQyaH9GwgnxtpFYd_PDnpU=WGiVT=52a6QpU+yvg@mail.gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e83540057263d007"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PX-sWhq02ulEow5uJ7yF0083uns>
Subject: Re: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 01 Aug 2018 18:25:19 -0000

On Tue, Jul 24, 2018 at 9:33 AM Tim Wicinski <tjw.ietf@gmail.com> wrote:

>    This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis

>    The draft is available here:
https://datatracker.ietf.org/doc/draft-bortzmeyer-rfc7816bis/

>    Please review this draft to see if you think it is suitable for
adoption
>    by DNSOP, and comments to the list, clearly stating your view.
>    Please also indicate if you are willing to contribute text, review,
etc.

I support the adoption.  I'm willing to review future versions.

I have a couple of minor comments on 00:

- Regarding the first paragraph of Section 6, I've noticed RFC8198
  would have the same improvement effect.  You may or may not to
  mention it, but I'm noting it here as the draft also has a TODO
  about mentioning RFC8020 in this context.

- Also in Section 6:

   QNAME minimisation may also improve lookup performance for TLD
   operators.  For a typical TLD, delegation-only, and with delegations
   just under the TLD, a two-label QNAME query is optimal for finding
   the delegation owner name.

  It's not super obvious why it's "optimal".  Is this because it would
  be an exact match for minimized queries and the assumption is that
  an exact match is much more efficient than longest match in TLD
  server implementations?

--
JINMEI, Tatuya