Hi, > On Jun 8, 2024, at 3:58 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > > Thanks, Adam, for the additional examples. They passed me by, since > I've been auto-deleting Mcsweeney's messages for a number of years, > based on previous experience. (Note: I will continue to do so.) > > This addition was needed, because BCP 83 explicitly addresses a > pattern of misbehaviour, not just a single instance. I agree and I support the PR-Action. Bob > > Regards > Brian Carpenter > > On 09-Jun-24 10:32, Adam Roach wrote: >> 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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
