[At-Large] CCWG Briefings - Presentation

[parminder]

Karl

I think I have not been able to make my proposal clear...   I do think
that incorporation of ICANN (the same ICANN as it is) under
international law is the best final solution, and internationalisation
is not what you and others make it out to be. However, my current
proposal was *not about internationalisation*, it is much simpler. (It
is also *not really about an alternative root* - not like we know of
alternative roots, this will still be *the ICANN root*, just physically
elsewhere.)  And so I will focus on that in this email, and respond to
issues of internationalisation later.

The following is my current proposal, which I would think is rather easy
to carry through.

First of all, whatever some members of this list may think, the issue of
possible wrongful interference of the US state in ICANN policy process
and/or root file is VERY REAL in a lot of people's and countries' mind.
It has often been stressed over the last decade and more (WGIG pointed
to it as one of the top 3 issues), and is also in principle a very
legitimate concern. Now, unless one thinks that there is not an issue at
all here which is at least worth seeking a solution for, there is no
point in proceeding further. But I assume that you and most others do
agree that there is a real issue at hand, but may think that any
solution may be worse than the original problem. If so, let me propose a
simple solution and am happy to hear what is so ill about it.

1. ICANN sets up a redundant parallel authoritative root zone in another
country, exactly like the original one, fully under its control. It
takes the root zone operators into confidence in this regard and all
protocols etc get shared. (Unlike what you say, this is not a parallel
root, this is the same root which, post transition, ICANN is supposed to
fully own. It is just a redundant back up in another country of the
working instance in the US. As a backup database, including one in
another country, does not become a different database.)

2. A board resolution, or preferably a by-law (even a fundamental
by-law  perhaps) makes it clear that if there is any interference/
order/ injunction from any of the branches of the US state - whether
judiciary, legislative or executive, which purports to interfere with
ICANN policy process and/or its maintenance of root zone, ICANN board,
failing to get the order/ injunction vacated (about which follows), will
declare the non US back-up root as the official operating one. This root
remains under the ICANN as ever, and therefore is not an alternative
root. Only the new applicable protocols, already shared, should be
requested to be followed by the root server operators, who I understand
would like to keep the root safe from arbitrary interference by US
jurisdiction and should therefore cooperate.

3. Whenever ICANN receives such an infringing order, it will first
respond by letting the concerned authority know that such resolution/
bylaw exists and therefore the order cannot be followed, and if insisted
upon will simply result the root immediately physically moving out of
the US. This being simply a fact, and the relevant order will have no
effect other than to move ICANN's root - and perhaps following it,
ICANN's main registration - outside the US, which in some ways
presumably hurts US's interests, the concerned Us authority is fully
expected to withdraw any such order. So like all good checks this
proposed one would be effective by its very existence and most probably
never needed to be made operational.

And this solves a key global issue, I understand, without too much ado.
Even the US should not be able to object to it, bec the backup is only
for an eventuality that US claims should never come to pass. And so
everyone is happy.

I would like to hear your and others' comments on this proposal.

parminder



 


On Sunday 28 February 2016 11:34 AM, Karl Auerbach wrote:
>
> On 2/27/16 2:45 AM, parminder wrote:
>> I disagree with Karl that California remains the best jurisdictional
>> bet...
> That's sensible.  I'm often wrong.  ;-)
>
> My point was less to advocate California than to reflect that there
> will be no jurisdiction that will be perfect bliss and beauty.   And
> that jumping from one frying pan to another will not really solve
> problems as much as merely shift them into new forms while, at the
> same time, causing a whole lot of effort, trouble, and risk as the
> jump is made.
>
> I understand the concern about US hegemony.
>
> But take heart, even those of us in the US feel locked out.
>
> I am a person who is pretty close to the topmost point of that
> hegemony - I'm a California techie (been part of what would become the
> internet since about 1968), am a California attorney, have written
> full internet standards, participated in the creation of ICANN and
> have been a member of its board of directors.
>
> So do I have influence?   No.  So I can well understand that others
> who are in less privileged positions than I would feel resentment and
> anger.
>
> However, the road you are asking us to follow is a road that involves
> the creation of what is essentially a new international body.   Where
> is the legitimacy of this body going to come from?  I fear that an
> effort to come to terms over this will result in something as
> egregious as the TPP.
>
> And how are the massive assets of ICANN (contracts, money, etc) going
> to be moved without the willing consent of a lot of third parties.
>
> Moreover, your road seems to involve what has been called a competing
> or alternative DNS root.  I'm not afraid of competing roots - in fact
> I think they are a good idea.  But many people are extremely (and not
> unreasonably) fearful of what could happen if the older roots - which
> will continue to be used (there is a lot of inertia) - and the new one
> begin to develop inconsistencies.
>
> Moreover, the root server operators are an mostly independent
> operators - they have not obligation to accept what ICANN, or anyone
> else, publishes as a root zone file.  Nor are they under any
> obligation to not alter that root zone file.  They have not done so,
> but that is the result of their desire to act with extreme caution
> rather than legal compulsion.  We owe a lot to the root server
> operators.  They deployed anycast servers on their on initiative
> without the consent, and even despite the consent, of ICANN.  Do we
> really want to work against a group who has perhaps done more to
> assure the stability of DNS than anyone?
>
> The point of my notes is that we should fix ICANN and do so in a way
> that follows well known, and widely accepted, methods.   ICANN was
> intentionally designed to be distant and unaccountable - deals were
> struck (and remain secret to this day) when the law firm that created
> ICANN was pushing "newco" through the US Dep't of Commerce.
>
> There is a lot of room to fix the existing ICANN.  We can reshape it
> to have a real membership structure, with real voters rather than
> artificial ones being proposed.  And we can change ICANN's organic
> documents - its Articles and Bylaws - to require that certain issues
> receive supermajority votes on the board, to remove the President from
> his ex-officio seat on the board (the damage that that has caused over
> the years is significant), etc.  As I mentioned previously, take a
> look at what we (Boston Working Group) proposed back in 1998 -
> http://cavebear.com/bwg/submission-letter.html
>
> The new proposals have a lot of good ideas.  I jump up and applaud
> changes to the Articles/Bylaws that better channel the decision making
> of the board of directors and require special procedures for certain
> matters.  I agree with the general notion of allowing members to have
> certain powers and rights - I just find that what is being proposed is
> redundant to, and inferior to, what is already available under
> California law.
>
>                 --karl--
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/at-large/attachments/20160305/c50da01c/attachment-0001.html>