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

Emil Ivov <emcho@jitsi.org> Wed, 27 November 2013 23:32 UTC

Return-Path: <emil@sip-communicator.org>
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 A2FD51ADF7C for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 15:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 P09Z0jXH-MNI for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 15:32:04 -0800 (PST)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6503D1ADE72 for <rtcweb@ietf.org>; Wed, 27 Nov 2013 15:32:04 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id ca18so102662wib.11 for <rtcweb@ietf.org>; Wed, 27 Nov 2013 15:32:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fFTsN59ohhVcnR0rDwk55tRPFDPYtyC8k3d/jYJNxvo=; b=l+8WyBjlUvmLwWTtudc15HpolN+1qjCIxrc17y+gUzufCVp0/IhhJ4HBfp0wo0FgyW qIY9GGEnn0CpztSWrR9snHBhBRI9jxEgXkhGSOnmaBKCv4+nu7Y9Yhh9Q04b8jHM3hbv tKyUB3vL/duNWi/0GgdzJQuhQ/xowLTODvDbgU+7ger8Exj3x1FB8FZ6JcILHjPih5c+ ZHjYpZpL9VESEM0mqZkaf690UletbT8f912d2W8kjdwK6kSWntHzkeIgHPX8gQAzwOt+ WxFdqpLm7Mxp+AgQo0nfwFRfL9Magr6uwlbyuy4c+4e9D8YKFRlQVtfTdXbxoEejIcta R/Zg==
X-Gm-Message-State: ALoCoQkgS9LRUBvuOEpa/nHZm9bDg6zgVDmpjPPA/+ipECU7g4hgcOUG3myHGeX8u+pRLmvuIElr
X-Received: by 10.180.103.193 with SMTP id fy1mr353176wib.10.1385595123211; Wed, 27 Nov 2013 15:32:03 -0800 (PST)
Received: from camionet.local ([2a01:e35:8a04:14f0:e0dc:6c8b:ed3a:af2e]) by mx.google.com with ESMTPSA id w1sm39999431wib.6.2013.11.27.15.32.00 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 15:32:02 -0800 (PST)
Message-ID: <529680EF.4010908@jitsi.org>
Date: Thu, 28 Nov 2013 00:31:59 +0100
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
References: <CEBBC7E7.1F4ED%mzanaty@cisco.com>
In-Reply-To: <CEBBC7E7.1F4ED%mzanaty@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
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: Wed, 27 Nov 2013 23:32:06 -0000

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