On Mon, Apr 14, 2025 at 08:18:29AM -0700,
The IESG <iesg-secretary@xxxxxxxx> wrote
a message of 28 lines which said:
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document: - 'Structured Error Data for
> Filtered DNS'
> <draft-ietf-dnsop-structured-dns-error-12.txt> as Proposed Standard
[Review based on the more recent -13.]
The draft seems basically OK to me. However, a few remarks.
1) The EDE code 16 - Censored has been… censored :-) The draft
mentions only EDE 4, 15 and 17, not 16 and I do not see in the
archives why.
2)
> If EDE support is signaled in the query as per Section 5.1, the
> server MUST NOT return the "Forged Answer" extended error code
> because the client can take advantage of EDE's more sophisticated
> error reporting (e.g., "Filtered", "Blocked").
I do not understand the reason for this choice. I find no discussion
in the mailing list.
3)
> 5. If the "c" field contains any URI scheme not registered in the
> Section 11.2 registry, **that field** MUST be discarded.
The "c" field can contain several contact points. Does the text mean
that all should be discarded or only the contact point with the
unregistered scheme?
"c": [
"tel:+358-555-1234567",
"frobnicate:foobar.example"
],
In that example, it seems we should be able to use the "tel"
URI. Otherwise, it will be impossible to deploy new schemes, because
they would break processing by old servers.
4) This example:
{
"c": [
"tel:+358-555-1234567",
"sips:bob@xxxxxxxxxxxxxxxxxxxx"
],
"j": "malware present for 23 days",
"s": 1,
"o": "example.net Filtering Service",
"l": "tzm"
}
"j" seems in english but the language tag indicates Central Atlas
Tamazight.
5) Table 1: Initial JSON Names Registry
Optional fields have a "N" but "l" (language) has "No". Is there a
semantic difference? ("l" is recommended, unlike the others.)
6) Interoperation with RPZ Servers
I do not understand why they need a special appendix. The fact that a
resolver blocks/filters/forges from a RPZ feed or from manual
configuration should be irrelevant, no?
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
