Re: Things that I think obvious....

John C Klensin <> Wed, 15 September 2004 02:53 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA20038; Tue, 14 Sep 2004 22:53:00 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C7Pzn-0008KP-FM; Tue, 14 Sep 2004 22:58:14 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C7PpP-0003iR-JP; Tue, 14 Sep 2004 22:47:27 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C7Phj-000248-HQ for; Tue, 14 Sep 2004 22:39:31 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA19183 for <>; Tue, 14 Sep 2004 22:39:29 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.33) id 1C7Pmk-000860-BE for; Tue, 14 Sep 2004 22:44:43 -0400
Received: from [] ( by with esmtp (Exim 4.34) id 1C7Phd-0003p8-C7; Tue, 14 Sep 2004 22:39:25 -0400
Date: Tue, 14 Sep 2004 22:39:25 -0400
From: John C Klensin <>
To: Harald Tveit Alvestrand <>
Message-ID: <>
In-Reply-To: <66692881EAD9BEB9C2457FA6@B50854F0A9192E8EC6CDA126>
References: <66692881EAD9BEB9C2457FA6@B50854F0A9192E8EC6CDA126>
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: bf422c85703d3d847fb014987125ac48
Content-Transfer-Encoding: 7bit
Subject: Re: Things that I think obvious....
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: 7a0494a0224ca59418dd8f92694c1fdb
Content-Transfer-Encoding: 7bit


Since I finally got around to posting my "what was that problem
anyway" note, it is probably time for me to come back and try to
question some of your assumptions, since I'm not sure I agree
completely with all of them.  More important, the logic on which
your definitions are constructed appears to be badly flawed.
Since poor definitions and logic can lead to confused thinking,
some careful analysis may be in order.

--On Thursday, 09 September, 2004 12:21 +0200 Harald Tveit
Alvestrand <> wrote:

> I thought it would make sense for me to mention a few things I
> have regarded as "obvious" in this discussion - just to make
> sure nobody comes along later and says "you can't draw a
> conclusion based on that - while I agree with you, there might
> be others who don't" or something like that.
> Clarity is good.
> It is very hard to state these things in a way where nobody
> can quibble with the formulations, but I will try anyway.

> 1 - The IETF exists, and it is the IETF community.
> Even though we have carefully avoided defining its boundaries,
> I believe that we all believe that the IETF exists. And it's
> obvious that if the people who do the technical work leave,
> the IETF is nothing.
> So the IETF is the community.

This logic doesn't follow. 

Restated as a logical proposition, you have just said

    { The people who do the technical work }
            are a necessary condition for 
    { a meaningful (i.e., "not nothing") IETF } 
    { the IETF }  == { the IETF community }

So, you have concluded that a term that you (still) haven't
defined is equivalent to another term based an a sufficiency
condition on what appears to be a subset (the "not nothing" one)
of the second term.  Now, logic may have undergone significant
advances since I took that course a few centuries ago (at least
it feels like that), but I don't think that flies.

In more practical terms, while I agree that the people who do
the technical work are a necessary condition for the IETF being
meaningful, we certainly have people around who participate in
the IETF, are eligible to serve on Nomcoms, may even post to
mailing lists, etc., but who do no observable technical work at
all.  If your intent is to say
     { the people who do the technical work } ==
     { the IETF } ==
     { the IETF community }
then all of those no-technical-work active participants are
excluded from the IETF community.  I don't think you mean that.
And, if you do, I suggest that the Nomcom selection procedure
model falls apart, as do several other things.

It is not an accident that we often make the distinction between
"IETF [technical] contributors" and "IETF participants".  Even
if both of those categories are a bit fuzzy, we understand that
they are different.

More broadly, we are, or pretend to be, in the business of
producing standards (and other things) to make the Internet work
better.    Either 

	* those standards have users and applications, and we
	care enough about those enough to consider the people
	and organizations who make the evaluation and practical
	applicability decisions part of our community (at least
	for some purposes), or
	* we are in serious danger of turning into a community
	of navel-gazers for which the main criterion for IETF
	success is that we are all happily amusing ourselves.

While it is certainly possible to believe in the latter, happy
amusement, definition after observing some of what goes on in
the IETF, I think (and hope) few of us actually believe it.
Moreover, some of that extended community is the source of the
economic and support resources for making the IETF go.  And one
might go so far as to say that, without those resources, the
IETF would rapidly become "nothing", i.e., that they are also a
necessary condition.

> 2 - The IETF leadership is the IESG and IAB.
> Some jobs are clearly given to the IESG in our documents;
> other jobs are clearly given to the IAB. Some jobs are not
> mentioned at all.
> As part of the process of change, the community may select
> other people or create new bodies for other types of
> leadership.
> And the IAB and IESG has to be in a continuing dialogue with
> the community in order to figure out what the right things to
> do are.
> But there is at present no other leadership function selected
> by the community.

Again, your principles are correct, but your syllogisms break

	(i) If we accept your narrow definition of "the
	community" (see above), then the IAB and IESG are
	selected by something else than "the community"
	(ii) The statement that there is "no other leadership
	function selected by the community" does not imply that
	the "IETF leadership is the IESG and IAB".  For example,
	whether it is working well or not, there is a case to be
	made that the Secretariat has a leadership role in the
	(iii) We also have documents that assign "jobs" to the
	Nomcom and its Chair, to WG Chairs, to the IANA and the
	RFC Editor, and to others.  If the criteria for
	"leadership" is that there are jobs given to people or
	organizations, then those are "leadership" too.  I would
	add directorate members, document authors and editors,
	and many others to that list too.
	(iv) More important that any of the three points above,
	and leading directly to (3), below, the observation that
	the IAB and IESG are "the leadership", even if accepted
	as true, does not imply that those bodies have any
	authority not explicitly granted to them by the
	community in specific authorizing documents, or the
	logical consequences of such organization.  Put in more
	traditional IETF terms, the section of members of the
	IESG and IAB does not endow either the individual
	members or the bodies as a whole with Royal Authority.
	"No Kings" is not a conditional statement; nowhere does
	it say "No Kings except when selected to serve on the
	IAB or IESG".
	(v) And, finally, "leadership" is, and always has been,
	a concept that has as much to do with influence as with
	authority.  If you don't believe that there are leaders
	in the community who are not the IESG or IAB, your
	definition of "leadership" is a bit unusual. 

Probably we can do better.

> 3 - The community has accepted the problem description and
> principles laid out in RFC 3716.
> The most common reaction I have had from people who have read
> RFC 3716 is "it's obvious, now that you say it". And it would
> be hard for anyone who reads the IETF list or the
> IETF-announce list, or the most recent plenaries, to be
> completely unaware of its existence, or that we are basing
> further work on its conclusions.
> So - if there was significant disagreement with its
> conclusions - I'd have expected to hear that before now.

Like Bernard and yourself, I participated in drawing 3716
together.  And I agreed with it at the time and _in general_
still do.  But I believe that the direction in which it has
taken us --either because we didn't understand some of the
issues before we started to design and implement, because we
just got some things wrong at the detail level, or because it
has been interpreted in ways more specific than we intended--
calls some of its "problem description" and/or "principles" into

More important, we have one, and only one, established way for
the community (see above) to "accept" something, and that
involves a Last Call and a formal IESG determination.   If we
can publish an Informational RFC whose existence is arguably
well-known in the community, and then interpret the absence of
"significant disagreement" as an indication of community
acceptance and assent, then we had best start treating RFCs 1149
and 2549 as important parts of the protocol suite. 

> As I said - I *think* these things are fairly obvious. But it
> might still be reasonable to check that other people agree. 

Be careful what you wish for...  :-(


Ietf mailing list