Re: RFC Series Editor Resignation

Benjamin Kaduk <kaduk@mit.edu> Fri, 28 June 2019 21:45 UTC

Return-Path: <kaduk@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 E8A371201AA for <ietf@ietfa.amsl.com>; Fri, 28 Jun 2019 14:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 iYS-hq7-XmG6 for <ietf@ietfa.amsl.com>; Fri, 28 Jun 2019 14:45:10 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586121201A8 for <ietf@ietf.org>; Fri, 28 Jun 2019 14:45:10 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5SLj4pb032368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jun 2019 17:45:06 -0400
Date: Fri, 28 Jun 2019 16:45:04 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael StJohns <mstjohns@comcast.net>
Cc: ietf@ietf.org
Subject: Re: RFC Series Editor Resignation
Message-ID: <20190628214503.GC30882@kduck.mit.edu>
References: <685B34F6-E0E2-4050-B9DD-615F475F62B7@encrypted.net> <6E58094ECC8D8344914996DAD28F1CCD18D3A5CF@dggemm526-mbx.china.huawei.com> <8CDEE96C-B1DA-4991-B8AA-A2455B705B77@mnt.se> <34F6E9B8-2BC2-46AC-8AF8-EFDA552D659D@tzi.org> <EA13A490-2636-459F-919B-8A72F4F45174@cable.comcast.com> <df5a6b6c-d444-7e72-dd6c-e2fa844195fa@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <df5a6b6c-d444-7e72-dd6c-e2fa844195fa@comcast.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/h1sMZG5BVBO5wsXFYvYAv0k-BII>
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: Fri, 28 Jun 2019 21:45:13 -0000

Hi Mike,

On Fri, Jun 28, 2019 at 01:38:21PM -0400, Michael StJohns wrote:
> On 6/28/2019 11:28 AM, Livingood, Jason wrote:
> > Usually a situation developed because some process was flawed or due to a lack alignment between responsibility & accountability, etc. This also means granting a bit of trust in colleagues and acknowledging that everyone is doing their best to achieve what they think will best serve the situation/platform/org/etc. This can be hard to do, but it is a healthy step that can make an org stronger.
> 
> Hi Jason -
> 
> The problem is that whatever trust I (we?) might want to grant in this 
> case is diminished by past actions such as the rfcplusplus bof, and in 
> the current instance, an explanation of behavior by the RSOC that 
> doesn't meet the smell test.
> 
> This also begs the question of what were they actually trying to achieve 
> and whether we the community believe those to be worthy goals.
> 
> A few of the other questions that should be asked in the post-mortem of 
> this stupidity* is "Why did the RSOC find it necessary to take the 
> actions it took without any community input whatsoever?" and "Did the 
> IAB have any pre-knowledge of the actions that were about to be taken?"
> 
> Mike
> 
> 
> * With respect to the term "stupidity", this was the least offensive 
> term I was able to come up with that had the appropriate impact in the 
> above statement. This is not an "unfortunate event" or a "well meaning 
> action" or even a "mistake". "Stupidity" at least leaves the question of 
> malign intent open.    Feel free to come up with your own terms.

I appreciate that you have put thought into your phrasing.  However, this
term nonetheless fails to meet the bar for professional conduct required
by RFC 3005.  We must treat each other with courtesy, even when we find
events to be disconcerting.  Making observations about the situation is
reasonable; attacking community members is out of bounds.

Thanks,

Ben
for the Sergeant-at-Arms