<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 12:14 PM, Joe Abley <span dir="ltr">&lt;<a href="mailto:jabley@hopcount.ca" target="_blank">jabley@hopcount.ca</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jeff,<br>
<div><br>
On 2014-01-09, at 11:18, Jeff Schmidt &lt;<a href="mailto:jschmidt@jasadvisors.com" target="_blank">jschmidt@jasadvisors.com</a>&gt; wrote:<br></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div></div>
Are you talking about changing the mechanism by which new TLDs are provisioned, such that a new TLD will initially be implemented with A and MX records in the root zone, to be followed by a more conventional NS set later?<br>


<br>
Or are you rather talking about introducing a new requirement for new gTLD registry operators whereby delegations from the TLD zone are handled that way?<br></blockquote><div><br></div><div>Why not both?  I interpreted the article as suggesting a concept, which the community can consider the best way to implement.<br>

<br></div><div>Frankly, we know that name collisions are going to happen.  The only judgement to be made is to evaluate the consequences of the collisions.  This proposal strikes me as a good practical solution to the problem of scoping trial delegations both to provide notification and thus data about consequences to be considered.<br>

 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Given the number of new gTLDs that have already been delegated, it seems as though implementation of the former has a dependency on some form of time travel. I can&#39;t speak to the feasibility of changing delegation policy for new gTLD registry operators, but I suspect any change in their operational requirements here is at best impractical, and at worst likely to result in a partial mesh of lawsuits.<br>
</blockquote><div><br></div><div>This is probably not the right forum for this discussion but I do wonder why you think this is so?  Name collision issues have been changing the processes and requirements of launching TLDs since the issue rose in prominence.  Why couldn&#39;t any proposed changes take effect at some future date and folks who are already in a process be permitted to finish with the former rules (assuming of course this is what the community decides)?<br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Specifying the use of a wildcard in a TLD zone (as you suggest as a possible mechanism) is bringing back all kinds of bad memories. A nod towards mail (with the MX reference) is better than the assumption that the only thing anybody ever looks up in the DNS is an address, but it&#39;s far from exhaustive. </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What about SRV lookups by Active Directory clients, for example, or TXT lookups by systems receiving mail? What about all the internal uses of DNS we don&#39;t know about?</blockquote>
<div><br></div><div>The SSAC report mentions these issues too.  These questions, in my mind, are one of the fundamental problems with trial delegations in general.  It is simply not possible to account for everything.  Ultimately, you can only do what you can do and you just have to deal with whatever happens that you didn&#39;t plan for when it happens.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You talk about A records; what about IPv6?<br></blockquote><div><br></div><div>I&#39;m less concerned about IPv6.  My sample size could be too small but it seems to me that sites that have deployed IPv6 are better off technically than IPv4 only.  If this problem exists at a site with IPv6 my perception is that they will be better equipped to deal with it.<br>
<br></div><div>I&#39;d be very interested in other opinions or evidence on this point.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
More generally, it&#39;s not clear to me that your proposed approach (wherever and however it is implemented) is going to offer much relief for people who might be afflicted by a collision between an internal-use name and a name in the global DNS namespace. Which particular damage scenarios do you think would be mitigated (or easier to diagnose) if this kind of idea was in place?<br>
</blockquote><div><br></div><div>In my opinion, this is not about relief or mitigation.  Just like trial delegations, this is about getting information to the folks that need it the most, i.e., notification.  This is another fundamental problem with trial delegations (and continued testing for collisions): you can&#39;t prove a negative so you never know when you&#39;re done.<br>
<br></div><div>Don&#39;t get me wrong.  I&#39;m not opposed to trial delegations or continued testing.  What I&#39;m opposed to is the lack of a deterministic process.  Name collisions will happen and are therefore a risk.  We need to focus on managing that risk and a key component of risk management is notification.<br>
<br></div><div>This proposal is an improvement on the trial delegations that have been proposed so far by ICANN and SSAC.  The discussion here on the technical issues to further improve this idea are even better, and I expect the JAS folks will be considering them.<br>
<br></div><div>Jim<br></div></div></div></div>