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

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

Thank you Tommy

-éric

On 14/02/2024, 18:24, "Tommy Jensen" <Jensen.Thomas=[e-mail] <mailto:[e-mail]>> wrote:


Hey Éric,


I've just updated the shepherd write up as requested. Thank you for your review as always!


Thanks,
Tommy


> -----Original Message-----
> From: Add <[e-mail] <mailto:[e-mail]>> On Behalf Of Eric Vyncke (evyncke)
> Sent: Wednesday, February 14, 2024 8:25 AM
> To: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Subject: [EXTERNAL] Re: [Add] AD review of draft-ietf-add-resolver-info-09 and
> the associated shepherd write-up
>
> [Certaines personnes qui ont reçu ce message ne reçoivent pas souvent de
> courriers de evyncke=[e-mail] <mailto:[e-mail]>. Découvrez pourquoi ceci est
> important à https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/LearnAboutSenderIdentification> ]
>
> 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]>
> <mailto:[e-mail] <mailto:[e-mail]>>"
> <[e-mail] <mailto:[e-mail]>
> <mailto:[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%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fboucadair.github.i
> o%2Fadd-resolver-information%2Fdraft-ietf-add-resolver-
> info.txt%26url_2%3Dhttps%3A%2F%2Fboucadair.github.io%2Fadd-resolver-
> information%2Fboucadair-patch-2%2Fdraft-ietf-add-resolver-
> info.txt&data=05%7C02%7CJensen.Thomas%40microsoft.com%7C7aa3a1e279d
> b494e2eac08dc2d797aa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0
> %7C638435247016600679%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C
> &sdata=DZ8QOTyQLmRFAPTwOhbRmlXoFq%2B7KUplFKZMSIP2%2Fqc%3D&res
> erved=0
> <https://author/
> -
> tools.ietf.org%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fboucadair.github.i
> o%2Fadd-resolver-information%2Fdraft-ietf-add-resolver-
> info.txt%26amp%3Burl_2%3Dhttps%3A%2F%2Fboucadair.github.io%2Fadd-
> resolver-information%2Fboucadair-patch-2%2Fdraft-ietf-add-resolver-
> info.txt&data=05%7C02%7CJensen.Thomas%40microsoft.com%7C7aa3a1e279d
> b494e2eac08dc2d797aa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0
> %7C638435247016623201%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C
> &sdata=zhTtIcSXfADT3atqDTFx4hSAUbQqtcfZ4rj2GDEuBhA%3D&reserved=0>.
>
>
> Please see inline for more context.
>
>
> Cheers,
> Med
>
>
> > -----Message d'origine-----
> > De : Add <[e-mail] <mailto:[e-mail]> <mailto:[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]> <mailto:[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.
>
>
>
>
>
> --
> Add mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ie/ <https://www.ie/>
> tf.org%2Fmailman%2Flistinfo%2Fadd&data=05%7C02%7CJensen.Thomas%40mi
> crosoft.com%7C7aa3a1e279db494e2eac08dc2d797aa2%7C72f988bf86f141af9
> 1ab2d7cd011db47%7C1%7C0%7C638435247016634381%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C0%7C%7C%7C&sdata=mOVCnmZH3Zo0cPV%2BCI7%2FPhaeSia3
> RB1c6HABLeWgn%2B8%3D&reserved=0