[governance] DMP} Statement on Process and Objectives for the Global Multistakeholder Meeting on the Future of Internet Governance
Jovan Kurbalija
jovank at diplomacy.edu
Mon Dec 9 16:20:37 EST 2013
Here are a few comments in line with JK
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?
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 (
http://www.un.org/en/documents/charter/chapter7.shtml).
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?
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.
On Mon, Dec 9, 2013 at 3:23 PM, McTim <dogwallah at gmail.com> wrote:
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20131210/19efb6c0/attachment.htm>
-------------- 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