Re: Follow up on disruptive person during IETF 119

Bron Gondwana <brong@fastmailteam.com> Tue, 02 April 2024 02:12 UTC

Return-Path: <brong@fastmailteam.com>
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 186B2C14F6F5; Mon, 1 Apr 2024 19:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b="Z+jqOMNP"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="QQAIkik6"
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 g7IufK8nu7oa; Mon, 1 Apr 2024 19:11:57 -0700 (PDT)
Received: from wfout3-smtp.messagingengine.com (wfout3-smtp.messagingengine.com [64.147.123.146]) (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 6F0EEC14F6E3; Mon, 1 Apr 2024 19:11:57 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.west.internal (Postfix) with ESMTP id BE5FD1C000CA; Mon, 1 Apr 2024 22:11:55 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Mon, 01 Apr 2024 22:11:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1712023915; x=1712110315; bh=WYNzt/z2qZTFdTlgNijd/vXgKSIfpCcrqWoAr8GeLzg=; b= Z+jqOMNPfbECLNpObIU4Oek04f9DLbpdmf2a//s1zVy4zgll2Uynrpi9IZHxCxX2 hjh5GMVM68LpawS0ba+5cF/QlmhYSOMEGYrRsj7bFHdltGlFV+TfBv5zjtYrWygZ 8e++e34Hs7GGEpGwUCJtLCgKF3jmHt7iS5uNnZ26D2tzNB01evyPaaqNixfphxE3 GeTBdASKKKMWFDpebIUQvDY3TinvqSqS0HGRxLG+t29t74sOnofkrVpoLb0CQtDU 6ClVtMZ194qr7ZfCKgXAKRvh1LUVxWYtgfVN5L6BqIIBPPjas0M3tO1TqGWkLPV6 xCt5xpqN9BCmM4K9cfFQPg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1712023915; x=1712110315; bh=WYNzt/z2qZTFdTlgNijd/vXgKSIf pCcrqWoAr8GeLzg=; b=QQAIkik6TvhZyxW6x6R/KfmgvuCbiWwaaMDS/5giIcBi O4j3ARWJojC1RKbJ1Ikz+FDWQmVpFJOS6XsacyKWYSUti3cbUvR+fsWy/Mghsoq8 1XIt6FD5GvhiWTJhM2F7+QAK+P66R1w3rLuehuk/zE2NhC62o4+BIejXkplTEdCs SCYQyEhm9L4lldJ7ouE7A1VF59HRPHQeN4OLcUMraPCzLCbwI9enEv4OuCHX1tS9 qX6SAyMaBQLMkbIWKQCo3WsmMZmQGmgvprh/fV3qlpqQW/QhLZYp00YhnrlyTNOG Q6ShlJlmLg5Y5UoHRQWGuhlkMtufK8FttU1LNeYAig==
X-ME-Sender: <xms:amkLZifZS_dnT4bEYiDVNH6E1oe71wfPmqIT1cpYmBHpHUnm8CYTPw> <xme:amkLZsObTrqzAu82Nb_-SAv81a7tZ296IAD4FJyu4vp48R7UAFc3RENkpZuXPhCiR 1Eo38SaFk8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudefuddgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedfuehr ohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpeffiefgjeefheetieevjeevhfetueeigfdvhedtffeu jedvudffgfeiteehkefgvdenucffohhmrghinhepmhhnohhtrdhnvghtnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshht mhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:amkLZjjcjZw8gmTTLDlai7Kfq71ZvivtqUWL7JiQ2kyk-KWv91YG2A> <xmx:amkLZv9_xPRYT_-QYbWEK0GxcWDgAhP-ZTS0Sdh1a_QtaMZFzDaDjQ> <xmx:amkLZutdASDJNzngYkDRPUAHUjn4ITl5A8rBb0xNKc5VxSE5jg6aJQ> <xmx:amkLZmG7gLrjKe6CLhoDHotzd_IJRxmDr0GOS9a2bRBQ0-LBQ3svTg> <xmx:a2kLZgUh-0LqALICTQ0RAiNNPt4H6umeNlRJ0KNva3YfI4EYcsl2YPz6N2Y>
Feedback-ID: i2d7042ce:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 952082D4007D; Mon, 1 Apr 2024 22:11:54 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542
MIME-Version: 1.0
Message-Id: <2c42f39c-71bb-4ec2-ab92-9a65b2865055@app.fastmail.com>
In-Reply-To: <7387D4AA-D940-416A-A5C4-7C5083C1ED50@mnot.net>
References: <5F30A325-7A57-49C5-8FD9-B23ADE8D155B@ietf.org> <CAL02cgRRhZFDFWxUAOSOkku-+soo5bQZmx44a2fh5dXpO3F4kQ@mail.gmail.com> <5079FA08-FF4D-47F2-BE83-41527654B1DC@ietf.org> <7387D4AA-D940-416A-A5C4-7C5083C1ED50@mnot.net>
Date: Tue, 02 Apr 2024 13:11:21 +1100
From: Bron Gondwana <brong@fastmailteam.com>
To: Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org>, IETF Executive Director <exec-director@ietf.org>
Cc: IETF WG Chairs <wgchairs@ietf.org>, Robert Sparks <rjsparks@nostrum.com>, Laura Nugent <lnugent@amsl.com>, team@meetecho.com
Subject: Re: Follow up on disruptive person during IETF 119
Content-Type: multipart/alternative; boundary="e06e3360ab35467694ccc373c8d2c846"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/ql7L-mhiAIBfXwMnieZBUSTzfzw>
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: Tue, 02 Apr 2024 02:12:03 -0000

I think we're coming close to needing a "KYC" type of registration process for the IETF, along with affirmative agreement to the Note Well.  I don't think we can have entirely anonymous people contributing to standards and align with our other requirements.

I have been increasingly feeling that the Note Well slides at the start of sessions either need an exact spoken script or need to be standardised in some other way, or removed.  They're either un-necessary, or need to be more explicitly managed somehow.

In particular, somebody can walk into the room after they have been presented and hence avoid been "notewelled".

And similarly, having a slightly harder process to become a person who can contribute to any IETF mailing list or document; such that you can't easily add sock-puppet accounts will give us the ability to handle denial of service risks.

Bron.

On Fri, Mar 22, 2024, at 14:18, Mark Nottingham wrote:
> Jay,
> 
> I hear you, but I sat in on an IGF (IIRC) session that was porn-bombed; it only has to happen once. We need to be ready for that.
> 
> You bring up a good point re data tracker: are we doing anything to identify obviously suspect / "sock puppet" accounts there? The high numbers from Turkey were suggestive.
> 
> Cheers,
> 
> 
> 
> > On 22 Mar 2024, at 11:25, Jay Daley <exec-director@ietf.org> wrote:
> > 
> > Two important things to remember
> > 
> > 1.  We intentionally use Meetecho in a mode that delegates permissions to Datatracker. This allows us to define who the chairs are, what eligibility people have for sessions etc.  
> > 
> > 2.  We’ve operated in a particular way for quite some time and this is first real issue we’ve had. Extrapolating from this to regular disruption is taking things too far.
> > 
> > Jay
> > 
> >> On 22 Mar 2024, at 11:10, Richard Barnes <rlb@ipv.sx> wrote:
> >> 
> >> 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?
> >> 
> >> --RLB
> >> 
> >> 
> >> On Thu, Mar 21, 2024 at 9:04 PM Jay Daley <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
> >> 
> > 
> > -- 
> > Jay Daley
> > IETF Executive Director
> > exec-director@ietf.org
> > 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com