[At-Large] R: CCWG Briefings - Presentation

Sun Mar 6 09:03:07 UTC 2016

Dear parminder,
Thanks for your detailed reply.
However, all I wanted to say is that the simple solution you proposed seemed to me not that simple, because even after the transition ICANN would not have "owned" the A-root: it was not at all to the merit of your proposal, but on the supposed simplicity of the solution.
This said, since we have opened this dialogue, I will give you my personal opinion.
I don't want to underestimate the problem of having one country - whether this is US or any different one - a more important role than the other countries. I have been an international civil servant for 13 years, and I am committed to internationalization.
However, as internet user, domain name registrant, and active participant to ALAC I have to say that I can identify half a dozen problems that are, for me, far more important than where the A-root is located.
IMHO, even with the DNS solidly in the hands of an international treaty organization (which, incidentally, will take years if not decades to establish, see for instance the still interim status of the CTBTO), the imbalance between the power of commercial organizations and plain internet users will not change, the heavy limitations - mainly for economic reasons - for ALAC members to participate in the policy development process will not change, the imbalance of power between the registering organizations - Registries and Registrars - and registrants will not change, just to name what crosses my mind right now.
So, given the fact that volunteers from the At-Large community have limited time, because they generally have day jobs in a different domain, I am in complete agreement with Olivier that our priorities are somewhere else than the international status of the root. This is not to say that this is not a problem, and I agree with you that a stress test could have been developed on this issue in the process of transferring NTIA's responsibilities, but I personally believe that the leading forces for driving this debate should be the GAC and generally speaking the professional politicians, for whom this issue is within their core competences and business, rather than for ALAC and At-Large users, for whom everyday' s problems are others.
IMHO, ALAC could endorse a reasonable proposal coming from other quarters, but should spend its limited bandwidth in addressing the many issues that we do have now rather than addressing a potential problem that might be caused in the future by a - highly unlikely - future interference by the US Government.
Cheers,
Roberto

> -----Messaggio originale-----
> Da: parminder [mailto:parminder at itforchange.net]
> Inviato: domenica 6 marzo 2016 04:18
> A: Roberto Gaetano
> Cc: Karl Auerbach; at-large at atlarge-lists.icann.org
> Oggetto: Re: [At-Large] CCWG Briefings - Presentation
> 
> 
> 
> On Saturday 05 March 2016 10:04 PM, Roberto Gaetano wrote:
> > 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.
> 
> 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.
> 
> 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).
> 
> > 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.
> 
> 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).
> 
> > 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.
> 
> 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.
> 
> 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 :).
> 
> 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!
> 
> 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.
> 
> 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.
> 
> regards
> parminder
> 
> > Cheers,
> > Roberto
> >
> >
> > Inviato da iPad
> >
> > Il giorno 05.03.2016, alle ore 11:49, parminder
> > <parminder at itforchange.net <mailto:parminder at itforchange.net>> ha
> scritto:
> >
> >> 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--
> >>>
> >>
> >> _______________________________________________
> >> At-Large mailing list
> >> At-Large at atlarge-lists.icann.org
> >> <mailto:At-Large at atlarge-lists.icann.org>
> >> https://atlarge-lists.icann.org/mailman/listinfo/at-large
> >>
> >> At-Large Official Site: http://atlarge.icann.org