Re: [rtcweb] The Voting Process

Hi Silvia,

If there is a consensus on the 3 steps approach then we should start talking about consensus call more than vote.
If we reach step 2, as there is much less options in step 2 than in step 3, we may be able to reach a consensus as per the usual IETF process.
If we reach step 3 there might be an opportunity given to the group to refine the list of options in step 3 to make the consensus call easier. 

Sincerely,
Gaëlle

-----Original Message-----
From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] 
Sent: Wednesday, November 27, 2013 4:54 PM
To: Gaelle Martin-Cocher
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] The Voting Process

That begs the question whether when voting one is allowed to click multiple boxes or just one.

Silvia.

On Thu, Nov 28, 2013 at 7:30 AM, Gaelle Martin-Cocher <gmartincocher@blackberry.com> wrote:
> 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.
>
>
>
> Sincerely,
>
> Gaëlle
>
>
>
>
>
> 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):
>
> Come up with a better mechanism for establishing MTI, or Vote for MTI, 
> or 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
>
> 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.