[Top] [All Lists]

Re: Functional differentiation and administrative restructuring

2004-09-07 22:37:07

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


--On Tuesday, 07 September, 2004 18:59 -0700 Ted Hardie
<hardie(_at_)qualcomm(_dot_)com> wrote:

As many will remember from the IETF 58 plenary presentation,
a big fan of functional differentiation.  Though I try not to
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
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
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
just sufficiently different from the role I see for ISOC that
I would
rather we have ISOC and the administrative support entity  as
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

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
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
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
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
overhead in keeping two organizations going, but I think the
benefit in focus is worth it.

Just two cents from an IETF participant,
                                      Ted Hardie

Ietf mailing list

Ietf mailing list