Subject: IASA Finances - an attempt at some uplevelling

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 10 Jan 2005 16:31:07 +0100

We have had a number of issues that circle around the financial model for 
the IASA. Some of these have been fairly nitpick-level, others have been 
more matters of principle, others are really hard to tell.

In order to get the discussion to a place where we can reach some 
conclusions, it might be worthwhile to try to take the discussion to a bit 
higher level.

The IASA model of finances, as presented in the BCP, is this one:

Money comes from a number of places, which can be grouped roughly as:

A - Money from meeting fees
B - Money from designated donations
C - Money from ISOC funds
D - Money left in IASA account at end of previous year

Similarly, the money goes to just a few places

X - Money spent in support of the IETF
Y - Money left by the end of the year (positive balance)

By the end of the year, A + B + C + D = X + Y (by the theory of accounts)

At the beginning of the year, we have a budget that estimates each of those 
- set by the IASA to cover the IETF's needs, approved and committed to by 
ISOC. At the moment, the assumption is X > A + B, A+B+C = X, Y=0 (we are 
not budgeting for fund-building in IASA, and we need support from ISOC 
income not specifically earmarked for the IASA).

This is accounted for using "divisional accounting", which has nothing to 
do with which bank accounts the cash balance is kept in. It's all books.

We all agree that money coming in as A and B and not spent on X is kept on 
an IASA account. So we have agreed that IASA can carry a positive balance - 
we do not require that Y is zero.

Disagreements surfacing as tickets:

- #737: How should donations be designated for IETF (that is, marked as B 
rather than C)? Currently, only Platinum sponsors' yearly dues may be 
marked in the "B" category; the BCP mentions the possibility of having 
other types of donation (smaller sums, non-yearly sums) designated as such.

- #748: At what times of the year is the C money put on the books? 
Alternatives are:
 - At budgeting/beginning of year
 - On a regular schedule
 - As bills are paid
 - At the end of the year
This really only affects two things: The numbers in the monthly report and 
the possibility of reducing C during the year. Money DOES NOT MOVE between 
real physical accounts because of this.

- Also #748: How are budget changes during the year handled? Who approves 
them, and how do changes in X affect changes to C? If X goes up, C goes up. 
If X goes down, or A and B go up - is C changed (making more money 
available to ISOC's other activities), or does C stay unchanged 
(accumulating money that comes in from C in the IASA account)?

- #722: What happens (in particular, what happens to C) if we split?

- #740: When ISOC holds reserves in case of emergency (outside of the group 
D money above), how is that shown in the reports on the IASA?

- #732: Raising money costs money. Are those costs skimmed off before money 
arrives from ISOC (reduction in C) and/or charged against designated 
donations (reducing B), or carried as an extra expense item?

- #721: How do we describe the fact that IASA can request audits, and say 
what it wants to audit for?

- #745, 749, 750: How much detail should the BCP give on the 
sync/discussion between IASA budgeting and ISOC budgeting?

So far, it's mainly a summary of what's in the BCP now. So let's see if 
it's possible to extract some more / clearer information at the principles 
level.... what follows is my personal thoughts about what these principles 
are, and how we need the BCP to reflect them.

Reserves
--------
Stepping back a bit, I think there are two kinds of reserves we need to 
consider:

