> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf