I requested a stricter registration policy because of the "suberror" registry, which includes codes indicating blocking due to "Malware", "Phishing", "Spam", and "Spyware". These are far from the only reasons that DNS servers refuse to answer queries. Other common reasons include "Pornography", "Gambling", "Advertising", "Copyright Violation", "Blasphemy", "Sanctions", "Extremism", "Incitement", ...
My preference would be to remove the "suberror" field and registry entirely. Failing that, I do not want to ask a Designated Expert whether to register suberror codes for every perceived evil in the world. Each registry entry implicitly normalizes this filtering rationale as a behavior deemed acceptable by the IETF. --Ben Schwartz ________________________________ From: Tommy Pauly <tpauly=40apple....@dmarc.ietf.org> Sent: Tuesday, November 5, 2024 10:46 AM To: DNSOP Working Group <dnsop@ietf.org> Cc: DNSOP Chairs <dnsop-cha...@ietf.org>; Benno Overeinder <be...@nlnetlabs.nl> Subject: [DNSOP] Re: Working Group Last Call draft-ietf-dnsop-structured-dns-error Overall, I think this document, and its definition of the EXTRA-TEXT field as JSON is important. To that end, I am eager to see progress in this area. However, I think we should not quite yet ship this out of the WG. Two specific points: - I’d Overall, I think this document, and its definition of the EXTRA-TEXT field as JSON is important. To that end, I am eager to see progress in this area. However, I think we should not quite yet ship this out of the WG. Two specific points: - I’d like to have a working group discussion with regards to the proposal in draft-nottingham-public-resolver-errors-00. While that doesn’t necessarily require being merged into draft-ietf-dnsop-structured-dns-error, it could be, and I would like to ensure with the WG that if they are separate, that there are no changes needed in draft-ietf-dnsop-structured-dns-error in order to support the details Mark’s draft is proposing. I think this incident/operator ID approach is potentially a very compelling tool to drive adoption of these errors across browser clients. - I am concerned about the IANA registry policy for the JSON names being IETF Review. (My concerns are slightly less for the other registries.) Requiring not only an RFC, but an IETF-stream RFC, seems like too high a bar. I would suggest Expert Review. Best, Tommy On Oct 26, 2024, at 9:10 PM, Benno Overeinder <be...@nlnetlabs.nl> wrote: Dear all, The draft-ietf-dnsop-structured-dns-error has seen several revisions and there has been considerable discussion on the mailing list and in the WG. At IETF 116, Gianpaolo Scalone (Vodafone) and Ralf Weber (Akamai) presented a proof of concept of this specification. The authors and the WG chairs believe the draft is ready for a Working Group Last Call. This initiates the Working Group Last Call (WGLC) for draft-ietf-dnsop-structured-dns-error, "Structured Error Data for Filtered DNS." The draft can be reviewed here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/__;!!Bt8RZUm9aw!5yHYzIH7UZT84CIbOttYH5wYSmd08DCgh-GztpIx3za7t4sfIZDMmxvYpzV9EKqJGumO7iwPYVpcDYNIk4Hw-blr-1A$> Intended Status: Proposed Standard Document Shepherd: Benno Please take the time to review this draft and share any relevant comments. For the WGLC to be effective, we need both positive support and constructive feedback; a simple lack of objection isn’t enough. If you believe this draft is ready for publication as an RFC, please state your support. Conversely, if you feel the document isn’t ready for publication, please provide your concerns and reasoning. This starts a two-week Working Group Last Call process, concluding on November 9, 2024. Thank you, Suzanne Tim Benno _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
