Hi Ben, The selected suberror codes are identified as threats by the IETF and would potentially compromise the security posture of the endpoint (see Section 10.4 of the draft). The other common reasons you mentioned fall under the category of 'censorship,' which could be perceived as an invasion of end-user privacy, and are therefore not included.
A stricter registration policy will allow new suberror codes to be added in the future with IETF approval, avoiding any undue pressure on Designated Experts. Cheers, -Tiru On Thu, 7 Nov 2024 at 19:40, Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
