Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07)

John C Klensin <john-ietf@jck.com> Wed, 12 January 2022 00:38 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CE83A18A8 for <rfced-future@ietfa.amsl.com>; Tue, 11 Jan 2022 16:38:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 j4nsFfF_1T9U for <rfced-future@ietfa.amsl.com>; Tue, 11 Jan 2022 16:38:12 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B1B3A18A6 for <rfced-future@iab.org>; Tue, 11 Jan 2022 16:38:11 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1n7ReT-0001Gq-2m; Tue, 11 Jan 2022 19:38:09 -0500
Date: Tue, 11 Jan 2022 19:38:03 -0500
From: John C Klensin <john-ietf@jck.com>
To: S Moonesamy <sm+ietf@elandsys.com>
cc: rfced-future@iab.org
Message-ID: <065B204CFF18FAEF88F13AAE@PSB>
In-Reply-To: <6.2.5.6.2.20220110231205.07ca1ba8@elandnews.com>
References: <F0016CA1725A561034951054@PSB> <7D28CA5F-594B-4212-9155-86669654A504@ietf.org> <A1A5EDBA-7598-4E74-ACEE-B7A39A8010F5@kuehlewind.net> <de858e02-a6ff-613b-3d2c-db85d5ea42b1@lear.ch> <CAFB3EA8-11D9-4D55-924A-B66294309869@kuehlewind.net> <2939BCCA4CA75D29739F59D4@PSB> <6.2.5.6.2.20220110231205.07ca1ba8@elandnews.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/oqM10r8nAm39YA4-XGd4JEnXV2o>
Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jan 2022 00:38:17 -0000


--On Monday, January 10, 2022 23:28 -0800 S Moonesamy
<sm+ietf@elandsys.com> wrote:

> Hi John,
> At 08:33 AM 03-01-2022, John C Klensin wrote:
>> involved before the selection committee is finalized".  We
>> could give guidance to the ED (which I assume we could trust
>> Jay to accept and follow) or we could request that the Board
>> make such a policy, but we basically can't tell the LLC what
>> to do or how to manage itself.
>> 
>> So I would go a step further than Mirja: if our intent is to
>> be sure the membership of the selection committee is a group
>> process rather than selection by an individual, we'd best
>> spell that out, at least as clear guidance.
 
> This group is requesting an external party to run a selection
> process.  Details, e.g. the delegation mechanism used within
> external party, is generally left to the external party to
> decide upon [1].

If you want to look at it in those terms (I, personally, don't
think it is particularly helpful), this group can specify any
selection process it concludes would be desirable and effective,
including having the RSAB or RSWG make open calls to the
community for search committee members, select that committee,
and have them go looking for an appropriate person to be RSCE.
If we had them do that, that committee would then presumably ask
the LLC to negotiate a contract with that person.  Presumably
the LLC could say "no, we won't do that" but I wouldn't expect
that and, if they did so without good reason, I assume there
would be an IETF community meltdown, the likes of which we have
not seen since the one popularly associated with the IAB meeting
in Kobe.

Again, I don't think that would be desirable, but the decisions
as to the process by which the RSCE is chosen really belong to
this group.  If the group believes that it is good to have the
LLC responsible for the selection process (not just the
contracting one), that is fine but, if the group also believes
it wants to give the LLC guidance in how that is done, we should
be able to assume that the LLC will follow that guidance.   If
we feel that we cannot make that assumption, then turning over
authority to make the selection to the LLC would be, to use the
precise technical term, really stupid.

That does suggest something we should (SHOULD ?) do before the
Last Call which Eliot just announced to be pending: just as the
IETF Last Call and IESG process involves formally asking IANA
(also an "external organization" if the LLC is one), we should
formally ask the LLC if they see any difficulties in accepting
and implementing any of the provisions of the document and. if
so, what they are.  If they do, those provisions of the document
probably need adjustment.

best,
   john