pausable explanation for the Document Series

[Bound, Jim]

> I partially disagree.  It's often too challenging to later change 
> fundamental design decisions made early on: just shipping a 
> spec with a 
> thought like "we'll fix the issues later" seems like a recipe for 
> disaster.

This is a paranoid and low risk way of viewing first implemenation of
products and standards.  The key compromise to this paranoid view is to
make sure that applications do not depend on the change at least for
product.  For a standard that is where the applicability statement comes
in.  The paranoid view will have us doing things like DHCPv6 and MObile
IPv6 for 6 years to just get to PS and this is UACCEPTABLE.

> 
> Naturally, when updating the documents some features are 
> ripped off, some 
> clarifications added etc., but this *typically* cannot 
> influence the basic 
> way specs work.  And therefore, the core things in specs must 
> be in very 
> good shape.

Defining what is core then is a key to success for those who want to do
prototype and for those that are paranoid.

> 
> In consequence, "security will be described in other documents" or 
> "deployment will be considered in other documents" doesn't 
> sound like a 
> good idea.  These can often hide some very nasty surprises 
> which affect 
> your design decisions on the core spec.

I would agree with the above.  But a spec does not have to be secure on
the Internet for PS prototype only in a lab.  That is the core issue for
me.

/jim

> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
>