Re: Alternative decision process in RTCWeb

Eric Rescorla <ekr@rtfm.com> Thu, 28 November 2013 14:57 UTC

Return-Path: <ekr@rtfm.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 6A14A1AE046 for <ietf@ietfa.amsl.com>; Thu, 28 Nov 2013 06:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 Tw5z-NlDGt1q for <ietf@ietfa.amsl.com>; Thu, 28 Nov 2013 06:57:52 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by ietfa.amsl.com (Postfix) with ESMTP id 07D371AE031 for <ietf@ietf.org>; Thu, 28 Nov 2013 06:57:51 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id q58so8195167wes.19 for <ietf@ietf.org>; Thu, 28 Nov 2013 06:57:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XJZAnCfnCQcGxfC7DVRoGIMCXx8GroZNlHS22o0kFOk=; b=ILdHWq46Mzx4A6CwS0IwkMbcudwluRi2YF1gw2ZtBTzWWz9HVk976GfDN/DZYOCeGP RLN3UNQF6Vz5BHcUay88dJdeQNkSyrjY2W3ovSFXgYK+K5R+Sr80zDXV3dRy5wWH8e8f 1XB8Cyf/Y/Sj4+qmLNDoEQBuVddmEVQiP5SxlPy90iiz0AMZ+tURsbBCUUWPovZEKUSS zAMpDcYO3Acwy9uw3SrQXqgStRp+Mtvx397PyRFpkVBIFW+DvtzXqFGPzzb6ahzse9NB vpcTNoqPt1ospvSjRXEKSmsCqsYa4zsXW+ZRArTvrU71T93RUOp10KnoTe+W7ZWuvL8H rt2Q==
X-Gm-Message-State: ALoCoQm/ICi6ZuUk+eK4mG4qQlD4AFeGuTf/3sYzfmdcsIwxh8NNmuWaPqcM87OyHMRYJGIVnBVt
X-Received: by 10.180.24.137 with SMTP id u9mr2856304wif.5.1385650670608; Thu, 28 Nov 2013 06:57:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 28 Nov 2013 06:57:10 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <529755F6.4050404@dcrocker.net>
References: <52970A36.5010503@ericsson.com> <529719D7.9020109@cisco.com> <CAKHUCzxjwMXzy6=9WdRPRRCunKsLm9JFuo6JavMtEC7Tbov8TQ@mail.gmail.com> <529755F6.4050404@dcrocker.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 28 Nov 2013 06:57:10 -0800
Message-ID: <CABcZeBON3EFrJjRctpeswvWw5s_o2zdOhVATk-YHXpieZUyibw@mail.gmail.com>
Subject: Re: Alternative decision process in RTCWeb
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: IETF Discussion <ietf@ietf.org>, "rtcweb-chairs@tools.ietf.org" <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 14:57:53 -0000

On Thu, Nov 28, 2013 at 6:40 AM, Dave Crocker <dhc@dcrocker.net> wrote:
> On 11/28/2013 3:18 AM, Dave Cridland wrote:
>>
>> I think that two consensus calls should be taken at this stage:
>
>
> I concur with the precedence concerns that have already been raised, and
> also wonder about trying to orchestrate a sequence of consensus calls
> designed to move the group through a process that will get some folk to
> change their positions, in order to get the matter resolved.
>
> The simplest form of such a sequence that I've heard about is to note the
> impasse, then ask whether the group does want to get the matter resolve.
> That's likely to get a strong rough consensus yes.  Then note it's not going
> to resolve until folk change their current positions. The example I heard
> about did then produce a preferred choice.
>
> No doubt, the current situation has folk who are more tenacious, so perhaps
> the sequence of calls needs to be a bit more elaborate.
>
> BTW, as distasteful as it might be, is there a reason that making /both/ MTI
> would not work?

It's one of the proposed choices. However, it's important to understand that in
in this case, many people more don't want X than do want Y.

-Ekr