Re: RFC Series Editor Resignation

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 20 June 2019 00:07 UTC

Return-Path: <brian.e.carpenter@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 DA750120497 for <ietf@ietfa.amsl.com>; Wed, 19 Jun 2019 17:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 WF8zLszRdk5T for <ietf@ietfa.amsl.com>; Wed, 19 Jun 2019 17:07:00 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 01AC31204A7 for <ietf@ietf.org>; Wed, 19 Jun 2019 17:07:00 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id y72so537991pgd.8 for <ietf@ietf.org>; Wed, 19 Jun 2019 17:06:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+GZBf0m3xeRi/PyO+Jh9pu9n1WfPniTcpHP3/cfzpD4=; b=kGdrAsrfZo4+X0VRvWY2TKz0GQCpojEQ10JZ4/BMFfgBWcJ+Y1+FB8xwI8k5r6Hnzv E5kZQ4z4gowiqMULCWet4+24/u7kCQ1emzfPZYC+mJ/mCdzSAqhTtQbiPNNovhRgHBmf mDmsbOOUZKCb30G6IB4BaL6ZS85ePiUhyMQC78rK7b6gJL2lpPLMLUdl6X27Ob44rFpc kgjBH9N5c04kQZI1HoWNkpEPDcsS/+aVdMST0XbKxWIUjXauzaPaGvcdd90iVZxDHPu2 b7XxDKssyU/piywBw1+dBBEQtRibtl0mqtI7tSf1mGpU7adtMTDpl/W6IwnUNbn8AYNU y7FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+GZBf0m3xeRi/PyO+Jh9pu9n1WfPniTcpHP3/cfzpD4=; b=g9NquH61cM3pGd/cK/gQvieHKUcZAQQjOR/eMKzHojLmUJFBAf8unEhCeyRh7xTN/W YofG74hbHz/h8zqagJ08sfGGRzcrVxczXtw3tfKvW7IgTJOg2UzpRXOXTrjJCOZrpdof YhletjwUvKxGR47Z/Dyo8JmD/JFAnk3lxVuChbHjIWsdTdpqHJh9fIO00W4nNFaHLzO3 moU+0ARw9AByFA3Qwx6CnqinOVlIYUFWi5RdfuCgSktZSDKYPQoRLBnUL762jpMjBlyQ ddchsRyc83q3/SHKJ7i4rUZFbA+CFY1YQdrN0Yez5epq9eAjMn34WWLm1bNM9v9sB7Y1 Ndgg==
X-Gm-Message-State: APjAAAXngGdJGzqnn+7SgyyEBKcaTrwpA5StSsu1CNoxZKq58YRi3Y8X 0iCEYRzFrg5W12ryew8mSZ5j7ifB
X-Google-Smtp-Source: APXvYqyLSEG87Skho+4jczNDf0xit7Yx93OHQ77N2FhTcNXGJKnxzfuHn/e3rjoe7CQX/IJxk2Dr8Q==
X-Received: by 2002:a17:90a:f488:: with SMTP id bx8mr13891293pjb.91.1560989219050; Wed, 19 Jun 2019 17:06:59 -0700 (PDT)
Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id y22sm39816456pgj.38.2019.06.19.17.06.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jun 2019 17:06:58 -0700 (PDT)
Subject: Re: RFC Series Editor Resignation
To: Michael StJohns <mstjohns@comcast.net>, ietf@ietf.org
References: <685B34F6-E0E2-4050-B9DD-615F475F62B7@encrypted.net> <58D30A55-FB45-476B-997F-1D9D58E89AE0@gmail.com> <A24BDAB9-B118-4A8A-A6DF-D2094ABF3E33@neilson.net.nz> <e4251435-b786-4bb4-0065-c76bc96f1eeb@gmail.com> <989B1B67-78B4-4CF3-BDD7-701F297880D3@neilson.net.nz> <cdcaf342-618a-c148-6864-59b4f8ee7f6b@gmail.com> <f4dd608d-aeb9-84ac-e879-50dc7cac3736@comcast.net>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <7b21af3e-d241-6f79-342b-5065e1c0af6f@gmail.com>
Date: Thu, 20 Jun 2019 12:06:55 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1
MIME-Version: 1.0
In-Reply-To: <f4dd608d-aeb9-84ac-e879-50dc7cac3736@comcast.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/cuJRAVPui6uqLqTrKjCj0ecGOos>
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: Thu, 20 Jun 2019 00:07:02 -0000

Mike,

> I'm unclear why they are making the decision on renewal without 
> community input

I think this is a key issue. I completely agree that the community
should not micro-manage either RSOC or IETF LLC in this matter. However,
community input on how the RFC Series is working and what needs to
be adjusted would be the obligatory first step, IMNSHO.

Regards
   Brian Carpenter

