Re: [rtcweb] Alternative decision process in RTCWeb

[Ron <[e-mail]>]

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