Hi Brian, Thanks for the questions. > Can you justify "increasing number"? I don't mean compared to 1986, but compared (for example) to 2011? As long as I can remember, people have been concerned about participants who are "goers" rather than "doers" at meetings, and you seem to be adding a further concern, "doers" whose action is to write text rather than write code. [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. [Hannes] Since I am attending a small number of the working groups I am obviously curious whether others have made a similar observation. Maybe I am hanging around in the "wrong" groups. I also attend OAuth and TLS, which are different. In those two groups a lot of implementation and deployment work is happening. > Also, you don't mention operators, whose role is not to write code at all but whose contribution to the IETF is essential. So that's another category of "doers". [Hannes] Actually, I wouldn't make this distinction because it is really about the persons involved. Every bigger organization has people who are more disconnected from the engineering than others. That's totally fine. Also consider that we are not talking about writing product-quality implementations in this conversation. Those implementations are often, with the level of specialization in our world, created and maintained by bigger teams in a company. With our regularly changing drafts I would recommend to wait with product-quality code till the specification matures or is completed. > I'd like to see some actual facts about these various categories of "doers". What % were they 10 or 20 years ago, and what % are they now? Has the hackathon changed the numbers? Etc. [Hannes] We could collect some numbers. I doubt it would be easy to collect them from the past. We could re-use the document shepherd writeup. Already today we (at least Rifaat and I do it) indicate whether there are implementations of a specific specification. We could add information about testing, hackathon participations, and details about the implementations. We could capture whether the authors themselves have worked on the code or someone else. If it was someone else, we could try to loop them into the discussion to collect the feedback. > > I would include this aspect under diversity, particularly when talking about the new leadership election cycles. > Yes, it should be on NomCom's radar. The need for enough ops people has long been understood, but recent development experience is also relevant. > > 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. > > *: I am also including authors of protocol specifications that do not implement their own specifications. > That's a bit cruel. [Hannes] The IETF mission statement says that we care about "engineering quality" and "running code" then we have to figure out how we get there. As mentioned in other conversations, for me this means more use of formal methods for security protocols and implementations supporting specifications. I would also point to the need for testing but I am already now stretching the limits of what people are willing to hear... > In larger organisations, it might be totally infeasible. But again, RFC7942 is our friend. [Hannes] As mention above, I am not asking for product-quality code. For what I am trying to accomplish, namely to feed implementation experience back into the specification work, I would already be happy to get the implementers involved. Having worked in a big telco equipment manufacturer myself I know that the implementers do not start their work until the specification is finished (or even years later). So, you would need some prototyping work while you are writing the spec. At least when I was working for this unnamed telco equipment manufacturer, developing prototypes and PoCs was in scope of my work. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
