Re: [Last-Call] Last Call: BCP 83 PR-Action Against Dan Harkins

John C Klensin <john-ietf@jck.com> Sun, 02 October 2022 21:16 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD21C14F727 for <last-call@ietfa.amsl.com>; Sun, 2 Oct 2022 14:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwaI_yVfzm_l for <last-call@ietfa.amsl.com>; Sun, 2 Oct 2022 14:16:30 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093E6C14F726 for <last-call@ietf.org>; Sun, 2 Oct 2022 14:16:29 -0700 (PDT)
Received: from localhost ([::1] helo=JcK-HP5) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1of6K3-0005UX-2c; Sun, 02 Oct 2022 17:16:27 -0400
Date: Sun, 02 Oct 2022 17:16:26 -0400
From: John C Klensin <john-ietf@jck.com>
To: Eric Rescorla <ekr@rtfm.com>
cc: last-call@ietf.org
Message-ID: <FBC8B5757D2293091FEE6776@JcK-HP5>
In-Reply-To: <CABcZeBOgNvKQJhmjFbgYe92N2qaysAUYb1Td0eRapO=LjFGCBg@mail.gmail.com>
References: <CFE25E25-D131-468E-9923-80350D6216F3@ietf.org> <CABcZeBPwt+YSizRkkO7JuHbZkQeuQsszB7RW2S6Kr2PTv206cA@mail.gmail.com> <3D4F4763DD0EBFB47798FA1E@JcK-HP5> <CABcZeBOgNvKQJhmjFbgYe92N2qaysAUYb1Td0eRapO=LjFGCBg@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/qzy-Z7FXhZjACn3rug9BhtimM7M>
Subject: Re: [Last-Call] Last Call: BCP 83 PR-Action Against Dan Harkins
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Oct 2022 21:16:34 -0000


--On Sunday, 02 October, 2022 11:14 -0700 Eric Rescorla
<ekr@rtfm.com> wrote:

> On Sun, Oct 2, 2022 at 11:03 AM John C Klensin
> <john-ietf@jck.com> wrote:
> 
>> 
>> 
>> --On Sunday, 02 October, 2022 10:33 -0700 Eric Rescorla
>> <ekr@rtfm.com> wrote:
>> 
>> > ...
>> > In particular, my experience is that it's far earlier to
>> > address misbehavior early on with smaller interventions than
>> > to wait until there is a long pattern of misbehavior and
>> > then ban
>> > someone. Nominally, we do have such mechanisms (SAA, etc.)
>> > but, they have proven so difficult to apply that the
>> > nominally last resort of the PR Action instead becomes in
>> > practice the only resort in practice.
>> 
>> Based on observations in recent months, I have somewhat more
>> confidence in the SAA mechanism than you do although I would
>> have agreed with you a couple of years ago,   As I said
>> earlier today, I'm concerned about their perceptions of what
>> they can or should do when the smaller and more private
>> interventions (even publicly suspending someone from a
>> particular list for a short time) fail, but a small bit of
>> tuning would fix that.
>> 
>> Situations in which all of the discretion --about whether to
>> act and how-- is vested in a single WG chair or list
>> maintainer without obligations to consult, e.g., either a
>> co-chair or AD, may be another matter.   Without criticizing
>> anyone, I tend to not trust any one person's judgment
>> (including my own) in isolation or without consultation,
>> especially if they perceive themselves as being abused.
>> 
> 
> Do you have some mechanisms in mind or are you merely speaking
> in the abstract?
> 
> For instance, RFC 3934 explicitly requires the approval of the
> AD for posting rights removal,
> even for 30 days. Moreover, such a decision is appealable.
> 
> https://www.rfc-editor.org/rfc/rfc3934#section-2

More in the abstract.  The existing mechanisms, including that
one, should, if everyone does their jobs, considers the various
balances carefully, and is extra-careful when the circumstances
might lead to claims of bias, be adequate (or better).  And, of
course, the appeal mechanism (which, unlike recalls, which I
think came up elsewhere, in this thread, are an appropriate and,
IMO, effective remedy when those involved get things wrong or
even just don't pay sufficient attention.

   john