Re: [Eligibility-discuss] NomCom selection Fwd: Notification for draft-eastlake-rfc3797bis-00.txt

Paul Hoffman <paul.hoffman@vpnc.org> Mon, 29 May 2023 23:51 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: eligibility-discuss@ietfa.amsl.com
Delivered-To: eligibility-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9074FC15154D for <eligibility-discuss@ietfa.amsl.com>; Mon, 29 May 2023 16:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlTKRTdvtv9u for <eligibility-discuss@ietfa.amsl.com>; Mon, 29 May 2023 16:51:22 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D17BC14CEF9 for <eligibility-discuss@ietf.org>; Mon, 29 May 2023 16:51:22 -0700 (PDT)
Received: from [10.32.60.195] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 34TNu52A056785 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 May 2023 16:56:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] claimed to be [10.32.60.195]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: eligibility-discuss@ietf.org
Date: Mon, 29 May 2023 16:51:19 -0700
X-Mailer: MailMate (1.14r5937)
Message-ID: <0531CD69-AAA4-4657-9B90-B50F76D997B7@vpnc.org>
In-Reply-To: <4a8f2bb4-25c3-5514-f13f-8db1804619a6@joelhalpern.com>
References: <54F373CD-1E97-42BC-9AAB-0451ABD9D448@eggert.org> <1229DD7D-3640-4EFD-8058-D0EC18020038@eggert.org> <18537EEF-4E16-4C48-8456-02A8FB0C8CFC@vpnc.org> <4a8f2bb4-25c3-5514-f13f-8db1804619a6@joelhalpern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/FdnH0eXofPUNVK7zwks4Lt_csTg>
Subject: Re: [Eligibility-discuss] NomCom selection Fwd: Notification for draft-eastlake-rfc3797bis-00.txt
X-BeenThere: eligibility-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF eligibility procedures <eligibility-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eligibility-discuss/>
List-Post: <mailto:eligibility-discuss@ietf.org>
List-Help: <mailto:eligibility-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 May 2023 23:51:26 -0000

On 29 May 2023, at 15:40, Joel Halpern wrote:

> Whether or not the procedure in that (draft-hoffman-...) is useful for other people I can't say.  But it removes may elements that the community felt were important in defining the nomcom process and rfc 3797.  For example, you removed all of the challenge periods and challenge criteria. 

Wait, wait. All this draft does is specify how to pick from a group. It is not meant to be a drop-in replacement for RFC 3797, and nothing in the draft says it is meant to be. If folks here like the idea of using an easier-to-understand mechanism that doesn't have the pitfalls of RFC 3797, a 3797bis that keeps all the important parts of the process could just slip in this mechanical part.

> And your educed the random numbers to one source, without specifying anything about the required degree of randomness in that source.

That is covered in the Security Considerations.

>   While I am not expert on the matter, the reason that was stated for having multiple sources was to get enough reliable randomness into the mix.

For the method used in RFC 3797, yes. For the method in this draft, a few bits is just fine.

--Paul Hoffman