Hi Michael, > On 23 Feb 2026, at 3:57 am, Michael Richardson <[email protected]> wrote: > > > So, as I understand the tussle: > > 1) we want well defined, and relatively stable lists of errors (with stable, > easily translated > explanations) so that they can be well understood, and are not subject to > random web page phising.
Yes. > 2) we want to allow the set of errors to be easily extended by many different > resolvers who have an increasing and many obtuse set of filtering > conditions. Well, resolvers will be the ones doing the pointing, but third parties might set up databases in expectation of resolvers wanting to point at them, and applications wanting to show those to end users. > Did I get that right? > > Thank for changing the title from censorship. > I think that the most common response users will see that will cause them > alarm or to further investigate will be malware alerts. > > I'm unclear if dnsop-*-transparency is intended to be used for any EDE, or > just ones which are Blocked,Censored,Blocked by Upsteam Server? > Filtered seems a weird middle point... "Remind me why you are blocking me? > Uhmm. You asked?" Going by the error codes in 8914, the most appropriate for our target use case is 16 -- "Censored", so maybe the title change was premature. > It feels to me that this calls for a base set of values, on some policy > between FCFS, Spec Required, or doubtfully IETF Action/RFC. Spec required doesn't make much sense, because a specification isn't required. Likewise IETF Action. I suspect we should get to the point that we have a shared understanding of the registry's value (per Ben's comments) before determining a policy. > And to this an extension set of vendor-specific codes, perhaps based upon PEN. > DHCP, Radius, PPP all did essentially this, with acknowleged mixed success > (particularly the DHCP codes that were kinda/sorta/not-really returned... and > some MS-PPP codes that were not replaced with standards, and also not well > enough described at times) I'm afraid you've lost me... could you explain the use case? Cheers, > > > > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