On 20-Jun-19 02:45, Michael StJohns wrote:
> On 6/19/2019 1:24 AM, Brian E Carpenter wrote:
>> They seem to have pre-announced there would be no second renewal. That is not a normal way of doing business, to my mind.
> 
> Especially doing so 2.5 years in advance.   That seems to be a bad 
> business practice to lock yourself (or your successors actually) into a 
> set of actions 2 years into the future.    And seriously, I've done 
> dozens of RFP like actions over the years during my time with the US DOD 
> - there's not a lot of "refining" that needs to be done, or that can't 
> be done during the process of the RFP (clarifications and precisions 
> process).
> 
> Hmm.  What do the LLC minutes say about this?  Where would we look?
> 
> And nominally, the IAB gave themselves oversight over the RFC process 
> with their original charter, but we've since gone through the IAOC and 
> LLC processes.  Given that neither the IAB nor the RSOC is a contracting 
> entity, I'm unclear why they are making the decision on renewal without 
> community input to the LLC?
> 
> Later, Mike
> 
> 
>>
>> Regards
>>     Brian Carpenter
>>
>> On 19-Jun-19 17:19, Alexander Neilson wrote:
>>> Hi Brian
>>>
>>> Just to quibble on one point.
>>>
>>> The term is for two years with two possibly extensions if mutually agreed.
>>>
>>> So in this case it sounds like the intention was signalled to take up one renewal option by one party and the other decided not to take a renewal.
>>>
>>> I don’t think it is any signal of unreliability. The term itself is almost at its conclusion. The contract considered an option to extend which has not been taken up.
>>>
>>> Regards
>>> Alexander
>>>
>>> Alexander Neilson
>>> Neilson Productions Limited
>>> 021 329 681
>>> alexander@neilson.net.nz
>>>
>>>> On 19/06/2019, at 16:46, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>>>
>>>> Well, I'm confused too. It's not as if the house was burning down, except that now it is.
>>>>
>>>> What Sarah's message didn't make quite clear is that the 2021 re-bid would be two years early, given that the full term of the current contract ends 6 years from 1/1/2018. (https://iaoc.ietf.org/documents/RSE-2018-Independent-Contractor-24Oct17-Public.pdf,
>>>> Clause 3 "TERM"). In other words the RSOC and/or IAB had already decided to truncate the contract. This makes us (legally personified as IETF LLC) look like an unreliable business partner.
>>>>
>>>> So what precipitated this disruption? From my point of view, everything was running well, even if occasionally some nominal target numbers were missed; it's great to have a series editor who actually has appropriate professional knowledge and experience, unlike all her predecessors. So the decision to prematurely run a bidding process seems to have been a really bad idea. Something about ain't broke, don't fix. The attempted fix has apparently caused serious breakage. This deserves a transparent explanation to the community.
>>>>
>>>> The phrase "expressly for the purposes of refining our RFP process" literally makes no sense to me as an explanation for breaking off a satisfactory contract. If there's something wrong with our RFP process, we seem to have thrown away almost all the time available to improve it, given that the normal date for the rebid would be sometime in 2023. That seems like the exact opposite of what the community needed from the RSOC and the IAB.
>>>>
>>>> Regards
>>>>    Brian Carpenter
>>>>
>>>>> On 19-Jun-19 15:55, Alexander Neilson wrote:
>>>>> I may be wrong but I read it as meaning a renewal of the current contract to allow time to refine the process and that new process would be the structure the RFP for a new contractor went out under.
>>>>>
>>>>> Regards
>>>>> Alexander
>>>>>
>>>>> Alexander Neilson
>>>>> Neilson Productions Limited
>>>>> 021 329 681
>>>>> alexander@neilson.net.nz <mailto:alexander@neilson.net.nz>
>>>>>
>>>>>> On 19/06/2019, at 14:52, Aaron Falk <aaron.falk@gmail.com <mailto:aaron.falk@gmail.com>> wrote:
>>>>>>
>>>>>> I’m not sure whether my question below should be addressed to the RSOC, IAB, IETF Exec Dir, or IETF LLC, so maybe one of them will enlighten me.
>>>>>>
>>>>>> Regarding
>>>>>>
>>>>>>     Although the RSOC had recommended renewing the RFC Series Editor (RSE) contract for another two years, and then put the contract back out to bid in 2021 expressly for the purposes of refining our RFP process
>>>>>>
>>>>>> I’m wondering what exactly it means to put a contract out to bid “to refine the RFP process”. For example, is someone bidding on the RSE contract supposed to assume they are just providing information and not actually going to be a candidate for the award? (Is that even legal?) Or, should we presume that this is an actual competition for the RSE work? I can’t understand how you can solicit bids for the RSE but say is is just to refine the process. Can someone explain this curious wording?
>>>>>>
>>>>>> If the goal is to replace the current RSE, perhaps someone can explain why.
>>>>>>
>>>>>> --aaron
>>>>>>
> 
> .
>