Re: Dispute process (Was: Resignation request)

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 10 March 2020 21:54 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D4E3A0E90; Tue, 10 Mar 2020 14:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 R8mDFahapnbX; Tue, 10 Mar 2020 14:54:41 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A293A3A0EEF; Tue, 10 Mar 2020 14:54:41 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id ay11so76075plb.0; Tue, 10 Mar 2020 14:54:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wzvmVl7QFA878vtmM+u/NJ9uTtcO6dq5Y/hGbKuvQgQ=; b=JqOg8DyiqQQnDwDsG1NXDp0x/TpuUY5PzgsEGbOdn0vR1573wyHAvVQMwAWH7zn+nB ZVnsknL8pPpsUSYEM+SmAbXKMnyXKoPe938AZv0maOAxyhQXN85BreOq1/K3jc/PQ+ph ubGfCXZgnAaufccDRD0X1U1uFGE6Wp4Jbn+5l3vLcvjsLXoIS6OYMUtptS4V75j1OTp9 A2eYK64e/yL2eK6JL6Xm+hmC9QpOkCmRd9DPNf4apGA96i+seDSCwuAcLEV9CgEsgl0w w8vDuPJY+dQleVqZWogg0z2ZKNbQxdGg8jNOqi+svVVcl6gChq4lO93mITlx4Fkw2ssL ImTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wzvmVl7QFA878vtmM+u/NJ9uTtcO6dq5Y/hGbKuvQgQ=; b=G7Dpl8qmCFKYkn8gSOR8sJRCTrNmBdnCf9yH2w0ZRwIBhieslWL7NvR/jcnPtRBUnP G3/SMIxjyybdwFfV7n6QOuFBkNQSAKRu6IRblcwKoK15EhD8OasmNTBSDUcN2sI2MiYm FSxbJc5FIyTGKAkN44j+qNeJfGqTr3ReGEVDMl/3kWcc4rmF/fqeGZplY8u0mkaztZb9 FSr6Y/wsU96JaP8OwByK3qEl2oVa0p1CNe0p8TXh19N3+cGCy9lnL/EDXT50KDryI//o Qei3mtIz1Rq38XBJ2crqmu14IxLgePV7H2xvBV0GlEnL3tD0p5Un9PpV/TBoKW8j5WK9 yI2g==
X-Gm-Message-State: ANhLgQ3jVAO5sx0Wo8rWvdxTmU1Erl+8Dbu+zjKwJMcPN3/2zkK3je5l Z4iFA7oJAsvkwqWv+IEkq6UxKUgj
X-Google-Smtp-Source: ADFU+vtC6lrZnZETblZbHwGypa4ttEYjqKJG8Ate9/eqbBDTd46qtSgs6udGYugV6oryJpDwG+6c2Q==
X-Received: by 2002:a17:902:aa4a:: with SMTP id c10mr8987plr.183.1583877280706; Tue, 10 Mar 2020 14:54:40 -0700 (PDT)
Received: from [130.216.37.131] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.37.131]) by smtp.gmail.com with ESMTPSA id 19sm27227379pfn.30.2020.03.10.14.54.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2020 14:54:40 -0700 (PDT)
Subject: Re: Dispute process (Was: Resignation request)
To: Nico Williams <nico@cryptonector.com>, Pete Resnick <resnick@episteme.net>
Cc: Alex Bogdanov <bogdanov=40google.com@dmarc.ietf.org>, IETF <ietf@ietf.org>, SPRING WG List <spring@ietf.org>
References: <3EF6505C-D442-41A4-A681-26ACF818BB4D@sobco.com> <C7B7787A-48E5-407F-9E81-BDEC2F1B2169@steffann.nl> <6651697D-A892-4CAB-BDC1-E385750294D3@gmail.com> <a708fc17-c799-2767-4a35-033b063456f5@pi.nu> <CA+q+MpU6-36xTzZL_-B-9fG8atfOiOF5-rdxFFVQV9_y8GOd8Q@mail.gmail.com> <20200310154115.GX18021@localhost> <EF46D631-4553-4378-9260-6E23BE94B14E@episteme.net> <20200310184518.GY18021@localhost>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <604af73d-98a6-5188-79a1-4aa4d4e1d581@gmail.com>
Date: Wed, 11 Mar 2020 10:54:36 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20200310184518.GY18021@localhost>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/t0ZXbPTBJKNrBW08qWfowhRpRH4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 10 Mar 2020 21:54:51 -0000

