Re: [rtcweb] The Voting Process

Gaelle Martin-Cocher <gmartincocher@blackberry.com> Wed, 27 November 2013 20:31 UTC

Return-Path: <gmartincocher@blackberry.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433E31A1F7D for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 12:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNKK3VC8Xuq9 for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 12:31:01 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0F71ADF9F for <rtcweb@ietf.org>; Wed, 27 Nov 2013 12:31:01 -0800 (PST)
Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 Nov 2013 15:30:53 -0500
Received: from XCT112CNC.rim.net (10.65.161.212) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 15:30:53 -0500
Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 15:30:52 -0500
From: Gaelle Martin-Cocher <gmartincocher@blackberry.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] The Voting Process
Thread-Index: AQHO65m19m9vCl4mUkGjCQkgFJ+S/Jo5skWAgAADH4CAAA8sgP//rKBA
Date: Wed, 27 Nov 2013 20:30:51 +0000
Message-ID: <92D0D52F3A63344CA478CF12DB0648AA548AE102@XMB111CNC.rim.net>
References: <52935C89.5040408@ericsson.com> <CAGgHUiQnkQKkc-ptMu6DtfUYJY6N9i7PUaeAqKxp96nB2MQBGA@mail.gmail.com> <52936207.5040704@ericsson.com> <E44893DD4E290745BB608EB23FDDB7620A13302B@008-AM1MPN1-041.mgdnok.nokia.com> <5295B273.1060305@ericsson.com> <C5B67CF6-44C2-44ED-A087-67D9737870AD@gmail.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com> <CAD5OKxshm+izp7N_2+rst_hfSCAccddgT-u7KRvbxJz6t5m+0A@mail.gmail.com> <52964309.3060108@bbs.darktech.org>
In-Reply-To: <52964309.3060108@bbs.darktech.org>
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.250]
Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AA548AE102XMB111CNCrimnet_"
MIME-Version: 1.0
Subject: Re: [rtcweb] The Voting Process
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2013 20:31:04 -0000

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

  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.