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

Sun Mar 1 17:28:54 UTC 2015

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/>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>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>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
>>><mailto:Accountability-Cross-Community at icann.org>Accountability-Cross-Community at icann.org 
>>>
>>>https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>
>>_______________________________________________
>>Accountability-Cross-Community mailing list
>><mailto:Accountability-Cross-Community at icann.org>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.
><http://www.avast.com/>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/de9802e1/attachment.html>