Functional differentiation and administrative restructuring

Ted Hardie <> Wed, 08 September 2004 02:06 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA27767; Tue, 7 Sep 2004 22:06:11 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C4ruE-0005An-Au; Tue, 07 Sep 2004 22:09:54 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C4ro5-0003m4-Eb; Tue, 07 Sep 2004 22:03:33 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C4rkf-00039i-LN for; Tue, 07 Sep 2004 22:00:01 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id VAA27363 for <>; Tue, 7 Sep 2004 21:59:59 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C4roE-00053P-0M for; Tue, 07 Sep 2004 22:03:42 -0400
Received: from ( []) by (8.12.10/8.12.5/1.0) with ESMTP id i881xR1i029532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <>; Tue, 7 Sep 2004 18:59:28 -0700 (PDT)
Received: from [] ( []) by (8.12.10/8.12.5/1.0) with ESMTP id i881xPUV028680 for <>; Tue, 7 Sep 2004 18:59:26 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06110413bd640a63bcb8@[]>
Date: Tue, 07 Sep 2004 18:59:24 -0700
From: Ted Hardie <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Subject: Functional differentiation and administrative restructuring
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15

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,
					Ted Hardie

Ietf mailing list