I believe this draft has ambiguities that will present issues for implementing clients that require further discussion and clarification before proceeding.

**Issue 1**
RFC8914 is clear (section 2) regarding EXTRA-TEXT that “This information is intended for human consumption (not automated parsing).“. 

Section 4 of this draft implicitly updates that requirement by stating that I-JSON can be sent in the field, but focuses on the technical aspects of the JSON structure, not on the implications of reversing that statement.

Changing a field stated as for human consumption to a field intended to be machine-readable is a major change and the implications of this change should be discussed in the draft, including an explicit statement updating the intent of the EXTRA-TEXT field. 

In particular I would expect to see discussion and consideration of how backwards compatibility with RFC8914 compliant, but structured-dns-error ignorant clients would be achieved. One obvious scenario that presents difficulties is a client expecting EXTRA-TEXT to contain human readable contents which it displays to an end-user, which would now (upon encountering a resolver implementing this draft) instead display JSON blobs intended for machine consumption to the user. This seems undesirable to me, but the draft is silent on whether this is an accepted consequence of the updates, simply overlooked or can be avoided in some way. 

At the very least, this situation should be discussed and acknowledged as OK in the draft, or ideally consideration of how to handle it - e.g. was a separate EDNS option code for structured-error considered? 


**Issue 2**
The above ambiguity also appears to lead into conflicting instructions for clients in section 5.3 - specifically the first and third bullet points are conflicting - clients SHOULD handle either plaintext or JSON in EXTRA-TEXT (point 3), but MUST discard invalid JSON (point 1). 

How is a client meant to determine if the EXTRA-TEXT field contains invalid JSON or simply plain text? Is it envisaged that the client performs some sort of content detection to determine whether the field is plain-text or JSON before trying to parse it as JSON - if so how? Or if the field cannot be parsed as JSON then why can’t the client simply treat it as plain text?

Again this seems to call for a discussion of why the existing EDNS option code is being reused. Attempting to deal with either human or machine readable data in a single field is generally a fraught and dangerous choice in protocol design, and the presence of these two conflicting requirements is a clear example of why. 

The use of a separate EDNS option code for human-readable vs machine-readable extended error information would provide a clean solution, but is not discussed.


**Issue 3**
Section 6 appears to alter DNS processing behaviour for RPZ servers (to avoid the use of NXDOMAIN, RA=0 in favour of the logic in section 5.2), there are 3 points here:

1) (issue) “can” is not a BCP 14 term, making it unclear the strength of this instruction for compatible servers - I recommend using an explicit MAY, SHOULD or MUST term here instead of the ambiguous can.
2) (issue) regardless of the term used, the implication that the presence of an EDE option can indeed alter DNS processing behaviour on the server is in conflict with the MUST NOT directive in section 6 of RFC8194, which section 10 of this draft says still apply to this document. If this section 6 does indeed intend to override the MUST NOT security considerations of section 6 in RFC8194 and allow a situation where EDE can alter DNS processing behaviour for RPZ servers that should be explicitly stated (both in this section) and also in the later security considerations section. 
3) (nit) the link/reference to #server-response in the text is not working

**Nit 1**
Section 3 contains an incorrect assertion that EDE (RFC8914) is a DNS filtering methods stating that: “DNS responses can be filtered by sending a bogus (also called "forged") A or AAAA response, NXDOMAIN error or empty answer, or an Extended DNS Error code defined in [RFC8914].” - EDE is being presented as a third alternative for filtering. It is not. RFC8914 clearly states that EDE MUST NOT alter DNS processing, so an EDE cannot be used to filter a DNS response - EDE can only add explanatory information about filtering that is occuring due to another method.

This sentence needs re-wording to clarify this, and I would suggest refactoring the entire paragraph into two parts, one which explains the issues with the actual filtering methods, and then a second part which separately covers why the existing EDE responses are insufficient for the use-cases this draft intends to support. Separating this explanation into two parts avoids the confusion the text currently introduces around whether or not RFC8914 is a filtering method or an information method.