[CWG-Stewardship] Strickling Remarks from 4 December re IANA Transition and Accountability

[Greg Shatan]

Responses inline below.

Greg

*Gregory S. Shatan **|* *Abelman Frayne & Schwab*

*666 Third Avenue **|** New York, NY 10017-5621*

*Direct*  212-885-9253 *| **Main* 212-949-9022

*Fax*  212-949-9190 *|* *Cell *917-816-6428

*gsshatan at lawabel.com <gsshatan at lawabel.com>*

*ICANN-related: gregshatanipc at gmail.com <gregshatanipc at gmail.com> *

*www.lawabel.com <http://www.lawabel.com/>*

On Thu, Dec 11, 2014 at 6:54 AM, Olivier MJ Crepin-Leblond <ocl at gih.com>
wrote:
>
>
> On 11/12/2014 06:28, Greg Shatan wrote:
>
> I just want to add a few points to Milton's response, since he
> (thankfully) said much of what I would have said (and more besides).
>
>
>
> On Wed, Dec 10, 2014 at 7:12 PM, Milton L Mueller <mueller at syr.edu> wrote:
>
>>
>>
>>
>>
>> *From:* cwg-stewardship-bounces at icann.org [mailto:
>> cwg-stewardship-bounces at icann.org] *On Behalf Of *Olivier MJ
>> Crepin-Leblond
>>
>>   I would say that this has already been demonstrated in the making up
>> of the ICG and the current CWG, both of which include non ICANN
>> participants from the global multistakeholder community.
>>
>> MM: Hello Olivier. Both the ICG and this CWG have been empowered by an
>> external entity – the NTIA. It was the NTIA that kicked off the process by
>> signaling its willingness to let go. It was NTIA that told ICANN to convene
>> but not control the process. It was the NTIA that set the parameters and
>> basic criteria a transition proposal had to meet. It is the NTIA, and the
>> US government more broadly, that will ultimately determine whether the
>> proposals we develop will be implemented. To look at these processes as
>> outgrowths of processes internal to ICANN is to be fundamentally out of
>> touch with what is going on here. As Jordan Carter pointed out in a message
>> a few minutes ago, given the concessions we had to wring out of ICANN to
>> make these processes as independent as they are, it is evident that these
>> examples you hold up would have been very different had they been internal
>> to ICANN.
>>
> GSS: The ICG is definitely not "internal-to-ICANN."  Here is #3 of the
> ICG's FAQs:
>
>   Is the ICG part of ICANN?
> No. The ICG is an independent coordination group that has been
> established as a result of a broad community consultation and in response
> to the NTIA's announcement. The ICG is conducting its work in an open,
> transparent and independent manner. The ICG will be providing its report
> to the community broadly. Moreover, the ICG has issued a Request for
> Proposal (RFP) to select a suitable neutral and independent contractor to
> perform its secretariat function
> <https://www.icann.org/news/announcement-2-2014-09-09-en>. The role of
> the secretariat is strictly limited to the functions that support the ICG,
> and will report exclusively to the ICG, its Chair or Vice-Chair(s).
>
>>    Similarly, I would point out that a totally independent MRT that does
>> not make use of ICANN's existing structures as a convenor would be missing
>> a coordinated Governmental involvement. Indeed, only ICANN has the ability
>> to make use of its members to relate back to the GAC and for the GAC to
>> express points. A totally independent MRT would have individual governments
>> speaking. Of course, individual governments were able to speak outside of
>> ICANN at, say ITU meetings or at NetMundial - but they were not restricted
>> to a handful of seats for the whole world.
>>
>> MM: The MRT _*will*_ make use of ICANN’s institutionalized
>> representational structures. No one who has thought seriously about the
>> composition of the MRT has proposed anything different from that. The GNSO
>> SGs will be putting people on to the MRT, so will the ccNSO, so will the
>> GAC, so will SSAC, so will ALAC. So will entities outside of ICANN. But it
>> will be independent of ICANN legally, which as Greg explained is essential.
>>
> GSS: As stated above, the ICG is not part of ICANN, yet it makes use of
> ICANN's structures (including the GAC), so your statement doesn't hold
> water.  The MRT can be set up in a similar fashion.
>
>>    MM: As a sideline, I am a bit disturbed by the special emphasis you
>> are placing on governmental involvement. Outside of their jurisdiction,
>> Governments’ only claim to involvement in ICANN is as one of many voices in
>> the policy development process. I do hope you, and all ALAC members,
>> understand that the IANA functions contractor is not a policy making
>> institution, nor is it supposed to be a vehicle for circumventing or
>> vetoing policy.
>>
>> MM: When it comes to the IANA functions, we do not need governments
>> “speaking,” collectively or individually, about implementation. We need
>> them in their role as ccTLD administrators, in which case they are just
>> another IANA customer. Insofar as they are indirectly affected by the IANA
>> functions, they are just another internet user stakeholder group – no
>> different from or more important than noncommercial organizations or
>> business users. There is no legitimate reason to afford governments a
>> special collective voice in the MRT. Even in the terms of the Tunis Agenda,
>> a document written by and for governments, IANA qualifies as “day to day
>> technical and operational matters” and thus as something to be left to the
>> private sector.
>>
>
>
>
> OCL: The NTIA announcement of 14 March 2014 mentions the "intent to
> transition key Internet domain name functions to the global
> multistakeholder community". There is no mention of the intent to
> transition the functions to only the IANA's direct customers.
>

