Re: RSE Bid Process

Ted Hardie <ted.ietf@gmail.com> Mon, 15 July 2019 14:40 UTC

Return-Path: <ted.ietf@gmail.com>
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 4DD96120168 for <ietf@ietfa.amsl.com>; Mon, 15 Jul 2019 07:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.com
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 JM3_ftMI7XmX for <ietf@ietfa.amsl.com>; Mon, 15 Jul 2019 07:40:20 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 8DCAC12015C for <ietf@ietf.org>; Mon, 15 Jul 2019 07:40:20 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id j6so2159255ioa.5 for <ietf@ietf.org>; Mon, 15 Jul 2019 07:40:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rWehHxDFIUJ8BKCYIr6QRyRbaZl+zAZC1A9u3VCzpDM=; b=iNEhOi8JPCjxhL0lnrMww/bs1oOGE96aSTaSm824RcSOT0E7975156hjcuMxrz4+4z IVWUAB9ZsNMLKRRNglTr23xJmuWWGuEIUhO+vqIGpwpA9J/s8yXzq6rKFW6eyiVQSwcJ GWuy6FplfzX4Vupd5SI/czp/VcLCyze2B2M4Rd8sDrJC/4cGVMTxXClxZVZlreqIBoUQ KsNI5Ig2q47tjw5YQrr5za4BPva446bzuSQAeFzcYHXP25r6q8o1H45XLIDq05AFUVR3 bczco8La07mgGaz7HvWU7poVY6IChSFFxR4Vu21Fkw73AgbCWCP3UsjrAQhAmByd7WxC ApGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rWehHxDFIUJ8BKCYIr6QRyRbaZl+zAZC1A9u3VCzpDM=; b=sIb+xltpjUO4vJ/OjBstSV1s2lU26H2LHd/Va7JTldCNSLzta7U5B/cfVniKSXdSel vFbb9TEjlE/h8d3bIrY4SUpZe7Kuje3Zl77DIfO4YTAhTLPiHu3or2Qx5oAX6ZXnhW88 I5+qkIkmeFkETKlYmcy5cWCLveQA3RQjWDLShxNtMcdoWHBh1VkmasnowrXui1Krj1if lLk8KO37F7wFoQFL0E3T+Kk94qv6ph4kmPTr96owIDypNkYZ4mqSGiCjQdTP7xXJgrH5 yNF9BKrt87oLRvRYgIfDz7sr/BWHcpbcI+C4Xkg6VrA25zOe7DENxPIR7XcS70At4B3S O6EA==
X-Gm-Message-State: APjAAAXRI+N9n8KAmwI2yz9NurxEV7A1u6vByEjqIDE/+jeW8T2xSRX+ H9MUTNLxKcuW6Ui9wyrPEd48wrSisoqSbYySdnxdnw==
X-Google-Smtp-Source: APXvYqyL6J3JDSbgzz7GS/Yxxcdqpa+67phwX6kp/2JyIkTHvr4I4yG/GKPButrlob5E22sqC2auSBepyI4EKfabBmM=
X-Received: by 2002:a5d:8e08:: with SMTP id e8mr26605299iod.139.1563201619727; Mon, 15 Jul 2019 07:40:19 -0700 (PDT)
MIME-Version: 1.0
References: <CA+9kkMALnyeoMJKOgwZ8QP1G+aeSTSBbu4HXAAxdyhcC0K=mDA@mail.gmail.com> <6.2.5.6.2.20190713065007.0c09c018@elandnews.com> <CA+9kkMAbvAdmFAkm5UnsmqWd51KEbFmSE=Jx2pXGUboEm-VYtA@mail.gmail.com> <a9d14442-db99-5907-c422-7d4fc4eebfe4@cs.tcd.ie>
In-Reply-To: <a9d14442-db99-5907-c422-7d4fc4eebfe4@cs.tcd.ie>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 15 Jul 2019 07:39:53 -0700
Message-ID: <CA+9kkMChvw=wvXrsf+G+iVzLN_vc9x9WQuXaZdghF9Zzxr6sEA@mail.gmail.com>
Subject: Re: RSE Bid Process
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: S Moonesamy <sm+ietf@elandsys.com>, rsoc@iab.org, Internet Architecture Board <iab@iab.org>, IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000041a022058db93df5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/DiBNv1c7sMR4iwOcEz_K1YjmnN8>
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, 15 Jul 2019 14:40:22 -0000

Hi Stephen,

A comment on mechanics in-line.

On Sun, Jul 14, 2019 at 12:52 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hi Ted,
>
> On 14/07/2019 20:08, Ted Hardie wrote:
> > A key question now is whether we conduct the hiring
> > according to a slightly modified SOW and have the new incumbent
> participate
> > in the larger discussion or conduct the discussion prior to recruiting a
> > new RSE.  The first strategy seems to be permitted by RFC 6635 under the
> > general rubric of the RSE's role in evolving the series.  The second is
> > also possible, but the result will likely be that there is no overlap
> > between a new incumbent and Heather.
>
> I agree the above is a key question on which we need
> community input in the very near term.
>
> I have a question about the options though, we have
> previously had Olaf take on the role of acting RSE
> (much to his delight wrt the acronym:-). That happened
> in different circumstances, with which I'm not familiar
> (and I suspect I'd mostly prefer to maintain my innocence
> as to those;-).
>
> So I (and I suspect other IETF participants) am unclear
> if we do or do not have a real option to try find a
> member of the community to take on the role of acting
> RSE whilst we do the work on a revision to the RSE model
> (aka a substantive revision of 6635).
>
> If that were an option, then I guess we'd have 3 high
> level options from which to choose - a) appoint a new
> RSE now (which I guess likely has to be the default if
> there's no clear community view about other actions),
> b) make no appointment whilst the community discuss a
> revision to the RSE model, or perhaps, c) try find an
> acting RSE whilst the community discuss revision of the
> RSE model.
>
> I'm not arguing for option (c) above, but just wonder
> if that is or is not a real option.


I think the way to do that would be to have the SOW define what the acting
RSE's role is and then put that SOW out for RFPs.  Those proposals might
well come from community participants whose focus was on facilitation and
consensus in IETF contexts, rather than on publication management.

Part of my reasoning here is that the time to conclude a full community
discussion isn't really clear yet.  If it takes a year, having an interim
RSE with that focus on facilitation may well be the right choice, but it
also may require us to fund the volunteer's effort.

Just my personal opinion,

Ted

I guess the potential
> benefit would be that we'd have time for proper community
> discussion but also have someone to whom e.g. decisions
> about format change details could be directed if a case
> arose that the RFC production centre weren't happy to
> handle themselves. But, there may be downsides to that
> option that I'm not seeing, so I'm not sure.
>
> Cheers,
> S.
>