Title: Service Binding Mapping for DNS Servers
Current Version: draft-ietf-add-svcb-dns-03
(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 will be ready for
consideration by the IESG after it is updated to correct some normative
referencing issues (see 1.g and 1.h below).
(1.b) Has the document had adequate review both from key WG members and from
key non-WG members?
The document was written to harmonise several different drafts that all
proposed to use the SVCB format to convey information about a DNS server that
supports encrypted transport. This document specifies a minimal SVCB mapping
for DNS URIs without addressing any particular use case. Draft-ietf-add-ddr
and draft-ietf-add-dnr have both followed the approach outlined in this
document.
The document has had detailed reviews by working group members, with replies to
the mailing list by the author indicating how the comments have been addressed.
All issues and pull requests on GitHub are closed.
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.
(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. Two outstanding nits remain as follows:
- Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113)
- Duplicate reference: RFC8484, mentioned in 'RFC8484', was also mentioned in
'DOH'.
Both have been highlighted to the author so should be addressed shortly.
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:
DOH (RFC 8484) – standards Track (also referenced as RFC 8484)
DOT (RFC7858) – standards Track (updated by RFC8310)
RFC 2119 – BCP 14 (updated by RFC 8174)
RFC 3629 – Standards Track
RFC 6570 – Standards Track
RFC 7540 – Standards Track (updated by RFC 8740, obsoleted by RFC 9113)
RFC 8174 – BCP 14RFC 8484 – Standards Track
SVCB (Internet-Draft) - Standards Track
NB The DNSOP SVCB doc is already in the RFC editor queue.
Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state?
Eight of the nine normative references are to RFCs, with the remaining one
referencing an Internet-Draft. The text in the draft providing the link to the
Internet-Draft currently references an older version which has been superseded.
If such normative references exist, what is the strategy for their completion?
I’ve asked the author to remove the “DOH” reference and replace it with RFC8484
to avoid clashing references to the same document, and to replace the “DOT”
reference with RFC7858 for consistency of referencing. I’ve asked the author
to replace the reference to RFC7580 with an appropriate reference to RFC 9113.
The link to the Internet-Draft 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].
(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 9 of the document contains the IANA considerations, identifying the
need for additions to the SVCB Service Parameters and DNS Underscore Global
Scoped Entry Registries. Specifically, IANA is requested to add the following
entries:
- SVCB Service Parameters Registry
Number – 7; Name – dohpath; Meaning - DNS over HTTPS path template
- DNS Underscore Global Scoped Entry Registry
RR Type – SVCB; _Node Name - _dns; Meaning – DNS SVCB Info
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.