pausable explanation for the Document Series

[Keith Moore]

> You miss the point I think?  And this is exactly how most products
> ship it is impossible to find all bugs in any first software release. 
> What you try to find are the show stoppers based on what that means
> for that product function.
> 
> So I suggest your disagreeing with reality?

Not at all.  Protocols aren't quite like products in several ways.  If
a vendor makes a buggy product, it screws those that buy that product,
but not everyone else who uses the same protocol.  (unless the vendor
has a monopoly, in which case I'd argue that the vendor has a higher
responsibility.)  Also, protocol bugs are often harder to fix than
product bugs(depending on the product). Also, protocols aren't specified
to the same level of detail that the code to implement those protocols
are, so it's reasonable to expect fewer bugs in protocol specs.

Again, I think the attempt to characterize the desire to have higher
quality in our protocol specs before we call them any kind of standard
(and before we consider them ready for deployment) as wanting those 
protocols to be "bug free" or "perfect" is misleading.  Clearly it is
neither possible nor realistic to expect bug free protocols.  But that
does not excuse our publishing a protocol standard with known bugs, nor
does it excuse our failures to do due diligence to avoid major problems
in our protocol designs.