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".
yes. but then again, vendors are insensitive to certain kinds of bugs.
the myriad bugs produced by introduction of NAT are good examples. a
little bit of analysis should have convinced any responsible vendor to
either not sell NAT products, or to be honest in marketing them and to
accompany them with rather strong disclaimers.
(not to attack NATs specifically, they're just the most obvious of many
examples and the easiest ones to cite)
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.
again, being used by the industry is no indicator of soundness. and
being used by the industry in the absence of public protocol review is
highly correlated with poor design.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf