On 11/4/13 7:52 AM, Larry Masinter wrote:
I don't think the draft helps clarify this point, at all, since it dwells at length on
"consensus" and "rough consensus" in terms of numbers independent of the nature
of the source.
I want to reserve judgment on the main point Larry makes, but I
explicitly disagree with the above, and I'd like to hear his reaction to
this before going back to the main question:
The draft explicitly *disavows* talking about numbers. It says that you
*can't* determine rough consensus on the basis of numbers, but rather
must look at the issues. And I think it says (or at least implies) that
you should look at the *issues* independent of the nature of the source. So:
For me, "rough consensus" and "running code" should be taken together, not independently.
I've always taken it as "rough consensus OF THOSE WITH running code".
If you've got a real technical issue, I don't think it matters if you
have running code.
Now, the reason I want to reserve judgment is because when we get to the
"rough" part, the draft says that we do have to make engineering
tradeoffs and might decide that we're going to dismiss a real technical
issue based on some other reasons (quoting the document, e.g., "But we
have a great deal of code already written that is similar to protocol X.
While I agree that protocol Y is more elegant, the risks to
interoperability with an untested solution is not worth it compared to
the advantages of going with the well-understood protocol X."). Does the
set of people saying "we need a different tradeoff" need to be folks who
have running code? That I might be convinced by. But I'm not sure. I'd
like to hear about some suggested text for sections 2 or 3 that talk
about this. I certainly don't want to require that any issue requires
someone with running code. But I'd like to hear more on this.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478