Hiya,

On 14/04/2025 16:18, The IESG wrote:

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Structured Error Data for
Filtered DNS'
   <draft-ietf-dnsop-structured-dns-error-12.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email protected] mailing lists by 2025-04-28. Exceptionally, comments may
be sent to [email protected] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Apologies for being a few days late.

My top level input is that this should be sent back to the WG with
a recommendation to chat more with some apps folks (not just for the
web, but mail, calendaring etc too) before trying again, if trying
again still seems like a plan.

Details:

- abstract: "filtered DNS responses lack structured information for end
  users to understand" - end users do not know the DNS exists; expecting
  them to understand DNS errors, outside of the context of whatever
  application has made the DNS query, will IMO be unproductive

- I'm generally unkeen on helping censors, and while I recognise that
  doing so is not the intent, it will be (at least) a side-effect, in
  this case without even the cutesey/ironic 451 reference. On balance
  I think (but not strongly) we've done enough to make filtering and
  censorship explicit so don't need this.

- Adding expectations of support for a variant of JSON seems optimistic.
  That said I don't know how well supported that I-JSON variant may be
  but I'd not expect anyone to go out of their way if they have some
  JSON support but not quite that.

- If a censor (in some authoritarian locale) includes a contact and a
  person gets in touch with that, or their user agent decides to do
  that, there could be negative consequences for the person. (That
  field seems somewhat like "if you're unhappy with our censoring you
  when you tried to get at something you ought not have wanted, please
  feel free to call into secret-police-HQ and we'll happily deal with
  your query" - not an attractive invitation.) And the 'contact' field
  is mandatory. Seems a bad plan to me.

- I agree with other comments to the effect that de-ref'ing the contact
  is asking for e.g. malware trouble.

- 11.3/11.4 seem wrong - "blocked by" is not an error when the blocking
  is deliberate - I think that indicates something is fundamentally
  wrong with this specification.

Cheers,
S.







Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to