Gonzalo, Thanks for this really well written and good summary. Again, the chairs – and the area directors – as well as the whole RTCWeb group have been working really hard on what many of us think will be critical technology. As one of the whiners about voting, let me say first that *do* believe that strictly speaking the rules can be interpreted to allow voting. That doesn't make it a wise choice or a *substitute* for rough consensus. Therefore I subscribe to the following interpretation: On 12/6/13 10:57 AM, Gonzalo Camarillo wrote: > Other people think that using > processes such as straw polls or some types of voting can help the WG > understand better the situation at hand and help build consensus, which > will be *ultimately* evaluated in the WGLC and IETF LCs on the document. > And I would go further, and suggest that RFC 2418 provides working group chairs with very broad latitude to declare what rough consensus is in such circumstances. The document merely points out that it is > 51% and it needn't be 99%. That large range should be fair warning that the ruff in this case could be quite rough. The ultimate point, as Jari mentioned in his note of 2 Dec 2013 is to aim for broad interoperability. And again, as one of the whiners, I probably have a responsibility to put forward some thoughts on how one might proceed. I state this as an outsider to the WG, and so perhaps these ideas have been already tried or considered and discarded. You've created a rather long list of options. It seems to me that it would be good to know what we are talking about in terms of "rough". It might be useful still for participants to be polled on whether or not they could live with each of those options. That is - have a positive signal. This can be used to establish a front runner or group of popular choices. Recalling Jari's message again that interoperability is what we are aiming for, it might also inform the working group to understand what user bases and implementations are impacted, at the same time. Stating which implementation one is developing or is planning to deploy will hopefully provide some feel for interoperability. This does weight near term over long term, but I think that's a good approach (you don't get to long term if you can't satisfy near term). I offer these purely as suggestions to be discarded if they are not found to be useful. Again, I wish the WG and the chairs the very best in trying to untie this knot, and I offer to be whatever use I can to assist. Eliot