Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

The draft defines an extension to RFC 8914 by specifying how a client may use an Extended DNS Error (EDE) to request a compliant server adds structured JSON data to the EXTRA-TEXT field of its response to indicate further detail on the rationale for filtering, which in turn could be presented to a user.

I note that before I wrote up this review the AD has already sent the document back to the WG. I would agree with his assessment that further work is needed.  This review is thus written as general suggestions for the authors to consider alongside other Last Call comments when revising the draft in the WG.

General comments:

I believe RFC 8914 has always provided a means for full-text explanations of filtering. This draft proposes a way for a client to use EDE to ask for structured information such that it could be - arguably - parsed and presented more readily to users (as well as other audiences). The question is whether it’s potentially harmful to end users - an attacker could provide an email address (for example) that a less savvy end user might engage with?  I’d like to see this discussed in more detail in the security considerations section, or actually in the main text as it’s pretty important.

On use cases, RPZ is only mentioned in an appendix. It would be nice if RPZ were presented in the main body of the text as an environment that this specification would need to work in, given I’d assume (perhaps wrongly, but I’m a user of an RPZ-enabled service) it’s quite common.

There is only one implementation mentioned, from a presentation in IETF 116.  Are there no other, more recent implementations?  I know this section is removed on publication, but I’d hope to see more, and ideally clearer evidence of interest from browser developers, or relevant application developers generally?

There is a general concern with DNS response sizes and the potential for undesirable fragmentation. The draft mentions response size in passing in section 4 (“the generated JSON should be as short as possible”) without clarifying why, and I think this should be more explicitly included, with guidance, perhaps as part of section 5.2.

In Section 5.3 point 1 the guidance seems a bit hand-wavy - would it not be better if the client was more clearly signalled that the server supports this specification, rather than having to deduce it from parsing the text field?

Tim