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

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

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

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

### Section 4

`IT/InfoSec team` or "DNS operator" or "DNS administrator" as used later in the 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).

Can the JSON object be empty as all JSON names are optional ? Should there be text about this special case ?

Why JSON and not CBOR ?

### Section 5.2

What can the server do when there are several blocking causes (e.g., malware + court order)?

### Section 5.3

What is the client behavior when receiving more than 1 EDE option ?

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

### Section 11.2

Please add a field in table 1 for "Mandatory (Y/N?)".

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