Skip to main content

Shepherd writeup
draft-ietf-add-resolver-info

Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-09

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

Document Shepherd: Tommy Jensen

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?

Yes, the document shepherd has reviewed the latest document draft and believes
it is ready for forwarding to the IESG. 

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

Yes.

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

No. The WG conducted a second review and LC at IETF 118 in response to a previous shepherd 
review that uncovered a security issue in -07 which is now addressed by -09.

(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 WG has fairly broad DNS representation, and this draft does not leave
that domain (no use of SVCB or other formats defined elsewhere, for example).
The Expert Review for the new RR type has now also taken place.

(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. The shepherd has clearly stated that his sponsor has no intention of
implementing, but it is due to a lack of scenario rather than opposition to
architecture. The shepherd has agreed to advance and champion the document as a
representation of WG consensus for use by others.

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 as of February 14th
2024.

(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?

It is a strong concurrence of a few individuals, but is still widely understood and accepted
by the WG.

(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.)

In short, no, the document shepherd does not believe there is a risk of
escalation, appeal, or retaliation by malcontent parties if this document is
published as an RFC.

Speaking as an industry member, the document shepherd is aware of parties who
have no interest in implementing the mechanism described in this document
(including his own employer), but none of these parties are opposed to the
standard itself for use by other parties. The reasons for not implementing
known to the document shepherd are rooted in product strategy reasoning, not
ethical or security concerns that would translate to valid reasons to block
publication.

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

On February 14th, 2024, the document shepherd ran the idnits tool version 2.17.1
and found two nits. One is “Unused Reference: 'I-D.pp-add-resinfo' is defined on line
390, but no explicit reference was found in the text”. This document is
referenced in the Acknowledgements section at the end of the document,
following the References section. The authors and document shepherd agree
having the reference is valuable as the referenced draft was a major source for
this document. The other nit was related to the document’s date being in the past (which is
expected).

Neither nit should prevent the document from proceeding through the
publication process.

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

An Expert Review for the new DNS RR type defined by this document has taken
place. The document shepherd does not believe there are other reviews required
for this document.

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: Proposed Standard
Justification: This document has the WG’s consensus after significant review, including resolving
design choices to be compatible with the expectations of more parties than the document authors
alone. In the shepherd’s opinion, this drafts meets all of the requirement in RFC 2026 Section 4.1.1
for a Proposed Standard (which was left unchanged by RFC 6410 Section 2.1 when the standard
tracks were reduced).

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

Yes, the document splits normative and informative references.

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

RFC 1035 – Standards Track (updated by 28 RFCs, most recently RFC 8767)
RFC 2119BCP 14 (updated by RFC 8174)
RFC 6763 – Standards Track (updated by RFC 8553)
RFC 8126BCP 26 (not updated)
RFC 8174BCP 14 (not updated)
RFC 8446 – Standards Track (not updated)
RFC 8914 – Standards Track (not updated)
RFC 9156 – Standards Track (not updated)
RFC 9462 - Standards Track (not updated)
RFC 9463 - Standards Track (not updated)

The informative references, together with an indication of the type and whether
they have been updated, are as follows:

I-D.pp-add-resinfo – intended for Standards Track, but expired (WG has rejected)
IANA-DNS – IANA’s “Domain Name System (DNS) Parameters” list
RFC 7858 – Standards Track (updated by RFC 8310)
RFC 8484 – Standards Track (not updated)
RFC 8499BCP 219 (not updated)
RFC 9250 – Standards Track (not updated)
RRTYPE – IANA’s “Resource Record (RR) TYPEs” list

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. All normative references are either RFC-published Standards
Track or BCP.

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

Yes, the IANA considerations section exists. Yes, the IANA and RFC Editor
requests are consistent with the rest of the document.

There are two IANA requests (document shepherd notes added in <> brackets):
  Create a new DNS RR TYPE with the following properties:
    Type: RESINFO
    Value: 261
    Meaning: Resolver Information as Key/Value Pairs
    Reference: RFCXXXX <this document>
  Create a new registry entitled “DNS Resolver Information Keys” under the
  “Domain Name System (DNS) Parameters” with the following columns:
    Name <string for the key’s name>
    Description <string describing the purpose of the key>
    Specification <document that defines the key>

The fields provided meet precedent for recent RR TYPE entries requested, namely
the SVCB and HTTPS RR TYPEs defined in draft-ietf-dnsop-svcb-https-12 sections
14.1 and 14.2. Additionally, the guidance in RFC 6895 was followed per
IANA’s guidance to get the RR type Expert Review.

In addition to the two IANA-specific requests, there is a note to the RFC
Editor to update all instance of “RFCXXXX” in the document with the final RFC
number granted to the document upon publication. Instances of “RFCXXXX” can be
found in Sections 7, 7.1, 7.2 (contained to the IANA considerations section).

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

Yes (see above).

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

Yes.

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

Yes.

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?

The Expert Review defined as required for new RR types in RFC 6895 has taken
place.

(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?

N/A. The closest thing to this is the example content of the new record type
defined within the document.
Back