<div dir="ltr"><div class="gmail_extra"><div><p style="margin:0.1pt 0in">Here are a few comments in line with JK</p><p style="margin:0.1pt 0in"><br></p><p style="margin:0.1pt 0in">So what you are saying is that the UN could tell the US to stop<br>
serving the records for a ccTLD and the US could then tell VRSN (by<br>court order?) to delete that ccTLD?</p><p style="margin:0.1pt 0in"><br></p><p style="margin:0.1pt 0in">JK: Sanctions cannot be adopted without the US support. Any action under UN Chapter VII, including sanctions,  must be agreed by the all 5 permanent members of the Security Council (<a href="http://www.un.org/en/documents/charter/chapter7.shtml">http://www.un.org/en/documents/charter/chapter7.shtml</a>).  </p>
<p style="margin:0.1pt 0in"><br><br>If that is the case, and VRSN complied (which I think they would fight<br>BTW) then it would be a UN "power" and the US would just be an agent<br>of the UN?<br><i><font face="georgia, serif"></font></i><span style="font-size:9pt;font-family:Arial;color:black" lang="EN-US"></span>


</p><p style="margin:0.1pt 0in"><br></p><p style="margin:0.1pt 0in">JK: If the USA, like any other state, adopts certain UN convention or policy, it has obligation to implement it.  If the USA supports decision on sanctions against certain country, it should implement the sanction regime. </p>
<p style="margin:0.1pt 0in"> <br></p></div>
<br><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 3:23 PM, McTim <span dir="ltr"><<a href="mailto:dogwallah@gmail.com" target="_blank">dogwallah@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
HI Jovan,<br>
<br>
On Mon, Dec 9, 2013 at 1:07 PM, Jovan Kurbalija <<a href="mailto:jovank@diplomacy.edu">jovank@diplomacy.edu</a>> wrote:<br>
> Thank you David, for clarifying this point. Tim, additional clarification is<br>
> in footnote [1]: ...... the UN Charter in the article 41 specifies that<br>
> sanctions may include ‘complete or partial interruption of economic<br>
> relations and of rail, sea, air, postal, telegraphic, radio, and other means<br>
> of communication, and the severance of diplomatic relations’. The<br>
> possibility of ‘deleting a country from the Internet’ or cutting the<br>
> Internet links was not used in any of the main international conflicts or<br>
> sanctions regimes, from the Balkans in 1990s till the recent one in Syria.<br>
<br>
<br>
I think you missed my point.  I was wondering HOW the US could delete<br>
a ccTLD? Only the zone admin can technically edit a zone file (unless<br>
you are talking about hacking into VRSN).  I guess what I was saying<br>
is that you seem to think they have this power to edit currently.<br>
That is not my understanding, and David's clarification backs that up.<br>
<br>
><br>
><br>
><br>
> Although the UN Charter provides a legal basis, the possibility of stopping<br>
> services of 'resolving' top level domain of countries under the sanctions<br>
> has  never been used.<br>
<br>
<br>
So what you are saying is that the UN could tell the US to stop<br>
serving the records for a ccTLD and the US could then tell VRSN (by<br>
court order?) to delete that ccTLD?<br>
<br>
If that is the case, and VRSN complied (which I think they would fight<br>
BTW) then it would be a UN "power" and the US would just be an agent<br>
of the UN?<br>
<br>
<br>
><br>
> Tim, on this question...<br>
><br>
><br>
> Did you mean that they would be the rootzone admin and the database manager?<br>
> They already host a rootserver (L) and are (via IANA function) the DB<br>
> manager.<br>
><br>
><br>
><br>
><br>
> JOVAN: David clarified that ICANN does not host the root server.<br>
<br>
<br>
I think he clarified that IANA is the DB admin (which was always clear<br>
to me).  ICANN runs the IANA function now.  I had lumped them together<br>
in my "they".<br>
<br>
<a href="http://www.iana.org/domains/root/db" target="_blank">http://www.iana.org/domains/root/db</a><br>
<br>
VRSN runs the distribution server, is this what you mean by "host the<br>
root server"?<br>
<br>
ICANN runs "L" rootserver.<br>
<br>
--<br>
Cheers,<br>
<br>
McTim<br>
"A name indicates what we seek. An address indicates where it is. A<br>
route indicates how we get there."  Jon Postel<br>
<br>
 In the blog<br>
> text, the Verisign option would be covered in "continuing to use the current<br>
> location would require changes in the US national law, in order to ensure<br>
> international inviolability of the root database".  Since a change in the US<br>
> law for this type of immunity/inviolability could be a complex exercise, the<br>
> solution for hosting the server by ICANN could be simpler, especially if a<br>
> broader arrangement is made for  ICANN+  (making ICANN a quasi-international<br>
> organisation). This could be also a solution for immunity for ICANN's role<br>
> as  DB manager.<br>
><br>
> David, I agree that root zone issue is a symbolic one.  The US 'deletion’<br>
> move is almost as improbable as the chance that the Higgs Boson experiment<br>
> in CERN will create anti-matter field which can siphon the Earth through a<br>
> black hole. But, this probability excited some journalist in Geneva (nice<br>
> Dan Brown style story).<br>
><br>
><br>
><br>
> The rootzone question is symbolic and it should be addressed that way.<br>
> Otherwise, we will - at best - continue wasting our time on it or - at worst<br>
> - have it escalating into the major issue in the fast shifting political<br>
> context.<br>
><br>
><br>
> Regards, Jovan<br>
><br>
><br>
><br>
> On 12/9/13 2:53 AM, David Conrad wrote:<br>
><br>
> Hi,<br>
><br>
> On Dec 8, 2013, at 8:26 PM, McTim <<a href="mailto:dogwallah@gmail.com">dogwallah@gmail.com</a>> wrote:<br>
><br>
> "The USA has never used this technical possibility to remove a country<br>
> from the Internet (US DOC authorizes ICANN via an IANA contract, to<br>
> manage the root zone).[1]"<br>
><br>
> Can you explain how the US could do this as a "technical possibilty".<br>
> AFAIK, they only ascertain if the change was done according to IANA<br>
> procedure.  They don't have control over the zone itself.<br>
><br>
> I gather the theory is that some part of the US Government would issue some<br>
> sort of legally binding directive outside of the normal IANA root zone<br>
> management function. Realistically, I'd imagine that directive would be<br>
> applied to Verisign, not ICANN since Verisign is the only organization that<br>
> has the technical capability to change the root zone unilaterally. Of<br>
> course, it remains unclear whether the root server operators would accept<br>
> such a change, but I gather we're talking symbology and theory here.<br>
><br>
> When you wrote "Such an ICANN+ would both host the root server, and<br>
> manage the root database."<br>
><br>
> I'm not sure what "host the root server" means here.<br>
><br>
> Did you mean that they would be the rootzone admin and the database<br>
> manager?  They already host a rootserver (L) and are (via IANA<br>
> function) the DB manager.<br>
><br>
> There might be a bit of confusion here.  To be explicit in the roles:<br>
><br>
> - ICANN, as the IANA function operator, validates (in terms of syntax,<br>
> semantics, and that the request can from an authorized party, i.e., the TLD<br>
> administrator) root zone change requests and submits those validated<br>
> requests for authorization to NTIA.  ICANN is _not_ the database manager.<br>
><br>
> - US Dept. of Commerce, NTIA authorizes those change requests, verifying<br>
> ICANN has performed the IANA root zone management function appropriately.<br>
> Once authorized, the change request is released to Verisign for<br>
> implementation.<br>
><br>
> - Verisign, under a cooperative agreement with NTIA, acts as the root zone<br>
> maintainer.  Verisign accepts the NTIA-authorized root zone change request,<br>
> implements that change request in the root zone by updating the root zone<br>
> database, resigns the root zone with the DNSSEC zone signing key (which has<br>
> been signed by the key signing key maintained by ICANN), and then places the<br>
> changed and newly signed root zone onto a distribution server, notifying<br>
> (via the DNS protocol) that a new zone is available.<br>
><br>
> - The 12 root server operators, either due to the notification sent by<br>
> Verisign or because of timers built into the root zone, automatically pull<br>
> the new root zone from the distribution server and place it on their servers<br>
> (which, in most cases, actually a constellation of instances all over the<br>
> planet).  For example, ICANN, as one of the 12 root server operators, pulls<br>
> the root zone from the distribution master server and then pushes it out to<br>
> the 146 sites (300+ machines last I heard) that respond to DNS queries sent<br>
> to the "L" root server address.<br>
><br>
> I hope this clarifies.<br>
><br>
> Regards,<br>
> -drc<br>
><br>
><br>
> --<br>
><br>
><br>
><br>
> Jovan Kurbalija, PhD<br>
><br>
> Director, DiploFoundation<br>
><br>
> Rue de Lausanne 56 | 1202 Geneva | Switzerland<br>
><br>
> Tel. <a href="tel:%2B41%20%280%29%2022%207410435" value="+41227410435">+41 (0) 22 7410435</a> | Mobile. <a href="tel:%2B41%20%280%29%20797884226" value="+41797884226">+41 (0) 797884226</a><br>
><br>
> Email: <a href="mailto:jovank@diplomacy.edu">jovank@diplomacy.edu</a>  | Twitter: @jovankurbalija<br>
><br>
><br>
><br>
><br>
><br>
> The latest from Diplo: today – this week – this month l Conference on<br>
> Innovation in Diplomacy (Malta, 19-20 November 2012) l new online courses<br>
</blockquote></div><br></div></div>