<div dir="ltr">I don't like this line about the Reconsideration Committee not being "understood", Chris.<div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>There is an internal body of belief that stands in stark contrast to the outside view. And that body of belief is consciously shielded.</div><div><br></div><div>If ICANN wants the Reconsideration Committee to stop being misunderstood, it should rename it the "Policy Process Double-checking Committee".</div><div><br></div><div>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).</div><div><br></div><div><br></div><div><br></div><div>Kieren</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 1:59 PM, Chris Disspain <span dir="ltr"><<a href="mailto:ceo@auda.org.au" target="_blank">ceo@auda.org.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span style="font-family:'Verdana';font-size:13px;color:rgb(102,102,102)">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.<div><br><div>
<p><br></p>
<p>Cheers,</p>
<p><br></p>
<p>Chris</p>
</div><div><div class="h5">
<br><div><div>On 30 Jan 2015, at 08:34 , Avri Doria <<a href="mailto:avri@acm.org" target="_blank">avri@acm.org</a>> wrote:</div><br><blockquote type="cite">
<div bgcolor="#FFFFFF" text="#330033">
Hi,<br>
<br>
I think Zero is a wee bit hyperbolic.<br>
<br>
I believe that the AOC does provide for accountability in the ATRT
reviews.<br>
<br>
We also vote on some Board seats and people have lost their seats.
<br>
Too slow and not as good as a recall procedure, but accountabilty.<br>
<br>
Nomcom also does not always renew terms, <br>
even if the people want them too. <br>
That is also accountability.<br>
<br>
The IRT can also provide accountability. <br>
and does.<br>
<br>
It is true none of these bind the board, <br>
and that needs fixing, <br>
but I strongly disagree with the statement that there is no
accountability.<br>
<br>
Sure, none are as stringent as taking out <br>
and executing at dawn (I've been catching up on Marco Polo on
Netflix) <br>
but they are accountability, <br>
though of a lesser degree.<br>
<br>
avri<br>
<br>
<br>
<div>On 29-Jan-15 14:14, Jonathan Zuck
wrote:<br>
</div>
<blockquote type="cite">
<div><p class="MsoNormal"><span>Kieren,</span></p><p class="MsoNormal"><span>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
<i>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.</span></p><p class="MsoNormal"><span>JZ</span></p><div><span> </span><br></div><div><span> </span><br></div><p class="MsoNormal"><b>From:</b><span> Kieren
McCarthy [<a href="mailto:kierenmccarthy@gmail.com" target="_blank">mailto:kierenmccarthy@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, January 29, 2015 1:57 PM<br>
<b>To:</b> McAuley, David<br>
<b>Cc:</b> Jonathan Zuck; Accountability Cross Community<br>
<b>Subject:</b> Re: [CCWG-ACCT] The big test of effective
accountability</span></p><div> <br></div>
<div><p class="MsoNormal">One more thing from me and then I'll shut
up.</p>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">I'd be interested to hear from people
that have actually gone through the various accountability
mechanisms what they thought of the experience. </p>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">For example:</p>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">* Were you happy with the process?</p>
</div>
<div><p class="MsoNormal">* Were you happy with the outcome?</p>
</div>
<div><p class="MsoNormal">* Did you feel your points were
understand and considered?</p>
</div>
<div><p class="MsoNormal">* What would have improved the process
for you?</p>
</div>
<div><p class="MsoNormal">* If you lost, why did you not progress
further in the appeal process?</p>
</div>
<div><div> <br></div>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">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.</p>
</div>
<div><div> <br></div>
</div>
<div><div> <br></div>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">Kieren</p>
</div>
<div><div> <br></div>
</div>
<div><div> <br></div>
</div>
<div><div> <br></div>
</div>
</div>
<div><div> <br></div>
<div><p class="MsoNormal">On Thu, Jan 29, 2015 at 9:58 AM,
McAuley, David <<a href="mailto:dmcauley@verisign.com" target="_blank">dmcauley@verisign.com</a>>
wrote:</p>
<blockquote>
<div>
<div><p class="MsoNormal">Hi Kieran,</p><div> <br></div><p class="MsoNormal">Thank you for this human-element
discussion, most interesting and helpful for me.
</p><div> <br></div><p class="MsoNormal">I differ with one remark you made
in the last post: “<i>yes, the Board can be
overruled but only on issues of process</i>.”</p><div> <br></div><p class="MsoNormal">It’s actually not all that
positive, if I have things correctly concerning
accountability measures within the ICANN environment
(not addressing courts here).</p><div> <br></div><p class="MsoNormal">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. </p><div> <br></div><p class="MsoNormal">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.</p><div> <br></div><p class="MsoNormal">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. .
</p><div> <br></div><p class="MsoNormal">David McAuley</p><p class="MsoNormal"><b>From:</b><span>
<a href="mailto:accountability-cross-community-bounces@icann.org" target="_blank">
accountability-cross-community-bounces@icann.org</a>
[mailto:<a href="mailto:accountability-cross-community-bounces@icann.org" target="_blank">accountability-cross-community-bounces@icann.org</a>]
<b>On Behalf Of </b>Kieren McCarthy<br>
<b>Sent:</b> Thursday, January 29, 2015 11:17 AM<br>
<b>To:</b> Jonathan Zuck</span></p>
<div>
<div><p class="MsoNormal"><br>
<b>Cc:</b> Accountability Cross Community<br>
<b>Subject:</b> Re: [CCWG-ACCT] The big test of
effective accountability</p>
</div>
</div>
<div>
<div><div> <br></div><p class="MsoNormal">Quick thoughts on this: </p>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">Yes, what the staff and
Board end up doing is partly the community's
fault.</p>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">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.</p>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">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.</p>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">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.</p>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">Just one example: yes, the
Board can be overruled but only on issues of
process. </p>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">This just creates one more
layer and process that ICANN will hold up as
accountability and the community will be
completely dissatisfied with.</p>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">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. </p>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">And this is the big change
we introduce this time around.</p>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">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.</p>
</div>
<div><div> <br></div>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">Kieren</p>
</div>
<div><p class="MsoNormal"><br>
-<br>
[sent through phone]</p>
</div><div> <br></div>
<div><p>On Thu, Jan 29, 2015 at 7:35 AM, Jonathan
Zuck <<a href="mailto:JZuck@actonline.org" target="_blank">JZuck@actonline.org</a>>
wrote:</p>
<blockquote>
<div>
<div><p class="MsoNormal"><span>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.</span></p><div><span> </span><br></div><p class="MsoNormal"><span>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.</span></p><div><span> </span><br></div><p class="MsoNormal"><span>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.</span></p><div><span> </span><br></div><p class="MsoNormal"><span>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" target="_blank">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.</span></p><div><span> </span><br></div><p class="MsoNormal"><span>My two cents</span></p><div><span> </span><br></div><p class="MsoNormal"><span>Jonathan</span></p><div><span> </span><br></div><div><span> </span><br></div><div><span> </span><br></div><div><span> </span><br></div><p class="MsoNormal"><b>From:</b><span>
<a href="mailto:accountability-cross-community-bounces@icann.org" target="_blank">
accountability-cross-community-bounces@icann.org</a> [<a href="mailto:accountability-cross-community-bounces@icann.org" target="_blank">mailto:accountability-cross-community-bounces@icann.org</a>]
<b>On Behalf Of </b>Kieren McCarthy<br>
<b>Sent:</b> Thursday, January 29,
2015 9:39 AM<br>
<b>To:</b> Malcolm Hutty<br>
<b>Cc:</b> Accountability Cross
Community<br>
<b>Subject:</b> Re: [CCWG-ACCT] The
big test of effective accountability</span></p><div> <br></div><p class="MsoNormal">Like this. Excellent
food for thought. </p>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">Will dig out
Steve's mission email - had completely
missed it. You have the email header
handy?</p>
<div><div> <br></div>
</div>
<div><div> <br></div>
</div>
<div><p class="MsoNormal">Kieren</p>
</div>
</div>
<div><p class="MsoNormal"><br>
-<br>
[sent through phone]</p>
</div><div> <br></div>
<div><p>On Thu, Jan 29, 2015 at 6:00 AM,
Malcolm Hutty <<a href="mailto:malcolm@linx.net" target="_blank">malcolm@linx.net</a>>
wrote:</p>
<blockquote><p class="MsoNormal"><br>
<br>
On 29/01/2015 11:45, Bruce Tonkin
wrote: <br>
> In terms of reviewing the new
gTLD program <br>
<br>
Kieren may correct me, but I read
his essay as being about more than <br>
just the gTLD program alone, albeit
that that was the example given. I <br>
read it as a general complaint that
ICANN tends to be to formalistic, <br>
and loses sight of the substance of
the issue, not only in gTLD <br>
applications, but often. And I think
that he's far from alone in that <br>
view, especially amongst those who
engage with ICANN peripherally
rather <br>
than intensively. <br>
<br>
> I compare this to a jury
process in the legal system. I don’t
think <br>
> you can just ask for another
jury to hear the case when the first
<br>
> jury finds against you. There
needs to be some basis for the
appeal <br>
> other than that you disagree
with the initial finding. <br>
[...] <br>
> So careful work is needed to
ensure that we have a process that <br>
> ensures independent reviews of
decisions, and also appropriate <br>
> criteria to initiate a review
of a decision. <br>
<br>
There I think you get to the heart
of the matter. <br>
<br>
Kieren's complaint about formalism
is interesting insofar as it goes, <br>
and I think it is a very useful
contribution, but it is only
identifies <br>
a problem, it doesn't analyse it or
propose a solution. I would like to
<br>
try to work from where Kieren left
off. <br>
<br>
Kieren, you're a journalist. You
live and breathe five-Ws and an H. <br>
Let's apply that here. <br>
<br>
WHAT's the problem? (Excessive legal
formalism, resulting in loss of <br>
sight of the substance of the
question). <br>
<br>
WHY do we have that problem? <br>
<br>
WHO caused it and who can address
that? <br>
<br>
HOW should it be addressed? <br>
<br>
(OK, I'm leaving out "when". Cut me
some slack.) <br>
<br>
<br>
WHY do we have the excessive
legalistic formalism Kieren
complains about? <br>
<br>
To some extent, this is
characteristic of all large
bureaucracies. They <br>
are instinctively defensive, and any
individual within them wants to <br>
show that they discharged their own
responsibilities properly even - <br>
perhaps especially - when they
don't, as an individual, necessarily
<br>
agree personally with the
organisation position. <br>
<br>
But Kieren suggests that ICANN is
particularly susceptible to this <br>
tendency, and I think I agree. An
organisation with a highly empowered
<br>
single leader (think Apple under
Steve Jobs) can cut through process
<br>
easily. I imagine an early
conversation at Apple going like
this: <br>
<br>
Product Manager: We assembled focus
groups in all our major target <br>
markets to identify the key
characteristics of a <br>
revolutionary, magical new phone. We
planted the best <br>
UI theorists in those groups, to
guide them towards <br>
characteristics and away from mere
features. We then <br>
tested the output with surveys from
the best polling <br>
companies, scientifically designed
to ensure all user <br>
groups had balanced representation.
Using their <br>
answers we ranked and prioritised
development goals. <br>
We hired the best and brightest
designers to deliver <br>
against that design brief, and I
proudly present, <br>
the You-Phone. <br>
<br>
Steve Jobs: The user experience
sucks and it feels like it was <br>
designed by a committee. Go back and
start again. <br>
<br>
<br>
Would we want ICANN to work like
this? No! We'd be rightly terrified
of <br>
leaving that much power in one
person's hands. We want ICANN to be
run <br>
by the community, with the Board
acting as an arm of the community <br>
conducting executive oversight, not
ruled by any single Global King of
DNS. <br>
<br>
So we create structures designed to
ensure that everybody's voice is <br>
heard and that everybody's interests
are taken into account, that <br>
competing positions are balanced as
fairly as it is possible to be, and
<br>
that decisions are demonstrably
rationally arrived at on the basis
of <br>
previously agreed consensus policy.
And we create more structures to <br>
appeal cases to on the basis that
any of those things failed in this <br>
instance. <br>
<br>
And we end up with the legalistic
formalism of which Kieren speaks. <br>
<br>
Why? <br>
<br>
I suggest that it is because we have
such a diverse community, and so <br>
the only thing we agree on is the
process criteria. We agree that <br>
everybody should be heard. We agree
that there should be periods of <br>
public comment, and then further
periods of reply comment. We agree
that <br>
policy should require consensus
support. But we're so anxious that
that <br>
might be the only thing we agree on
that we stop there. And so when a <br>
decision looks bad, the only thing
we have to fall back on is an appeal
<br>
to process. <br>
<br>
And mostly the process was followed
(at least in a narrow sense) so it's
<br>
very hard to reverse the decision,
even if you might like to (as Bruce
<br>
has described). And the dissatisfied
party becomes embroiled in an <br>
increasingly embittered proxy fight
with an increasingly defensive <br>
bureaucracy, when everybody knows
that the gravamen of the complaint <br>
isn't really about process at all,
it is, as Kieren says, about the <br>
substance. <br>
<br>
Some would say this means we need to
"unshackle" the Board, to give them
<br>
a wide-ranging and broad discretion
to "do the right thing", or <br>
sometimes "to take decision based in
the public interest". Removing or <br>
reducing external constraints would
enable "effective leadership" and <br>
give the Board "flexibility to
respond to a changing world" without
<br>
being "buried in legal challenges".
<br>
<br>
I consider such an approach to be a
trap. Those arguments are the same <br>
arguments one would make if an
avowed enemy of community
accountability. <br>
Following such recommendations will
lead inevitably to a Board with a <br>
top-down, paternalistic view of
governing the community at best, if
not <br>
something even worse. <br>
<br>
Instead, let us look to other I*
communities, which do not seem to
have <br>
the same problem, to see how the
IETF and the RIRs maintain genuine <br>
bottom-up community governance, and
at the same time remain focused on <br>
the substance. <br>
<br>
Let me tell a story about how one of
the RIRs recently dealt with a <br>
potentially difficult problem. <br>
<br>
Towards the end of last year, on the
mailing list for the RIPE NCC, a <br>
Ukrainian who seemed to be a
partisan of the government in Kiev,
and an <br>
opponent of the regime in Crimea and
Donetsk, raised a point about the <br>
rules. RIPE NCC rules say that
organisations applying from IP
addresses <br>
must supply government issued ID, he
said. Why does the RIPE NCC <br>
continue to serve users in Crimea?
Does the RIPE NCC accept the
validity <br>
of the Donetsk regime? On what basis
and with what justification? Surely
<br>
the only proper course is for the
RIPE NCC to cease to support <br>
organisations in Crimea until the
legitimately recognised government
of <br>
Ukraine is restored in the region (I
am using his voice, you understand,
<br>
not my own, but this is a
paraphrase, not a direct quote). <br>
<br>
The RIPE community immediately saw
this intervention for what it was in
<br>
substance: an attempt to embroil the
RIPE NCC in the ongoing regional <br>
conflict, on the side to which he
was partisan. It was not really a <br>
genuine enquiry about the rules, it
was an attempt to force a legalistic
<br>
interpretation that would subvert
their intended substance. <br>
<br>
And the RIPE community responded
swiftly, vocally, and overwhelmingly
of <br>
one view. The mission of RIPE NCC is
to support users by helping to <br>
coordinate the distribution of IP
addresses to those that need them. <br>
Networks in Crimea need IP
addresses. This does not change
because the <br>
legitimacy of the claimed government
with effective control of the <br>
region is disputed. Many members of
the RIPE Community had considerable
<br>
sympathy with the Ukrainian
partisan, and deep personal
opposition to <br>
Russian intervention in Eastern
Ukraine. Nonetheless, they agreed on
one <br>
thing: the geopolitics of the
Ukraine is not the responsibility of
the <br>
RIPE NCC. The rule requiring
government issued ID is there to
support <br>
RIPE NCC's mission to coordination
IP address distribution so that <br>
networks are allocated the address
space they require (so that RIPE NCC
<br>
can identify the entities to which
it has made allocations); to apply <br>
the same rule to prevent IP address
block allocation would be to subvert
<br>
the mission. While there is no
universally recognised government in
<br>
Eastern Ukraine, the RIPE NCC should
accept such ID from entities in <br>
that area as they are reasonably
able to provide. <br>
<br>
This story, I think, exemplifies the
ability to cut to the substance of <br>
the issue that Kieren seeks. How is
it arrived at? Not by the <br>
introduction of any strong central
leader: the NCC staff and Board was
<br>
almost silent while this discussion
played out amongst the community. <br>
It was arrived at because the
community had a strongly unified
sense of <br>
its own limited mission (to support
the distribution of IP addresses to
<br>
those that need them, through
coordinated allocation policies) and
the <br>
members of that community were
overwhelmingly willing to set aside
their <br>
own views on a matter outside the
scope of that mission when it was <br>
suggested that some other reasoning
requires an effect fundamentally <br>
contrary to the mission. We will not
have an argument about whether RIPE
<br>
NCC should act to /limit/ the
allocation of IP addresses to
entities in <br>
Crimea, not even dressed in the coat
of a rules interpretation. Maybe <br>
action should be taken against the
regime in Crimea - but not by RIPE <br>
NCC. RIPE NCC will discharge its own
mission, and leave the geopolitics <br>
to others. <br>
<br>
Is this not the same culture we want
to inculcate in ICANN? <br>
<br>
I believe that story exemplifies the
strength of the RIRs, and describes
<br>
exactly what we want from ICANN too.
<br>
<br>
And it is very far from the ICANN
Kieren describes. <br>
<br>
WHO can bring this change about? <br>
<br>
Only us. <br>
<br>
When we look to Kieren's complaint,
and see how far short ICANN falls of
<br>
the strong culture shows by the RIRs
and the IETF, the "fault" lies with
<br>
us, the community. We don't *want*
the Board, or the CEO, or the staff
<br>
to come up with a dramatically
developed version of the ICANN
Mission <br>
that will then overrule existing
processes and policies. <br>
The Mission must be developed by,
and founded in, the community
itself. <br>
<br>
What we need is for the community to
develop a much clearer idea of the <br>
Mission, and an exposition of what
that means and how it is to be <br>
applied. Then all the accountability
structures we create, the Review <br>
Boards and Reconsideration Panels
and Ombudsmen and the rest, they
will <br>
have a proper standard for review.
Not a sterile standard that looks <br>
only to bare process, but one that
asks "Is this consistent with the <br>
fundamental mission?" <br>
<br>
Consider how this might work in
practice. <br>
<br>
For .gay, there are many objections
one might make. One might say the <br>
proposed registrar was not suitable
- but that should only lead to the <br>
selection of an alternative, or the
imposition of tighter control, not <br>
to refusal to delegate. If you're
not confident in the registrar you <br>
might impose behavioural controls
(e.g. to prevent limitation of
supply) <br>
or structural controls (e.g. a
shorter contract, to require
renunciation <br>
of any presumption of renewal of the
registry contract etc) or some <br>
combination of the two. There will
be plenty of room for arguments
about <br>
the best way to proceed. <br>
<br>
But arguments that resolve to (or
are recognisable as a mere pretext <br>
for) the claim that .gay ought not
to exist can be dismissed: ICANN's <br>
mission is to make domains
available, not to prevent their
availability. <br>
<br>
I promised a HOW. <br>
<br>
Here is HOW I think we should
proceed. <br>
<br>
In our Frankfurt face-to-face we
constructed, yet again, a map of <br>
possible new structures, and most of
the focus went on that. But there <br>
was also a slot on it for the
question of clarifying the mission,
as the <br>
basis for review. A few weeks ago,
on this list, Steve DelBianco made a
<br>
very valuable start, suggesting a
new codification of the mission.
That <br>
contribution has passed almost
without notice. <br>
<br>
I don't necessarily think Steve's
formulation is perfect, but it's a
lot <br>
better than anything else I've yet
seen, and it has the virtue of being
<br>
a contribution on this critical
subject, almost alone. Let us work <br>
together on that, to build that
common shared sense of Mission. <br>
Not an infinitely broad Mission,
intended to allow any possible
action <br>
in an unknowable future, but a
narrow mission, intended to guide,
to <br>
help make decisions which are
choices, that can, as Bruce says,
act as a <br>
meaningful criterion for review of
decisions. <br>
<br>
Let us have the courage to believe
we can build a strong consensus on a
<br>
meaningfully limited mission, not
merely on narrow questions of
process. <br>
If we can succeed in that, we can
succeed in creating an ICANN that is
<br>
meaningfully accountable to the
community on matters of essential <br>
substance, not merely failures of
process. <br>
<br>
Kind Regards, <br>
<br>
Malcolm. <br>
<br>
-- <br>
Malcolm Hutty | tel: <a href="tel:%2B44%2020%207645%203523" target="_blank">+44 20 7645 3523</a>
<br>
Head of Public Affairs | Read the
LINX Public Affairs blog <br>
London Internet Exchange | <a href="http://publicaffairs.linx.net/" target="_blank">
http://publicaffairs.linx.net/</a>
<br>
<br>
London Internet Exchange Ltd <br>
21-27 St Thomas Street, London SE1
9RY <br>
<br>
Company Registered in England No.
3137929 <br>
Trinity Court, Trinity Street,
Peterborough PE1 1DA </p>
</blockquote>
</div><div> <br></div>
</div>
</div>
</blockquote>
</div><div> <br></div>
</div>
</div>
</div>
</div>
</blockquote>
</div><div> <br></div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Accountability-Cross-Community mailing list
<a href="mailto:Accountability-Cross-Community@icann.org" target="_blank">Accountability-Cross-Community@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>Accountability-Cross-Community mailing list<br><a href="mailto:Accountability-Cross-Community@icann.org" target="_blank">Accountability-Cross-Community@icann.org</a><br><a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br></blockquote></div><br></div></div></div></span></div><br>_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
<a href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-Community@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br>
<br></blockquote></div><br></div>