Robert Wilton has entered the following ballot position for draft-ietf-dnsop-dns-error-reporting-07: No Objection
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: ---------------------------------------------------------------------- Hi, Thanks for this document. DNS really isn't my area of expertise, and it may be that if I was very familiar with DNS and DNS deployment then the approach taken here for error reporting would seems like the obvious and pragmatic choice. Specifically, I do appreciate that this is a lightweight solution, and the solution may well be good enough to achieve its goals of better error reporting without too much effort and without causing too much confusion. But, without the domain knowledge, I'm not particularly enamored on the approach of overloading the error reporting onto the basic DNS query mechanism rather than a separate message type or channel. It feels a bit like if the only thing that you have is a hammer, then everything looks like a nail ... and ultimately I'm concerned that the error reports that looks like a query, but are not really a query, may end up being confusing in logs, debugging, etc., for non-expert users. Hopefully, this doesn't happen when it gets deployed, and if it does then I guess that the plan B option of deprecating this approach and specifying a more heavyweight out of band mechanism always exists. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
