Re: [rtcweb] Alternative decision process in RTCWeb

Eliot Lear <> Thu, 28 November 2013 13:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0CA791ACC87; Thu, 28 Nov 2013 05:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.202
X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4SqprCCNwrZG; Thu, 28 Nov 2013 05:52:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 15A061A1F19; Thu, 28 Nov 2013 05:52:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2758; q=dns/txt; s=iport; t=1385646769; x=1386856369; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=of9Cwtn0+lzovpWosdPwYeOBUoJOdyRQmS6/RNEsyco=; b=KQkkMp1zDRt3gSixsIr44B4/QQZNEu+JZv+E/AALtVzlqEmUcT5mnL7i oHgu/LgAYxwlHGX54wqWsJzQNml4Spq3XfXjf4gzZDJML04Yc5cAANG+W S713Hh3qDxBqkHgz1h9GiZSaX1/fymUjAAwYSV6IXIV49/Q6D2ZyXGTtc 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,791,1378857600"; d="scan'208";a="771642"
Received: from ([]) by with ESMTP; 28 Nov 2013 13:52:48 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rASDqfke026951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Nov 2013 13:52:43 GMT
Message-ID: <>
Date: Thu, 28 Nov 2013 14:52:40 +0100
From: Eliot Lear <>
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: Hervé <>, Dave Cridland <>, IETF Discussion <>
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl>
In-Reply-To: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Thu, 28 Nov 2013 10:02:48 -0800
Cc:, Eric Burger <>,
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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: Thu, 28 Nov 2013 13:52:52 -0000

While I appreciate the difficult position the chairs are in, I don't
agree with the approach and I believe it is inappropriate for the
working group to make such a decision.  Working groups don't vote.  Want
to change that process?  Better gain IETF consensus first.  And I will
argue against any such attempt.  There are plenty of other standards
bodies that do vote.  Go to one of them if that's what you want.


On 11/28/13 2:35 PM, Hervé wrote:
> Dave Cridland wrote:
>> 2) If the Working Group does want to mandate a single codec, is there
> consensus for one of the alternate decision-making processes described
> in RFC 3929? This is our best guess at what to do here; despite it being
>  a (presumably expired) Experimental track RFC.
> RFC 3929 has been mentioned on the rtcweb mailinglist and during the last meeting.
>> If nobody else appeals the decision, then I will - assuming I'm allowed to - if it gets this far.
>> it's not clear to me that there is a consensus surrounding the voting
> rules - they've certainly yet to be summarised in one place based on the
>  discussion that has occurred so far.
> No decision yet. Per
> today
> is the last planned day for comment/discussion on the _proposal_ to vote,
> before the proposal gets updated. A further call for consensus to use
> the proposal would follow after updating.
> Perhaps you'd like to get involved now rather than later.
> Here's what I sent to someone else regarding the proposed schedule:
> Nov 28          last day of comment/discussion period on proposed _voting process_
> after Nov 28    WG chairs will update, if necessary, the process proposal
> after update    normal IETF process to reach consensus about adopting the (updated) process proposal
> +2 weeks        last day of the consensus call about adopting the voting process
> IF consensus was reached to use the voting process in those 2 weeks after the update for that process, ONLY THEN would the (2 week) voting period start (if that wasn't changed in the update/concensus call).
> So the voting process can theoretically _start_ Dec 13 at the earliest, if accepted. Probably later (if ever), given that updating the proposal is unlikely to be instantaneous.
> I hope that made it clearer. The source for this is the bottom section of
> - Hervé