Re: [Add] New Version Notification for draft-mglt-add-rdp-02.txt

Stephane Bortzmeyer <bortzmeyer@nic.fr> Mon, 27 July 2020 14:58 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501643A19C7 for <add@ietfa.amsl.com>; Mon, 27 Jul 2020 07:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 JyWAIqPa5aOl for <add@ietfa.amsl.com>; Mon, 27 Jul 2020 07:58:53 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [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 ietfa.amsl.com (Postfix) with ESMTPS id 099D43A1A75 for <add@ietf.org>; Mon, 27 Jul 2020 07:55:04 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1BE21280173; Mon, 27 Jul 2020 16:55:03 +0200 (CEST)
Received: by mx4.nic.fr (Postfix, from userid 500) id 156BB2806D9; Mon, 27 Jul 2020 16:55:03 +0200 (CEST)
Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 0DD18280173; Mon, 27 Jul 2020 16:55:03 +0200 (CEST)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 02E8C642C582; Mon, 27 Jul 2020 16:55:03 +0200 (CEST)
Received: by b12.nic.fr (Postfix, from userid 1000) id 987F53FF16; Mon, 27 Jul 2020 16:55:02 +0200 (CEST)
Date: Mon, 27 Jul 2020 16:55:02 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Daniel Migault <mglt.ietf@gmail.com>
Cc: ADD Mailing list <add@ietf.org>
Message-ID: <20200727145502.GA7147@nic.fr>
References: <159078807168.11416.12425165143603046178@ietfa.amsl.com> <MW3PR15MB3785F6A2720F1E4ABB77AAE3E38F0@MW3PR15MB3785.namprd15.prod.outlook.com> <CADZyTkkMAfv2ktC=oHOy32JCriBJ6x1=7+W1B4FGX9FqsnjQdA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADZyTkkMAfv2ktC=oHOy32JCriBJ6x1=7+W1B4FGX9FqsnjQdA@mail.gmail.com>
X-Operating-System: Debian GNU/Linux 10.4
X-Kernel: Linux 4.19.0-9-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/1CUVvKT-ps52I3pL5YsSDWoRGIw>
Subject: Re: [Add] New Version Notification for draft-mglt-add-rdp-02.txt
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 14:58:55 -0000

On Fri, May 29, 2020 at 08:21:59PM -0400,
 Daniel Migault <mglt.ietf@gmail.com> wrote 
 a message of 218 lines which said:

> Please find an update version of the DNS Resolver Discovery Protocol (DRDP)

To tell the truth, I do not completely understand the protocol, or the
problem it tries to solve. But I work on that. A high-level
description would help. Section 2 is quite confusing. It says "The
DNS client may obtain the contextual resolving domains via various
way, including a configuration or via DHCP Options [I-D.btw-add-home]"
and later "This document describes two mechanisms for a DNS client to
retrieve resolving domains", these mechanisms being different from the
ones mentioned in the first sentence.

First question, about the concept of "resolving domain". 5.1 says
"FQDN - such as resolver.example.com - and the domain part (
example.com ) is designated as the resolving domain". The term "the
domain part" is unclear. Does it mean "the FQDN without the
most-specific label"? If the resolving service is
foo.bar.example.eu.org, is the resolving domain bar.example.eu.org?
(5.3 seems to imply this.)

Second, I do not get the relationship between "resolving domain" and
"resolving domain list". What is called "resolving domain" in 5.1
seems to be a "resolving domain list" in 5.2.