[discuss] Roadmap for globalizing IANA

Vinay Kesari vinay.kesari at gmail.com
Sat Mar 8 10:55:16 UTC 2014


Hi Milton,

I agree that splitting powers and functions between institutions is a great
way of ensuring accountability, and is the basis of most systems of checks
and balances. It is something that must certainly be explored in the area
of DNS policy and administration.

How is accountability to be ensured, though? A fixed-term contract (which
is what the paper proposes) acts as a check since the threat of non-renewal
always hangs over the head of the policy making body. But if we move away
from this idea (as suggested in your trailing email) to an open ended
arrangement combined with clauses relating to exigent circumstances, my
fear is that the proposal then becomes incompatible with (or at least
materially dilutes) Principle 1, which is 'Completely separate root zone
file modification from policy-making'. Because DNSA would then need to
actually monitor orders from ICANN/the policy making body, to ensure that
they do not fall afoul of the 'safety valve clause'.

I want to stress that I am not pressing this point in order to be
difficult. Your proposal appeals to me on a logical level, because it has
the potential to isolate some of the (hopefully) less controversial
sections of the Internet governance debate and find a practical solution to
them. But in searching for such a solution, I would want to be certain that
labels/principles (such as the complete separation of policy and technical
functions) can practically be achieved.

Regards,
Vinay



On 7 March 2014 21:35, Milton L Mueller <mueller at syr.edu> wrote:

>  Vinay,
>
> These are good questions and that is why I tried to clarify, in my
> response to Mawaki, that the ICANN-DNSA contract would be more of a
> one-time negotiated settlement rather than a contract in which DNSA is
> principal.
>
>
>
> However, I would say that separating them still provides a key
> check/balance. It has often been noted that the root server operators
> currently are passive takers of the root zone file from Verisign, but that
> if the USG went haywire and started abusing its authority, e.g. by throwing
> enemy ccTLDs out of the root, then some RS operators, e.g. in Europe or
> Asia, or even some in USA, might not go along with it. A contract that
> contained some kindof safety valve clause that provided extraordinary
> grounds for not implementing a policy request by ICANN, is conceivable.
>
>
>
> *From:* discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] *On
> Behalf Of *Vinay Kesari
> *Sent:* Friday, March 07, 2014 7:23 AM
> *To:* Brenden Kuerbis
> *Cc:* discuss at 1net.org
>
> *Subject:* Re: [discuss] Roadmap for globalizing IANA
>
>
>
> Hi Brenden and Milton,
>
>
>
> I think Mawaki's point about the accuracy of stating that DNSA would have
> 'no policy role' (in the context of the contract between DNSA and the
> policy making body) requires further exploration. Brenden, while your
> response covers termination of the contract, it does not address what
> happens when it's time to renew the contract.
>
>
>
> Assume this scenario (which might be a bit simplistic, but isn't
> implausible):
>
>
>
> The DNSA is set up in 2015 along the lines proposed, and ICANN and DNSA
> negotiate a 5 year agreement containing fairly standard, commercially
> acceptable terms. There are no disputes between the contracting parties
> during the term of the contract. However, between 2015 and 2019 global
> geopolitics results in certain countries effectively walking away from
> ICANN (and all other I* organisations) and setting up a 'competing' policy
> making body organised along multilateral lines (let's call it 'NewCo',
> shall we? :)). It is now 2019, and DNSA issues an RFP - it receives
> responses from ICANN and NewCo. DNSA now needs to make a decision on who to
> award the contract to.
>
>
>
> How would you see this scenario playing out, in process terms? What kind
> of selection procedure would DNSA use, considering that most objective
> criteria would automatically favour ICANN since it is the incumbent?
>
>
>
> Regards,
>
> Vinay
>
>
>
> PS: Let me make it clear that the only thing I am debating here is the
> compatibility of the DNSA proposal with the paper's Principle #1 -
> "Completely separate root zone file modification from policy-making."
>
>
>
> --
>
>
>
> Vinay Kesari
>
> ICT Lawyer
>
> New Delhi
>
>
>
>
>
>
>
> On 6 March 2014 20:26, Brenden Kuerbis <bnkuerbi at syr.edu> wrote:
>
> 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> 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 | 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>
> 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 | 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> 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]
> >>> > Sent: Tuesday, March 04, 2014 12:32 PM
> >>> > To: Shatan, Gregory S.
> >>> > Cc: 'joseph alhadeff'; 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] On
> >>> >> Behalf Of joseph alhadeff
> >>> >> Sent: Tuesday, March 04, 2014 9:55 AM
> >>> >> To: 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
> >>> >> 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
> >>> >> http://1net-mail.1net.org/mailman/listinfo/discuss
> >>> >
> >>>
> >>>
> >>> _______________________________________________
> >>> discuss mailing list
> >>> 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/9f5ee210/attachment-0001.html>


More information about the discuss mailing list