[DNSOP] Further feedback on draft-ietf-dnsop-structured-dns-error-15

[Mark Nottingham <[e-mail]>]

Hi all,

After the discussion on Monday, I had a look through structured-dns-error-15 to see if anything would clash with what we're thinking of in draft-nottingham-public-resolver-errors.

In short, it appears that updates by the authors address many of the issues I found previously; there are only a couple left that would raise concerns for me if the two drafts were kept separate. See below for those, along with some comments and questions I had along the way (that don't affect that decision).

## Issues

- 5.2 prohibits using sub-error codes in 'Censored' responses. That seems excessive; conceivably, they might conceivably be needed down the road.

- Section 5.3 step 2 requires the use of encrypted DNS, otherwise the extra information is thrown away. Conceivably, some clients may have enough information available to trust non-encrypted DNS at some future time. I agree with the notion that the client should evaluate the context of the DNS resolver and make decisions based upon that regarding how to use the information -- and that definitely involves whether the connection is encrypted -- but baking it into the algorithm like this precludes them from any future flexibility, no matter what the use case.

If WG consensus on this is firm and fully informed, so be it, but I thought I heard an indication that there was a subtle shift away from such draconian measures in the discussion on Monday.

- Similarly, 5.3 step 6 puts constraints on the information available to clients who have enabled a DoT opportunistic privacy profile. This likewise seems to take any discretion out of the client's hands and bakes it into the algorithm. 

- Same question for step 7 regarding opportunistic discovery.

- 10.2 puts specific requirements on browsers (as opposed to clients) -- is that intentional? 
 

## Comments

- Section 3 ("DNS Filtering Techniques and Their Limitations") should be moved to an appendix; it has a very different character as compared to the rest of the specification.

- Because this specification requires use of I-JSON, it should be clarified whether non-conforming messages are required to be rejected. See RFC7493 Section 3. I'd suggest this NOT be required (but we still need to be explicit about that).

- Making 'j' mandatory seems excessive; most of these responses will never be seen by "IT staff" and the justification may be self-evident from other fields.

- Requiring contact details for reporting seems... optimistic, and will likely lead to 'do-not-reply' style addresses being used. I'd suggest making this a SHOULD.

- 10.2 "The value consists solely of an organization name and does not contain any additional free-form content such as instructions, URLs, or messaging intended to influence the end-user behavior."  Is this implementable? The context seems to imply it can be done in an automated fashion.

- 11.1 Has a registry column for 'mandatory'. It should be noted that new mandatory extensions can't be introduced in a backwards-compatible way, and so this should always be 'no' for extensions registered after the initial RFC publication.

- 11.2 Probably needs to say that contact URI schemes must be registered URI schemes.

Cheers,

--
Mark Nottingham   https://www.mnot.net/