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.
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. 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?" ==== 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. 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) -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
