<html>
<body>
Correct, a Bylaw alone is not sufficient. What is needed is a way to
ensure that if the Board does not follow its Bylaws, the community can
take action. Whether that means we can overturn a Board action or force
an action (in the case of inaction), remove part or all of the Board,
have clear standing to take them to court, or some other remedy or
combination of remedies is what we are here for.<br><br>
Alan<br><br>
At 31/01/2015 01:05 PM, Robin Gross wrote:<br>
<blockquote type=cite class=cite cite="">I think we'd need more than a
bylaw amendment because the problem is at the level of the
<u>enforcement</u> of the bylaws. For example Annex A in ICANN's
bylaws describes the way GNSO policy must be made in a bottom-up
fashion. The existence of the bylaws has not stopped the staff from
changing GNSO policy and the bylaws have not stopped the board from
looking the other way when staff does. We need those bylaws
enforced and it is the board's job to do that. <br><br>
So I do not believe a bylaw amendment on its own is sufficient to provide
the assurance that the bylaws will be enforced.<br><br>
Robin<br><br>
On Jan 30, 2015, at 7:37 PM, Paul Rosenzweig wrote:<br><br>
<blockquote type=cite class=cite cite=""><a name="_MailEndCompose"></a>I
agree Robin. So then what is your view on a Bylaw amendment as a
commitment with teeth/inevitability? Prior to this discussion, I
was of the view that changing the Bylaws was both a necessary and
sufficient condition to satisfy a WS1 requirement. Now I see that
we have at least one case scenario where a Bylaw mandate has gone
unexecuted for years, despite e.g<a name="_MailEndCompose"></a>. the
failure being called out in ATRT1 and ATRT2. This makes
me concerned that one could, hypothetically, change the Bylaws to require
our new membership organization, or the redress mechanism that is my own
focus, have the Bylaw passed and written in stone and still not see the
actual membership or redress change take effect because ICANN as an
institution slow-walks the change. This makes me want to consider
strongly whether our phrasing in WS1 of “implemented or committed to” is
too loose and ought not to be changed to “implemented” ….<br>
<br>
Paul<br>
<br>
<b>**NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 ***<br>
</b>509 C St. NE<br>
Washington, DC 20002<br>
<br>
Paul Rosenzweig<br>
<a href="mailto:paul.rosenzweigesq@redbranchconsulting.com">
paul.rosenzweig@redbranchconsulting.com</a><br>
O: +1 (202) 547-0660<br>
M: +1 (202) 329-9650<br>
Skype: +1 (202) 738-1739 or paul.rosenzweig1066<br>
<a href="http://www.redbranchconsulting.com/index.php?option=com_content&view=article&id=19&Itemid=9">
Link to my PGP Key</a><br>
<br>
<b>From:</b> Robin Gross
[<a href="mailto:robin@ipjustice.org" eudora="autourl">
mailto:robin@ipjustice.org</a>] <br>
<b>Sent:</b> Friday, January 30, 2015 4:19 PM<br>
<b>To:</b> Accountability Cross Community<br>
<b>Subject:</b> Re: [CCWG-ACCT] The big test of effective
accountability<br>
<br>
I interpret WS1 as those items for which more than mere promises have
been made to implement, but rather items where commitments that have some
teeth (or inevitability) are in place, such that they couldn't be left
lingering indefinitely.<br>
<br>
Robin<br>
<br>
On Jan 30, 2015, at 12:39 PM, David W. Maher wrote:<br><br>
<br>
<dl>
<dd>+1<br>
<dd>David W. Maher<br>
<dd>Senior Vice President – Law & Policy<br>
<dd>Public Interest Registry<br>
<dd>312 375 4849 <br>
<dd> <br>
<dd> <br>
<dd>From: </b>Jonathan Zuck
<<a href="mailto:JZuck@actonline.org">JZuck@actonline.org</a>><br>
<dd>Date: </b>Friday, January 30, 2015 2:30 PM<br>
<dd>To: </b>Paul Rosenzweig
<<a href="mailto:paul.rosenzweig@redbranchconsulting.com">
paul.rosenzweig@redbranchconsulting.com</a>>, "'McAuley,
David'"
<<a href="mailto:dmcauley@verisign.com">dmcauley@verisign.com</a>>,
'Accountability Cross Community'
<<a href="mailto:accountability-cross-community@icann.org">
accountability-cross-community@icann.org</a>><br>
<dd>Subject: </b>Re: [CCWG-ACCT] The big test of effective
accountability<br>
<dd> <br>
<dd>Indeed<br><br>
<dd>Sent from my Windows Phone<br>
<div align="center"><br>
</div>
<dd>From:
</b><a href="mailto:paul.rosenzweig@redbranchconsulting.com">Paul
Rosenzweig</a><br>
<dd>Sent: </b>1/30/2015 3:29 PM<br>
<dd>To: </b><a href="mailto:dmcauley@verisign.com">'McAuley, David'</a>;
<a href="mailto:accountability-cross-community@icann.org">'Accountability
Cross Community'</a><br>
<dd>Subject: </b>Re: [CCWG-ACCT] The big test of effective
accountability<br>
<dd>Thank you David for that explanation. To be candid it only
heightens my view that the accountability measures the community wants
need to be both committed to and actually implemented in place before the
IANA transition occurs.<br>
<dd> <br>
<dd>Paul<br>
<dd> <br>
<dd>**NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 ***<br>
</b>
<dd>509 C St. NE<br>
<dd>Washington, DC 20002<br>
<dd> <br>
<dd>Paul Rosenzweig<br>
<dd><a href="mailto:paul.rosenzweigesq@redbranchconsulting.com">
paul.rosenzweig@redbranchconsulting.com</a><br>
<dd>O: +1 (202) 547-0660<br>
<dd>M: +1 (202) 329-9650<br>
<dd>Skype: +1 (202) 738-1739 or paul.rosenzweig1066<br>
<dd>
<a href="http://www.redbranchconsulting.com/index.php?option=com_content&view=article&id=19&Itemid=9">
Link to my PGP Key</a><br>
<dd> <br>
<dd>From:</b> McAuley, David
[<a href="mailto:dmcauley@verisign.com">mailto:dmcauley@verisign.com</a>]
<br>
<dd>Sent:</b> Friday, January 30, 2015 1:42 PM<br>
<dd>To:</b> Paul Rosenzweig; 'Accountability Cross Community'<br>
<dd>Subject:</b> RE: [CCWG-ACCT] The big test of effective
accountability<br>
<dd> <br>
<dd>That is how the DCA Trust IRP panel seemed to see it, Paul.<br>
<dd> <br>
<dd>Bylaw Art. IV, Section 3.6 says this:<br>
<dd> <br>
<dd>There shall be an omnibus standing panel of between six and nine
members with a variety of expertise, including jurisprudence, judicial
experience, alternative dispute resolution and knowledge of ICANN's
mission and work from which each specific IRP Panel shall be selected.
The panelists shall serve for terms that are staggered to allow for
continued review of the size of the panel and the range of expertise. A
Chair of the standing panel shall be appointed for a term not to exceed
three years. Individuals holding an official position or office within
the ICANN structure are not eligible to serve on the standing panel. In
the event that an omnibus standing panel: (i) is not in place when an IRP
Panel must be convened for a given proceeding, the IRP proceeding will be
considered by a one- or three-member panel comprised in accordance with
the rules of the IRP Provider; or (ii) is in place but does not have the
requisite diversity of skill and experience needed for a particular
proceeding, the IRP Provider shall identify one or more panelists, as
required, from outside the omnibus standing panel to augment the panel
members for that proceeding.<br>
<dd> <br>
</i>
<dd>It is open to some interpretation because it instructs how to choose
a panel if a standing panel is not in place. A reasonable (to me)
interpretation of the provision is that the alternative way of selecting
a panel is for those cases prior to a standing panel being stood up. But
it has been years and the introductory language to the bylaw is: “There
shall be</i> …”<br>
<dd> <br>
<dd>Here is the full paragraph of what the DCA Trust IRP panel said in
the procedural ruling in August:<br>
<dd> <br>
<dd>114) The need for a compulsory remedy is concretely shown by ICANN’s
longstanding failure to implement the provision of the Bylaws and
Supplementary Procedures requiring the creation of a standing panel.
ICANN has offered no explanation for this failure, which evidences that a
self-policing regime at ICANN is insufficient. The failure to create a
standing panel has consequences, as this case shows, delaying the
processing of DCA Trust’s claim, and also prejudicing the interest of a
competing .AFRICA applicant.
</i>
(<a href="https://www.icann.org/en/system/files/files/irp-procedure-declaration-14aug14-en.pdf">
https://www.icann.org/en/system/files/files/irp-procedure-declaration-14aug14-en.pdf</a>
)<br>
<dd> <br>
</i>
<dd>To be fair, this was an interim ruling by a single panel and ICANN
would most assuredly not agree with this decision.<br>
<dd> <br>
<dd>To your question, regarding “failed to implement,” I would say failed
so far. I think Avri’s term “lingering” is a good one – this is lingering
so far.<br>
<dd> <br>
<dd>David<br>
<dd> <br>
<dd>From:</b> Paul Rosenzweig
[<a href="mailto:paul.rosenzweig@redbranchconsulting.com">
mailto:paul.rosenzweig@redbranchconsulting.com</a>] <br>
<dd>Sent:</b> Friday, January 30, 2015 11:45 AM<br>
<dd>To:</b> McAuley, David; 'Accountability Cross Community'<br>
<dd>Subject:</b> RE: [CCWG-ACCT] The big test of effective
accountability<br>
<dd> <br>
<dd>David<br>
<dd> <br>
<dd>Can you elaborate on this please? This is the first instance
I’ve read of in which it is said that ICANN failed to implement a Bylaw
mandate. Is that a fair description? Because if it is, that
suggests to me the possibility that even a Bylaw change might not be
adequate to satisfy accountability requirements until the bylaw as
actually implemented.<br>
<dd> <br>
<dd>Or am I misreading what you are saying?<br>
<dd>Paul<br>
<dd> <br>
<dd>**NOTE: OUR NEW ADDRESS -- EFFECTIVE 12/15/14 ***<br>
</b>
<dd>509 C St. NE<br>
<dd>Washington, DC 20002<br>
<dd> <br>
<dd>Paul Rosenzweig<br>
<dd><a href="mailto:paul.rosenzweigesq@redbranchconsulting.com">
paul.rosenzweig@redbranchconsulting.com</a><br>
<dd>O: +1 (202) 547-0660<br>
<dd>M: +1 (202) 329-9650<br>
<dd>Skype: +1 (202) 738-1739 or paul.rosenzweig1066<br>
<dd>
<a href="http://www.redbranchconsulting.com/index.php?option=com_content&view=article&id=19&Itemid=9">
Link to my PGP Key</a><br>
<dd> <br>
<dd>From:</b> McAuley, David
[<a href="mailto:dmcauley@verisign.com">mailto:dmcauley@verisign.com</a>]
<br>
<dd>Sent:</b> Friday, January 30, 2015 9:26 AM<br>
<dd>To:</b> Accountability Cross Community<br>
<dd>Subject:</b> Re: [CCWG-ACCT] The big test of effective
accountability<br>
<dd> <br>
<dd>Another thing that ICANN has let linger (and which is not a
recommendation but a bylaw) is the creation of a standing IRP panel that
would have “a variety of expertise, including jurisprudence, judicial
experience, alternative dispute resolution and knowledge of ICANN's
mission and work</i>” to populate panels on individual IRP cases.<br>
<dd> <br>
<dd>The panel in the (still ongoing) IRP case brought by DotConnectAfrica
(DCA) Trust over the handling of the new .africa TLD recognized that the
lack of a standing panel had an impact
(<a href="https://www.icann.org/en/system/files/files/irp-procedure-declaration-14aug14-en.pdf">
https://www.icann.org/en/system/files/files/irp-procedure-declaration-14aug14-en.pdf</a>
):<br>
<dd> <br>
<dd>“The failure to create a standing panel has consequences, as this
case shows, delaying the processing of DCA Trust’s claim, and also
prejudicing the interest of a competing .AFRICA applicant</i>.”<br>
<dd> <br>
<dd>David<br>
<dd> <br>
<dd>From:</b>
<a href="mailto:accountability-cross-community-bounces@icann.org">
accountability-cross-community-bounces@icann.org</a>
[<a href="mailto:accountability-cross-community-bounces@icann.org">
mailto:accountability-cross-community-bounces@icann.org</a>] On Behalf Of
</b>Avri Doria<br>
<dd>Sent:</b> Thursday, January 29, 2015 6:27 PM<br>
<dd>To:</b> Accountability Cross Community<br>
<dd>Subject:</b> Re: [CCWG-ACCT] The big test of effective
accountability<br>
<dd> <br><br>
<dd>Hi,<br><br>
<dd>And unfortunately they ignored the ASEP recommendations. The
ASEP was recommended by ATRT1, and its recommendations have been
recommend by ATRT2 for the committee working on Accountability it
recommended - ie. us.<br><br>
<dd>The fact that those recommendations lingered is indeed why we need
the binding bits.<br><br>
<dd>So often we come close, yet at the last minute we let something go
undone and the work gets lost.<br><br>
<dd>Stuff like this needs fixing.<br><br>
<dd>avri<br>
<dd>On 29-Jan-15 17:37, Kieren McCarthy wrote:<br>
<dl>
<dd>I don't like this line about the Reconsideration Committee not being
"understood", Chris.<br>
<dd> <br>
<dd>ICANN's staff and Board have developed the rules by which the
committee acts and the way in which it decides to apply those rules.
Those rules have also changed over time. <br>
<dd> <br>
<dd>This is part of the problem - ICANN corporate lives within its own
world half the time. I can recall several conversations I had with
ICANN's general counsel when on staff where he presented me with an
entirely different perspective on critical matters to the one that I and
much of the community felt existed. <br>
<dd> <br>
<dd>There is an internal body of belief that stands in stark contrast to
the outside view. And that body of belief is consciously shielded.<br>
<dd> <br>
<dd>If ICANN wants the Reconsideration Committee to stop being
misunderstood, it should rename it the "Policy Process
Double-checking Committee".<br>
<dd> <br>
<dd>Or, alternatively, and preferably, changing the functioning of the
committee to actually "reconsider" decisions. And include
people other than Board members (one of the accountability
recommendations made many years ago but never implemented).<br>
<dd> <br>
<dd> <br>
<dd> <br>
<dd>Kieren<br>
<dd> <br>
<dd> <br>
<dd> <br>
<dd>On Thu, Jan 29, 2015 at 1:59 PM, Chris Disspain
<<a href="mailto:ceo@auda.org.au">ceo@auda.org.au</a>> wrote:<br>
<dd>Agree Avri. And whilst the reconsideration request process is widely
pilloried it does, in fact, provide a level of accountability. It may not
be understood, it may not provide the sort of or level of accountability
that is desirable but, I for one, would want it to be improved/expanded
rather than see it disappear as in a [very] narrow band of cases it does
work.<br>
<dd> <br>
<dd> <br>
<dd>Cheers,<br>
<dd> <br>
<dd>Chris<br>
<dd> <br>
<dd>On 30 Jan 2015, at 08:34 , Avri Doria
<<a href="mailto:avri@acm.org">avri@acm.org</a>> wrote:<br>
<dd> <br><br>
<dd>Hi,<br><br>
<dd>I think Zero is a wee bit hyperbolic.<br><br>
<dd>I believe that the AOC does provide for accountability in the ATRT
reviews.<br><br>
<dd>We also vote on some Board seats and people have lost their
seats. <br>
<dd>Too slow and not as good as a recall procedure, but
accountabilty.<br><br>
<dd>Nomcom also does not always renew terms, <br>
<dd>even if the people want them too. <br>
<dd>That is also accountability.<br><br>
<dd>The IRT can also provide accountability. <br>
<dd>and does.<br><br>
<dd>It is true none of these bind the board, <br>
<dd>and that needs fixing, <br>
<dd>but I strongly disagree with the statement that there is no
accountability.<br><br>
<dd>Sure, none are as stringent as taking out <br>
<dd>and executing at dawn (I've been catching up on Marco Polo on
Netflix) <br>
<dd>but they are accountability, <br>
<dd>though of a lesser degree.<br><br>
<dd>avri<br>
<dd>On 29-Jan-15 14:14, Jonathan Zuck wrote:<br>
<dl>
<dd>Kieren,<br>
<dd>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</i>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.<br>
<dd>JZ<br>
<dd> <br>
<dd> <br>
<dd>From:</b> Kieren McCarthy
[<a href="mailto:kierenmccarthy@gmail.com">
mailto:kierenmccarthy@gmail.com</a>] <br>
<dd>Sent:</b> Thursday, January 29, 2015 1:57 PM<br>
<dd>To:</b> McAuley, David<br>
<dd>Cc:</b> Jonathan Zuck; Accountability Cross Community<br>
<dd>Subject:</b> Re: [CCWG-ACCT] The big test of effective
accountability<br>
<dd> <br>
<dd>One more thing from me and then I'll shut up.<br>
<dd> <br>
<dd>I'd be interested to hear from people that have actually gone through
the various accountability mechanisms what they thought of the
experience. <br>
<dd> <br>
<dd>For example:<br>
<dd> <br>
<dd>* Were you happy with the process?<br>
<dd>* Were you happy with the outcome?<br>
<dd>* Did you feel your points were understand and considered?<br>
<dd>* What would have improved the process for you?<br>
<dd>* If you lost, why did you not progress further in the appeal
process?<br>
<dd> <br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd> <br>
<dd> <br>
<dd>Kieren<br>
<dd> <br>
<dd> <br>
<dd> <br>
<dd> <br>
<dd>On Thu, Jan 29, 2015 at 9:58 AM, McAuley, David
<<a href="mailto:dmcauley@verisign.com">dmcauley@verisign.com</a>>
wrote:<br>
<dl>
<dd>Hi Kieran,<br>
<dd> <br>
<dd>Thank you for this human-element discussion, most interesting and
helpful for me.<br>
<dd> <br>
<dd>I differ with one remark you made in the last post: “yes, the Board
can be overruled but only on issues of process</i>.”<br>
<dd> <br>
<dd>It’s actually not all that positive, if I have things correctly
concerning accountability measures within the ICANN environment (not
addressing courts here).<br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd>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. .<br>
<dd> <br>
<dd>David McAuley<br>
<dd>From:</b>
<a href="mailto:accountability-cross-community-bounces@icann.org">
accountability-cross-community-bounces@icann.org</a>
[mailto:<a href="mailto:accountability-cross-community-bounces@icann.org">
accountability-cross-community-bounces@icann.org</a>] On Behalf Of
</b>Kieren McCarthy<br>
<dd>Sent:</b> Thursday, January 29, 2015 11:17 AM<br>
<dd>To:</b> Jonathan Zuck<br><br>
<dd>Cc:</b> Accountability Cross Community<br>
<dd>Subject:</b> Re: [CCWG-ACCT] The big test of effective
accountability<br>
<dd> <br>
<dd>Quick thoughts on this: <br>
<dd> <br>
<dd>Yes, what the staff and Board end up doing is partly the community's
fault.<br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd>Just one example: yes, the Board can be overruled but only on issues
of process. <br>
<dd> <br>
<dd>This just creates one more layer and process that ICANN will hold up
as accountability and the community will be completely dissatisfied
with.<br>
<dd> <br>
<dd>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. <br>
<dd> <br>
<dd>And this is the big change we introduce this time around.<br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd> <br>
<dd>Kieren<br><br>
<dd>-<br>
<dd>[sent through phone]<br>
<dd> <br>
<dd>On Thu, Jan 29, 2015 at 7:35 AM, Jonathan Zuck
<<a href="mailto:JZuck@actonline.org">JZuck@actonline.org</a>>
wrote:<br>
<dl>
<dd>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.<br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd>All that said, it’s not really relevant to the task at hand.
Obviously this whole situation has us
“<a href="http://en.wikipedia.org/wiki/Omphaloskepsis">navel gazing</a>,”
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.<br>
<dd> <br>
<dd>My two cents<br>
<dd> <br>
<dd>Jonathan<br>
<dd> <br>
<dd> <br>
<dd> <br>
<dd> <br>
<dd>From:</b>
<a href="mailto:accountability-cross-community-bounces@icann.org">
accountability-cross-community-bounces@icann.org</a>
[<a href="mailto:accountability-cross-community-bounces@icann.org">
mailto:accountability-cross-community-bounces@icann.org</a>] On Behalf Of
</b>Kieren McCarthy<br>
<dd>Sent:</b> Thursday, January 29, 2015 9:39 AM<br>
<dd>To:</b> Malcolm Hutty<br>
<dd>Cc:</b> Accountability Cross Community<br>
<dd>Subject:</b> Re: [CCWG-ACCT] The big test of effective
accountability<br>
<dd> <br>
<dd>Like this. Excellent food for thought. <br>
<dd> <br>
<dd>Will dig out Steve's mission email - had completely missed it. You
have the email header handy?<br>
<dd> <br>
<dd> <br>
<dd>Kieren<br><br>
<dd>-<br>
<dd>[sent through phone]<br>
<dd> <br>
<dd>On Thu, Jan 29, 2015 at 6:00 AM, Malcolm Hutty
<<a href="mailto:malcolm@linx.net">malcolm@linx.net</a>>
wrote:<br>
<dl><br><br>
<dd>On 29/01/2015 11:45, Bruce Tonkin wrote: <br>
<dd>> In terms of reviewing the new gTLD program <br><br>
<dd>Kieren may correct me, but I read his essay as being about more than
<br>
<dd>just the gTLD program alone, albeit that that was the example given.
I <br>
<dd>read it as a general complaint that ICANN tends to be to formalistic,
<br>
<dd>and loses sight of the substance of the issue, not only in gTLD <br>
<dd>applications, but often. And I think that he's far from alone in that
<br>
<dd>view, especially amongst those who engage with ICANN peripherally
rather <br>
<dd>than intensively. <br><br>
<dd>> I compare this to a jury process in the legal system. I don’t
think <br>
<dd>> you can just ask for another jury to hear the case when the
first <br>
<dd>> jury finds against you. There needs to be some basis for the
appeal <br>
<dd>> other than that you disagree with the initial finding. <br>
<dd>[...] <br>
<dd>> So careful work is needed to ensure that we have a process that
<br>
<dd>> ensures independent reviews of decisions, and also appropriate
<br>
<dd>> criteria to initiate a review of a decision. <br><br>
<dd>There I think you get to the heart of the matter. <br><br>
<dd>Kieren's complaint about formalism is interesting insofar as it goes,
<br>
<dd>and I think it is a very useful contribution, but it is only
identifies <br>
<dd>a problem, it doesn't analyse it or propose a solution. I would like
to <br>
<dd>try to work from where Kieren left off. <br><br>
<dd>Kieren, you're a journalist. You live and breathe five-Ws and an H.
<br>
<dd>Let's apply that here. <br><br>
<dd>WHAT's the problem? (Excessive legal formalism, resulting in loss of
<br>
<dd>sight of the substance of the question). <br><br>
<dd>WHY do we have that problem? <br><br>
<dd>WHO caused it and who can address that? <br><br>
<dd>HOW should it be addressed? <br><br>
<dd>(OK, I'm leaving out "when". Cut me some slack.) <br><br>
<br>
<dd>WHY do we have the excessive legalistic formalism Kieren complains
about? <br><br>
<dd>To some extent, this is characteristic of all large bureaucracies.
They <br>
<dd>are instinctively defensive, and any individual within them wants to
<br>
<dd>show that they discharged their own responsibilities properly even -
<br>
<dd>perhaps especially - when they don't, as an individual, necessarily
<br>
<dd>agree personally with the organisation position. <br><br>
<dd>But Kieren suggests that ICANN is particularly susceptible to this
<br>
<dd>tendency, and I think I agree. An organisation with a highly
empowered <br>
<dd>single leader (think Apple under Steve Jobs) can cut through process
<br>
<dd>easily. I imagine an early conversation at Apple going like this:
<br><br>
<dd>Product Manager: We assembled focus groups in all our major target
<br>
<dd>markets to identify the key characteristics of a <br>
<dd>revolutionary, magical new phone. We planted the best <br>
<dd>UI theorists in those groups, to guide them towards <br>
<dd>characteristics and away from mere features. We then <br>
<dd>tested the output with surveys from the best polling <br>
<dd>companies, scientifically designed to ensure all user <br>
<dd>groups had balanced representation. Using their <br>
<dd>answers we ranked and prioritised development goals. <br>
<dd>We hired the best and brightest designers to deliver <br>
<dd>against that design brief, and I proudly present, <br>
<dd>the You-Phone. <br><br>
<dd>Steve Jobs: The user experience sucks and it feels like it was <br>
<dd>designed by a committee. Go back and start again. <br><br>
<br>
<dd>Would we want ICANN to work like this? No! We'd be rightly terrified
of <br>
<dd>leaving that much power in one person's hands. We want ICANN to be
run <br>
<dd>by the community, with the Board acting as an arm of the community
<br>
<dd>conducting executive oversight, not ruled by any single Global King
of DNS. <br><br>
<dd>So we create structures designed to ensure that everybody's voice is
<br>
<dd>heard and that everybody's interests are taken into account, that
<br>
<dd>competing positions are balanced as fairly as it is possible to be,
and <br>
<dd>that decisions are demonstrably rationally arrived at on the basis of
<br>
<dd>previously agreed consensus policy. And we create more structures to
<br>
<dd>appeal cases to on the basis that any of those things failed in this
<br>
<dd>instance. <br><br>
<dd>And we end up with the legalistic formalism of which Kieren speaks.
<br><br>
<dd>Why? <br><br>
<dd>I suggest that it is because we have such a diverse community, and so
<br>
<dd>the only thing we agree on is the process criteria. We agree that
<br>
<dd>everybody should be heard. We agree that there should be periods of
<br>
<dd>public comment, and then further periods of reply comment. We agree
that <br>
<dd>policy should require consensus support. But we're so anxious that
that <br>
<dd>might be the only thing we agree on that we stop there. And so when a
<br>
<dd>decision looks bad, the only thing we have to fall back on is an
appeal <br>
<dd>to process. <br><br>
<dd>And mostly the process was followed (at least in a narrow sense) so
it's <br>
<dd>very hard to reverse the decision, even if you might like to (as
Bruce <br>
<dd>has described). And the dissatisfied party becomes embroiled in an
<br>
<dd>increasingly embittered proxy fight with an increasingly defensive
<br>
<dd>bureaucracy, when everybody knows that the gravamen of the complaint
<br>
<dd>isn't really about process at all, it is, as Kieren says, about the
<br>
<dd>substance. <br><br>
<dd>Some would say this means we need to "unshackle" the Board,
to give them <br>
<dd>a wide-ranging and broad discretion to "do the right
thing", or <br>
<dd>sometimes "to take decision based in the public interest".
Removing or <br>
<dd>reducing external constraints would enable "effective
leadership" and <br>
<dd>give the Board "flexibility to respond to a changing world"
without <br>
<dd>being "buried in legal challenges". <br><br>
<dd>I consider such an approach to be a trap. Those arguments are the
same <br>
<dd>arguments one would make if an avowed enemy of community
accountability. <br>
<dd>Following such recommendations will lead inevitably to a Board with a
<br>
<dd>top-down, paternalistic view of governing the community at best, if
not <br>
<dd>something even worse. <br><br>
<dd>Instead, let us look to other I* communities, which do not seem to
have <br>
<dd>the same problem, to see how the IETF and the RIRs maintain genuine
<br>
<dd>bottom-up community governance, and at the same time remain focused
on <br>
<dd>the substance. <br><br>
<dd>Let me tell a story about how one of the RIRs recently dealt with a
<br>
<dd>potentially difficult problem. <br>
<br>
<dd>Towards the end of last year, on the mailing list for the RIPE NCC, a
<br>
<dd>Ukrainian who seemed to be a partisan of the government in Kiev, and
an <br>
<dd>opponent of the regime in Crimea and Donetsk, raised a point about
the <br>
<dd>rules. RIPE NCC rules say that organisations applying from IP
addresses <br>
<dd>must supply government issued ID, he said. Why does the RIPE NCC
<br>
<dd>continue to serve users in Crimea? Does the RIPE NCC accept the
validity <br>
<dd>of the Donetsk regime? On what basis and with what justification?
Surely <br>
<dd>the only proper course is for the RIPE NCC to cease to support <br>
<dd>organisations in Crimea until the legitimately recognised government
of <br>
<dd>Ukraine is restored in the region (I am using his voice, you
understand, <br>
<dd>not my own, but this is a paraphrase, not a direct quote). <br><br>
<dd>The RIPE community immediately saw this intervention for what it was
in <br>
<dd>substance: an attempt to embroil the RIPE NCC in the ongoing regional
<br>
<dd>conflict, on the side to which he was partisan. It was not really a
<br>
<dd>genuine enquiry about the rules, it was an attempt to force a
legalistic <br>
<dd>interpretation that would subvert their intended substance. <br><br>
<dd>And the RIPE community responded swiftly, vocally, and overwhelmingly
of <br>
<dd>one view. The mission of RIPE NCC is to support users by helping to
<br>
<dd>coordinate the distribution of IP addresses to those that need them.
<br>
<dd>Networks in Crimea need IP addresses. This does not change because
the <br>
<dd>legitimacy of the claimed government with effective control of the
<br>
<dd>region is disputed. Many members of the RIPE Community had
considerable <br>
<dd>sympathy with the Ukrainian partisan, and deep personal opposition to
<br>
<dd>Russian intervention in Eastern Ukraine. Nonetheless, they agreed on
one <br>
<dd>thing: the geopolitics of the Ukraine is not the responsibility of
the <br>
<dd>RIPE NCC. The rule requiring government issued ID is there to support
<br>
<dd>RIPE NCC's mission to coordination IP address distribution so that
<br>
<dd>networks are allocated the address space they require (so that RIPE
NCC <br>
<dd>can identify the entities to which it has made allocations); to apply
<br>
<dd>the same rule to prevent IP address block allocation would be to
subvert <br>
<dd>the mission. While there is no universally recognised government in
<br>
<dd>Eastern Ukraine, the RIPE NCC should accept such ID from entities in
<br>
<dd>that area as they are reasonably able to provide. <br><br>
<dd>This story, I think, exemplifies the ability to cut to the substance
of <br>
<dd>the issue that Kieren seeks. How is it arrived at? Not by the <br>
<dd>introduction of any strong central leader: the NCC staff and Board
was <br>
<dd>almost silent while this discussion played out amongst the community.
<br>
<dd>It was arrived at because the community had a strongly unified sense
of <br>
<dd>its own limited mission (to support the distribution of IP addresses
to <br>
<dd>those that need them, through coordinated allocation policies) and
the <br>
<dd>members of that community were overwhelmingly willing to set aside
their <br>
<dd>own views on a matter outside the scope of that mission when it was
<br>
<dd>suggested that some other reasoning requires an effect fundamentally
<br>
<dd>contrary to the mission. We will not have an argument about whether
RIPE <br>
<dd>NCC should act to /limit/ the allocation of IP addresses to entities
in <br>
<dd>Crimea, not even dressed in the coat of a rules interpretation. Maybe
<br>
<dd>action should be taken against the regime in Crimea - but not by RIPE
<br>
<dd>NCC. RIPE NCC will discharge its own mission, and leave the
geopolitics <br>
<dd>to others. <br><br>
<dd>Is this not the same culture we want to inculcate in ICANN? <br><br>
<dd>I believe that story exemplifies the strength of the RIRs, and
describes <br>
<dd>exactly what we want from ICANN too. <br><br>
<dd>And it is very far from the ICANN Kieren describes. <br><br>
<dd>WHO can bring this change about? <br><br>
<dd>Only us. <br><br>
<dd>When we look to Kieren's complaint, and see how far short ICANN falls
of <br>
<dd>the strong culture shows by the RIRs and the IETF, the
"fault" lies with <br>
<dd>us, the community. We don't *want* the Board, or the CEO, or the
staff <br>
<dd>to come up with a dramatically developed version of the ICANN Mission
<br>
<dd>that will then overrule existing processes and policies. <br>
<dd>The Mission must be developed by, and founded in, the community
itself. <br><br>
<dd>What we need is for the community to develop a much clearer idea of
the <br>
<dd>Mission, and an exposition of what that means and how it is to be
<br>
<dd>applied. Then all the accountability structures we create, the Review
<br>
<dd>Boards and Reconsideration Panels and Ombudsmen and the rest, they
will <br>
<dd>have a proper standard for review. Not a sterile standard that looks
<br>
<dd>only to bare process, but one that asks "Is this consistent with
the <br>
<dd>fundamental mission?" <br><br>
<dd>Consider how this might work in practice. <br><br>
<dd>For .gay, there are many objections one might make. One might say the
<br>
<dd>proposed registrar was not suitable - but that should only lead to
the <br>
<dd>selection of an alternative, or the imposition of tighter control,
not <br>
<dd>to refusal to delegate. If you're not confident in the registrar you
<br>
<dd>might impose behavioural controls (e.g. to prevent limitation of
supply) <br>
<dd>or structural controls (e.g. a shorter contract, to require
renunciation <br>
<dd>of any presumption of renewal of the registry contract etc) or some
<br>
<dd>combination of the two. There will be plenty of room for arguments
about <br>
<dd>the best way to proceed. <br><br>
<dd>But arguments that resolve to (or are recognisable as a mere pretext
<br>
<dd>for) the claim that .gay ought not to exist can be dismissed: ICANN's
<br>
<dd>mission is to make domains available, not to prevent their
availability. <br><br>
<dd>I promised a HOW. <br><br>
<dd>Here is HOW I think we should proceed. <br><br>
<dd>In our Frankfurt face-to-face we constructed, yet again, a map of
<br>
<dd>possible new structures, and most of the focus went on that. But
there <br>
<dd>was also a slot on it for the question of clarifying the mission, as
the <br>
<dd>basis for review. A few weeks ago, on this list, Steve DelBianco made
a <br>
<dd>very valuable start, suggesting a new codification of the mission.
That <br>
<dd>contribution has passed almost without notice. <br><br>
<dd>I don't necessarily think Steve's formulation is perfect, but it's a
lot <br>
<dd>better than anything else I've yet seen, and it has the virtue of
being <br>
<dd>a contribution on this critical subject, almost alone. Let us work
<br>
<dd>together on that, to build that common shared sense of Mission. <br>
<dd>Not an infinitely broad Mission, intended to allow any possible
action <br>
<dd>in an unknowable future, but a narrow mission, intended to guide, to
<br>
<dd>help make decisions which are choices, that can, as Bruce says, act
as a <br>
<dd>meaningful criterion for review of decisions. <br><br>
<dd>Let us have the courage to believe we can build a strong consensus on
a <br>
<dd>meaningfully limited mission, not merely on narrow questions of
process. <br>
<dd>If we can succeed in that, we can succeed in creating an ICANN that
is <br>
<dd>meaningfully accountable to the community on matters of essential
<br>
<dd>substance, not merely failures of process. <br><br>
<dd>Kind Regards, <br><br>
<dd>Malcolm. <br><br>
<dd>-- <br>
<dd>Malcolm Hutty | tel:
<a href="x-msg://520/tel:%2B44%2020%207645%203523">+44 20 7645
3523</a><br>
<dd>Head of Public Affairs | Read the LINX Public Affairs blog <br>
<dd>London Internet Exchange |
<a href="http://publicaffairs.linx.net/">
http://publicaffairs.linx.net/</a> <br><br>
<dd>London Internet Exchange Ltd <br>
<dd>21-27 St Thomas Street, London SE1 9RY <br><br>
<dd>Company Registered in England No. 3137929 <br>
<dd>Trinity Court, Trinity Street, Peterborough PE1 1DA<br><br>
</dl>
<dd> <br><br>
</dl>
<dd> <br><br>
</dl>
<dd> <br>
<dd> <br><br>
<dd><pre>_______________________________________________</pre><br><br>
<dd><pre>Accountability-Cross-Community mailing list</pre><br><br>
<dd><pre><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a></pre><br><br>
<dd><pre>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</pre><br>
</dl>
<dd> <br>
<dd>_______________________________________________<br>
<dd>Accountability-Cross-Community mailing list<br>
<dd><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
<br>
<dd> <br><br>
<br>
<dd>_______________________________________________<br>
<dd>Accountability-Cross-Community mailing list<br>
<dd><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
<br>
<dd> <br><br>
</dl>
<dd> <br>
<dd>_______________________________________________<br>
<dd>Accountability-Cross-Community mailing list<br>
<dd><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
<br><br>
</dl> </blockquote><br><br>
_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
Accountability-Cross-Community@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote></body>
</html>