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

Michael StJohns <mstjohns@comcast.net> Sat, 31 August 2019 21:43 UTC

Return-Path: <mstjohns@comcast.net>
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 62841120122 for <ietf@ietfa.amsl.com>; Sat, 31 Aug 2019 14:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 EofrgYQahb-y for <ietf@ietfa.amsl.com>; Sat, 31 Aug 2019 14:43:04 -0700 (PDT)
Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 47CD3120074 for <ietf@ietf.org>; Sat, 31 Aug 2019 14:43:04 -0700 (PDT)
Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id 4AOjijAQK3mMa4B9DiYHWG; Sat, 31 Aug 2019 21:43:03 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1567287783; bh=VMYIqfWrdTqPQ7lAdb/z1StHb/nwp6faF6Z7xz5z8/8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=QMoizn8EPCVRm5rN+5llpmPen9iOYkBNEICTvpMWEz1RFxa2aqICREls/ngr9hwAP gCnCYhouGBqkBydd2CIWtobXLNMiKz2JhP8kKTTvUHnEXkYs+xmabOgJJ9vFLh5Omr ZObftmsHOgmnlyJBDXuV9pwkOoVByBYGo63EuRNn7ik7GK8ounB4MsvHZYXbqW46zw wbjHNw3nTRp2AZRGEJKeK9+NLfUHnNzqIVVrlbpv9vq7h7OQk8pUBgAzMtNkUiwv40 j1dBeuL3/qqBXP6xL1HPdulMv3iNdmSdntJxjJIMRfmrVvR6SbeOjDDeTu1rahP5uy OrVfRGE0FXOnw==
Received: from [IPv6:2601:152:4400:437c:45b4:2693:4311:18bc] ([IPv6:2601:152:4400:437c:45b4:2693:4311:18bc]) by resomta-ch2-16v.sys.comcast.net with ESMTPSA id 4B9Bi7SOabEcn4B9DijDW7; Sat, 31 Aug 2019 21:43:03 +0000
X-Xfinity-VMeta: sc=0;st=legit
Subject: Re: Sergeant-at-Armss and New proposal/New SOW comment period
To: ietf@ietf.org
References: <061D2F46-71C3-4260-B203-73B07EB59418@encrypted.net> <5B276430-96A9-44EA-929B-B9C2325AFCA5@encrypted.net> <863c6fa8-2735-b2c6-5542-d5d100485a6e@outer-planes.net> <10843FAF-66D2-483D-96AB-2F993803AAC6@cisco.com> <6FA9D85E1B425914CA994AFD@PSB> <96294b14-bee3-9045-fb5c-7984302d198e@network-heretics.com> <f922bf27-1f3f-8ded-f934-a00f0a2e9769@nostrum.com> <5C25F4C2-0B49-41F0-A2C4-025C388E278B@gmail.com> <4E57C402-2305-430D-9FA0-50377F50DAA4@nostrum.com>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <41d240e5-e672-4e30-3435-4e78dc70f8be@comcast.net>
Date: Sat, 31 Aug 2019 17:42:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <4E57C402-2305-430D-9FA0-50377F50DAA4@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/qhyvW13MV-VTNbzxKKKqMW_xYNQ>
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, 31 Aug 2019 21:43:06 -0000

*sigh*

Adam - Hyperbole at this point is not helpful.  Specifically "no 
supervision" does not come even close to what we've been asking.... no - 
make that telling ...  the SAA to do.   Let's not distract the  
conversation off the topic.

The SAA MUST NOT be used as a tool, or even be perceived as being used 
as a tool to stymie dissent, or to stop or steer discussions that might 
be uncomfortable to the SAA or I*.   The fact that there is an RFC-I 
mailing list does not in itself mean that all RFC related discussions 
must take place on that list.

Matthew was wrong to attempt to get the discussion moved over and needs 
to use a much finer filter in the future, as do all of the SAA, on any 
discussion that might be a community pushback or even discussion on I* 
leadership proposals.

For now - let's keep it here.  If we get to a point where we're cycling 
on a few topics, and those topics are more appropriate for the other 
list (e.g. maybe more details on things that have a broad community 
buy-in), then yeah, feel free to suggest it.

By the way - while I'm on the topic:

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.

  Later, Mike





'On 8/31/2019 3:55 PM, Adam Roach wrote:
> This is a fair point. Is it your position that there is no supervision function intended to keep the discussion within the mailing list’s charter, aside from that required to tamp down abusive behavior?
>
> /a
>
>> On Aug 31, 2019, at 14:36, Bob Hinden <bob.hinden@gmail.com> wrote:
>>
>> Adam,
>>
>>> On Aug 31, 2019, at 12:02 PM, Adam Roach <adam@nostrum.com> wrote:
>>>
>>> On 8/31/19 1:15 PM, Keith Moore wrote:
>>>> It's not easy to think of a topic more important to the future of IETF than the manner in which its output is published.   To suggest that this topic should not be discussed in IETF, but should instead be discussed in a venue outside of IETF, defies all logic.
>>>
>>> I think this overstates things a bit.
>>>
>>> One of the key objections that was repeatedly raised regarding the RFCPLUSPLUS BOF was that it took place within the context of IETF process, and since it had implications on streams other than the IESG stream, ran the risk of overstepping its bounds [1]. I believe it's pretty clear, even ignoring RFC 3005's "well-established list" clause, that whatever sincere concerns existed about proposing changes to the RFC Editor function solely within the IETF process back then must necessarily translate to holding a more existential discussion about the future of that function on an IETF mailing list list.
>>>
>>> To be clear, I suggested to the SAA that the conversation had this very risk of overstepping the bounds of the IETF's purview, as was clearly communicated by the community during that BOF. Any criticism of this logic should be directed at me rather than him.
>> Rereading RFC3005, it says:
>>
>>    The IETF Chair, the IETF Executive Director, or a sergeant-at-arms
>>    appointed by the Chair is empowered to restrict posting by a person,
>>    or of a thread, when the content is inappropriate and represents a
>>    pattern of abuse.
>>
>> The intended role of the sergeant-at-arms is for content that is is inappropriate and represents a
>> pattern of abuse.   There was no “inappropriate” nor “pattern of abuse” here whatsoever.
>>
>> Bob
>>
>>
>>
>>
>>
>>> /a
>>>
>>> ____
>>> [1] There were many such comments, both on-list and at the microphone. This one is representative: https://mailarchive.ietf.org/arch/msg/rfcplusplus/jQHmeaGqN231LNIPfCQwpeUIxds
>>>