Subject: Re: [rtcweb] Alternative decision process in RTCWeb

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Nov 2013 10:34:48 -0500

On Nov 28, 2013, at 8:52 AM, Eliot Lear <[email-masked]> wrote:
> While I appreciate the difficult position the chairs are in, I don't
> agree with the approach and I believe it is inappropriate for the
> working group to make such a decision.  Working groups don't vote.  Want
> to change that process?  Better gain IETF consensus first.  And I will
> argue against any such attempt.  There are plenty of other standards
> bodies that do vote.  Go to one of them if that's what you want.

One of the things to talk about here is the issue of voting versus a coin toss.   The advantage of a coin toss is that nobody can say it was gamed, because it's random—there is no process to blame if it doesn't go your way.   Voting, however, is somewhat predictable, and can be gamed.

So the concern is that if the working group has consensus to vote, it's probably because interested parties have some reason to believe the vote will go their way.   They may be horribly mistaken, or they may be correct—that isn't the point.   The point is that they aren't actually okay with the outcome not going their way.

So if the working group is willing to agree to a vote, and unwilling to agree to a coin toss, that says something _very important_ about the status of consensus in the working group.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Nov 2013 12:02:57 -0500

On Nov 28, 2013, at 11:29 AM, Dave Crocker <[email-masked]> wrote:
> As merely one obvious example, people can simply be tired of the impasse
> and eagerly seek progress and be willing to settle on any mechanism they
> think will fairly break it -- even if it works against the outcome they
> prefer.

The one tidbit you may be missing is that the working group specifically chose not to do a coin toss.   So "willing to settle for any mechanism" clearly doesn't apply in this case.

---

From: cowwoc <[email-masked]>
Date: Thu, 28 Nov 2013 12:55:17 -0500

> So if the working group is willing to agree to a vote, and unwilling to agree to a coin toss, that says something _very important_ about the status of consensus in the working group.

The list we are preparing to vote on is an all-inclusive list. If you 
feel that a coin flip is a better option, you're going to need to 
compile an "all options being equal" list first.

If it's any consolation, I believe the fact that voting records will be 
open to the public (who voted and for what) will act to reduce gaming or 
at least enable us to detect it after-the-fact.

Which brings up the question: will the vote results be binding? Or will 
they act as a strong recommendation for a follow-up consensus call? :)

Gili

---

From: Dave Crocker <[email-masked]>
Date: Thu, 28 Nov 2013 08:29:10 -0800

On 11/28/2013 7:34 AM, Ted Lemon wrote:
> if the working group has consensus to vote, it's probably because
> interested parties have some reason to believe the vote will go
> their way.
...
> So if the working group is willing to agree to a vote, and unwilling
>  to agree to a coin toss, that says something _very important_ about
>  the status of consensus in the working group.

No it doesn't.  Or at least, not what you indicate, above, that it says.

The thinking you describe is possible, of course, but it's not
guaranteed.  People's motives and expectations and logic can vary quite
a bit in a situation like this.

Let's not confuse 'possible' with 'certain'.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Nov 2013 14:52:40 +0100

Eliot

