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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Tiru,

Thanks for your reply.

See in-line for EV>

Basically, I still a problem with the support of only one language in a *human readable* reply. I will think more over the weekend, but I am afraid that a change in the I-D s/human-readable/machine-readable/ or the support for multiple languages is required. And, I know that your own country have more than 3 languages (and possibly different character sets).

Regards

-éric


From: tirumal reddy <[e-mail]>
Date: Thursday, 7 May 2026 at 07:33
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: [e-mail] WG <[e-mail]>; Dan Wing <[e-mail]>; [e-mail] <[e-mail]>; Mohamed Boucadair <[e-mail]>; Benno Overeinder <[e-mail]>
Subject: Re: AD review of draft-ietf-dnsop-structured-dns-error-19

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]<mailto:[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.

EV> sure that in help network security, but it is more often used for policy enforcement. Suggest to add this to the abstract.


### 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.

EV> thanks


### 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.

EV> please add these terms in the terminology section


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.

EV> I am insisting.


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.

EV> ack


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.

EV> Humm true of course. Is it worth mentioning ?


### 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.

EV> So a single SDE ? Please add text then.


### 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."

EV> ack

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.

EV> not convinced but OK

### 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.

EV> the IANA initial registry MUST match the format of the registration data


## 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 ?

EV> different format (at least over HTML)

Cheers,
-Tiru