Re: RFC Series Editor Resignation

Ted Hardie <ted.ietf@gmail.com> Wed, 19 June 2019 15:02 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 8AC8E12071A for <ietf@ietfa.amsl.com>; Wed, 19 Jun 2019 08:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.997 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, HTML_MESSAGE=0.001, 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 vqRCTGJBSJWS for <ietf@ietfa.amsl.com>; Wed, 19 Jun 2019 08:02:31 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 CF18212015B for <ietf@ietf.org>; Wed, 19 Jun 2019 08:02:23 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id s7so38784199iob.11 for <ietf@ietf.org>; Wed, 19 Jun 2019 08:02:23 -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=D/0LshRayeLoSGmH3nIHC/kXPmkSejeoB1WxbFmINos=; b=uDQrw72cukWlM77uTL7HZnQBYY5pUCni3OLqd4/duE5ApX8iwZEIGe2sI0Iqf/HC+U mvRIHv9ZXenIsiP5DTtbWpGGUAl7H1p6VUfTIjMUBA9SgF0KfM7QUBKujGs6Kd07rpo6 YbaNG+Wae9e3KtZYiwVaoURDKmKA0n9U23BWojmHCz1Y5Vr00wIsGBYgsM3sdy3LwbyA +aCxcD5duTt8FlVcmmS0RfEc7fXtIPMxeu+Rnb5djNlBtKd8e5JFKb5WYnDma54OgIlg AOnArBMZCMC5InZuB6nfMJKKAVWizTwNiFyNI3iELqoOy2lcp3Ha0YUQaKMnqKcIsMvP f06g==
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=D/0LshRayeLoSGmH3nIHC/kXPmkSejeoB1WxbFmINos=; b=XH1uWpivamAi4cuiZ30LgIXUvPeE/GD83eX9sUTW7kjK0Oh1z2XqgPR099aIw7OWSG vnzJZBFwBYjr5kbhaGDpzB8IJ8Ej6GESiaPXIE05A3IuCM9kkcFZbWFomCj90qYROPxH zS8GwPy5qO8TH+LY0vUaa3uoPfyDFUrTViItJXrKDYWeC9jyZfS/g3VBHlVk5moMCtwm 5w1oKjv78CELiOldBMR2lqQji1bniv5rImNVkBTePuKe3bQa6iDpZXX7ALNGawHDqz9Y f9IypQ23gYWERA5lyaKQj65synRFMgEGnW0ve0Oza59g5Dm+Y7B8+psjEUnRyUVYT86V GjyQ==
X-Gm-Message-State: APjAAAV9pYIaN4fhCORRzplU+hiyt5qg9ysT8HhnzjOfdlwnYWSmEB6E P4Qr5dFc4pwCtccJgZE4vTiIH01rubsjbhAIZVY=
X-Google-Smtp-Source: APXvYqwFyPuiM1A5slwBla1S1/6xmzFSN930WDDZDOTCqGCIRN1XO2wFPwO85pA07+LP9Uf5gkziNVY58oCCr+AnMwk=
X-Received: by 2002:a6b:e00b:: with SMTP id z11mr225783iog.27.1560956542879; Wed, 19 Jun 2019 08:02:22 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <f4dd608d-aeb9-84ac-e879-50dc7cac3736@comcast.net>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 19 Jun 2019 08:01:52 -0700
Message-ID: <CA+9kkMCoc__uP_W23iMtNZ4LPZSFZ=YK9Pq_vkui6wAucEhj3w@mail.gmail.com>
Subject: Re: RFC Series Editor Resignation
To: Michael StJohns <mstjohns@comcast.net>
Cc: IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003f8dc6058bae84f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/TfnJP6ixC6N6tALXHgGM5iLC8GA>
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 15:02:35 -0000

Hi Mike,


> 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.


The functions of the RSOC are set out here:

https://tools.ietf.org/html/rfc6635#page-14

It normally acts with authority delegated from the IAB.  In the case of
decisions that affect the RSE individually, such as contract extensions, it
recommends action to the IAB.  This language is substantially the same in
the update in preparation:

https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc6635bis/?include_text=1

The difference between the two is that the first describes the relation to
IASA and the second specifies that it be the IETF LLC. In this case, the
recommendation to renew the contract for the next 2-year term and Heather's
announcement to the IAB, RSOC, and LLC that she did not intend to renew
were received on the same day, so none of the rest of that process went
forward.  Instead, the RFP process will go forward, with coordination among
the IAB, RSOC, and LLC and with Heather's assistance.

There were a couple of threads on the IASA2 mailing list on the topic of
the update which you may wish to review.


> 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?
>
>
The only thing that has changed here is that the contracting party moved
from ISOC to the IETF LLC.  The rest of the process, including the role of
the RSOC in making this recommendation is the same.

regards,

Ted Hardie



> 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
> >>>>>
>
>