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

Richard Barnes <rlb@ipv.sx> Fri, 22 March 2024 01:21 UTC

Return-Path: <rlb@ipv.sx>
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 27B35C14F5E7 for <wgchairs@ietfa.amsl.com>; Thu, 21 Mar 2024 18:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ipv-sx.20230601.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 GlH_pJX84OLv for <wgchairs@ietfa.amsl.com>; Thu, 21 Mar 2024 18:21:15 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 99561C14F690 for <wgchairs@ietf.org>; Thu, 21 Mar 2024 18:21:08 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-36864f7c5cdso4770525ab.1 for <wgchairs@ietf.org>; Thu, 21 Mar 2024 18:21:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1711070467; x=1711675267; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QZjx6B0c+/filPEajTFX/ZZViEs1GdMRsa7OQrRQWoQ=; b=yBCZSsvgm3KVkNI2N1JdH1P6XDcl+Tssqk8pXmacKm5b16Ui+dSYzLfvpI+98fyQhb DkdtOk/OrWgjxvFap6mdYIrMTCQTISgUPfBy1kY/paJLqFNGvFrlEeAH/A9qaiNFC1PG yJ/D6ECDshWUl68QjO0d9w4HZ5Qk+KCDPVD4pZLQKMoaJK7CcidwAAyGg6LTqPQGSzvq a1ShIYAgP7pdJVW2WUW1uea33R5kRtbumkNbrzh+m3s7C6qXPvrdKXj415iO1NwUfdkh dutvOPyvd9CFQsyxvEGFx2tkIGY23wbW4UMMkUiaZFXeQ4SO+4Jqnql9VyjKzlD6EO7+ xwWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711070467; x=1711675267; 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=QZjx6B0c+/filPEajTFX/ZZViEs1GdMRsa7OQrRQWoQ=; b=EswXbybitHdxY9hMrzJuLFPBRTYWaEdAQIA9NBmgtKGFDT5ciVs3ANcK0DCbb8q1wA teaJIQySLNrSeJ2O//d3gyY8aUjwGU334rxIwFoRRf/5iLvoQWHO+n4MrRCEhvES1Qm6 F6VKIu5fs4LM/eNwNuWvrVKye7oLd+AvOF03DTPr+dUHUaFsTeRJ7j+MwsOm0cobCPAk yzJDqRI9rOpB2N+cHhB1zHU1dTQUZxO7a68HYkt0CG+s4j8c4UJgUwHLvarbHPy3pCvc cbOX4nO15p4Pa4o/5eQl8BSp8B9NKEfqQBPa2xFY0TJ1nr0kbr2ytvOkxnvBjAEoBB/4 7FSA==
X-Forwarded-Encrypted: i=1; AJvYcCVySO2rxK5ZFRwDqL/QI0CJs9LSMRYXYwyvfx0vAhKyfIAqydjcVF82gKae+ZXOKTtgkcXYyhlbjaa2Bqkf02FJZA==
X-Gm-Message-State: AOJu0Yy8LZsw7Fp/O7dpwkpZs20nEo7U7k7iCVKupghNbK7OoBE6wK4Y KNlGBVIa6EMqNyNAwl6WH2nW/MlM2bBsvcFnc/mx/8xjMf8kAKUIuak4mPGES7fuetUNZres0Qv mm0stamJvvoY0jyn4hgzK59O8GOJah+HQM3+JBQ==
X-Google-Smtp-Source: AGHT+IEUaoVfBSEaxVQtLjFrnBQFE4nkvRDqMOMDUY9MOQjJ5vaUM2iHsO0g+I9pyhn/n0NSRTlRf7mPJzW7ZRYEQKQ=
X-Received: by 2002:a92:d5cb:0:b0:366:a93c:66c9 with SMTP id d11-20020a92d5cb000000b00366a93c66c9mr1079907ilq.4.1711070467339; Thu, 21 Mar 2024 18:21:07 -0700 (PDT)
MIME-Version: 1.0
References: <5F30A325-7A57-49C5-8FD9-B23ADE8D155B@ietf.org> <CAL02cgRRhZFDFWxUAOSOkku-+soo5bQZmx44a2fh5dXpO3F4kQ@mail.gmail.com> <03c50f14-ca6a-4c4b-b11b-dca9dd345d10@meetecho.com>
In-Reply-To: <03c50f14-ca6a-4c4b-b11b-dca9dd345d10@meetecho.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 21 Mar 2024 21:20:56 -0400
Message-ID: <CAL02cgR=+aSZDz8rJ8V_GmJDbEHuA6n5=_TTkBzZzr48BTdbOg@mail.gmail.com>
Subject: Re: [Team] Re: Follow up on disruptive person during IETF 119
To: Alessandro Amirante <alex@meetecho.com>
Cc: Jay Daley <exec-director@ietf.org>, IETF WG Chairs <wgchairs@ietf.org>, The IESG <iesg@ietf.org>, Robert Sparks <rjsparks@nostrum.com>, Laura Nugent <lnugent@amsl.com>, team@meetecho.com
Content-Type: multipart/alternative; boundary="000000000000645a40061435a30a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/j7I9icN_3mvQ-wk1zOkDuPZ8saI>
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:21:16 -0000

