Re: [rtcweb] Alternative decision process in RTCWeb

[Maik Merten <[e-mail]>]

I very much agree with Ron here. Given that both H.264 and VP8 seem to 
not be universally deployable by all participants in all scenarios I 
guess many will agree that reaching consensus on one of those may not be 
realistic.

So it appears that we need $fallback (to be later used in something like 
"all entities MUST implement $fallback" or "all entities MUST implement 
at least two of {H.264, VP8, $fallback}" etc.). As far as I can see 
following codecs have been mentioned as possible candidates for $fallback:

H.261, MPEG-1 Part 2, H.263, Theora (sorted by age and performance)

I don't remember seeing an exploratory discussion to determine what (if 
any) codecs are considered to have "acceptable risk" (this is different 
from "no risk", which may not be achievable). However, it may take some 
time for each participant to make their own risk assessment. Thus I very 
much like Ron's proposal of starting discussion with the codec with the 
lowest perceived IPR risk and trying to move to higher performance 
levels until substantial indication shows up that the next step brings 
"unacceptable risk".


Maik

Am 29.11.2013 07:09, schrieb Ron:
> 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
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>