[governance] DMP} Statement on Process and Objectives for the Global Multistakeholder Meeting on the Future of Internet Governance

McTim dogwallah at gmail.com
Mon Dec 9 07:23:33 EST 2013


HI Jovan,

On Mon, Dec 9, 2013 at 1:07 PM, Jovan Kurbalija <jovank at diplomacy.edu> wrote:
> Thank you David, for clarifying this point. Tim, additional clarification is
> in footnote [1]: ...... the UN Charter in the article 41 specifies that
> sanctions may include ‘complete or partial interruption of economic
> relations and of rail, sea, air, postal, telegraphic, radio, and other means
> of communication, and the severance of diplomatic relations’. The
> possibility of ‘deleting a country from the Internet’ or cutting the
> Internet links was not used in any of the main international conflicts or
> sanctions regimes, from the Balkans in 1990s till the recent one in Syria.


I think you missed my point.  I was wondering HOW the US could delete
a ccTLD? Only the zone admin can technically edit a zone file (unless
you are talking about hacking into VRSN).  I guess what I was saying
is that you seem to think they have this power to edit currently.
That is not my understanding, and David's clarification backs that up.

>
>
>
> Although the UN Charter provides a legal basis, the possibility of stopping
> services of 'resolving' top level domain of countries under the sanctions
> has  never been used.


So what you are saying is that the UN could tell the US to stop
serving the records for a ccTLD and the US could then tell VRSN (by
court order?) to delete that ccTLD?

If that is the case, and VRSN complied (which I think they would fight
BTW) then it would be a UN "power" and the US would just be an agent
of the UN?


>
> Tim, on this question...
>
>
> Did you mean that they would be the rootzone admin and the database manager?
> They already host a rootserver (L) and are (via IANA function) the DB
> manager.
>
>
>
>
> JOVAN: David clarified that ICANN does not host the root server.


I think he clarified that IANA is the DB admin (which was always clear
to me).  ICANN runs the IANA function now.  I had lumped them together
in my "they".

http://www.iana.org/domains/root/db

VRSN runs the distribution server, is this what you mean by "host the
root server"?

ICANN runs "L" rootserver.

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel

 In the blog
> text, the Verisign option would be covered in "continuing to use the current
> location would require changes in the US national law, in order to ensure
> international inviolability of the root database".  Since a change in the US
> law for this type of immunity/inviolability could be a complex exercise, the
> solution for hosting the server by ICANN could be simpler, especially if a
> broader arrangement is made for  ICANN+  (making ICANN a quasi-international
> organisation). This could be also a solution for immunity for ICANN's role
> as  DB manager.
>
> David, I agree that root zone issue is a symbolic one.  The US 'deletion’
> move is almost as improbable as the chance that the Higgs Boson experiment
> in CERN will create anti-matter field which can siphon the Earth through a
> black hole. But, this probability excited some journalist in Geneva (nice
> Dan Brown style story).
>
>
>
> The rootzone question is symbolic and it should be addressed that way.
> Otherwise, we will - at best - continue wasting our time on it or - at worst
> - have it escalating into the major issue in the fast shifting political
> context.
>
>
> Regards, Jovan
>
>
>
> On 12/9/13 2:53 AM, David Conrad wrote:
>
> Hi,
>
> On Dec 8, 2013, at 8:26 PM, McTim <dogwallah at gmail.com> wrote:
>
> "The USA has never used this technical possibility to remove a country
> from the Internet (US DOC authorizes ICANN via an IANA contract, to
> manage the root zone).[1]"
>
> Can you explain how the US could do this as a "technical possibilty".
> AFAIK, they only ascertain if the change was done according to IANA
> procedure.  They don't have control over the zone itself.
>
> I gather the theory is that some part of the US Government would issue some
> sort of legally binding directive outside of the normal IANA root zone
> management function. Realistically, I'd imagine that directive would be
> applied to Verisign, not ICANN since Verisign is the only organization that
> has the technical capability to change the root zone unilaterally. Of
> course, it remains unclear whether the root server operators would accept
> such a change, but I gather we're talking symbology and theory here.
>
> When you wrote "Such an ICANN+ would both host the root server, and
> manage the root database."
>
> I'm not sure what "host the root server" means here.
>
> Did you mean that they would be the rootzone admin and the database
> manager?  They already host a rootserver (L) and are (via IANA
> function) the DB manager.
>
> There might be a bit of confusion here.  To be explicit in the roles:
>
> - ICANN, as the IANA function operator, validates (in terms of syntax,
> semantics, and that the request can from an authorized party, i.e., the TLD
> administrator) root zone change requests and submits those validated
> requests for authorization to NTIA.  ICANN is _not_ the database manager.
>
> - US Dept. of Commerce, NTIA authorizes those change requests, verifying
> ICANN has performed the IANA root zone management function appropriately.
> Once authorized, the change request is released to Verisign for
> implementation.
>
> - Verisign, under a cooperative agreement with NTIA, acts as the root zone
> maintainer.  Verisign accepts the NTIA-authorized root zone change request,
> implements that change request in the root zone by updating the root zone
> database, resigns the root zone with the DNSSEC zone signing key (which has
> been signed by the key signing key maintained by ICANN), and then places the
> changed and newly signed root zone onto a distribution server, notifying
> (via the DNS protocol) that a new zone is available.
>
> - The 12 root server operators, either due to the notification sent by
> Verisign or because of timers built into the root zone, automatically pull
> the new root zone from the distribution server and place it on their servers
> (which, in most cases, actually a constellation of instances all over the
> planet).  For example, ICANN, as one of the 12 root server operators, pulls
> the root zone from the distribution master server and then pushes it out to
> the 146 sites (300+ machines last I heard) that respond to DNS queries sent
> to the "L" root server address.
>
> I hope this clarifies.
>
> Regards,
> -drc
>
>
> --
>
>
>
> Jovan Kurbalija, PhD
>
> Director, DiploFoundation
>
> Rue de Lausanne 56 | 1202 Geneva | Switzerland
>
> Tel. +41 (0) 22 7410435 | Mobile. +41 (0) 797884226
>
> Email: jovank at diplomacy.edu  | Twitter: @jovankurbalija
>
>
>
>
>
> The latest from Diplo: today – this week – this month l Conference on
> Innovation in Diplomacy (Malta, 19-20 November 2012) l new online courses

-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.igcaucus.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.igcaucus.org/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t


More information about the Governance mailing list