Re: [DNSOP] [dnsdir] Dnsdir early review of draft-ietf-dnsop-structured-dns-error-03

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 <dnsdir@ietf.org> 写道：
> 
> Hi Di, 
> 
> Thanks for the review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Di Ma via Datatracker <noreply@ietf.org>
>> 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