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

Emil Ivov <> Wed, 27 November 2013 23:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A2FD51ADF7C for <>; Wed, 27 Nov 2013 15:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P09Z0jXH-MNI for <>; Wed, 27 Nov 2013 15:32:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6503D1ADE72 for <>; Wed, 27 Nov 2013 15:32:04 -0800 (PST)
Received: by with SMTP id ca18so102662wib.11 for <>; Wed, 27 Nov 2013 15:32:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 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 with ESMTPSA id w1sm39999431wib.6.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 15:32:02 -0800 (PST)
Message-ID: <>
Date: Thu, 28 Nov 2013 00:31:59 +0100
From: Emil Ivov <>
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)" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.