Re: NomCom procedures revision

John C Klensin <john-ietf@jck.com> Sat, 29 August 2015 13:52 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FE41B2AD7 for <ietf@ietfa.amsl.com>; Sat, 29 Aug 2015 06:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm9IJ9ZNFd5G for <ietf@ietfa.amsl.com>; Sat, 29 Aug 2015 06:52:19 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0EC11A90E7 for <ietf@ietf.org>; Sat, 29 Aug 2015 06:52:18 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZVgYK-000JIx-4G; Sat, 29 Aug 2015 09:52:16 -0400
Date: Sat, 29 Aug 2015 09:52:11 -0400
From: John C Klensin <john-ietf@jck.com>
To: Joel Halpern <jmh@joelhalpern.com>, 'ietf' <ietf@ietf.org>
Subject: Re: NomCom procedures revision
Message-ID: <8BCE6324E528B2121EFE760F@JcK-HP8200.jck.com>
In-Reply-To: <55E0DC42.2020303@joelhalpern.com>
References: <CAL0qLwYJzFZT=OgWqiiTw-n6mvb3PPusRtArmPs_d4_qpLfmpg@mail.gmail.com> <CADnDZ8_KsNP=_nwp2wrckXtHF8ZSxrQTvf9UKbAMpt68BiiCFA@mail.gmail.c om> <CAL0qLwbhhqG1qoHbBrymPQrU31qjswPAhdeJBqVdRj2L4AR80A@mail.gmail.com> <55E0426A.3000800@alvestrand.no> <55E063DC.3020503@dcrocker.net> <087d01d0e1db$a5b0f6f0$f112e4d0$@olddog.co.uk> <55E0DC42.2020303@joelhalpern.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/qv239k_MrVn7_f-_HcKd7I2ZLLU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
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>
X-List-Received-Date: Sat, 29 Aug 2015 13:52:20 -0000


--On Friday, August 28, 2015 18:10 -0400 Joel Halpern
<jmh@joelhalpern.com> wrote:

> I was a bit confused by this discussion.  By 3777, the chair
> establishes the voting procedure.  By assumption, he
> establishes it before it is needed.
> 
> A sensible chair will establish procedures that the committee
> is comfortable with.  Since it is the chair who will
> administer whatever proecedures are used, it eh committee does
> not trust the chair to establsih them, why would the committee
> trust the chair to adminsiter them?
> 
> I would hate to have an overly strict rule on voting
> procedures, and a couple of nomcom members get into a typical
> IETF dispute about the best answer, and thereby hang the work
> of the nomcom.
> 
> Why is this being made more complex, with strict priority,
> strict rules on adoption, etc?

I agree with Joel and would like to, once again, suggest that
the IETF seems to have developed a tendency toward solving
problems that are extremely uncommon or don't exist at all
(perhaps "because we can") and doing so by developing complex
and prescriptive rules.  We almost never get those rules right,
often because Murphy's Law predicts that the next time some set
of rules is really needed will be due to some case, or involve
some issue, that the rules didn't exactly predict. 

Instead, let's assume that the leaders, chairs, etc., whom we
appoint are competent and responsible adults who will exercise
reasonable discretion and make decisions in the best interests
of the IETF when that counts.  If that assumption turns out to
be incorrect, let's try to fix that, rather than seeing if we
can transform broad discretion into robot-like rule-driven
behavior.

So, for me, the right "rule" is "let the Chair decide".  If we
have to concentrate on cases where that might go wrong,
concentrate on whether the mechanisms for the voting (sic)
members of the Nomcom can overrule or remove the Chair, not on
making the procedures rigid or trying to specify what happens in
rare cases.

FWIW, I have something of the same reaction toward qualification
formulae.  Every time we allow an interim meeting and allow it
to behave exactly as a f2f one does, including making decisions
that will supposedly be ratified on the mailing list; every time
we replace rough consensus and discretion with rigid decision
rules; and perhaps even every time a Nomcom concludes that it
needs to develop and use complex questionnaires for which,
inevitably, responses are at least partially a function of how
much the candidate (or her company) wants the job, rather than
relying on Nomcom member knowledge of the community and who
might make the best candidate, we move away from really being
able to justify the assumption that attending a bunch of
meetings is the only reasonable qualification for serving on the
Nomcom --no matter how those meetings are counted.  As some who,
like Brian, is doing a significant percentage of meetings
remotely but who has enough background and ongoing involvement
with the IETF that I think I have at least as much perspective
as a relative newcomer who has attended a year's worth of
meetings but never written an I-D, chaired a WG, or really
contributed to a discussion, I'm coming to the conclusion that
it is at least as important to have active participants with
recent remote participation experience on the Nomcom (and
probably on the IESG) as it is to have participants with recent
meeting experience.  The kind of adjustments Brian and others
have suggested may help, but I think the real issue is that we
need not just to allow for fewer recent f2f meetings but to
consider remote participation experience a real asset (while,
ideally, pushing back on Nomcom membership by what Marshall Rose
referred to a Go-ers, rather than Do-ers, no matter how many f2f
(or remote) meetings they attend.

best,
    john