Re: [Gendispatch] New Version Notification for draft-knodel-nomcom-gender-representation-00.txt

Mallory Knodel <mknodel@cdt.org> Sat, 25 November 2023 11:28 UTC

Return-Path: <mknodel@cdt.org>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA310C15C289 for <gendispatch@ietfa.amsl.com>; Sat, 25 Nov 2023 03:28:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
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 qicku2ISjjC4 for <gendispatch@ietfa.amsl.com>; Sat, 25 Nov 2023 03:28:24 -0800 (PST)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F22C1519B2 for <gendispatch@ietf.org>; Sat, 25 Nov 2023 03:28:24 -0800 (PST)
Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1cfb3ee8bc7so3596165ad.1 for <gendispatch@ietf.org>; Sat, 25 Nov 2023 03:28:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; t=1700911704; x=1701516504; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=d2QYGOQMxtk/KtheFYWszis+CUjqdG+gWwod0luxjfw=; b=FAh7Dgk05oo/R78UeT4L6PE1umGeOz9QaI1X8EXbIDxER8Jf22pElGEg/Ox4jEvesF Vh6IQBhn8guGoZBj1VmQtbPo4knD2Tc4eAvWomwnWGkUguvghaYkb4TDl/9sfQz3v4IW Ha846V3A1kBjknsNPv6h/uiCv4XN1HE9n7pnw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700911704; x=1701516504; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=d2QYGOQMxtk/KtheFYWszis+CUjqdG+gWwod0luxjfw=; b=QFfFU3jxuCFo5Lpt+MxXvGeTVYZJk9Hb4Di3Vv7gDSHhiHig8KtG9skRBL8NwdOfOB /Tu52c/p5H9ctynQNnOEwL/u0n5paoloalfiTE9OK+8PkahTZp+r2CmNfKjOCe1s0SzS Ler2moE8HjwXdZJ+RPllGWRUy1d/qxeXQlrpQGWR2gOz7kwh6TgY90huC+wtDaWavWL5 ZEMJjmlpwie5KRnLbYjSp2xny68PnmHxWE3+zUbKevgcSzaZRywAXZDiwAab6nn9ph8D VfXfWcNJ3FTG3+b73fmLYhVhVcoYjqmxnGgufu0zDw7YabZl2eqM5M11WXGrvBg1GDpL Ys/w==
X-Gm-Message-State: AOJu0YwglhtCOlk6x5iONgRAeVFG62hm4m+qLV+2Orea80/f5Xh4mQrp iVJTI4sKzrc9+FTxNIg6OTE9T8FZvrX2yaLpQ0Iw1grV5+Q/wYGbTHo=
X-Google-Smtp-Source: AGHT+IESoYiqspIOF8OYVpihOCt8r01wBPt9st7SNrfBga+M8Gz4FI5IncvbBUkbuqEAS7u+ZVZ8042acbflqH+TMjk=
X-Received: by 2002:a17:902:e5c6:b0:1cf:a246:6f4f with SMTP id u6-20020a170902e5c600b001cfa2466f4fmr6781476plf.27.1700911703896; Sat, 25 Nov 2023 03:28:23 -0800 (PST)
MIME-Version: 1.0
References: <170047856358.34393.9049917006003776714@ietfa.amsl.com> <f871d358-8d9d-4714-99a8-6a51198a61c9@cdt.org> <CABcZeBO-DuAjhAnWBH3p-bvncG6u9Y7RfyeaGMDW6oGbkVt8rg@mail.gmail.com> <CAGVFjM+sTVKPwFaLLz57ni-qHVxY3cKuJgpxhu=6FtN-4gmqbA@mail.gmail.com> <7aa2509a-82d6-43f0-b0c8-8b8bf68c8f02@huitema.net> <f1932f22-0555-63d9-9a38-6f75e0739546@gmail.com> <AD39B27C-74EA-420B-925C-DFD4BD76F768@mnot.net>
In-Reply-To: <AD39B27C-74EA-420B-925C-DFD4BD76F768@mnot.net>
From: Mallory Knodel <mknodel@cdt.org>
Date: Sat, 25 Nov 2023 06:28:12 -0500
Message-ID: <CAGVFjMLm5O9VugphiBHTBpkbi89s2ypj2rV4pKYwpVBcpSYiPw@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Christian Huitema <huitema@huitema.net>, Eric Rescorla <ekr@rtfm.com>, "gendispatch@ietf.org" <gendispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e7d09e060af85d9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/5dq82wwo93Vm9Egj8hLS1abwwEw>
Subject: Re: [Gendispatch] New Version Notification for draft-knodel-nomcom-gender-representation-00.txt
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2023 11:28:28 -0000

