<div dir="ltr"><div>Matt,</div><div><br></div><div>Thanks. With respect to</div><div><blockquote type="cite"><div><div class="m_-5978816427905374255m_5441015209539675045gmail-m_-1496977587599224194WordSection1" style="font-family:HelveticaNeue;font-size:14px"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif"><span style="font-size:11pt">The one glaring failure and our great disappointment is that the IETF has refused to take-up our Recommendation #1 to clearly create an RFC 1918-like protected namespace for local use.</span></div></div></div></blockquote><font face="Calibri, sans-serif"><span style="font-size:16px">I think it would be quite appropriate for ICANN to create a 1918-like protected namespace for local use. I don't say this lightly. My first choice, and I assume everyone else's, would be for the IETF to do this. But "the IETF" doesn't exist in the sense of being a fully coherent and integrated organization with specific people in charge and required to deal with such issues. (The IAB is a closer fit in terms of being an organized body that might take this on, but it has limited bandwidth and chooses its own agenda.) Instead, it's a venue for parties interested in a topic to get together and attempt to reach consensus on a specific topic.</span></font></div><div><font face="Calibri, sans-serif"><span style="font-size:16px"><br></span></font></div><div><font face="Calibri, sans-serif"><span style="font-size:16px">Even if the IETF were to designate some portion of the of the top level namespace as exclusively for local use. it would be up to ICANN to refuse to allocate such names into the root. (Or, perhaps, to include them in the root in a way that accomplishes the purposes, but that's a topic for later discussion.) . In contrast, because ICANN has complete control of the root zone and because the problem we're dealing arose precisely because there was no 1918-like designation of a portion of the namespace, I'd argue ICANN has both the authority and responsibility to implement JAS's Recommendation #1. ICANN should, of course, use consensus and it should, of course, maintain communication and coordination with the IETF, but it should proceed.</span></font></div><div><font face="Calibri, sans-serif"><span style="font-size:16px"><br></span></font></div><div><font face="Calibri, sans-serif"><span style="font-size:16px">Steve </span></font></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 3, 2019 at 12:47 PM Matt Larson <<a href="mailto:matt.larson@icann.org" target="_blank">matt.larson@icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
Dear colleagues,
<div><br>
</div>
<div>David Conrad and I thought the email below from Jeff Schmidt (who is known to most of you based on his firm's previous work on name collisions) was worth forwarding to this group, which we are doing with Jeff's permission.</div>
<div><br>
</div>
<div>Matt</div>
<div><br>
<div><br>
<blockquote type="cite">
<div>Begin forwarded message:</div>
<br class="m_-5978816427905374255m_5441015209539675045gmail-m_-1496977587599224194Apple-interchange-newline">
<div style="margin:0px">
<span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b>From:
</b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">Jeff Schmidt <<a href="mailto:jschmidt@jasadvisors.com" target="_blank">jschmidt@jasadvisors.com</a>><br>
</span></div>
<div style="margin:0px">
<span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b>Subject:
</b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif"><b>[Ext] JAS no-bid on NCAP Study 1</b><br>
</span></div>
<div style="margin:0px">
<span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b>Date:
</b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">August 27, 2019 at 11:25:49 AM EDT<br>
</span></div>
<div style="margin:0px">
<span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(0,0,0)"><b>To:
</b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">Roy Arends <<a href="mailto:roy.arends@icann.org" target="_blank">roy.arends@icann.org</a>>, Matt Larson <<a href="mailto:matt.larson@icann.org" target="_blank">matt.larson@icann.org</a>>,
David Conrad <<a href="mailto:david.conrad@icann.org" target="_blank">david.conrad@icann.org</a>><br>
</span></div>
<br>
<div>
<div class="m_-5978816427905374255m_5441015209539675045gmail-m_-1496977587599224194WordSection1" style="font-family:HelveticaNeue;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt">Hello Team ICANN!<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt"><u></u> <u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt">JAS elected not to bid on the NCAP Study 1; thank you for the invitation and please keep us in mind for Study 2 if such a study occurs.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt"><u></u> <u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt">Our primary rationale for not bidding on Study 1 is simply that we don’t believe we have anything useful to add to the discussion given the limited scope of Study 1. We believe that at this point DNS namespace collisions
are well understood (albeit by a relatively small technical community) and that any further work product from JAS would largely be a restatement of our October 2015 Final Report. In the three years since our Final Report, our conclusions have been shown to
be largely correct and the mitigation strategy we proposed (“Controlled Interruption”) has had the desired effects. Many TLDs have been delegated and used in a variety of fashions at this point and – as we suggested – the few problems that surfaced were isolated
and not serious. Our definition of DNS namespace collisions and the causes/etiology as described in Sections 4 and 5 of our report still hold. At the end of the day, we can’t take your money if we don’t believe we have anything useful to add. ;-)<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt"><u></u> <u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt">The one glaring failure and our great disappointment is that the IETF has refused to take-up our Recommendation #1 to clearly create an RFC 1918-like protected namespace for local use. Until this happens, DNS namespace
collisions will continue to occur; however, increased awareness should reduce the risk of widespread serious future problems (with the “corp-like” exception noted below). Given the lack of clarity of RFC 6762 (including errata), this issue will persist until
folks are told unambiguously the *<b>right</b>* way to do this.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt"><u></u> <u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt">We believe the datasets available to research collisions are also fairly well known – the DNS-OARC DITL data, data that may be made available from large recursive operators, and authoritative data acquired by acquiring/hosting
known colliding domains (the 30+ such domains JAS owns, Mike O’Connor’s<span class="m_-5978816427905374255m_5441015209539675045gmail-m_-1496977587599224194Apple-converted-space"> </span><a href="http://corp.com/" style="color:rgb(149,79,114);text-decoration:underline" target="_blank">corp.com</a>, etc). While these datasets have
been available for years, extremely limited research interest (essentially zero) has been shown in collision-related topics. <span class="m_-5978816427905374255m_5441015209539675045gmail-m_-1496977587599224194Apple-converted-space"> </span><u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt"><u></u> <u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt">JAS remains concerned about the security implications of a small number of “special” domains – like .corp – including the ones that have not yet been discovered. The special nature of the string “corp” was not predictable
a-priori and highly esoteric; all future TLD application rounds should contain steps to identify potential corp-like “special” strings requiring exceptional treatment. JAS also remains concerned about the practice of “drop catching” which is essentially the
intentional discovery and monetization of DNS namespace collisions and referenced this practice in our Final report and in Recommendation #14. We would very much appreciate the opportunity to assist with these issues at some future point.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt"><u></u> <u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt">Happy to chat further feel free to reach out of course; just wanted to make sure I closed the loop since you invited a bid from us. Please do let whomever you select to perform Study 1 know that we’re happy to chat with
them and provide whatever historical information/assistance we can.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt"><u></u> <u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif">
<span style="font-size:11pt">Thank you!<br>
Jeff</span></div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
NCAP-Discuss mailing list<br>
<a href="mailto:NCAP-Discuss@icann.org" target="_blank">NCAP-Discuss@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/ncap-discuss" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/ncap-discuss</a><br>
<br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</blockquote></div></div>