Skip to main content

Last Call Review of draft-ietf-add-dnr-15
review-ietf-add-dnr-15-dnsdir-lc-blacka-2023-04-14-00

Request Review of draft-ietf-add-dnr
Requested revision No specific revision (document currently at 16)
Type IETF Last Call Review
Team DNS Directorate (dnsdir)
Deadline 2023-04-09
Requested 2023-03-30
Authors Mohamed Boucadair , Tirumaleswar Reddy.K , Dan Wing , Neil Cook , Tommy Jensen
I-D last updated 2023-11-06 (Latest revision 2023-04-27)
Completed reviews Dnsdir Telechat review of -16 by David Blacka
Artart IETF Last Call review of -10 by Robert Sparks (diff)
Opsdir IETF Last Call review of -10 by Joe Clarke (diff)
Secdir IETF Last Call review of -09 by Rich Salz (diff)
Dnsdir IETF Last Call review of -15 by David Blacka (diff)
Secdir IETF Last Call review of -15 by Rich Salz (diff)
Assignment Reviewer David Blacka
State Completed
Request IETF Last Call review on draft-ietf-add-dnr by DNS Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/dnsdir/wSpAgG5dYxRyU3M1jv9ZvRyd1l4
Reviewed revision 15 (document currently at 16)
Result Ready w/nits
Completed 2023-04-14
review-ietf-add-dnr-15-dnsdir-lc-blacka-2023-04-14-00
Overall I found this draft well-written, straightforward, and relatively easy
to follow (although there are a lot of external RFC references).

Some overall advice:

It would be helpful to put "ADN" in the list of terms (section 2).  It is
defined in the introduction, but it is used liberally in the rest of the
document and a reader might expect to be able to find in the terms section.

Additionally, "ADN-only" might be helpful to put in the list of terms.  This
term is used less often, but it is repeated far enough away from section 3.1.6
to possibly be helpful in section 2.

I don't really want to suggest that you change the various option formats, but
as a DNS person, I had an observation about them.

* The "ADN length" should not be necessary as wire-format DNS names are
actually length encoded.  Providing the ADN length does, however, allow a
parser to skip over the name without parsing the ADN itself which may be
useful. * The "ADN length" doesn't need to be 16-bits, and it isn't in the
DHCPv4 format.  It is a little curious that the length of this field differs
across the different option implementations.

Beyond that, I just had some language nits:

In section 3:

> This document describes how a DNS client can discover local encrypted DNS
resolvers using DHCP (Sections 4 and 5) and Neighbor Discovery protocol
(Section 6): Encrypted DNS options.

This seems odd. I think this sentence could just end after "(Section 6)".

In section 3.2.1:

> To avoid adding a dependency on another server to resolve the ADN, the
Encrypted DNS options return the IP address(es) to locate the encrypted DNS
resolver. These encrypted DNS resolvers may be hosted on the same or distinct
IP addresses. Such a decision is deployment specific.

I found this wording of the 2nd sentence hard to follow.  Hard enough to follow
that I don't know what is trying to be said.  Maybe the 2nd and 3rd sentences
could just be deleted?

In section 3.1.6:

Why is there a block quote here?  What is it quoting?

In section 3.1.8:

> The ADN is present and encoded as per Section 10 of [RFC8415].

In addition to providing the RFC reference, one could also describe the
encoding as "uncompressed DNS wire format."