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

[Keith Moore <[e-mail]>]

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.