IETF Administrative Reorganization: What was that problem anyway?

John C Klensin <> Tue, 14 September 2004 21:47 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id RAA24801; Tue, 14 Sep 2004 17:47:33 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C7LEC-00024F-UG; Tue, 14 Sep 2004 17:52:45 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C7Kvo-00068K-Al; Tue, 14 Sep 2004 17:33:44 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C7KbL-0000E2-Co for; Tue, 14 Sep 2004 17:12:35 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id RAA21710 for <>; Tue, 14 Sep 2004 17:12:33 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.33) id 1C7KgJ-0001G6-5g for; Tue, 14 Sep 2004 17:17:44 -0400
Received: from [] ( by with esmtp (Exim 4.34) id 1C7KbF-0001lM-Ky for; Tue, 14 Sep 2004 17:12:29 -0400
Date: Tue, 14 Sep 2004 17:12:29 -0400
From: John C Klensin <>
Message-ID: <>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb
Content-Transfer-Encoding: 7bit
Subject: IETF Administrative Reorganization: What was that problem anyway?
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: f60fbf3dbcaca652b6d10036f0630412
Content-Transfer-Encoding: 7bit

In trying to parse both Carl's document and the general
situation in the last few weeks, I've found myself getting
increasingly dissatisfied with the document and the discussion,
mostly with regard to ways in which the document has
constrained the discussion and was, itself, constrained by RFC
3716 (the "AdminRest" report) and what it is believed to say.
As a member of the committee that put 3716 together (but
speaking only for myself), I think it is subject to the same
sort of rules that apply to the relationship between our
"model" or "requirements" documents and subsequent actual
protocol work: if we discover in protocol development that the
models are inappropriate or unimplementable, we change the
models rather than considering ourselves locked to them.  In
fairness to Carl, this is an option he didn't have: the
contract held him fairly closely to RFC 3716.

Disclaimer: the comments below, and in my next note, draw,
without attribution, on a lot of virtual and physical
in-the-hall conversations.  I'll let the contributors identify
themselves if they like, but I probably could not do so
accurately and don't think it would be particularly helpful at
this point.   I have been working on these notes for a week or
so, and, while related pieces have shown up in on-list comments,
I've changed my mind several times about whether to send it.  A
few comments in the last 72 hours have convinced me it is time.

While I think the complexities of Carl's "simple" solution
calls for reconsidering some of the conclusions of 3716 (or at
least a more intensive community review of those conclusions),
that document hints at the issue here in its section 4.1:

   o  nevertheless, it remains a non-goal to create an
      organizational entity that exists simply for the purpose
	  of continuing to exist. This should be executed with the
	  minimum formality needed in order to address the
	  identified requirements. 

Stripped of a good deal of speculation about organizational 
structures and arrangements, the key to 3716 and the concerns
that surrounded it seems to me, again in retrospect, to be
exactly two problems:

	(1) For a number of policy and budgetary reasons, having two
	revenue sources that have to be kept isolated from each
	other lies on a scale between "suboptimal" and "nuts".  One
	of those streams is the meeting registration fees and their
	allocation to secretariat support as well as meeting costs.
	The other involves donations and other funds collected by
	ISOC and dedicated to non-Secretariat IETF support.

	(2) The IESG perceives that they are not getting adequate
	support for their work, and the standards process more
	generally, from the Secretariat and that, despite
	considerable effort, there has been little progress on
	solving that problem.  The efforts to do so go back many
	years, including six to eight years or more of unsuccessful
	attempts to work out a statement of relationships and
	authority, in the form of an MOU, with CNRI and then with
	Foretec.    As I have mentioned in another note, the key
	difficulties in that process seem to hinge on fundamental
	philosophical disagreements about the nature of the
	relationship.  Independent of the causes, details, and how
	we got here, some fraction of the IESG and IAB now believe
	that the relationship with the secretariat has become
	sufficiently poisoned that a significantly better
	relationship is not possible with the existing Secretariat
	and its management.  

    It is worth noting that, from the Secretariat's viewpoint,
	it is likely that uncertainties about the administrative
	reorganization process and their future have made it
	impossible to do the job well and, in particular, to do any
	long-term planning.  From that perspective, part of the
	problem is that the IETF has put them in a position of
	making it impossible to do long-term planning, and then
	complained that they are not doing long-term planning.  But
	the problems that are impeding the IESG's work and the
	standards process were significant long before the
	reorganization process began.

Those two issues, especially the second, have a fairly clear
negative impact on our ability to produce good-quality
standards efficiently.  Aspects of it intrude on IESG
efficiency and throughput, on the frequency with which things
get lost or fall through the cracks, on interactions with
meeting sponsors, on liaison relationships with other
organizations and with problems in document handling as well as
with comparatively trivial issues such as inability to keep
restrictions on posting to mailing lists in place.  Nothing
else of an administrative support nature seems to be on that
particular critical path.  In particular, questions about,
e.g., "what to incorporate" seem seriously peripheral to the
real question: how do the proposals of Carl's document help us
get better standards or get them more efficiently?

It also seems to me that the "need for the IETF to control its
own destiny" is not a problem or goal.  It is a nice slogan and
a source of confusion, maybe bordering on FUD.  But there is an
interesting element of every standards body (as distinct from
consortium) I've been able to remember or discover.  Either they
are part of governments or they are closely linked to a
"sponsor" organization.  The sponsor organization model protects
the standards body from being directly involved in fund-raising
and other activities that would give the appearance (or worse)
of having the standards process contaminated by the interests of
donors/ contributors.  If the standards body manages the
sponsor, that advantage is lost, and all sorts of complications
-- legal and of appearances-- immediately appear. But some of
the proposals of Carl's document, especially Scenario C (and now
D) and some of the "Mechanisms" of Scenario B, would put us
precisely into a situation in which the standards body
completely controls the "administrative" sponsor.

So I think we should back up a bit and concentrate on the
critical path, rather than on constructing the edifices and
monuments of complex structures that might actually weaken the
IETF.  Once we understand that critical path, and how to solve
the critical path problems, it may be sensible for us to return
and look at other issues, ornamentation, etc.

While different of us have different definitions when we get to
the fine details, I suggest that another way to identify the
critical path is to ask ourselves, for each idea and proposal,
"does this represent the solution to a problem that, if solved,
will improve the IETF's ability to efficiently produce
good-quality standards... and improve it enough to make the
investment in, and risks of, the change worthwhile?".   If the
answer is "no" then, IMO, we should get the issues for which the
answer is "yes" dealt with first and return to the "no" cases
later, if ever.   Put yet differently, if something is going to
be expensive, disruptive, or risky to fix, then it had better be
seriously enough broken to justify the work.  The two
critical-path issues described above appear to meet that test.
Nothing else that is now on the table as "administrative
restructuring" seems to meet it.

Compared to other standards bodies, the IETF has some important
distinguishing features.  For this discussion, the key ones are

  -- Little permanent bureaucracy, and
  -- Minimal focus on process for its own sake

In addition,
  -- We don't expect our senior volunteer leadership to
     directly manage budgets or staff

While this is as key a feature as the other two, no other
voluntary standards body has this expectation either.  The
comments above about "sponsors" reflect the reasons what that is
the case.

The scenarios Carl outlines, especially the more "independent"
ones, appear to compromise all three.  3716 suggests one
employee.  While it may not be obvious on casual reading,
Carl's document recognizes the fact that, especially in an
"independent" operation, the Administrator would need to be
augmented by additional staff.  Whether that staff become
employees of the IETF Administrative Entity, or are
contractors, or are "leased" as part of some other arrangement,
or are outsourced entirely, may impact appearances or budget
pools -- and some options are more expensive than others-- but
they still need to be managed and given direction.
Exceptionally satisfactory performance needs to be rewarded and
exceptionally unsatisfactory performance needs to be corrected
or punished.  If that level of direction and management is not
in place, then we reinvent critical-path problem (2) above,
with an unfamiliar organizational structure, and that would be
negative progress, IMO.

