Skip to main content

Last Call Review of draft-ietf-add-ddr-07
review-ietf-add-ddr-07-artart-lc-fossati-2022-06-28-00

Request Review of draft-ietf-add-ddr
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2022-07-08
Requested 2022-06-24
Authors Tommy Pauly , Eric Kinnear , Christopher A. Wood , Patrick McManus , Tommy Jensen
I-D last updated 2022-06-28
Completed reviews Intdir Last Call review of -08 by Juan-Carlos Zúñiga (diff)
Artart Last Call review of -07 by Thomas Fossati (diff)
Genart Last Call review of -08 by Robert Sparks (diff)
Secdir Last Call review of -08 by Benjamin M. Schwartz (diff)
Assignment Reviewer Thomas Fossati
State Completed
Request Last Call review on draft-ietf-add-ddr by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/PT-6Rhoa4WieVi3lmSFMhlvbSo4
Reviewed revision 07 (document currently at 10)
Result Almost ready
Completed 2022-06-28
review-ietf-add-ddr-07-artart-lc-fossati-2022-06-28-00
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!