Subject: Consensus? Separate bank account

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 08 Dec 2004 23:11:21 +0100

After all this threading, it seems clear that it would be bad to send out 
the Last Call today as planned without settling this issue.
(Not to mention that the secretariat still hasn't posted version -02)

So - scanning back - I find that we have Bert's suggestion for "principle" 
that seems to have met with no strong disfavour:

   Once funds or in-kind donations have been credited to the IETF accounts,
   they shall be irrevocably allocated to the support of the IETF.

(Scott preferred my variant:

    Donations to the IETF shall be irrevocably committed to the support of
    the IETF

but I don't - this does not cover meeting fees)

So I propose the following consensus text - relative to bcp-02, which is 
visible on 
<http://www.alvestrand.no/ietf/adminrest/draft-ietf-iasa-bcp-02.html>:

a) Add under "Principles", section 2.2, between item 4 and 5:

   Once funds or in-kind donations have been credited to the IETF accounts,
   they shall be irrevocably allocated to the support of the IETF.

b) Note, but DO NOT CHANGE, the following statements from section 5.
I believe they address the suggestions Margaret has made for a more 
detailed specification of money moving into and out of the accounts.

5.2 IETF Meeting Revenues

Meeting revenues are an important source of funds for IETF functions. The 
IAD, in consultation with the IAOC, sets the meeting fees as part of the 
budgeting process. All meeting revenues shall be credited to the 
appropriate IASA account.

5.3 Designated Donations, Monetary and In-Kind

.....
ISOC shall create appropriate administrative structures to coordinate such 
donations with the IASA. In-kind resources are owned by the ISOC on behalf 
of the IETF and shall be reported and accounted for in a manner that 
identifies them as such. Designated monetary donations shall be credited to 
the appropriate IASA account.

5.4 Other ISOC Support

Other ISOC support shall be based on the budget process as specified in 
Section 6. ISOC shall credit the appropriate IASA accounts at least 
quarterly.

....

5.5 IASA Expenses

The IASA exists to support the IETF. Therefore, only expenses related to 
supporting the IETF may be debited from the IASA account.

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 08 Dec 2004 18:35:20 -0800

As near as I can tell, there is no argument that IETF money or assets 
should be kept for use by/on behalf of the IETF - should not be spent on 
other things, and should be accounted for appropriately. The language you 
reference seems to deal with various ways to phrase that. However it is 
phrased, I suspect we all agree on that.

What I understood the question to be was whether one would use generally 
agreed accounting principles in doing so - for example, not mingling 
designated funds with general funds in a common checkbook, and whether the 
words "account" or "accounts" mean "separate bank account" or "set of 
ledger accounts among the chart of accounts in accordance with normal 
accounting practice".

This shows up in section 3.1, where the IAD maintains "an account", and in 
section 5, which at times uses "accounts", in the plural and indicating a 
normal corporate set of ledger accounts, and at other times uses "account", 
in the singular, apparently conceptualizing a personal checkbook. I would 
like to read both of these as specifying that there will be an appropriate 
set of ledger accounts (plural, in the sense that a General Ledger program 
uses the term) as described in section 5.1, and not detailing whether the 
storage vehicle is a single checkbook, a checkbook and a savings account, 
or some other combination of bank vehicles.

I think you want to leave the details of the bank accounts to the financial 
folks discretion, as the right approach may change from time to time. You 
just want to be very clear on what is the IETF's and what isn't, and be 
able to review/report the ledger accounts when you need to.

At 11:11 PM 12/08/04 +0100, Harald Tveit Alvestrand wrote:
>identifies them as such. Designated monetary donations shall be credited 
>to the appropriate IASA account.
>
>5.4 Other ISOC Support
>
>Section 6. ISOC shall credit the appropriate IASA accounts at least quarterly.
>
>....
>
>5.5 IASA Expenses
>
>This message was passed through [email-masked], which 
>is a sublist of [email-masked]. Not all messages are passed. Decisions on 
>what to pass are made solely by IETF_CENSORED ML Administrator 
>([email-masked]).

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Dec 2004 07:53:40 +0100

--On onsdag, desember 08, 2004 18:35:20 -0800 Fred Baker <[email-masked]> 
wrote:

