Re: [Add] Dnsdir last call review of draft-ietf-add-resolver-info-10

[[e-mail]]

Hi Jim, 

Thanks for the review. 

The changes made so far to address your review can be tracked at: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/add-resolver-information/draft-ietf-add-resolver-info.txt&url_2=https://boucadair.github.io/add-resolver-information/Jim-Review/draft-ietf-add-resolver-info.txt

Please see more context inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jim Reid via Datatracker <[e-mail]>
> Envoyé : mercredi 28 février 2024 15:07
> À : [e-mail]
> Cc : [e-mail]; [e-mail]; last-
> [e-mail]
> Objet : Dnsdir last call review of draft-ietf-add-resolver-info-10
> 
> Reviewer: Jim Reid
> Review result: Ready with Nits
> 
> 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?
> 

[Med] Fixed.

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

[Med] Thanks. 

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

[Med] 6.1 of 6763 points to 6.2 which includes clear guidance than "few hundreds". I think the guidance in 6.2 of 6763 is fine.

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

[Med] ACK.

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

[Med] The point of citing 7070 is to contextualize the term for Internet technologies. This was added to address a comment from Éric. I suggest to keep this reference.

> 

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.