Skip to main content

Last Call Review of draft-ietf-add-resolver-info-10
review-ietf-add-resolver-info-10-dnsdir-lc-reid-2024-02-28-00

Request Review of draft-ietf-add-resolver-info
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team DNS Directorate (dnsdir)
Deadline 2024-02-29
Requested 2024-02-15
Authors Tirumaleswar Reddy.K , Mohamed Boucadair
I-D last updated 2024-02-28
Completed reviews Genart Last Call review of -11 by Mallory Knodel (diff)
Dnsdir Last Call review of -10 by Jim Reid (diff)
Artart Last Call review of -10 by Arnt Gulbrandsen (diff)
Dnsdir Telechat review of -11 by Jim Reid (diff)
Artart Telechat review of -11 by Arnt Gulbrandsen (diff)
Dnsdir Early review of -02 by Johan Stenstam (diff)
Dnsdir Telechat review of -11 by Jim Reid (diff)
Assignment Reviewer Jim Reid
State Completed
Request Last Call review on draft-ietf-add-resolver-info by DNS Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/dnsdir/FsRp2Ap5H3yabEwGmd0M8OVFarQ
Reviewed revision 10 (document currently at 13)
Result Ready w/nits
Completed 2024-02-28
review-ietf-add-resolver-info-10-dnsdir-lc-reid-2024-02-28-00
I have replaced Johan Stemstan as the dnsdir reviewer of this ID. The
comments made in his earlier review(s) have been addressed. Overall,
the document is concise and clear. It is easy to understand. The ID is
almost ready for publication.

There are however some largely cosmetic nits.

1 "upstream resolver server" seems a tautology. What else could a
resolver server be? Besides, upsteam of what? Are there any downstream
resolvers?

The term "upstream resolver" has crept into a few RFCs but it doesn't
appear to have been formally defined by the IETF. For simplicity, I
think the ID should just say "resolver server" and avoid "upstream
resolver" entirely.

2 The first two sentences of section 1 are clunky. I think they could
be replaced with:

"Historically, DNS clients have not needed to know about which
features (if any) were provided by their corresponding recursive
resolver servers. Recent developments which include DoH (RFC8484) and
Extended Error Reporting (RFC8914) mean that earlier assumption no
longer generally applies. Instead of depending on opportunistic
approaches, modern DNS clients need a more reliable way to discover
which of these newer resolver features are available so they can then
make use of them."

3) Clearer guidance on the size of RESINFO records would be helpful.
RFC6763 mumbles in places about "only a few hundred bytes". RESINFO
RRs are unlikely to be bigger than that and I think it would be
prudent to say so in this ID. Better still,the draft could say RESINFO
responses should not be bigger than N bytes. For some value of N.

4) "RESINFO RR type query" should be "query for RESINFO QTYPE". QTYPE
is the term used in RFC1035. So there! ;-)

5) RFC7070's definition of reputation is poor. It comes from a source
that seems to be unavailable on-line. I think the I-D should directly
reference a decent on-line dictionary's definition of "reputation",
preferably the OED's. [Webster's and its variants are an affront to
the English language IMO.]