Lixia Zhang wrote:
......
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).
forgive me for jumping into the middle of a discussion (and I did not
know which of the lemonade doc's the above referred to), but my past
experience seems suggesting that an attempt to implement a "not well
understood" idea is a good way towards a better understanding of how
to make the idea work, or what can be potential issues.
Yes, but this is only useful once one understands what is actually
needed in a spec to begin with ;-).
I found running code most useful when the spec is nearly ready for
publication.
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.
it seems to me the above argues that running code is necessary, but
not sufficient as evidence of a sound design.
Agreed. Running code is useful to identify things that are difficult to
implement or unclear.
(well, that is the interpretation; I have not seen anywhere a claim
that running code is sufficient, but rather simply to filter out the
weed)
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf