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

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

Dear authors, dear shepherd, DNSOP WG,

As Mohamed ‘Med’ Boucadair is now the responsible AD for DNSOP, he passed me the role of responsible AD for this I-D :-) Therefore, here is my own AD review. Before proceeding with the publication process (IETF Last Call and the IESG evaluation), I request to have all points below addressed, i.e., by changing the text, by replying by email wit explanations, ... (Feel free to reject my comments as long as you explain why).

Benno, the shepherd’s write-up needs to be revised:

  1.  In point 1), there is an unfinished sentence “The status of Proposed Standard will”
  2.  Change the responsible AD to a guy name “Éric Vyncke” ;-)

### Section 1

I am unsure whether firewalls and IPS do use DNS filtering rather than content inspection.

Is it worth defining “Users of DNS service”, is it the app or the user using the app ? The text also uses “end user”, is the same human being ?

` the DNS server`is a little ambiguous here, should it rather be “recursive DNS resolver“ ?

### Section 3

` In order to return a block page over HTTPS, man in the middle (MITM)` should “without triggering an invalid TLS server authentication” be added ? Please refrain from using “MITM”, favor “on path attack” or simply “interception” in this case.

` The HTTPS server will have access` unsure which HTTPS server is referred to... is it the expected or the spoofed reply servers ?

s/Enterprise networks do not assume/Enterprise networks do not always assume/

Should there be text in the DNSSEC bullet that if the filtering DNS server is also the DNSSEC validator, then all is good ?

Should bullet (4) be merged in bullet (3) ?

### Section 4

Does this text add any value ` Note that [RFC7493<https://www.rfc-editor.org/rfc/rfc7493>] was based on [RFC7159<https://www.rfc-editor.org/rfc/rfc7159>] but [RFC7159<https://www.rfc-editor.org/rfc/rfc7159>] was replaced by [RFC8259<https://www.rfc-editor.org/rfc/rfc8259>].`?

s/ This field is structured as an array of contact URIs, using/ This field is structured as an array of contact URIs that MUST use/ ?

Can the “l” name occur in the absence of “j” or “o” names ?
As I live in a country with 3 (+ English) languages, I sincerely regret that only one language can be used... IMHO, “j” should be an array of <language, text> especially when the end user is residential.

Did the WG consider using a single URI pointing to a possibly larger JSON file ?

Did the WG consider using CBOR for encoding ? It may be useful to justify in the I-D why JSON was preferred to CBOR.

### Section 5.2

S/ A or AAAA record query/ A or AAAA resource record query/

The 2 seconds for TTL seems very short to me. I would avoid using this value even as an example.

### Section 5.3

As the I-D states `following ordered actions`, please use a numbered list.

Also, I wonder about the actual order as the channel considerations should probably be first, before the JSON syntax.

In ` If the "c" field contains any URI scheme not registered in the Section 10.3<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-structured-dns-error-10#IANA-Contact> registry, it MUST be discarded` it is unclear what the “it” refers to.

s/ In such a case, the content of the "c" attribute can be ignored/ In such a case, the content of the "c" attribute MAY be ignored/

The last two bullets (DNS forwarder and app) are not really part of this list but should probably appear as stand alone.

### Section 6

Is worth explaining why value = 0 is there and why there are no values for 1 to 4 ?

### Section 7

It is unclear whether the original reply is forwarded as it is received, i.e., is the information specified in this document also forwarded ?

### Section 10.1

I am not an application expert, but is this registration required ?

### References

draft-ietf-add-ddr-10 is now RFC 9642

draft-ietf-add-resolver-info-13 is now RFC 9606 (the authors should know ;-) )

DNS terminology is no more RFC 8499 but RFC 9499