> designated funds with general funds in a common checkbook, and whether
> the words "account" or "accounts" mean "separate bank account" or "set of
> This shows up in section 3.1, where the IAD maintains "an account", and
> in section 5, which at times uses "accounts", in the plural and
> indicating a normal corporate set of ledger accounts, and at other times
> uses "account", in the singular, apparently conceptualizing a personal
> checkbook. I would like to read both of these as specifying that there
> will be an appropriate set of ledger accounts (plural, in the sense that
> a General Ledger program uses the term) as described in section 5.1, and
> not detailing whether the storage vehicle is a single checkbook, a
> checkbook and a savings account, or some other combination of bank
> vehicles.
>
> I think you want to leave the details of the bank accounts to the
> financial folks discretion, as the right approach may change from time to
> time. You just want to be very clear on what is the IETF's and what
> isn't, and be able to review/report the ledger accounts when you need to.

Agreed - I thought this was already OK with the addition of section 5.1 on 
"Divisional accounting", so I did not suggest a change for it. Do we need 
to make a global pass of s/account/accounts/?

                             Harald

---

From: Fred Baker <[email-masked]>
Date: Thu, 09 Dec 2004 02:27:00 -0800

At 07:53 AM 12/09/04 +0100, Harald Tveit Alvestrand wrote:
>Do we need to make a global pass of s/account/accounts/?

I think so.

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Dec 2004 18:26:08 -0500

Harald,

This is purely a procedural question, but my interpretation of
the note below and the general support your suggestion has
gotten is that the document that is actually being last-called
is not draft-ietf-iasa-bcp-02.txt, as identified in the Last
Call posted yesterday afternoon, but a hypothetical document,
draft-ietf-iasa-bcp-02-bis.txt, which consists of the I-D as
modified by assorted comments and agreements on the IETF mailing
list or perhaps elsewhere.

Is that your intent?

If so, I am at least mildly concerned: normally, we have Last
Call reviews against stable documents, not documents that are
still actively changing, much less virtual documents in which
significant  changes are being made out of band and in a way
that is very hard for someone casually participating in the IETF
to track.  Do you have a better suggestion?  Can  we expect a
-03 for final review halfway through the Last Call window, with
the window being restarted if the changes are significant enough?

     john

--On Wednesday, 08 December, 2004 23:11 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

> After all this threading, it seems clear that it would be bad
> to send out the Last Call today as planned without settling
> this issue.
> So - scanning back - I find that we have Bert's suggestion for
> "principle" that seems to have met with no strong disfavour:
> 
> So I propose the following consensus text - relative to
> bcp-02, which is visible on
> I believe they address the suggestions Margaret has made for a
> more detailed specification of money moving into and out of
> the accounts.
> 
> Meeting revenues are an important source of funds for IETF
> functions. The IAD, in consultation with the IAOC, sets the
> meeting fees as part of the budgeting process. All meeting
> revenues shall be credited to the appropriate IASA account.
> 
> ISOC shall create appropriate administrative structures to
> coordinate such donations with the IASA. In-kind resources are
> owned by the ISOC on behalf of the IETF and shall be reported
> and accounted for in a manner that identifies them as such.
> Designated monetary donations shall be credited to the
> Other ISOC support shall be based on the budget process as
> specified in Section 6. ISOC shall credit the appropriate IASA
> accounts at least quarterly.
> 
> ....
> 
> 5.5 IASA Expenses
> 
> The IASA exists to support the IETF. Therefore, only expenses
> related to supporting the IETF may be debited from the IASA
> account.
> 
> 
>

---

From: [email-masked]
Date: Sat, 11 Dec 2004 12:58:54 +0100

Hi,

I agree it does seem procedurally a little skewed.

But in thinking about it, I feel that this may not end up a problem as 
long as one thing happens.  That is, if -03 (the 02-bis you refer to) 
is different in any substantive manner, i.e. other then editorial, it 
will need to go through a second call before the IESG can decide on it. 
  I.e,, as you said, as soon as an -03 that is substantially different 
comes out, the LC clock restarts.

I think getting this into wider community review, i.e. due to LC, is a 
good thing to do at this point, even while some of us, myself included, 
continue to argue on particular points we are uncomfortable with.

a.

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 11 Dec 2004 07:17:16 -0500

Hi Avri and John,

I interpreted Harald's note differently than you did...

>>>  to send out the Last Call today as planned without settling

To mean that Harald is _not_ starting the IETF Last Call as scheduled.

When he does start the Last Call, I assume it will be clearer than 
this and that there will be an official, tracker-generated IETF Last 
Call message to go with it.

One of the side-effects of doing this work in the IETF at large is 
that I don't think we'll have two last call cycles (WG LC and IETF 
LC), I think we'll just have a 4-week IETF LC.  Also, the person who 
is currently declaring consensus on the document issues (Harald, in a 
chair-like capacity) will also end-up being the shepherding AD.  So, 
I am not sure how/if there will be an AD Review stage before IETF 
LC...

Margaret

