DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)
draft-ietf-add-dnr-16

# Internet AD comments for {draft-ietf-add-dnr-15}
CC @ekline

## Nits

### S7.1

* "RAs messages" -> "RAs" or "RA messages"

This is my second ballot on this document.  Thank you for addressing my COMMENT feedback on -11.

Thank you to Rich Salz for the SECDIR review. Per my -11 ballot:

“I see that there is a marker to discuss the RFC6125 vs. RFC6125bis reference in https://mailarchive.ietf.org/arch/msg/secdir/tAX9quY3bSfKwX5ny5zJ64Tmpn0/.  Generally, I like the idea of referencing the newer document.  I saw that the authors would prefer to keep the RFC6125 reference.”  Nine months have passed and RFC6125bis is now out of the WG and with the AD. Do the old assumption still hold?

** Section 3.1.1
   In order to allow for PKIX-based authentication between a DNS client
   and an encrypted DNS resolver, the Encrypted DNS options are designed
   to always include an authentication domain name.

Wouldn’t it be more precise to say:

OLD
Allow for PKIX-based authentication been a DNS client and an encrypted DNS resolver

NEW
Allow for a PKIX-based authentication of the encrypted DNS resolver to the DNS client

** Section 3.1.9.  I don’t understand the purpose of this section.  It appears to be providing normative recommendation for protocol mechanisms (e.g., [TS.24008]) that are not specified by this document.  Is this text needed?

** Section 3.3.  What is process for handling the option data if the PKIX validation fails?  Should the guidance of Section 3.1.8 (“If any of the checks fail, the receiver discards the received Encrypted DNS option”) be followed?

I'm balloting No Objection, but can someone please remind me how this is "discovery"? 

e.g:  "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", "This document focuses on the *discovery* of encrypted DNS such as ...", "These options are designed to convey the following information: the DNS Authentication Domain Name (ADN), a list of IP addresses, and a set of service parameters.  This procedure is called Discovery of Network-designated Resolvers (DNR)."

I get that DNR is a known term (and yes, some folk like the acronym), but there isn't really much "discovery" happening is there? If someone tells me "To reach Mordor, take exit 13 of I-95 and then turn left", it would seem disingenuous for me to claim that I've "discovered" Mordor wouldn't it? "Discovery" to me implies a more active role, while this document basically provides a big signpost saying "The encrypted nameservers are OVER HERE!!!".

Again, I'm not trying to show this down / change things at this point, but rather trying to figure out what I'm missing...

Thanks for working on this specification.

I observed that the section 3.4 is lacking some description. I was not able to completely follow the section. The title says - multihoming considerations but it simply says it is out of scope and there is no description of reasoning behind that exclusion. It does not say what would happen to the client if the DNS service is provided on multiple interfaces. Does not impose any restriction on the resolver to not offer service using the options specified in this specification. It also asks to consult RFC6731 for issues and does not say if the issues are about multi-interfaces nodes in general or if the issues are about the use of the specified options in this specification with multi-interfaces nodes.

I would suggest to be clear about the considerations, issues and reasoning behind the exclusion, as it would improve the document.

# GEN AD review of draft-ietf-add-dnr-15

CC @larseggert

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### URLs

These URLs in the document can probably be converted to HTTPS:

 * http://www.3gpp.org/DynaReport/24008.htm

### Grammar/style

#### Section 3.1.2, paragraph 2
```
ey both the ADN and IP addresses. Otherwise a means to correlate an IP addres
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Otherwise".

#### Section 3.1.9, paragraph 1
```
the encrypted DNS resolver, it may fallback to using the Do53 resolver. 3.3.
                                   ^^^^^^^^
```
The word "fallback" is a noun. The verb is spelled with a space.

#### Section 5.2, paragraph 2
```
ined in [RFC4861]. A value of all one bits (0xffffffff) represents infinity.
                                  ^^^^^^^^
```
Don't use the number "one" with plural words. Did you mean "one bit", "a bit",
or simply "bits"?

## 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. Review generated by the [`ietf-reviewtool`][IRT].

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