The danger here is that when people bring work to IETF, they might
refuse to change protocols which are already deployed.
This already happens to far too great a degree. People keep arguing
that because they have running/deployed code, IETF has to standardize
exactly what they have already produced. In many cases things that are
deployed before they get widespread design review are very poorly designed.
I think we've seen several examples of where the IETF has spent
significant amount of energy, ranging from heated discussions to
specification work, on solutions that simply won't fly. It would be
useful if that energy waste could be reduced. Having 'running code' as
a barrier for serious consideration within the IETF may be one approach.
I agree that running code should be given extra weight, but I am not
sure that running code should be a requirement for something which is
not well understood yet (some Lemonade WG documents come to mind).
IMHO, "running code" gets more credit than is warranted. While it is
certainly useful as both proof of concept and proof of implementability,
mere existence of running code says nothing about the quality of the
design, its security, scalability, breadth of applicability, and so
forth. "running code" was perhaps sufficient in ARPAnet days when there
were only a few hundred hosts and a few thousand users of the network.
It's not sufficient for global mission critical infrastructure.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf