Hi Michael, On 4/28/25 1:55 PM, Michael Richardson wrote:
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: A. Blocked if the provider has a mandatory malware/phishing filter. B. Filtered if the provider has a voluntary malware/phishing filter. C. Censored for governmental mandates. D. Forged Answer 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.
I changed the numbers to letters above, to avoid confusion when mentioning other numbers. RFC8914 defines EDE codes for all 4 already. In the introduction this I-D aims to cover the needs for both enterprise and ISP use cases, yet in section 5.3 pt. 3 this I-D is not allowed to be used with C aka. EDE code 16 - Censored. The new codes I was asking for was not EDE codes, but rather sub-error codes as defined in section 11.3, where the initial set only contains the sub-codes relevant in an enterprise network. I am mainly bringing it up in regards to this I-D, because the introduction aims to cover both enterprise and ISP usage, I therefore think it would be a bit silly to submit another I-D extending this one, adding support for ISP usage without trying to first raise it here. > My understanding is that the EXTRA-TEXT is there to distiguish B/C/D, for instance. A/B/C/D all have their own dedicated EDE codes, but in the case of D then the EXTRA-TEXT can be used to describe if D was due to A, B or C. I view D more as a transition thing, a currently needed necessary evil (just like IPv4). Human readable EXTRA-TEXT makes sense for the DNSSEC related EDE's, but if we want to get browsers to display helpful error pages for DNS filtering, then it is clear that we need to make it more structured, like this I-D is doing.
What I hear underneath your comments is that you'd like (as an ISP) very much not to get blamed for situation (C), and point the users at the right entity (via "c").
RFC8914 specifically defined EDE code 16 - Censored for this use case, so why not use it? I haven't found any mention of why it has been left out. -- Best regards Asbjørn Sloth Tønnesen Network Engineer Fiberby - AS42541 _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