GS: I'm not sure what you ar responding to here.  Neither Milton nor I nor
the CWG proposal has stated an intent to transition only to IANA's direct
customers.

>
>
>      At this stage, I could use exactly the same wording about the
>> current CWG first draft, replacing "other than to be 'internal-to-ICANN"
>> with "other than to be separable from ICANN".
>>
> GSS: This is a false equivalency.  You are comparing a five-line
> three-sentence paragraph -- about which nothing is known other than those
> few words -- with an entire section in the proposal which has been worked
> out and debated and amplified and clarified through hours of meetings and
> phone calls and hundreds of emails.
>
>
> OCL: my point is that in my opinion the challenges in working out the
> details of the CWG's first draft and making them implementable are equally
> as complex as developing a solution that involves accountability
> mechanisms.
>

GS:  I disagree. In any event, we are considerably further along in working
out the details of the CWG proposal than we (or the CCWG-Accountability,
since you seem to think accountability mechanisms are not our job) are on a
solution that relies on creating or reconstructing internal-to-ICANN
accountability mechanisms.


> Another CCWG is specifically tasked with this.
>

GS: I disagree with this as well.  Accountability mechanisms for
performance or lack of performance of the IANA Functions are our task, not
the CCWG-Accountability.  This is clear from the Charters, as I
demonstrated earlier as well.  Following your logic, we can create
something that is utterly dependent on the CCWG-Accountability to work out
all of the accountability mechanisms needed to make our proposal workable,
and that is utterly unworkable without the CCWG's *deus ex machina *descending
onto the stage and taming ICANN into an amiable creature.  I think that
would be a complete abrogation of our duties.


> I am repeatedly surprised that there is more faith in the CWG's proposal
> which introduces a multitude of unknown unknowns as far as accountability
> is concerned, than in a process that involves a strengthening of ICANN's
> accountability.
>

GS:  I would not classify the solutions in the CWG proposal as "unknown
unknowns"; at worst, they are known unknowns -- we know what the blanks
are, we just need to finish filling them in.  The major framework of the
CWG proposal is a "known known" using existing building blocks like
contracts and multistakeholder groups.  It's really not very exotic.
Indeed, when our proposal first came out, we were accused of being
"unimaginative" and "status-quoist" in the blogosphere and twitterverse.



> Is there really so much distrust about ICANN?
>

GS:  I think others have answered this in this and other threads.  I will
take a different tack. Whether there is a great deal of distrust in ICANN
today or not, we need to look down the line and think about worst case
scenarios and risk mitigation.  Using a valid, enforceable contract and an
independent third party provides a very traditional way of binding a
corporation, and isolates the accountability mechanisms from the target of
those mechanisms.  By contrast, the ALAC concept puts the accountability
mechanism inside the target.  If you had a wild animal in a cage, would you
put the tranquilizer gun inside the cage, or outside of it?


> Also - please do not equate this paragraph to a defense of ICANN on my
> part. I have serious concerns about ICANN's accountability. I think a
> number of things need to be fixed. But having seen how new entities get
> set-up with all of the best intentions in the world and then go rogue after
> a few years, I would be happier with a solution that fixes an animal that
> we already know inside out.
>

GS: I am also hopeful of a broad solution to enhancing ICANN's
accountability that fixes the animal, and I look forward to the CCWG's work
on that score. But it is not our job to fix all of ICANN.  We have a
different task and we need to put forward a proposal that meets the task.

As for the rogue entity (or entities) started with the best of intentions
that you have seen:  can you give us some more concrete detail and examples
of these?  I am sure that we could learn something from these past problems
so that we can avoid their mistakes and weaknesses.  It would be good to
have some real examples to deal with.

Best regards,

Greg

>
> Warmest regards,
>
> Olivier
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141212/e818578a/attachment-0001.html>