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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hi Med,

Barring the nits about "possibily" and the absence of an example in section 3, please submit this revised I-D and will initiate the IETF Last Call.

See below for some EV> (nothing blocking, just a reply to yours).

***Tommy, please provide the requested justification for the intended status.***

Regard and thanks for the super-fast reaction.

-éric

PS: among French-speaking engineers, can you use "Éric" rather than "Eric" ;-) in the Acknowledgements ?(it is written with a big smile tough)

On 14/02/2024, 13:10, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


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 <https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/add-resolver-information/draft-ietf-add-resolver-info.txt&amp;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] <mailto:[e-mail]>> De la part de Eric Vyncke (evyncke)
> Envoyé : mercredi 14 février 2024 11:11
> À : [e-mail] <mailto:[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.

EV> still missing but it was a mere suggestion

> 
> ## 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).
== 

EV> adding a reference to RFC 7070 could help indeed, I am still uneasy with the wording.
EV> but, if authors and WG want to go with the wording, then let it go.

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

EV> I either need new reading glass or another cup of coffee...

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