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

[Ballot comment]
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.

[Ballot comment]
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...

[Ballot comment]
My ballot position has not changed since the last version as this update only removes the ECH references.

I find the set of documents in the ADD WG incomplete from a security point
of view. This is due to client policy being purposefully left out of the WG
charter, which is unfixable at this point in the process. I will therefore
abstain so that these documents can be published. Hopefully, a BoF/WG in the
future will attempt to address this security problem.

(see history tab on my previous ballot for further details)

[Ballot comment]
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?

[Ballot comment]
# 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

[Ballot comment]
This is the 2nd ballot after removing all ECH references as this effort appears to be stalled in the TLS WG. The revised I-D went through a 2nd round of WGLC and IETF Last Calls.

The diff is at: https://author-tools.ietf.org/iddiff?url1=draft-ietf-add-dnr-09&url2=draft-ietf-add-dnr-15&difftype=--html and I suggest to focus only on those changes (ECH removal and other text).

Regards

-éric

PS: of course, a -bis or an update will be written when ECH/ESNI is ready.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-add-dnr-15. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Options Codes registry on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

https://www.iana.org/assignments/dhcpv6-parameters/

a single, new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: OPTION_V6_DNR
Client ORO: Yes
Singleton Option: No
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the BOOTP Vendor Extensions and DHCP Options registry on the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry page located at:

https://www.iana.org/assignments/bootp-dhcp-parameters/

a single, new registration will be made as follows:

Tag: [ TBD-at-Registration ]
Name: OPTION_V4_DN
Data length: N
Meaning: Encrypted DNS Server
Reference: [ RFC-to-be ]

Third, in the IPv6 Neighbor Discovery Option Formats registry on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at:

https://www.iana.org/assignments/icmpv6-parameters/

a single, new registration will be made as follows:

Type: [ TBD-at-Registration ]
Description: Encrypted DNS Option
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.
Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-04-09):

From: The IESG
To: IETF-Announce
CC: Andrew.Campling@419.Consulting, add-chairs@ietf.org, add@ietf.org, draft-ietf-add-dnr@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Second Last Call:  (DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)) to Proposed Standard


The IESG has received a request from the Adaptive DNS Discovery WG (add) to
consider the following document: - 'DHCP and Router Advertisement Options for
the Discovery of Network-
  designated Resolvers (DNR)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-04-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The document specifies new DHCP and IPv6 Router Advertisement options
  to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over-
  TLS, DNS-over-QUIC).  Particularly, it allows a host to learn an
  authentication domain name together with a list of IP addresses and a
  set of service parameters to reach such encrypted DNS resolvers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-add-dnr/

The ADD WG has another document https://datatracker.ietf.org/doc/draft-ietf-add-ddr/, which should probably be reviewed at the same time.


No IPR declarations have been submitted directly on this I-D.

As this is the 2nd IETF Last Call for this document with really minor changes [1], the IETF Last Call will be shorter than usual.

Regards

-éric

[1] https://mailarchive.ietf.org/arch/msg/add/xR8V-Oe-IaQk-rVEwwudvRdS6hk/

Title: DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

Current Version: draft-ietf-add-dnr-08



(1.a)  Who is the Document Shepherd for this document?

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it is ready for consideration by the IESG



(1.b)  Has the document had adequate review both from key WG members and from key non-WG members?

It has been reviewed by working group members, hence the number of iterations of the draft to date.  A total of 128 mailing list posts reference the various DDR drafts, complemented by closed issues and closed pull requests on GitHub.  The authors have also given updates on progress during working group sessions at IETF meetings to highlight the draft to a broader audience.

Looking outside of the ADD working group, there has been consultation with the DHC working Group on the DHCP content in this draft. 



Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of detailed reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub.  In addition, the authors have responded positively to points raised during discussions at IETF meetings, for example by leveraging SVCB.  Where proposed changes have been rejected, comments have been posted to the mailing list to explain the reasoning.

When the document has been updated, the authors have been careful to post an explanation of the changes to the mailing list to indicate what input has been taken on board in the new version. 



