<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Apple Color Emoji";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word;-webkit-nbsp-mode: space;line-break:after-white-space">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">I could get behind prescribing this for a fixed period as the first thing the TRT does to collect data about a string. Assuming we address the IANA delegation issue.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Talk in a few.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Jeff<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">NCAP-Discuss <ncap-discuss-bounces@icann.org> on behalf of Casey Deccio <casey@deccio.net><br>
<b>Date: </b>Wednesday, August 30, 2023 at 2:54 PM<br>
<b>To: </b>ncap-discuss@icann.org <ncap-discuss@icann.org><br>
<b>Subject: </b>Re: [NCAP-Discuss] Nearly-empty TLD zone contents (was Re: Outline of possible phases)<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Jeff,<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">A few points:<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On Aug 30, 2023, at 9:27 AM, Jeff Schmidt <<a href="mailto:jschmidt@jasadvisors.com">jschmidt@jasadvisors.com</a>> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Fair point re: apples and Tonka Trucks.<span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Apple Color Emoji"">😊</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I think this is a fine idea, should be tested, and may very well wind-up in the toolbox.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">It may have some traits incrementally superior to some other techniques, but it isn’t a game changer.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> was responding somewhat energetically to the consensus call which implies larger scope than “this is a good idea.”</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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".<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Casey<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>