pausable explanation for the Document Series

[Bound, Jim]

I understand.  But keeping bugs out is something I consider pretty easy
to do if we follow a good engineering process and review.  Where it gets
tricky is the classic engineering trade-off of risk vs going forward and
where we live with the warts.  Another is if we have option 1, 2, and 3
and the WG is split on supporting all options.  This gets back to my
issue of we need to put the assumptions we have on the table better.

/jim

> -----Original Message-----
> From: Keith Moore [mailto:moore at cs.utk.edu] 
> Sent: Monday, June 09, 2003 12:13 PM
> To: Bound, Jim
> Cc: moore at cs.utk.edu; jari.arkko at piuha.net; 
> hinden at IPRG.nokia.com; problem-statement at alvestrand.no
> Subject: Re: pausable explanation for the Document Series
> 
> 
> > 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.
>