Maybe I am the worst person to respond here but I agree with Brian. I've always had a problem with the large number of different document types. My overall view is that essentially market forces decide how a document is taken and implemented, and the IETF process has never had enough responsiveness to follow that in a timely fashion that has any real meaning. This applies to proposed standard --> draft standard --> standard, and it will not be different here. Changing something from experimental to proposed standard in a process that will probably take 12 months will be unlikely change the number of people implementing and deploying an RFC. Regards Keith > -----Original Message----- > From: wgchairs-bounces@xxxxxxxx [mailto:wgchairs-bounces@xxxxxxxx] On > Behalf Of Brian E Carpenter > Sent: 20 April 2012 16:24 > To: stbryant@xxxxxxxxx > Cc: adrian@xxxxxxxxxxxx; ietf@xxxxxxxx; wgchairs@xxxxxxxx > Subject: Re: Proposed IESG Statement on the Conclusion of Experiments > > On 2012-04-20 16:12, Stewart Bryant wrote: > > On 20/04/2012 14:36, Murray S. Kucherawy wrote: > >> What about the idea of requiring new Experimental documents to include > >> text that indicates when the experiment is to be considered completed > >> absent new work on it? Essentially, the document declares a date by > >> which the experiment is considered concluded, and code points > >> automatically deprecated, and the document itself goes to Historic > >> status, unless some other document action updates the deadline or > >> moves the work to the Standards Track. > > If you factor in the historic success rate that engineers typically have > > in predicting s/w development schedules, I would expect that the overrun > > rate on predicted end exp dates would be close to 100%, even after > > several extensions. > > Exactly. This whole discussion seems to be about over-engineering a > small corner of the IETF process that isn't a particular source > of practical problems anyway, afaik. > > So, the standard question: what's the problem that needs solving here? > > Brian