coders in IETF (was: Diversity and Inclusiveness in the IETF)

Keith Moore <moore@network-heretics.com> Wed, 24 February 2021 09:46 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 F37223A12D8 for <ietf@ietfa.amsl.com>; Wed, 24 Feb 2021 01:46:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=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 qnSiUTN5UpNO for <ietf@ietfa.amsl.com>; Wed, 24 Feb 2021 01:46:29 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2FD3A12D6 for <ietf@ietf.org>; Wed, 24 Feb 2021 01:46:29 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 53BBB7AB for <ietf@ietf.org>; Wed, 24 Feb 2021 04:46:27 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 24 Feb 2021 04:46:28 -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=iRXgxClzII0G1oGp022gFZq5gX/rBggriGu0h+WDV Hs=; b=VIkGdeXakniU3xX6NGQxcasgbLMRyi4hdP+vOI0EwxwuUljxxw++xZV22 q1EHS/ZQZu9KfJwoR4R4MfTYjUqDPWX7tS+VrpBJPYCri8x8Uw5AW0JEzAVbwFUV Z53ft1Z0vU0tZvzPZHUC6LEvzXFHbAPPUkzjOSW080ILLC3grqG05UtkcazPpJHu xMk2xCCzmBhkn1Ekdjey7WbY1rb8m2FoEo3KRdqRjL98o169e+ps2weSlD0pJNbp yx+oZ6h94+vDaxH1mfkrU/cMCG9mg4ySlpiCbTu7MvHLnOcXfMW2EdemXE9wbCFp CDBZvWGRzMA79zJ2gcOvqS1kwwK0A==
X-ME-Sender: <xms:cyA2YMQASAoPnTeBg6k5LkH2pWqKBS30se4NTEi2m3CG7UZlIxv8vA> <xme:cyA2YJyH_gVXZgCF_x74ks79Xl9nou1dOKBz1vctKzdah0DOk3iUuHncXCUmigUSw 7sJhtADa9gX3w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeejgddtjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhephefhuedtheefgf efgffhkeehgfeugfeiudeugeejkeefleelueeiffetfeeuudeunecukfhppedutdekrddv vddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:cyA2YJ09Zn48L-FRGzZ3s3LrMZmnqACFdWeDl3JKgBGKImo7FPmghw> <xmx:cyA2YAC2guRXhQgOde1m1ISZJY3GM0CXk2VrkmU331FEDX9ci6ezig> <xmx:cyA2YFhCb781_AqtLuZOogVXjlGWD1GlkXWTJ-9dA5DHbnERe-paTw> <xmx:cyA2YMTAZAHPUOHGzr3NzuhcUiHABK4oYKDONzX6v7Ml8EgfFqZJlA>
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 0ACA524005E for <ietf@ietf.org>; Wed, 24 Feb 2021 04:46:26 -0500 (EST)
Subject: coders in IETF (was: Diversity and Inclusiveness in the IETF)
To: ietf@ietf.org
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <AM0PR08MB37168C83CF19A3CDFEF15FD8FA809@AM0PR08MB3716.eurprd08.prod.outlook.com> <1fdfebbf-58ab-0f18-da53-ec06d9953c5f@gmail.com> <AM0PR08MB371640432AA23B27BB2D948DFA9F9@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <a96a19fd-8efb-5805-2b22-96aa849d75aa@network-heretics.com>
Date: Wed, 24 Feb 2021 04:46:26 -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: <AM0PR08MB371640432AA23B27BB2D948DFA9F9@AM0PR08MB3716.eurprd08.prod.outlook.com>
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/6SnUApKRs6vqdS2V45z9Qk9K5CA>
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: Wed, 24 Feb 2021 09:46:31 -0000

On 2/24/21 3:47 AM, Hannes Tschofenig wrote:

> [Hannes] I started noticing it after the IETF started the hackathons, 
> which gave implementers more visibility. In the groups I participate 
> in, I regularly ask around for volunteers to join the hackathon. Then, 
> you get an idea who is interested to participate and who isn't. The 
> hackathons are also a "light" form of coding because you are selecting 
> a really small specification aspect only. Hence, the bar is pretty low 
> for entry. At f2f hackathons you also have a number of people joining 
> who use the event to chat. So, you have to take this into account as 
> well. 

I don't recall whether I've been present when you were asking for 
volunteers, but in general I think it might help attract participants if 
people know how low the bar is.   I've sometimes wondered whether I need 
to have my own implementation of a protocol in order to participate 
usefully.

I can also say that another reason I've never joined a hackathon is that 
this would require another couple of nights of travel expense when my 
funds are often already strained getting to the meetings.   (Though it 
has occasionally occurred to me that attending the hackathon might 
actually be a better investment than attending WG meetings.)   Remote 
hackathons would reduce the hotel expense but maybe take more time away 
from paying work.  When I've had employer support for attending IETF, I 
doubt that employer would have wanted to pay for me to attend a hackathon.

> Participating in some working groups I more and more get the impression to sit in a document writing class rather than in an Internet engineering organization.

>> Since our principal output is text, that isn't so surprising, but I think there's a case for sending any spec that does not adhere to RFC7942/BCP205 back to the WG.
> [Hannes] On the surface, it looks like we are producing text. But actually we want much more. We want running code (in the sense of deployed code) and we should expand it to "running secure code".
> I think that this is the biggest mental obstacle. If we believe our work is done when the specification is done, then we will fail to reach the full potential of our work. I understand that this message is inconvenient because many participants have difficulties to influence the deployment or even implementations. This is also the cause of a lot of frustration in the IETF work because person A says or writes "I went feature foo." but persons B and C then need to implement 'foo' and then deploy it. Needless to say that persons B and C are less excited about doing the work for person A. IMHO this is the root cause of many conflicts as far as I can see.

My impression is that IETF has always been (at least since 1990 which is 
about when I started) much more about producing specifications than 
code.  Implementation experience was always valued in WG discussions, 
but implementations were not the main goal or even an explicit goal 
except as needed for advancement beyond Proposed.    Part of this was 
rooted in experience that interoperability was obtained from clear 
specifications of "bits on the wire", rather than by either APIs or a 
reference implementation.    But conditions were somewhat different 
then, because then you had more diverse hardware, (you still had 
machines with 36-bit words for example), more diversity in operating 
systems, and it wasn't the case that you could expect the same 
programming languages to be supported everywhere. (perhaps not even C).

I welcome the efforts to attract more developers, as I believed for long 
time that IETF specifications were becoming a bit distant from 
implementation realities.  So I saw the hackathon and efforts to attract 
open source developers as corrections that were somewhat overdue.

I don't find myself thinking that specification authors or editors need 
to be developers (IMO other skills are more important to writing a good 
specification).   But it really helps to have some people in the WG and 
in the conversation who are working on at least prototype or reference 
implementations.

Keith

p.s. among other kinds of "doers" whose clue might benefit IETF work, I 
might suggest people who understand how to make effective configuration 
and user interfaces.    Especially in the area of security but not 
exclusively so.   Ease of configuration and use are some of the 
important reasons why proprietary solutions succeed over standard 
solutions.   I'm not saying that IETF should specify user interfaces but 
rather that protocols need to be designed with ease of configuration and 
use in mind.