Re: Functional differentiation

Bernard Aboba <> Thu, 09 September 2004 11:38 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id HAA09348; Thu, 9 Sep 2004 07:38:45 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C5NK9-0008Qz-6x; Thu, 09 Sep 2004 07:42:45 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C5N7h-0004mX-MW; Thu, 09 Sep 2004 07:29:53 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C5DPJ-0005Uz-0b for; Wed, 08 Sep 2004 21:07:25 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id VAA08670 for <>; Wed, 8 Sep 2004 21:07:23 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.33) id 1C5DT2-0007Go-GK for; Wed, 08 Sep 2004 21:11:18 -0400
Received: from localhost (aboba@localhost) by (8.10.2/8.10.2) with ESMTP id i8910Ab11514 for <>; Wed, 8 Sep 2004 18:00:10 -0700
Date: Wed, 08 Sep 2004 18:00:10 -0700
From: Bernard Aboba <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
X-Mailman-Approved-At: Thu, 09 Sep 2004 07:29:52 -0400
Subject: Re: Functional differentiation
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: 944ecb6e61f753561f559a497458fb4f

I think there is an assumption in Ted's message below that needs to be
explicitly called out.

That is the distinction between the entity that handles IETF
administration and the organization(s) that actually do the administrative
work: organizing meetings & teleconferences, administrating web sites &
mailing lists, etc.

At the moment, we are discussing various scenarios for housing the entity
that handles IETF administration.  This is a different question from who
does the work.  In the scenarios in which the ISOC takes on a significant
administrative role, I would caution against having ISOC simultaneously
take on one or more major roles as an IETF contractor -- since this
violates the principle of "arms length" dealings.

Given this, the following sentence confuses me:

"But that does not mean ISOC should take over worrying about
the IETF's administrative details."

Even in Scenarios A or B, the ISOC acts as an administrator of contracts
with entities who do the work -- but my assumption is that the ISOC is not
itself responsible for administrative details such as agendas for
biweekly IESG meetings or scheduling of WGs.

For example, today the ISOC contracts with USC/ISI for the RFC Editor
function, but the ISOC is not involved in the day to day administrative
details of the RFC Editor.

Given this, the question we should be asking is whether the ISOC is suited
to expanding its role as an administrator of contracts on behalf of the


Ted Hardie said:

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