pausable explanation for the Document Series

[Pekka Savola]

On Fri, 6 Jun 2003 john.loughney at nokia.com wrote:
> > 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).

In real world, people implement the protocols for pilot/test purposes in 
any case.  This can be done when the I-D has reached reasonable level of 
stability.

Of course, we could try to add some "experimental" category below PS, to 
try to document these pilot protocols -- but this is slightly problematic 
also, as we have to make sure people understand that if protocol is 
modified for PS, no backward-compatibility must be required..

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