> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf