[Last-Call] Re: Last Call: BCP 83 PR-Action for Timothy Mcsweeney

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The only objection I have is that this PR action last call seems a bit incomplete.

Just a surface-level dig into McSweeney's posts reveals a history ad hominem attacks (cf. https://mailarchive.ietf.org/arch/msg/uri-review/pDeKKQpjYrwRe4zyrGvzCmwE_ec/ and https://mailarchive.ietf.org/arch/msg/ietf/ArncdBPwobpoCcf2625HsJzGVa8/). There's more subtle subversion to be found in his historical behavior, to such a degree that I've several times come close to asking the IESG to consider taking action in the past. To date, though, the problematic behavior has seemed to be masterfully crafted to be disruptive in a way that explicitly stays within the lines of what is technically "allowable behavior" per our own documents while still demanding excessive time from participants, leadership, and experts. As one (of multiple) examples: If McSweeney's early behavior is unfamiliar to anyone here, it's worth pointing out that he harried the URI list and the registry expert by demanding registration of a clearly syntactically invalid URI scheme, and then appealed its rejection first to the IESG and then to the IAB. If someone were to ask me how to waste the IETF's time as effectively as possible, this is literally the playbook I would have written. It was a well-crafted and clever denial-of-service attack. Given the criteria of "unprofessional" and "disruptive," I believe this behavior -- and the subsequent long-running pattern -- does qualify, but it's always been just subtle enough and left just enough doubt about intentions to be tricky to call out. And so in some regards, I'm glad that McSweeney finally cross a line of decorum in such an explosive and unambiguous way, since it removes this doubt entirely.

I take Yoav's point about established processes, and it's worth taking seriously. I think there are some countervailing facts here that make the current PR action warranted, as Roman alludes to below. One thing that's tricky to account for a priori in these kinds of human-oriented processes is unforeseeable and extreme behavior that is so far outside cultural norms that it could not have been adequately treated in the documents describing our process. The cited mail is deeply repugnant, consisting of both personal aggression towards an IETF participant, and general aggression towards a class of participants.

One of the things that has, in my opinion, made the IETF process successful and resilient to intentional disruption is the fact that we don't have votes, and we allow our processes to take many different paths to success. We afford chairs, area directors, and other people who have taken up the roles of progressing work a fair degree of latitude to "do the right thing" when it comes to judging consensus, controlling microphone lines, determining next steps, and so forth. I think it is a tremendous strength that responsible people are allowed to use their good faith judgement to determine what needs to happen, combined with the safeguards of appeals when it appears that someone has either exercised bad judgement or bad faith.

And so I think it's entirely appropriate that, should participants in general find that a behavior is so egregious, so unprofessional, and so toxic as to warrant doing so, then moving swiftly to protect the community from the resulting disruption is appropriate, even if it means that we're having to adapt our processes slightly to deal with unforeseeable levels of bad behavior.

For my own part, I do find such action warranted in this case.

/a

On 6/8/2024 9:40 AM, IETF Chair wrote:
The IESG has initiated a posting rights (PR) action that would restrict the posting rights of Timothy Mcsweeney per the procedures in BCP 83 (RFC 3683). Specifically, his posting privileges to the ietf@xxxxxxxx discussion list would be suspended.

In the IESG's assessment, this individual’s recent post [1] was an egregious example of misogynistic harassment inconsistent with the IETF Guidelines for Conduct (RFC 7154), IETF Anti-Harassment Policy [2], and “abusive of the consensus-driven process” (per Section 2 of RFC 3683).

The IESG recognizes the role of a progressive disciplinary process, to include the escalatory moderation practices of the IETF Discussion list moderators per RFC 9245 and [3]. Additionally, the IESG appreciates the role of the Ombudsteam and the IETF Anti-Harassment Procedures (RFC 7776).  However, the IESG feels that this particular response of a PR is warranted in this situation.

The IESG plans to make a decision and is soliciting final community comments on this action. Please send substantive comments to the last-call@xxxxxxxx mailing lists by 6 July 2024 [4]. Exceptionally, comments may be sent to iesg@xxxxxxxx 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.

Note: Comments should be limited to the criteria described in BCP 83 (Section 1 of RFC3683), notably on whether the individual in question has engaged in behavior that is "unprofessional commentary, regardless of the general subject" in a manner disruptive enough to warrant this action.

Roman Danyliw
IETF Chair, on behalf of the IESG
—
[1] https://mailarchive.ietf.org/arch/msg/ietf/NjNux65wUXXQaMmgENuwoopZPjI/
[2] https://datatracker.ietf.org/doc/statement-iesg-ietf-anti-harassment-policy-20131103/
[3] https://github.com/ietf/Moderators/blob/main/sop.md
[4] PR actions require an IETF Last Call (IETF LC).  The four-week duration of this IETF LC is consistent with that of an AD-sponsored document action.

_______________________________________________
IETF-Announce mailing list -- ietf-announce@xxxxxxxx
To unsubscribe send an email to ietf-announce-leave@xxxxxxxx


--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux