Re: [rtcweb] Last day for any additional Video Codec Selection alternatives

"Hutton, Andrew" <andrew.hutton@unify.com> Thu, 28 November 2013 07:44 UTC

Return-Path: <andrew.hutton@unify.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 4A5DA1AE182 for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 23:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y79Ky5ePkoXt for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 23:44:06 -0800 (PST)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 39D4E1AC7EE for <rtcweb@ietf.org>; Wed, 27 Nov 2013 23:44:06 -0800 (PST)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id E042C1EB85CA; Thu, 28 Nov 2013 08:44:04 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 08:44:04 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [rtcweb] Last day for any additional Video Codec Selection alternatives
Thread-Index: AQHO68jmMsNzl/GA5k+N2jf2CqzHjZo6Q6aN
Date: Thu, 28 Nov 2013 07:44:03 +0000
Message-ID: <384FC86B-9D26-41AF-8A79-9EB76609049E@siemens-enterprise.com>
References: <CEBBC7E7.1F4ED%mzanaty@cisco.com>,<529680EF.4010908@jitsi.org>
In-Reply-To: <529680EF.4010908@jitsi.org>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives
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: Thu, 28 Nov 2013 07:44:08 -0000

+1 to Emil's comments seems some people have forgotten that the first phase of this process is a consensus call on whether to go ahead with voting or not.

I am still hoping it won't come to a vote which is unknown territory for the IETF and unlikely to provide any good result.

Andy

On 27 Nov 2013, at 23:32, "Emil Ivov" <emcho@jitsi.org> wrote:

> On 27.11.13, 22:42, Mo Zanaty (mzanaty) wrote:
>> Several folks have objected to a vote. Is it worthwhile to have an
>> alternative that expresses this?
>> 
>> ³Voting MUST NOT be used to decide MTI video codec(s).²
>> 
>> I realize it is whacky to ask someone to vote to express an objection to
>> voting.
> 
> It is indeed quite ironic.
> 
>> But otherwise, how will the chairs/ADs be able to reconcile the
>> objections with the vote results?
> 
> The same way we generally declare consensus or lack thereof. A vote would be exactly as nonsensical here as for any other IETF decision.
> 
>> I¹ve only seen a handful of voting objections,
> 
> I haven't seen any arguments against those objections. Just people worried that if a vote does eventually happen their favorite option might not be on the list.
> 
> I haven't seen anyone explaining how any possible constituency would be defended, how non-rights would be determined, or why it is IETFs business at all to resolve questions after clearly proving it couldn't.
> 
>> and only several dozen total voices expressing various
>> opinions, while the rooms seemed packed with hundreds and the list has
>> over a thousand subs. I have no idea where rough consensus lies in the
>> larger community,
> 
> You seem to assume that rough consensus necessarily lies somewhere. It doesn't. Sometimes people agree to disagree.
> 
>> nor how significant voting objections may be in that
>> larger community. But that seems like useful, perhaps essential,
>> information to know how to interpret the results. For example, if 40%
>> objected to voting (as a first choice),
> 
> What if 30% objected to voting as a third choice?
> 
>> that would immediately send a red
>> flag no matter what result was ultimately selected via instant runoff.
>> Conversely, if only 1% objected to voting, that may be less of a concern.
> 
> Or it may be game theory in action. It's an entirely new land where the IETF has not ventured before. Doing so now cannot work! A vote in the IETF is only a reason to contest the results forever and discredit the work of this group.
> 
> If we can't reach consensus then let's call it a day and leave another body do the call if they feel comfortable with it.
> 
> Emil
> 
> 
> -- 
> https://jitsi.org
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb