<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Dominique,<div><br><div><div>On Dec 18, 2012, at 8:43 AM, Dominique Lacroix <<a href="mailto:dl@panamo.eu">dl@panamo.eu</a>> wrote:</div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><div class="moz-cite-prefix"><font face="Courier New, Courier,
monospace" size="+1">Le 18/12/12 17:28, David Conrad a écrit :<br>
</font></div>
<blockquote cite="mid:DE7FCDFF-3F87-4D72-AF46-FCF75517937A@virtualized.org" type="cite"><font face="Courier New, Courier, monospace" size="+1">The
most the US government could do would be to direct its
contractors to remove the ccTLD's records from the root zone. </font></blockquote>
<font face="Courier New, Courier, monospace" size="+1"><font size="+1"><font face="Courier New, Courier, monospace">Yes,
that's what I meant, and so the author in the article we're
commenting.<br>
<br>
</font></font>And the operating contractor IS Verisign. Return
to the starting point.</font><font size="+1"><br></font></div></blockquote><div><br></div><div>No. If the USG were to direct its contractors to violate the processes over which it provides oversight, we would not be back at the starting point, we would be in uncharted territory.</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><font size="+1"><font face="Courier New, Courier, monospace">So you confirm that,
even being a bad move provoking a crisis, it could be possible.</font><br></font></div></blockquote><div><br></div><div>I confirm it is possible for the USG to direct its contractors to violate existing processes.</div><div><br></div><div>However, this does NOT "remove DNS access for a country". As mentioned, the root servers must pick up the inappropriately modified zone. In addition, DNS caches must expire out the old information (and you may find that ccTLD name servers tend to be quite long lived in DNS caches). In the intervening time between when the root zone was inappropriately modified and when resolutions for the ccTLD name servers start to fail, it is extremely likely that the situation would either be resolved (pun intended) or an alternative mechanism would be established by which the root zone was accepted by the root servers. Since ultimately it is resolver operators (typically ISPs) that decide which root name servers to use and most of those resolver operators do not reside in a jurisdiction subject to US law, it is wildly unlikely the USG would slit their own throats by trying to violate the processes they provide oversight for. Particularly given there are much easier (and subject to greater "plausible deniability") ways to have the same effect as removing a country from the DNS.</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><font size="+1">
<font face="Courier New, Courier, monospace">That's exactly why
it's an asymetric situation unesasy to be accepted by a lot of
countries in the world.</font><br></font></div></blockquote><div><br></div>My impression is that the uneasiness is primarily driven by a misunderstanding of how root zone updates work and the role performed by the USG in those updates. As mentioned when this issue came up previously, my experience with the USG role when I was at IANA was that it was exclusively focused on ensuring ICANN hasn't run amok and that documented processes are followed. </div><div><br></div><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><font size="+1"><font face="Courier New, Courier, monospace">Could we imagine
another process? not necessarily with a plenary UN assembly ;-)</font><br></font></div></blockquote><br></div><div>Sure, I'm not a particular fan of the current process and there are always ways in which you can add more Byzantine complexity in order to address political concerns, however without an organization that is above national laws, you will _always_ be at the mercy of the nation that is hosting the organization that is making the root zone edits and signing the root zone. </div></div><div><br></div><div>Regards,</div><div>-drc</div><div><br></div></body></html>