Re: Enough is Enough.

John Wroclawski <jtw@csail.mit.edu> Sat, 24 October 2020 19:16 UTC

Return-Path: <jtw@csail.mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CB93A1080; Sat, 24 Oct 2020 12:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRlVS0MWy2E2; Sat, 24 Oct 2020 12:16:57 -0700 (PDT)
Received: from ana-server.csail.mit.edu (ana-server.csail.mit.edu [18.26.1.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2F83A10E6; Sat, 24 Oct 2020 12:16:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ana-server.csail.mit.edu (Postfix) with ESMTP id 1F97EF25E765; Sat, 24 Oct 2020 15:16:54 -0400 (EDT)
X-Virus-Scanned: amavisd-new at ana-server.csail.mit.edu
Received: from ana-server.csail.mit.edu ([127.0.0.1]) by localhost (ana-server.csail.mit.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iVF4abYZ3Ynh; Sat, 24 Oct 2020 15:16:48 -0400 (EDT)
Received: from jmp.cambridge.schlepp.org (c-71-232-17-13.hsd1.ma.comcast.net [71.232.17.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ana-server.csail.mit.edu (Postfix) with ESMTPSA id 647B4F25E749; Sat, 24 Oct 2020 15:16:47 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: Enough is Enough.
From: John Wroclawski <jtw@csail.mit.edu>
In-Reply-To: <20201024190436.GC52044@faui48f.informatik.uni-erlangen.de>
Date: Sat, 24 Oct 2020 15:16:45 -0400
Cc: Ofer Inbar <cos@aaaaa.org>, "legal@ietf.org" <legal@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC8F2A7C-BBC8-42DE-B265-243ADA0972A2@csail.mit.edu>
References: <MN2PR11MB4366A0264CACD3D1B18E82E4B51F0@MN2PR11MB4366.namprd11.prod.outlook.com> <20201024153933.GB52044@faui48f.informatik.uni-erlangen.de> <20201024160758.GF2632@mip.aaaaa.org> <20201024190436.GC52044@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Y0r-KJejwkunOrwGfuw8LIuMKJk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Oct 2020 19:16:58 -0000


> On Oct 24, 2020, at 3:04 PM, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> Still waiting of course for someone to explain better boundary definition
> of "unusual circumstances".

I’d suggest that “unusual” means “not in the normal course of doing business”.

People stop working with the IETF all the time. It’s expected within the normal course of IETF business, so it’s not unusual. People also abandon specific ideas all the time; that too is expected in the normal course of business, so not unusual.

It’s not expected in the normal course of business that, picking an example at random, a draft with a legally actionable libelous slur is published. Hence, if that did occur, the “unusual circumstance” test would seem to be passed, since it’s not a thing that’s expected within the normal course of the IETF business process.

My 2c,
John