pausable explanation for the Document Series

Bound, Jim Jim.Bound at hp.com
Sat Jun 7 23:38:21 CEST 2003


If we want PS to mean do prototype but don't product the outcome.  Then
if a spec cannot get to PS say in 5 IETF meetings then it should just
die or got to experimental.  Then we have to use our partners in
industry like ISOC, Fora, other Standards bodies, and the Press to make
it clear to the market and vendors that PS will no longer or treated by
the IETF as "installed base" to not change it.  We would have to
grandfather all stuff before that for purposes of installed base or it
would be "perceived" as coo to kill something.
Most vendors are very careful with PS.

/jim

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:harald at alvestrand.no] 
> Sent: Thursday, June 05, 2003 2:14 AM
> To: john.loughney at nokia.com; problem-statement at alvestrand.no
> Subject: Re: pausable explanation for the Document Series
> 
> 
> 
> 
> --On torsdag, juni 05, 2003 06:53:57 +0300 
> john.loughney at nokia.com wrote:
> 
> > Hi all,
> >
> > I've always assumed that industry does not use DS or FS 
> simply because 
> > the IETF does not produce them in any great number.  The 
> IETF doesn't 
> > seem to produce them because WGs are, in general, charted 
> to make PSs; 
> > after which, they try to shut down.  There is very little 
> incentive in 
> > the IETF progress documents.  Industry, being industry, takes what 
> > they get & runs with it.
> >
> > I'm not sure how many of the proposals discussed would impact this 
> > situation in any meaningful way.
> 
> at least two try to:
> 
> Brian's DS/Full merger
> 
> <shameless plug>
> Maintenance Teams
> </shameless plug>
> 
> but industry running on PS is not a core problem, I think.
> 
> The more-core problem is industry running on protocols with 
> design flaws 
> and protocol bugs, which cannot be fixed because of the 
> installed base.
> 
> If PS was perfect, this would not be a serious problem. But 
> it isn't so.
> 
> (my favourite example of deployment lock-in is the MIME 
> version number - 
> when the first post-RFC revision of the MIME spec was done, 
> we wanted to 
> increase the version number from 1.0 to 1.1, to celebrate the 
> fixing of 
> many bugs and unclear points in the specification.
> One vendor had a product in days-before-release state, which 
> would not 
> interoperate with UAs that sent 1.1 in the version number.
> We decided to freeze the version number at 1.0 forever...... 
> not a big loss to humanity, but it looks stupid.)
> 
>                     Harald
> 
> 


More information about the Problem-statement mailing list