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