[CCWG-ACCT] The big test of effective accountability

Kieren McCarthy kierenmccarthy at gmail.com
Thu Jan 29 14:38:32 UTC 2015


Like this. Excellent food for thought. 


Will dig out Steve's mission email - had completely missed it. You have the email header handy?





Kieren




-
[sent through phone]

On Thu, Jan 29, 2015 at 6:00 AM, Malcolm Hutty <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150129/bba8e514/attachment.html>


More information about the Accountability-Cross-Community mailing list