(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No – the authors have done a good job in highlighting specific sections where they have sought additional review or input.



(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.



Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign early after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than Verisign had filed a patent with the USPTO.  For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/



(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been discussion amongst a variety of individuals, with ten people mentioned in the acknowledgements section of the document.  I believe that the document represents the consensus view of the working group as a whole and that it addresses a significant need that was identified during previous working group discussions.



(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern, nor are there any known issues of extreme discontent or conflict. 



(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  Two outstanding nits remain as follows:

- “There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document” – this refers to the text “a1.a2.a3.a4, which is not in fact an FQDN but an address to illustrate the encoding

- “Missing Reference: 'ThisDocument' is mentioned on line 744, but not defined” – the three tables in the IANA Considerations section all contain a reference to [ThisDocument], which the RFC Editor will replace those with the RFC number to be assigned for this doc

Given the first is a false positive and the second will be addressed by the RFC editor, neither should prevent the document from progressing.



Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.



If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard



(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

draft-ietf-add-svcb-dns – Standards Track
draft-ietf-dnsop-svcb-https – Standards Track

RFC 2119 – BCP 14 (updated by RFC 8174)
RFC 2132 – Standards Track (updated by RFCs 3442, 3942, 4361, 4833, 5494)
RFC 3396 – Standards Track
RFC 4861– Standards Track (updated by RFCs 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425, 9131)
RFC 8106– Standards Track
RFC 8174– BCP 14
RFC 8415– Standards Track

As can be seen, seven of the nine normative references are to RFCs, with two referencing Internet-Drafts. 



Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

No.



If such normative references exist, what is the strategy for their completion? 

Not applicable.



Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable.



(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 8 of the document contains the IANA considerations, identifying the need for two option codes and one option type within existing registries.  Specifically, IANA is requested to:

- assign a new DHCPv6 Option Code in the registry maintained in “DHCPv6 Option Codes” (https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2)

- assign a new DHCP Option Code in the registry maintained in "BOOTP Vendor Extensions and DHCP Options" (https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options)

- assign a new IPv6 Neighbor Discovery Option type in the "IPv6 Neighbor Discovery Option Formats" sub-registry under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry (http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5)



If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Not applicable.



If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.



Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.



If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.



(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

[Ballot comment]
Thanks to Robert Sparks for his ARTART review.

In Section 3.2, the RECOMMENDED seems to be dangling.  Should we give some implementers advice here about why they might legitimately decide to do something different?

Same question about the SHOULDs in Sections 4.2, 5.2, and 6.2.

In the diagram at the top of Section 4.1, should "OPTION_V6_DNR" actually be "Option-code"?  It looks like it should be the name of the field (like everything else in the diagram) rather than a specific value.  Similarly, in 5.1, should "OPTION_V4_DNR" be "Code"?  And in 6.1, should "TBA3" be "Type"?

[Ballot comment]
# SEC AD comments for {draft-ietf-add-dnr-12}
CC @paulwouters

## Abstain

I find the set of documents in the ADD WG incomplete from a security point
of view. This is due to client policy being purposefully left out of the WG
charter, which is unfixable at this point in the process. I will therefore
abstain so that these documents can be published. Hopefully, a BoF/WG in the
future will attempt to address this security problem.

## unresolved DISCUSS items

###

How and where a user decides to send their DNS queries impacts their privacy.
But the document lists no Privacy Considerations section as per RFC 6973
Note: The draft was updated and added one, but not one that helps the enduser
in any way.

###

Encrypted DNS servers need a public FQDN because otherwise you cannot get
a certificate for all connecting clients that are not provisioned with a
private/enterprise CA. How do home users run their own without having a
public domain? And how do I authenticate the encrypted DNS on 10.1.1.1
that has no FQDN? (and really, has no verifiable identity at all)
Note: There are ways to generate and transport certificates from public
reachable nodes to the Encrypted DNS servers, but this is still a complicated
method, which home routers are unlikely to be able to safely do.

###

    The DNS client verifies the connection based on PKIX validation

No CRLs, OneCRL updates, no OCSP, no Certificate Transparency is available
without functional DNS. So full PKIX validation as specified here is not
available.
Note: The text was updated and mentions OCSP, but it is not clear that a
hard fail should happen based on missing OCSP stapling or missing CT information.

###

  If the DHCP responses or RAs are dropped by the attacker, the client
  can fallback to use a preconfigured encrypted DNS resolver.

This raises the big question of why you think that strategy is a "fallback
strategy" and not the default behaviour of the client. Wouldn't it be more
secure if there is no DHCP/RA drop attacks possible?
Note: this is an item where even though client policy is out of scope of
the charter, the document defines a tiny bit (and not enough) client policy.

## Comments

###

The overarching issue of the ADD WG in general is the concern that using
the local network's DNS server (encrypted or not) is a privacy concern.
With HTTP dying and HTTPS sealing the last plain-text with Encrypted Client
Hello (ECH), DNS is the last resort of getting to know the enduser's
intent of where they are trying to connect to.

There are many parties interested in seeing the DNS query content, but
the enduser is rarely able to determine whether the local network used
can be trusted. This is true for coffee shops, hotels, malls but also
their home ISP. The only clear case of trust is the enterprise user, who
is provisioned (forced) via their enterprise management to use specific
DNS resolvers.

There are a number of well-known public DNS services such as Google DNS
(8.8.8.8), Quad9 (9.9.9.9) and Cloudflare (1.1.1.1). Arguably, these
servers have a better reputation of protecting the enduser's privacy
than most local networks, as endusers cannot trust most local networks
they use as they are not even aware of who owns various wifi networks they use.

The question all of this raises is, whether the user isn't better of
just never trusting or using the local network's DNS server, whether
encrypted or not. In that case, all of these ADD documents have little
value. For example, we see this already with Firefox and its TRR program
https://wiki.mozilla.org/Trusted_Recursive_Resolver and to some extend
with the Android phone "private DNS" feature
https://www.howtogeek.com/795644/how-to-enable-secure-private-dns-on-android/

On the other hand, we have the argument of, if the enduser is using
the local unencrypted DNS, it might as well use the local encrypted DNS.
While this is true if this decision is hidden from the enduser, if the
enduser believes they are using "encrypted DNS", they might not be aware
that this encrypted connection still reveals all privacy sensitive data
to the local network entity (or its trusted third party). An aware enduser
might also make different choices when they think their DNS is "safely
encrypted", such as visiting the website of an abortion provider. That is,
the ADD specifications might lure the enduser in a false sense of security.
To me this is one of the biggest issues while reviewing the ADD drafts. Are
these drafts potentially harmful to the enduser, or does it only offer
improvements to the status quo of the current common (non-encrypted) DNS
topologies? While the latter could be true, I do believe based on the
development seen at Google/Android and Mozilla/Firefox, that we are
already far into the phase where the enduser only decides _which_ remote
trustworthy encrypted DNS service they are going to use and as such only
use the local network DNS to kickstart their internet connection (captive
portal, paywall) after which they switch to remote encrypted DNS service.

And that of course, raises an issue with DNS security providers, who
wish to monitor and firewall all their DNS clients' DNS requests to
improve enduser security. This includes government mandates to ISPs to
filter certain DNS requests for local legal reasons. Which again raises
the issues of where such filtering power can be abused by authoritative
regimes, restrictive cults (eg scientology netnanny) or other malicious entities.

To summarize, I am really on the fence with respect to all the ADD drafts.
While "encrypted DNS" is always better than "unencrypted DNS", the
overarching issue of "never use or trust the local DNS resolvers" trumps
the DNR /DDR protocols. For those who can dictate how their users MUST
use DNS (eg Enterprise usage, parental control, opt-in security software),
device provisioning/configuration options are available that require no
ADD protocols with the exception of draft-ietf-add-svcb-dns.

[Ballot comment]
Updated to clear my DISCUSS position based on the proposed updates in -12.


I support Erik's second DISCUSS point regarding different field sizes for IPv4 vs IPv6.

Some additional non blocking comments:
(1)
3.1.4.  Why Not Separate Options for ADN and IP Addresses?

  A single option is used to convey both the ADN and IP addresses
  because otherwise means to correlate an IP address conveyed in an
  option with an ADN conveyed in another option will be required if,
  for example, more than one ADN is supported by the network.

I wasn't sure how useful/relevant this text is in the RFC.  It seems to be about the path not taken.  Perhaps it could be elided?

(2) 5.2.  DHCPv4 Client Behavior

Should this specify that only a single OPTION_V4_DNR option is allowed (or perhaps DHCPv4 mandates that anyway)?

(3)
  If the local DNS client supports one of the discovered Encrypted DNS
  protocols identified by Application Layer Protocol Negotiation (ALPN)
  protocol identifiers, the DNS client establishes an encrypted DNS
  session following the order of the discovered resolvers.

Should it be "discovered Encrypted DNS protocols" or just "Encrypted DNS protocols"?  I also struggled with what "order of the discovered resolvers" is actually referring to.  Would "order of the listed resolvers" be clearer?  I.e., in what way have the resolvers been discovered?

Regards,
Rob

[Ballot discuss]
# Internet AD comments for {draft-ietf-add-dnr-11}
CC @paulwouters

## Discuss

###

How and where a user decides to send their DNS queries impacts their privacy.
But the document lists no Privacy Considerations section as per RFC 6973

###

Encrypted DNS servers need a public FQDN because otherwise you cannot get
a certificate for all connecting clients that are not provisioned with a
private/enterprise CA. How do home users run their own without having a
public domain? And how do I authenticate the encrypted DNS on 10.1.1.1
that has no FQDN? (and really, has no verifiable identity at all)

###

    The DNS client verifies the connection based on PKIX validation

No CRLs, OneCRL updates, no OCSP, no Certificate Transparency is available
without functional DNS. So full PKIX validation as specified here is not
available.

###

    The DNS client uses Web PKI trust anchors by default unless
    configured otherwise.

CAB/Forum is currently, as far as I know, not taking encrypted DNS into account
for their BR's. Also, every OS and even some applications use their own "webpki"
root store that differs from each other. This can lead to interoperability issues.

###

Spoofing attacks are mentioned in the document. Obtain _any_ certificate from Let's
Encrypt via ACME, eg using "something.example.com", then spoof authentication-domain-name
on the wifi. While this attack might be blocked by the AP not allowing wifi clients to
send packets to each other, this is not true for all networks, and especially not for
home networks where the goal is for local clients to be able to connect to each other.
Is there a better way to lock the authentication-domain-name? One possible method might
be to bind it to the ESSID. eg if the ESSID is wifi.nohats.ca. one could only allow
authentication-domain-name to be a name within nohats.ca. Some method of reducing the
scope of this attack is needed I believe.

###

      Addr Length:  Length of enclosed IPv6 addresses in octets.  When
      present, it MUST be a multiple of 16.

Why not just a one octet counter then? The number of IPv6 addresses that follow.
Then the length of the Addr field becomes counter times 16 octets. That seems
more constrained than "multiple of 16"

###

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                              |
      |                        ipv6-address                          |
      |                                                              |
      |                                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The diagrams lack reference octets. What is the width ? or 4 rows ? or ?
I assume this is supposed to be 4 octets wide and 16 octets total? eg
I would write:

                          1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------------------------------------------------------+
      |                                                              |
      |                        ipv6-address                          |
      |                                                              |
      |                                                              |
      +---------------------------------------------------------------+
      |                              ...                              |
      +---------------------------------------------------------------+

(also my pet peeve is people using +-+-+-+ instead of -----)


###

      A value of zero means that this Authentication Domain Name MUST no
      longer be used.

Why not just omit the entry ? Are clients supposed to keep old entries for
their entire lifetime even if when asking a new list, those entries no longer
appear? That is not clear from this document. Either that should be made
explicit, or the values of 0 should not be allowed.

###

  By default, Encrypted DNS connections received from outside the local
  network MUST be discarded by the encrypted DNS forwarder in a CPE.

What is an "encrypted DNS forwarder in a CPE"? This is not defined in the
document and I am confused. I assume the CPE announces some encrypted DNS
server as either itself or to some external IP at the ISP network?

If itself, how can it get a real FQDN the client can verify with PKIX
using CAB/Forum ? If to an external IP, isn't it just acting as a NAT/router
forwarding packets and then what does it mean to be an "encrypted DNS forwarder" ?

###

  This recommendation is meant to isolate local network
  DNS resolver services from the public Internet and prevent external
  attacks against the local Encrypted DNS resolver.

  If the DHCP responses or RAs are dropped by the attacker, the client
  can fallback to use a preconfigured encrypted DNS resolver.

This raises the big question of why you think that strategy is a "fallback
strategy" and not the default behaviour of the client. Wouldn't it be more
secure if there is no DHCP/RA drop attacks possible?

###

Multihoming is declared out of scope, but realistically most devices we are
talking about here are phones, and those are all multihomed. So I feel pretty
strongly that it should not be left out of scope.

[Ballot comment]
## Comments

###

The overarching issue of the ADD WG in general is the concern that using
the local network's DNS server (encrypted or not) is a privacy concern.
With HTTP dying and HTTPS sealing the last plain-text with Encrypted Client
Hello (ECH), DNS is the last resort of getting to know the enduser's
intent of where they are trying to connect to.

There are many parties interested in seeing the DNS query content, but
the enduser is rarely able to determine whether the local network used
can be trusted. This is true for coffee shops, hotels, malls but also
their home ISP. The only clear case of trust is the enterprise user, who
is provisioned (forced) via their enterprise management to use specific
DNS resolvers.

There are a number of well-known public DNS services such as Google DNS
(8.8.8.8), Quad9 (9.9.9.9) and Cloudflare (1.1.1.1). Arguably, these
servers have a better reputation of protecting the enduser's privacy
than most local networks, as endusers cannot trust most local networks
they use.

The question all of this raises is, whether the user isn't better of
just never trusting or using the local network's DNS server, whether
encrypted or not. In that case, all of these ADD documents have little
value. For example, we see this already with Firefox and its TRR program
https://wiki.mozilla.org/Trusted_Recursive_Resolver and to some extend
with the Android phone "private DNS" feature
https://www.howtogeek.com/795644/how-to-enable-secure-private-dns-on-android/

On the other hand, we have the argument of, if the enduser is using
the local unencrypted DNS, it might as well use the local encrypted DNS.
While this is true if this decision is hidden from the enduser, if the
enduser believes they are using "encrypted DNS", they might not be aware
that this encrypted connection still reveals all privacy sensitive data
to the local network entity (or its trusted third party). An aware enduser
might also make different choices when they think their DNS is "safely
encrypted", such as visiting the website of an abortion provider. That is,
the ADD specifications might lure the enduser in a false sense of security.
To me this is one of the biggest issues while reviewing the ADD drafts. Are
these drafts potentially harmful to the enduser, or does it only offer
improvements to the status quo of the current common (non-encrypted) DNS
topologies? While the latter could be true, I do believe based on the
development seen at Google/Android and Mozilla/Firefox, I think we are
already far into the phase where the enduser only decides _which_ remote
trustworthy encrypted DNS service they are going to use and as such only
use the local network DNS to kickstart their internet connection (captive
portal, paywall) after which they switch to remote encrypted DNS service.

And that of course, raises an issue with DNS security providers, who
wish to monitor and firewall all their DNS clients' DNS requests to
improve enduser security. This includes government mandates to ISPs to
filter certain DNS requests for local legal reasons. Which again raises
the issues of where such filtering power can be abused by authoritative
regimes, restrictive cults (eg scientology netnanny).

To summarize, I am really on the fence with respect to all the ADD drafts.
While "encrypted DNS" is always better than "unencrypted DNS", the
overarching issue of "never use or trust the local DNS resolvers" trumps
the DNR /DDR protocols. For those who can dictate how their users MUST
use DNS (eg Enterprise usage, parental control, opt-in security software),
device provisioning/configuration options are available that require no
ADD protocols with the exception of draft-ietf-add-svcb-dns.

[Ballot discuss]
Hi,

Thanks for this document.  I think that what is being proposed here is useful.

I have one minor discuss comment, where I am really just asking for a bit more clarity over which fields are optional in the protocol extensions:

  ipv6-address(es) (variable length):  Indicates one or more IPv6
      addresses to reach the encrypted DNS resolver.  An address can be
      link-local, ULA, or GUA.  The format of this field is shown in
      Figure 3.

Should this be 0 or more IPv6 addresses if this field is optional (as per the description in option length)? 

In general, I found it slightly unclear as to which fields are optional to include and which are always present.  Possibly, explicitly indicating which fields are optional would add clarity.  A similar comment applies to the DHCPv4 packet format, and IPv6 RAs.

[Ballot comment]
I support Erik's second DISCUSS point regarding different field sizes for IPv4 vs IPv6.

Some additional non blocking comments:
(1)
3.1.4.  Why Not Separate Options for ADN and IP Addresses?

  A single option is used to convey both the ADN and IP addresses
  because otherwise means to correlate an IP address conveyed in an
  option with an ADN conveyed in another option will be required if,
  for example, more than one ADN is supported by the network.

I wasn't sure how useful/relevant this text is in the RFC.  It seems to be about the path not taken.  Perhaps it could be elided?

(2) 5.2.  DHCPv4 Client Behavior

Should this specify that only a single OPTION_V4_DNR option is allowed (or perhaps DHCPv4 mandates that anyway)?

(3)
  If the local DNS client supports one of the discovered Encrypted DNS
  protocols identified by Application Layer Protocol Negotiation (ALPN)
  protocol identifiers, the DNS client establishes an encrypted DNS
  session following the order of the discovered resolvers.

Should it be "discovered Encrypted DNS protocols" or just "Encrypted DNS protocols"?  I also struggled with what "order of the discovered resolvers" is actually referring to.  Would "order of the listed resolvers" be clearer?  I.e., in what way have the resolvers been discovered?

Regards,
Rob

[Ballot comment]
Thank you for the work on this document.

Many thanks to Robert Sparks for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/6Iw-VYqtHg3pTJCEXsY7bjfSyPw/, and to the authors for addressing Robert's comments.

Francesca

[Ballot discuss]
# Internet AD comments for {draft-ietf-add-dnr-11}
CC @paulwouters

## Discuss

The overarching issue of the ADD WG in general is the concern that using
the local network's DNS server (encrypted or not) is a privacy concern.
With HTTP dying and HTTPS sealing the last plain-text with Encrypted Client
Hello (ECH), DNS is the last resort of getting to know the enduser's
intent of where they are trying to connect to.

There are many parties interested in seeing the DNS query content, but
the enduser is rarely able to determine whether the local network used
can be trusted. This is true for coffee shops, hotels, malls but also
their home ISP. The only clear case of trust is the enterprise user, who
is provisioned (forced) via their enterprise management to use specific
DNS resolvers.

There are a number of well-known public DNS services such as Google DNS
(8.8.8.8), Quad9 (9.9.9.9) and Cloudflare (1.1.1.1). Arguably, these
servers have a better reputation of protecting the enduser's privacy
than most local networks, as endusers cannot trust most local networks
they use.

The question all of this raises is, whether the user isn't better of
just never trusting or using the local network's DNS server, whether
encrypted or not. In that case, all of these ADD documents have little
value. For example, we see this already with Firefox and its TRR program
https://wiki.mozilla.org/Trusted_Recursive_Resolver and to some extend
with the Android phone "private DNS" feature
https://www.howtogeek.com/795644/how-to-enable-secure-private-dns-on-android/

On the other hand, we have the argument of, if the enduser is using
the local unencrypted DNS, it might as well use the local encrypted DNS.
While this is true if this decision is hidden from the enduser, if the
enduser believes they are using "encrypted DNS", they might not be aware
that this encrypted connection still reveals all privacy sensitive data
to the local network entity (or its trusted third party). An aware enduser
might also make different choices when they think their DNS is "safely
encrypted", such as visiting the website of an abortion provider. That is,
the ADD specifications might lure the enduser in a false sense of security.
To me this is one of the biggest issues while reviewing the ADD drafts. Are
these drafts potentially harmful to the enduser, or does it only offer
improvements to the status quo of the current common (non-encrypted) DNS
topologies? While the latter could be true, I do believe based on the
development seen at Google/Android and Mozilla/Firefox, I think we are
already far into the phase where the enduser only decides _which_ remote
trustworthy encrypted DNS service they are going to use and as such only
use the local network DNS to kickstart their internet connection (captive
portal, paywall) after which they switch to remote encrypted DNS service.

And that of course, raises an issue with DNS security providers, who
wish to monitor and firewall all their DNS clients' DNS requests to
improve enduser security. This includes government mandates to ISPs to
filter certain DNS requests for local legal reasons. Which again raises
the issues of where such filtering power can be abused by authoritative
regimes, restrictive cults (eg scientology netnanny).

To summarize, I am really on the fence with respect to all the ADD drafts.
While "encrypted DNS" is always better than "unencrypted DNS", the
overarching issue of "never use or trust the local DNS resolvers" trumps
the DNR /DDR protocols. For those who can dictate how their users MUST
use DNS (eg Enterprise usage, parental control, opt-in security software),
device provisioning/configuration options are available that require no
ADD protocols with the exception of draft-ietf-add-svcb-dns.

###

Encrypted DNS servers need a public FQDN because otherwise you cannot get
a certificate for all connecting clients that are not provisioned with a
private/enterprise CA. How do home users run their own without having a
public domain? And how do I authenticate the encrypted DNS on 10.1.1.1
that has no FQDN? (and really, has no verifiable identity at all)

###

    The DNS client verifies the connection based on PKIX validation

No CRLs, OneCRL updates, no OCSP, no Certificate Transparency is available
without functional DNS. So full PKIX validation as specified here is not
available.

###

    The DNS client uses Web PKI trust anchors by default unless
    configured otherwise.

CAB/Forum is currently, as far as I know, not taking encrypted DNS into account
for their BR's. Also, every OS and even some applications use their own "webpki"
root store that differs from each other. This can lead to interoperability issues.

###

Spoofing attacks are mentioned in the document. Obtain _any_ certificate from Let's
Encrypt via ACME, eg using "something.example.com", then spoof authentication-domain-name
on the wifi. While this attack might be blocked by the AP not allowing wifi clients to
send packets to each other, this is not true for all networks, and especially not for
home networks where the goal is for local clients to be able to connect to each other.
Is there a better way to lock the authentication-domain-name? One possible method might
be to bind it to the ESSID. eg if the ESSID is wifi.nohats.ca. one could only allow
authentication-domain-name to be a name within nohats.ca. Some method of reducing the
scope of this attack is needed I believe.

###

  authentication-domain-name (variable length):  A fully qualified
      domain name of the encrypted DNS resolver.  This field is
      formatted as specified in Section 10 of [RFC8415].

      An example of the authentication-domain-name encoding is shown in
      Figure 2.  This example conveys the FQDN "doh1.example.com.", and
      the resulting Option-length field is 18.

      +------+------+------+------+------+------+------+------+------+
      | 0x04 |  d  |  o  |  h  |  1  | 0x07 |  e  |  x  |  a  |
      +------+------+------+------+------+------+------+------+------+
      |  m  |  p  |  l  |  e  | 0x03 |  c  |  o  |  m  | 0x00 |
      +------+------+------+------+------+------+------+------+------+

The draft says "as specified in Section 10 of [RFC8415]" but that is just
a redirect to Section 3.1 of [RFC1035] which doesn't tell me how to
encode the NAME. For example, I do not understand why one "." is encoded
as 0x07 and another "." is 0x03 ?

###

      Addr Length:  Length of enclosed IPv6 addresses in octets.  When
      present, it MUST be a multiple of 16.

Why not just a one octet counter then? The number of IPv6 addresses that follow.
Then the length of the Addr field becomes counter times 16 octets. That seems
more constrained than "multiple of 16"

###

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                              |
      |                        ipv6-address                          |
      |                                                              |
      |                                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The diagrams lack reference octets. What is the width ? or 4 rows ? or ?
I assume this is supposed to be 4 octets wide and 16 octets total? eg
I would write:

                          1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------------------------------------------------------+
      |                                                              |
      |                        ipv6-address                          |
      |                                                              |
      |                                                              |
      +---------------------------------------------------------------+
      |                              ...                              |
      +---------------------------------------------------------------+

(also my pet peeve is people using +-+-+-+ instead of -----)


###

      A value of zero means that this Authentication Domain Name MUST no
      longer be used.

Why not just omit the entry ? Are clients supposed to keep old entries for
their entire lifetime even if when asking a new list, those entries no longer
appear? That is not clear from this document. Either that should be made
explicit, or the values of 0 should not be allowed.

###

  By default, Encrypted DNS connections received from outside the local
  network MUST be discarded by the encrypted DNS forwarder in a CPE.

What is an "encrypted DNS forwarder in a CPE"? This is not defined in the
document and I am confused. I assume the CPE announces some encrypted DNS
server as either itself or to some external IP at the ISP network?

If itself, how can it get a real FQDN the client can verify with PKIX
using CAB/Forum ? If to an external IP, isn't it just acting as a NAT/router
forwarding packets and then what does it mean to be an "encrypted DNS forwarder" ?

###

  This recommendation is meant to isolate local network
  DNS resolver services from the public Internet and prevent external
  attacks against the local Encrypted DNS resolver.

  If the DHCP responses or RAs are dropped by the attacker, the client
  can fallback to use a preconfigured encrypted DNS resolver.

This raises the big question of why you think that strategy is a "fallback
strategy" and not the default behaviour of the client. Wouldn't it be more
secure if there is no DHCP/RA drop attacks possible? See my introduction text.

###

Multihoming is declared out of scope, but realistically most devices we are
talking about here are phones, and those are all multihomed. So I feel pretty
strongly that it should not be left out of scope.

[Ballot discuss]
After reading this document, I am unclear if it is permitted to omit IP addresses from the Encrypted DNS Option. It doesn't help that there are few normative keywords below:

(3.1.6) "In contexts where putting additional complexity on requesting hosts is acceptable, returning an ADN only can be considered."

(3.1.8) "the client makes the following validation checks:... the option includes at least one valid IP address and the "alpn" service parameter."

(3.1.9) "It is RECOMMENDED that at least the following DNR information... A list of IP addresses to locate the encrypted DNS resolver."

The option formats seem to allow the possibility of having zero addresses. ("0" is a multiple of 4 and 16).

I *think* you are saying it is possible to include an ADN, IP address(es), or both, but not neither, with "both" being RECOMMENDED. But that isn't really compatible with the client rejecting those as invalid in (3.1.8).

If that is accurate, I would recommend:
- deleting "at least one valid IP address and" from (3.1.8)
- Updating (3.1.9) to say that while both are RECOMMENDED, at least one of ADN and IP Address(es) MUST be included.

[Ballot discuss]
# Internet AD comments for {draft-ietf-add-dnr-11}
CC @ekline

## Discuss

This seem like exceptionally minor points, but are hopefully easily dispatched.

### S4.1, S5.1, S6.1

* The example ADN encoding in S4.1 shows that the trailing null byte is
  included in the encoding (the label length of the DNS root).

  This raises the question: why do any of these options need an explicit
  ADN length?  Given: the ADN is a mandatory message element, must be the
  first element in the message, and there can be no more than one such
  element, it seems that parsing bounded by the overall option length
  and validating the "RFC1035-ness" :-) of the span preceding the null byte
  might save a byte or two?

  (For comparison: the RFC 8801 PVD ID FQDN did not require a length hint.)

### S4.1, 6.1

* If an ADN length is to be retained in these messages, why is the ADN length
  2 bytes in the IPv6 variants whereas in the DHCPv4 option a 1 byte length
  suffices?  I know it seems silly to DISCUSS a 1 byte difference, but I
  figured it would be easy to either explain or fix.

* Similarly, why is the Addr Length 2 bytes?

  My reckoning of a 1-byte addr length would be the ability to list up to
  15 IPv6 addresses for a single ADN.  With 2 bytes a network can advertise
  ... over 4000 of them (for a single ADN)?

My suspicion is that the variable length nature of the ADN component means
these options are easily pushed out of 2/4/8 byte alignment, and there may
not be much benefit to attempting to adhere to something that only appears
like it might align well.

(Being parsimonious with bytes may be more of a concern for RAs than DHCP.)

[Ballot comment]
# Internet AD comments for {draft-ietf-add-dnr-11}
CC @ekline

## Comments

### S3.4

* I think it would be fair to note that RA options may be encapsulated within
  or associated with a PVD Option (RFC 8801) and that multihoming may be
  attempted by this mechanism, for client implementations with 8801 support.

### S7.1

* Consider rewording the active element doing the discarding/filtering:
  for sure "the router" may be doing the enforcement, but more broadly
  "the network infrastructure" might be doing the enforcement (e.g., at
  the switch, wireless access point, etc).

## Nits

### S7.4

* "an information" -> "any information", I think

[Ballot comment]
Thank you to Rich Salz for the SECDIR review.  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.  Is this preference to avoid putting this document in MISREF waiting for RFC6125bis?  If so, can the reference be reevaluate based on RFC6125bis’s maturing when this document goes to AUTH48?  If there is something more than the MISREF issue, can it please be explained? 

** Section 3.1.8.  Per the validation guidance, wouldn’t the following also apply:

-- The ADN is _present_ and encoded per Section 10 of [RFC8415]? Specifically, isn’t the ADN mandatory?

-- if apln=anything http, then dohpath MUST be present

** Section 3.1.9

  It is
  RECOMMENDED that at least the following DNR information is made
  available to a requesting host:
...
  *  An authentication domain name.

Isn’t the ADN mandatory?

** Section 3.3

  The DNS client verifies the connection based on PKIX validation
  [RFC5280] of the DNS resolver certificate and uses the validation
  techniques as described in [RFC6125] to compare the authentication
  domain name conveyed in the Encrypted DNS options to the certificate
  provided (see Section 8.1 of [RFC8310] for more details). 

-- Recommend being more precise and normative on the validation logic.  Section 8.1 of RFC8310 already references RFC6125 and RFC5280.

NEW

The DNS client MUST verify the certificate chain of the DNS resolver certificate and compare the authentication domain name conveyed in the Encrypted DNS options to the certificate provided per Section 8.1 of [RFC8310]. 

-- Regardless, RFC8310 and (depending on the text used) RFC6125+ RFC5280 need to be normative references since they are the canonical place to describe the prescribed validation behavior.

** Section 3.3

  The DNS
  client uses Web PKI trust anchors by default unless configured
  otherwise to use explicit trust anchors. 

Why is the default the Web PKI here but in draft-ietf-add-drr (per Section 4.2) a more generic “This SHOULD use the default system or application trust anchors”?

** Section 7.4

  Because of these attacks, only
  cryptographically authenticated communications are trusted on WLANs.
  This means that an information (e.g., NTP server, DNS resolver,
  domain search list) provided by such networks via DHCP, DHCPv6, or RA
  are untrusted because DHCP and RA messages are not authenticated.

I don’t understand the first sentence and the implications of the second.  Who is trusting what on WLANs?  What is the difference in behavior expected depending on the WLAN technology used?

** Section 7.4
  If the pre-shared key (PSK) is the same for all clients that connect
  to the same WLAN (e.g., WPA-PSK), the shared key will be available to
  all nodes, including attackers. 

Just because a PSK is used, why would the shared key be available to attackers.  The attacker would have to have access to one of those nodes with the PSK (unless they can extract it due to weak authentic mechanisms such as [Krack], etc).

** Section 7.4.  Editorially, I had trouble following this section.  What’s the DHCP/RA specific threat – is it that on-path attacks are possible in shared key environments – just like on a wired network?

** Other Editorial
-- Section 3.1.4.  Editorial.  Consider breaking this long sentence into two:

OLD
  A single option is used to convey both the ADN and IP addresses
  because otherwise means to correlate an IP address conveyed in an
  option with an ADN conveyed in another option will be required if,
  for example, more than one ADN is supported by the network.

NEW
A single option is used to convey both the ADN and IP addresses.  Otherwise a means to correlate an IP address conveyed in an option with an ADN conveyed in another option will be required if, or example, more than one ADN is supported by the network.

-- Section 3.1.5.  Editorial. s/has the merit relying/has the merit of relying/

-- Section 3.1.6.  Editorial. s/then issues/then issue/

[Ballot comment]
# GEN AD review of draft-ietf-add-dnr-11

CC @larseggert

## Comments

### Section 2, paragraph 6
```
    Encrypted DNS resolver:  refers to a DNS resolver that supports any
        encrypted DNS scheme.
```
Same as for  draft-ietf-add-ddr, wouldn't "encrypting resolver" be a more
accurate term?

### Section 3.4, paragraph 0
```
  3.4.  Multihoming Is Out Of Scope
```
Does this mean that if a device is multi-homed, the techniques in this
specification SHOULD NOT/MUST NOT be used?

### Section 4.1, paragraph 12
```
    Addr Length:  Length of enclosed IPv6 addresses in octets.  When
        present, it MUST be a multiple of 16.
```
Isn't this field always present, but would be zero if no ipv6-address(es) are?

### Section 5.1, paragraph 16
```
    Addr Length:  Length of included IPv4 addresses in octets.  When
        present, it MUST be a multiple of 4.
```
Isn't this field always present, but would be zero if no IPv4 address(es) are?

### Section 6.1, paragraph 15
```
    Addr Length:  16-bit unsigned integer.  This field indicates the
        length of enclosed IPv6 addresses in octets.  When present, it
        MUST be a multiple of 16.
```
Isn't this field always present, but would be zero if no ipv6-address(es) are?

### IANA

The IANA review of this document seems to not have concluded yet.

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

### Section 3.1.1, paragraph 2
```
        |  Some certification authorities issue server certificates based
        |  on IP addresses, but preliminary evidence indicates that such
        |  certificates are a very small percentage (less than 1%) of
        |  issued certificates.
```
It might be preferable to not include text from RFC6125 here, in case that is
ever subject to an errata or replacement or update by another document.

### Section 3.1.6, paragraph 3
```
        |  How an ADN is passed to a local resolution library is
        |  implementation specific.
```
Is there a reason this text is indented/quoted?

### URLs

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

* http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5

### Grammar/style

#### Section 6.1, paragraph 23
```
d by the attacker, the client can fallback to use a preconfigured encrypted
                                  ^^^^^^^^
```
The word "fallback" is a noun. The verb is spelled with a space.

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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-add-dnr-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Option Codes registry on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

https://www.iana.org/assignments/dhcpv6-parameters/

a new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: OPTION_V6_DNR
Client ORO: Yes
Singleton Option: No
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the BOOTP Vendor Extensions and DHCP Options registry on the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry page located at:

https://www.iana.org/assignments/bootp-dhcp-parameters/

a new registration will be made as follows:

Tag: [ TBD-at-Registration ]
Name: OPTION_V4_DNR
Data Length: N
Meaning: Encrypted DNS Server
Reference: [ RFC-to-be ]

Third, in the IPv6 Neighbor Discovery Option Formats registry on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at:

Type: [ TBD-at-Registration ]
Description: Encrypted DNS Option
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-07-08):

From: The IESG
To: IETF-Announce
CC: Andrew.Campling@419.Consulting, add-chairs@ietf.org, add@ietf.org, draft-ietf-add-dnr@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)) to Proposed Standard


The IESG has received a request from the Adaptive DNS Discovery WG (add) to
consider the following document: - 'DHCP and Router Advertisement Options for
the Discovery of Network-
  designated Resolvers (DNR)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-07-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The document specifies new DHCP and IPv6 Router Advertisement options
  to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over-
  TLS, DNS-over-QUIC).  Particularly, it allows a host to learn an
  authentication domain name together with a list of IP addresses and a
  set of service parameters to reach such encrypted DNS resolvers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-add-dnr/

The ADD WG has another document https://datatracker.ietf.org/doc/draft-ietf-add-ddr/, which should probably be reviewed at the same time.

No IPR declarations have been submitted directly on this I-D.

Title: DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

Current Version: draft-ietf-add-dnr-08



(1.a)  Who is the Document Shepherd for this document?

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it is ready for consideration by the IESG



(1.b)  Has the document had adequate review both from key WG members and from key non-WG members?

It has been reviewed by working group members, hence the number of iterations of the draft to date.  A total of 128 mailing list posts reference the various DDR drafts, complemented by closed issues and closed pull requests on GitHub.  The authors have also given updates on progress during working group sessions at IETF meetings to highlight the draft to a broader audience.

Looking outside of the ADD working group, there has been consultation with the DHC working Group on the DHCP content in this draft. 



Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of detailed reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub.  In addition, the authors have responded positively to points raised during discussions at IETF meetings, for example by leveraging SVCB.  Where proposed changes have been rejected, comments have been posted to the mailing list to explain the reasoning.

When the document has been updated, the authors have been careful to post an explanation of the changes to the mailing list to indicate what input has been taken on board in the new version. 



(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No – the authors have done a good job in highlighting specific sections where they have sought additional review or input.



(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.



Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign early after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than Verisign had filed a patent with the USPTO.  For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/



(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been discussion amongst a variety of individuals, with ten people mentioned in the acknowledgements section of the document.  I believe that the document represents the consensus view of the working group as a whole and that it addresses a significant need that was identified during previous working group discussions.



(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern, nor are there any known issues of extreme discontent or conflict. 



(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  Two outstanding nits remain as follows:

- “There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document” – this refers to the text “a1.a2.a3.a4, which is not in fact an FQDN but an address to illustrate the encoding

- “Missing Reference: 'ThisDocument' is mentioned on line 744, but not defined” – the three tables in the IANA Considerations section all contain a reference to [ThisDocument], which the RFC Editor will replace those with the RFC number to be assigned for this doc

Given the first is a false positive and the second will be addressed by the RFC editor, neither should prevent the document from progressing.



Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.



If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard



(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

draft-ietf-add-svcb-dns – Standards Track
draft-ietf-dnsop-svcb-https – Standards Track

RFC 2119 – BCP 14 (updated by RFC 8174)
RFC 2132 – Standards Track (updated by RFCs 3442, 3942, 4361, 4833, 5494)
RFC 3396 – Standards Track
RFC 4861– Standards Track (updated by RFCs 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425, 9131)
RFC 8106– Standards Track
RFC 8174– BCP 14
RFC 8415– Standards Track

As can be seen, seven of the nine normative references are to RFCs, with two referencing Internet-Drafts. 



Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

No.



If such normative references exist, what is the strategy for their completion? 

Not applicable.



Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable.



(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 8 of the document contains the IANA considerations, identifying the need for two option codes and one option type within existing registries.  Specifically, IANA is requested to:

- assign a new DHCPv6 Option Code in the registry maintained in “DHCPv6 Option Codes” (https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2)

- assign a new DHCP Option Code in the registry maintained in "BOOTP Vendor Extensions and DHCP Options" (https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options)

- assign a new IPv6 Neighbor Discovery Option type in the "IPv6 Neighbor Discovery Option Formats" sub-registry under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry (http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5)



If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Not applicable.



If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.



Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.



If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.



(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

Title: DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

Current Version: draft-ietf-add-dnr-08



(1.a)  Who is the Document Shepherd for this document?

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it is ready for consideration by the IESG



(1.b)  Has the document had adequate review both from key WG members and from key non-WG members?

It has been reviewed by working group members, hence the number of iterations of the draft to date.  A total of 128 mailing list posts reference the various DDR drafts, complemented by closed issues and closed pull requests on GitHub.  The authors have also given updates on progress during working group sessions at IETF meetings to highlight the draft to a broader audience.

Looking outside of the ADD working group, there has been consultation with the DHC working Group on the DHCP content in this draft. 



Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of detailed reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub.  In addition, the authors have responded positively to points raised during discussions at IETF meetings, for example by leveraging SVCB.  Where proposed changes have been rejected, comments have been posted to the mailing list to explain the reasoning.

When the document has been updated, the authors have been careful to post an explanation of the changes to the mailing list to indicate what input has been taken on board in the new version. 



(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No – the authors have done a good job in highlighting specific sections where they have sought additional review or input.



(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.



Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign early after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than Verisign had filed a patent with the USPTO.  For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/



(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been discussion amongst a variety of individuals, with ten people mentioned in the acknowledgements section of the document.  I believe that the document represents the consensus view of the working group as a whole and that it addresses a significant need that was identified during previous working group discussions.



(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern, nor are there any known issues of extreme discontent or conflict. 



(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  Two outstanding nits remain as follows:

- “There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document” – this refers to the text “a1.a2.a3.a4, which is not in fact an FQDN but an address to illustrate the encoding

- “Missing Reference: 'ThisDocument' is mentioned on line 744, but not defined” – the three tables in the IANA Considerations section all contain a reference to [ThisDocument], which the RFC Editor will replace those with the RFC number to be assigned for this doc

Given the first is a false positive and the second will be addressed by the RFC editor, neither should prevent the document from progressing.



Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.



If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard



(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

draft-ietf-add-svcb-dns – Standards Track
draft-ietf-dnsop-svcb-https – Standards Track

RFC 2119 – BCP 14 (updated by RFC 8174)
RFC 2132 – Standards Track (updated by RFCs 3442, 3942, 4361, 4833, 5494)
RFC 3396 – Standards Track
RFC 4861– Standards Track (updated by RFCs 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425, 9131)
RFC 8106– Standards Track
RFC 8174– BCP 14
RFC 8415– Standards Track

As can be seen, seven of the nine normative references are to RFCs, with two referencing Internet-Drafts. 



Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

No.



If such normative references exist, what is the strategy for their completion? 

Not applicable.



Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable.



(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 8 of the document contains the IANA considerations, identifying the need for two option codes and one option type within existing registries.  Specifically, IANA is requested to:

- assign a new DHCPv6 Option Code in the registry maintained in “DHCPv6 Option Codes” (https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2)

- assign a new DHCP Option Code in the registry maintained in "BOOTP Vendor Extensions and DHCP Options" (https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options)

- assign a new IPv6 Neighbor Discovery Option type in the "IPv6 Neighbor Discovery Option Formats" sub-registry under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry (http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5)



If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Not applicable.



If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.



Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.



If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.



(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

Title: DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

Current Version: draft-ietf-add-dnr-08


(1.a)  Who is the Document Shepherd for this document?

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it is ready for consideration by the IESG


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members?

It has been reviewed by working group members, hence the number of iterations of the draft to date.  A total of 128 mailing list posts reference the various DDR drafts, complemented by closed issues and closed pull requests on GitHub.  The authors have also given updates on progress during working group sessions at IETF meetings to highlight the draft to a broader audience.

Looking outside of the ADD working group, there has been consultation with the DHC working Group on the DHCP content in this draft. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of detailed reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub.  In addition, the authors have responded positively to points raised during discussions at IETF meetings, for example by leveraging SVCB.  Where proposed changes have been rejected, comments have been posted to the mailing list to explain the reasoning.

When the document has been updated, the authors have been careful to post an explanation of the changes to the mailing list to indicate what input has been taken on board in the new version. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No – the authors have done a good job in highlighting specific sections where they have sought additional review or input.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign early after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than Verisign had filed a patent with the USPTO.  For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been discussion amongst a variety of individuals, with ten people mentioned in the acknowledgements section of the document.  I believe that the document represents the consensus view of the working group as a whole and that it addresses a significant need that was identified during previous working group discussions.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern, nor are there any known issues of extreme discontent or conflict. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  Two outstanding nits remain as follows:

“There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document” – this refers to the text “a1.a2.a3.a4, which is not in fact an FQDN but an address to illustrate the encoding
“Missing Reference: 'ThisDocument' is mentioned on line 744, but not defined” – the three tables in the IANA Considerations section all contain a reference to [ThisDocument], which the RFC Editor will replace those with the RFC number to be assigned for this doc

Given the first is a false positive and the second will be addressed by the RFC editor, neither should prevent the document from progressing.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard



(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

draft-ietf-add-svcb-dns – Standards Track
draft-ietf-dnsop-svcb-https – Standards Track

RFC 2119 – BCP 14 (updated by RFC 8174)
RFC 2132 – Standards Track (updated by RFCs 3442, 3942, 4361, 4833, 5494)
RFC 3396 – Standards Track
RFC 4861– Standards Track (updated by RFCs 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425, 9131)
RFC 8106– Standards Track
RFC 8174– BCP 14
RFC 8415– Standards Track

As can be seen, seven of the nine normative references are to RFCs, with two referencing Internet-Drafts. 


Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

No.


If such normative references exist, what is the strategy for their completion? 

Not applicable.


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable.


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 8 of the document contains the IANA considerations, identifying the need for two option codes and one option type within existing registries.  Specifically, IANA is requested to:

- assign a new DHCPv6 Option Code in the registry maintained in “DHCPv6 Option Codes” (https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2)

- assign a new DHCP Option Code in the registry maintained in "BOOTP Vendor Extensions and DHCP Options" (https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options)

- assign a new IPv6 Neighbor Discovery Option type in the "IPv6 Neighbor Discovery Option Formats" sub-registry under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry (http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5)


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Not applicable.


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.



Title: DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

Current Version: draft-ietf-add-dnr-08


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it is ready for consideration by the IESG


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members?

It has been reviewed by working group members, hence the number of iterations of the draft to date.  A total of 128 mailing list posts reference the various DDR drafts, complemented by closed issues and closed pull requests on GitHub.  The authors have also given updates on progress during working group sessions at IETF meetings to highlight the draft to a broader audience.

Looking outside of the ADD working group, there has been consultation with the DHC working Group on the DHCP content in this draft. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of detailed reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub.  In addition, the authors have responded positively to points raised during discussions at IETF meetings, for example by leveraging SVCB.  Where proposed changes have been rejected, comments have been posted to the mailing list to explain the reasoning.

When the document has been updated, the authors have been careful to post an explanation of the changes to the mailing list to indicate what input has been taken on board in the new version. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No – the authors have done a good job in highlighting specific sections where they have sought additional review or input.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign early after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than Verisign had filed a patent with the USPTO.  For reference, the following link is to the relevant posts on the ADD mailing list.




(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been discussion amongst a variety of individuals, with ten people mentioned in the acknowledgements section of the document.  I believe that the document represents the consensus view of the working group as a whole and that it addresses a significant need that was identified during previous working group discussions.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern, nor are there any known issues of extreme discontent or conflict. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  Two outstanding nits remain as follows:

• “There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document” – this refers to the text “a1.a2.a3.a4, which is not in fact an FQDN but an address to illustrate the encoding


• “Missing Reference: 'ThisDocument' is mentioned on line 744, but not defined” – the three tables in the IANA Considerations section all contain a reference to [ThisDocument], which the RFC Editor will replace those with the RFC number to be assigned for this doc

Given the first is a false positive and the second will be addressed by the RFC editor, neither should prevent the document from progressing.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard



(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

 draft-ietf-add-svcb-dns – Standards Track
 draft-ietf-dnsop-svcb-https – Standards Track

 RFC 2119 – BCP 14 (updated by RFC 8174)
 RFC 2132 – Standards Track (updated by RFCs 3442, 3942, 4361, 4833, 5494)
 RFC 3396 – Standards Track
 RFC 4861– Standards Track (updated by RFCs 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425, 9131)
 RFC 8106– Standards Track
 RFC 8174– BCP 14
 RFC 8415– Standards Track

As can be seen, seven of the nine normative references are to RFCs, with two referencing Internet-Drafts. 


Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

No.


If such normative references exist, what is the strategy for their completion? 

Not applicable.


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable.


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 8 of the document contains the IANA considerations, identifying the need for two option codes and one option type within existing registries.  Specifically, IANA is requested to:

- assign a new DHCPv6 Option Code in the registry maintained in “DHCPv6 Option Codes” ()

- assign a new DHCP Option Code in the registry maintained in "BOOTP Vendor Extensions and DHCP Options" ()

- assign a new IPv6 Neighbor Discovery Option type in the "IPv6 Neighbor Discovery Option Formats" sub-registry under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry ()


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Not applicable.


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

##Title: DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

####Current Version: draft-ietf-add-dnr-08


*(1.a)  Who is the Document Shepherd for this document?* 

Document Shepherd: Andrew Campling


*Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?*

I have reviewed the document and believe that it is ready for consideration by the IESG


*(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

It has been reviewed by working group members, hence the number of iterations of the draft to date.  A total of 128 mailing list posts reference the various DDR drafts, complemented by closed issues and closed pull requests on GitHub.  The authors have also given updates on progress during working group sessions at IETF meetings to highlight the draft to a broader audience.

Looking outside of the ADD working group, there has been consultation with the DHC working Group on the DHCP content in this draft. 


*Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of detailed reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub.  In addition, the authors have responded positively to points raised during discussions at IETF meetings, for example by leveraging SVCB.  Where proposed changes have been rejected, comments have been posted to the mailing list to explain the reasoning.

When the document has been updated, the authors have been careful to post an explanation of the changes to the mailing list to indicate what input has been taken on board in the new version. 


*(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?*

No – the authors have done a good job in highlighting specific sections where they have sought additional review or input.


*(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.* 

No.


*Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.*

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign early after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than Verisign had filed a patent with the USPTO.  For reference, the following link is to the relevant posts on the ADD mailing list.




*(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?*

There has been discussion amongst a variety of individuals, with ten people mentioned in the acknowledgements section of the document.  I believe that the document represents the consensus view of the working group as a whole and that it addresses a significant need that was identified during previous working group discussions.


*(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)*

There are no open issues that I am aware of, nor any other outstanding areas of concern, nor are there any known issues of extreme discontent or conflict. 


*(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough.* 

Yes.  Two outstanding nits remain as follows:
- “There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document” – this refers to the text “a1.a2.a3.a4, which is not in fact an FQDN but an address to illustrate the encoding
- “Missing Reference: 'ThisDocument' is mentioned on line 744, but not defined” – the three tables in the IANA Considerations section all contain a reference to [ThisDocument], which the RFC Editor will replace those with the RFC number to be assigned for this doc

Given the first is a false positive and the second will be addressed by the RFC editor, neither should prevent the document from progressing.


*Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews?* 

Not applicable.


*If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.*

Intended RFC status: standard



*(1.h)  Has the document split its references into normative and informative?* 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

     draft-ietf-add-svcb-dns – Standards Track
     draft-ietf-dnsop-svcb-https – Standards Track

     RFC 2119 – BCP 14 (updated by RFC 8174)
     RFC 2132 – Standards Track (updated by RFCs 3442, 3942, 4361, 4833, 5494)
     RFC 3396 – Standards Track
     RFC 4861– Standards Track (updated by RFCs 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425, 9131)
     RFC 8106– Standards Track
     RFC 8174– BCP 14
     RFC 8415– Standards Track

As can be seen, seven of the nine normative references are to RFCs, with two referencing Internet-Drafts. 


*Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?* 

No.


*If such normative references exist, what is the strategy for their completion?* 

Not applicable.


*Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].*

Not applicable.


*(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document?* 

Section 8 of the document contains the IANA considerations, identifying the need for two option codes and one option type within existing registries.  Specifically, IANA is requested to:

- assign a new DHCPv6 Option Code in the registry maintained in “DHCPv6 Option Codes” ()

- assign a new DHCP Option Code in the registry maintained in "BOOTP Vendor Extensions and DHCP Options" ()

- assign a new IPv6 Neighbor Discovery Option type in the "IPv6 Neighbor Discovery Option Formats" sub-registry under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry ()


*If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified?* 

Not applicable.


*If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations?* 

Not applicable.


*Does it suggest a reasonable name for the new registry?  See [RFC2434].* 

Not applicable.


*If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?*

Not applicable.


*(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?*

Not applicable.