[DNSOP] Re: AD review of draft-ietf-dnsop-structured-dns-error

[tirumal reddy <[e-mail]>]

On Sat, 12 Apr 2025 at 11:04, Eric Vyncke (evyncke) <[e-mail]>
wrote:

> 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.
>

We addressed the pending issues, please see
https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-12.html

Best Regards,
-Tiru


>
>
> 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 <[e-mail]>
> *Date: *Monday, 7 April 2025 at 16:25
> *To: *Eric Vyncke (evyncke) <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> Mohamed Boucadair <[e-mail]>, [e-mail] <
> [e-mail]>
> *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) <[e-mail]>
> 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
>
>
>
>
>
>
>
>
>
>
>
>