On 16 Apr 2014, at 16:01, Wesley Eddy <wes(_at_)mti-systems(_dot_)com> wrote:
On 4/16/2014 9:31 AM, Thomas Clausen wrote:
FWIW, my personal belief is that "running code" should be a
requirement for anything going std. track -- and that a (mandatory)
period as Experimental prior to go std. track would yield the stable
spec against which to reasonably build code, and run
(interoperability) tests, fix bugs, etc. If after (pulling a number
out my hat here) a year as Experimental there's no running code, then
that's probably a good indicator, also, as to if this is something
the IETF should bother doing....
If there's no running code, or pretty concrete plans and commitments
to get there, then there's really no need for an Experimental RFC that
will get a number and last forever. An I-D that expires in direct
conjunction with the interest and energy in it is just fine.
Experimental RFCs are for things that we're encouraging folks to get
out and play with in multiple implementations,
Isn't that *exactly* what we want to see happen before we propose things as
standards?
I think that Spencer's thesis was that it didn't happen because "implementing
towards something that isn't stable and which expires" (and I-D) wasn't
attractive, and the bar for std.track was too high, so "something with a lower
bar, which is stable and archival, but which isn't a PS" would be helpful?
That "something" could conveniently be Experimental.
Experimental exists already, and the experiment targeted (at least, the RTG ADs
insist on Exp RFCs carrying an explicit section describing that) would simply
be "to build a few implementations and see if they interoperate". (Of course,
things with "sharp edges" or "things to figure out" would have a different "The
Experiment" section ... )
The only required "process change" would be, that ADs treat "Experimental" as
"Experimental" in their evaluation, and not at std. track (which they,
currently, do).
perhaps on the real
Internet or under some specific conditions, but which may have sharp
edges or explode on impact, and need a bit more work to figure out
if we can seriously recommend the world to depend on them as Standards.
Fair enough, but almost orthogonal to the point I am trying to make: going std.
track without running code (it has happened, and it is happening) makes even
less sense than going experimental without running code.