--On Saturday, January 15, 2005 11:00 PM -0500 Rob Austein
<sra(_at_)isc(_dot_)org> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf