Re: Qualifying for NomCom

Harald Alvestrand <> Thu, 07 April 2016 20:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF0A712D6E8 for <>; Thu, 7 Apr 2016 13:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zj16cg0seqEf for <>; Thu, 7 Apr 2016 13:58:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A3CF12D665 for <>; Thu, 7 Apr 2016 13:58:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1A3E7C7C75 for <>; Thu, 7 Apr 2016 22:58:08 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a0t2itb7WoR2 for <>; Thu, 7 Apr 2016 22:58:07 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 524227C7C74 for <>; Thu, 7 Apr 2016 22:58:07 +0200 (CEST)
Subject: Re: Qualifying for NomCom
References: <>
From: Harald Alvestrand <>
Message-ID: <>
Date: Thu, 7 Apr 2016 22:58:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Apr 2016 20:58:17 -0000

I liked the suggestion of a process experiment where the Nomcom chair
could accept a volunteer that did not qualify under the current rules,
based on his/her own judgment, possibly with a challenge period (we
already have a challenge period in the procedure).

Once we have a few tens of examples of people who want to serve and the
community doesn't mind being allowed to serve, we can start seeing if we
can find rules that cover them.


On 04/07/2016 08:11 PM, Murray S. Kucherawy wrote:
> Yes, this again.
> I've refreshed RFC7437bis in the datatracker since we're effectively
> between active NomCom periods, so now's a good time to take another
> look at this.
> For those that didn't follow along last time, the big showstopper for
> this draft as I have it now had to do with updating the criteria for
> qualifying to serve on the NomCom.  The current draft says:
> (1) To qualify, one must have attended three of the last five
> in-person meetings, as it's been for a long time now.
> (2) This is regularly criticized as selecting for attendees with the
> support and budget to travel to the meetings, and possibly excludes
> people who make substantial or numerous IETF contributions but
> participate remotely more than in person.
> We made previous attempts on this list to come up with new criteria
> given (2) above, but weren't successful at coming to consensus, so I
> took them back out, leaving the text that's there now.  The previous
> thread:
> I'd like to take another run at this before the next NomCom really
> gets going.  One suggestion I was given here at IETF 95 is to come up
> with some system that's worth trying, and not over-engineer it to
> protect against gaming or other abuses until such time as such abuse
> is evident.  It might, for example, be sufficient defense to empower
> the NomCom Chair or the IETF Chair (or both) with a "panic button",
> making them able to declare that selection criteria will fall back to
> what we have now if it looks like the proposed new qualification
> system is likely to yield an inappropriate set of selecting NomCom
> members.
> Comments welcome.
> -MSK

Surveillance is pervasive. Go Dark.