Re: "why I quit writing internet standards"

On 04/16/2014 09:14 AM, Yoav Nir wrote:
> On Apr 16, 2014, at 5:01 PM, 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.
> 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