[CCWG-ACCT] Notes-Recordings-Transcript links for CCWG ACCT Session #14 24 February

Sun Mar 1 18:17:45 UTC 2015

Hi,

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.

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.

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

Cheers!
sent from Google nexus 4
kindly excuse brevity and typos.
On 1 Mar 2015 17:43, "Avri Doria" <avri at acm.org> wrote:

>  Hi,
>
> I support your position Alan.
>
> 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.
>
> 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.
>
> My general refrain on this is it should be possible, but it should be hard
> to do.
>
> avri
>
> * for an example please see https://datatracker.ietf.org/doc/rfc7437/
>
>  IAB, IESG, and IAOC Selection, Confirmation, and Recall Process:
>            Operation of the Nominating and Recall Committees
>
>
> On 28-Feb-15 21:06, Alan Greenberg wrote:
>
> 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!).
>
> 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.
>
> 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.
>
> 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.
>
> Alan
>
>
>
> At 28/02/2015 08:01 PM, Bruce Tonkin wrote:
>
> Hello Roelof,
>
>
> >>  - 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).
>
> 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.
>
> I noted that under law the directors of ICANN owe a fiduciary (
> http://en.wikipedia.org/wiki/Fiduciary)  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.
>
> 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:
> https://www.icann.org/resources/pages/code-of-conduct-2012-05-15-en .
> 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."
>
>  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."
>
>
> 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.
>
> 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
>  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.
>
> Regards,
> Bruce Tonkin
>
>
>
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
>
>
>
> ------------------------------
>    <http://www.avast.com/>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150301/76d2b33d/attachment.html>