Consultation on restricting participant access to IETF systems

IETF Executive Director <exec-director@ietf.org> Wed, 29 June 2022 20:36 UTC

Return-Path: <exec-director@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BABC157B39 for <ietf-announce@ietfa.amsl.com>; Wed, 29 Jun 2022 13:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 NGLY_W7tild0 for <ietf-announce@ietfa.amsl.com>; Wed, 29 Jun 2022 13:36:30 -0700 (PDT)
Received: from ietfx.amsl.com (ietfx.amsl.com [50.223.129.196]) (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 1C784C14792F for <ietf-announce@ietf.org>; Wed, 29 Jun 2022 13:36:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 1301840D10D7 for <ietf-announce@ietf.org>; Wed, 29 Jun 2022 13:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from ietfx.amsl.com ([50.223.129.196]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pviNtRMTdzsL for <ietf-announce@ietf.org>; Wed, 29 Jun 2022 13:36:30 -0700 (PDT)
Received: from smtpclient.apple (host-92-27-125-209.static.as13285.net [92.27.125.209]) by ietfx.amsl.com (Postfix) with ESMTPSA id AC5964053E5D for <ietf-announce@ietf.org>; Wed, 29 Jun 2022 13:36:29 -0700 (PDT)
From: IETF Executive Director <exec-director@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Reply-To: admin-discuss@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Consultation on restricting participant access to IETF systems
Message-Id: <AABA4DB0-7489-41D0-AD84-D5CD64698311@ietf.org>
Date: Wed, 29 Jun 2022 21:36:26 +0100
To: IETF Announcement List <ietf-announce@ietf.org>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/L8z1bBQ0ShDiJn2QHqEFXlAyQK0>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2022 20:36:35 -0000

The IETF Administration LLC (IETF LLC) has received legal advice that there are specific circumstances where it may need to restrict an individual’s access to IETF IT systems or face potentially serious legal consequences.  The circumstances identified so far are:

1.  When an individual is using IETF systems to seriously harass another and all attempts to get them to voluntarily desist have failed.
2.  When an individual is using IETF systems to repeatedly infringe the intellectual property rights of one or more third parties and all attempts to get them to voluntarily desist have failed.
3.  When ordered to do so by a court order from a court with jurisdiction over the IETF LLC.

Please note that ‘IETF systems’ means mailing lists, Datatracker, remote participation services (Meetecho, Webex and Zulip), and more.

Clearly each of the three circumstances described above are very different.  For circumstance 1 (harassment), there are existing processes that would be followed initially, such as involving the Omdbudsteam and the RFC 3683 process for revoking posting rights.  However, this consultation is about what should happen if and when any applicable processes have been followed and we still reach the point where legal counsel advises us to restrict access.

For circumstance 2 (IPR infringement), the RFC 3683 process could also potentially be used, but again this consultation is about what happens when that doesn’t work or the infringement is not sufficiently addressed by that.  We also need a policy here because legal counsel has counseled us to define a US Digital Millennium Copyright Act (DMCA) policy to benefit from the associated ‘safe harbor’ regime and avoid potential significant risks the IETF LLC could face in the absence of such a policy. 

For circumstance 3 (court order), while our discretion to act would be very limited, there are still important questions of how we do it and what we tell the community. 

With this context, the IETF LLC would like community feedback on what a draft policy for restricting access should look like, working on the assumption that such restriction will ultimately be necessary under certain circumstances and it is therefore important to define such a policy in advance.  The IETF LLC will then draft a policy using this feedback and consult on that text.

The reason that this consultation is being issued by the IETF LLC rather than say the IESG, is because the IETF LLC has the ultimate legal responsibility here, as defined in RFC 8711 “​​The IETF LLC is responsible for establishing and enforcing policies to ensure compliance with applicable laws, regulations, and rules”. However, if anyone feels that an IETF LLC consultation is not the appropriate mechanism to consider such a policy and it should instead be handled through a community-led process, then please let us know.  Alternatively, some may feel that a consultation is not needed because this should be left to the lawyers to advise and the LLC to follow their advice, in which case please let us know.

While comments are welcome on any aspect of this, the key questions that the IETF LLC seeks feedback on are:

*  Who should be the decision maker(s) for any restriction of access under this policy and what process should they be required to follow?  For example, could it be the IETF LLC board acting on a recommendation of the IETF Executive Director and advice of legal counsel, and having consulted as appropriate, the IESG, IAB, IRTF Chair, Ombudsman, etc?
	
*  Should we restrict the person or the infringing logins, email addresses, etc?  It is recognised that people can get around restrictions by using different email addresses, IP addresses, etc but the alternative of expecting the IETF LLC to try to identify the person behind those may have unintended consequences for those that choose to participate pseudonymously for reasons unrelated to these circumstances.
	
*  How should any restriction of access be structured, considering both the severity of the limitation and the period of the restriction?  For example, should it begin with system access (such as sending an email or submitting an I-D) being moderated and if that doesn’t work escalate to complete disconnection? And for how long would any restriction apply?

* What right of appeal should anyone subject to access restriction have and to whom?
	
*  What information should be made public regarding any action to restrict access?

Please provide your feedback either to the admin-discuss@ietf.org public mailing list, or to me directly at exec-director@ietf.org by 7 August 2022.   

-- 
Jay Daley
IETF Executive Director
exec-director@ietf.org