Re: Alternative decision process in RTCWeb

"Scott O. Bradner" <sob@sobco.com> Sun, 01 December 2013 23:43 UTC

Return-Path: <sob@sobco.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 7090C1AE211 for <ietf@ietfa.amsl.com>; Sun, 1 Dec 2013 15:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level:
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] 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 0tDILTasxWAc for <ietf@ietfa.amsl.com>; Sun, 1 Dec 2013 15:43:33 -0800 (PST)
Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id B85CB1AE1F9 for <ietf@ietf.org>; Sun, 1 Dec 2013 15:43:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 067B847598F; Sun, 1 Dec 2013 18:43:21 -0500 (EST)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-C0hxL7qEVr; Sun, 1 Dec 2013 18:43:19 -0500 (EST)
Received: from [10.0.1.11] (173-166-5-69-newengland.hfc.comcastbusiness.net [173.166.5.69]) by sobco.sobco.com (Postfix) with ESMTPSA id E3C1E47597F; Sun, 1 Dec 2013 18:43:19 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: Alternative decision process in RTCWeb
From: "Scott O. Bradner" <sob@sobco.com>
In-Reply-To: <tsl4n6wk09e.fsf@mit.edu>
Date: Sun, 01 Dec 2013 18:43:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <48016D6E-6B76-4DC9-A6AD-6F9FCE8BAF0E@sobco.com>
References: <52970A36.5010503@ericsson.com> <tsl4n6wk09e.fsf@mit.edu>
To: IETF Discussion <ietf@ietf.org>
X-Mailer: Apple Mail (2.1822)
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: Sun, 01 Dec 2013 23:43:35 -0000

+1

i.e., maybe N=0 in this case

changing the basic genetics of the IETF is not warranted in this case (imo)

in the past (e.g., multicast routing) we formed two WGs and the problem worded itself out 
(one WG produced a result)

Scott


On Nov 28, 2013, at 10:35 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:

>>>>>> "Gonzalo" == Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> writes:
> 
> 
> Hi.  I've thought about the general issue of alternative decision making
> a lot, and it did come up a number of times while I was an AD, although
> none with such significant stakeholder interest as this.
> 
> The issue I'm most concerned about is confirming that there is rough
> consensus to make a decision.  I think any variance from rough consensus
> for decision making must itself meet a fairly high consensus bar.
> 
> "But we can't make a decision; we have to make a decision, so of course
> we're going to do something alternative," you might say.
> 
> You don't have to make a decision though.  You can decide the IETF is
> not the right forum for your decision.  You can decide not to
> standardize.  You can decide to run experiments, get  data, try to
> implement.  You can give up.
> You can redefine the problem.  You can for example decide to have two
> mandatory-to-implement options, or require receivers to implement both
> and not mandate which senders must pick.
> 
> In many cases it does turn out to be easier to get consensus that a
> decision must be made than it is to get consensus on a decision.
> However without chairs being able to clearly show that consensus to
> decide has been reached I'd expect an appeal and expect that appeal to
> be successful.
> 
> Next, it's strongly desirable to get consensus on your process for
> making the decision.
> If you can get that, or lacking that, get consensus  on someone who will
> decide the process (chairs or AD), I think you are coming along
> reasonably.
> 
> Obviously concerns of fairness are important.  A process that inherently
> advantaged one company or viewpoint would be suspect.
> 
> I'd personally favor coin-flips, external arbitors or similar over
> voting.  We don't want to encourage voting because we could get into
> situations where people block the consensus process in order to force a
> vote.  Absent things like well-defined membership and procedures to
> avoid one company stuffing the ballot box, going there seems
> problematic.
> 
> Coin flips are nice.  They really create pressure among anyone who
> actually cares about the outcome to compromise, to explore whether a
> consensus can be built.  However for the frequent situations where a
> decision is critical but it really doesn't matter (even if some people
> think it does), they get the job done.