IETF Logo Mail Archive

Re: Alternative decision process in RTCWeb

Phillip Hallam-Baker <hallam@gmail.com> Mon, 02 December 2013 20:26 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098CB1ACCE2 for <ietf@ietfa.amsl.com>; Mon, 2 Dec 2013 12:26:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Gpvav4B2kxDP for <ietf@ietfa.amsl.com>; Mon, 2 Dec 2013 12:26:08 -0800 (PST)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B65A51ACCFF for <ietf@ietf.org>; Mon, 2 Dec 2013 12:26:07 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id u57so6833014wes.4 for <ietf@ietf.org>; Mon, 02 Dec 2013 12:26:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v3aJGduZ7v/kcr2/GeLP41d/t67u1ulxWBpltmGGtY4=; b=JfgIwwaAfK5wokR0tJzEdtPni7+N3wu2vwcmr8mfhNLZoAaD1Kp2rJjGPKO4w4SqyI 5AASuL28/dBZQjUUVKZu6/lIXhBOA8IDxitReEoMpFqTyQRAc+ZhAVyswbpWKgo6Y/nf XAlgC4qBb9W/JEpv7BZcvtBv/VM6EMpPfslJx9c50c8IkC+yTE03ZfZfJLtSXN9Dh3CF tI1Pz+2v1ESHAgTMSuDeyE2cKrPeeoWctsMzx6ejyAwKcds+y76bYA5JBKsZF15UEk7/ +QCxhZnBxLX7vvrFgiglE3084AsQeJGvmf4YC1+WzFGuaGQODbNwyV6HlYO/DHWwyXxM yfBw==
MIME-Version: 1.0
X-Received: by 10.194.94.167 with SMTP id dd7mr3842863wjb.43.1386015964906; Mon, 02 Dec 2013 12:26:04 -0800 (PST)
Received: by 10.194.243.136 with HTTP; Mon, 2 Dec 2013 12:26:04 -0800 (PST)
In-Reply-To: <529CC0CA.6050305@dcrocker.net>
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <52974AA8.6080702@cisco.com> <CAKFn1SHMBG=Rwq8SNJkPz6EUD9O9P+0gTD569_5eXc7ndBpYRQ@mail.gmail.com> <529A0A4A.1040107@gmail.com> <8610FB3A-D931-4B89-A753-CA64B8AA80DB@cisco.com> <529CC0CA.6050305@dcrocker.net>
Date: Mon, 02 Dec 2013 15:26:04 -0500
Message-ID: <CAMm+LwhLCKo_=EdPEH39cN1+RVs0yQc=Mq6c1aJeJADxBG1SVA@mail.gmail.com>
Subject: Re: Alternative decision process in RTCWeb
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: multipart/alternative; boundary="047d7bb03c463dce4404ec92fd2c"
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 20:26:10 -0000

On Mon, Dec 2, 2013 at 12:18 PM, Dave Crocker <dhc@dcrocker.net> wrote:

> On 12/2/2013 8:08 AM, Cullen Jennings (fluffy) wrote:
>
>> We have NOT called for a vote. We have NOT even sent out an consensus
>> call to see if there is consensus to use an alternative process. We sent an
>> email to discuss that possibility. I really wish people would actually look
>> at what is going on.
>>
>
>
> Actually, the thread has been pretty good about focusing on what's being
> done.  What's being done is an effort to invent an IETF voting process,
> exactly contrary to established IETF principles and practice.
>
> The pressures towards voting are constant and reasonable.  For the IETF,
> they are also wrong.
>

Actually they are right, they just have the wrong process.

This is not a technical decision, if it was, the answer would be very easy
to decide, just run some tests.

The issue is a business decision and the question for browser and platform
providers is whether a proposed MTI CODEC is available to them on
acceptable terms. Here acceptable depends not on the state of patent law
but the state of patent gamesmanship and the cost of evaluating a proposal
for potential infringement liability, the cost of mounting a defense, the
risk of an adverse judgement, etc.

The people who decide such matters are not here at the table so argument is
superfluous. And simply asserting that a CODEC is MTI will not make it so,
it will only help interoperation if the stakeholders decide to recognize
the outcome.


Rather than having a vote for a particular CODEC, the only approach that
can arrive at a consensus is for the stakeholders to state which CODECs are
acceptable to them and define consensus as being a CODEC that is supported
by 90% or 95% or some overwhelming proportion of stakeholders by market
share.

That isn't IETF process either but it is the only approach that is going to
result in a decision that has buy in from all the necessary stakeholders.




-- 
Website: http://hallambaker.com/

v2.23.0 | Report a Bug | By Email