[Add] AD review of draft-ietf-add-dnr-08

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

# Éric Vyncke, INT AD, comments for draft-ietf-add-dnr-08
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.

Regards,

-éric

## COMMENT

### 6MAN review of the RA option

The document shepherd write-up is explicit about the DHC WG review but what about the 6MAN review of the RA options ? Suggest to be clear in the doc shepherd document about this point, even if only writing "6MAN WG was not consulted" (then I will make it clear for the IETF last call).

### "DNS Server" could be ambiguous

The abstract, the introduction, and possibly other sections use "local DNS server" while I think that the authors' intent was rather "local recursive DNS server". If this is the case, then suggest changing the wording.

### Section 3.1 flow

```
   In order to allow for PKIX-based authentication between a DNS client
   and an encrypted DNS server,
```
While the above text is correct, the reader has only the explanation later. Suggest to change the flow to ease the reader's task.

### Section 3.1 ADN

"ADN" is not expanded at first use.

### Section 3.1 Global IPv4 address

```
   This IP address can be a
   private IPv4 address, a link-local address, a Unique Local IPv6
   unicast Address (ULA), or a Global Unicast Address (GUA).
```
What about global IPv4 address ? The wording seems to indicate an exhaustive list while it is not. What about anycast ?

### Section 3.1 round-robin

```
   If multiple IP addresses are to be returned in an Encrypted DNS
   option, these addresses are ordered in the preference for use by the
   client.
```
Should there be a recommendation somewhere for a round-robin to spread the load ?

### Section 3.1 RECOMMENDED vs. MUST vs. SHOULD

```
   At least the following service
   parameters are RECOMMENDED to be supported by a DNR implementation:
```
While "dohpath" is obviously applicable only to DoH, should the normative language be more than "RECOMMENDED", a "MUST" or "SHOULD" seems at the right level for "alpn" and "port" at least.

Later in `returning an ADN only can be considered` suggest using a 'MAY'

Beware that these changes are important and will need to be run again through the WG during the IETF Last Call.

### Section 4.1 reference to dnsop-svcb ?

```
      Service Parameters (SvcParams) (variable length):  Specifies a set of
      service parameters that are encoded following the rules in
      Section 2.1 of [I-D.ietf-dnsop-svcb-https].  Service parameters
```
is it section 2.1 (zone file) or section 2.2 (wire format)?

### Section 5.1 example

To be consistent with section 4.1, please also use a figure similar to figure 2 rather than the existing figure 5.

### Section 5.1 address length

```
   Addr Length:  Indicates the length of included IPv4 addresses in
      octets.  It MUST be a multiple of 4 for ServiceMode.
```
Unsure what "for ServiceMode" has to do here... Should it be removed ?

### Section 6.1 address length

```
   Addr Length:  Indicates the length of included IPv6 addresses in
      octets.  It MUST be a multiple of 16 for ServiceMode.
```
Unsure what "for ServiceMode" has to do here... Should it be removed ?

### Section 6.2

What happens when multiple RAs are received ? Either from different routers or from the same router ?

### Section 7.4 PSK

"pre-shared key", may I assume it is the WPA PSK ? Please be specific.

### Section 7.4 station-to-station

If not mistaken (but I am far from being a IEEE 802.11 expert), the AP can be configured to prevent all station-to-station conversations, which will stop many of the above attacks. If confirmed, then suggest to mention it.

### Section 8.3

"DNS Encrypted DNS Option" or "Encrypted DNS Option" ?

## 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