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
