Re: RSE Bid Process

Ted Hardie <ted.ietf@gmail.com> Mon, 08 July 2019 16:54 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 D6EBF120323 for <ietf@ietfa.amsl.com>; Mon, 8 Jul 2019 09:54:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.692
X-Spam-Level:
X-Spam-Status: No, score=-0.692 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 cL1rwKwm7SUf for <ietf@ietfa.amsl.com>; Mon, 8 Jul 2019 09:54:56 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 36EF212032C for <ietf@ietf.org>; Mon, 8 Jul 2019 09:53:34 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id q22so15000580iog.4 for <ietf@ietf.org>; Mon, 08 Jul 2019 09:53:34 -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=AnsmIK6ZFi4w7FU+2qYBYSi9AcnE5MceQOJEIbnwcWc=; b=sQbSohIndOwwJBOFchS9HxVadx7StXyQ82yeBITpdUytpNG5IFe2VrJ+2i1K8h0X+B a7Q28OwWD0FPjpLowSZgqmQpMnQ6XLf+Ymy88n6Mr3/VyzRpHo7csc8onuQyxMHHCNV/ 7o8QAs80+pCakrwJqM5Ko4sfZI+K10QREO+XIlF0sCiz+WDUZN4FpS24omBLJwakzP2e uFY0+/MKcHwQTieR4vR/6OXeN+Oub5Yv0hXENC32fQOaefhqnIkAe2s5EGapcrC14/cK phY30T5IIHCuTWLZuCj2xCuUzE56WzpswRz7VVnjUcvdjBf/NKuNoYxencwqTlYlfHC4 yTNg==
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=AnsmIK6ZFi4w7FU+2qYBYSi9AcnE5MceQOJEIbnwcWc=; b=piCIDvBwUe7k+lTDWybXdUNFbmmFJwNOjoR4uRsrKNb1Y/tCA/+Sl0an73x/k4mWZg WYo9DiLrHDDb683QP3kYisX0vXPFG/0Mmgo5wVI69QbusaStCZES8fFWvD7h4c8cqyDE VaPJB8dnQTuaHfHfj5A6fneXV57L1I08wfQamYNGOHkZ7p367FCqwrr8VVNw/Qtf8cZ4 hkIqr5XD6gCleeJpskoSee7rJYprhGAhE5tu9fJt5+VaO3J8qu5GUWDa58irvFy2AIQu uScCA0PxyDaztIV8YeG2CipBY6KhcYqhbHDQg0DTvGF1Sgn29+htCp3TnT1oaplmOVxY THfA==
X-Gm-Message-State: APjAAAV3iQLZulfreEYfpPIY2quFfP6jsYIjFnmrtIXajVnXqsJcf4Vx QA1IZk5NRGIX/1fEqyLqpL9xFDWSFeCjGwA2g4Y=
X-Google-Smtp-Source: APXvYqz31SWGoMxWuM+j1JZ70DwFCqlixUISm1KbwVY1Q73Y7705J3MzWS0/DsrvYYryMEe2EYWc4x39V9YMu4zBQ7k=
X-Received: by 2002:a6b:5f01:: with SMTP id t1mr14397974iob.219.1562604813233; Mon, 08 Jul 2019 09:53:33 -0700 (PDT)
MIME-Version: 1.0
References: <CA+9kkMALnyeoMJKOgwZ8QP1G+aeSTSBbu4HXAAxdyhcC0K=mDA@mail.gmail.com> <a5357fbc-ebf5-e148-c88d-f7803cdbcc9b@comcast.net>
In-Reply-To: <a5357fbc-ebf5-e148-c88d-f7803cdbcc9b@comcast.net>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 08 Jul 2019 09:53:06 -0700
Message-ID: <CA+9kkMCHfQ3pjVH17yYQpwVgB+U6ig+0DZptap-C4_oJ7SqyWg@mail.gmail.com>
Subject: Re: RSE Bid Process
To: Michael StJohns <mstjohns@comcast.net>
Cc: IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d13afb058d2e4838"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/uGaeBjO5ikh7H4Sa3OVuGoPUlCw>
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, 08 Jul 2019 16:55:08 -0000

Hi Mike,

Apologies for the delay in replying; I was off for the July 4th long
weekend.  Some thoughts in-line.

On Thu, Jul 4, 2019 at 6:12 AM Michael StJohns <mstjohns@comcast.net> wrote:

> Top posting and in line:
>
> Hi Ted -
>
> Thanks for this outline.  However, I'm not sure that going forward with
> the RFP before fixing the structural issues with the relationships between
> the IAB, RSOC, RSE and LLC makes sense.  Patrick's note is on point.
> Unfortunately, figuring out how to fix those relationships,and getting
> agreement is probably not possible in the next 2-3 months.
>

