Hi Robert, comments below. > On 14 Dec 2023, at 10:02, Robert Wilton via Datatracker <[email protected]> > wrote: > > 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!9Nuqbgr2zSnBE9zLNkEFSzbaIxFp2FbfxYudMPEBDbTROZ-ukKX64_EM33i4xasd-cfYaMIeaTJw17e4Hw9FyA$ > [ietf[.]org] > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/__;!!PtGJab4!9Nuqbgr2zSnBE9zLNkEFSzbaIxFp2FbfxYudMPEBDbTROZ-ukKX64_EM33i4xasd-cfYaMIeaTJw17c-biY_4Q$ > [datatracker[.]ietf[.]org] > > > > ---------------------------------------------------------------------- > 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.
Hi Robert, thanks for your comments. I understand the sentiment. I hope better error reporting will be developed in the future, based on deployment feedback of the current proposal. The issue is that currently, there is no, not even basic, error reporting from the resolver operator to an authoritative server operator. This helps to establish a baseline and we can go from there. Warmly, Roy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
