An experimental RFC indeed has a lower acceptance bar when it comes to technical solutions, applicability, and ability to deal with various conditions in the Internet. For a standards track RFC, we would like to be very sure that it works well in almost all conditions that we can encounter in the Internet. An experimental RFC might only work well in some specific situations, or we would need testing to ensure that it works well in all situations. There might not be IETF-wide consensus that the solution is the one and only right solution for the problem in question. The solution may be technically insufficient in some way, e.g., lack management tools or scalability problems.
However, even an experimental RFC needs to satisfy some basic technical and process principles and be safe to use. In particular:
- We still need to believe that the idea is potentially good.- The working group needs to have consensus behind the design choices in the document. We are not here to publish a spec as it was in its individual stage; the point of the working group is that the working group has useful input to the document.
- Truth in advertising: the spec may be deficient in some manner, or, perhaps more likely, we do not understand how well it works. These cases need to be clearly documented in the specification. Its OK to say "we don't know if this works well".
- The specification cannot rewrite rules that were laid out in standard track specifications.
- The specification needs to be fulfill some basic safety rules, mostly about not making things worse and not hurting the rest of the Internet. For instance, even experimental RFCs need to deal with congestion avoidance.
- The specification must be up to a reasonable level of engineering. For instance, it should be fully specified, implementable, address security in some form, etc.
The exact ambition level beyond these basic requirements is largely up to the working group. My understanding is that people have high hopes for Lisp. I would expect you to shoot pretty high and not leave too many problems in the specification. Otherwise it would be hard to move from an experimental RFC to a standards track RFC, and any actual deployment would hit issues.
But in any case, fulfilling at leas the basic requirements is essential for a successful RFC publication. There has been situations where even experimental work has been stuck for years in the final IETF and IESG review stage, because the working group did not produce work that was acceptable to the rest of the IETF. So take care of this early, and talk to your chairs, ADs and technical advisors if there's any doubt about what's necessary in your documents.
Jari
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.