Re: [spring] Dispute process (Was: Resignation request)

Warren Kumari <warren@kumari.net> Tue, 10 March 2020 17:56 UTC

Return-Path: <warren@kumari.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BB83A0443 for <spring@ietfa.amsl.com>; Tue, 10 Mar 2020 10:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=kumari-net.20150623.gappssmtp.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 Uq1fPacqfIYf for <spring@ietfa.amsl.com>; Tue, 10 Mar 2020 10:56:30 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 6883B3A0440 for <spring@ietf.org>; Tue, 10 Mar 2020 10:56:30 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id q9so5009230lfc.10 for <spring@ietf.org>; Tue, 10 Mar 2020 10:56:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BhLPTeCmLWbjpkbkthe55/vgv34tLrQ/txEPsRiXA48=; b=KNacb+ZXfCwupECdx/Q9yIU1K9LVA6La1ULuRD+XqUi4eR2x9yE+1SVfO/5BpQAOTq CgMejKU0ce0/DxAi57Le+1/h4JZukUXRcxfKEU2WOmVYaSsyqRyVeZpWCkGLcQp7xQoo zL7oGjhSXJnvg6twkfj+2QamBt4eLBsL0tM0P03ES0UAL/eAXerMmF7+iCraAhNWWgQD jXUkEcCtPXh5SuXSz+ENMuWPR0++8iMEK+7U1fY13HSEPmPgA682tgM+lvqyMFc2j+B6 xbqskB/lnb9eS08cXGMts3p7tn7XqVD7P7tzCYlOjDY69KlmxAtA5RPLVYr9i6OxP4rm S/AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BhLPTeCmLWbjpkbkthe55/vgv34tLrQ/txEPsRiXA48=; b=I2aJXs3vWw3AJBWTgptfr+IHaNXc4U1d298L/9X3707rbdupN0z7J2X/z9LSjn45TX +QqXGhnVAzxDoR1Dxjv+GF51unxdrHTD1KlJZ6mzJNfSOxoe6tKrioWuokCd893lItsN QJidFEs4aFj695YBTs1TbUmDQSbtOJBHcQ5a84xmiAWQvdeve4hgcF3oV25BxaUx1JHG JSTEtxmlzT1gFnsRTQpgzBBDC0s2DrO9p8aBw0ISpN+cT/j2PbWlej8Myj3nFLBvIlt6 zWPy+pm0Ti8XLcV73O5dQ1eU8JF8cMgN9ACuXAfGA57WCBlpB+TpbZYBEjW34EcDyrbt DUWQ==
X-Gm-Message-State: ANhLgQ06QLjqthzTQErmjIMjaz0VdlRHxV9NuOVIMcs+2kQ62o1MJdub bN7soW780f9vgiVC3xNCDefwGfYMYo0o4pj8W6JbWIsWVCc=
X-Google-Smtp-Source: ADFU+vtPpOybWBUOxNfWVjYxUqtn7OFZr8Q1f7rxDy/uYhzbWX3stFH9+wEtBLbNNMlNSn24+o0DbPopwM6EbAGkMVM=
X-Received: by 2002:a05:6512:305:: with SMTP id t5mr12183012lfp.104.1583862987671; Tue, 10 Mar 2020 10:56:27 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <EF46D631-4553-4378-9260-6E23BE94B14E@episteme.net>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 10 Mar 2020 13:55:50 -0400
Message-ID: <CAHw9_iLpVkzDuaaKsVy70w-B2+tYUJ9mW0Me76s+57NGa_fr5g@mail.gmail.com>
To: Pete Resnick <resnick@episteme.net>
Cc: Nico Williams <nico@cryptonector.com>, Alex Bogdanov <bogdanov=40google.com@dmarc.ietf.org>, IETF <ietf@ietf.org>, SPRING WG List <spring@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/jTkKGc5QXPEfR4StbpS_ok_afu4>
Subject: Re: [spring] Dispute process (Was: Resignation request)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2020 17:56:33 -0000

On Tue, Mar 10, 2020 at 1:13 PM Pete Resnick <resnick@episteme.net> 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?
>
> 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? (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?
>
> I have no doubt that this process is under-used (as a chair and an AD, I
> had 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 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.

+1.

I realize that +1 is largely content free, but I believe that appeals
and recalls are an incredibly important part of the IETF process -
they are the reason that we can have a process which uses rough
consensus (not voting), and where our process has the flexibility to
(as Spencer would say) "Do the right thing!", and not blindly follow
checklists. In order for these to work, people need to be able, and
comfortable invoking appeals and recalls[0]...

W
[0]: In my copious free time, I still want to organize an exercise
where we fully exercise the recall process - have a pretend AD who
does something outrageous, and then work the entire process (with some
optimizations to not waste everyone's time!)  to fully make sure there
are not any hidden gotcha's. We have worked most of it, and have
thought about it in table-tops, etc - but I'd hate to discover a
hidden issue right when it is most contentions and needed....

>
> pr
> --
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf