Well, in this message, from the PR action, he just calls me stupid.
I’m not stupid.
thanks,
Rob
On Tue, Oct 4, 2022 at 22:06 Ben Campbell <ben@xxxxxxxxxxx> wrote:
I have, for the last several days, been trying to compose a response, and haven’t gotten it right yet. But Christian expressed it perfectly. That is, I would support the PR-action, but I have reservations. It is not clear to me that the growing consensus separates "unpopular opinions" from the "abusive messaging patterns”.
Don’t get me wrong; I think there is enough to support the PR-Action based strictly on the latter. But Lar’s message could be interpreted to also be concerned with the former. I would like the IESG to clarify the distinction and draw some bright lines.
Ben.
> On Oct 4, 2022, at 11:19 PM, Christian Huitema <huitema@xxxxxxxxxxx> wrote:
>
>
> On 9/29/2022 9:15 AM, 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
>
> I understand that that the IESG want the "rude and abusive" behavior to stop. I am however concerned that the action as written doesn't distinguish clearly between censoring unpopular positions and censoring abusive messaging patterns.
>
> I looked at Dan's posts listed in the last call, and I find a mix of reasonable arguments followed by attacks, with quite a bit of trolling. Take for example https://mailarchive.ietf.org/arch/msg/gendispatch/i-d7HlWgrkmrVlC7JZQSXDwIJCQ/. It argues that a word like "master key" is an established term of the art whose origin is not tainted by racism, and that the IETF (or the IEEE) should not attempt a systematic replacement. Whether one agrees or not, that's a reasonable argument during a discussion of terminology. But then, the message goes on with a rant about the political priorities and personal ethics of the proponents of such replacements, and the IETF can do without these kind of attacks. It can also certainly do with the kind of trolling found in https://mailarchive.ietf.org/arch/msg/gendispatch/-On8AHrdnnCMlJOOyb1M1nlYMpk/, in which Dan pretends to be offended by the use of the word "native" in some computer languages.
>
> The IESG should clarify that unpopular opinions, per se, are OK. We need many voices in any debate. Indeed, in the terminology debate, the IETF eventually adopted the NIST guideline. This was significantly different from the original proposal, but probably closer to IETF consensus.
>
> I am concerned that the sentence about "expressing racism by denying anti-racist sentiment" can be misinterpreted, or misused. Clearly, attacking or belittling people because of their race, religion, sexual practices or culture has no place in the IETF. Personal attacks against proponents of specific anti-racist actions is also wrong. But some proposals motivated by anti-racism may well be misguided. Like any other proposals, they should be debated based on their merits.
>
> I would like the IESG to rewrite its message and clearly indicate that they are censoring personal attacks, ridiculing and trolling, but not censoring the debate itself.
>
> -- Christian Huitema
>
> --
> last-call mailing list
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
