Hi Di, Thanks for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Di Ma via Datatracker <nore...@ietf.org> > Envoyé : lundi 26 juin 2023 07:59 > À : dns...@ietf.org > Cc : dnsop@ietf.org; draft-ietf-dnsop-structured-dns- > error....@ietf.org > Objet : Dnsdir early review of draft-ietf-dnsop-structured-dns- > error-03 > > Reviewer: Di Ma > Review result: Ready with Nits > > Generally speaking, I think the extension to DNS proposed by this > document will not affect DNS operations adversely since it is > common and mature to extend > EDNS0 to carry DNS signaling information as far as I observed. > > I have got several technical comments for the authors to consider: > > As stated in section 5.2 “If EDE support is signaled in the query > the server MUST NOT return the "Forged Answer" extended error > code...”, is “Forged Answer” the only code that is not allowed? [Med] It is the only one to report that filtering happened but still an answer is being provided. Note that the candidate list of codes is called out in: For the DNS filtering mechanisms described in Section 3 the DNS server can return extended error codes Blocked, Filtered, or Forged Answer defined in Section 4 of [RFC8914]. However, these codes only explain that filtering occurred but lack detail for the user to diagnose erroneous filterings. > suggest authors articulate the rule not just an instance, in order > to facilitate the consistency among different implementations. > > As in section 5.3, “On receipt of a DNS response with an EDE > option from a DNS responder, the following actions are performed > on the EXTRA-TEXT field”, are all those “actions” ordered or > unordered? I think it needs to be specified. > [Med] The actions are not provided in the execution order: clarified in https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/32/files. > In section 6, RPZ is not standardized by IETF. I suggest removing > “Interoperation with RPZ Servers” or moving it to appendix since > this draft is intended to be a standards track RFC. > [Med] This is fair. Please see the PR at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/31/files. > And I also have some editorial comments: > [Med] All good points. Please see the PR at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/30/files. > In section 4, “The contact details of the IT/InfoSec team to > report mis-classified DNS filtering. This field is structured as > an array of contact URIs (e.g., tel, sips, https). At least one > contact URI MUST be included. This field is mandatory.” It is > necessary to reference RFCs to “tel, sips, https”. > > In section 5.3, there is an in-paragraph long space breaking “If a > DNS client has enabled opportunistic privacy profile (Section 5 of > [RFC8310]) for DoT, the DNS client will either fall back to an...” > ...and “encrypted connection without authenticating the DNS > server...”. > > In section 5.3, the first action is described as “Verify the field > contains valid JSON.” which is the only segment using a verb to > describe the very action. I think it would be better to align all > the action description wording. > > ____________________________________________________________________________________________________________ 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
