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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 11 March 2020 00:28 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 CF5813A0A10; Tue, 10 Mar 2020 17:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 iGR_9NwpwLg5; Tue, 10 Mar 2020 17:28:15 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 54CAD3A09AA; Tue, 10 Mar 2020 17:28:15 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id x22so182460lff.5; Tue, 10 Mar 2020 17:28:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H4/wsGA+Ehu/9WPEZarePws2ILcBRjolW0XMvubjqlI=; b=PiEVb5Qf1YAaN6owZi8VKVySDKF0DieM0h1ICCLg9gYee8DtC0U4Zi+WeOvwbgZfp+ gfYxxayBd6GZi3rc48ITpERcnYzwYbPjBGOzed4gjN9KYGkIDmdMywpkE5Llu4aTHhdJ ky8G4aUafka4+C60Wi8IzAiNPsB0aBCUHu6mRACk+J+Rq5ZvFBboqgl7DACpXPAdazEc uaU70xLlUcEdE/MuSE16Rb1tPmpjcLe8CrQCUWa2BtxhR5dfdoCOJG3RR+9uz0AcEiAG Fmy48OIbN+ZyDuZKYdtYTtnXv48nY/m4taP+hnkbGwBpaJBfzvAuET/9mM8D+0pm06iv LTNA==
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=H4/wsGA+Ehu/9WPEZarePws2ILcBRjolW0XMvubjqlI=; b=Q+HVDnoMJ6b5ELTX/wWeL+ag4dnR2eryBVYgZft0mS9BnrqHt8OfFvq+2JTkzWTuV1 uvsay3J/d+3t9UxNS7J2a2t3SDKuh/EQj7qUDBd276v62IIa8IKbZoH5lLnLcLUaPNYD NCefF+UnNbzYw6iUc6vnLIKBCVF7D5UERMuoa/RHTVV8y1BcIs2Vh6YFnGtvXv0NerwS OVWxScNtbfNXXtxPqaoiTKPE0OIFbzhriGHc+Il2D+YgqMczLJvGu7kicSLbljI7+k5q aQJG0bnWwVaqwi0SFbqD6QF8IOUdn3B8+pQp9CqxF9+kO7rFGcllabgoA5BaO8xZQ+P9 7DOg==
X-Gm-Message-State: ANhLgQ2nbgeEsCKsQAz8GKFJrcyNN1ZLirBsPfrMEuSNfydrfnVbulGN Vqz8YKqOQZUsDuJ6yoJVrysxC2TedtrITzsAs74=
X-Google-Smtp-Source: ADFU+vv3HYwSLKp/rfE+ajHpU76d9mZoI04CTdqKKjE/qGfw8rf+4odbtYW7qth9JMqY0YxuK6lmKRj0Y8O0hZb54CY=
X-Received: by 2002:ac2:5222:: with SMTP id i2mr366302lfl.81.1583886493407; Tue, 10 Mar 2020 17:28:13 -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> <20200310184518.GY18021@localhost> <604af73d-98a6-5188-79a1-4aa4d4e1d581@gmail.com> <20200310235523.GA18021@localhost>
In-Reply-To: <20200310235523.GA18021@localhost>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 10 Mar 2020 19:27:47 -0500
Message-ID: <CAKKJt-cMo-=pDQNkqGURuUwzpkUPw9t-G1yNR=O4nivjt01AhQ@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Alex Bogdanov <bogdanov=40google.com@dmarc.ietf.org>, SPRING WG List <spring@ietf.org>, IETF <ietf@ietf.org>, Pete Resnick <resnick@episteme.net>
Content-Type: multipart/alternative; boundary="000000000000cddd1505a0894f16"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/sCvCh2TYdVH-njptSRAcpoDikuI>
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: Wed, 11 Mar 2020 00:28:18 -0000

All you have to do is ask :-)

That's the awesome part about appeal transparency.

On Tue, Mar 10, 2020 at 6:56 PM Nico Williams <nico@cryptonector.com> wrote:

> On Wed, Mar 11, 2020 at 10:54:36AM +1300, Brian E Carpenter wrote:
> > On 11-Mar-20 07:45, Nico Williams wrote:
> > > 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.
>
> It is a bias in the process.  And rightfully so IMO.  The point is that
> to get relief requires sufficient motivation to seek it via an appeal.
>
> Q: How many appeals have there been, and how many have succeeded?
>

This isn't as readable as it was before the website redesign (IMO), but
https://www.ietf.org/standards/process/appeals/ lists the appeals to the
IESG and the IESG response. I'd note that "succeeded" isn't binary - there
are multiple responses that aren't thumbs up/thumbs down - but everybody
knows what happened.

The appeals that make it to the IAB are at https://www.iab.org/appeals/.
I'd note that the IAB tends to say "the IESG didn't think about X, so they
should try again", rather than "what the IESG should have done was Y". But,
again, everybody knows what happened.

I hope that's helpful.

Best,

Spencer


> But perhaps we can do post-mortems as a lighter-weight relief process,
> where a reversal isn't the goal, but that a) it be determined if there
> were errors (or perhaps harassment by the people complaining! it goes
> both ways) and b) some chastisement.
>
> > > 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.
>
> But there is a social dynamic.  Appeal and become the bad guy, lose good
> will, lose friends, and find your future participation affected.  We're
> talking about people who must have their RFCs published!
>
> > I'll stop there because I have precisely zero knowledge of the case
> > you cite.
>
> That's fair, and it would be best if we didn't discuss it in this thread
> anyways -- its details are not germane, but that such a case exists in
> the broad strokes I used to describe it, is germane to the point that
> the process of obtaining relief is costly and non-trivial.
>
> I'd settle for not having that happen again than for getting a do-over
> with an appeal.
>
> Nico
> --
>
>