If the community prefers adjusting RFC 6635 before re-running the bid
process, that's probably possible, but we will likely lose the transition
period between Heather and the new RSE as a result.  That's a pretty
important trade-off, and one I'd want folks to discuss.

Given the small size of the community of editor/publishers we are going to
> try and draw from and our current missteps, my estimation is that we're
> unlikely to get more than one bid if that, and that any contract terms
> we're offered by a given bidder are going to be much tighter and much more
> restrictive on things like IAB/RSOC "management" and "oversight".   There's
> going to want to be more assurance by the bidders that independent
> contractor means "independent".  I would also expect that bidders will want
> more assurances against arbitrary termination of the contract.
>
> Considering all of the above, let me make an alternate proposal.  First
> that we ask back the previous RSOC in place of the current group and ask
> them to serve until we resolve the issues with the various relationships
> (e.g. the next publication of 6635 as a community - not IAB - document).
> We give them the responsibility for running the bid process and for the
> ultimate selection of the final candidate with the advice and agreement of
> the LLC.
>

As my note pointed out, 3 of the 4 current members of the RSOC were serving
before the refresh, with tenure up to 5 years.  So "asking back" the
previous RSOC would continue to include them.  That seems to limit, in my
eyes, the impact of this change.

Further, I'm not sure that the precedent this would set is in line with the
preferences expressed in RFC 6635 or your note.  Until there is an
adjustment of the process, the only way to change the RSOC membership is
for the IAB to do it.  This would establish as precedent that the IAB could
dismiss the sitting RSOC as a body if it did not like the outcome of their
work.  There's a great deal of both text and established practice that
makes the IAB hands-off to the work of the RSOC, and this would seem to run
directly against that intent.

As an additional point, you use the term above "arbitrary termination".  I
hope you understand that termination was not invoked here.  The contract
does include provisions for termination with a much shorter notice, and it
includes provisions for not renewing the contract.  The RSOC's
recommendation to the IAB was for renewal of the contract for the available
term.  I've discussed in other messages how that intent likely went astray
because the message included other elements, but the upshot is that she was
not terminated.  The portion of the process that completed was a
recommendation that her contract be renewed.  She has decided not to take
up a renewal.  As noted elsewhere in this message, we regret that, but we
also need to be clear it was not a termination.


> We use the existing SOW to the greatest extent possible.  We mostly
> divorce the IAB from the RSOC/RSE until the relationship issues are
> resolved - note that may require a contract modification with the RSE at
> some point.
>
>
The previous RSOC does have experience with this bidding process which
> should mitigate some possible time sinks in getting up to speed.
>
> As Heather pointed out some time ago, the previous bidding process
resulted in a single bid, by the incumbent.  Relying on re-running that
same process may not be the best strategy.


> More inline - applies even if we don't take the above suggestion.
>
> On 7/3/2019 3:02 PM, Ted Hardie wrote:
>
> As folks are aware, there is ongoing discussion on Heather’s decision not
> to continue as RFC Series Editor (RSE) and about how the situation has been
> handled. Firstly, we’d like to express our regret at how things have
> transpired and our willingness to have an open discussion with the
> community about where we can all best go from here. This mail sets out our
> view of how recent events unfolded, and our understanding of the process
> for finding the next RSE.
>
>
> The RSE currently has a two year contract which began in 2018 and which
> permitted two extensions of up to two years each.  As part of their duties
> under RFC 6635, the RFC Series Oversight Committee (RSOC) reviewed the
> contract in May of this year.  On June 6th, they notified Heather Flanagan,
> the current RSE, that they would recommend the contract be extended for two
> years.  At the same time, they noted an intent to prepare a Request for
> Proposals during that two year period, in order to address some concerns
> that were raised about response rates after the last bid process.
> Immediately afterwards, the RSOC notified the IAB both of their
> recommendation to renew the contract in 2020 and their intent to prepare an
> RFP for 2022.
>
> Initial discussions within the IAB would normally have been held at the
> following IAB meeting, on June 10th.   On June 7th, however, the RSE
> notified the IAB, the IETF LLC Board, and RSOC that she did not intend to
> renew the contract.  The IAB is grateful that she provided early notice and
> that she has agreed during the remaining months of the existing contract to
> help the RSOC and IETF community to consider the requirements needed for
> the next RFC Series Editor.
>
> Discussions on the requirements are ongoing on the IETF list.  While we
> expect additional community discussions of future processes or models, we
> also want to take advantage of the time Heather’s courtesy provided as best
> we can.  As a result, we believe we should begin the RFP process as set out
> in RFC 6635 now, with an aim to getting an RSE and a contract in place with
> sufficient transition time.  Since the last running of this process, the
> IAOC has concluded and the IETF LLC taken shape, so we wanted to lay out to
> the community our understanding of that process with the IETF LLC in
> place.  As with other aspects of the IAOC to LLC transition, the RSOC and
> IAB will aim for minimal change to the current process, and zero unexpected
> changes. That would give the following steps:
>
>
> 0) The RSOC prepares a short paper on how a succession plan for the RFC
> editor might work, and how recruiting in this space might work.   That
> paper needs to cover what happens if the RFP fails to receive even one
> bidder.
>
>
> 1) The RSOC prepares a statement of work based on RFC 6635 and previous
> RFPs <https://iaoc.ietf.org/documents/RSE-RFP-4August2017.pdf>.
>
> 2) The RSOC sends the SOW out for public comment.
>
> If IAB members, the IAB, or the IETF LLC board have comments, they occur
> during this period.  There is no separate review for them.
>
> 3) After the RSOC finalizes the SOW, it notifies the IAB, which requests
> the IETF LLC issue an RFP.
>
> Instead, the RSOC provides the SOW to the LLC which turns it over to the
> lawyers.
>
>
> I believe this is functionally the same, since the IAB does not approve
the SOW, simply forwards it.


