Hi Stephane, Thanks for the review, please see inline
On Thu, 24 Apr 2025 at 19:25, Stephane Bortzmeyer <bortzmeyer= [email protected]> wrote: > On Mon, Apr 14, 2025 at 08:18:29AM -0700, > The IESG <[email protected]> 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. > The sub-error codes defined in the draft are not relevant for "Censored", other fields could be returned with this EDE, updated draft for clarity. > > 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. > If a "Forged Answer" is returned, sub-error codes such as "malware" cannot be used, as these sub-error codes are associated with extended error codes like "Filtered" and "Blocked" (see https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-14.html#section-11.3) for details. > > 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. > Good point, update text as follows: If the "c" field contains any contact URIs that use a scheme not registered in the {{IANA-Contact}} registry, only those URIs MUST be discarded. Contact URIs using registered schemes can be processed. > > 4) This example: > { > "c": [ > "tel:+358-555-1234567", > "sips:[email protected]" > ], > "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. > Thanks, fixed. > > 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.) > It was a typo, fixed. > > 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? > The intent behind including an appendix on RPZ servers (which are widely deployed today) is not to treat them as special, but to provide practical guidance for implementers who may wish to map RPZ policy actions (such as NXDOMAIN) to structured error data. -Tiru > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
