[DNSOP] Re: AD review of draft-ietf-dnsop-structured-dns-error-19

[tirumal reddy <[e-mail]>]

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) <[e-mail]>
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