> Note: this is not an approval step, just the mechanics of who has the
> token to turn this crank.
>
> 4) The RFP is issued by the IETF LLC.
>
> 5) The RSOC, or a committee formed from within the RSOC, reviews the
> proposals and interviews candidates.  Depending on the number of candidates
> this could involve steps for creating a short list before running
> interviews.
>
> This is the one that bothers me the most.  Given the missteps its unclear
> this is the right group of people to be picking the next RSE.  Instead,
> pick a search committee (as described I think in the previous SOW),
> consisting of folks that have at least a little knowledge in the
> publication/editing space.  These don't actually need to be IETF
> participants especially if the SOW is tightly written.
>

I believe you're right that this could be a search committee formed by the
RSOC, rather than totally within it. As an example, the RSOC could decide
that it needs to use a search firm to reach appropriate candidates.  Under
the current process, however, step 6 remains the same:  the RSOC must make
the recommendation.

>
>
> 6) The RSOC recommends an appointment to the IAB.
>
> 7) The IAB approves the appointment, subject to contracting.
>
> Here's another possible issue.  It's unclear that the community and the
> IAB/RSOC are aligned with what they want as an RFC editor.    I'm not sure
> that will matter in the end especially if we get only one or two bidders.
>
I believe the IAB and RSOC are both following these discussion closely and
I am sure that we will continue to get more input from the community in the
form of comments on the SOW.


>
>
> 8) The IETF LLC negotiates a contract with the appointed RSE.
>
> 9) After timing is agreed, the new RSE is announced and a transition
> begins.
>
> Once again, we regret how things have transpired and will be engaging with
> the community on the longer term handling of how the IAB, RSE and IETF
> relate to one another. That may include a new version of RFC 6635.  Until
> those conclude, however, we believe we need to move forward with the
> current process. As part of that, we want to confirm with the community our
> understanding of the process required under the existing model and
> procedures.
>
> If you have comments on this point, please send them by replying to this
> mail or to iab@iab.org and rsoc@iab.org.  Note that both lists include
> the current RSE as a member.  If you have comments on the SOW, e.g., on
> appropriate length or renewal intervals, please send them to RSOC after the
> SOW has been published for community review. For comments on the broader
> situation, the ietf@ietf.org list is, as always, available.
>
> As an immediate structural change, we need either the IAB or the RSOC, not
> both, to have their fingers in the RSE pie.   If that's the RSOC, then it
> should probably be selected by the community, not by the IAB.
>
> As I noted above, the RSOC generally operates independently of the IAB.
The current documents call out specific times when the IAB must approve the
actions of the RSOC, particularly this:

For all decisions that affect the RSE individually (e.g., hiring and
firing), the RSOC prepares recommendations for the IAB, but the final
decision is the responsibility of the IAB.  For instance the RSOC
would do the following:

   o  perform annual reviews of the RSE and report the result of these
      reviews to the IAB.

   o  manage RSE candidate selection and advise the IAB on candidate
      appointment (in other words, select the RSE subject to IAB
      approval).

The IAB treats these approvals as it does confirmations of the IESG slate
for NomCom appointments.  We don't re-run the process, we confirm that the
process ran as described.

regards,

Ted

> Later, Mike
>
>
>
> Regards,
>
> Ted Hardie
>
> for the IAB
>
>
>
>