Subject: [lisp] experimental RFCs

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Sep 2009 16:00:01 +0300

Several people have asked me what difference it makes that we produce 
experimental RFCs in this working group. For instance, do we have a 
lower bar for these RFCs than we might have for standards track RFCs? 
For what it is worth, here's my opinion on this.

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