Howdy,
Responses inline.
At 1:28 AM -0400 9/8/04, John C Klensin wrote:
Ted,
Let me try to briefly start from your assumptions and explain
why one might reach the opposite conclusion. Before I go on,
I'm assuming that your conclusion really implies "organization
separate from ISOC" rather than "separate organization within
some ISOC framework". There are scenarios for the latter with
which I'd be perfectly comfortable.
For starters, I'm a fan (if that term can be applied to a
relatively dismal approach to things) of risk and cost-benefit
analyses in a "whole system" environment. If a magic wand
could be found that would assure an instant and smooth
transition from wherever we are today to whatever state we would
like to end up in, while simultaneously holding Murphy's Law at
bay, and, in particular...
* providing our volunteer leadership with both a lot of
extra cycles without subtracting those cycles from the
standards process, and
* providing that same leadership with executive
management skills for which they were not selected and
that, to be blunt, are not in evidence, and
If you mean by the two points above the "existing volunteer
leadership", this is exactly contrary to the point of functional
differentiation. I heartily agree that role of "manage the
standards process" and "manage the public policy outreach"
and "manage the site selection process" are very different
skills. The point is to get different people into the roles,
so they can do them well.
I think we both agree that doing this well is not the IESG's
forte. I think we disagree in that I don't see it as ISOC's forte
either, and I'm not sure why you do. You know the history
of ISOC's finances, especially related to meeting management.
Would not the IETF administrative entity or ISOC need to
_hire_ the key people for this?
* guaranteeing that the IRS would instantly award
tax-exempt status to the new entity, avoiding a
prolonged period in which we needed to collect circa
1.75 times the amount of money we needed to operate
(contrary to the usual 12-24 months or longer it takes
to get that status if there are no hitches) and escrow
the tax reserve, and
This point and the related points below on donors and credit
ratings are very important, but they are also very short term in an
organization with a 25 year history and aiming for permanence.
Building the relationships around these problems is not good
planning, in my personal opinion.
* guaranteeing that the corporations and organizations
who have generously supported the IETF via ISOC would be
immediately willing to support an untried new entity at
double (or more) the funding level when their history of
the last several years with ISOC has been to push back
on funding requests until and unless ISOC and the IETF
could get a model into place that was sustainable at a
much lower level of donations, and
* guaranteeing that, with the same leadership steering
the administrative entity that steers the standards
process (there are other models, and I hope to be able
to circulate a proof-of-concept strawman within the next
few days, but all of Carl's scenarios basically assume
that relationship as, more or less, RFC 3716 did)
doesn't get us into difficulties with either tax status,
perceived conflicts of interest, or control/capture by
donors,
One: I personally assume that day to day management is done by
someone else than those managing the standards process, because
doing so otherwise is deeply, deeply broken. Two: an administrative
entity whose only purpose is to "keep the chips up" in the
felicitous phrase of Bernard Woolley is not one where capture
has the same level of concern as it would if both the standards
process and the administrative entity were united. In other
words, keeping ISOC (with its existing role in the standards
process) separate from the Administrative entity is a better
hedge against capture than combining them would be.
* guaranteeing that we could actually (and quickly) find
and hire an Administrator and supporting staff (while
the proposal claims "one person" that actually isn't
what it says), including sorting out benefits and
status, etc., and that the Administrator and staff could
quickly and smoothly get things up and running while
resisting micromanagement from the volunteer leadership
and/or the community, and
This is not an insurmountable problem in my eyes; it's a hiring
decision. Basing a long term decision on its difficulty doesn't
make sense to me.
* guaranteeing that hotel and meeting facilities would
be willing to book facilities at more or less current
deposit/ advance payment rates when the booking
organization has _no_ credit rating (or that we could
transfer that booking responsibility to another
organization that would be willing to assume that level
of risk on our behalf without additional compensation).
... and so on. That isn't the whole list, but it perhaps starts
to make the point.
Now, if someone supplied that particular high-potency magic
wand, then I'd probably agree that a separate structure would
make things cleaner and more obvious (not necessarily better in
the grand scheme of things, but at least reasonable). But,
from a risk analysis standpoint, even the abbreviated list above
is a pretty long list. If any one of those assumptions (or any
of several of those not listed) is not met and things go
seriously wrong, the odds of the standards process grinding to a
complete halt -- think "no meetings", "no IESG phone calls",
and/or "even less functional mailing lists and archives" as
examples-- are non-trivial.
You are asking for a high-potency magic wand. In fact, what
we are looking for is energy. The energy to get this done
right can be found in our community; there are enough people
who care about it to make sure it happens. There are nightmare
scenarios here, and I am sorry if they trouble your nights. But
there are nightmare scenarios in any transition here. The
basic point remains: we need to make sure that people can
focus on their real jobs. ISOC has a job in education, outreach,
policy making, and standards. Adding "keeping the chips up"
for critical computer systems, meeting planning, and the related
support systems does not make sense. The jobs just aren't
congruent enough to support the connection.
Again, just two cents from an IETF participant,
regards,
Ted Hardie
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf