[CCWG-ACCT] Budgetary veto/control solves the wrong problem and avoids solving the right one

Alan Greenberg alan.greenberg at mcgill.ca
Wed Jul 29 15:26:50 UTC 2015

My normal refrain on many of these discussions is 
that if we trust AC/SOs to appoint Board members, 
we should also presume that they are mature and 
will not use any of these powers in ways that are 
less than honourable and free from vindictive purposes.

However, with some of the talk going on about the 
lessened position that ACs should have in this 
process, I sadly CAN see how there could be an 
attempt to gang up on one group...


At 29/07/2015 08:25 AM, Chris Disspain wrote:
>Hi Mathieu,
>See below
>>On 29 Jul 2015, at 19:31 , Mathieu Weill 
>><<mailto:mathieu.weill at afnic.fr>mathieu.weill at afnic.fr> wrote:
>>Hi Chris,
>>Thanks for starting a list of key and concrete 
>>scenarios to outline how the proposed measures 
>>could work. I think that's useful and am 
>>tagging this email for Hillary as this type of 
>>use-case would be useful to our communications plan.
>>Le 29/07/2015 06:50, Chris Disspain a écrit :
>>>Let’s assume that the single member has a 
>>>total of 20 votes (5 each for ASO, ccNSO, GNSO 
>>>and ALAC) and that the threshold for the veto 
>>>is 75%. That means that 15 votes are required.
>>>Let’s assume that ALAC asks for an allocation 
>>>of $2,000,000 to run an At Large Summit. At 
>>>the moment, that is an extraordinary item 
>>>(i.e. it is not automatically budgeted for 
>>>each year or each X years) and the process of 
>>>approval involves, in essence, the Board 
>>>approving it. Under the veto provision, it 
>>>would be possible for the ASO, ccNSO and GNSO 
>>>to vote against the budget because of that line item.
>>I note that it would require unanimity outside 
>>of ALAC to veto the budget in that 
>>scenario.  Worth questioning whether that is a 
>>useful safeguard or an interference into the matters of ALAC.
>>Another scenario that was considered by this 
>>group was a proposal from the Board to allocate 
>>a significant part of Icann funds to a summit 
>>on Internet governance, for example. Once 
>>again, the question is whether the veto and the 
>>associated threshold provide a useful safeguard or undue interference.
>Well, I think a community wide concern about a 
>general budget item may be different from a 
>concern about an AC or SO specific item. Leaving 
>aside the desirability of a veto, I would expect 
>a ‘community' wide concern about a significant 
>budget expense on Internet governance to carry a 
>high persuasive weight with the Board. I think a 
>concern about a budget expense specific to an SO 
>or AC is different and may deserve different treatment.
>>>Equally, the ALAC, ccNSO and ASO could vote 
>>>against a gTLD industry summit line item or a 
>>>non-commercial users meeting cost. And, 
>>>entirely the reverse could happen with SOs and 
>>>ACs 'horse-trading' with each other so that 
>>>they each get their (to quote you) needs, concerns, demands, objections met.
>>Not being a native English speaker, I can't be 
>>sure of my understanding of horse-trading. 
>>However, once again it's worth considering 
>>whether a cross community discussion should 
>>take place on which needs, concerns, demands, 
>>from the various SOs or ACs should be funded or 
>>not, whether we qualify it as "horse-trading" 
>>or "cross community coordination in the budgetary process”.
>My apologies for using unclear colloquialisms. I 
>mean that SOs and ACs could ’negotiate’ amongst 
>themselves to secure their own particular 
>’needs, concerns or demands’. And they would be 
>doing so without any fiduciary responsibility to 
>ICANN ('We will agree to your summit if you 
>agree to ours and we both block theirs’). Not 
>necessarily an issue provided we are happy to create this environment.
>>And once again, the Board gets to propose the 
>>budget, just like now, and the veto process 
>>would be exceptional and requiring 
>>supermajority. Only 33% support and it moves on.
>You seem to be working on 67% requirement to 
>block rather than a 75%. Or to use your way of 
>putting it, you are working on only 33% support 
>required rather than only 25%. That would mean 
>that in my scenario of 20 votes split between 4 
>SOs/ACs, 13.4 votes would be enough to veto. 
>Leaving aside whether you would round up to 14 
>or down to 13, that scenario means that the veto 
>wouldn’t even need to be unanimous across 3 
>SOs/ACs. Again
.not necessarily a problem as 
>long as we are clear that this is what we want.
>>I understand the intent of the WS2 item on the 
>>budget process to be intended to look at these coordination issues.
>>>Is this really what we want to set up?
>>>>On 29 Jul 2015, at 03:02 , Greg Shatan 
>>>><<mailto:gregshatanipc at gmail.com>gregshatanipc at gmail.com> wrote:
>>>>I don't think the budget veto was ever 
>>>>intended to substitute for community 
>>>>participation in the budget process, rather 
>>>>it was intended to encourage it (in a sort of 
>>>>dark and foreboding way).  There are already 
>>>>a number of ways in which the community in 
>>>>general, and SOs and ACs (and their component 
>>>>parts) participate in the budget process, and 
>>>>these have been improving over time.  I'm not 
>>>>going to catalogue them here, but I should 
>>>>think it's readily available on the website 
>>>>or from Xavier Calvez's team.  These should 
>>>>continue to be improved.  One continuing 
>>>>shortcoming is that we are all still 
>>>>supplicants, beseeching ICANN finance for a 
>>>>little more pie.  While this is true in 
>>>>private (and public) entities as well, the 
>>>>level of influence of the community is 
>>>>probably lower than it should be.  As it is 
>>>>now, the community can register all of its 
>>>>needs, concerns, demands, objections, etc., 
>>>>and in the end there is nothing to make those 
>>>>anything more than "kind requests."
>>>>The budget veto is a final backstop in the 
>>>>event of a budget that fundamentally is at 
>>>>odds with where it should be.  The budget 
>>>>veto should not be viewed primarily as a 
>>>>power, as much as an admonishment, to add 
>>>>discipline the budget process.  It should 
>>>>constrain the Board from delivering a 
>>>>"veto-able" budget.  The best way to avoid 
>>>>that, of course, is communication with and 
>>>>due consideration of the need of the community throughout the process.
>>>>One other note -- there seems to be a 
>>>>misunderstanding of what a "non-profit 
>>>>corporation" (and why it is called 
>>>>"non-profit").  A "for-profit" corporation 
>>>>pays out net profits to its owners 
>>>>(shareholders or other types of owners).  A 
>>>>non-profit does not have owners or 
>>>>shareholders, so it does not pay out profits 
>>>>to anybody.  While an entity can be " 
>>>>non-profit," this does not mean it is 
>>>>"non-surplus." "Non-profit" does not mean 
>>>>that it is not supposed to run an excess of 
>>>>revenues over expenses, or have no more 
>>>>assets than it has liabilities.  So, this 
>>>>idea of "balance" is misplaced.  A 
>>>>non-profit, like a for-profit, needs to 
>>>>balance its books in an accounting sense, but 
>>>>that does not in any way mean that there is a 
>>>>prohibition or even a presumption against 
>>>>having a surplus of cash over 
>>>>expenses.  There may be a point when sitting 
>>>>on a pile of cash is not consistent with the 
>>>>entity's goals, but that can also be true of 
>>>>a for-profit corporation.  It's entirely fair 
>>>>to talk about the numbers, but we should be 
>>>>careful not to bring in presumptions that 
>>>>don't exist.  [Caveat: I'm not referring to 
>>>>charitable organizations, which are often referred to as non-profits as well.]
>>>>On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl 
>>>>Gutiérrez <<mailto:crg at isoc-cr.org>crg at isoc-cr.org> wrote:
>>>>Dear George,
>>>>I agree with you that a cumulated budget veto 
>>>>is a pretty useless accountability tool 
>>>>(independently of how difficult it would be 
>>>>for the sole member to exercise it
>>>>Moreover, I think the community on the one 
>>>>hand should take care that the public 
>>>>interest objectives (policy development and 
>>>>compliance functions) are properly funded. It 
>>>>would be much more effective if those 
>>>>separate hose budgets (policy development and 
>>>>compliance functions) would be developed in a 
>>>>bottom up fashion, based on the needs of the 
>>>>community, and through the communities direct 
>>>>involvement. No need for a veto then since 
>>>>the SOs/ACs would be DIRECTLY responsible for their budgets.
>>>>On the other hand, it is up to management to 
>>>>guarantee the financial BALANCE  of the day 
>>>>to day operations (yes, balance because ICANN 
>>>>purpose is non for profit), as well as 
>>>>guarantee the demands of the community for 
>>>>proper funding of the public interest 
>>>>functions (independently of the line overseer 
>>>>of the functions, which is another black box altogether).
>>>>This would be in my view a much more 
>>>>effective system of so called “checks and 
>>>>balances”  than an absolute veto over the 
>>>>cumulated budget, where the community has 
>>>>little knowledge on the different objectives 
>>>>under it was produced, and remains in my eyes 
>>>>will very obscure, independently of the 
>>>>overall sum in relation to the size of the business.
>>>>Carlos Raúl Gutiérrez
>>>><mailto:crg at isoc-cr.org>email: <mailto:crg at isoc-cr.org>crg at isoc-cr.org
>>>>Skype: carlos.raulg
>>>><tel:%2B506%208837%207173>+506 8837 7173 (cel)
>>>><tel:%2B506%204000%202000>+506 4000 2000 (home)
>>>><tel:%2B506%202290%203678>+506 2290 3678 (fax)
>>>>Apartado 1571-1000
>>>>San Jose, COSTA RICA
>>>>><mailto:george.sadowsky at gmail.com>On Jul 27, 
>>>>>2015, at 9:30 AM, George Sadowsky 
>>>>><<mailto:george.sadowsky at gmail.com>george.sadowsky at gmail.com> wrote:
>>>>>These are my personal opinions.
>>>>>I suspect that the reaction to this post 
>>>>>will be, "we are way past this, we've 
>>>>>discussed this, and now just help us work on 
>>>>>the implementation details."  If so, I think 
>>>>>that's a mistake, because what I'd like to 
>>>>>do is question one of the fundamental 
>>>>>assumptions behind what this group is doing.
>>>>>When this process started, there was general 
>>>>>agreement that it was more important to do 
>>>>>this right than to do it 
>>>>>quickly  Unfortunately, this feeling appears 
>>>>>to have reversed, with the current sense 
>>>>>that it is more important to get it done 
>>>>>quickly in the name of the transition than 
>>>>>to spend the time needed to do it 
>>>>>right.  This process is going beyond 
>>>>>accountability to a fundamental redesign of 
>>>>>ICANN, with IMO inadequate concern for 
>>>>>assuring inclusivity of support as well as 
>>>>>lack of concern for unanticipated consequences.
>>>>>So here's what I'd like to contribute ...
>>>>>I've been uncomfortable with the notion of 
>>>>>budgetary control/veto since the idea was 
>>>>>first presented.  I think that I now know 
>>>>>why: in my opinion it solves the wrong 
>>>>>problem, and it is the wrong solution to the right problem.  Let me explain.
>>>>>In general, budgetary control is exercised 
>>>>>by groups who want to control an aggregate 
>>>>>budget, whether for reasons of limiting 
>>>>>growth or ensuring that aggregate expenses 
>>>>>for a budget do not exceed some measure of 
>>>>>income.  I don't think that's the case here, 
>>>>>although I suppose that under exceptional circumstances it might be.
>>>>>The alternative is that the control the 
>>>>>group appears to want must be by program or 
>>>>>even by line item, even though you're 
>>>>>planning to use a very blunt 
>>>>>instrument  --  control over approval of the 
>>>>>aggregate budget  --  as your tool to 
>>>>>accomplish this.  If that's the case, then 
>>>>>what you really want is programatic control, 
>>>>>not budgetary control.  If the program is 
>>>>>accepted, then subject to resource 
>>>>>constraints, it's up to the staff to 
>>>>>deliver, and any specific line item or 
>>>>>similar objection, however expressed, 
>>>>>interferes with the execution of the activity.
>>>>>If the disagreement is with the program, 
>>>>>with the objectives to be accomplished, and 
>>>>>how the objectives are to be accomplished, 
>>>>>then that is where the control should be 
>>>>>exercised.  Any budgetary control after that 
>>>>>is micromanagement.  The response to that is 
>>>>>if you don't trust the organization to 
>>>>>implement a rather well defined activity, 
>>>>>then change the management/staff, don't 
>>>>>restrict their resources and let them continue anyway.
>>>>>I suggest pursuing this line of argument 
>>>>>further.  In my opinion, our fundamental 
>>>>>problem has two components: (1) a persistent 
>>>>>inadequate level of trust between groups 
>>>>>within the ICANN community, and (2) our 
>>>>>inability/unwillingness to create and use 
>>>>>structures to deal directly with this 
>>>>>situation and improve it.   I see the 
>>>>>mechanism as starting with a lack of 
>>>>>trust   --  in Board, management, staff, as 
>>>>>well as the ACs and the SOs and their 
>>>>>constituent parts  -- that generates not 
>>>>>only suspicion regarding motives, 
>>>>>non-transparent actions, and actions that 
>>>>>are not equally favorable to all groups 
>>>>>involved, but also the sense that the 
>>>>>process is not serving "me" (whoever I am) 
>>>>>well and is therefore out of control.
>>>>>In other words, IMO we have a fundamental 
>>>>>problem of trust, and we don't have an 
>>>>>effective way to talk about it or to otherwise address it, much less solve it.
>>>>>The budget rejection process that is being 
>>>>>defined by the group is IMO based more upon 
>>>>>defining ultimate ("nuclear" if you like) 
>>>>>confrontation mechanisms than upon finding 
>>>>>cooperative mechanisms to identify and 
>>>>>resolve potential conflicts at an earlier 
>>>>>stage.  It does not address the trust issue, 
>>>>>and to the extent that my hypothesis is 
>>>>>correct, if not addressed the trust issue 
>>>>>will continue to bedevil ICANN activities, 
>>>>>in other probably equally destructive 
>>>>>ways.   Should not this group be equally or 
>>>>>more concerned about mechanisms to identify 
>>>>>issues and encourage cooperative-based and 
>>>>>trust building processes to solve problems 
>>>>>as they arise?   It does not appear so to me.
>>>>>In summary, the current approach, gaining 
>>>>>more control over budget approval, is based 
>>>>>upon a model of checks and balances, and 
>>>>>that may be legitimate to some 
>>>>>extent.  However, I sense that is not the 
>>>>>way in which it is planned to be 
>>>>>employed.  If so, it solves the wrong 
>>>>>problem, nad it does not address the real 
>>>>>problem.   We need a different approach, one 
>>>>>of getting to the root of disagreements, 
>>>>>real and perceived, that is early and based 
>>>>>upon increased cooperation and trust, and we 
>>>>>need a way to communicate that encourages 
>>>>>this to happen.  This is not an easy problem 
>>>>>to solve, but IMO it's the real problem that 
>>>>>we have to solve, rather than some well 
>>>>>meaning but inaccurate proxy representation of it.
>>>>>Please consider these thoughts in your discussions.
>>>>>Accountability-Cross-Community mailing list
>>>>><mailto:Accountability-Cross-Community at icann.org>Accountability-Cross-Community at icann.org
>>>>Accountability-Cross-Community mailing list
>>>><mailto:Accountability-Cross-Community at icann.org>Accountability-Cross-Community at icann.org
>>>>Accountability-Cross-Community mailing list
>>>><mailto:Accountability-Cross-Community at icann.org>Accountability-Cross-Community at icann.org
>>>Accountability-Cross-Community mailing list
>>><mailto:Accountability-Cross-Community at icann.org>Accountability-Cross-Community at icann.org
>>Mathieu WEILL
>>AFNIC - directeur général
>>Tél: +33 1 39 30 83 06
>><mailto:mathieu.weill at afnic.fr>mathieu.weill at afnic.fr
>>Twitter : @mathieuweill
>Accountability-Cross-Community mailing list
>Accountability-Cross-Community at icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150729/1309de33/attachment.html>

More information about the Accountability-Cross-Community mailing list