IETF (still) too slow

The IETF is slow. The IETF is too slow. We know that, no news here.

There was a discussion today about this topic in the OPS area meeting of the 99th IETF meeting, mostly driven by the fact that the networking industry (not just the IETF) is hit by a wave of YANG modules. Some ideas were presented to help organize this process. I personally do not think the IETF has a problem due to a lack of version numbers nor do I think the IETF has a real problem with format conversions of artefacts. There are many formats people use to produce content and to convert into the IETF blessed I-D format. What I personally find lacking is the following:

• The IETF should encourage WGs and authors to use git. The IETF might consider to host a github clone such as gogs as a service so that WG can use it and data automatically falls under IETF contributions etc. (There is subversion and Trac on the tools server but git has won the version control competition so its time to move on.)
• What is lacking is early review and identification of core models that enable augmentations. There needs to be some architectural oversight, ideally a group of people that try to understand the big picture and that provide coordination (via the ADs). And ADs need to be willing to support this (of course).
• What is entirely lacking in the IETF is some form of release management; there need to be meaningful bundles of modules and ideally work should be prioritized to reach well defined release goals. (IETF has limited pools of experienced technical contributors that try to do too many things concurrently, which is often not effective.)
• What is often lacking is early implementation experience. Understanding how to do things right frequently benefits from implementation experience. If people do not have the energy to implement, there should at least be collections of examples (that can be validated) showing configurations for common scenarios.
• A more fundamental problem: The IETF rewards contributors by putting their name on RFCs. This causes some people to write specifications for career reasons instead of a keen interest in a certain technology and an interest to implement what they specify. This sometimes does not work well and often binds critical amounts of time of other contributors that could be more effectively spent on other things.
• Bad code smells. Filter aggressively if the code smells. Bad smelling stuff should be largely ignored (no agenda time etc.)