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

Ted Lemon <mellon@fugue.com> Thu, 27 October 2022 14:22 UTC

Return-Path: <mellon@fugue.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 E286CC15E41A for <last-call@ietfa.amsl.com>; Thu, 27 Oct 2022 07:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
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 wlXAMUyQ2j7y for <last-call@ietfa.amsl.com>; Thu, 27 Oct 2022 07:22:01 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767C7C157B41 for <last-call@ietf.org>; Thu, 27 Oct 2022 07:21:53 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id l28so1204702qtv.4 for <last-call@ietf.org>; Thu, 27 Oct 2022 07:21:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TQd/LRzXBnLmfNX8IC8+kPgj1WAhLHcNXU1A9SKdEIw=; b=387pgPJohlKHJNuuaq8fkti/BxhrKG5U1Wj4ugHARecAmtOtEOf1ICJ5Ot2HU1BkWS vMIShzXby5hrs//msP/P4hnDDmORy1DqPLYXobKXtHR6gMbc4jH9c5VX7eCvmpF7ab+h 99q6T1XdsiYnx+9bjzxTuTpgLEZhcAT4K2WB+Y1U7rPxm4QlfvQEspSKOTE1MUapyeMG srvtEykRo9Toxq4zTwf+vgMofh6Fw4raw5QnLaTRzZTQ/wHPbBYYOTjUJRhkhEjDhEgu UWV/rI0z8zPbqYSMKvjX31bb5GO0QB5sFQoeaaLsBdKNLoBUerdMcOj7+jA9JG2wGgmG DQsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TQd/LRzXBnLmfNX8IC8+kPgj1WAhLHcNXU1A9SKdEIw=; b=ch35Qg8x5BPCwq8d4t7BqQh8PMvPBNBHbrn8ZLAsaUBwjUiMR25mLHtHSXiVIjpUiy EOlaBrIEmrEkp4xFBPuT9M/aXhlP1R7KCreplhEKsdhntjMRw85kUCPNX85JBU2EoPpw 2Usf+nqidEJukj2RhrMvOUZ6A6KiwZuUUW4xt9n5Wbk4ZBcLQZOHZgxcOnGWxMcMw9bU 88HyQMGdqzzMSRFRr1HagVSgFm4MGUM/ACf9GGNsj8eZQTA+M/RPwrjdW6u1uUOM7vE3 dSmHPDDK2tBhLc18tCH1sUxgLC4NZkS46yA3riMJ0hPn66lIPFRcjOMEBT+iQmC+Ma/P gYoQ==
X-Gm-Message-State: ACrzQf32IVzVIDPv4NHF4UuIask1Lco4ax27BtsPKs/JPSbdHAVuNdJ4 n/6UJn8W9QaRctxOfHD/wgkj1THvZ6mrN4WWxT25Fn15cAOfmMUF
X-Google-Smtp-Source: AMsMyM5yB+vSL+RKYtAZOnFri1jx/Iq20NSZ3s6uNh7wF117bnGqTUMmHxPzntmjMx+i6AvRH85uarWGR/OjKUpSScs=
X-Received: by 2002:ac8:7c46:0:b0:39c:fa92:a27a with SMTP id o6-20020ac87c46000000b0039cfa92a27amr39613979qtv.61.1666880512267; Thu, 27 Oct 2022 07:21:52 -0700 (PDT)
MIME-Version: 1.0
References: <CFE25E25-D131-468E-9923-80350D6216F3@ietf.org> <d5f91bf1-4407-8ec5-50ab-a8bdb7327c0f@gmail.com> <ef5c4886-5438-0537-611f-19b7ac54daa4@gmail.com> <CAPt1N1kOCKi=1kdLucU+dxDSdqCGW38U0Du8nDbc2chLdVJVCQ@mail.gmail.com> <E35A397E4DCDAD5D0BA33D9A@PSB>
In-Reply-To: <E35A397E4DCDAD5D0BA33D9A@PSB>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 27 Oct 2022 16:21:41 +0200
Message-ID: <CAPt1N1kjMqZXEs__nL4j5z3hoQMD1b-xGA=NUSkN22AdsK-SAw@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, IETF Chair <chair@ietf.org>, last-call@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d1297b05ec04dc21"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/wfPU54J2l86j2971wx9mjTucVsc>
Subject: Re: [Last-Call] Change of position: 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: Thu, 27 Oct 2022 14:22:05 -0000

John, I don’t filter mail from Dan, so I’ve been watching his postings
here, and it’s clear that he doesn’t actually understand the problem, or
that he just disagrees philosophically that it could be a problem (which by
the way is a perfectly valid position!). And so in fact we have a running
sample indicating that no commitment exists to stop this behavior.

