Re: Thoughts on the nomcom process

Jari Arkko <jari.arkko@piuha.net> Tue, 18 March 2008 22:01 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9423A6F65; Tue, 18 Mar 2008 15:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.337
X-Spam-Level:
X-Spam-Status: No, score=-100.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGpR2--E1crz; Tue, 18 Mar 2008 15:01:43 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A7D3A697B; Tue, 18 Mar 2008 15:01:41 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4303A6D31 for <ietf@core3.amsl.com>; Tue, 18 Mar 2008 15:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0-c7q+dbm-q for <ietf@core3.amsl.com>; Tue, 18 Mar 2008 15:01:39 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0A24A28C144 for <ietf@ietf.org>; Tue, 18 Mar 2008 15:01:32 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id C1D16198718; Tue, 18 Mar 2008 23:59:13 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5DB791986F9; Tue, 18 Mar 2008 23:59:13 +0200 (EET)
Message-ID: <47E03B30.2080902@piuha.net>
Date: Tue, 18 Mar 2008 23:59:12 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306)
MIME-Version: 1.0
To: Spencer Dawkins <spencer@wonderhamster.org>, Lakshminath Dondeti <ldondeti@qualcomm.com>
Subject: Re: Thoughts on the nomcom process
References: <47DC8FAE.6010306@qualcomm.com> <006d01c8875c$37f9adf0$6401a8c0@china.huawei.com>
In-Reply-To: <006d01c8875c$37f9adf0$6401a8c0@china.huawei.com>
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Spencer, Laksminath,

> You did something very GOOD this time - you invoked the never-before-invoked 
> arbitration process, instead of secretly resolving an "irresistable force 
> meets immovable object" dispute. Please accept credit for this good 
> judgement

+1

INDEED. Thanks, Laksminath.

And as for what to do about this problem for the future - I would
suggest that we should not focus too much on this particular incident or
even IAB's role. There are different confirming bodies and there are
different situations.

I think a good first step is to make sure the questionnaire templates
are clear about what information stays strictly within the nomcom and
what may be shown to confirming bodies. And clarify that feedback from
the community shall never leave the nomcom, if that's not already clear.

But even after doing this, the basic question of what confirming means
stays open. I think the intent is that the confirming body makes a final
sanity check and under normal circumstances that should be it. I
understand the need for requesting some amount of information; it may
well be that the candidates are not all personally known to the
confirming body. CVs would be useful in this process, for instance. This
is what we have been talking about on the list. However, presumably we
have the confirming process to catch problems, so the more difficult
case is the problem case. Hopefully this is extremely rare or
non-existent. I would expect the confidentiality rules on, e.g.,
feedback to hold even in such a case. But it would seem a dialog between
the nomcom and the confirming body would be needed, and some information
would have to be exchanged -- perhaps in summarized form. "Yes, we
realize A has these issues but the only other candidate B had such and
such problem" or "He escaped from the institution last month? Oops,
perhaps we need to go with our backup candidate instead."

I have no idea how to specify the process on this so that it works under
all circumstances. But my main expectation for the confirming bodies is
that they do a thorough job without resorting to repeating nomcom's work
or questioning the results unless a truly serious problem can be seen.

Jari

P.S. Since the dispute resolution results are public, I would be
interested to know what kind of a report Scott would have been able to
give in the plenary, had the dispute been about a person rather than the
process. I hope we never have to see that. But maybe some food for
thought about the confidentiality rules of this whole thing...

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf