Re: draft-sullivan-nomcom-chair-select-00

Toerless Eckert <tte@cs.fau.de> Mon, 14 February 2022 22:02 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 B00873A0AF4 for <ietf@ietfa.amsl.com>; Mon, 14 Feb 2022 14:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 uGbvp0B2Zzu5 for <ietf@ietfa.amsl.com>; Mon, 14 Feb 2022 14:02:10 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CF03A12AD for <ietf@ietf.org>; Mon, 14 Feb 2022 14:02:09 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 3EAC7549B4C; Mon, 14 Feb 2022 23:02:02 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 297024EA65F; Mon, 14 Feb 2022 23:02:02 +0100 (CET)
Date: Mon, 14 Feb 2022 23:02:02 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: ietf@ietf.org, sullivan@isoc.org
Subject: Re: draft-sullivan-nomcom-chair-select-00
Message-ID: <YgrRWsltfnp3aqwI@faui48e.informatik.uni-erlangen.de>
References: <20220214055405.v7qujqp5lmqynga5@outlook.office365.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20220214055405.v7qujqp5lmqynga5@outlook.office365.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/OjdRnsbeAROhRviOgWs6ScO6cS8>
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, 14 Feb 2022 22:02:15 -0000

Andrew:

a) I could not figure out from the draft or this mail thread under which
   track you want this document to become an RFC. Depending on the
   track choosen i guess the way how the document should be discussed
   could be as you indicated (one on one with you), or it should be
   discussed many-to-many in a group. So i'll just start addressing
   both you and ietf@ietf.org until thats clear.

b) Thanks a lot for the work. 

c) I think the procedures described are pretty good and very diligent.
   However:

c.1) It is unclear to me why we would want these rules to apply to
   every ISOC President. I for once could see this perfectly well simply
   as a declaration by you, outlining the process you will follow. and
   making it "just" a declaration would make it easier for your successors
   to adjust/change the processes.

c.2) Maybe i am reading incorrectly between the lines, but
   "this represents a change to the existing process" sounds as if
   this document needs to become an RFC so that you could publically
   "moot" candidates. But thats not clear to me. Just because public
   "mooting" wasn't done so far doesn't seem to mean that you couldn't
   do it even without this document becoming an RFC defining requirements.
   Aka: i see nothing in the existing RFCs prohibiting the mooting.

c.3) The other key reason why i guess you wrote this is to establish
   even past your term a less insider-trading approach to the selection
   process. Which is admirable. But i again have to weight good intention
   against ever growing bureaucracy and RFCs piling on requirements
   because all of our RFC requirements especially those about process
   are legislated over by anal retentive engineers forever.

In summary: IMHO, this doc might work better if it was just a declaration
of how you will do things without raising actual process requirements
against your successors or you.  I think even in that form the document
would be making any successor select a process that attempts its best to
make selection less biased and less insider-trading.

Cheers
    Toerless

On Mon, Feb 14, 2022 at 12:54:05AM -0500, Andrew Sullivan wrote:
> Dear colleagues,
> 
> I write with my job hat on.  I'm employed by the Internet Society.
> 
> Part of my job here is to select the NomCom Chair.  I've been
> uncomfortable about how that has worked in the past, and more than a
> year ago I said I'd write a new process.  I failed at that goal, but
> it's a new year so I've finally written this.  It's at
> https://datatracker.ietf.org/doc/draft-sullivan-nomcom-chair-select/.
> 
> I am eagerly requesting feedback on that draft _for things under my
> control_.  The procedures in RFC 8713 give me a lot of latitude in how
> to deal with this appointment.  They give me no control whatsoever as
> to whether I _should_ be able to do this, who else should do it, and
> so on.  Feedback of the form "Here's how NomCom should work for real,"
> will be ignored, because they will not provide me guidance as to what
> I should do.
> 
> Please also resist the temptation to tell me, "Tell someone else it's
> their thing and promise to follow what they promise."  If the IETF
> wants to modify RFC 8713, including removing my own role in this
> selection, I don't imagine a universe in which I'd work to work to
> foil that.  But similarly I am not willing to create an entirely new
> consultative body (or new job for an existing consultative body)
> without the community saying so.  This document is merely an outline
> of how I plan to execute my duties as they're already defined.
> 
> I hope this will be a modest contribution to the IETF, and I look
> forward to your suggestions.
> 
> _Please_ send me feedback directly and not copied to the list.  I
> won't be able to follow discussion about this on the list except
> sporadically, and I'm going to have to put this plan into action some
> time in the coming weeks.  Thanks very much.
> 
> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> President & CEO, Internet Society
> sullivan@isoc.org
> +1 416 731 1261

-- 
---
tte@cs.fau.de