The goal here is not to help Dan. It is to make the community safe. If Dan
lets go of his resistance to doing what that takes, that’s great. But we
should err on the side of protecting the community, rather than bending
over backwards to not inconvenience Dan.

So the test of whether he’s actually committed to changing is not to not
ban him, but to not permaban him. Ban him for a while, then bring him back.
Maybe mod him. See how he does. If there’s a consistent track record,
great, problem solved.

As to whether or not Dan should apologize, if he isn’t willing to do so,
that’s really strong evidence that he isn’t actually willing to make the
requested change in behavior—he doesn’t agree that it’s a problem. Again,
perfectly fine to disagree, but then that means that we have to protect the
community from him. So I see no reason to call apologizing wearing sack
cloth. It’s just what you do when you screw up.

I think the pushback against apologies might just be that we see so many
people transgress, make a mouth-only apology, and then go right back to
transgressing. It’s not unreasonable to be a bit cynical about this, but
reconciliation is actually a well understood process, and we can insist on
it if we want to. And I certainly want us to.

Op do 27 okt. 2022 om 15:58 schreef John C Klensin <john-ietf@jck.com>

> Ted,
>
> I agree with most of what you wrote but still agree with Brian's
> conclusion, at least up to the point just short of what you
> characterize as "declare victory".  Let me try another take on
> this, based partly on your analysis and "at step one" comment.
> As I see it, Dan has figured out that some of his past comments
> and style were unhelpful to either getting the points he was
> trying to make across or to the community.   He has indicated
> that he will stop.  IMO, those two steps took much too long, but
> I don't see how that should figure into what we do going
> forward.  Your fourth step, paraphrased, requires that he
> demonstrate his understanding and commitment by not
> re-demonstrating the problem for some time.  I think it is
> consistent with what you wrote that we not require that he
> grovel or (with apologizes to those from parts of the world in
> which the metaphor is not familiar) that he appear in London in
> sackcloth and ashes.   I agree with you about both, but, if he
> is forced off mailing lists until he demonstrates that he has
> stopped the problem behavior, he has no opportunity to make that
> demonstration, amounting to a lifetime ban.  Moreover, at least
> from my point of view, it hurts the community by depriving us of
> the widest possible diversity of perspectives on our actual
> technical work.  I've said/agreed from the beginning of this
> discussion that if he (or anyone else) is acting in a way that
> severely disrupts the community's functioning then the
> community's ability to function well must take priority over any
> individual but, if the disruption stops without our suppressing
> what might be valuable input, then we are, indeed, meting out
> punishment, part of it to ourselves.
>
> So a radical suggestion in two parts:
>
>   (1) The community should agree to wind this discussion down
> and to stop it for a while, at least until the level of passion
> abates somewhat.  I have trouble believing that there is much
> more that is useful and new that can be said and, as others have
> pointed out, the discussion itself has been disruptive and
> detrimental to getting substantive work done.  If there is
> consensus for that, no matter how rough, the moderator(s) should
> do their thing and remind people to dial the discussion and
> postings down as appropriate, treating persistence in bringing
> it back up as inappropriate behavior.
>
>  (2) The IESG should take a decision off their agenda for some
> weeks or months.  As the end of that period, if Dan has
> demonstrated to their satisfaction that the troublesome postings
> and behavior have stopped, they retire the PR-action proposal.
> If, in the interim, there is more troublesome behavior, they put
> the issue back on their agenda and, presumably, quickly and
> efficiently reach the obvious conclusion (although I still hope
> the rationale would be cleaned up somewhat).
>
> While BCP 83 does not provide for what amounts to a probationary
> period, it does not prohibit it either.  Because we can
> certainly point to precedents in which the IESG has postponed,
> for very extended periods, making a decision after the Last Call
> has ended, I am not suggesting inventing new process on the fly.
> I think there might be a better way to do the same thing, but
> BCP 83, as I read it, prohibits revisiting a PR-action for at
> least a year, so it would require a process change.
>
> In case it is not clear, I am just trying to dig us (not just
> Dan) out of a hole that could easily turn into what both of us
> are arguing against -- treating this process and outcome as
> punishment, especially punishment for past behavior that has
> stopped -- and, I hope, to wind down this painful discussion for
> at least a while.
>
> best,
>    john
>
>
> --On Thursday, October 27, 2022 12:20 +0200 Ted Lemon
> <mellon@fugue.com> wrote:
>
> > There are quite a few steps in the reconciliation process when
> > someone has engaged in transgressive behavior that needs to be
> > corrected.
> >
> > The first step is getting the person engaging in the behavior
> > to come to understand how to differentiate between
> > transgressive behavior and other behavior.
> >
> > Second, the person needs to want to stop engaging in
> > transgressive behavior.
> >
> > Third, the person needs to actually stop engaging in
> > transgressive behavior.
> >
> > Fourth, the person needs to work to repair the damage they
> > have done by engaging in transgressive behavior in the past.
> > This includes at a minimum, successfully not engaging in
> > further transgressive behavior for some significant period of
> > time, so as to establish that there is an actual behavior
> > change, and not just verbal agreement to change behavior.
> >
> > The point of this is not to punish the person. It is to stop
> > the harm that the person has been doing through their
> > behavior. We don't actually care why the person is behaving
> > this way. We don't need to decide that the person is "a bad
> > person." We just need to identify the behavior, explain why it
> > is a transgression, and what is expected.
> >
> > It is quite common when trying to address problems like this
> > to value the person committing the transgression over the
> > health of the organization, because the person is a person,
> > and the organization is not a person. It's much easier for us
> > to cognize the person as someone whose interests should be
> > protected than it is to cognize the organization in the same
> > way.
> >
> > Nevertheless, if we truly value the organization, we have to
> > prioritize the organization's health over the ability of a
> > particular person to participate in the organization. It is
> > not appropriate to even refer to the person as a bad person.
> > All we care about is the person's behavior. The behavior is
> > the problem that needs to be corrected. The corrective action
> > isn't a punishment. It need not continue longer than
> > necessary, but it must continue for that long.
> >
> > So, to Brian's point, we are now perhaps at stage one in this
> > four stage process. That's great, but it's way too soon to
> > declare victory. I'm a bit disappointed that Brian has decided
> > that we are done when we've only perhaps just started, but
> > he's entitled to his opinion.
> >
> >
> >
> > On Thu, Oct 27, 2022 at 6:26 AM Brian E Carpenter <
> > brian.e.carpenter@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I'd like to change my position on this. In a recent message,
> >> Dan acknowledges that using sarcasm or satire is problematic:
> >>
> >> https://mailarchive.ietf.org/arch/msg/last-call/-8qnygF1ywCc3
> >> nQAWg0jGCEtLdo/ To my mind, given that Dan has been a
> >> significant technical contributor over many years, that is
> >> really all the community can ask for. I don't think the IETF
> >> would gain anything at this point by applying a PR Action,
> >> and would possibly lose future significant technical
> >> contributions.
> >>
> >> Regards
> >>     Brian Carpenter
> >>
> >> On 01-Oct-22 10:06, Brian E Carpenter wrote:
> >> > I've had a filter in place that deletes mail from Dan
> >> > Harkins
> >> automatically
> >> > for some years, so I haven't been disturbed by most of
> >> > their recent
> >> postings.
> >> > But I think that this PR action is fully justified by their
> >> > long record of uncivil and disruptive messages,
> >> >
> >> > Regards
> >> >      Brian Carpenter
> >> >
> >> > On 30-Sep-22 05:15, IETF Chair wrote:
> >> >> Following community feedback after various incidents, as
> >> >> documented
> >> below, the
> >> >> IESG has initiated a posting rights (PR) action that would
> >> >> restrict the
> >> posting
> >> >> rights of Dan Harkins, as per the procedures found in BCP
> >> >> 83 (RFC 3683). Specifically, his posting privileges to
> >> >> these lists would be suspended:
> >> >>
> >> >> * admin-discuss
> >> >> * gendispatch
> >> >> * ietf
> >> >> * terminology
> >> >>
> >> >> In the IESG's opinion, this individual has a history of
> >> >> sending emails
> >> that are
> >> >> inconsistent with the IETF Guidelines for Conduct (RFC
> >> >> 7154) and thereby "disrupt the consensus-driven process"
> >> >> (RFC 3683). Among these are
> >> contributions
> >> >> that:
> >> >>
> >> >> * Express racism in the form of denying, belittling, and
> >> >> ridiculing
> >> anti-racist
> >> >>     sentiment and efforts
> >> >>
> >> >> * Are rude and abusive, and often amount to insulting
> >> >> ridicule
> >> >>
> >> >> (Links to examples of such emails sent to the lists above
> >> >> during the
> >> last two
> >> >> years are provided at the end of this email.)
> >> >>
> >> >> Multiple attempts have been made to enter into a private
> >> >> discussion
> >> with this
> >> >> individual, both by IESG and community members, to
> >> >> communicate disquiet
> >> with his
> >> >> conduct on the lists. These attempts to restore respectful
> >> >> and
> >> courteous conduct
> >> >> on the lists have been rebuffed with communication that
> >> >> can be
> >> considered both
> >> >> antagonistic and hostile, and the pattern of behavior
> >> >> observed has
> >> continued.
> >> >>
> >> >> The IESG also notes that the following actions have
> >> >> already been taken
> >> in
> >> >> response to the individual's actions:
> >> >>
> >> >> * Two I-Ds were removed from the public archive due to
> >> >> their offensive
> >> nature:
> >> >>
> >> https://datatracker.ietf.org/doc/html/draft-les-white-interse
> >> ctional-dots
> >> >>
> >> https://datatracker.ietf.org/doc/html/draft-les-white-tls-pre
> >> ferred-pronouns
> >> >>     (following these links displays the tombstone notice
> >> >>     explaining
> >> their removal)
> >> >>
> >> >> * His posting rights were restricted on the admin-discuss
> >> >> mailing list:
> >> >>
> >> https://mailarchive.ietf.org/arch/msg/admin-discuss/ZANH2VPN-
> >> U8VMvvOWLb5l03FdCs/
> >> >>
> >> >> * A final public warning was issued on the gendispatch
> >> >> mailing list:
> >> >>
> >> https://mailarchive.ietf.org/arch/msg/gendispatch/68a4amMa1ai
> >> aRUPzPGgXdiY9gHg/
> >> >>
> >> >> None of the attempts to discuss his participation style or
> >> >> warn the
> >> individual
> >> >> have led to any improvements. The IESG therefore believes
> >> >> that a PR
> >> action is
> >> >> the correct response to his continued problematic behavior
> >> >> across a
> >> number of
> >> >> different lists.
> >> >>
> >> >> The IESG plans to make a decision in the next few weeks,
> >> >> and solicits
> >> final
> >> >> comments on this action. Please send substantive comments
> >> >> to the last-call@ietf.org mailing lists by 27 October
> >> >> 2022. Exceptionally,
> >> comments may
> >> >> be sent to iesg@ietf.org instead. If sending private
> >> >> feedback to the
> >> IESG,
> >> >> please indicate if you would be open to having your
> >> >> comments anonymized
> >> and
> >> >> shared in a summary.
> >> >>
> >> >> Please note: Comments should be limited to the criteria
> >> >> described in
> >> BCP 83,
> >> >> notably on whether the individual in question has engaged
> >> >> in postings
> >> that are
> >> >> "unprofessional commentary, regardless of the general
> >> >> subject" in a
> >> manner
> >> >> disruptive enough to warrant this action.
> >> >>
> >> >> Lars Eggert
> >> >> IETF Chair, on behalf of the IESG
> >> >> –-
> >> >>
> >> >> Examples of problematic emails during the last two years
> >> >> include:
> >> >>
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/gendispatch/zdq3F0PV40C
> >> yw5ooj0orOWaYyUw/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/gendispatch/i-d7HlWgrkm
> >> rVlC7JZQSXDwIJCQ/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/gendispatch/YhPI9zZ_3xf
> >> idt5V-ORRnET36yY/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/gendispatch/B33zk8VfOYt
> >> 4b4Cj-kIHXG3AXdg/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/gendispatch/d3iDS4WNkCJ
> >> A3aMFnX2HjP4tsps/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/gendispatch/-On8AHrdnnC
> >> MlJOOyb1M1nlYMpk/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/terminology/n6UMvDuYLKm
> >> mvpP1ajICFvf634M/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/terminology/QCdjDbokmlA
> >> RcwVqQ1TV3Rlz7eQ/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/terminology/X6OF0MBKAzy
> >> LhYaAfAxS6srXRNw/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/terminology/idJhG1MsLmK
> >> HyRlaAafcW2JF6Z8/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/ipsec/LoGSVatZ4EsYRq4K5
> >> 2rmvRZTndk/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/ietf/pl2lVqhtF4Z-0YuTjh
> >> COmdyi1qE/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/ietf/DFgnF_j8py_eMBGI1I
> >> UFdMahTKw/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/terminology/T3oCpY3BbTN
> >> LXWAWsCnFvahRLUQ/
> >> >> *
> >> https://mailarchive.ietf.org/arch/msg/admin-discuss/xLuz4WTCm
> >> 5ibIiMVN5ID8OWsCI0/
> >> >>
> >> --
> >> last-call mailing list
> >> last-call@ietf.org
> >> https://www.ietf.org/mailman/listinfo/last-call
> >>
>
>
>