It is much more subjective, but these discussions seem to lead
to much more process too, and all of the options in Carl's
report seem to put the IETF Leadership, especially the IETF and
IAB Chairs, squarely in the middle of it.  As I have pointed out
elsewhere, we aren't selecting those people for business
administration and budget skills, don't have a good model for
doing so if we wanted to, and should not want to (Carl's -01
draft makes this point as well, at least as I read it).  And, as
discussed in some of my other notes and more briefly above, no
other voluntary standards body puts its finances under the
control of the volunteer standards leadership.  That separation
is maintained for important substantive reasons, the most
important of which is to avoid entangling the standards process
in apparent conflicts of interest.

Of course this does not imply that the standards body and its
leadership should be kept in ignorance of the administrative
and financial arrangements, nor that they should be "protected"
from having effective input into them.  Reporting and openness
and discussions, whether about budget status or about bagels at
meeting breaks, should obviously be permitted and, in general,
encouraged.  But we should not confuse openness and reporting
with decision-making authority.  Responsiveness should include
consideration of fiscal and strategic administrative issues.
And the guarantee of responsiveness, in _any_ organizational
structure in which administrative/financial management are
separated from standards management, lies in mutual trust and
mutual understanding of goals and objectives, not in
discussions of, e.g., who can blow whose bolts.  

The administrative structure needs, as an absolute requirement,
to pay careful and high-priority attention to input from the
standards structure because it is the only way the IETF can
succeed.  The standards structure needs, as an absolute
requirement, to pay careful and high-priority attention to
input from the administrative structure because it is the only
way the IETF can succeed.  If either body does not understand
that, it is in need of radical restructuring or replacement.
But building complex structures to prevent or react to events
that are not only unlikely but also impossible to precisely map
advance is bad engineering and bad administrative planning.

Whether it has been fully appreciated by the community and its
leadership or not, the above describes, not only a possible new
regime, but how things have always been done in the IETF, at
least when things were working well.  The standards leadership
explained needs to the administrative/financial organization;
that organization responded by either complying with those
needs or engaging in a dialogue about what was feasible and
what the alternatives were.  The problems we have seen more
recently were not in the model, but that the "complying...
engaging" part appears to have gotten lost somewhere along the
line.  And while, IMO, there were particular factors that made
that breakdown likely in the current case that would not apply
to any of the plausible alternatives, there is some risk of
getting into that state with _any_ separate administrative
structure.  We need to understand that and accept it, accepting
in particular that even a Nomcom-selected body that is subject
to the recall rules can become unresponsive to the community.
And, again, erecting idols of the bolt-blowing deity won't make
it painless if is occurs, no matter how impressive the statues
or how polished the mechanisms.

The question, then, is whether we can devise a scenario that
addresses the critical path questions without inventing any
more administrative structure than needed, without depending on
unreasonable expectations of the skills of the IETF _technical_
leadership, and without compromising the apparent and actual
independence and ability of the IETF to develop good technical
standards without undue influence from funding sources.

Assuming that scenario is an appropriate goal and the one we
want to address in this effort, I've reprised key criteria
below. Obviously, there is a separate question of whether a
Grand IETF Restructuring is a more appropriate goal and useful
in and of itself.  My own view is that it is quite unlikely to
be worth the risks and costs.  But, should the community really
wish to go down that path, I urge that we consider it in terms
of what problems are being solved and how important it is to
solve them.

To reprise, the criteria for that alternative administrative
organizational structure should include:

	(i) The IETF volunteer (standards process) leadership and,
	for that matter, anyone with responsibility for steering
	the standards process, is at arms-length from financial
	dealings with particular donors who might be assumed to be
	influencing the IETF's standards process.

	(ii) Nomcom appointments to IETF volunteer technical/
	standards process leadership positions are not expected to
	require that candidates have significant administrative
	or financial skills, nor are candidates expected to acquire
	those skills on appointment.

	(iii) We put as much IETF energy into organization-creation
	as is actually needed to solve identifiable and real
	problems, and no more.  In particular, we don't try to
	create elaborate structures to handle hypothesized problems
	that have not occurred and probably will never occur, nor
	do we try to use IETF Administration as a way to develop
	and carry out unnecessary social experiments.


Ietf mailing list