[art] Artart last call review of draft-ietf-add-ddr-07

Thomas Fossati via Datatracker <noreply@ietf.org> Tue, 28 June 2022 22:52 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF73DC15AE34; Tue, 28 Jun 2022 15:52:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Thomas Fossati via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: add@ietf.org, draft-ietf-add-ddr.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.5.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165645677583.27600.9815891521084108318@ietfa.amsl.com>
Reply-To: Thomas Fossati <thomas.fossati@arm.com>
Date: Tue, 28 Jun 2022 15:52:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/PT-6Rhoa4WieVi3lmSFMhlvbSo4>
Subject: [art] Artart last call review of draft-ietf-add-ddr-07
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2022 22:52:55 -0000

Reviewer: Thomas Fossati
Review result: Almost Ready

This looks like a very useful document.  It's short but packed with
information.  It's largely very well written, though I found Section 4.1
slightly harder to parse than the rest and I think that area needs some
(small) editorial tweaks before the document can be shipped.

# Minor issues

Why the following isn't a MUST NOT?

   Clients SHOULD NOT automatically use a Designated
   Resolver without some sort of validation, such as the two methods
   defined in this document or a future mechanism.

--

This bit is puzzling:

   A client MUST NOT use a Designated Resolver designated by one
   Unencrypted Resolver in place of another Unencrypted Resolver.

There seems to be some context missing to explain why a client should
found itself in that position.  What I seem to understand from the text
that follows:

   As these are known only by IP address, this means each unique IP
   address used for unencrypted DNS requires its own designation discovery.
   This ensures queries are being sent to a party designated by the
   resolver originally being used.

is that clients must go through the designation process when their
network attachment changes / they are re-configured WRT their UR. And
that's because there is strict administrative coupling between a UR and
its DRs that would be subverted otherwise.

I am scanning this for the first time and I may be off on a tangent
space, but if my reading is correct, then the text could be reorganised
a bit to make the context for the requirement clearer.

--

I found this other bit hard to parse:

   Generally, clients also SHOULD NOT reuse the Designated Resolver
   discovered from an Unencrypted Resolver over one network connection
   in place of the same Unencrypted Resolver on another network
   connection.

What about:

   If a client is configured with the same Unencrypted Resolver's IP
   address on two different networks n1 and n2, a Designated Resolver
   that has been discovered on n1 SHOULD NOT be reused on n2 without
   repeating the discovery process.

instead?


--

In the IANA section 

   IANA is requested to add an entry in "Transport-Independent
   Locally-Served DNS Zones" registry for 'resolver.arpa.' with the
   description "DNS Resolver Special-Use Domain", listing this document
   as the reference.

Ignorant question: is there an associated delegation of 'resolver.arpa.'
needed in the '.arpa.' zone?  Or is that not necessary?

# Nits

I've submitted a PR with a few typos fixed.

cheers, thanks!