Early Review of draft-ietf-dnsop-structured-dns-error-03
review-ietf-dnsop-structured-dns-error-03-dnsdir-early-ma-2023-06-25-01

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