OK, so why isn't the answer just "Let the chairs turn the disruptive person
off"?

On Thu, Mar 21, 2024 at 9:14 PM Alessandro Amirante <alex@meetecho.com>
wrote:

> Il 22/03/24 02:10, Richard Barnes ha scritto:
> > Hi Jay,
> >
> > Thanks for taking action on this.  I'm surprised that this is such a
> > complicated thing to implement, especially the part where a WG chair has
> > to contact the secretariat.  That adds a bunch of slowness during an
> > IETF meeting, and is clearly not workable for interim meetings.
> >
> > Normal web conferencing platforms (Webex, Zoom, MS Teams, etc.) have
> > tools for a meeting host to manage disruptive "Zoom bombing"
> > participants.  Does MeetEcho not have such tools?
>
> Yes, obviously Meetecho does have such tools as well.
>
> AA
>
> > --RLB
> >
> >
> > On Thu, Mar 21, 2024 at 9:04 PM Jay Daley <exec-director@ietf.org
> > <mailto:exec-director@ietf.org>> wrote:
> >
> >     IESG / WG Chairs
> >
> >     The background here is that we had one individual disrupt a number
> >     of sessions, including the plenary, and we were required to first
> >     temporarily ban them and then permanently ban them.
> >
> >     The meetings team (LLC, Secretariat, NOC, Meetecho, Tools) have
> >     discussed this and we propose the following way forward to manage
> >     similar instances in the future.
> >
> >     1.  Maintain a trust-based approach with an exception process,
> >     rather than introduce new controls to lock/unlock a whole session.
> >     We think approach both maintains the permissive culture of the IETF
> >     and avoids extra complexity for WG Chairs.
> >
> >     2.  Add a new feature in Datatracker that allows the Secretariat to
> >     remove a participant from a session and more permanently.  The
> >     technical details here are that this feature will revoke their
> >     registration permissions and call a Meetecho API to remove them.
> >
> >     3.  For single session removal this new process can be invoked by a
> >     WG chair (of the session) or an AD, contacting the Secretariat.
> >     Permanent removal can only be authorised by me or Roman, normally
> >     after rapid consultation with the IESG.
> >
> >     Does this work for everyone?
> >
> >     Jay
> >
> >     --
> >     Jay Daley
> >     IETF Executive Director
> >     exec-director@ietf.org <mailto:exec-director@ietf.org>
> >
>
> --
> Ing. Alessandro Amirante, Ph.D.
>
> Meetecho S.r.l.
> www.meetecho.com
>
> Via Riviera di Chiaia 124
> 80122 Napoli, Italy
>
> Mobile: +39 329 6178743
> E-mail: alex@meetecho.com
>
>