[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 06:18:08 UTC 2015

Hi Jordan,

Okay thanks for marking the script. I guess Chris concern is valid then and
I like to add my +1 to it. We will most likely be creating political
parties within the SO/AC if that is implemented.
There are three options that comes to mind to avoid this:

- Define scope of what can be vetoed in a budget; it has to be items that
are global to the community and not specific to SO/AC like the ALAC
assembly is specific and as such should have the immunity

- Put a minimal votes required from each SO/AC as an additional requirement
to the 75% total

- Determine that budget veto could cause more damage than it could fix and
remove it as one of the possible powers.

That said, I don't understand why it's the 75% of total when we all know
that the budget veto power will be exercised by the "sole member" which
comprises of all SO/AC. It just doesn't put the essence of sole membership
in practice.

On 29 Jul 2015 7:01 am, "Jordan Carter" <jordan at internetnz.net.nz> wrote:

> Chris: you are right and Seun is wrong. We are not setting up mini-quorums
> or mini-vetoes by creating individual thresholds within participating SOs
> or ACs.
> best
> Jordan
> On 29 July 2015 at 17:48, Chris Disspain <ceo at auda.org.au> wrote:
>> 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
>> A good point and if I have misunderstood then I apologise. Could someone
>> clarify please?
>> Cheers,
>> Chris
>> On 29 Jul 2015, at 15:45 , Seun Ojedeji <seun.ojedeji at gmail.com> wrote:
>> 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.
>> Regards
>> >
>> > 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> 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.
>> >>>
>> >>> 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> wrote:
>> >>>>
>> >>>> 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
>> 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.
>> >>>>
>> >>>> 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
>> >
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
> --
> Jordan Carter
> Chief Executive
> *InternetNZ*
> +64-495-2118 (office) | +64-21-442-649 (mob)
> Email: jordan at internetnz.net.nz
> Skype: jordancarter
> *A better world through a better Internet *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150729/5ee806da/attachment.html>

More information about the Accountability-Cross-Community mailing list