Re: I-D Action: draft-kucherawy-nomcom-procexp-00.txt

John C Klensin <> Sun, 10 April 2016 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD3CE12D60B for <>; Sun, 10 Apr 2016 09:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m9Ohg2t8PZ8U for <>; Sun, 10 Apr 2016 09:59:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE7A412D558 for <>; Sun, 10 Apr 2016 09:59:37 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1apIi0-000F1h-IY; Sun, 10 Apr 2016 12:59:36 -0400
Date: Sun, 10 Apr 2016 12:59:31 -0400
From: John C Klensin <>
To: "Murray S. Kucherawy" <>
Subject: Re: I-D Action: draft-kucherawy-nomcom-procexp-00.txt
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Cc: IETF discussion list <>
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: Sun, 10 Apr 2016 16:59:38 -0000


One more thought about the challenge process.  Without
performing the experiment, we can only guess at how many
challenges there would be and that might make a difference.
However, I wonder whether, instead of adding "didn't attend
enough meetings and isn't appropriate" on to the challenge
criteria for post-selection challenges, it might be better to
create a different category and allow challenges on that basis
to people entering the selection pool.

In other words, 

(1) The pool is announced (as today) with the "fewer meetings"
people identified (as you now suggest).

(2) There is a brief period for community challenges to those
who have not attended three of five meetings, paralleling the
period in which the Secretariat checks to be sure those who have
claimed three of five meetings really did attend.

(3) Once we get past step 2, the pool is the pool and, while any
one selected can be challenged under the rules of RFC 7437,
challenges based on meeting attendance are no longer allowed.

I'm not sure, and I'm a tad concerned about DoS attacks (see
above), but it seems to me that might be a little bit cleaner.
It would also have the property that potentially-controversial
challenges based on unsuitability would occur much earlier in
the process, before the random draw is made, and that might be
an advantage.