pausable explanation for the Document Series
pekkas at netcore.fi
Fri Jun 6 10:30:05 CEST 2003
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
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