<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
Hi,<br>
<br>
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>
The fact that those recommendations lingered is indeed why we need
the binding bits.<br>
<br>
So often we come close, yet at the last minute we let something go
undone and the work gets lost.<br>
<br>
Stuff like this needs fixing.<br>
<br>
avri<br>
<br>
<br>
<div class="moz-cite-prefix">On 29-Jan-15 17:37, Kieren McCarthy
wrote:<br>
</div>
<blockquote
cite="mid:CAA4fB=1p3COnm0g4uCjMkA9B7yOudZiD=idGLpUPYj3M1d8g=A@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<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 moz-do-not-send="true"
href="mailto:ceo@auda.org.au" target="_blank">ceo@auda.org.au</a>></span>
wrote:<br>
<blockquote class="gmail_quote">
<div><span>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
moz-do-not-send="true"
href="mailto:avri@acm.org" target="_blank">avri@acm.org</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div> 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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:accountability-cross-community-bounces@icann.org"
target="_blank">
accountability-cross-community-bounces@icann.org</a>
[mailto:<a
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:accountability-cross-community-bounces@icann.org"
target="_blank">
accountability-cross-community-bounces@icann.org</a> [<a
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:Accountability-Cross-Community@icann.org" target="_blank">Accountability-Cross-Community@icann.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:Accountability-Cross-Community@icann.org"
target="_blank">Accountability-Cross-Community@icann.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-Community@icann.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>