Re: Functional differentiation and administrative restructuring

[John C Klensin <[e-mail]>]

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
	
	* 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
	
	* 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,
	
	* 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

	* 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.

Now, by contrast, if we do this under an ISOC umbrella (really
expanding the existing umbrella somewhat) or, for that matter,
under a CRNI umbrella (if Bob Kahn hasn't gotten so completely
disgusted with us during this process that he would not consider
it), then the tax uncertainties go away, many of the
organizational uncertainties disappear, we have a sponsoring
organization that is not controlled by, or controlling of, the
standards process (a model that is used by every
non-government-based standards body in the world that I've been
able to identify), and we have a significant and tested safety
net under the other functions and risks.  

I think that is important, because I think that assuming that
the creation of a new structure and transition to it will go
rapidly, smoothly, and without a hitch is... well, words escape
me.  If the costs of making that assumption and having it not
turn out to be true were, at worst, some minor inconvenience,
then I think it might well be worth considering carefully.
But, as far as I can tell, the "separate organization" model
bets the entire survival of the IETF against a "nothing will go
wrong" assumption.  And that seems to me to be a bad choice...
unless there are no alternatives and independent of where
various styles of analysis lead us in some more perfect and
utopian world.

     john


--On Tuesday, 07 September, 2004 18:59 -0700 Ted Hardie
<[e-mail]> wrote:

> As many will remember from the IETF 58 plenary presentation,
> I'm
> a big fan of functional differentiation.  Though I try not to
> be
> dogmatic in its application, I believe there are a lot of
> cases where
> the creation of well-focused groups with limited goals is more
> successful than the creation of groups with larger scale but
> more
> diffuse goals.  I think it makes it easier to know what success
> will look like when a group does its job well; I think it
> makes it
> easier to train people to do those jobs, and I think it is
> easier to recruit people into the roles.
> 
> As I, personally, look at the choices in front of us for
> administrative
> restructuring, I find that preference manifesting itself in
> the question:
> 
> "In which of these scenarios do folks best get to concentrate
> on their real jobs?"
> 
> The conclusion I come to at the moment is that scenarios in
> which the
> administrative work is done by a different entity than ISOC
> meet the
> test better.  This isn't because I think ISOC isn't willing to
> do the work,
> or concern over disengagement, or anything to do with how ISOC
> relates to IETF as a standards-setting organization.  The work
> is
> just sufficiently different from the role I see for ISOC that
> I would
> rather we have ISOC and the administrative support entity  as
> two
> separate, functionally distinct organizations.
> 
> I want to see ISOC working to educate policy makers.
> I want to see ISOC educating engineers in emerging areas.
> I want to see ISOC fighting for freedom of expression on the
> net.
> 
> To me, those are ISOC's real job.  I think it is very, very
> important, and I think the existing relationship between the
> IETF and ISOC is an important part of making sure that
> ISOC can do that job.
> 
> But that does not mean ISOC should take over worrying about
> the IETF's administrative details. Worrying over the
> scalability
> of a ticket system is an administrative job.  Getting an
> agenda for
> biweekly meetings together in advance and minutes out after
> is an administrative job.  Worrying about the  scheduling of
> 130
> probably conflicting working groups into twelve rooms over 5
> days is
> an amazingly hard administrative job.  All of those jobs are
> critical to keeping the IETF functioning, and I value them all
> highly.  But the skills needed for them are not the same as
> policy
> outreach, or technical training, or editorial persuasion.
> 
> To put this in more IETF-typical terms, does this look like one
> area or two?  To me, two.  I recognize that there is an
> increased
> overhead in keeping two organizations going, but I think the
> benefit in focus is worth it.
> 
> Just two cents from an IETF participant,
> 				regards,
> 					Ted Hardie
> 
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf





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