[Add] AD review of draft-ietf-add-ddr-06

["Eric Vyncke (evyncke)" <[e-mail]>]

# Éric Vyncke, INT AD, comments for draft-ietf-add-ddr-06
CC @evyncke

Thank you for the work put into this document.

As usual, as the responsible AD for the ADD WG, I have done an AD review before the IETF Last Call. Please find a MD-formatted review below. Before going further, I am requesting the authors to act/reply/comment on all the points below. The end goal is to ease the rest of the publication process.

I hope that this helps to improve the document,

Regards,

-éric

## COMMENTS

### Action points from the shepherd write-up

Did the authors consider the point 1.g of Andrew Campling's shepher review ? See https://datatracker.ietf.org/doc/draft-ietf-add-ddr/shepherdwriteup/

### Section 1 DoQ ?

What about DNS-over-QUIC (not listed) ? Same applies for section 2 and other places. This may leave the impression that this I-D does not apply to DoQ.

### Section 1 URL path or template ?

Should "URL paths" be replaced by "DoH templates" ?

### Section 1 DHCPv6

Is there a reason why DHCPv6 RFC 8415 is not listed in paralle with DHCPv4 ?

### Section 2 port 53

AFAIK, DoT, DoQ, ... could be configured to also run on port 53, so, defining a "unencrypted resolver" as simply running on port 53 is probably not fully correct (happy to be corrected on this point though).

### Single stack client

What happens when the SVCB are only linked to IPv6 addresses (no A RR exist) and the client has only IPv4 connectivity ?

### Section 4.1 non-public address

```
      for when a resolver is
      accessed using a non-public IP address.
```
It is somehow ambiguous whether the non-public IP address is the resolver address or the client address.

### Section 4.1 what is public address ?

Also, what is meant by "non-public IP address" and later in the text “public IP address” ?

### Section 4.1 multi-homing

Thank you for the text about multiple network connection, may I suggest to make a sub-section out of this paragraph ? If only to stress its importance.

### Section 5 mention DNR

```
   or if a network provisioning
   protocol (such as DHCP or IPv6 Router Advertisements) provides a name
   for an Encrypted Resolver alongside the resolver IP address.
```
Please add a reference to the DNR document.

### BCP14 should be normative

Please move RFC 2119 and 8174 to the normative section.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments