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