RE: Options for IETF administrative restructuring

John C Klensin <john@jck.com> Mon, 06 September 2004 20:51 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01486; Mon, 6 Sep 2004 16:51:16 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4QVe-0004id-JK; Mon, 06 Sep 2004 16:54:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4QNL-0003pb-C1; Mon, 06 Sep 2004 16:46:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4QMh-0003i8-NG for ietf@megatron.ietf.org; Mon, 06 Sep 2004 16:45:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01227 for <ietf@ietf.org>; Mon, 6 Sep 2004 16:45:25 -0400 (EDT)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4QPx-0004dc-BH for ietf@ietf.org; Mon, 06 Sep 2004 16:48:52 -0400
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1C4QMd-0008bw-2z; Mon, 06 Sep 2004 16:45:23 -0400
Date: Mon, 06 Sep 2004 16:45:22 -0400
From: John C Klensin <john@jck.com>
To: graham.travers@bt.com, ietf@ietf.org
Message-ID: <CC4C1DD738BC86BEA1A994AD@scan.jck.com>
In-Reply-To: <3D67CCA7D63E714B980D21A038EEA08E0EF5612E@i2km02-ukbr.domain1.systemhost.net>
References: <3D67CCA7D63E714B980D21A038EEA08E0EF5612E@i2km02-ukbr .domain1.systemhost.net>
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: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Subject: RE: Options for IETF administrative restructuring
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit

Graham,

One comment...  more, perhaps to come, or already covered by
others.


--On Monday, 06 September, 2004 12:31 +0100
graham.travers@bt.com wrote:

> All,
> 
> My two cents worth...
> 
> 1.  I'm inclined to prefer option A or B, on the grounds of
> keeping things simple ( BUT see point 4, below ).
>...
> 5.  Section 3.1 of Carl's Report ( Page 20 ) states
> "Evaluation of applicants might consist of a search committee
> appointed by the IETF Chair."  Isn't the appointment of
> committee members what the IETF empowers the Nomcom for ? 
>...

That provision worries me a great deal, and not because of "what
the Nomcom is for".   In the IETF community, we have,
predominantly, a group of people whose expertise is in various
aspects of Internet protocol design (including their security,
operational, and other implications).  We do not have a
community of professional executive-level managers with
extensive line budgetary and contractual experience.  Indeed, if
significant numbers of those people started showing up at
meetings or otherwise actively participating in the IETF's
standards work, much of the community would consider it a source
of significant anxiety (just as we get anxious about excess
quantities of marketing types, professional process-oriented
standardizers, lawyers, etc.).  But the Nomcom membership is
supposed to reflect a random sample of the community: if the
community doesn't contain those skills and experiences in
significant quantities, neither will the Nomcom.  Clearly, it is
an open question as to whether a Nomcom on which those skills
are not heavily represented would be able to make good
selections of people who are expected to exercise those skills:
it is possible, but I'd find basing our future on that idea very
uncomfortable (and more uncomfortable the more autonomy the
Administrator is expected to have).

Giving the IETF Chair the appointment power might help with
this, especially if some consultation process were required.  At
least the IETF Chair is not chosen at random and, assuming the
Nomcom does its job, can be reasonably expected to have
leadership skills above the community average.  But the same
observations more or less still apply: we don't pick IETF Chairs
for that group of skills, nor for recognizing them, nor for
having contacts and knowledge of communities from which either
good candidates or good candidate-selectors might come.  If we
expect the IETF Chair (or the IAB Chair, or the IAB and/or IESG
as a whole) to have the fiscal and formal relationship
management skills needed to hire, manage, or aggressively
oversee the Administrator (or the type of models contemplated in
the document more generally), we are imposing additional
constraints and tasks on positions that are already too
time-consuming and too hard to fill and about which the Nomcom
may not have the perspective needed to make good decisions.

And I think that is pretty scary.

    john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf