Re: Alternative decision process in RTCWeb

Eliot Lear <lear@cisco.com> Thu, 28 November 2013 10:24 UTC

Return-Path: <lear@cisco.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 99CE01ADF47 for <ietf@ietfa.amsl.com>; Thu, 28 Nov 2013 02:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level:
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 vHA0HyQ3gyQk for <ietf@ietfa.amsl.com>; Thu, 28 Nov 2013 02:24:32 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 57DBD1ADF46 for <ietf@ietf.org>; Thu, 28 Nov 2013 02:24:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1365; q=dns/txt; s=iport; t=1385634271; x=1386843871; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=beMz6k0512NY5c476nmP1nL+SoZpBAdATasrBNr/+Z8=; b=X4b4DJDj5taKBbd1B1/nC3wm8xZsKscZhnabL6jkzNB/+AxQTDjnXu/+ c/5/N3qv55uhe+2A6ErqHNEx2rZgU2g5Y2mGItNAu5+GuCwjAJfJZBydU YiTDGWnU43i9rGuicRsVPnAtMaNZAPtFbzcXJxVoGzdfGH17EPP7pEQFr g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAEEZl1KQ/khR/2dsb2JhbABYgwc4g020fk6BIBZ0giUBAQEEI1UBEAsYAgIFFgsCAgkDAgECASsaBgEMAQcBAQWHeA2vJpBzF4EpjQ0BAU8HgmuBSAOYFJITgyo7gTU
X-IronPort-AV: E=Sophos;i="4.93,790,1378857600"; d="scan'208";a="761518"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 28 Nov 2013 10:24:30 +0000
Received: from mctiny.local ([10.61.163.87]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rASAONF6026183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Nov 2013 10:24:25 GMT
Message-ID: <529719D7.9020109@cisco.com>
Date: Thu, 28 Nov 2013 11:24:23 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, IETF Discussion <ietf@ietf.org>
Subject: Re: Alternative decision process in RTCWeb
References: <52970A36.5010503@ericsson.com>
In-Reply-To: <52970A36.5010503@ericsson.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: rtcweb-chairs@tools.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: Thu, 28 Nov 2013 10:24:34 -0000

Hi Gonzalo,


On 11/28/13 10:17 AM, Gonzalo Camarillo wrote:
> Folks,
>
> as you may know, the RTCWeb WG is trying to select a
> mandatory-to-implement video codec. So far, the WG has been unable to
> reach consensus using traditional consensus calls. Now, the WG is
> considering alternative options to make that decision.
>
> If you are interested in following that discussion on the RTCWeb list,
> this would be a good place to start:
>
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html
>

Let's be clear on what is being suggested: a form preferential voting
rather than continuing to seek rough consensus through other
alternatives.  The ramifications of what is being proposed extend well
beyond the working group.  That is not how our organization operates. 
As Bernard Aboba wrote:

> [BA] It strikes me that once we venture beyond consensus and running
> code into voting, we have left our home behind for someplace else
> whose principles should at the least be articulated.

And I would go further.  I would expect a very rough process ride if
this path is taken, and it should require IETF consensus given the
potential moral hazards it introduces to other activities.  Failing that
consensus, the working group should find a way to sort themselves within
the bounds of our existing processes.

Eliot