<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On Saturday 05 March 2016 10:04 PM,
Roberto Gaetano wrote:<br>
</div>
<blockquote
cite="mid:DUB404-EAS14377E0BF4533D60FE336CF94BF0@phx.gbl"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>The A-root, that is the master file from where the zone files
are distributed to the other roots, is not "owned" by ICANN, but
operated by Verisign under contract with the US administration,
and that, to the best of my knowledge, is not going to change
after the transition.</div>
</blockquote>
<br>
I agree Roberto, that is still the catch. And a big one! This is
something the US deliberately kept out of the transition process, a
smart move I must say, since US, unlike the so called 'global
multistakeholder community', knows and closely watches and protects
its interest. <br>
<br>
So basically, unlike what is the popular message that goes out, post
transition the US still remains in complete control of the
authoritative root file (it is now just not able to give any
directions any more to ICANN reg. its policy work etc). <br>
<br>
<blockquote
cite="mid:DUB404-EAS14377E0BF4533D60FE336CF94BF0@phx.gbl"
type="cite">
<div id="AppleMailSignature">The process is that the ICANN Board
directs IANA to do the changes (in case, for instance, of a new
TLD to be added), the changes are performed by IANA who sends
them to Verisign.</div>
</blockquote>
<br>
Yes, but a Verisign answerable to the US, and not ICANN. And this
does not change, right! So, in essence, what is being said is that
IANA authorised changes really still go to the US gov which, and
this is important to note, is under no obligation to do as IANA
wants (other than perhaps the downstream pressure of possible
non-replication by other root operators, an issue that I will come
to later).<br>
<br>
<blockquote
cite="mid:DUB404-EAS14377E0BF4533D60FE336CF94BF0@phx.gbl"
type="cite">
<div id="AppleMailSignature"> This transfer is the one where NTIA
intervenes to validate the change, and it is this function that
has to be replaced, not at all the management of the A-root,
that will remain where it is.</div>
</blockquote>
<br>
Frankly, this seems to be a rather formal and not a real substantive
difference. Lets say, in the pre IANA transition stage, the US gov
had refused to validate a requested change -- there would have been
an outcry, it would have been considered illegitimate, outrageous,
and so on..... Now, lets take the post IANA transition situation.
IANA transmits a root change request to A root manager, Verisign,
but meanwhile the US gov, under whose contract verisign operates
A-root, instructs verisign not to make those changes.. What happens,
the same outrage, allegation of illegitimacy, and so on... Could
someone really tell me, where is the difference? And please not in,
what often becomes deliberately obfuscating, techno-managerial
language, but in direct political language. I am sure no one has the
illusion reg. IANA transition being a techno-managerial and not
a political issue. I hope we stay within that construction. <br>
<br>
I am sure I am going to hear pious statements about how US would
never do it, it never has (which btw is contestable, but lets not go
there). Sure. But if the US is really so pious *why, when it was
divesting itself from other stuff, it did not also divest itself of
control over the authoritative A-root?* Could someone answer this
question for me. I really look forward to read what new spin is
thrown in to respond to this :). <br>
<br>
Another stock response that I expect to hear is - US wont do it bec
it should fear that other root operators would not follow suit...
But that check was always there, even earlier, against US refusing
to validate an ICANN root change request... So nothing changes,
right!<br>
<br>
A policy making power is meaningful only to the extent that there is
policy implementation power. Minus the latter, the former is
meaningless. What stops, say, my organisation from making gTLD
policies? The simply fact that I cannot implement them, which
requires control over the authoritative A-root. Without the control
over the A-root, ICANN's policy making power, and its so called
(anticipated) new 'independence', are meaningless. It exists as long
as US allows it to exist. Which one must say is a rather pitiable
situation. <br>
<br>
I think that this group - ALAC, which sits between a
techno-political set up and the larger public, and is supposed to
represent the latter's interest, has the responsibility to interpret
the politics of these techno- managerial and political changes for
the public in intelligible terms, and most of all show clearly where
power lies, what are its legitimate forms, and what and where power
goes or does not go post transition. Sorry to say, but I dont think
we have been doing a very good job of it.<br>
<br>
regards<br>
parminder<br>
<br>
<blockquote
cite="mid:DUB404-EAS14377E0BF4533D60FE336CF94BF0@phx.gbl"
type="cite">
<div id="AppleMailSignature">Cheers,</div>
<div id="AppleMailSignature">Roberto</div>
<div id="AppleMailSignature"><br>
<br>
Inviato da iPad</div>
<div><br>
Il giorno 05.03.2016, alle ore 11:49, parminder <<a
moz-do-not-send="true" href="mailto:parminder@itforchange.net"><a class="moz-txt-link-abbreviated" href="mailto:parminder@itforchange.net">parminder@itforchange.net</a></a>>
ha scritto:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
Karl<br>
<br>
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. <br>
<br>
The following is my current proposal, which I would think is
rather easy to carry through.<br>
<br>
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. <br>
<br>
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.)<br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
I would like to hear your and others' comments on this
proposal.<br>
<br>
parminder<br>
<br>
<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On Sunday 28 February 2016 11:34
AM, Karl Auerbach wrote:<br>
</div>
<blockquote cite="mid:56D28E04.2030804@cavebear.com"
type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 2/27/16 2:45 AM, parminder
wrote:<br>
</div>
<blockquote cite="mid:56D17E49.2080806@itforchange.net"
type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
<font face="Verdana">I disagree with Karl that California
remains the best jurisdictional bet...<br>
</font></blockquote>
That's sensible. I'm often wrong. ;-)<br>
<br>
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.<br>
<br>
I understand the concern about US hegemony.<br>
<br>
But take heart, even those of us in the US feel locked out.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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 - <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cavebear.com/bwg/submission-letter.html">http://cavebear.com/bwg/submission-letter.html</a><br>
<br>
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.<br>
<br>
--karl--<br>
<br>
</blockquote>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>At-Large mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:At-Large@atlarge-lists.icann.org">At-Large@atlarge-lists.icann.org</a></span><br>
<span><a moz-do-not-send="true"
href="https://atlarge-lists.icann.org/mailman/listinfo/at-large">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a></span><br>
<span></span><br>
<span>At-Large Official Site: <a moz-do-not-send="true"
href="http://atlarge.icann.org">http://atlarge.icann.org</a></span></div>
</blockquote>
</blockquote>
<br>
</body>
</html>