--On Saturday, January 15, 2005 11:00 PM -0500 Rob Austein <sra@xxxxxxx> wrote:
... On #3: I assume that "zero base" is a reference to "zero-base budgeting" (ZBB), a technical term in financial circles. I don't think we're using it literally, and agree that the usage is unclear.
Actually, it is also used in a variety of administrative contexts, see below.
I -think- the intent here is to say that anything done in-house has to be justified, not just initially but with periodic review. ZBB is basicly about forcing ongoing projects to justify themselves in the same way that new projects would have to when it comes time to do budgeting, so nobody gets to say "please give us $N because it's what we got last year." So I think the overall intent here is reasonable, but the phrasing needs work.
Mea culpa. I think I used the term in one of my notes without really intending that it be adopted literally into the text, then didn't catch it and correct when it was. The intent is not only that the projects be rejustified as if they were new, but with the assumption that, even if the projects are justified, they are entitled to zero staff (or any other resources) except insofar as the staffing can be justified at whatever level is appropriate.
How the text should be fixed depends a bit on what we do about that "outsourcing" assumption, to which I continue to object. If we can lose it, the paragraph might end up reading something like:
The IAOC is expected to determine what IETF
administrative functions are to be performed, and how or
where they should be performed (e.g., internally to the
IASC or by outside organizations), so as to maintain an
optimal balance of functional performance and cost of
each such function. The IAOC should document all such
decisions, and the
justification for them, for review by the community. Each
function should be reviewed on a regular basis, using the
assumption that the function is unnecessary and that, if
necessary, it is overstaffed, rather than an assumption
that anything that has been done is necessary, and
adjusted as needed.That probably still needs word smithing. The second sentence may be redundant enough with other statements in the BCP that it can be removed. And the last sentence is a bit long. But it is at least relatively jargon-free.
And, fwiw, I completely agree with you on the following: my preference would be to pull this out since, if the situation I think it is intended to deal with arises, it won't help. Any reserve that represents an ISOC guarantee, rather than IETF-collected funds (for which there are carry-forward provisions elsewhere) don't need to be "held" in any specific way, and it is undesirable to try to specify otherwise: the important thing is the guarantee. The IETF-collected funds don't really count against the reserve as that is now described in the document, they are just money that prevents the reserve from being needed/used. If one is contemplating a break in the relationship, IETF-collected funds should belong to the IETF but it is unrealistic to expect ISOC to extend any guarantees against cost overruns past the point at which they lose all review capability over how we spend money, i.e., the point of divorce... and that has been covered elsewhere.
A previous version of the text for #4 read as if the IETF were demanding a dowery from ISOC, which really bothered me. The text in -04 isn't that bad, and the specific statement that the "surplus" (if any) can count against the "reserve" is a step in the right direction, but the current version still reads a bit like the IETF giving ISOC orders about how ISOC should spend ISOC money that comes neither from IETF meeting fees nor from designated donations, which is just wrong.
Telling ISOC how to spend IETF money is appropriate, but if folks from the IETF want to control how ISOC spends -other- ISOC money, they (we) should join ISOC, not put demands into this BCP. But maybe it really is just intended as a suggestion. If this is just a suggestion from the IETF to ISOC, it's badly phrased.
Personally, I don't think this needs to be in the BCP at all, but from comments I've seen it's obvious that others would disagree.
In any case, this is, at least in potential, a substantive issue, so we'd better settle it.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf