On Sat, 12 Apr 2025 at 11:04, Eric Vyncke (evyncke) <evyn...@cisco.com> 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 <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> > 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
