Hi David, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : David Blacka via Datatracker <noreply@xxxxxxxx> > Envoyé : vendredi 14 avril 2023 23:57 > À : dnsdir@xxxxxxxx > Cc : add@xxxxxxxx; draft-ietf-add-dnr.all@xxxxxxxx; last-call@xxxxxxxx > Objet : Dnsdir last call review of draft-ietf-add-dnr-15 > > Reviewer: David Blacka > Review result: Ready with Nits > > Overall I found this draft well-written, straightforward, and relatively > easy to follow (although there are a lot of external RFC references). > > Some overall advice: > > It would be helpful to put "ADN" in the list of terms (section 2). It is > defined in the introduction, but it is used liberally in the rest of the > document and a reader might expect to be able to find in the terms > section. > [Med] Done. Please see https://tinyurl.com/latest-dnr-changes > Additionally, "ADN-only" might be helpful to put in the list of terms. > This term is used less often, but it is repeated far enough away from > section 3.1.6 to possibly be helpful in section 2. > [Med] Done. See the diff. > I don't really want to suggest that you change the various option > formats, but as a DNS person, I had an observation about them. > > * The "ADN length" should not be necessary as wire-format DNS > names are actually length encoded. [Med] Agree. We considered this in the past, but we are trying to not deviate from the guidelines set by the WGs that owns the protocols we are using. Please see, e.g., https://mailarchive.ietf.org/arch/msg/add/8bFZgNdS9vVy7PBYuUwXhBFAAa4/. Providing the ADN length does, > however, allow a parser to skip over the name without parsing the > ADN itself which may be useful. * The "ADN length" doesn't need to > be 16-bits, and it isn't in the > DHCPv4 format. It is a little curious that the length of this field differs > across the different option implementations. [Med] This is to be consistent with the usage in DHCPv6. > > Beyond that, I just had some language nits: > > In section 3: > > > This document describes how a DNS client can discover local > encrypted > > DNS > resolvers using DHCP (Sections 4 and 5) and Neighbor Discovery > protocol (Section 6): Encrypted DNS options. > > This seems odd. I think this sentence could just end after "(Section 6)". > [Med] I prefer to leave the text as it is. The sentences right after refers to these options. > In section 3.2.1: > > > To avoid adding a dependency on another server to resolve the ADN, > the > Encrypted DNS options return the IP address(es) to locate the > encrypted DNS resolver. These encrypted DNS resolvers may be > hosted on the same or distinct IP addresses. Such a decision is > deployment specific. > > I found this wording of the 2nd sentence hard to follow. Hard enough > to follow that I don't know what is trying to be said. Maybe the 2nd > and 3rd sentences could just be deleted? > [Med] The main message is that the resolvers returned in Encrypted DNS options may share the same IP address or have dedicated IP addresses. > In section 3.1.6: > > Why is there a block quote here? What is it quoting? > [Med] This is an aside element as per rfc7991.html#section-2.6: This element is a container for content that is semantically less important or tangential to the content that surrounds it. > In section 3.1.8: > > > The ADN is present and encoded as per Section 10 of [RFC8415]. > > In addition to providing the RFC reference, one could also describe the > encoding as "uncompressed DNS wire format." > > [Med] That is covered in RFC8415. I prefer to leave the current wording. 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
