[discuss] Roadmap for globalizing IANA

parminder parminder at itforchange.net
Sat Mar 8 03:40:31 UTC 2014



On Friday 07 March 2014 09:30 PM, Mawaki Chango wrote:
>
>
> On Fri, Mar 7, 2014 at 3:27 PM, Milton L Mueller <mueller at syr.edu 
> <mailto:mueller at syr.edu>> wrote:
>
>     Right, Brenden, I agree that Mawaki has raised an important issue.
>     We suggested, perhaps a bit too casually, that the contract
>     between DNSA and ICANN might be renegotiated after a period.
>     I think that was not fully thought out, 
>
>
> Right!...Not too early, but I guess not too late either.
> It indeed didn't strike me as well thought out to even suggest that 
> DNSA would be in position to make the decision as to who gets the 
> contract, right after saying it only has a clerical (IANA functions) 
> and a technical (Root zone maintainer) role


Yes, this is the principal problem with Milton and Brenden's proposal.

Everyone's eye is on the one big knotty problem on the CIR side of 
global IG - the oversight of ICANN..... It is not clear whether Milton 
and Brenden's proposal at all attempts to solve this problem. If it 
does, it tries to do so in a strangely circular, and, IMO, rather 
untenable way.

They wish to create a new entity with an extremely unclear status, role 
and authority. They like to call its function as merely clerical and of 
only technical implementation. It is strange to describe the role and 
function in such a manner of an agency which seems to have complete 
legal and physical custody of the root of the global Internet - and that 
too with no oversight above it at all, which seems to make this control 
rather absolute, whether Milton and Brenden actually say this or not.

   Milton and Brenden say that this new entity cannot abuse this all 
crucial position because it will be bond by a contract with ICANN to do 
only implementation as per policy developed by ICANN. However, at the 
same time is seems that this new entity is the Principal in the implied 
contract, which it can award to other possible contractors than ICANN... 
Unclear here who writes the contract and ensures its inviolability (as 
Mawaki argues). Is it to be under some clear international law and 
system beyond both these entities - the new one and the ICANN? That is 
the crucial missing point. What stops this new entity from giving the 
contract to a party that agrees (gradually and progressively, or at one 
go) to its own thinking/ interests rather than not? Does  every 
contractor not keep a keen eye  on the next renewal periodin terms of 
how it acts, as for instance ICANN does at present vis a vis DoC of US 
government.

Evidently, despite the proponents best effort at sugar-coating the fact, 
the new entity would exercise a de facto oversight role over ICANN, by 
being the Principal of the contract between them, and having the actual 
authority and legal possession vis a vis root changes.

Can a trade association be trusted to exercise such a role? I take the 
easy route to quote what Adam Smith said - Adam Smith, the so called 
founder of free market doctrines.

  "People of the same trade seldom meet together, even for merriment and 
diversion, but the conversation ends in a conspiracy against the public, 
or in some contrivance to raise prices.... But though the law cannot 
hinder people of the same trade from sometimes assembling together, it 
ought to do nothing to facilitate such assemblies, much less to render 
them necessary. "

Adam gives us a clear advice - do not encourage an assembly of tld 
operators for any purpose at all, much less give them the control of 
global Internet's root.

However, even before Milton and Brenden's proposal can be judged to be 
good or bad I think it will be judged as impractical by neutral legal 
pandits and jurists.

About Brenden's point below on termination of contracts, conditions in 
this regard always favour the entity who holds the default power - if 
there were no contract (as for instance between a property owner and one 
who rents it)... In this case, it is the proposed new entity that holds 
all the important cards. In any case, there is the issue of renewal of 
the contract - a situation which lies outside the contract and cannot 
ordinarily be guided by the contract. Here the defualt power and 
position - which lies with the proposed new entity - becomes all 
important, and gives it the kind of power most of us cannot even think 
of giving to such an entity.

