Re: Functional differentiation and administrative restructuring

[Ted Hardie <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf