<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I agree that it would be best for the entire community to have the recall power with respect to the NomComm appointees. They are supposed to be representative of the larger community and so that is the appropriate place for that recall to happen. It would also create an incentive for NomComm to appoint people who might be more responsive to the community than otherwise. I also support the proposal that an AC/SO should be able to set their own threshold and other terms for recall.<div><br></div><div>Thanks,</div><div> Robin<br><div><br></div><div><br><div><div>On Mar 1, 2015, at 9:28 AM, Alan Greenberg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div>
Thanks Avri,<br><br>
Certainly for an AC/SO, there is an obligation to document how the
selection is made (or who it is made by) and if there were a recall
allowed, then that procedure must be documented as well. I don't know to
what extent we should or could prescribe those rules for them, but I
don't think it would be unreasonable to say that the decision to recall
should be made by the same group (current incumbents) that do the
selection, and that it should require a supermajority instead of just a
majority.<br><br>
I am less sure I agree on the NomCom recall. I would prefer a mechanism
that required the overall community to act instead of the NomCom. The
NomCom is a surrogate for the community at least partly because of the
desire for confidentiality in its candidate list, confidential references
and deliberations. When you are only taking about a binary decision to
recall or not recall a particular person, I see no reason why the secrecy
of the NomCom is needed, and indeed, I think that it would be a negative
with regard to transparency of how/why the decision is taken.<br><br>
Alan<br><br>
At 01/03/2015 11:42 AM, Avri Doria wrote:<br>
<blockquote type="cite" class="cite" cite="x-msg://3065/">Hi,<br>
<font color="#330033"><br>
I support your position Alan. <br><br>
But in order for it to work, it must be as laborious to remove as it is
to elect. There needs to be something that is similar to the
process it takes to put someone on the Board. For example, if
Nomcom placed someone on te Board, [a] Nomcom* should remove
them. Like wise, if a process like the one that At-Large has to put
them on, then a similar process needs to be created to take them
off.<br><br>
It is more difficult to figure out what to do in terms of the GNSO, but
as soon as we document our systems for (s)electing Board members, we
should consider a system for removal. &c.<br><br>
My general refrain on this is it should be possible, but it should be
hard to do.<br><br>
avri<br><br>
* for an example please see
<a href="https://datatracker.ietf.org/doc/rfc7437/">
https://datatracker.ietf.org/doc/rfc7437/</a><br>
<br>
</font><pre> IAB, IESG, and IAOC Selection, Confirmation, and Recall
Process:
Operation of
the Nominating and Recall Committees</pre><font color="#330033"><br><br>
On 28-Feb-15 21:06, Alan Greenberg wrote:<br>
<blockquote type="cite" class="cite" cite="x-msg://3065/">Bruce, I have several problems
with your rationale. First, decisison of the ICANN Board which hinge on
how a particular (or even two) Board Members vote are few and far
between, so the concept of an AC/SO turfing their Board member(s) because
they did n't get something is rather hypothetical. Moreover, at least in
the case, of travel budget requests, I didn't think that the Board voted
on items at that level (perhaps if they did some of our requests would be
looked at more kindly!). <br><br>
But on a higher level, do you really think that this kind of action would
happen? I cannot imagine the GNSO doing something of that sort when you
were Chair, nor in any time since. Nor do I think that ANY of the groups
that appoint Board members would. <br><br>
If a Board member selected by an AC or SO is really and consistently
acting in a way that the AC/SO does not appropriate, they certainly would
not have selected them if they could have foreseen it, so why should they
not be able to rectify the situation. Some political jurisdiction allow
that with their duly elected appointees, so why not here. <br><br>
Although I see the attraction in having a formal set of standards to
identify the more egregious sins, I believe that in reality, in the very
few cases where either the Board itself or an AC/SO would be likely to
recall, the reasons may well be outside of that class of problem.
<br><br>
Alan <br><br>
<br><br>
At 28/02/2015 08:01 PM, Bruce Tonkin wrote: <br>
<blockquote type="cite" class="cite" cite="x-msg://3065/">Hello Roelof, <br><br>
<br>
>> - Recall Board members if not acting in global public
interest rather than if not acting in segmented interest of a community.
Consider community capture (especially a segment of community). <br><br>
My comment on the call was about a concern that allowing segments of the
community to recall "their" Board member may move away from the
objective of ensuring that Board members primarily focus on the global
public interest in their decision making. <br><br>
I noted that under law the directors of ICANN owe a fiduciary
(<a href="http://en.wikipedia.org/wiki/Fiduciary">
http://en.wikipedia.org/wiki/Fiduciary</a>) duty to the
organization, but I also noted that the organization was established to
act in the global public interest. When new Board
members join the Board we make clear that they have a fiduciary duty
under law and must understand the organization's financials etc, but we
also make clear that they need to act on behalf of the community as a
whole, not just the part of the community that appointed the director/s.
<br><br>
The Board currently does have the power to remove a director with a 3/4
majority vote. In practice the Board sets clear expectations
for the conduct of directors through its code of conduct:
<a href="https://www.icann.org/resources/pages/code-of-conduct-2012-05-15-en">
https://www.icann.org/resources/pages/code-of-conduct-2012-05-15-en</a>
. Also Board members must annually certify that they
have read this code, and acknowledge in writing that they understand
it. The code notes that "Board Members
should not be, or appear to be, subject to influences, interests or
relationships that conflict with the interests of ICANN or ICANN's
ability to operate for the benefit of the Internet community as a
whole." <br><br>
Under the enforcement of the code of conduct - it notes that
"Serious breaches of this Code may be cause for dismissal of the
Board Member committing the infraction in accordance with ICANN's Bylaws
and applicable law." <br><br>
<br>
I don't have a problem in principle with a segment of the ICANN community
that appoints a director having the ability to recall that director, but
would prefer that they use the same standard -ie the Board Directors'
Code of Conduct. I also don't have a
problem with the Board having the same restriction in the bylaws.
<br><br>
I think we need to avoid situations where one part of the community
withdraws a Board member because a Board decision was not particularly
favourable to their part of the community - even though the decision is
in the global public interest. e.g. If one group didn't
get their budget request for travel approved, or one group didn't like an
increase in registry or registrar fees in a particular year.
This has the risk of making the board behave in a political manner rather
than focussing on the global public interest. The Board
meets with each stakeholder group at ICANN and that is the forum where
each stakeholder group can put their case for a particular
decision. Generally Board members appointed by a particular
part of a community listen to all the parts of the community and make a
decision in the interests of the community as a whole, and don't play an
active role on the Board pushing the agenda of their part of the
community. Board members from a particular par <br>
t of the community do however help explain to other Board
members the nuances of the concerns from their part of the
community where that is not clear. <br><br>
Regards, <br>
Bruce Tonkin <br><br>
<br><br>
<br><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" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote><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" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
<br><br>
</blockquote><br><br>
<br>
<hr>
This email has been checked for viruses by Avast antivirus software.
<br>
<a href="http://www.avast.com/">www.avast.com</a> <br><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" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</font></blockquote></div>
_______________________________________________<br>Accountability-Cross-Community mailing list<br><a href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-Community@icann.org</a><br>https://mm.icann.org/mailman/listinfo/accountability-cross-community<br></blockquote></div><br></div></div></body></html>