I agree with Mark. I’ve stated this position before and it’s why the draft
is written the way it is.

The problem statement is well understood. Folks came with the data— thank
you! That didn’t require anyone asking in advance anyone else about their
gender.

Sometimes a problem is well understood enough that the solution is just
easy.

There’s no need to datify the obvious.

-Mallory

On Sat, 25 Nov 2023 at 00:24, Mark Nottingham <mnot@mnot.net> wrote:

> On 25 Nov 2023, at 1:55 pm, Brian E Carpenter <brian.e.carpenter@gmail.com>
> wrote:
> >
> >> The PNTS discussion appears to assume that the nomcom will have access
> >> to the "gender preferences" in the IETF registration forms. I personally
> >> finds that problematic. If I remember correctly, when the question was
> >> added to the form, the data was to be used or statistics only. We are in
> >> to teach the industry to protect private information, not collect more
> >> than what you need, make sure that the data is deleted as soon as no
> >> needed anymore, etc.
> >> Repurposing the data certainly does not fit with privacy best practices.
> >> Moving from "doing global statistics at the end of the meeting" to "keep
> >> the data and use it for nomcom qualification" implies, for example, that
> >> data is kept for much longer -- a least until the nomcom is selected,
> >> which means two years from the first qualifying meeting for the
> >> selection. Maybe even longer, if we want the data available for dealing
> >> with an appeal.
> >> Then there is the issue of, if we keep the data, how do we protect it
> >> and prevent it from leaking? What of participants coming from countries
> >> that enforce rigid social norms? What of participants from formerly
> >> liberal countries whose new government takes a turn towards repressive
> >> attitudes? Are we sure that none of these repressive governments would
> >> ever hack our databases?
> >> Maybe I am too sensitive. But I don' have a good feeling there.
> >
> > You are correct that NomCom volunteers would need to (a) state their
> > gender identity and (b) agree to it being used in the nomcom selection
> > process. And if that process is to remain subject to public verification,
> > as today, they must (c) agree to it being made public.
> >
> > That may be enough to kill the proposal. At the very least, it makes
> > "prefer not to say" a necessary option.
>
> Oh, geez.
>
> I am very supportive of the goals of this draft, and thank Mallory for
> bringing it up.
>
> However, I am extremely wary of creating a situation where people's gender
> identity is necessarily declared and scrutinised in public as part of our
> process -- even with a 'prefer not to say' option.
>
> Because some will accuse others of trying to game the process by using
> PNTS, or by declaring a gender that isn't "obvious" to others. People with
> non-traditional gender identities are some of the most vulnerable in any
> community, and creating an atmosphere where gender identity is questioned
> creates a hostile environment for them if they have chosen not to be 'out'
> yet.
>
> Of course, they can choose to conform and list their gender as others tend
> to perceive it, so as not to 'rock the boat' -- but the point here is that
> previously, they didn't have to make that choice to participate fully in
> the IETF. In effect, we could be improving our community (through better
> gender diversity) at the expense of worse personal experiences for specific
> people. That's a tradeoff of different harms which needs to be balanced and
> considered.
>
> So if this is going to proceed in any form, we need to get active input
> and buy-in from a much more diverse set of viewpoints than the typical IETF
> activity, and consider the less obvious impacts of our design choices.
>
> Cheers,
>
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>