At 12:58 PM +0100 12/11/04, [email-masked] wrote:
>But in thinking about it, I feel that this may not end up a problem 
>as long as one thing happens.  That is, if -03 (the 02-bis you refer 
>to) is different in any substantive manner, i.e. other then 
>editorial, it will need to go through a second call before the IESG 
>can decide on it.  I.e,, as you said, as soon as an -03 that is 
>substantially different comes out, the LC clock restarts.
>
>I think getting this into wider community review, i.e. due to LC, is 
>a good thing to do at this point, even while some of us, myself 
>included, continue to argue on particular points we are 
>uncomfortable with.
>
>a.
>
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 11 Dec 2004 16:19:16 +0100

> list or perhaps elsewhere.

Not really - I believe that -02 is close enough to what the IETF has 
consensus on that if we had to live with an unchanged -02 version, that 
would be acceptable to the IETF (but not optimal).

As with all Last Calls, the community members have the opportunity for two 
kinds of comments:

- To declare "no, we are not part of the consensus", and ask for the 
document to be significantly changed if the consensus agrees with the
- To suggest wording improvements, clarifications and procedures for 
handling of marginal situations that do not change the main thrust of the 
document.

The last class of comments, which also includes IESG comments when the 
document comes before the IESG, and adjustments to take those into account, 
is quite commonplace in our process - it is extremely common to have one or 
more versions of a document emitted between Last Call and final approval. 
If that happens relatively quickly, it's rare to reissue the Last Call.

> the window being restarted if the changes are significant enough?

I believe that we want to do three things to make sure the process is 
transparent and apparent to everyone:

- Keep the discussion on the IETF list (sorry, Mike!)
- Use the issue tracker at rt.psg.com actively
- Emit a "rolled up textual changes" version around December 23, which will 
hopefully be the same version that the IESG considers for approval on 
January 6.

If we have to make significant changes, we will have to restart the Last 
Call and push the establishment of IASA out by the requisite amount of 
time. But the reason I think it's appropriate to issue the Last Call now is 
that I don't think we have to make really significant changes - all the 
open issues I have currently seen on the IETF list is more or less of the 
form "I think this can be better expressed as...".

This is, of course, a judgment call, and I'm sure you'll read the document 
carefully and alert us if you think we're uncomfortably close to the 
boundary between "minor" and "significant".

BTW: Henrik Levkowetz has graciously volunteered to strengthen the editing 
team with more capacity to run the issue tracker. Thanks, Henrik!

                                     Harald

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Dec 2004 10:59:35 -0500

--On Saturday, 11 December, 2004 12:58 +0100 [email-masked] wrote:

> But in thinking about it, I feel that this may not end up a
> problem as long as one thing happens.  That is, if -03 (the
> 02-bis you refer to) is different in any substantive manner,
> i.e. other then editorial, it will need to go through a second
> call before the IESG can decide on it.   I.e,, as you said, as
> soon as an -03 that is substantially different comes out, the
> LC clock restarts.
> 
> I think getting this into wider community review, i.e. due to
> LC, is a good thing to do at this point, even while some of
> us, myself included, continue to argue on particular points we
> are uncomfortable with.

I think we generally agree.  I'm not opposed to doing it this
way and can see some advantages; I just think it is important
that we be extremely clear about what we are doing and that the
final result really reflects community consensus.   Seeing a
note from Harald that seemed to explain why were weren't quite
ready for a Last Call and then a Last Call announcement is, to
me, the sort of thing that calls for comment.

While I appreciate the importance of the planned schedule, I
think that, for many reasons, the perceived fairness of the
process -- and all of the IETF integrity issues that rest on
it-- requires that intermediate document, requires an
interpretation of whether it contains any substantive changes
that resolves any uncertainty in favor of an extended Last Call,
and requires the IESG not apply any post-last-call "fixes" to
the document (or at least not any that any reasonable person
could consider substantive) without reopening the last call
process.

As long as we are very careful about those things, and we are
clear about how the decisions are being made, I have no
procedural problems.

   john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 13 Dec 2004 07:13:53 +0100

just a small followup re timing.... I've said most of what I have to say on 
this issue....

> me, the sort of thing that calls for comment.

My thinking between the Wednesday note (which said "we can't send out the 
Last Call today") and the Thursday Last Call was that we had a proposed 
resolution of the issue that seemed to be accepted and was not (in my 
judgment) a significant change to the document - so I figured it was "close 
enough", and emitted the Last Call.

The previous schedule had the Last Call being emitted on Wednesday.
See Thursday's Last Call notice and my Saturday response to John in this 
thread for the rest of my thinking.

                     Harald