On 04/16/2014 09:14 AM, Yoav Nir wrote:
On Apr 16, 2014, at 5:01 PM, Wesley Eddy <wes@xxxxxxxxxxxxxxx> 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.
Except that an I-D usually doesn’t get IANA allocations, so you use a number from the private space, and you have to coordinate with anyone who wants to interoperate about which private number to use.
All this is true, AFAICT.
In a private conversation yesterday with My Esteemed Colleague From
Dublin, he asked why I thought we needed to pick AN answer, out of all
the possible ways for working groups to do what we're talking about here.
Stephen was right - we don't have to pick AN answer. What's appropriate
for some proposals may not be appropriate for other proposals (and IANA
considerations would be one of several flavors of constraints that would
vary across proposals).
But I think picking a few answers would be helpful.
One of the suggestions in this thread was that we put specifications
that are thought ready for prototyping in the same place, so people who
want to contribute to the process as implementers know where to look.
Not saying that's the right thing to do, but it's probably something
worth thinking about (rather than, "for that specification, in that
working group, if they think it's ready for prototyping, you should look
THERE, but for this other specification ...").
Finally, I'll say what I usually say at this point in the conversation,
which is that when we were talking about stuff like this in the early
2000s, the expectation was that we would wait until we had IETF
consensus to modify our process BCPs. It turns out that's a really high
bar. The IESG ended up approving https://tools.ietf.org/html/rfc3933 as
one way to try things without making irrevocable changes to the way
things work for everyone.
RFC 3933 is still in effect (as BCP 93), and it allows experiments with
changes to BCPs that would go away if they turn out to be bad ideas.
There are probably one or two reasonable process experiments that would
be appropriate as we try to figure out ways to (as Jari suggested):
o ... work to mutual benefit with open source efforts (those that
would benefit from an IETF-like environment)?
o ... better build specs to (rough) consensus, including making sure
that (an understood) vocal minority opinion does not block progress?
o ... focus on running code.
As we said at the IETF 89 Admin Plenary when discussing TRAM and DART,
the IESG can move pretty quickly when we get coherent proposals. Please
talk amongst yourselves, if this matters to you.
Spencer, who (full disclosure) was co-author on RFC 3933, speaking only
as a retired process wonk