On Sat, Mar 21, 2026 at 02:16:53AM +0000, Mukund Sivaraman wrote: > This would be the ideal DNS way of transferring this information in my > opinion. Converting this to a draft should be straightforward and I can > prepare this draft for the WG without author assignment.
I took an hour this evening to prepare the sample draft below to show the use of EDNS options to convey the same filtering information and complement RFC 8914 instead of overriding it: https://datatracker.ietf.org/doc/html/draft-muks-dns-filtering-00 The GitHub repository with the draft's XML source is here: https://github.com/muks/draft-muks-dns-filtering I disclaim any copyright or authorship, so if the authors of dnsop-structured-dns-error wish to switch from JSON to the EDNS options (however unlikely that is), they may do so freely. I am not trying to subvert the work here of transferring filtering information, or take away this from the current authors. My main points are technical - I don't like *how* dnsop-structured-dns-error implements its objective. I am supportive of its objective. The linked draft above: * does not copy any "Security considerations" from dnsop-structured-dns-error; that text is written for clients, especially web browsers, and I have no comment about it. * does not include any extra INFO-CODEs for the sub-errors of dnsop-structured-dns-error; these may be introduced as necessary. * does not list the contact URI schemes as what's in dnsop-structured-dns-error is fine This is all I can do to show my displeasure at the design of dnsop-structured-dns-error, by describing how it should have been done. Feel free to use the contents of this draft as you wish. Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
