pausable explanation for the Document Series

[Jari Arkko]

Bob Hinden wrote:

>> The more-core problem is industry running on protocols with design 
>> flaws and protocol bugs, which cannot be fixed because of the 
>> installed base.
>>
>> If PS was perfect, this would not be a serious problem. But it isn't so.
> 
> 
> First versions of anything are never perfect.  This is true for products 
> and standards.  As long as we try to solve the problem by trying to make 
> the first version perfect we will fail.  It only delays the first 
> version and causes it to miss the market need.  The only solution I know 
> of is to do new versions.  This seems to work well in industry.
> 
> Perfection doesn't work.  Shipping products and getting bug reports works.

Agree 100%. Waterfall development vs. incremental development.
Serious debates early on in the project how all possible features
"must" be supported. Claims that engineers would not make the
mistakes they usually do, if they had just done more "planning"
or "design". Introduction of reviews, so that more problems
can be caught. Claims that the product we are making is soooo
important that we can not possibly have any bugs or missing
features in it. In the end, key success factors for the project
are missed, because no one bothered to try out how the thing
would work out in real usage. Or competition is on its improvement
cycle 17 when your first buggy release comes out. Or you run out
of money. Finally, the management blames the engineers for
bad quality.

I've been there in the distant past, but I know better now.
But I'm alarmed that the above sounds very much like the
discussions we're having here.

A few observations on what this might mean for
the IETF:

- It really is essential to get real usage, not just
   more reviews or interop tests. So *some* amount of
   industry adoption early on is required.

- Having to "fix" a standard (e.g. deprecate site-locals)
   is not a sign of bad early specifications, its a sign
   of being able to learn and adopt.

- While we normally don't like to compromise on things
   like quality, security, scalability, we have to learn
   to do things in pieces better. And when we are already
   doing things in small pieces, we need to have a better
   view of the full architecture/roadmap early on.

- This doesn't necessarily mean that we have to put out
   more PS RFCs with a lower quality. We could keep
   ahead of the industry's exaggeration of PS status
   value by introducing a new document level lower in
   chain.

--Jari