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

Christian Huitema <> Thu, 25 February 2021 01:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C8813A0ADF for <>; Wed, 24 Feb 2021 17:39:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hXCBgO42dPnU for <>; Wed, 24 Feb 2021 17:39:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC0693A0ADA for <>; Wed, 24 Feb 2021 17:39:38 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1lF5co-000jvb-RJ for; Thu, 25 Feb 2021 02:39:32 +0100
Received: from (unknown []) by (Postfix) with ESMTPS id 4DmFnp0PpszLh9 for <>; Wed, 24 Feb 2021 17:39:26 -0800 (PST)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1lF5cj-0006nd-TT for; Wed, 24 Feb 2021 17:39:25 -0800
Received: (qmail 16734 invoked from network); 25 Feb 2021 01:39:23 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 25 Feb 2021 01:39:23 -0000
Subject: Re: coders in IETF (was: Diversity and Inclusiveness in the IETF)
To: Keith Moore <>,
References: <> <> <> <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Wed, 24 Feb 2021 17:39:22 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------3D22C2CD04D4DA76E2912503"
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x9j7219Tb9QoiGKb6esGsuKj/EwzSHE5FGYwwjsNRPCKHe 2EzgvezraRe+YIXuuGrmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaF72OcLi5sd8B4EwxAXygZhQ6V51u76v35b1wNe/MvdIN+Yj9 JT+HIE3AciYbXmyy2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NDxdyIeJZUl7T+dBx2dACj6fcyzIvQqguCIBx7DVbL6eb u172M0R2VlaBhd+XcuKQDRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuSW8D9t0kz0vlag+LRt89q4JMFoNbQ2n4sBe9p8tT1Z4GyuLfHqAnAj7rgKH7+eCmm39tJ DaM/m4egogqAa2MjZlShcA6Xvva2QAVEjpqzANap+28aWyCRVT7YkY7LckVcLwJNW18Dpl7Q4ngy 8crKCL13qFZSq8Fx+9otn0aqja8VKPqpdskk5LxBR/9t1zMMkdu6/R2FM84kxYRFSvC1IDg1BRW7 hzp8w3iHcOwbVtsmWfnQGGis4EvbR3jXsI0ESXwhBU2hwt/J18C+HygJl/jEzm1SsR8v3aJbN/NZ fa8pHhHaz+HPa0HAgEx4sWDF
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Feb 2021 01:39:41 -0000

On 2/24/2021 1:46 AM, Keith Moore wrote:
>> 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.

Yes, at the end of the day the IETF will produce specifications. But 
there is a world of differences between specifications that result only 
from theoretical considerations and specifications that were produced 
and tested by developing implementations. It is a bit like the famed 
difference between theory and practice.

> 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). 

Similar considerations happen today. Different languages of course, but 
also different deployment conditions, dealing with different load 
balancers, different architectures of server farms, firewalls, 
transmission medias... And, by the way, developing in C is somewhat 
controversial these days, but there are different schools of thought 
about what the replacement language should be.

-- Christian Huitema