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 14RFC 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.