Re: Alternative decision process in RTCWeb
Eric Burger <eburger@standardstrack.com> Mon, 02 December 2013 00:07 UTC
Return-Path: <eburger@standardstrack.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 07D261AE22A for <ietf@ietfa.amsl.com>; Sun, 1 Dec 2013 16:07:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.122
X-Spam-Level:
X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no
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 qZ6pk_RPytrt for <ietf@ietfa.amsl.com>; Sun, 1 Dec 2013 16:07:15 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACFE1AE220 for <ietf@ietf.org>; Sun, 1 Dec 2013 16:07:15 -0800 (PST)
Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:60212 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <eburger@standardstrack.com>) id 1VnH2Z-0000xa-4N for ietf@ietf.org; Sun, 01 Dec 2013 16:07:11 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_8FE57436-FA77-474D-B1D7-0BA547A37FD1"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Message-Id: <B95A241A-40DA-407D-9077-54F1A5175687@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: Alternative decision process in RTCWeb
Date: Sun, 01 Dec 2013 19:07:03 -0500
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <52974AA8.6080702@cisco.com> <CAKFn1SHMBG=Rwq8SNJkPz6EUD9O9P+0gTD569_5eXc7ndBpYRQ@mail.gmail.com> <529A0A4A.1040107@gmail.com> <CA+9kkMB44JYj-hkp_O72f2yg-OtBuyqN=NC3aW2PBvh7ZO-kBw@mail.gmail.com>
To: IETF <ietf@ietf.org>
In-Reply-To: <CA+9kkMB44JYj-hkp_O72f2yg-OtBuyqN=NC3aW2PBvh7ZO-kBw@mail.gmail.com>
X-Mailer: Apple Mail (2.1822)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
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 00:07:17 -0000
No: this is what the sort of statement get *me* an epic beat down: Why do this sort of thing here when you can do it in 3GPP? ETSI has membership, voting, and the whole mobile and telco crowd. If I cannot tell the difference between IETF and 3GPP and 3GPP procedures, it is time to go home. On Dec 1, 2013, at 12:01 PM, Ted Hardie <ted.ietf@gmail.com> wrote: > On Sat, Nov 30, 2013 at 7:54 AM, Melinda Shore <melinda.shore@gmail.com> wrote: > On 11/30/13 4:45 AM, Roger Jørgensen wrote: > > And if the problem is that bad, that it's impossible to reach > > consensus in the WG, what about replacing the chairs? ... > > Not for failure to gain consensus, by any means. "No consensus, > do nothing" is a legitimate (if frustrating) outcome. I think > they showed really questionable judgment in calling for a vote > and laying out eligibility criteria, and for me that's a huge issue > (congratulations, guys - just like that you changed us into a > member organization) but failure to gain consensus is a valid > outcome. > > > For what it's worth, all the chairs agree that failure to get consensus is a valid outcome and it may be where we end up. The internal discussion among the chairs and RAI ADs was extremely extensive and not at all fun; think soul-searching, beating of breasts, tearing of sack cloth, and wearing of ashes. Trust us that we did not do this lightly; as one of us put it in the internal discussion: "We're going to get an epic beat down for this". > > So why did we put ourselves forward for that? Because we're charged as WG to make the WebRTC ecosystem as complete and strong as we can. if we don't have a decision on this issue, we're creating a standard that will be hobbled out of the gate. Its baseline negotiation mechanism means it has some freedom of movement, and it may eventually get up a good speed. But this hurts it in ways that it is very hard for us to ignore. We'd be going out with a large likelihood of isolated WebRTC communities, especially in mobile apps, instead of a unified ecosystem. Balancing that pain against this is not easy. > > We would have preferred to get consensus; we would have preferred over this to get an RFC 3929 decision. And at no time did we propose imposing voting unilateraly. We have sought the consensus of the working group on it, to see if this works as a last ditch effort to see if there is *any* way forward. > > So, three ex-ADs and two current ones agreed to go this far out on a limb to get some way forward. It was sufficiently important for us to put this out, _knowing we'd get an epic beat down for it_. That's how much this decision means. > > There may not be any way forward, and we'll accept that if that is the result of this discussion. I personally continue to hope that this set of exchanges will raise awareness among working group participants of the importance of pushing to a common standard here, and that we may see some common ground emerge. > > regards, > > Ted Hardie > > > > Melinda > >
- Re: Alternative decision process in RTCWeb Jari Arkko
- Alternative decision process in RTCWeb Gonzalo Camarillo
- Re: Alternative decision process in RTCWeb Eliot Lear
- Re: Alternative decision process in RTCWeb Dave Cridland
- Re: Alternative decision process in RTCWeb Eric Burger
- Re: Alternative decision process in RTCWeb Dave Cridland
- A few thoughts on processes WAS (Re: Alternative … Gonzalo Camarillo
- Re: Alternative decision process in RTCWeb Eric Burger
- Re: Alternative decision process in RTCWeb Eliot Lear
- Re: Alternative decision process in RTCWeb Dave Cridland
- Re: Alternative decision process in RTCWeb Dave Crocker
- Re: Alternative decision process in RTCWeb Eric Rescorla
- Re: Alternative decision process in RTCWeb Dave Cridland
- Re: Alternative decision process in RTCWeb Ted Lemon
- Re: Alternative decision process in RTCWeb Sam Hartman
- Re: Alternative decision process in RTCWeb Eric Rescorla
- Re: Alternative decision process in RTCWeb Dave Crocker
- Re: Alternative decision process in RTCWeb Cullen Jennings
- Re: Alternative decision process in RTCWeb Dave Cridland
- Re: Alternative decision process in RTCWeb Ted Lemon
- Re: Alternative decision process in RTCWeb Melinda Shore
- Re: Alternative decision process in RTCWeb Tim Bray
- Re: Alternative decision process in RTCWeb Yoav Nir
- Re: Alternative decision process in RTCWeb Michael Richardson
- Re: Alternative decision process in RTCWeb Ted Lemon
- RE: [rtcweb] Alternative decision process in RTCW… Bernard Aboba
- Re: Alternative decision process in RTCWeb Phillip Hallam-Baker
- Re: Alternative decision process in RTCWeb Phillip Hallam-Baker
- Re: Alternative decision process in RTCWeb Carsten Bormann
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… Roberto Peon
- Re: Alternative decision process in RTCWeb Dave Cridland
- Re: Alternative decision process in RTCWeb Stephan Wenger
- Re: Alternative decision process in RTCWeb Roger Jørgensen
- Re: Alternative decision process in RTCWeb Harald Alvestrand
- Re: Alternative decision process in RTCWeb Dave Crocker
- Re: Alternative decision process in RTCWeb Joel M. Halpern
- Re: Alternative decision process in RTCWeb Bjoern Hoehrmann
- Re: Alternative decision process in RTCWeb Melinda Shore
- Re: Alternative decision process in RTCWeb Eric Burger
- Re: Alternative decision process in RTCWeb Ofer Inbar
- Re: Alternative decision process in RTCWeb Phillip Hallam-Baker
- Re: Alternative decision process in RTCWeb cb.list6
- Re: Alternative decision process in RTCWeb Ted Hardie
- Re: Alternative decision process in RTCWeb Melinda Shore
- Re: Alternative decision process in RTCWeb Scott O. Bradner
- Re: Alternative decision process in RTCWeb Eric Burger
- Re: Alternative decision process in RTCWeb Paul Hoffman
- Re: Alternative decision process in RTCWeb Ted Hardie
- Re: Alternative decision process in RTCWeb Avri Doria
- RE: [rtcweb] Alternative decision process in RTCW… DRAGE, Keith (Keith)
- Re: [rtcweb] Alternative decision process in RTCW… Mary Barnes
- Re: Alternative decision process in RTCWeb Cullen Jennings (fluffy)
- Re: [rtcweb] Alternative decision process in RTCW… Ron
- Re: Alternative decision process in RTCWeb cb.list6
- Daughter of CODEC (was Re: Alternative decision p… Eric Burger
- Re: Daughter of CODEC (was Re: Alternative decisi… cb.list6
- Re: Daughter of CODEC (was Re: Alternative decisi… Mary Barnes
- Re: Alternative decision process in RTCWeb Carsten Bormann
- Re: Alternative decision process in RTCWeb Dave Crocker
- Re: Daughter of CODEC (was Re: Alternative decisi… Phillip Hallam-Baker
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Phillip Hallam-Baker
- Re: Alternative decision process in RTCWeb Pete Resnick
- Re: Alternative decision process in RTCWeb Phillip Hallam-Baker
- Re: Alternative decision process in RTCWeb Jari Arkko
- Re: [rtcweb] Alternative decision process in RTCW… Dave Crocker
- Re: Daughter of CODEC (was Re: Alternative decisi… Eric Burger
- Re: Alternative decision process in RTCWeb Sam Hartman
- Re: [rtcweb] Alternative decision process in RTCW… Sam Hartman
- Re: [rtcweb] Alternative decision process in RTCW… Bjoern Hoehrmann
- Re: [rtcweb] Alternative decision process in RTCW… Martin Thomson
- Re: Alternative decision process in RTCWeb Ofer Inbar
- Re: [rtcweb] Alternative decision process in RTCW… Stephan Wenger
- Re: [rtcweb] Alternative decision process in RTCW… Phillip Hallam-Baker
- Re: [rtcweb] Alternative decision process in RTCW… Harald Alvestrand
- Re: [rtcweb] Alternative decision process in RTCW… Ted Lemon
- Re: [rtcweb] Alternative decision process in RTCW… Eric Burger
- Re: [rtcweb] Alternative decision process in RTCW… Jim Gettys
- 0, 1, or many standards and their impact (or not) Eliot Lear
- Re: [rtcweb] Alternative decision process in RTCW… Hector Santos
- Re: 0, 1, or many standards and their impact (or … Phillip Hallam-Baker
- Re: [rtcweb] Alternative decision process in RTCW… Phillip Hallam-Baker
- Re: Daughter of CODEC (was Re: Alternative decisi… Peter Saint-Andre
- Re: [rtcweb] Alternative decision process in RTCW… Jari Arkko
- Re: Daughter of CODEC (was Re: Alternative decisi… Gonzalo Camarillo
- Re: [rtcweb] Alternative decision process in RTCW… Eric Burger
- Re: Daughter of CODEC (was Re: Alternative decisi… Richard Barnes
- Re: [rtcweb] Alternative decision process in RTCW… Phillip Hallam-Baker
- Re: [rtcweb] Alternative decision process in RTCW… David Singer
- Re: Daughter of CODEC (was Re: Alternative decisi… Cullen Jennings (fluffy)
- Re: A few thoughts on processes WAS (Re: Alternat… Eliot Lear
- Re: A few thoughts on processes WAS (Re: Alternat… Harald Alvestrand
- Re: A few thoughts on processes WAS (Re: Alternat… Dave Crocker
- Re: A few thoughts on processes WAS (Re: Alternat… Gonzalo Camarillo
- Re: A few thoughts on processes WAS (Re: Alternat… Spencer Dawkins at IETF
- Re: Daughter of CODEC (was Re: Alternative decisi… Timothy B. Terriberry