Re: [Add] AD review of draft-ietf-add-resolver-info-09 and the associated shepherd write-up

[[e-mail]]

Hi Éric,

Thanks for the review. 

A candidate version to address your review can be seen 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/boucadair-patch-2/draft-ietf-add-resolver-info.txt.

Please see inline for more context. 

Cheers,
Med

> -----Message d'origine-----
> De : Add <[e-mail]> De la part de Eric Vyncke (evyncke)
> Envoyé : mercredi 14 février 2024 11:11
> À : [e-mail]
> Objet : [Add] AD review of draft-ietf-add-resolver-info-09 and the
> associated shepherd write-up
> 
> Tiru, Med, and ADD WG,
> 
> First of all, thank you for all the work done on this draft.
> 
> Please find below my AD review of draft-ietf-add-resolver-info-09.
> 
> Before proceeding with the publication process, i.e., the IETF Last
> Call, I am requesting a reply to all the points below, either by a
> simple reply or by a text change.
> 
> Tommy,
> 
> Thank you for the detailed shepherd write-up (barring the absence of
> intended status justification) and I smiled when reading that your own
> employer does not intend to implement this feature (this part was
> written with sensitivity -- thanks).
> 
> # COMMENTS
> 
> ## Section 1
> 
> Just to be clear s/ upstream resolvers/ upstream recursive resolvers/
> 

[Med] OK

> ## Section 3
> 
> Please qualify "the resolver" in `If the resolver understands the
> RESINFO RR`, i.e., is it the stub or recursive ? Also in a couple of
> other places.
> 

[Med] ACK. Went with "DNS client" to be consistent through the document.  

> Adding an example would be appreciated by the readers.
> 
> ## Section 4
> 
> `The motivation for using the same format as TXT records is to convey
> a small amount of useful information about a DNS resolver`
> 
> Unsure whether the above text brings any value.

[Med] ACK

> 
> ## Section 5
> 
> Which "server" it is in `The server MUST support the content-type
> 'text/html'.`
> 

[Med] Changed to "resolver information server". This term is used in the sentence right after.

> s/ if and only if the encrypted resolver has sufficient reputation,
> according to some local policy/ if and only if according to some local
> policy/ ? Using the term "reputation" is rather vague.
> 

[Med] Reputation is a key aspect to trust the info. A local policy is provided as an example to feed that info. I'm not sure we need to cite documents, e.g., RFC 7070, for a generic definition of reputation:

=
   With the advent of these authentication protocols, it is possible to
   satisfy the requirement for a mechanism by which mutually trusted
   parties can exchange assessment information about other actors.  For
   these purposes, we may usefully define "reputation" as "the
   estimation in which an identifiable actor is held, especially by the
   community or the Internet public generally".  (This is based on the
   definition of "reputation" in [RANDOMHOUSE].)  We may call an
   aggregation of individual assessments "reputation input".

   While the need for reputation services has been perhaps especially
   clear in the email world, where abuses are commonplace, other
   Internet services are coming under attack and may have a similar
   need.  For instance, a reputation mechanism could be useful in rating
   the security of web sites, the quality of service of an Internet
   Service Provider (ISP), or an Application Service Provider (ASP).
== 

> The infourl example is rather weird as it seems to indicate that the
> host server must be collocated with the DNS recursive resolver...
> 

[Med] Please note that the example uses "example.com" and "example.net".

> ## Section 6
> 
> s/ the attributes received from the resolver, which will be used for
> resolver selection or display / the attributes received from the
> resolver *that* will be used for resolver selection or *displayed* /
> 

[Med] OK

> This section also uses the term "reputation" that is rather vague and
> does not add any value, why not simply using "according to local
> policy" ?

[Med] Idem as above.

> 
> # NITS

[Med] Fixed all. Thanks. 

> 
> ## Abstract
> 
> s/ the scope of the document/ the scope of this document/
> 
> ## Section 1
> 
> s/ that may impact delivered DNS services, means to help stub
> resolvers/ that may impact delivered DNS service; means to help stub
> resolvers/ or another to make easier the parsing of the sentence.
> 
> ## Section 4
> 
> s/ The resolver information uses/ The resolver information record
> uses/
> 
> ## Section 5
> 
> s/ possibily/ possibly/
> 
> ## Section 6
> 
> s/ DNS clients communicating with DNS resolvers discovered MUST employ
> / DNS clients communicating with *discovered* DNS resolvers MUST *use*
> / (2 changes)
> 
> ## Section 7
> 
> s/ occurences/ occurrences/
> 
____________________________________________________________________________________________________________
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.