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.
