pausable explanation for the Document Series

Pekka Savola pekkas at
Fri Jun 6 10:30:05 CEST 2003

On Fri, 6 Jun 2003 john.loughney at 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 

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

More information about the Problem-statement mailing list