<html>
<body>
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.<br><br>
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...<br><br>
Alan<br><br>
At 29/07/2015 08:25 AM, Chris Disspain wrote:<br>
<blockquote type=cite class=cite cite="">Hi Mathieu,<br><br>
See below…..<br><br>
<br><br>
Cheers,<br><br>
<br>
Chris<br><br>
<blockquote type=cite class=cite cite="">On 29 Jul 2015, at 19:31 ,
Mathieu Weill
&lt;<a href="mailto:mathieu.weill@afnic.fr">mathieu.weill@afnic.fr</a>
&gt; wrote:<br><br>
Hi Chris, <br><br>
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. <br><br>
Le 29/07/2015 06:50, Chris Disspain a écrit :<br>
<blockquote type=cite class=cite cite=""><br>
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. <br><br>
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. <br>
</blockquote>I note that it would require unanimity outside of ALAC to
veto the budget in that scenario.&nbsp; Worth questioning whether that is
a useful safeguard or an interference into the matters of ALAC. <br><br>
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. </blockquote><br>
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.<br><br>
<br><br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite="">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. <br>
</blockquote>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 &quot;horse-trading&quot; or
&quot;cross community coordination in the budgetary process”.
</blockquote><br><br>
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.<br><br>
<blockquote type=cite class=cite cite=""><br>
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. </blockquote><br>
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.<br><br>
<blockquote type=cite class=cite cite=""><br>
I understand the intent of the WS2 item on the budget process to be
intended to look at these coordination issues. <br><br>
Best<br>
Mathieu <br><br>
<blockquote type=cite class=cite cite="">Is this really what we want to
set up?<br><br>
<br>
Cheers,<br><br>
Chris<br><br>
<blockquote type=cite class=cite cite="">On 29 Jul 2015, at 03:02 , Greg
Shatan
&lt;<a href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>
&gt; wrote:<br><br>
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).&nbsp; 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.&nbsp; 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.&nbsp; These should continue to be
improved.&nbsp; One continuing shortcoming is that we are all still
supplicants, beseeching ICANN finance for a little more pie.&nbsp; 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.&nbsp; 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 &quot;kind requests.&quot;<br><br>
The budget veto is a final backstop in the event of a budget that
fundamentally is at odds with where it should be.&nbsp; The budget veto
should not be viewed primarily as a power, as much as an admonishment, to
add discipline the budget process.&nbsp; It should constrain the Board
from delivering a &quot;veto-able&quot; budget.&nbsp; The best way to
avoid that, of course, is communication with and due consideration of the
need of the community throughout the process.&nbsp; <br><br>
One other note -- there seems to be a misunderstanding of what a
&quot;non-profit corporation&quot; (and why it is called
&quot;non-profit&quot;).&nbsp; A &quot;for-profit&quot; corporation pays
out net profits to its owners (shareholders or other types of
owners).&nbsp; A non-profit does not have owners or shareholders, so it
does not pay out profits to anybody.&nbsp; While an entity can be &quot;
non-profit,&quot; this does not mean it is &quot;non-surplus.&quot;
&quot;Non-profit&quot; 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.&nbsp; So, this idea of &quot;balance&quot; is
misplaced.&nbsp; 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.&nbsp; 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.&nbsp; It's entirely fair to talk about the
numbers, but we should be careful not to bring in presumptions that don't
exist.&nbsp; [Caveat: I'm not referring to charitable organizations,
which are often referred to as non-profits as well.]<br><br>
Greg<br><br>
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez
&lt;<a href="mailto:crg@isoc-cr.org">crg@isoc-cr.org</a>&gt; wrote:<br>

<dl>
<dd>Dear George,<br><br>

<dd>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…)<br><br>

<dd>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.<br><br>

<dd>On the other hand, it is up to management to guarantee the financial
BALANCE&nbsp; 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).<br><br>

<dd>This would be in my view a much more effective system of so called
“checks and balances”&nbsp; 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.<br><br>

<dd>Best<br><br>
<br>

<dd>Carlos Raúl Gutiérrez<br>

<dd>_____________________<br><br>

