Hi, Med, All the clarifications and updates you have made to this draft are fine by me. Di > 2023年6月27日 14:23，mohamed.boucadair--- via dnsdir 写道： > > Hi Di, > > Thanks for the review. > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Di Ma via Datatracker >> Envoyé : lundi 26 juin 2023 07:59 >> À : dnsdir@ietf.org >> Cc : dnsop@ietf.org; draft-ietf-dnsop-structured-dns- >> error.all@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. > -- > dnsdir mailing list > dnsdir@ietf.org > https://www.ietf.org/mailman/listinfo/dnsdir