On 11/28/13 2:35 PM, Hervé wrote:
> Dave Cridland wrote:
>
>> 2) If the Working Group does want to mandate a single codec, is there
> consensus for one of the alternate decision-making processes described
> in RFC 3929? This is our best guess at what to do here; despite it being
>  a (presumably expired) Experimental track RFC.
>
>
> RFC 3929 has been mentioned on the rtcweb mailinglist and during the last meeting.
> http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html
> http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_II
>
>
>> If nobody else appeals the decision, then I will - assuming I'm allowed to - if it gets this far.
>> it's not clear to me that there is a consensus surrounding the voting
> rules - they've certainly yet to be summarised in one place based on the
>  discussion that has occurred so far.
>
> No decision yet. Per
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html today
> is the last planned day for comment/discussion on the _proposal_ to vote,
> before the proposal gets updated. A further call for consensus to use
> the proposal would follow after updating.
> Perhaps you'd like to get involved now rather than later.
>
>
> Here's what I sent to someone else regarding the proposed schedule:
> Nov 28          last day of comment/discussion period on proposed _voting process_ http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html
>  
> after Nov 28    WG chairs will update, if necessary, the process proposal
> after update    normal IETF process to reach consensus about adopting the (updated) process proposal
>  
> +2 weeks        last day of the consensus call about adopting the voting process
>  
>  
> IF consensus was reached to use the voting process in those 2 weeks after the update for that process, ONLY THEN would the (2 week) voting period start (if that wasn't changed in the update/concensus call).
>  
> So the voting process can theoretically _start_ Dec 13 at the earliest, if accepted. Probably later (if ever), given that updating the proposal is unlikely to be instantaneous.
>  
>  
> I hope that made it clearer. The source for this is the bottom section of http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html
>  
>  
> - Hervé 		 	   		  
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Nov 2013 15:51:22 -0500

On Nov 28, 2013, at 2:27 PM, Michael Richardson <[email-masked]> 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.

Right, that's the concern.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Nov 2013 14:39:49 -0800

> 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?  

Given that "alternative decision processes" are quite unlikely to influence participant behavior,  it is appropriate to question why such a voting process is being used, without at least a determination of consensus to do so.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 29 Nov 2013 01:07:51 +0000

While I don't believe the WG would be positive on that, I do not believe that question has been put to a consensus call. So I would question the word specifically. 

If you still believe it so, please tell me when you think the WG decided this.

Keith 

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Lemon
> Sent: 28 November 2013 17:03
> To: Dave Crocker
> Cc: [email-masked]; Eliot Lear; 
> [email-masked]; Eric Burger; IETF Discussion
> Subject: Re: [rtcweb] Alternative decision process in RTCWeb
> 
> > As merely one obvious example, people can simply be tired of the 
> > impasse and eagerly seek progress and be willing to settle on any 
> > mechanism they think will fairly break it -- even if it 
> works against 
> > the outcome they prefer.
> 
> The one tidbit you may be missing is that the working group 
> specifically chose not to do a coin toss.   So "willing to 
> settle for any mechanism" clearly doesn't apply in this case.
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Nov 2013 22:38:03 -0500

> If you still believe it so, please tell me when you think the WG decided this.

I'm just going by what people have told me.   If the working group hasn't indeed been asked whether they would accept the outcome of a coin toss, I would argue that that question should be asked.

---

From: Ron <[email-masked]>
Date: Fri, 29 Nov 2013 16:39:36 +1030

On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote:
> [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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Nov 2013 14:27:33 -0500

Ted Lemon <[email-masked]> wrote:
    >> mechanism they think will fairly break it -- even if it works against
    >> the outcome they prefer.

    > specifically chose not to do a coin toss.  So "willing to settle for
    > any mechanism" clearly doesn't apply in this case.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Maik Merten <[email-masked]>
Date: Fri, 29 Nov 2013 09:30:28 +0100

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 29 Nov 2013 00:22:53 -0800

I'd prefer seeing the charter changed and no codec mandated.
The only reason to specify a must-implement is to increase interop; if
mandating a codec does not increase the amount of interop, why do it?

-=R

On Thu, Nov 28, 2013 at 7:38 PM, Ted Lemon <[email-masked]> wrote:

> I'm just going by what people have told me.   If the working group hasn't
> indeed been asked whether they would accept the outcome of a coin toss, I
> would argue that that question should be asked.
>
>

---

From: cowwoc <[email-masked]>
Date: Fri, 29 Nov 2013 10:54:35 -0500

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:
> 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:
>
> 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
>

---

From: Leon Geyser <[email-masked]>
Date: Fri, 29 Nov 2013 20:01:45 +0200

I also agree what Ron said.

On 29 November 2013 17:54, cowwoc <[email-masked]> wrote:

>> 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.
>>
>> "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:
>>
>> 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
>>

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 29 Nov 2013 15:41:24 -0500

> Why would this one simple procedure not work to resolve the deadlock?

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