Asbjørn Sloth Tønnesen wrote: > In general the enterprise use-case seams to take up most of this I-D, where as > the ISP use-cases doesn't seams to have studies as closely, and therefore seams > less coherent when read from an ISP's point of view.
> In the introduction, in the first paragraph "filtering required by law enforcement" > and "requirement imposed by an external entity" is hinting towards that this I-D > should also be usable with the "EDE code 16 - Censored". > https://datatracker.ietf.org/doc/html/rfc8914#name-extended-dns-error-code-16- ... > In section 1: "can return extended error codes Blocked, Filtered, or Forged Answer" > and in other places: Why is "Censored" not included? The censored error code is > highly relevant for adoption of this I-D for ISPs. > In controlled enterprise deployments, I assume that Blocked, Filtered and Forged is relevant. > For residential ISP's Blocked, Filtered, Censored and Forged can be > relevant. Numbering your comments: 1. Blocked if the provider has a mandatory malware/phishing filter. 2. Filtered if the provider has a voluntary malware/phishing filter. 3. Censored for governmental mandates. 4. Forged forged for any of the above, when accompanied by a HTTP-only block page. My reading is that this document is not adding new error codes, which RFC8914 did, but rather it is just adding the explanatory text. And I think you are asking for new codes. My understanding is that the EXTRA-TEXT is there to distiguish 2/3/4, for instance. What I hear underneath your comments is that you'd like (as an ISP) very much not to get blamed for situation (3), and point the users at the right entity (via "c"). -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org