Nico,
On 11-Mar-20 07:45, Nico Williams wrote:
> On Tue, Mar 10, 2020 at 12:11:47PM -0500, Pete Resnick wrote:
>> On 10 Mar 2020, at 10:41, Nico Williams wrote:
>>
>>> ...the process we have for
>>> dealing with complaints is heavily biased against plaintiffs -- which is
>>> probably as it should be, as otherwise we might never get anything done,
>>> but then legitimate complaints don't get heard.  I feel OP's
>>> frustration.
>>
>> Nico, could you (or others) expand on this?
> 
> Yes.  Challenging consensus is difficult.  People with substantive
> commentary sometimes get tanks driven over them.  I've a few stories of
> this.  One fairly recent one involving the TLS WG.
> 
>> I really think this is worthy of a separate discussion: What is it about the
>> current process that you find biased against those who bring up a dispute?
> 
> If you get left on the rough side of consensus, whether rightly or
> wrongly, and you wish to challenge this, it's really difficult.  You
> might have to file an appeal, 

Well yes. There's no way round that - you're on the losing side, which
has been a bad deal throughout human history. But at least there *is*
an appeal process (which in practice there wouldn't be, if we used
majority voting to make decisions). That doesn't indicate bias in
the process.

> and if you do you'll annoy and anger
> people who want their RFCs published a year ago.

Again, that doesn't indicate bias in the process.
 
>> (I take it we're talking about RFC 2026 section 6.5
>> <https://tools.ietf.org/html/rfc2026#section-6.5>.) Have you encountered a
>> bias in undertaking such a dispute?
> 
> What I've encountered is that at the limit you have to appeal or give
> up, and how well things go before you get to that stage depends on how
> willing WG chairs and responsible AD are to actively mediate dispute
> resolution.

Of course. But isn't that exactly why the appeals process exists? To
put pressure on chairs and ADs to mediate? I assure you that it's
much more uncomfortable for them to handle a formal appeal than
to try mediation.

I'll stop there because I have precisely zero knowledge of the case
you cite.

    Brian

> 
> The case I felt went really badly was the TLS DNSSEC extension.  I don't
> want to summarize that here because it will be too easy to accidentally
> or unconsciously mischaracterize some detail and trigger a flame war.
> 
> That case left many palpably angry, including myself.  The resolution of
> that case, BTW, was that the WG decided to drop the work item and let
> each do their own extension via the ISE.  IMO that is less than ideal
> because if it keeps happening then we're going to have a large TLS
> extension support matrix and our users will be sad.
> 
> There's no easy way to challenge a consensus to drop a work item.  What
> are you gonna do, appeal asking the IAB to force a WG to take on a work
> item it doesn't want to?  A WG could even conclude out of spite if
> forced to do something it doesn't want to.
> 
> So there was no question of appeal, really.  But I do feel that the
> chairs and responsible AD did not help enough ahead of the WG throwing
> its hands up in the air -- that might be an incorrect perception though,
> as maybe the chairs and AD were simply unable to get the strongest
> personalities on either side of the dispute to compromise, but, too, I
> think they could have called the consensus rather than wait till the WG
> threw in the towel on the work item.
> 
>> I have no doubt that this process is under-used (as a chair and an AD, I had
> 
> I've reached out to chairs and ADs a number of times before, and that
> has worked, and can work where they're willing to.
> 
> It's difficult to go beyond that to appeals.  We do have to be done at
> some point with any one work item.  There is good will to tend to.
> 
> The OP of this thread's parent thread clearly felt much more strongly
> about their case than anyone did about the TLS DNSSEC extension.  No one
> in the latter case felt so aggrieved as to post a "resignation request".
> 
>> to actively encourage people to use the dispute process instead of just
>> giving up), but I've always assumed that it was just people not wanting to
>> "rock the boat", or not wanting to be seen as a "complainer", or thought
> 
> There is definitely some of that.
> 
> Or at some point a party gets exhausted and gives up.
> 
> Some of this is that we're a somewhat academic bunch (RFCs count as
> papers now, no?) and you know how it is with academics: the lower the
> stakes the worse the infighting.
> 
>> that nobody up the chain would take them seriously. Those are serious
>> problems and we should be figuring out how to address them, since people
>> bringing up failures is the only way we can stop bad things from happening
>> when a WG or someone in leadership gets tunnel vision and does the wrong
>> thing. However, this is the first time I've heard someone express that the
>> process itself is stacked against someone with a dispute. If that's true, we
>> should really talk about how to fix that.
> 
> Not sure how to make it better, except maybe thus: it should be possible
> to get a review of how a dispute was resolved not so much as an appeal,
> but as a way to remediate problems to help alleviate _next_ dispute.
> 
> Nico
>