<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Jeff,<div class=""><br class=""></div><div class="">A few points:<br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 30, 2023, at 9:27 AM, Jeff Schmidt <<a href="mailto:jschmidt@jasadvisors.com" class="">jschmidt@jasadvisors.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt;" class="">Fair point re: apples and Tonka Trucks.<span class="Apple-converted-space"> </span></span><span style="font-size: 11pt; font-family: "Apple Color Emoji";" class="">😊</span><span style="font-size: 11pt;" class=""><o:p class=""></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt;" class="">I think this is a fine idea, should be tested, and may very well wind-up in the toolbox.</span></div></div></div></blockquote><div><br class=""></div><div>At this point we cannot be passive. It is a fine idea, and it can be tested -- to some extent. But it will only "wind-up in the toolbox" if the NCAP group actively supports it, i.e., it gets consensus.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt;" class=""> It may have some traits incrementally superior to some other techniques, but it isn’t a game changer.</span></div></div></div></blockquote><div><br class=""></div><div>This all depends on what traits, on what basis they were compared, which other techniques they were compared to, and the threshold for "game changer". I'm not suggesting that you're incorrect, but the statements are so vague that really it could be applied in almost any way. That is why we have tried to be very, very specific -- particularly in the latest few meetings.</div><div><br class=""></div><div>And to borrow from something I said in my previous email: this is a minimally disruptive mechanism that guarantees full qnames and mitigates the effects of caching (not to mention aggressive negative caching, local root, and qname minimization), so we have not only better insights into qname patterns but also query volume -- i.e., from clients behind the resolvers. We've only ever had a sample of qnames before (even before qname minimization), and we've always been constrained by the effects of caching (even before aggressive negative caching, local root, and qname minimization). And all this without disrupting potential clients. So again, it all depends on your definition of "game changer". But this is definitely an improvement and also aligns with some of the objectives of NCAP.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt;" class=""> was responding somewhat energetically to the consensus call which implies larger scope than “this is a good idea.”<o:p class=""></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt;" class="">What I see is a “pool” of techniques that are in the TRT’s toolbox, all with various risk profiles, objectives, data collection value, and alerting value/characteristics. We as a group argue about the specifics (which technique is better at X than the other, alerting is more important than data collection, etc.), but in general we agree that there are a sea of tradeoffs and multiple potential techniques.</span></div></div></div></blockquote><div><br class=""></div><div>The specifics are important for the group to understand the implications on things like alerting coverage, security and privacy, user experience, notification, etc. And yes, we agree that there are tradeoffs. Next we use those tradeoffs to make recommendations. Also, I am of the opinion that we need to be somewhat specific with regard to technical recommendations given to the Board. In other words, it should not be something like: "you can do any of these things".</div><div><br class=""></div><div>Casey</div></div></div></div></body></html>