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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf