On 7-aug-2005, at 1:07, Brian Rosen wrote:
I notice that we have stopped being interested in running code.
I think that is to our community's detriment.
[...]
Probably more importantly, I think we should be VERY suspicious of
new,
complex specifications before we have running code.
I've been thinking about this on and off for a day, and I'm not
convinced that having running code at the time a specification is
first fleshed out would be all that helpful.
Can you point to any instance in recent IETF history (after 1995 or
2000 or so) where having having running code early in the process
would have made for a better _designed_ protocol?
Sure, trying to implement something brings out bugs in the
specification, but those are usually relatively minor things that
don't go to the design of the protocol. And wide deployment generally
shows that a protocol could have been better in one regard or
another, and that some parts of it don't turn out to be useful in
practice.
However, waiting for implementations on account of the former only
delays having a fixed spec even longer (we already see protocols
_deployed_ before there is an RFC, which is very harmful IMO) while
waiting for the latter leads to insanity such as RFC 1771 being stuck
at "draft standard" even though it has dozens of interoperable
implementations, a decade of operational experience and there
wouldn't be an internet without it.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf