pausable explanation for the Document Series

[john.loughney at nokia.com]

Hi Pekka,

> 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.
> 
> 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.
> 
> 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.

Of course the core of any protocol developed in the IETF should be 
extremely stable even at the PS level.  However, if how can you
get deployment concerns for many protocols that are not yet PS?  There
is a big chicken & egg problem here.  For protocol work, we should
have a tight scope on what is contained in the draft (& later PS).

John