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

"Theodore Y. Ts'o" <tytso@mit.edu> Mon, 02 September 2019 22:17 UTC

Return-Path: <tytso@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 4749512007C for <ietf@ietfa.amsl.com>; Mon, 2 Sep 2019 15:17:00 -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 0mRI8zfVglU1 for <ietf@ietfa.amsl.com>; Mon, 2 Sep 2019 15:16:58 -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 70DE612009E for <ietf@ietf.org>; Mon, 2 Sep 2019 15:16:58 -0700 (PDT)
Received: from callcc.thunk.org ([66.31.38.53]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x82MGs99024781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Sep 2019 18:16:55 -0400
Received: by callcc.thunk.org (Postfix, from userid 15806) id 6788542049E; Mon, 2 Sep 2019 18:16:54 -0400 (EDT)
Date: Mon, 02 Sep 2019 18:16:54 -0400
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Bob Hinden <bob.hinden@gmail.com>
Cc: Adam Roach <adam@nostrum.com>, Keith Moore <moore@network-heretics.com>, IETF <ietf@ietf.org>
Subject: Re: Sergeant-at-Armss and New proposal/New SOW comment period
Message-ID: <20190902221654.GD3367@mit.edu>
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> <876EC772-37E4-413C-8FA6-A8744D6A9A33@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <876EC772-37E4-413C-8FA6-A8744D6A9A33@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/fgSZ_DHowwaVsMz5Es24IDDNlyg>
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: Mon, 02 Sep 2019 22:17:00 -0000

On Mon, Sep 02, 2019 at 10:04:52AM -0700, Bob Hinden wrote:
> Adam,
> 
> > On Aug 31, 2019, at 12:55 PM, Adam Roach <adam@nostrum.com> 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?
> 
> There has been a lot of discussion about this, but to answer your question.
> 
> I don’t read any “supervision function" in RFC3005.  It’s short and clear on what the it’s scope is.

I'll add that when I served as S-A-A, I tried to use a very light
touch, and the only goal that *I* understood the job involved was to
tamp down abusive behavior.

I'll also add that it probably helped that I didn't hold another IETF
leadership role, since it never meant that there was any question of
any conflict of interest that I might be trying to "supervise" some
discussion that was, say, critical of the IESG as a body.

To the extent that Ben also serves an Security AD, regardless of
whether he is executing his role in good faith, when there comes a
time people are questioning decisions by the IETF leadership, it's
going to make it harder for him to fulfill his role as S-A-A.  And
please note that I am not arguing that he *has* abused his role; just
that when faith in the IETF leadership might be lacking in some
quarters, there may very well be a perception of abuse ---
*especially* when trying to "manage" discussion might get perceived as
a way of shutting down criticism of IETF leadership.

If, in the future, there is a desire to open up RFC 3005 for
improvements, one change which might be appropriate is a very strong
suggestion to maintain a greater separation of roles to minimize the
perception of conflicts of interest.

Regards,

					- Ted