[CCWG-ACCT] The big test of effective accountability

[Malcolm Hutty]

On 29/01/2015 14:38, Kieren McCarthy wrote:
> Like this. Excellent food for thought. 
> 
> Will dig out Steve's mission email - had completely missed it. You have
> the email header handy?

It was introduced as part of the discussion about what "public interest"
meant in the ICANN context.

http://mm.icann.org/pipermail/accountability-cross-community/2014-December/000182.html


> 
> Kieren
> 
> -
> [sent through phone]
> 
> 
> On Thu, Jan 29, 2015 at 6:00 AM, Malcolm Hutty <malcolm at linx.net
> <mailto:malcolm at linx.net>> wrote:
> 
> 
> 
>     On 29/01/2015 11:45, Bruce Tonkin wrote:
>     > In terms of reviewing the new gTLD program
> 
>     Kieren may correct me, but I read his essay as being about more than
>     just the gTLD program alone, albeit that that was the example given. I
>     read it as a general complaint that ICANN tends to be to formalistic,
>     and loses sight of the substance of the issue, not only in gTLD
>     applications, but often. And I think that he's far from alone in that
>     view, especially amongst those who engage with ICANN peripherally
>     rather
>     than intensively.
> 
>     > I compare this to a jury process in the legal system. I don’t think
>     > you can just ask for another jury to hear the case when the first
>     > jury finds against you. There needs to be some basis for the appeal
>     > other than that you disagree with the initial finding.
>     [...]
>     > So careful work is needed to ensure that we have a process that
>     > ensures independent reviews of decisions, and also appropriate
>     > criteria to initiate a review of a decision.
> 
>     There I think you get to the heart of the matter.
> 
>     Kieren's complaint about formalism is interesting insofar as it goes,
>     and I think it is a very useful contribution, but it is only identifies
>     a problem, it doesn't analyse it or propose a solution. I would like to
>     try to work from where Kieren left off.
> 
>     Kieren, you're a journalist. You live and breathe five-Ws and an H.
>     Let's apply that here.
> 
>     WHAT's the problem? (Excessive legal formalism, resulting in loss of
>     sight of the substance of the question).
> 
>     WHY do we have that problem?
> 
>     WHO caused it and who can address that?
> 
>     HOW should it be addressed?
> 
>     (OK, I'm leaving out "when". Cut me some slack.)
> 
> 
>     WHY do we have the excessive legalistic formalism Kieren complains
>     about?
> 
>     To some extent, this is characteristic of all large bureaucracies. They
>     are instinctively defensive, and any individual within them wants to
>     show that they discharged their own responsibilities properly even -
>     perhaps especially - when they don't, as an individual, necessarily
>     agree personally with the organisation position.
> 
>     But Kieren suggests that ICANN is particularly susceptible to this
>     tendency, and I think I agree. An organisation with a highly empowered
>     single leader (think Apple under Steve Jobs) can cut through process
>     easily. I imagine an early conversation at Apple going like this:
> 
>     Product Manager: We assembled focus groups in all our major target
>     markets to identify the key characteristics of a
>     revolutionary, magical new phone. We planted the best
>     UI theorists in those groups, to guide them towards
>     characteristics and away from mere features. We then
>     tested the output with surveys from the best polling
>     companies, scientifically designed to ensure all user
>     groups had balanced representation. Using their
>     answers we ranked and prioritised development goals.
>     We hired the best and brightest designers to deliver
>     against that design brief, and I proudly present,
>     the You-Phone.
> 
>     Steve Jobs: The user experience sucks and it feels like it was
>     designed by a committee. Go back and start again.
> 
> 
>     Would we want ICANN to work like this? No! We'd be rightly terrified of
>     leaving that much power in one person's hands. We want ICANN to be run
>     by the community, with the Board acting as an arm of the community
>     conducting executive oversight, not ruled by any single Global King
>     of DNS.
> 
>     So we create structures designed to ensure that everybody's voice is
>     heard and that everybody's interests are taken into account, that
>     competing positions are balanced as fairly as it is possible to be, and
>     that decisions are demonstrably rationally arrived at on the basis of
>     previously agreed consensus policy. And we create more structures to
>     appeal cases to on the basis that any of those things failed in this
>     instance.
> 
>     And we end up with the legalistic formalism of which Kieren speaks.
> 
>     Why?
> 
>     I suggest that it is because we have such a diverse community, and so
>     the only thing we agree on is the process criteria. We agree that
>     everybody should be heard. We agree that there should be periods of
>     public comment, and then further periods of reply comment. We agree
>     that
>     policy should require consensus support. But we're so anxious that that
>     might be the only thing we agree on that we stop there. And so when a
>     decision looks bad, the only thing we have to fall back on is an appeal
>     to process.
> 
>     And mostly the process was followed (at least in a narrow sense) so
>     it's
>     very hard to reverse the decision, even if you might like to (as Bruce
>     has described). And the dissatisfied party becomes embroiled in an
>     increasingly embittered proxy fight with an increasingly defensive
>     bureaucracy, when everybody knows that the gravamen of the complaint
>     isn't really about process at all, it is, as Kieren says, about the
>     substance.
> 
>     Some would say this means we need to "unshackle" the Board, to give
>     them
>     a wide-ranging and broad discretion to "do the right thing", or
>     sometimes "to take decision based in the public interest". Removing or
>     reducing external constraints would enable "effective leadership" and
>     give the Board "flexibility to respond to a changing world" without
>     being "buried in legal challenges".
> 
>     I consider such an approach to be a trap. Those arguments are the same
>     arguments one would make if an avowed enemy of community
>     accountability.
>     Following such recommendations will lead inevitably to a Board with a
>     top-down, paternalistic view of governing the community at best, if not
>     something even worse.
> 
>     Instead, let us look to other I* communities, which do not seem to have
>     the same problem, to see how the IETF and the RIRs maintain genuine
>     bottom-up community governance, and at the same time remain focused on
>     the substance.
> 
>     Let me tell a story about how one of the RIRs recently dealt with a
>     potentially difficult problem.
> 
>     Towards the end of last year, on the mailing list for the RIPE NCC, a
>     Ukrainian who seemed to be a partisan of the government in Kiev, and an
>     opponent of the regime in Crimea and Donetsk, raised a point about the
>     rules. RIPE NCC rules say that organisations applying from IP addresses
>     must supply government issued ID, he said. Why does the RIPE NCC
>     continue to serve users in Crimea? Does the RIPE NCC accept the
>     validity
>     of the Donetsk regime? On what basis and with what justification?
>     Surely
>     the only proper course is for the RIPE NCC to cease to support
>     organisations in Crimea until the legitimately recognised government of
>     Ukraine is restored in the region (I am using his voice, you
>     understand,
>     not my own, but this is a paraphrase, not a direct quote).
> 
>     The RIPE community immediately saw this intervention for what it was in
>     substance: an attempt to embroil the RIPE NCC in the ongoing regional
>     conflict, on the side to which he was partisan. It was not really a
>     genuine enquiry about the rules, it was an attempt to force a
>     legalistic
>     interpretation that would subvert their intended substance.
> 
>     And the RIPE community responded swiftly, vocally, and
>     overwhelmingly of
>     one view. The mission of RIPE NCC is to support users by helping to
>     coordinate the distribution of IP addresses to those that need them.
>     Networks in Crimea need IP addresses. This does not change because the
>     legitimacy of the claimed government with effective control of the
>     region is disputed. Many members of the RIPE Community had considerable
>     sympathy with the Ukrainian partisan, and deep personal opposition to
>     Russian intervention in Eastern Ukraine. Nonetheless, they agreed on
>     one
>     thing: the geopolitics of the Ukraine is not the responsibility of the
>     RIPE NCC. The rule requiring government issued ID is there to support
>     RIPE NCC's mission to coordination IP address distribution so that
>     networks are allocated the address space they require (so that RIPE NCC
>     can identify the entities to which it has made allocations); to apply
>     the same rule to prevent IP address block allocation would be to
>     subvert
>     the mission. While there is no universally recognised government in
>     Eastern Ukraine, the RIPE NCC should accept such ID from entities in
>     that area as they are reasonably able to provide.
> 
>     This story, I think, exemplifies the ability to cut to the substance of
>     the issue that Kieren seeks. How is it arrived at? Not by the
>     introduction of any strong central leader: the NCC staff and Board was
>     almost silent while this discussion played out amongst the community.
>     It was arrived at because the community had a strongly unified sense of
>     its own limited mission (to support the distribution of IP addresses to
>     those that need them, through coordinated allocation policies) and the
>     members of that community were overwhelmingly willing to set aside
>     their
>     own views on a matter outside the scope of that mission when it was
>     suggested that some other reasoning requires an effect fundamentally
>     contrary to the mission. We will not have an argument about whether
>     RIPE
>     NCC should act to /limit/ the allocation of IP addresses to entities in
>     Crimea, not even dressed in the coat of a rules interpretation. Maybe
>     action should be taken against the regime in Crimea - but not by RIPE
>     NCC. RIPE NCC will discharge its own mission, and leave the geopolitics
>     to others.
> 
>     Is this not the same culture we want to inculcate in ICANN?
> 
>     I believe that story exemplifies the strength of the RIRs, and
>     describes
>     exactly what we want from ICANN too.
> 
>     And it is very far from the ICANN Kieren describes.
> 
>     WHO can bring this change about?
> 
>     Only us.
> 
>     When we look to Kieren's complaint, and see how far short ICANN
>     falls of
>     the strong culture shows by the RIRs and the IETF, the "fault" lies
>     with
>     us, the community. We don't *want* the Board, or the CEO, or the staff
>     to come up with a dramatically developed version of the ICANN Mission
>     that will then overrule existing processes and policies.
>     The Mission must be developed by, and founded in, the community itself.
> 
>     What we need is for the community to develop a much clearer idea of the
>     Mission, and an exposition of what that means and how it is to be
>     applied. Then all the accountability structures we create, the Review
>     Boards and Reconsideration Panels and Ombudsmen and the rest, they will
>     have a proper standard for review. Not a sterile standard that looks
>     only to bare process, but one that asks "Is this consistent with the
>     fundamental mission?"
> 
>     Consider how this might work in practice.
> 
>     For .gay, there are many objections one might make. One might say the
>     proposed registrar was not suitable - but that should only lead to the
>     selection of an alternative, or the imposition of tighter control, not
>     to refusal to delegate. If you're not confident in the registrar you
>     might impose behavioural controls (e.g. to prevent limitation of
>     supply)
>     or structural controls (e.g. a shorter contract, to require
>     renunciation
>     of any presumption of renewal of the registry contract etc) or some
>     combination of the two. There will be plenty of room for arguments
>     about
>     the best way to proceed.
> 
>     But arguments that resolve to (or are recognisable as a mere pretext
>     for) the claim that .gay ought not to exist can be dismissed: ICANN's
>     mission is to make domains available, not to prevent their
>     availability.
> 
>     I promised a HOW.
> 
>     Here is HOW I think we should proceed.
> 
>     In our Frankfurt face-to-face we constructed, yet again, a map of
>     possible new structures, and most of the focus went on that. But there
>     was also a slot on it for the question of clarifying the mission, as
>     the
>     basis for review. A few weeks ago, on this list, Steve DelBianco made a
>     very valuable start, suggesting a new codification of the mission. That
>     contribution has passed almost without notice.
> 
>     I don't necessarily think Steve's formulation is perfect, but it's a
>     lot
>     better than anything else I've yet seen, and it has the virtue of being
>     a contribution on this critical subject, almost alone. Let us work
>     together on that, to build that common shared sense of Mission.
>     Not an infinitely broad Mission, intended to allow any possible action
>     in an unknowable future, but a narrow mission, intended to guide, to
>     help make decisions which are choices, that can, as Bruce says, act
>     as a
>     meaningful criterion for review of decisions.
> 
>     Let us have the courage to believe we can build a strong consensus on a
>     meaningfully limited mission, not merely on narrow questions of
>     process.
>     If we can succeed in that, we can succeed in creating an ICANN that is
>     meaningfully accountable to the community on matters of essential
>     substance, not merely failures of process.
> 
>     Kind Regards,
> 
>     Malcolm.
> 
>     -- 
>     Malcolm Hutty | tel: +44 20 7645 3523
>     Head of Public Affairs | Read the LINX Public Affairs blog
>     London Internet Exchange | http://publicaffairs.linx.net/
> 
>     London Internet Exchange Ltd
>     21-27 St Thomas Street, London SE1 9RY
> 
>     Company Registered in England No. 3137929
>     Trinity Court, Trinity Street, Peterborough PE1 1DA
> 
> 
> 

-- 
            Malcolm Hutty | tel: +44 20 7645 3523
   Head of Public Affairs | Read the LINX Public Affairs blog
 London Internet Exchange | http://publicaffairs.linx.net/

                 London Internet Exchange Ltd
           21-27 St Thomas Street, London SE1 9RY

         Company Registered in England No. 3137929
       Trinity Court, Trinity Street, Peterborough PE1 1DA