But that's specifically what "proposed" is for (currently). "Here's
something we think we want to make a standard -- now test it".
The problem with this notion is two-fold:
(1) Almost all protocols stay at "Proposed".
(2) The impact is particularly profound if there are multiple candidate
protocols in a working group. If we had the model, "let's make all
viable candidates Proposed Standards and then re-convene in a year to
see which one worked best", there would be a basis to the deferred
implementation experience.
In most cases, the chosen protocol works well enough, if necessary after
an RFCxyz-bis round ("with enough thrust, anything flies"), but we don't
seem to do a good job in using early implementation experience to guide
our choice.
On the positive side, it should be noted that the NSIS working group
just had a pre-IETF interop event with 5 implementations, even before
working group last call on the main specs. From what I gather, these
have been quite useful in confirming the implementability of the spec
and in ferreting out some remaining issues. In that case, there were no
competing protocol proposals, however.
Henning
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf