Re: [rtcweb] Alternative decision process in RTCWeb

[Basil Mohamed Gohar <[e-mail]>]

On 11/29/2013 01:09 AM, Ron wrote:
> On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote:
>>> On Nov 28, 2013, at 2:27 PM, Michael Richardson <[e-mail]> wrote:
>>> That tells me that the participants are not willing to live with losing and
>>> move on, and so no voting process will work either.
>>
>> [BA] The participants aren't willing to live with losing for business or
>> legal reasons that aren't within the jurisdiction of an IETF WG.  As an
>> example,  would an open source product that requires source code to be
>> provided without a license fee put that aside because IETF RTCWEB has agreed
>> upon H.264 as MTI?  Similarly, would a vendor who is concerned about
>> potential liability from incorporating VP8 put that concern aside because the
>> IETF RTCWEB WG has decided to make VP8 MTI?  
> 
> I think EKR said this more succinctly with:
> 
>  "it's important to understand that in in this case, many people more
>   don't want X than do want Y."
> 
> And I think you both have clearly identified the problem, and why voting
> is clearly not a solution to it.
> 
> 
> The blocking issue is that many people have valid reasons why they _can't_
> deploy one or more of the possible choices.  You can't possibly solve that
> by taking a poll of what the majority of people would _prefer_, ignoring
> all other people's blocking constraints.
> 
> 
> However I think we can still resolve this by following normal consensus
> procedures, and walking our way up from the least troublesome options to
> the most, and seeing at what point consensus actually breaks down.
> 
> 
>  1. Do we want an MTI codec?
> 
>    It's generally accepted there is consensus the answer to this is Yes.
>    We also have a list of codecs that we could possibly choose from.
>    It also seems generally accepted that IPR trouble is the least
>    negotiable  problem that is at the heart of many objections.
> 
>  So let's start where that problem is the smallest, at the very bottom:
> 
> 
>  2. Can anybody show a sustainable objection for why we _can't_ use H.261.
> 
>    If they can, we're probably doomed.  If they can't we have an initial
>    choice for MTI.
> 
> 
>  3. Can anybody show a sustainable objection for why <alternative>
>     can't replace H.261 as the MTI codec?
> 
>    If they can, lather rinse repeat through the other alternatives.
>    If they can't, we have a new baseline to ask this question of
>    for the remaining alternatives.
> 
> 
> Yes, this may take some time (but surely less than we've already spent),
> but it clearly separates the question of what people _can't_ do, from
> what they would prefer to do if they had their druthers.
> 
> We probably won't get the best possible codec as the MTI fallback,
> but we probably will get a decision that isn't fundamentally doomed.
> And that's fine, because people will still get their preferred codec
> through runtime negotiation if they use an implementation which does
> accept the risk of supporting it - and the safe interop fallback if
> it doesn't.
> 
> 
> Why would this one simple procedure not work to resolve the deadlock?
> 
>   Ron

This is as good or better than anything else I've seen mentioned so far.
 Definitely a +1 from me, not that we're voting or anything...;)


-- 
Libre Video
http://librevideo.org