- The money (let's call this the "backstop") that allow us to operate for a 
while if there is an unexpected shortfall of income. The reason for having 
that reserve is prudent contingency planning, and the BCP says that this 
financial capacity is provided by ISOC, by whatever means that ISOC wishes 
to provide it.

- The funds that consist of money earmarked for IETF work, but not yet 
spent (let's call this the "balance"). The reason for the existence of 
these is a question of fairness and proper accounting, not planning - when 
money is given to support the IETF, it needs to be clearly shown that it is 
retained for that purpose only.

The balance may form part of the backstop, but not the other way around - 
if ISOC provides a reserve out of non-designated money, using the ISOC line 
of credit or by other means, that money still isn't designated for IETF use 
in the absence of a crisis.

In the case of a split (should that ever be a reasonable thing to do), it's 
reasonably clear that the balance stays with the IETF-controlled entity, 
while what to do about the "backstop" reserve will depend on a number of 
factors, and certainly we can't describe all of them in this document.

I think that's what the document currently says. But I may have read it too 
many times.... some changes to make it even clearer suggested later.

Separable income
----------------
It's a relatively consistent message from the IETF community throughout the 
IASA discussions that "if people want to give money to support the IETF, 
then they should be able to do so - and see that this happens". There have 
been no requests for designating the funds more specifically than that.

This is a transparency issue, not a way to increase or decrease overall 
numbers. We have had the request from the community, and we need to answer 
it.

The overhead of this single separation should be reasonably low (I'd like 
to have ISOC estimate a cost in terms of "X dollars for the program and Y 
dollars per donation"), and the procedures fairly standard.

This needs to remain, IMHO.

We do have an issue with the fact that there are many activities that one 
could imagine ISOC doing that will be "grey" - not strictly IETF, but 
strongly linked to the IETF. I think we have to take this as it comes - the 
existence of "grey" does not remove the need to handle "black" and "white" 
in a transparent manner.

Where "cost of fundraising" is concerned - I think it's simplest in terms 
of showing people where the money goes if the cost of fundraising for the 
IETF is charged to the IASA, and a portion of the cost of fundraising for 
ISOC in general is charged to the IASA. But the important factor, the one 
that should get into the BCP, is that the cost of fundraising is reported.

Budgeting process
-----------------

I thnk we must allow ourselves to "learn to walk" here - the IASA and the 
rest of ISOC need to be allowed to work out these procedures together. The 
absolute requirement should be on the openness of the process - that the 
IETF community is able to see and understand who makes the decisions, at 
what time, and who's responsible for approving or changing them.

In that spirit, I think the best way forward on the tickets that deal with 
this process may be to say less, not more - give the freedom to work this 
out in a way that works in practice.

I think that this applies also to the question of changes in the allocation 
of money during the year. I'll just add one point here... if a large chunk 
of ISOC's unlabelled resources come from people who think that they are 
giving that in part for supporting the IETF, ISOC may find itself well 
served by allocating that money to the "committed IETF-designated funds", 
even though it does not have to. It makes things much easier to explain.

The exception to my "say less" injunction is the requirement for 
transparency - here, it seems reasonable to state that the transparency is 
needed, and that if the IAOC suspects that it does not get the right 
information, it can take steps (like a special audit) to do something about 
it.

Specific suggestion for text changes
====================================

Reserves
--------
Section 2.2 bullet 7, current:

   8.  The IASA shall establish a target for a reserve fund to cover
       normal operating expenses and meeting expenses in accordance with
       prudent planning, and ISOC shall work with the IASA to build up
       and maintain the reserve.

Under the principle of "state principles, not mechanisms", change to:

   8.  The IASA, in cooperation with ISOC, shall ensure that sufficient
       reserves exist to keep the IETF operational in the case of
       unexpected events such as income shortfalls.

All other details should be in section 5.6.
In section 5.6, change:

   Rather than having the IASA attempt to build that reserve in its
   separate accounts, the IASA looks to ISOC to build and provide that
   operational reserve, through whatever mechanisms ISOC deems
   appropriate: line of credit, financial reserves, meeting cancellation
   insurance, and so forth.  Such reserves do not appear
   instantaneously; the goal is to reach this level of reserves within 3
   years after the creation of the IASA.  Such funds shall be held in
   reserve for use by IASA for use in the event of IETF meeting
   cancellation or other unexpected fiscal emergencies.  These reserves
   shall only be spent on IETF support functions.

to:

   The IASA expects ISOC to build and provide that
   operational reserve, through whatever mechanisms ISOC deems
   appropriate: line of credit, financial reserves, meeting cancellation
   insurance, and so forth. Long term, financial reserves are preferred;
   it should be a goal for ISOC to reach this level of reserves within 3
   years after the creation of the IASA.

   If the IASA account accumulates a surplus, ISOC may count that as
   part of the reserve.

IASA accounts
-------------
In section 7 (Removability), change:

      Any accrued funds, any IETF-specific intellectual property rights,
      and any IETF-specific data and tools shall also transition to the
      new entity.

to

      Any IASA account balance, any IETF-specific intellectual
      property rights, and any IETF-specific data and tools shall also
      transition to the new entity. Other terms of removal shall be
      negotiated between the non-ISOC members of the IAOC and ISOC.

(the last point is an afterthought. It seems strange to have ISOC members 
negotiating with ISOC in the case of a separation. While I don't expect to 
have to use that paragraph, many have argued that it's better to get it 
written properly while we're starting than to wait until we need it.)

This is just the text for addressing the funds stuff - I'll write up a 
couple of other notes for the other issues, if the general 
description/method/view finds favour on the IETF list.

Comments?

                   Harald

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Jan 2005 18:18:20 +0200

> Money comes from a number of places, which can be grouped roughly as:
(snip)
> Y - Money left by the end of the year (positive balance)
(snip)
> At the beginning of the year, we have a budget that estimates each of 
(snip)

All this makes sense.

> - The money (let's call this the "backstop") that allow us to operate 
> for a while if there is an unexpected shortfall of income. The reason 
> for having that reserve is prudent contingency planning, and the BCP 
> says that this financial capacity is provided by ISOC, by whatever means 
> that ISOC wishes to provide it.
> 
> these is a question of fairness and proper accounting, not planning - 
> when money is given to support the IETF, it needs to be clearly shown 
> that it is retained for that purpose only.
> 
> The balance may form part of the backstop, but not the other way around 
> - if ISOC provides a reserve out of non-designated money, using the ISOC 
> line of credit or by other means, that money still isn't designated for 
> IETF use in the absence of a crisis.

Right.

> In the case of a split (should that ever be a reasonable thing to do), 
> it's reasonably clear that the balance stays with the IETF-controlled 
> entity, while what to do about the "backstop" reserve will depend on a 
> number of factors, and certainly we can't describe all of them in this 
> document.

If the document already says that the backstop is provided
by the ISOC, is there any case where it would NOT be left
also at the ISOC in case of a split? This seems simple to
me but maybe I missed something...

> Separable income
> ----------------
> It's a relatively consistent message from the IETF community throughout 
> the IASA discussions that "if people want to give money to support the 
> IETF, then they should be able to do so - and see that this happens". 
> There have been no requests for designating the funds more specifically 
> than that.
> 
> numbers. We have had the request from the community, and we need to 
> answer it.

I agree.

> Where "cost of fundraising" is concerned - I think it's simplest in 
> terms of showing people where the money goes if the cost of fundraising 
> for the IETF is charged to the IASA, and a portion of the cost of 
> fundraising for ISOC in general is charged to the IASA. But the 
> important factor, the one that should get into the BCP, is that the cost 
> of fundraising is reported.

Yes.

> Budgeting process
> -----------------
> 
> I thnk we must allow ourselves to "learn to walk" here - the IASA and 
> the rest of ISOC need to be allowed to work out these procedures 
> together. The absolute requirement should be on the openness of the 
> process - that the IETF community is able to see and understand who 
> makes the decisions, at what time, and who's responsible for approving 
> or changing them.
> 
> In that spirit, I think the best way forward on the tickets that deal 
> with this process may be to say less, not more - give the freedom to 
> work this out in a way that works in practice.

I agree.

> Specific suggestion for text changes

Ok.

>   If the IASA account accumulates a surplus, ISOC may count that as

Ok.

> IASA accounts

Ok.

--Jari

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Jan 2005 12:23:03 -0500

--On Monday, 10 January, 2005 16:31 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

>...
> (the last point is an afterthought. It seems strange to have
> ISOC members negotiating with ISOC in the case of a
> separation. While I don't expect to have to use that
> paragraph, many have argued that it's better to get it written
> properly while we're starting than to wait until we need it.)

Harald, I may have other thoughts on your other suggestions as I
think more about them, but this strikes me as just wrong.  There
are many people who are members of ISOC who are members because
it seems like the Right Think to Do, with or without the former
$35 fee.  Many people became members by virtue of attending one
conference or another, and are still on the rolls since the
membership fee was eliminated and everyone was carried forward.
Unless you want to make non-ISOC-membership a criterion for
anyone on the IAOC who is not appointed by ISOC --which I think
would be a very serious case of shooting ourselves in the foot--
you run the risk of every IAOC member being also an ISOC member,
leaving no one to negotiate or, worse, leaving only one or two
people to "represent" all IETF interests.

In addition, because this might discourage IETF participants
from becoming ISOC members, there is a case to be made that the
ISOC Board could not approve this without violating their duties
to ISOC.

It would be reasonable to exclude any person who has a position
of authority or responsibility within ISOC's structure from
participating on both sides of a negotiation (or negotiating for
the IETF if you want to force them to the other side), excluding
any ISOC member feels to me like it is both excessive and dumb.

I'd look to Lynn or Fred for an acceptable way to state
"position or authority or responsibility" in the ISOC context.
I don't know what would work and be stable as they evolve their
management and volunteer structures.

     john

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 10 Jan 2005 14:07:50 -0500

John,

I believe Harald meant ISOC-appointed members of the
IAOC, and not "folks on the IAOC who happen to be ISOC
members".  (Hopefully, everyone on the IAOC will be
an ISOC member...).

That said, I'm not entirely comfortable with the proposal.
I don't want to belabour it, because I don't want to
give particular importance to something that is intended
to be an edge case.

I would suggest that the right way to handle it is, either:

. to note that this will be rife with potential for
   "conflict of interest", and that IAOC members appointed
   (or ex officio) by ISOC are expected to recuse themselves
   from discussion of separation issues (this should
   amount to what Harald has said, but phrases it in terms
   of more normal operating procedures); or

. define a new committee, that is not the IAOC, but the
   IETF-specific subset (+ others, as necessary).

Leslie.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 10 Jan 2005 20:20:20 +0100

Apologies for the bad parse.

When I said "non-ISOC member", I intended to say "the members of IAOC who 
are not representing ISOC", not "not a member of ISOC".

Having the ISOC President have a formal role in representing the IETF when 
discussing how to dissolve the relationship between ISOC and the IETF 
doesn't sound right. The ISOC-appointed representative is less obvious to 
me - the BCP says that he/she does not represent ISOC.

                   Harald

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Jan 2005 16:27:25 -0500

>    IETF-specific subset (+ others, as necessary).

I'm in complete agreement with the above.  And I think I prefer
your second formulation, if only because the right group of
people to serve on a disentangling committee may not be the same
people who have been selected to sit on the IAOC, regardless of
how they are selected.

In an odd way, that also makes the question of what to put in
this document easier.   If we go back to the principle that
un-doing this agreement requires a new BCP, that hypothetical
document can specify the relevant arrangements and transition
structure as needed under the circumstances.   

That has another implication that may be important:  Presumably
any decision to undo the ISOC model should originate (at least
formally) within the IETF -- the IAOC, or a subset of the IAOC
should not have the authority to do it on its own.  If the IAOC
members, or a subset of them, are unhappy with ISOC, that should
be brought to the attention of the IETF.   And, if an un-doing
process starts with ISOC deciding to fold its tent or kick the
IETF out, it is again not clear that the members of the IAOC,
with or without restrictions, are the right ones to handle that
process -- the IETF community would almost certainly need to be
brought into the discussion.

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jan 2005 10:06:13 +0100

All of which suggests to me that Harald's contentious last
sentence should simply be removed.

btw I agree with all his other suggested changes.

    Brian