<dd><a href="mailto:crg@isoc-cr.org">email:
</a><a href="mailto:crg@isoc-cr.org">crg@isoc-cr.org</a><br>

<dd>Skype: carlos.raulg<br>

<dd><a href="tel:%2B506%208837%207173">+506 8837 7173</a> (cel)<br>

<dd><a href="tel:%2B506%204000%202000">+506 4000 2000</a> (home)<br>

<dd><a href="tel:%2B506%202290%203678">+506 2290 3678</a> (fax)<br>

<dd>_____________________<br>

<dd>Apartado 1571-1000<br>

<dd>San Jose, COSTA RICA<br><br>
<br><br>
<br><br>
<br><br>
<blockquote type=cite class=cite cite="">
<dd><a href="mailto:george.sadowsky@gmail.com">On Jul 27, 2015, at 9:30
AM, George Sadowsky
&lt;</a><a href="mailto:george.sadowsky@gmail.com">
george.sadowsky@gmail.com</a>&gt; wrote:<br><br>

<dd>All,<br><br>

<dd>These are my personal opinions.<br><br>

<dd>I suspect that the reaction to this post will be, &quot;we are way
past this, we've discussed this, and now just help us work on the
implementation details.&quot;&nbsp; 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.&nbsp; <br><br>

<dd>When this process started, there was general agreement that it was
more important to do this right than to do it quickly&nbsp;
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.&nbsp; 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.<br><br>

<dd>So here's what I'd like to contribute ...<br><br>

<dd>I've been uncomfortable with the notion of budgetary control/veto
since the idea was first presented.&nbsp; 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.&nbsp; Let me explain.<br><br>

<dd>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.&nbsp; I don't think that's the case here, although I suppose
that under exceptional circumstances it might be.<br><br>

<dd>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&nbsp; --&nbsp; control over approval of the
aggregate budget&nbsp; --&nbsp; as your tool to accomplish this.&nbsp; If
that's the case, then what you really want is programatic control, not
budgetary control.&nbsp; 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.&nbsp; <br><br>

<dd>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.&nbsp; Any budgetary control after
that is micromanagement.&nbsp; 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.<br><br>

<dd>I suggest pursuing this line of argument further.&nbsp; 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.&nbsp;&nbsp; I see the
mechanism as starting with a lack of trust&nbsp;&nbsp; --&nbsp; in Board,
management, staff, as well as the ACs and the SOs and their constituent
parts&nbsp; -- 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
&quot;me&quot; (whoever I am) well and is therefore out of control.&nbsp;
<br><br>

<dd>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.<br><br>

<dd>The budget rejection process that is being defined by the group is
IMO based more upon defining ultimate (&quot;nuclear&quot; if you like)
confrontation mechanisms than upon finding cooperative mechanisms to
identify and resolve potential conflicts at an earlier stage.&nbsp; 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.&nbsp;&nbsp;
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?&nbsp;&nbsp; It does not appear
so to me.<br><br>

<dd>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.&nbsp; However, I sense that is not the way in
which it is planned to be employed.&nbsp; If so, it solves the wrong
problem, nad it does not address the real problem.&nbsp;&nbsp; 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.&nbsp;
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.<br><br>

<dd>Please consider these thoughts in your discussions.<br><br>

<dd>George<br><br>
<br><br>
<br><br>
<br><br>

<dd>_______________________________________________<br>

<dd>Accountability-Cross-Community mailing list<br>

<dd><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>

<dd>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote><br><br>

<dd>_______________________________________________<br>

<dd>Accountability-Cross-Community mailing list<br>

<dd><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>

<dd>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
<br><br>

</dl><br>
_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
<a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote><br><br>
<br><br>
<pre>_______________________________________________
Accountability-Cross-Community mailing list
<a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</pre></blockquote><br><br>
<pre>-- 
*****************************
Mathieu WEILL
AFNIC - directeur général
Tél: +33 1 39 30 83 06
<a href="mailto:mathieu.weill@afnic.fr">mathieu.weill@afnic.fr</a>
Twitter : @mathieuweill
*****************************
</pre></blockquote><br>
_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
Accountability-Cross-Community@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote></body>
</html>