Title: Discovery of Designated Resolvers
Current Version: draft-ietf-add-ddr-06
(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 extensively reviewed by working group members, hence the number of
iterations of the draft to date. Just under 150 mailing list posts directly
reference the various DDR drafts, complemented by 34 closed issues and 27
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 6man
on the way that RFC 8106 has been interpreted. In addition, support for DDR
has already been implemented by Cisco in its Umbrella software, by Quad9 in its
resolver, Microsoft in its Windows operating system and by Apple in both iOS 16
and macOS Ventura.
Does the Document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?
No. A number of reviews of the document were posted to the working group
mailing list, along with the issues and pull requests logged on GitHub.
(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 shortly 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 that 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 extensive discussion amongst a variety of individuals. I
believe that the document represents the consensus view of the working group as
a whole.
(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.
(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. One outstanding nit remains as follows:
- There are 7 instances of lines with non-RFC2606-compliant FQDNs in the
document – this is a false positive caused by references to “resolver.arpa” in
the text
In addition, although not essential, the draft would benefit from the addition
of a temporary implementation status section to aid reviewers and marked for
removal by the RFC editor before publication. This has been flagged to the
authors for their consideration.
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, the link in the text references -02
which expires 5 August 2022, the document is currently at version 3
draft-ietf-dnsop-svcb-https – Standards Track, the link in the text references
-08 which expired 15 April 2022, the document is currently at version 10
RFC 1918 – BCP 5 (updated by RFC 6761)
RFC 6303 – BCP 163RFC 6761 – Standards Track
RFC 7858– Standards Track (updated by RFC 8310)
RFC 8484– Standards Track
Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state?
Five of the seven normative references are to RFCs, with the remaining two
referencing Internet-Drafts. The text in the draft providing links to the two
Internet-Drafts currently references older versions which have been superseded
by new drafts.
If such normative references exist, what is the strategy for their completion?
The links to the relevant Internet-Drafts will update during the next iteration
of the document.
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, addressing the need
for a special use domain name “resolver.arpa” as referenced elsewhere in the
document. Specifically, IANA is requested to add an entry in
"Transport-Independent Locally-Served DNS Zones" registry for 'resolver.arpa.'
with the description "DNS Resolver Special-Use Domain", listing this document
(ie DDR) as the reference.
If the document specifies protocol extensions, are reservations requested in
appropriate IANA registries? Are the IANA registries clearly identified?
Yes. The document calls for the addition of "resolver.arpa" to the Special-Use
Domain Names (SUDN) registry established by RFC 6761. IANA is requested to add
an entry in "Transport-Independent Locally Served DNS Zones" registry for
'resolver.arpa.' with the description "DNS Resolver Special-Use Domain"
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.