[CCWG-ACCT] The big test of effective accountability
Avri Doria
avri at acm.org
Thu Jan 29 21:34:33 UTC 2015
Hi,
I think Zero is a wee bit hyperbolic.
I believe that the AOC does provide for accountability in the ATRT reviews.
We also vote on some Board seats and people have lost their seats.
Too slow and not as good as a recall procedure, but accountabilty.
Nomcom also does not always renew terms,
even if the people want them too.
That is also accountability.
The IRT can also provide accountability.
and does.
It is true none of these bind the board,
and that needs fixing,
but I strongly disagree with the statement that there is no accountability.
Sure, none are as stringent as taking out
and executing at dawn (I've been catching up on Marco Polo on Netflix)
but they are accountability,
though of a lesser degree.
avri
On 29-Jan-15 14:14, Jonathan Zuck wrote:
>
> Kieren,
>
> That hard truth here is that while we endeavor to list existing
> “accountability” mechanisms, there are, in fact, none. It’s a complete
> red herring to explore them as part of this process. There are plenty
> of opportunities to “vent” but there are, in fact, ZERO accountability
> mechanisms in place, with the exception often cited but ridiculous
> “elect a different board.” No one wants to hear that but it’s the
> truth. Our goal here, in the near term is essentially to create ONE
> mechanism of accountability in place, perhaps two. It is my sincere
> belief that the presence of even a /single/ accountability mechanism
> will go a long way to change the culture inside ICANN because the net
> result will be to turn the light back on the community to reach
> consensus. This is a GROSS oversimplification, not meant to inspire
> nit picking but a return to the task at hand which is to create a
> framework for reform which, if the community remains motivated, will
> allow major cultural changes to take place.
>
> JZ
>
>
>
>
>
> *From:*Kieren McCarthy [mailto:kierenmccarthy at gmail.com]
> *Sent:* Thursday, January 29, 2015 1:57 PM
> *To:* McAuley, David
> *Cc:* Jonathan Zuck; Accountability Cross Community
> *Subject:* Re: [CCWG-ACCT] The big test of effective accountability
>
>
>
> One more thing from me and then I'll shut up.
>
>
>
> I'd be interested to hear from people that have actually gone through
> the various accountability mechanisms what they thought of the
> experience.
>
>
>
> For example:
>
>
>
> * Were you happy with the process?
>
> * Were you happy with the outcome?
>
> * Did you feel your points were understand and considered?
>
> * What would have improved the process for you?
>
> * If you lost, why did you not progress further in the appeal process?
>
>
>
>
>
> This kind of feedback should be being done by ICANN itself but I'm
> willing to bet it hasn't been. It's also not that hard to do: their
> names are publicly available. ICANN has all their contact details. I
> bet many of them would be happy to talk.
>
>
>
>
>
>
>
> Kieren
>
>
>
>
>
>
>
>
>
> On Thu, Jan 29, 2015 at 9:58 AM, McAuley, David <dmcauley at verisign.com
> <mailto:dmcauley at verisign.com>> wrote:
>
> Hi Kieran,
>
>
>
> Thank you for this human-element discussion, most interesting and
> helpful for me.
>
>
>
> I differ with one remark you made in the last post: “/yes, the
> Board can be overruled but only on issues of process/.”
>
>
>
> It’s actually not all that positive, if I have things correctly
> concerning accountability measures within the ICANN environment
> (not addressing courts here).
>
>
>
> At present the board can be overruled in reconsideration requests
> – but only by the board itself on, as you say, process issues.
> This probably does not meet any realistic, objective
> accountability standard.
>
>
>
> In IRP before independent panels, the board can take the panel’s
> decision or leave it – it is nothing more than a recommendation,
> again on process-based issues.
>
>
>
> The IRP panel in the DotConnectAfrica (DCA) Trust case ruled that
> it could bind ICANN in a procedural ruling this past year, but
> ICANN’s subsequent arguments before the same panel as well as
> other IRP panels indicate that it does not accept that decision.
> It could be interesting to see what ICANN does with the eventual
> final ruling in the case, depending on whether the panel rules in
> DCA’s favor. .
>
>
>
> David McAuley
>
> *From:*accountability-cross-community-bounces at icann.org
> <mailto:accountability-cross-community-bounces at icann.org>
> [mailto:accountability-cross-community-bounces at icann.org
> <mailto:accountability-cross-community-bounces at icann.org>] *On
> Behalf Of *Kieren McCarthy
> *Sent:* Thursday, January 29, 2015 11:17 AM
> *To:* Jonathan Zuck
>
>
> *Cc:* Accountability Cross Community
> *Subject:* Re: [CCWG-ACCT] The big test of effective accountability
>
>
>
> Quick thoughts on this:
>
>
>
> Yes, what the staff and Board end up doing is partly the
> community's fault.
>
>
>
> Where I do place fault is in both continuing to do so, and failing
> to make changes despite clear signs that it is not working
> effectively and is even damaging trust.
>
>
>
> The Board seem confused and frustrated that they continue to be
> yelled at. The community can't believe that the Board still hasn't
> heard them. I think the gap is the lack of human judgement and the
> priority of process and legal argument.
>
>
>
> I am a big fan of solid changes over long discourse. But what I
> started to see on this group was a tendency toward process
> solutions and legal-style decision making.
>
>
>
> Just one example: yes, the Board can be overruled but only on
> issues of process.
>
>
>
> This just creates one more layer and process that ICANN will hold
> up as accountability and the community will be completely
> dissatisfied with.
>
>
>
> ICANN's staff will defend to the hilt the Board's initial
> decision, creating a fight and tension, limiting discussion and
> sharing of information, increasing distrust, reinforcing the
> barrier between Corporate and community.
>
>
>
> And this is the big change we introduce this time around.
>
>
>
> My fear is that unless we break that habit, there will be another
> 10 years of dissatisfaction and another group like this one trying
> again to bring 'accountability' in 2025.
>
>
>
>
>
> Kieren
>
>
> -
> [sent through phone]
>
>
>
> On Thu, Jan 29, 2015 at 7:35 AM, Jonathan Zuck
> <JZuck at actonline.org <mailto:JZuck at actonline.org>> wrote:
>
> I’m somewhat hesitant to speak up given Malcolm’s excellent
> treatise but a few things spring to mind. The first and
> simplest is that process still provides a structure the
> re-humanization you seek. In a large organization if there
> isn’t a way to trigger the group “rethinking” an issue, it
> will never happen. I believe that while this conversation is
> emotionally rewarding, we need to be very careful to stay
> inside our remit to come up with some very specific
> recommendations for increasing accountability (in a legal
> sense) to replace the somewhat “legal” accountability that
> exists today so my first inclination is to table this
> discussion and get back to work.
>
>
>
> My second inclination is to dive in <g> and to come to the
> defense of the board and ICANN staff a little bit. The buzzing
> in the back of my head for the past year or so is that the
> “community” is partially to blame for the environment in which
> we find ourselves. ICANN is afraid of litigation because we
> are litigious. The board does our job for us often because we
> have failed to do it ourselves.
>
>
>
> If the result of a policy development process is a failure to
> find consensus, to compromise, to be “human” as you suggest
> Kieren, the board is faced with the unenviable task of playing
> Solomon because the community have essentially abdicated our
> responsibility. The boards entire job is supposed to ONLY be
> about process and whether we’ve followed it. Instead, we
> present the board with unfinished work, expect them to “rule”
> on it and threaten to sue if we don’t get our way. If the
> board is guilty of anything in this context, it is their
> willingness to accept this challenge, which I suggest is
> dehumanizing because, like Solomon, they are not in the best
> position to find a solution and often create arbitrary
> compromise which is the number one characteristic of an
> arbitration environment. More often than not, the board should
> simply reject the unfinished work and send it back to the
> community to get it done right. So I think there’s a lot to
> Kieren’s concern but I think the community plays a significant
> role in the problem and must therefore play a significant role
> in the solution and I’m ready for us to tackle it.
>
>
>
> All that said, it’s not really relevant to the task at hand.
> Obviously this whole situation has us “navel gazing
> <http://en.wikipedia.org/wiki/Omphaloskepsis>,” and that’s not
> all bad but we do have a very specific task to accomplish in
> the here and now and we would do well to focus on that alone,
> at least for the time being.
>
>
>
> My two cents
>
>
>
> Jonathan
>
>
>
>
>
>
>
>
>
> *From:*accountability-cross-community-bounces at icann.org
> <mailto:accountability-cross-community-bounces at icann.org>
> [mailto:accountability-cross-community-bounces at icann.org] *On
> Behalf Of *Kieren McCarthy
> *Sent:* Thursday, January 29, 2015 9:39 AM
> *To:* Malcolm Hutty
> *Cc:* Accountability Cross Community
> *Subject:* Re: [CCWG-ACCT] The big test of effective
> accountability
>
>
>
> 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 <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
> <tel:%2B44%2020%207645%203523>
> Head of Public Affairs | Read the LINX Public Affairs blog
> London Internet Exchange | http://publicaffairs.linx.net/
> <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
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150129/c04637d6/attachment.html>
More information about the Accountability-Cross-Community
mailing list