[DNSOP] Dnsdir early review of draft-ietf-dnsop-structured-dns-error-03

[Di Ma via Datatracker <[e-mail]>]

Reviewer: Di Ma
Review result: Ready with Nits

Generally speaking, I think the extension to DNS proposed by this document will
not affect DNS operations adversely since it is common and mature to extend
EDNS0 to carry DNS signaling information as far as I observed.

I have got several technical comments for the authors to consider:

As stated in section 5.2 “If EDE support is signaled in the query the
server MUST NOT return the "Forged Answer" extended error code...”, is “Forged
Answer” the only code that is not allowed? I suggest authors articulate the
rule not just an instance, in order to facilitate the consistency among
different implementations.

As in section 5.3, “On receipt of a DNS response with an EDE option from a DNS
responder, the following actions are performed on the EXTRA-TEXT field”, are
all those “actions” ordered or unordered? I think it needs to be specified.

In section 6, RPZ is not standardized by IETF. I suggest removing
“Interoperation with RPZ Servers” or moving it to appendix since this draft is
intended to be a standards track RFC.

And I also have some editorial comments:

In section 4, “The contact details of the IT/InfoSec team to report
mis-classified DNS filtering. This field is structured as an array of contact
URIs (e.g., tel, sips, https). At least one contact URI MUST be included. This
field is mandatory.” It is necessary to reference RFCs to “tel, sips, https”.

In section 5.3, there is an in-paragraph long space breaking “If a DNS client
has enabled opportunistic privacy profile (Section 5 of [RFC8310]) for DoT, the
DNS client will either fall back to an...” ...and “encrypted connection without
authenticating the DNS server...”.

In section 5.3, the first action is described as “Verify the field contains
valid JSON.” which is the only segment using a verb to describe the very
action. I think it would be better to align all the action description wording.