> On 12 Dec 2023, at 08:17, Éric Vyncke via Datatracker <[email protected]> > wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-dnsop-dns-error-reporting-07: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dns-error-reporting-07 > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points. > > Special thanks to Benno Overeinder for the shepherd's detailed write-up > including the WG consensus *but it lacks* the justification of the intended > status. > > Other thanks to Carlos Pignataro, the Internet directorate reviewer (at my > request), please consider this int-dir review: > https://datatracker.ietf.org/doc/review-ietf-dnsop-dns-error-reporting-07-intdir-telechat-pignataro-2023-12-09/ > (even if only nits were detected) > > Other thanks to James Gannon, the DNS directorate reviewer, please consider > this int-dir review: > https://datatracker.ietf.org/doc/review-ietf-dnsop-dns-error-reporting-07-dnsdir-telechat-gannon-2023-12-10/ > (and I have read the discussions about James' previous review) > > I hope that this review helps to improve the document, > > Regards, > > -éric > > # COMMENTS (non-blocking) > > ## Abstract > > I find it a little sad that this method is only applicable to DNSSEC (as there > could possibly be other errors to be reported for plain DNS). Should this be > mentioned in the abstract ?
The abstract clearly states “fail to resolve or validate due to a misconfiguration or an attack”. It mentions “fail to resolve or validate” twice. > In the same vein, should "resolve or" be removed from `that fail to resolve or > validate` ? Fail to resolve implies that there are other errors than those related to DNSSEC. That was the point. > > ## Section 6.1 & 6.3 > > Suggest to give some hints when the SHOULD in the last paragraph can be > bypassed. I do not foresee when a SHOULD should be bypassed, however I find a MUST too stringent and prescriptive. I can imagine that a monitoring agent is under such a load that it forfeits the option of sending a TC bit response in order to solicit TCP. Or it already has enough information about a failing domain that it doesn’t need another report to be re-send over TCP. Hope this helps, Roy > > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
