Re: Sergeant-at-Armss and New proposal/New SOW comment period

Benjamin Kaduk <kaduk@mit.edu> Sun, 01 September 2019 19:52 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 70A5A1200C4 for <ietf@ietfa.amsl.com>; Sun, 1 Sep 2019 12:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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, URIBL_BLOCKED=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 JD-vqJMENlRU for <ietf@ietfa.amsl.com>; Sun, 1 Sep 2019 12:52:18 -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 6A36812007C for <ietf@ietf.org>; Sun, 1 Sep 2019 12:52:18 -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 x81JqBvP001178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 1 Sep 2019 15:52:13 -0400
Date: Sun, 01 Sep 2019 14:52:10 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael <mstjohns@comcast.net>
Cc: ietf@ietf.org, Adam Roach <adam@nostrum.com>
Subject: Re: Sergeant-at-Armss and New proposal/New SOW comment period
Message-ID: <20190901195210.GA27269@kduck.mit.edu>
References: <964a7d97-f146-4d2e-aa3e-d39fc08f6f76@Mikes-IPhone>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <964a7d97-f146-4d2e-aa3e-d39fc08f6f76@Mikes-IPhone>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wOTloFLA7zSpH6AzBL7PSI2l8Ak>
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: Sun, 01 Sep 2019 19:52:21 -0000

Hi Mike,

I'd like to follow up on that more -- my recollection is that I was
explicitly not attempting to advocate a particular position, and was rather
trying to foster effective communication in a stressful environment that
was prone to a breakdown of communication.  I'd like to better understand
how and why I failed to do so, so that I can do better in the future.

My default assumption would be that it's best to have that follow-up
offlist, but I am not going to attempt to impose my preference on you.

Thanks,

Ben

On Sat, Aug 31, 2019 at 09:15:00PM -0400, Michael wrote:
> Ben - specifically in the discussion that prompted Alissa to threaten to PR me.
> 
> Mikr
> 
> Sent from XFINITY Connect Mobile App
> 
> ------ Original Message ------
> 
> From: Adam Roach
> To: Michael StJohns, ietf@ietf.org
> Sent: August 31, 2019 at 9:06 PM
> Subject: Re: Sergeant-at-Armss and New proposal/New SOW comment period
> 
> On 8/31/19 4:42 PM, Michael StJohns wrote: > Adam - Hyperbole at this point is not helpful. Specifically "no > supervision" does not come even close to what we've been asking... I'm sorry if that came across as hyperbole. I'm honestly trying to probe at what the community thinks RFC 3005 provides for. If there's some legitimate authority granted (by what language?) to someone (whom?) to provide such shepherding, I'm curious about what people think that looks like. The language that Bob cites, on its face, implies that it does not exist. I was simply trying to clarify that such was the point he was making. The rest of your points are reasonable, and as long as no one else is objecting to the possibility of having this conversation on IETF territory [1] -- rather than a venue hosted by the RFC Editor -- then I'm happy to drop attempts to redirect the conversation. We've heard jurisdictional complaints in the past, and I'm simply trying to avoid them this time around. I have one questio
> n for you: > The SAA should not participate in a conversation that it expects to > have oversight on. Listening is fine, advocacy for one side or > another is pretty much disqualifying in acting as the SAA for that > topic as SAA decisions could be seen to be tainted by bias. I understand the principle you're laying out. Your phrasing implies that you've seen instances of this happening, which I would find out of character for either Matthew or Benjamin. Have you seen this happening? Or are you just trying to ward off future issues? /a ____ [1] Its impacts on the IRTF and ISE notwithstanding