Hi Joe, Many thanks for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Joe Clarke via Datatracker <noreply@xxxxxxxx> > Envoyé : vendredi 8 juillet 2022 17:00 > À : ops-dir@xxxxxxxx > Cc : add@xxxxxxxx; draft-ietf-add-dnr.all@xxxxxxxx; last- > call@xxxxxxxx > Objet : Opsdir last call review of draft-ietf-add-dnr-10 > > Reviewer: Joe Clarke > Review result: Has Nits > > I have been tasked to review this document on behalf of the OPS > directorate. > This document describes new means by which a DNS client can > discover encrypted DNS services by DHCPv4, DHCPv6, and/or IPv6 RA > messages. From an operational point of view, I found the > description of the protocol and how the client behaves to be good. > I was pleased to see sections that described why certain > considerations were made. That said, I didn't see any discussion > of how a DHCP client would treat encrypted DNS options along with > the standard name-server (option 6, v6 option 23) in DHCP or the > RDNSS. [Med] We don't include such details because: * Whether a client asks for Do53 in addition to encrypted DNS is implementation and policy based. * Also, how a DNS selects among learned Do53 and Encrypted DNS servers is beyond discovery. You mention you initially thought of using those > approaches, but that leads to probing. > > Section-wise, I found a couple of nits: > > Section 3.1.8: > > s/If the checks fail, the receiver discards/If any of the checks > fail, the receiver MUST discard/ [Med] OK for the first part of the suggested change. For the second one, we are not using the normative language on purpose because otherwise this will be redundant with text such as: The DHCPv6 client MUST silently discard any OPTION_V6_DNR that fails to pass the validation steps defined in Section 3.1.8. > > I felt this makes the text both clearer and more normative. You > use normative language in later sections when referring to 3.1.8. > > === > > Section 5.1: > > In the figure, I feel TBA2 should be replaced with OPTION_V4_DNR. > [Med] Fixed. Thanks. _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
