<p dir="ltr">Hi,</p>
<p dir="ltr">While I understand and agree with the intent of keeping a board member accountable through recall threat, I think it would be neater and less subject to abuse/uncertainties if a board member knows he/she will be removed if not acting in the interest of the community. I am of the opinion that board should always act in the interest of the entire community(the organisation); especially as the composition of board is not balanced per SO/AC in representation, its members then should not act representatively.</p>
<p dir="ltr">The referenced recall process could be very much applied for the noncom selected board members, I can't say the same for SO/AC selected members. However if such kill switch needs to be handed to various SO/AC then I think the recall process needs to be uniform across the communities as much as possible; factors that remove a board member needs to be clearly defined and should not be bent on the member solely representing his/her SO/AC.</p>
<p dir="ltr">Overall there is need to strike a balance so we don't have a board that becomes representative in it's action but a board that is representative of the entire community. That way it will be easier to notice if any SO/AC board member is acting contrary and then the kill switch can be initiated by respective SO/AC</p>
<p dir="ltr">Cheers!<br>
sent from Google nexus 4<br>
kindly excuse brevity and typos.</p>
<div class="gmail_quote">On 1 Mar 2015 17:43, "Avri Doria" <<a href="mailto:avri@acm.org">avri@acm.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#330033">
Hi,<br>
<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/" target="_blank">https://datatracker.ietf.org/doc/rfc7437/</a><br>
<pre> IAB, IESG, and IAOC Selection, Confirmation, and Recall Process:
Operation of the Nominating and Recall Committees</pre>
<br>
<div>On 28-Feb-15 21:06, Alan Greenberg
wrote:<br>
</div>
<blockquote type="cite">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">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" target="_blank">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" target="_blank">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" 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>
<br>
_______________________________________________
<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>
<br>
<br>
</blockquote>
<br>
<br><br>
<hr style="border:none;color:#909090;background-color:#b0b0b0;min-height:1px;width:99%">
<table style="border-collapse:collapse;border:none">
<tr>
<td style="border:none;padding:0px 15px 0px 8px">
<a href="http://www.avast.com/" target="_blank">
<img border="0" src="http://static.avast.com/emails/avast-mail-stamp.png">
</a>
</td>
<td>
<p style="color:#3d4d5a;font-family:"Calibri","Verdana","Arial","Helvetica";font-size:12pt">
This email has been checked for viruses by Avast antivirus software.
<br><a href="http://www.avast.com/" target="_blank">www.avast.com</a>
</p>
</td>
</tr>
</table>
<br>
</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>