Re: [rtcweb] Alternative decision process in RTCWeb

[Leon Geyser <[e-mail]>]

I also agree what Ron said.


On 29 November 2013 17:54, cowwoc <[e-mail]> wrote:

>
> I'm in favor of this approach, with a fallback to voting if that fails,
> with a fallback to "No MTI" if that fails.
>
> Gili
>
>
> On 29/11/2013 3:30 AM, Maik Merten wrote:
>
>> 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
>>>
>>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>