[secdir] Secdir last call review of draft-ietf-elegy-rfc8989bis-03

Vincent Roca via Datatracker <noreply@ietf.org> Tue, 24 January 2023 13:07 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1095C1522AA; Tue, 24 Jan 2023 05:07:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Vincent Roca via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-elegy-rfc8989bis.all@ietf.org, eligibility-discuss@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <167456565791.19127.12641700321697459649@ietfa.amsl.com>
Reply-To: Vincent Roca <vincent.roca@inria.fr>
Date: Tue, 24 Jan 2023 05:07:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/gqHgHDIG4NP2VoBhzUw4caUuj1k>
Subject: [secdir] Secdir last call review of draft-ietf-elegy-rfc8989bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2023 13:07:38 -0000

Reviewer: Vincent Roca
Review result: Has Nits

Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

Summary: Has Nits

This I-D proposes an update to the NomCom eligibility process in order to
reduce the risk of coordinated attacks by an adversary who wants to get the
control of IETF, in a context where the generalization of remote attendance to
IETF meetings changes the rules.

I understand (end of section 3):
>   Finally, overly restrictive criteria work against getting a broad
>   talent pool.¶
but here we're not talking about IETF participation (which must remain as open
as possible), it's a key selection process for the IETF.

In my opinion (my two cents):
-- the NomCom candidate must be part of the **active community**.
Being part of the NomCom committee is earned.
How to define "active community" deserves consensus, but if Paths 2 and 3
(section 4) are valid, IMHO Path 1 is not, and there's a huge gap between 2-3
and 1! Can't we find a midway as a replacement for Path 1, e.g., being
co-author of a WG-Item document (the whole standardisation process takes so
long...)?

-- the NomCom candidate **identity must be verified**.
I've never been asked to prove my identity at IETF (registration, picking my
badge, editing an I-D), which is mostly fine. However we're talking here of
being part of a committee that is key to the IETF: it deserves additional
checks. And if there could be good reasons for an IETF participant to use a
pseudonym, this is an exception, not the rule, and it disqualifies for NomCom
IMO.

Additional remark:

-- Section 4: I understand we're talking about IETF, but I see no reason to
ignore IRTF altogether in Path 2 (section 4). Beeing a Research Group Chair or
Secretary is also sign of being part of the active community.

-- Section 4: I don't see a justification for 3 years (WG/RG chair or
secretary) versus 5 years (RFC author). Being in responsibility of a Group is
engaging and a sign of a commitment to the Community, much more than being
co-author of an RFC which is above all an individual achievement.

In any case thank you for considering this important topic.