At 11:00 AM -0700 9/18/08, Ian Jackson wrote: > >That a different system might do things differently would not be good >for Debian so we don't encourage it. We would prefer to keep Debian >and its derivatives as close as possible so that we can share >development work (particularly, so that we can all benefit from each >others' improvements). Thanks for your considered reply to the issues. In the section above, you hit on one of the crucial issues: what's the cost of a fork? It's actually highly variable. In many instances, a fork doesn't actually create interoperability problems at all, but instead carries two different code bases forward in different directions, while still allowing bits and pieces from the two code bases to be passed back and forth at will. The cost there is low. In other instances, it does create two new systems, each of which continues to evolve separately but without the ability to freely move code from one to another. Both instances may limit the benefit each group may have from the other's efforts, but it is clearly the latter case which is the most troubling. In the IETF, the lack of interoperability is not simply expressed in the re-use of code, but in the compatibility of the wire formats and thus the ability to pass messages among the actors who share the net. In the IETF, interoperability is one the key measurements of success; without it, no protocol is a success in our terms. There are things which must also happen, but it is the foundation of all the protocol work that happens here. The contortions we engage to maximize that often look strange, but they fall out of a very basic principle: The Internet must not fork. To remain "the Internet" and not simply an internet, we must do everything we can to prevent it. There are a host of local optimizations which could be made in specific environments, and there are extraordinary temptations at times to make them and gateway at the border of those regions. It's almost always a mistake. Every time we have broken the core interoperablity of the network in order to achieve some local optimization, the system as a whole has been hurt. Sometimes so severely that we are still recovering. No one objects to the code implementing a protocol from being changed, modified, or, yes, forked. Maintaining a frankly ugly distinction between "code" and "text" is an expression of our willingness to see those modifications. But our willingness to see the protocols drift into a non-interoperable mess should approach zero. It hurts the net too much, by isolating those whom the net should connect. Speaking only for myself, regards, Ted Hardie _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf