RFC 2026 says this about Experimental RFCs: The "Experimental" designation typically denotes a specification that is part of some research or development effort. However, I do not believe that this is still typical. Authors come up with ideas that they think are useful. If when the documents are ready for publication it is still not clear whether there are enough implementers convinced by the use case (some definition of running code), they are encouraged to publish them as experimental rather than proposed standard. I am the author of two Experimental RFCs. In both cases I was going for standards track, and in both cased an AD was the document shepherd and he told me to go for Experimental. The first of these (4478) has three independent, interoperable implementations in shipping code, although I don't know if it's used much. I am not aware of any implementations of the other one (6023), although there may be some. When I asked an AD about promoting 4478 to standards track (seeing as we have all this running code) his response was "why bother?" (these are three different ADs in this story...) Neither of these can really be called an "experiment" except in the sense of "let's see if the Internet needs this specification". They may be used more later than they are now, but they're in no way stopping. I don't see why we should waste precious cycles on maintaining old Experimental RFCs. Either they're in use or they're not, and a search engine can usually reveal this. It may be a good idea to have former authors or ADs or volunteers write a paragraph that can be displayed on, say, the tools page for the RFC, along the lines of "In seven years, this RFC has seen three independent implementations, but it is not in wide use", or "the protocol in this RFC is used everywhere on the web, and this could be progressed to PS if we had the energy." I don't think we should waste our energy by creating an RFC for each of those experimental RFCs. Yoav On Apr 19, 2012, at 11:31 PM, Adrian Farrel wrote: > All, > > The IESG has been discussing how to tidy up after Experimental RFCs. > > We have developed the following draft IESG statement. This does not > represent a change in process, and continues to value Experimental RFCs > as an important part of the IETF process. It does, however, seek to > encourage documentation of the conclusion of experiments. > > We are aware that there may be other discussion points around > Experimental RFCs, and we would like to discuss these, but we also > believe that there is merit in making small, incremental improvements. > > The IESG would welcome your thoughts on this draft before they approve > the final text on April 26th. > > Thanks, > Adrian > > ============= > > IESG Statement on Conclusion of IETF Experiments > > > Experiments are an established and valuable part of the IETF process. > A number of core Internet protocols were first published as Experimental > RFCs while the community gathered experience and carefully investigated > the consequences of deploying new mechanisms within the Internet. > > In the case where an experiment leads on to the development of a > Standards Track RFC documenting a protocol, the new RFC obsoletes the > old Experimental RFC and there is a clear conclusion to the experiment. > > However, many experiments do not lead to the development of Standards > Track RFCs. Instead, the work may be abandoned through lack of interest > or because important lessons have been learned. > > It is currently hard to distinguish between an experiment that is still > being investigated, and an old experiment that has ceased to be of > interest to the community. In both cases an Experimental RFC exists in > the repository and newcomers might easily be misled into thinking that > it would be helpful to conduct more research into an abandoned > experiment. > > In view of this, the original proponents of experiments (that is, > authors of Experimental RFCs, and Working Groups that requested the > publication of Experimental RFCs) are strongly encouraged to document > the termination of experiments that do not result in subsequent > Standards Track work by publishing an Informational RFC that: > > - very briefly describes the results of the experiment > > - obsoletes the Experimental RFC > > - if appropriate, deprecate any IANA code points allocated for the > experiment > > - may request that the Experimental RFC is moved to Historic status. > > If there is no energy in the community for the producing such an > Informational RFC, if the authors have moved on to other things, or if > the Working Group has been closed down, Area Directors should author or > seek volunteers to author such an Informational RFC. > > > Scanned by Check Point Total Security Gateway.