Re: Diversity and Inclusiveness in the IETF

Keith Moore <moore@network-heretics.com> Tue, 23 February 2021 13:56 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51793A2B82 for <ietf@ietfa.amsl.com>; Tue, 23 Feb 2021 05:56:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ0-zT96163z for <ietf@ietfa.amsl.com>; Tue, 23 Feb 2021 05:56:37 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A87C3A2B86 for <ietf@ietf.org>; Tue, 23 Feb 2021 05:56:36 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4BFD85C019D for <ietf@ietf.org>; Tue, 23 Feb 2021 08:56:36 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 23 Feb 2021 08:56:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=uPE3HPOgqtcCfDsvKBhi7U/wO1avL0tTx67Yh+sKt Ss=; b=XhnKoiHJbXr8gHpTesqccVy0JgykffDcocp96anD4vCd7vVXOODy9z52u a1u/u60KUQPZrRrlIxFRO7+TkUlk2aiyoVcTXvEhBlJq588kEGHHW/Bz6V55HK3T nGp+2d5A9Ix/kAZFFjIreqP2iA/7eK2g0JAfcfBOCHJ012r9xGd/zd8/h1bLvzyS mrEyeuGqq472CsgoZMG2esPEHHjeKDMb2c2qaQNqRZmmbrsEaRZC++DnQ4CR4QYT Gcyhgmt55b8n3ldyKxUWtPXxkh3KEvuTybnazpyq0JDHwUXFmpIiX8xv3E8e7DHh w1WDgLApa5ZLD/ZKpn20mm0iHZbXw==
X-ME-Sender: <xms:kwk1YGWwRuWrFFpubOz_sfhfBi5oBnB9t03tV-9bktjG-8gfnycIdg> <xme:kwk1YChaJb1wJV0zyFILBhNcatCTfSMO8cOCHk-Eca_Imas_vsFexmMv89GflYZMW Q8xTXbIUcTpkw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhephefhuedtheefgf efgffhkeehgfeugfeiudeugeejkeefleelueeiffetfeeuudeunecukfhppedutdekrddv vddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:kwk1YHRI7IUOtStVUWVBYg-7WtMHtVd24hR4zZEq3fV-XhYcpx682g> <xmx:kwk1YFH-TXMJbc0-cC6Fl-RQGJ-jk0X9i0vyNs8wDm8L168BYs8inA> <xmx:kwk1YPkXXeqFdmGZ3vhoqkIbZL9t3s9zGw_vX9CMUln4Ams7JMTnFA> <xmx:lAk1YCsRaPx3k40xTJXbcBuqT43kMq6V34hpIoB7GnMXsoHJ-MsM3Q>
Received: from [192.168.1.90] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D66E108005B for <ietf@ietf.org>; Tue, 23 Feb 2021 08:56:35 -0500 (EST)
Subject: Re: Diversity and Inclusiveness in the IETF
To: ietf@ietf.org
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> <c946eb86-6c67-0711-eb6b-19aa8173b5be@network-heretics.com> <AB8D4BF4-7624-42AC-BD20-D41C9A4E8AB8@tzi.org>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <f4cfacac-093f-3664-517b-49a7456d0160@network-heretics.com>
Date: Tue, 23 Feb 2021 08:56:34 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <AB8D4BF4-7624-42AC-BD20-D41C9A4E8AB8@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ntIzY6X2-YmmDeAAyuE0AcHii0w>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2021 13:56:39 -0000

On 2/23/21 5:05 AM, Carsten Bormann wrote:

> On 2021-02-23, at 05:33, Keith Moore <moore@network-heretics.com> wrote:
>> And yet, you shouldn't be required to work with any specific person to get around those idiosyncrasies.
> While this is a desirable goal, it also is a lofty one.

To clarify, one of the complaints that we have heard is that a newcomer 
was told that he had to work with one specific person or he could not 
expect to succeed in IETF.

I certainly agree that it's likely to remain difficult for a newcomer to 
get consensus around an RFC in an established area without help from a 
more experienced IETF participant.

(Though I also remember that when I first started writing drafts, the 
notion of "shepherd" did not exist yet.   I definitely had supportive 
comments and constructive suggestions from other participants via 
private email after I submitted my initial draft, and I had been on the 
working group mailing list since before the group was chartered so I was 
familiar with the conversation. IETF was smaller then than it is now, 
but not that much smaller. What's changed is that we have more 
bureaucracy, more rules, and a much wider and more diverse range of 
increasingly narrow interests.)

> The reality in *any* organization is that it is easier to do things for people who know the organization than for those who don’t.  (We have a German word for that, Stallgeruch, which is hard to translate, so I’m not going into more details here.)
>
> The objective can only ever be to make the organization *more* accessible.
> I believe finding a shepherd for new work is exactly the right way to approach the IETF, and I applaud Bron for playing this role with datetime-new.

I don't have a problem with people being encouraged to find a shepherd 
(though perhaps not required to do so).   I only have a problem if 
someone is told "you MUST work with this one person". Sometimes this 
kind of relationship can be used to manipulate or use the newer person 
to support poor technical or political positions.

> (I found Bron’s telling of the deleterious effects of fashions like “everything must be done in OAuth” refreshing; our work has also been hit by this one, but is now slowly emerging, albeit in a rather damaged way, from ACE.  But avoiding fashions is maybe orthogonal to making the organization more accessible from the outside — fashions damage insiders, too.  It is also not easy to recognize a fashion from a groundswell.)

Since I consider OAuth rather limited in its applicability (especially 
if you don't believe every application should be tied to the web) and 
kind of dangerous (from a privacy perspective), I was appalled to read that.

Keith