Re: [irsg] Follow up on disruptive person during IETF 119

Reese Enghardt <ietf@tenghardt.net> Fri, 22 March 2024 01:35 UTC

Return-Path: <ietf@tenghardt.net>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A2BC14F60F; Thu, 21 Mar 2024 18:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.497
X-Spam-Level:
X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_MED=-2.3, 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=tenghardt.net
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 IrE43c_FTtCK; Thu, 21 Mar 2024 18:35:49 -0700 (PDT)
Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 A5D82C14F700; Thu, 21 Mar 2024 18:35:47 -0700 (PDT)
Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 5B1BCB2; Fri, 22 Mar 2024 02:35:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1711071345; bh=sh5UH7QecwbaG8SVCJ0Fe9suLDw1rc+BYMbWXlw9EQA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=tYUXDLWxGx8OjyUW4mdb1RSrZtQ9JObJcn3Kn3UMkk/ZLUKViwFe+EnLGlEiHHcbs LnxTM4hqFrXrhf9G/cZ/R+VbAR/HQU2/RQgwXGB5q2WupC4aQZPv452MTswjmTZ3js UTOw9z/KrkCO8y5ouz2tM0qfbdACbGtCesiWq5qowH/JCEeoV65lvWWBq64LQIiSmN IPSxMlERVZv2oGA7+ray2em7XluFN0Dxw/ehkMsdXZxSEgMoFTvlyd2a9Vd10ns+0s fOZFO+VAcrSytg2Ziu3InEXFjU8oPAgIPCEQq5Qy3neZ+9mb2rUZV+9pRXO5R+KBob jAVsXKimRdIgA==
Message-ID: <8006de20-277e-b940-b57d-f1ea1dc7a3a2@tenghardt.net>
Date: Fri, 22 Mar 2024 11:35:37 +1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Subject: Re: [irsg] Follow up on disruptive person during IETF 119
Content-Language: en-US
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>, Jay Daley <exec-director@ietf.org>, The IESG <iesg@ietf.org>
Cc: IETF WG Chairs <wgchairs@ietf.org>, Robert Sparks <rjsparks@nostrum.com>, Laura Nugent <lnugent@amsl.com>, "team@meetecho.com" <team@meetecho.com>
References: <5F30A325-7A57-49C5-8FD9-B23ADE8D155B@ietf.org> <PAXPR07MB7838B22552B3EAE3840E954398312@PAXPR07MB7838.eurprd07.prod.outlook.com>
From: Reese Enghardt <ietf@tenghardt.net>
In-Reply-To: <PAXPR07MB7838B22552B3EAE3840E954398312@PAXPR07MB7838.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/IFjN9WWzabPy_X_bDyt9-8g2Cec>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2024 01:35:53 -0000

Hi,

On 3/22/24 11:19, Francesca Palombini wrote:
>
> I appreciate that we would keep a “trust-based approach”, but I do 
> think that WG chairs or at least ADs need to be able to not 
> necessarily remove disruptive participant from a session, but 
> definitely block a participant from sending audio/video for a longer 
> amount of time, say a session (that is not switch their audio/video 
> off) without necessarily going through the secretariat.
>
> I also think we need to think about the same for chats, even if it was 
> not a problem this time.
>
I agree with Francesca here.

The individual in question was in one of the sessions I chaired.

I worked with Meetecho in the chat, and they said they're able to boot 
the participant if needed. This was fine for me, if stressful.

It'd be better if we as chairs had an easier way to do this, and 
definitely please don't make it harder. Having to contact the 
Secretariat while also chairing is definitely harder than just 
contacting Meetecho, we chat them for general audio/video issues anyways..

I noticed that in my next session as chair, I saw new controls to revoke 
audio/video from a participant (once, then they could start staring 
audio/video again). This feature is a good start, and it was sufficient 
to address the individual in question. Is this feature temporary or will 
it stay?

Also, big shout-out to the Meetecho folks for their great support in 
this matter!

Best,
Reese