Hi Eric, Thanks for the detailed review. I raised PR https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/88 to address most of your comments. Please see the inline responses for comments where the draft is not updated.
On Tue, 5 May 2026 at 19:38, Eric Vyncke (evyncke) <[email protected]> wrote: > [As Med is a co-author, he cannot be the responsible AD for this document, > hence, I have been selected as the responsible AD] > > # Éric Vyncke, INT AD, AD review for > draft-ietf-dnsop-structured-dns-error-19 > CC @evyncke > > Thank you for the work put into this document. It is very easy to read. > > Please find below my AD review. > > As the responsible AD, I expect all the points below to be addressed, > either by a revised I-D, or an email reply. Of course, authors and WG can > reject my points, but this needs to be justified. Once all the points are > addressed, I will proceed with the publication process, i.e., IETF Last > Call. > > Special thanks to Benno Overeinder for the shepherd's detailed write-up > including the WG consensus, the history behind the 2nd "publication > request", and the justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > Note: this AD reviews follows the Markdown syntax of > https://github.com/mnot/ietf-comments/tree/main, i.e., they can be > processed by a tool to create github issues. > > ## Critical issues > > ### Shepherd's write-up > > Q18 got it wrong as sections 11.2 et al. request the creation of a new > registry. > > ### Abstract > > I am not sure whether `including *network* security` is correct as it does > not really protect the network per se but more the IT system or the end > users. Suggest either rephrase it or remove it. > "network security" is appropriate: an endpoint infected with malware can scan the attached network for vulnerabilities and perform lateral movement. DNS filtering that blocks communication with C2 server serves a network security purpose. > > ### Section 1 > > Why not adding a reference to RFC 7754 section 6 `promptly informing the > endpoint that blocking has occurred provide necessary transparency to > redress any errors, particularly as they relate to any collateral damage > introduced by errant filter`? > > ### Section 3 > > In bullet 1, `The HTTPS server hosted on the network security device will > have access to the client's IP address and the hostname being requested. `, > isn't this the same issue with DNS server in all 3 scenarios ? The > difference there is for the *path* component and not the *host* part of the > URL. > Yes, the block-page server additionally learns the URL path component, revealing more about the specific resource the end user attempted to access. Updated text accordingly. > > ### Section 4 > > `IT/InfoSec team` or "DNS operator" or "DNS administrator" as used later > in the section? > The "c" field contains the contact details of the IT/InfoSec team that the end-user needs to reach to report misclassified filtering. "DNS administrator" elsewhere in the section refers to the party operating the DNS server. These are distinct roles. > > As a resident of a country, Belgium, with THREE national languages (not to > mention the common use of English), I find *VERY* limiting the use of a > single language... Why not an array of languages ? or a 'accept language' > in the DNS query SDE option? Relying on `optionally translate it` is > wishful thinking (especially for small messages). > Adding a preferred language field to the SDE option in the query is appealing, similar to the HTTP Accept-Language header where the client sends a list of preferred languages and the server picks the best match. However, it would require a non-trivial wire format change to the SDE option, which currently has no OPTION-DATA, as well as updates to the client request and server-side processing. Furthermore, the "l" field already allows clients to identify the language and invoke machine translation. If you insist on this change, I am open to discuss with my co-authors to update the draft. > > Can the JSON object be empty as all JSON names are optional ? Should there > be text about this special case ? > This case is already handled in Step 5 of {{client-processing}}, which requires the client to discard the JSON object if none of the "c", "j", or "s" fields are present or all have empty values. > > Why JSON and not CBOR ? > JSON was chosen over CBOR as the structured message is sent over an encrypted DNS transport (e..g, DoT, DoH, DoQ) which handles fragmentation. > > ### Section 5.2 > > What can the server do when there are several blocking causes (e.g., > malware + court order)? > When multiple blocking causes apply, the "j" field can be used to provide additional context about all applicable causes. > > ### Section 5.3 > > What is the client behavior when receiving more than 1 EDE option ? > {{!RFC8914}} already addresses this: "Senders MAY include more than one EDE option and receivers MUST be able to accept (but not necessarily process or act on) multiple EDE options in a DNS message." > > Should bullet 2 and 3 be swapped ? > > ### Section 10 > > Should there be a 'privacy considerations' sub-section ? > > ### Section 11 > > "IETF review" seems like a pretty high bar to me, why not "specification > required" ? > The "IETF Review" policy was deliberately chosen to prevent registration of sub-error codes that could conflict with IETF policy. A lower bar like "Specification Required" would not provide sufficient oversight to prevent such registrations. > > ### Section 11.2 > > Please add a field in table 1 for "Mandatory (Y/N?)". > All current fields are optional and the draft already requires that future extensions must not introduce mandatory fields for backward compatibility. > > ## Non-critical / cosmetic issues > > Note: these points must also be addressed. > > ### Section 3 > > s/succesfully/successfully/ > s/a end user/an end user/ (more than once) > > For readability, I wonder whether `This document defines a structured, > machine-readable....` part should appear either as a new paragraph in > bullet 3 or even outside of the bulleted list (of course adding a reference > to bullet #3). > > ### Section 8 > > Consider using a 'dig' request to show the SDE & EDE encoding. BTW, the > length of the example is about 100 octets... hence a justification for not > using CBOR is mostly required. > > ### Section 11 > > The formats and apparences of the sub-sections are all different (use of > bullet, bold, ...), please fix. > Could you please elaborate on the formatting inconsistencies you observed in Section 11 ? Cheers, -Tiru
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
