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!
I tried to resist the 47th rehash of this thread, but... too late...
Within a commercial environment, the organization has to be
fairly convinced that their better mousetrap is going to work,
in order to fund it, productize it, document it, sell it, and support it.
This process will always find more bugs in the mousetrap than
simply documenting it and skipping all the other steps.
If a vendor bothers to do all this, and multiple IETFers can say in a BoF
that they have used the mousetrap and it really does work,
that is worth a whole lot more than "I read the draft and
it looks pretty good".
There is a certain amount of healthy risk that the IESG
can take when chartering new standards-track work.
Prior implementations should not be a gating factor, but
it makes their decision much easier when there is objective
evidence the mousetrap actually works and it is already being
used by the industry.
But implementation and deployment are not enough alone.
There also needs to be some pre-existing consensus that
a standard version could be written and approved by the IETF,
and people are willing to work on it.
The slogan says "rough consensus and running code".
It doesn't say "rough consensus, then running code".
Without running code, there is no deployment.
Without deployment, there is no point to this exercise.
Andy
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.
(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)
Lixia
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf