Re: RFC Series Editor Resignation

Richard Barnes <rlb@ipv.sx> Wed, 19 June 2019 18:49 UTC

Return-Path: <rlb@ipv.sx>
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 A5833120047 for <ietf@ietfa.amsl.com>; Wed, 19 Jun 2019 11:49:54 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 OnTgSkiQPcIN for <ietf@ietfa.amsl.com>; Wed, 19 Jun 2019 11:49:51 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 41798120963 for <ietf@ietf.org>; Wed, 19 Jun 2019 11:49:35 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id i4so116763otk.0 for <ietf@ietf.org>; Wed, 19 Jun 2019 11:49:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EN8vBKPl7rGeLnDiA5Rn5Y877Z+78XwP/kKV6bGCWCY=; b=jekVlK28g1PuJmygbOuRS4OgjCuwbyZMr7ruFOwHYX09dbYE2qKU24rZBi/qjKTjut dcWyQa9hwlpFEd8mfgFGX3oC3TI5Bl38ghhTV4TON1O7vgFcodTGN/n86wmyH2nOniCU X2tiVT8flI0ISdCfyy13pIbhRr355kKhHdvP1wqb8uvueL4/DXXlzAPhZpX2EQOkJ3tT O65yy+4d25Q7AJvtbte0YZaXcmXerDxGWUlyidU9Il7fdVFmkAcuwbvcwm4i7+2Sxp0p LMDaudkHA10WMHt1ud4+R9vlkOBg9Zg1ERsXOV/9hYaIKN2Z6HLNHd2pYOGfMM/EUDQe QMRg==
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=EN8vBKPl7rGeLnDiA5Rn5Y877Z+78XwP/kKV6bGCWCY=; b=ZNLkeC3kQQpwCU2dFkISannvSDHSku7QUulTdMOq4h5f6xBK7yJ+iNKfI04H0Ud/L0 AbOkXe/cV+v2mh8nV+AN5qtdHLTDxVPuaTbXPAnxa3cC44NFsQvp8+HW+DisB2G95McV JCXfLnOzzXTmvjIivHZF8R6mnu9hVC6VLnvihmG0ujNfcS7FAZSPlYM8h0YGiClkX75W LVW893YHb9cfFDPcMNrej5TGJUsXD0jbMF2LjpHk88uksgNUHBbZyYWPzV9tJfH7D3MQ Bf+ffp5kn8Ic8aE4NLRjAjOOQPeXDTgOCh0J9KQfy5fTwq9i/+ZOhekPalwiyxZMDQz0 2ybg==
X-Gm-Message-State: APjAAAWi4zAUnHJmfNzniBwgGzKcaVaAlIFmcRekzsiVGqD0lrJdokry anolQg0lu44ODBmrocfCyyjBqLOK8cMbdBBkYZEQaJ4EDeFaOg==
X-Google-Smtp-Source: APXvYqzwlbJmN+cqp9cz6BMMSiq8F6SWKOXxNYCYKeI8ctzu7Dh9IotogElRbbKA8pm+v9LZG6uaxm8UDo4qZAALNQI=
X-Received: by 2002:a05:6830:1596:: with SMTP id i22mr1115901otr.93.1560970174297; Wed, 19 Jun 2019 11:49:34 -0700 (PDT)
MIME-Version: 1.0
References: <685B34F6-E0E2-4050-B9DD-615F475F62B7@encrypted.net> <e9d747d0-a708-7bfa-f090-d0454344e782@levkowetz.com> <cc4c0ed5-dd1b-9eda-a294-e8e7c53ccb09@gmail.com> <AF9E74FB410E2F020188A5B9@PSB> <851A68D3-1C1B-494E-BFE4-41A036171976@fugue.com> <1715AC0F-F3D9-4FFA-A0A0-BFDF54EA8EB2@comcast.net> <CAL02cgSbFO29vdGsmPJguM5gboFTvZycKKF+YvOweKHTFmP3Vw@mail.gmail.com> <b2108726-83f9-0ae6-3058-b03c85d1b30c@comcast.net>
In-Reply-To: <b2108726-83f9-0ae6-3058-b03c85d1b30c@comcast.net>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 19 Jun 2019 11:49:07 -0700
Message-ID: <CAL02cgQfajMUttC45049wSA6dGKP4ZAOQmbiGJRzdoSfyrFghw@mail.gmail.com>
Subject: Re: RFC Series Editor Resignation
To: Michael StJohns <mstjohns@comcast.net>
Cc: Ted Lemon <mellon@fugue.com>, John C Klensin <john-ietf@jck.com>, IETF Discussion <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000be8db4058bb1b089"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7-VB4VXtsLFWHpirP6zXsvtvo8w>
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: Wed, 19 Jun 2019 18:49:55 -0000

On Wed, Jun 19, 2019 at 11:34 AM Michael StJohns <mstjohns@comcast.net>
wrote:

> On 6/19/2019 12:27 PM, Richard Barnes wrote:
>
> Preparing for a re-bid after the first extension doesn't necessarily mean
> that the second extension won't be exercised.  Plans are just plans and
> circumstances could change.
>
> I don't think that passes the smell test.
>
> Announcing a plan to re-bid at least 18 months and maybe more like 24
> months ahead of a re-bid beginning suggests to me that the exercise of the
> second extension would only happen if the re-bid didn't result in viable
> offers - including any other offers from the incumbent possibly bidding
> against themselves.
>
Lot of assumptions in here.  "Suggests to me" doesn't mean "necessarily
follows".


>
> I think we both have to drink.  ☕️☕️
>
> No - I don't think so.
>
> "Every time you post you have to drink a shot. "

☕️🐝

--RLB

While its possible a later IAB or RSOC could change the conditions, I think
> what I said is a good representation of current reality.
>
> Later, Mike
>
>
>
> --Richard
>
>
> On Wed, Jun 19, 2019 at 9:19 AM Mike StJohns <mstjohns@comcast.net> wrote:
>
>> Tell me if I have to drink.  The current contract was for 2 years with
>> the possibility of 2 2year extensions for a possible total of 6 years.  The
>> contract started 1 Jan 2018 making the initial end date 31 Dec 2019.   From
>> what Sarah’s note said, the IAB and RSOC decided to exercise the first
>> extension option which if accepted would place the contract end at 31 Dec
>> 2021 (2.5 years from now).  The IAB RSOC at the same time is indicated that
>> they would never exercise the second extension, instead indicating they
>> would put the RSE back out for a new contract with an award date by 1Jan
>> 2022.
>>
>> Did I miss anything or does Sarah’s note allow for a different set of
>> conclusions?
>>
>> Mike
>>
>>
>>
>> Sent from my iPad
>>
>> > On Jun 19, 2019, at 11:55, Ted Lemon <mellon@fugue.com> wrote:
>> >
>> > The amount of speculation going on here is impressive. FWIW, my main
>> reaction to this is that I’m really sorry to hear that Heather is going.
>> She’s been wonderful.
>> >
>> > I don’t know if there is any debugging required here, but I do know
>> that no part of the debugging process can happen on this mailing list. I
>> won’t ask you to stop, because you won’t.
>> >
>> > So perhaps we can have a drinking game. One shot of espresso every time
>> someone speculates wildly. Two shots every time someone gets the length of
>> the term wrong. Every time you post you have to drink a shot.
>> >
>> > Sent from my iPhone
>> >
>> >> On Jun 19, 2019, at 11:47 AM, John C Klensin <john-ietf@jck.com>
>> wrote:
>> >>
>> >> Stewart,
>> >>
>> >> I disagree, but only partially.   I think there are actually at
>> >> least three or four separate questions involved with this.  One
>> >> is a strategy question or set of them having to do with how the
>> >> RFC Editor Function is managed and overseen.  Questions of
>> >> contract lengths, who has responsibility for what, and even the
>> >> question the Mike St Johns raised about whether, with the IASA
>> >> and then IASA2 transitions and other changes, the IAB's having
>> >> exclusive control is still right for the community are all part
>> >> of that.  So are other questions, e.g., whether,  there should
>> >> be people on the RSOC who are selected by the Nomcom for those
>> >> roles or appointed by other community bodies.   Those are issues
>> >> that affect the whole community (including many
>> >> none-participants in the IETF) and should be about to be
>> >> discussed broadly.   If a public discussion of them is not
>> >> possible, I think we are in very big trouble indeed.
>> >>
>> >> Second, there are questions surrounding whether some of the
>> >> decisions that seem to have been made here --notably taking an
>> >> action that would have a high likelihood of constraining options
>> >> 2.5 years out--  represent good business and/or management
>> >> practices.  With one exception that I trust is not the case and
>> >> that would raise other issues, I cannot imagine why the
>> >> community should not be able to discuss whether or not the
>> >> process of overseeing the RSE (and the RFC Editor Function
>> >> generally) is applying good practices.   If Heather was not
>> >> consulted (I don't think we know whether she was or not and she
>> >> is certainly not the person who should be obligated to tell us)
>> >> before the decision was made about the tradeoffs involved, how
>> >> difficult she thought it would be a find a replacement, etc.,
>> >> that is, to me, another management process issue for which there
>> >> should be some accountability. (I know such a conversation might
>> >> have been awkward but, noting that the nomcom handles equally
>> >> awkward conversations every year, if we cannot have expectations
>> >> about Heather's professionalism and that of the RSOC that are at
>> >> least that high, we are in big trobule.) If none of that can
>> >> discussed in public, then, AFAICT, we are essentially deciding
>> >> that the RSOC (or the RSOC and the IAB together) are not
>> >> accountable to the community around issues that clearly involve
>> >> management decisions and not just handing out architectural
>> >> advice.
>> >>
>> >> Third, there is the question of Heather's performance. Taking an
>> >> action that, at least IMO, would have a high likelihood of
>> >> resulting in her saying "I don't need any more of this" (even
>> >> from someone of Heather's normal cheery temperament, especially
>> >> as compared to the hotheads among us) and doing so without
>> >> community input, even if that input had been requested to be
>> >> sent to the RSOC rather than this list, seems inappropriate ...
>> >> or is part of the management and accountability issues mentioned
>> >> above.
>> >>
>> >> None of the above interacts with the details of particular
>> >> contracts with individuals, cost negotiations, etc., which
>> >> should clearly not be on this list.
>> >>
>> >> best,
>> >> john
>> >>
>> >>
>> >> --On Wednesday, June 19, 2019 15:26 +0100 Stewart Bryant
>> >> <stewart.bryant@gmail.com> wrote:
>> >>
>> >>> I really do not think that this is a discussion that should
>> >>> take place in a public forum like this.
>> >>>
>> >>> There is much that both parties may legitimately wish to keep
>> >>> private in situations such as this.
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>