Also, Vinay's poser is very interesting and very real, and I did not 
hear a response to it - how will the new proposed entity react to a 
situation where, at the time of renewal of the contract, an entity other 
than ICANN comes up with a claim of better, including more globally 
representative, policy development position?

parminder





> --regardless of scenarios such as the one Vinay has come up with. And 
> that was precisely basis for my question.
>
> Either your proposal is missing some other entity with the authority 
> to award that contract or your proposed structure will have to be 
> re-designed. Once USG is taken out of the equation the main purpose of 
> the new DNSA will be to carry out decisions made by ICANN; I don't see 
> how that makes both independent entities _freely_ choosing to enter 
> into such contract. Nor do I see how DNSA can be said to be just 
> clerical and technical while being in position to decide who is going 
> to be the policymakers whose decisions they are meant to implement.
>
> Mawaki
>
>     because we don't want DNSA to be the principal and ICANN the
>     agent, nor do we want ICANN to be the  principal and DNSA the
>     agent. What we want is a stable agreement between two equal
>     parties that is worked out once and kept in place indefinitely,
>     unless something goes terribly wrong.
>
>
>     -----Original Message-----
>     From: Brenden Kuerbis [mailto:bkuerbis at gmail.com
>     <mailto:bkuerbis at gmail.com>]
>     Sent: Thursday, March 06, 2014 9:51 AM
>     To: Mawaki Chango
>     Cc: discuss at 1net.org <mailto:discuss at 1net.org>; Milton L Mueller
>     Subject: Re: [discuss] Roadmap for globalizing IANA
>
>     Hi Mawaki,
>
>     Thanks for reading the proposal and your questions.
>
>     It's worth noting there is a world of difference between
>     government contracting
>     <http://www.law.cornell.edu/wex/government_contracts>, the
>     situation we have currently, and private contracting
>     <http://www.law.cornell.edu/wex/contract>, which we propose
>     between a DNSA (registration authority) and ICANN (policy
>     development authority).  E.g., the former often contains mandatory
>     clauses, e.g., unilateral rights to terminate or amend, while the
>     conditions of the later are up to the parties to negotiate.  Of
>     course, a contract would be enforceable by law, and jurisdiction
>     necessarily identified.
>
>     Given that, and to your point, we are not suggesting that the DNSA
>     (nor ICANN) would be in a position to terminate the contract
>     unilaterally. Rather, termination conditions would have be
>     negotiated between the parties. Arguably, structurally separating
>     the IANA function (specifically, root zone management) makes
>     identifying those conditions easier. It could focus the
>     negotiation on determining tangible (e.g., service levels), rather
>     than subjective (e.g., is the institution multistakeholder
>     enough), measures.
>
>     Milton might have something to add, but thanks for helping us
>     clarify that point.
>
>
>     ---------------------------------------
>     Brenden Kuerbis
>
>
>     On Thu, Mar 6, 2014 at 7:39 AM, Mawaki Chango <kichango at gmail.com
>     <mailto:kichango at gmail.com>> wrote:
>     > As it has been brought to my attention that my comments and question
>     > were not clear enough to some, here is another way of stating my
>     > concerns quoting from the original text (with a reiteration of my
>     > comments in square brackets and caps).
>     >
>     > <quote>
>     >
>     > The DNSA would require a binding contract with ICANN regarding the
>     > conditions under which
>     >
>     > it would agree to implement changes in the root zone or other
>     > associated databases to reflect policies
>     >
>     > emerging from ICANN's policy development processes [WHO WILL BE THE
>     > ENFORCER IN ODER TO MAKE SUCH CONTRACT BINDING?]. The contract
>     should
>     > ensure that the DNSA
>     >
>     > has no policy authority but merely implements valid requests for
>     > additions or deletions emerging from
>     >
>     > ICANN's policy process [NOTED!]. DNSA would promise to abide by
>     ICANN
>     > policy directives on the
>     >
>     > condition that ICANN's policy decisions related to the root not be
>     > used to impose requirements on
>     >
>     > registries, via registry agreements, to regulate content or
>     otherwise
>     > locally lawful behavior of registrants.
>     >
>     > The existence of this contract would provide the opportunity for
>     > developing an additional accountability
>     >
>     > check on ICANN [HOW SO? AGAIN WHO IS THE AUTHORITY THAT WOULD MAKE
>     > THIS SO-CALLED "ADDITIONAL ACCOUNTABILITY" EFFECTIVE?]. For example,
>     > if the contract was not in perpetuity but was renewable every five
>     >
>     > years, diverse entities might compete to replace the existing
>     ICANN as
>     > the policy development
>     >
>     > authority [SO HERE IS THE CRUX: YOU SEEM TO BE SUGGESTING THAT
>     ONE OF
>     > THOSE PARTIES, THE DNSA, IS IN A POSITION TO AWARD THIS CONTRACT TO
>     > THE OTHER, AND SO IT MIGHT AT SOME POINT WITHDRAW IT FROM THAT OTHER
>     > PARTY AND AWARD IT TO ANOTHER -- NOT UNLIKE THE POSITION THE USG WAS
>     > IN WITH ICANN. DO YOU UNDERSTAND THE TENSION? AT THE VERY LEAST
>     THERE
>     > IS A GAP IN YOUR EXPLAINING REGARDING THE FULL MECHANISMS OF THIS
>     > CONTRACTING, BUT YOU CAN'T JUST SAY DNSA HAS NO POLICY AUTHORITY
>     WHILE
>     > IMPLYING IT MIGHT TAKE THE CONTRACT AWAY FROM ICANN (SINCE YOU
>     HAVEN'T
>     > EXPLAINED WHERE ELSE THE AUTHORITY FOR DOING THAT WOULD LIE IN THAT
>     > RELATIONSHIP OR GOVERNANCE STRUCTURE.] As for the DNSA, as a private
>     > association of incumbent registries, any attempt by it to
>     >
>     > manipulate root zone management to thwart competition or
>     discriminate
>     > against eligible members would
>     >
>     > be easily challenged by competition law authorities in Europe, the
>     > U.S., or elsewhere
>     >
>     > </quote>
>     >
>     >
>     >
>     > =====================================
>     > Mawaki Chango, PhD
>     > Founder and CEO
>     > DIGILEXIS Consulting
>     >
>     > m.chango at digilexis.com <mailto:m.chango at digilexis.com> |
>     http://www.digilexis.com
>     > Twitter: @digilexis | @dig_mawaki | Skype: digilexis
>     > ======================================
>     >
>     >
>     >
>     > On Wed, Mar 5, 2014 at 8:59 AM, Mawaki Chango
>     <kichango at gmail.com <mailto:kichango at gmail.com>> wrote:
>     >>
>     >> Milton,
>     >>
>     >>
>     >> [Note: Sorry for coming late in this conversation and yet not
>     reading
>     >> all the previous comments and answers due to limited
>     connection. So I
>     >> am posting the following after reading the paper and drafting this
>     >> off line. Apologies for any unintentional repetition.]
>     >>
>     >>
>     >> Thank you and Brenden for putting together this innovative
>     attempt to
>     >> solving the challenges of the evolving institutional field for
>     >> Internet governance, and for sharing it. I have two points
>     about your proposal.
>     >>
>     >>
>     >> First, it is not clear to me how combining the IANA functions
>     (which
>     >> your proposal define as clerical) with the Root Zone Maintainer
>     >> functions (which I would think are technical, with no more decision
>     >> making power than the IANA functions) in a new entity provides that
>     >> entity with the authority you seem to be giving it.
>     >>
>     >> Indeed, it sounds like you're proposing to end the _political_
>     >> oversight from USG by replacing it with the industry (DNSA)
>     >> oversight. You say the existence of a contract between ICANN
>     and the
>     >> DNSA provides check and balance to ICANN and that other
>     entities may
>     >> even compete to replace ICANN if that contract were to (as it
>     could)
>     >> be made renewable every 5 years for instance, etc. In other words,
>     >> this contract doesn't seem like a contract between peer
>     organizations
>     >> with each just having specific different roles toward the
>     other, but
>     >> a contract between a principal and an agent, or in any case between
>     >> an entity that has (a higher) authority over the other since the
>     >> former can put an end to the raison d'etre of the latter and
>     give it away to a competitor.
>     >>
>     >>
>     >> While I understand the incentive-based rationale for the membership
>     >> of the DNSA, I fail to see where you make the case for such larger
>     >> authority as you attribute to it, again merely by combining the
>     IANA
>     >> functions with the Root Zone Maintainer functions. What is the
>     source
>     >> of the DNSA authority which makes it competent to exercise an
>     >> oversight that matches the previous political oversight (since
>     removing the term "political" from "oversight"
>     >> doesn't seem to narrow it to only the clerical and technical roles
>     >> DNSA is supposed to carry out in the new governance structure) and
>     >> competent to decide to grant or not to grant ICANN its contract?
>     >>
>     >>
>     >> I think clarifying this will also help resolve the question as to
>     >> whether political considerations (in the larger sense of political)
>     >> need to be brought to bear in deciding who should be part of
>     the DNSA
>     >> -- which can be a decisive factor for the success or failure of
>     this proposal.
>     >>
>     >>
>     >> My second point is much shorter and concerns your reference to a
>     >> treaty, at last twice. I don't seem to find anywhere in the text an
>     >> explanation about what the purpose of a treaty would be within the
>     >> framework of this proposal. Would you mind elaborate on that?
>     >>
>     >>
>     >> Thanks,
>     >>
>     >>
>     >> Mawaki
>     >>
>     >>
>     >> =====================================
>     >> Mawaki Chango, PhD
>     >> Founder and CEO
>     >> DIGILEXIS Consulting
>     >>
>     >> m.chango at digilexis.com <mailto:m.chango at digilexis.com> |
>     http://www.digilexis.com
>     >> Twitter: @digilexis | @dig_mawaki | Skype: digilexis
>     >> ======================================
>     >>
>     >>
>     >>
>     >> On Wed, Mar 5, 2014 at 6:52 AM, Adam Peake <ajp at glocom.ac.jp
>     <mailto:ajp at glocom.ac.jp>> wrote:
>     >>>
>     >>>
>     >>> On Mar 5, 2014, at 2:57 AM, Shatan, Gregory S. wrote:
>     >>>
>     >>> > Adam:
>     >>> >
>     >>> > Don't worry, I haven't dismissed the proposal out of hand.  I'm
>     >>> > still chewing on it.
>     >>> >
>     >>> > You mention the concern about "predictable and reliable service"
>     >>> > -- do you know of any instances where the current set-up has
>     >>> > failed to provide that?
>     >>> >
>     >>>
>     >>>
>     >>> For a period of about 12 months before David Conrad joined as IANA
>     >>> General Manager in 2005 I understand IANA was not working well.
>     >>> David fixed things.  David or ccTLD managers on this list could
>     >>> explain and clarify/correct my clumsy words.  IANA now has another
>     >>> very capable manager, Elise Gerich.  But yes, I believe highly
>     unreliable service for a while.
>     >>> Not quite the current set-up but within the general current
>     arrangement.
>     >>>
>     >>>
>     >>> > I think the point about diversity of registries is an
>     important one.
>     >>> > In addition to those you mention, there are the ".brand"
>     >>> > registries as well, who would provide yet another voice.  (I
>     >>> > assume these would be included, even though they are not
>     mentioned
>     >>> > specifically in the proposal.  To the extent these are "single
>     >>> > registrant" gTLDs, the "weighting" issue is interesting.  (Of
>     >>> > course, there may be non-.brand single registrant TLDs as
>     well (I
>     >>> > think I saw a couple of applications where the users were not
>     >>> > really "registrants" of SLDs ).)
>     >>> >
>     >>>
>     >>>
>     >>> Diversity can be a great protector: interests and motivations may
>     >>> not align, etc.
>     >>>
>     >>> Adam
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> > Greg
>     >>> >
>     >>> > -----Original Message-----
>     >>> > From: Adam Peake [mailto:ajp at glocom.ac.jp
>     <mailto:ajp at glocom.ac.jp>]
>     >>> > Sent: Tuesday, March 04, 2014 12:32 PM
>     >>> > To: Shatan, Gregory S.
>     >>> > Cc: 'joseph alhadeff'; discuss at 1net.org
>     <mailto:discuss at 1net.org>
>     >>> > Subject: Re: [discuss] Roadmap for globalizing IANA
>     >>> >
>     >>> >
>     >>> > Hi Greg,
>     >>> >
>     >>> > On Mar 5, 2014, at 1:49 AM, Shatan, Gregory S. wrote:
>     >>> >
>     >>> >>
>     >>> >> The popular term for this might be "the fox guarding the
>     henhouse."
>     >>> >> Of course, if it is merely "operational," then perhaps the
>     >>> >> concern is overblown.  But if these functions are merely
>     >>> >> operational, why not just leave them at ICANN?
>     >>> >>
>     >>> >
>     >>> >
>     >>> > Not sure about "fox guarding the henhouse"...  These
>     functions are
>     >>> > essential to the registries' business.  As Milton keeps
>     reminding
>     >>> > us, it's operational, they need predictable and reliable
>     service.
>     >>> >
>     >>> > The diversity of registries is quite positive, very different
>     >>> > business models (from com to new community tlds), different
>     >>> > stakeholders and particularly sponsoring entities (for profit,
>     >>> > ccTLD, government, IGO, NGO), geographic diversity (though even
>     >>> > with around 25% ccTLD not as balanced as we'd hope), even
>     language.
>     >>> >
>     >>> > I think it's worth looking at the merits of the proposal.
>     >>> >
>     >>> > Best,
>     >>> >
>     >>> > Adam
>     >>> >
>     >>> >
>     >>> >> Greg Shatan
>     >>> >>
>     >>> >> From: discuss-bounces at 1net.org
>     <mailto:discuss-bounces at 1net.org> [mailto:discuss-bounces at 1net.org
>     <mailto:discuss-bounces at 1net.org>]
>     >>> >> On Behalf Of joseph alhadeff
>     >>> >> Sent: Tuesday, March 04, 2014 9:55 AM
>     >>> >> To: discuss at 1net.org <mailto:discuss at 1net.org>
>     >>> >> Subject: Re: [discuss] Roadmap for globalizing IANA
>     >>> >>
>     >>> >> While I am not as well versed in these issues and their history
>     >>> >> of some of the more frequent commentators, it would seem that
>     >>> >> accountability is often benefited by and predicated on a
>     separation of duties in oversight.
>     >>> >> The new organization seems to rely on self-interested parties
>     >>> >> having an alignment of interest with the public good as opposed
>     >>> >> to the more traditional concept of separation of
>     duties/interest
>     >>> >> in oversight.  Am I missing the checks and balances?
>     >>> >>
>     >>> >> Best-
>     >>> >>
>     >>> >> Joe
>     >>> >> WOn 3/3/2014 9:43 PM, Milton L Mueller wrote:
>     >>> >> Nii, thanks for your questions. Most of them are actually
>     >>> >> answered in the paper itself, but I will answer your
>     questions directly.
>     >>> >>
>     >>> >>> Why is removing USG not mean just that? End of contract
>     >>> >>
>     >>> >> First, it would be the end of 2 contracts, not one. ICANN and
>     >>> >> Verisign. You cannot just end the IANA functions contract.
>     >>> >>
>     >>> >> Second, both contracts contain serious accountability measures.
>     >>> >> However wrongly conceived the idea of unilateral U.S. oversight
>     >>> >> is, how do we ensure that the root zone is managed properly and
>     >>> >> what is the recourse if the root zone managers are either
>     >>> >> negligent, incompetent or corrupt? What do you replace the
>     IANA contract with?
>     >>> >>
>     >>> >> The reason for a DNSA is that registries have the strongest
>     >>> >> incentive to get root zone management right. It is their data
>     >>> >> that the root zone contains. To ensure impartial administration
>     >>> >> we create a nondiscriminatory right to own DNSA to all
>     registries?
>     >>>
>     >>> >>
>     >>> >>> What problem is being solved by combining functions from other
>     >>> >>> organizations to create another entity dnsa?
>     >>> >>
>     >>> >> As noted above: 1) accountability problem; 2) incentives
>     problem.
>     >>> >> To which we can add: not letting ICANN get too powerful.
>     >>> >>
>     >>> >>> The proposed Dnsa is potentially a consortium of 1000+
>     >>> >>> registries and how would this work.
>     >>> >>
>     >>> >> Not that many companies involved. More like a few hundred; lots
>     >>> >> of companies have multiple TLDs. Ownership shares might be
>     based
>     >>> >> on some metric of size, such as names under registration, etc.
>     >>> >>
>     >>> >> How does GNSO work? How does ccNSO work? How did Intelsat work?
>     >>> >> (consortium of ~200 national telecom operators). How did
>     Nominet work?
>     >>> >> (shared ownership by many registrars) How does IEEE work?
>     >>> >> (hundreds of thousands of members).
>     >>> >>
>     >>> >>> Is this different from creating another ICANN
>     >>> >>
>     >>> >> Very different. ICANN is for making policy. It involves
>     >>> >> representation of diverse stakeholders and a complicated
>     process
>     >>> >> for developing consensus on policy and approval by the
>     board. DNSA is for operations.
>     >>> >> Most people I have talked to agree that we need to keep those
>     >>> >> things separate. So, we separate them
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >> _______________________________________________
>     >>> >> discuss mailing list
>     >>> >> discuss at 1net.org <mailto:discuss at 1net.org>
>     >>> >> http://1net-mail.1net.org/mailman/listinfo/discuss
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >> * * *
>     >>> >>
>     >>> >> This E-mail, along with any attachments, is considered
>     >>> >> confidential and may well be legally privileged. If you have
>     >>> >> received it in error, you are on notice of its status. Please
>     >>> >> notify us immediately by reply e-mail and then delete this
>     >>> >> message from your system. Please do not copy it or use it
>     for any
>     >>> >> purposes, or disclose its contents to any other person.
>     Thank you for your cooperation.
>     >>> >>
>     >>> >> * * *
>     >>> >>
>     >>> >> To ensure compliance with Treasury Department regulations, we
>     >>> >> inform you that, unless otherwise indicated in writing, any
>     U.S.
>     >>> >> Federal tax advice contained in this communication  (including
>     >>> >> any attachments) is not intended or written to be used, and
>     >>> >> cannot be used, for the purpose of (1) avoiding penalties under
>     >>> >> the Internal Revenue Code or applicable state and local
>     >>> >> provisions or (2) promoting, marketing or recommending to
>     another party any tax-related matters addressed herein.
>     >>> >>
>     >>> >> Disclaimer Version RS.US.20.10.00
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >>
>     >>> >> _______________________________________________
>     >>> >> discuss mailing list
>     >>> >> discuss at 1net.org <mailto:discuss at 1net.org>
>     >>> >> http://1net-mail.1net.org/mailman/listinfo/discuss
>     >>> >
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> discuss mailing list
>     >>> discuss at 1net.org <mailto:discuss at 1net.org>
>     >>> http://1net-mail.1net.org/mailman/listinfo/discuss
>     >>
>     >>
>     >
>
>
>
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140308/f4ae0dbb/attachment-0001.html>


More information about the discuss mailing list