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

Sun Mar 1 18:48:13 UTC 2015

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.

Thanks,
 Robin

On Mar 1, 2015, at 9:28 AM, Alan Greenberg wrote:

> Thanks Avri,
> 
> 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.
> 
> 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.
> 
> Alan
> 
> At 01/03/2015 11:42 AM, Avri Doria 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 
>>> 
>> 
>> 
>> 
>> 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
> _______________________________________________
> 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/dcb27ea2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150301/dcb27ea2/signature.asc>