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.