Re: [rtcweb] The Voting Process

Hi Hervé

-----Original Message-----
From: Hervé [mailto:h_o_w_@hotmail.com] 
Sent: Wednesday, November 27, 2013 5:16 PM
To: Gaelle Martin-Cocher; rtcweb@ietf.org
Cc: Magnus Westerlund; John Leslie; tim panton; Roman Shpount; Ron; cowwoc; Silvia Pfeiffer
Subject: RE: [rtcweb] The Voting Process

________________________________
> From: gmartincocher@blackberry.com
> To: rtcweb@ietf.org
> Date: Wed, 27 Nov 2013 20:30:51 +0000
> Subject: Re: [rtcweb] The Voting Process
>
>
> On the process:
>
>
>
> Could we try to reach a consensus by involving a multiple steps process?
>
> Could we structure the MTI question into three questions, with 
> consensus being declared on one before moving onto the next?
>
> This way the question is structured as to find the last point at which 
> a consensus can be achieved.
>
>
>
> This would look like:
>
>
>
> First step: determine the consensus for an MTI or not:
>
> 7. There is no MTI video codec
>
>
>
> Step two: determine the consensus for the "last resort" codec
>
> 6. All entities MUST support H.261
>
> 6. All entities MUST support H.263
>
> 9. All entities MUST support Theora
>
>
>
> Step three: determine if there is any further consensus on a better 
> MTI
> proposition:
>
> 1. All entities MUST support H.264
>
> 2. All entities MUST support VP8
>
> 3. All entities MUST support both H.264 and VP8
>
> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>
>      support at least one of H.264 and VP8
>
> 5. All entities MUST support at least one of H.264 and VP8
>
> 8. 5+$last_resort, i.e. All entities MUST support $last_resort and
>
>      all entities MUST support at least one of H.264 and VP8
>
> 10. All entities MUST implement at least two of {VP8, H.264, 
> $last_resort}
>
> 12. All entities MUST support decoding using both H.264 and VP8, and
>
>      MUST support encoding using at least one of H.264 or VP8
>
>
>
> If there is no consensus at step 3, then use the consensus reached at step 2.

> If a consensus for an MTI is reached at step 1, but there is no 
> consensus at step 2, then  no MTI would be defined.

At that point, they just agreed there should be an MTI.
[Gaelle] at that point we would have agreed that it would be ideal to have an MTI but as we can't reach a consensus on any of them, then the conclusion is "while it would have been ideal, the group is unable to make a recommendation, hence no MTI is defined".

Is the "we won't get to your high quality codec unless you first agree about these older ones" part to encourage people to reach consensus?
[Gaelle] Those last_resort codecs are indeed far to be ideal but seems more favorable to a consensus (from my perception of the discussions on the list and of previous consensus calls). If we can't reach a consensus even on those, then we don't move to step 3 as at that point it seem highly probable that we would not reach a consensus at step 3 either. It should be noted that some of the least controversial options in step 3 do not replace step 2 but are enhancing it. (e.g. option 8 and 10).
At the contrary, if we reach a consensus at step 2, then at step 3, we may either have enough desire to reach a consensus on one of the step 3 options, or that would clearly indicate that the consensus reached at step 2 is "good enough". 

Since they're looking for consensus, they could agree to have any number even no $last_resort in step 2, right? and then still proceed to step 3.
Is that intentional?
[gaelle] as proposed at the beginning, a consensus needs to be reached at each step to proceed to the next.

> Sincerely,
>
> Gaëlle

Looks like it could be a long process, with many opportunities to come to the default state, no MTI.

I think the voting process proposed by the WG Chairs could give about the same information faster, especially if modified to use a condorcet method.
But as far as consensus based processes go, I think Gaëlle's is preferable to going straight to no MTI.

- Hervé

> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
> Sent: Wednesday, November 27, 2013 2:08 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] The Voting Process
>
>
>
> If you could come up with an alternative that works, great. The only 
> reason we are voting is because all other options have failed.
>
> It is my understanding that we have the following options (from best 
> to
> worst):
>
>    1.  Come up with a better mechanism for establishing MTI, or
>    2.  Vote for MTI, or
>    3.  Give up and declare No MTI
>
> Gili
>
> On 27/11/2013 1:13 PM, Roman Shpount wrote:
>
>
>
> I am not sure about the rest of the group but from my point of view 
> the proposed process clearly shows that IETF in general and this group 
> in particular is not equipped to vote. I also strongly disagree that 
> voting would produce a MTI video codec decision which would meaningful 
> in any way. We need a way to find consensus regarding the MTI or drop 
> the whole MTI idea (which would also require consensus).
>
> _____________
> Roman Shpount
>
>
>
>
>
>
> _______________________________________________
>
> rtcweb mailing list
>
> rtcweb@ietf.org<mailto:rtcweb@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and 
> delete this information from your system. Use, dissemination, 
> distribution, or reproduction of this transmission by unintended 
> recipients is not authorized and may be unlawful.
>
> _______________________________________________ rtcweb mailing list
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb 		 	   		  
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.