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

[Christian Huitema <[e-mail]>]

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