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

Seun Ojedeji seun.ojedeji at gmail.com
Wed Jul 29 05:45:14 UTC 2015

On 29 Jul 2015 5:51 am, "Chris Disspain" <ceo at auda.org.au> wrote:.
> 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.
SO: My understanding was that the 75% is from each SO/AC(i.e ~4 out of 5
votes of each SO/ALAC) and not from total votes casted

> 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.
> 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.
> Is this really what we want to set up?
SO: If my understanding of the 75% above is incorrect then I agree as well;
it's definitely not a setup to uphold.


> Cheers,
> Chris
>> On 29 Jul 2015, at 03:02 , Greg Shatan <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.]
>> Greg
>> On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg at isoc-cr.org>
>>> 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.
>>> Best
>>> Carlos Raúl Gutiérrez
>>> _____________________
>>> email: crg at isoc-cr.org
>>> Skype: carlos.raulg
>>> +506 8837 7173 (cel)
>>> +506 4000 2000 (home)
>>> +506 2290 3678 (fax)
>>> _____________________
>>> Apartado 1571-1000
>>> San Jose, COSTA RICA
>>>> On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky at gmail.com>
>>>> All,
>>>> 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
>>>> 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
>>>> 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
>>>> 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.
>>>> George
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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/20150729/bc1ac3c7/attachment.html>

More information about the Accountability-Cross-Community mailing list