Tiru and other authors, Thanks for your reply and for the revised I-D. As noted below, some points of the AD review were either not addressed at all or I still have suggestions.
Nevertheless, I am proceeding with the IETF Last Call, i.e., you may consider my AD review comments as a community review during the IETF Last Call. Regards -éric From: tirumal reddy <kond...@gmail.com> Date: Monday, 7 April 2025 at 16:25 To: Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: dnsop@ietf.org <dnsop@ietf.org>, danw...@gmail.com <danw...@gmail.com>, neil.c...@noware.co.uk <neil.c...@noware.co.uk>, Mohamed Boucadair <mohamed.boucad...@orange.com>, be...@nlnetlabs.nl <be...@nlnetlabs.nl> Subject: Re: AD review of draft-ietf-dnsop-structured-dns-error Hi Eric, Thanks for the review. Please see inline On Fri, 4 Apr 2025 at 17:27, Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>> wrote: Dear authors, dear shepherd, DNSOP WG, As Mohamed ‘Med’ Boucadair is now the responsible AD for DNSOP, he passed me the role of responsible AD for this I-D :-) Therefore, here is my own AD review. Before proceeding with the publication process (IETF Last Call and the IESG evaluation), I request to have all points below addressed, i.e., by changing the text, by replying by email wit explanations, ... (Feel free to reject my comments as long as you explain why). Benno, the shepherd’s write-up needs to be revised: 1. In point 1), there is an unfinished sentence “The status of Proposed Standard will” 2. Change the responsible AD to a guy name “Éric Vyncke” ;-) ### Section 1 I am unsure whether firewalls and IPS do use DNS filtering rather than content inspection. DNS filtering is also done by firewalls and IPS. For instance, by-pass content inspection for domains with low security risk score. Is it worth defining “Users of DNS service”, is it the app or the user using the app ? The text also uses “end user”, is the same human being ? Fixed text, please see https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/59 ` the DNS server`is a little ambiguous here, should it rather be “recursive DNS resolver“ ? It could be either a DNS resolver or DNS forwarder. EVY> suggest to explicitly write so in the I-D ### Section 3 ` In order to return a block page over HTTPS, man in the middle (MITM)` should “without triggering an invalid TLS server authentication” be added ? Please refrain from using “MITM”, favor “on path attack” or simply “interception” in this case. Fixed text, please see https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/59 ` The HTTPS server will have access` unsure which HTTPS server is referred to... is it the expected or the spoofed reply servers ? The HTTP server hosted on the network security device, fixed text. s/Enterprise networks do not assume/Enterprise networks do not always assume/ Should there be text in the DNSSEC bullet that if the filtering DNS server is also the DNSSEC validator, then all is good ? Good point, updated text. Should bullet (4) be merged in bullet (3) ? Yes, merged. ### Section 4 Does this text add any value ` Note that [RFC7493<https://www.rfc-editor.org/rfc/rfc7493>] was based on [RFC7159<https://www.rfc-editor.org/rfc/rfc7159>], but [RFC7159<https://www.rfc-editor.org/rfc/rfc7159>] was replaced by [RFC8259<https://www.rfc-editor.org/rfc/rfc8259>].`? Yes, it helps when going through RFC7493 to refer to RFC8259 instead of RFC7159 (RFC7493 refers to RFC7159) . s/ This field is structured as an array of contact URIs, using/ This field is structured as an array of contact URIs that MUST use/ ? Fixed. Can the “l” name occur in the absence of “j” or “o” names ? "j" is a mandatory field, so "l" cannot occur without it. As I live in a country with 3 (+ English) languages, I sincerely regret that only one language can be used... IMHO, “j” should be an array of <language, text> especially when the end user is residential. The idea is if the language is known, it could be translated by the client to the end-user's native language. (My country has 22 national languages :)) EVY> Oh man... you beat me flat there ;-) EVY> suggest adding some text around it even if I still would prefer an array of languages. Did the WG consider using a single URI pointing to a possibly larger JSON file ? Did the WG consider using CBOR for encoding ? It may be useful to justify in the I-D why JSON was preferred to CBOR. JSON is already used by DNS (see RFC8427) and the spec mandates DoT, DoH or DoQ, fragmentation is not an issue over these transports. EVY> OK, the justification is good ### Section 5.2 S/ A or AAAA record query/ A or AAAA resource record query/ Fixed. EVY> actually not fixed... The 2 seconds for TTL seems very short to me. I would avoid using this value even as an example. Okay, replaced with 10 seconds. ### Section 5.3 As the I-D states `following ordered actions`, please use a numbered list. Thanks, updated. Also, I wonder about the actual order as the channel considerations should probably be first, before the JSON syntax. #1 discusses implementations that both support and do not support this specification. If the input is not valid JSON, subsequent steps will be skipped. In ` If the "c" field contains any URI scheme not registered in the Section 10.3<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-structured-dns-error-10#IANA-Contact> registry, it MUST be discarded` it is unclear what the “it” refers to. Fixed. s/ In such a case, the content of the "c" attribute can be ignored/ In such a case, the content of the "c" attribute MAY be ignored/ Fixed. The last two bullets (DNS forwarder and app) are not really part of this list but should probably appear as stand alone. Yes, added a new section (see https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/62) ### Section 6 Is worth explaining why value = 0 is there and why there are no values for 1 to 4 ? 1 to 4 are reserved for other error codes, please see Section 10.4 ### Section 7 It is unclear whether the original reply is forwarded as it is received, i.e., is the information specified in this document also forwarded ? Yes, the EXTRA-TEXT field is forwarded to the DNS client. Updated text for clarity. ### Section 10.1 I am not an application expert, but is this registration required ? Good catch, it is not required, removed the section. ### References draft-ietf-add-ddr-10 is now RFC 9642 draft-ietf-add-resolver-info-13 is now RFC 9606 (the authors should know ;-) ) Yes, fixed all above :) DNS terminology is no more RFC 8499 but RFC 9499 Fixed. Cheers, -Tiru
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
