Re: "Early rebid" (was Re: letters from Ted & Alissa)

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 03 July 2019 22:27 UTC

Return-Path: <jmh@joelhalpern.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 AAE7D12067E for <ietf@ietfa.amsl.com>; Wed, 3 Jul 2019 15:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 L60PwUeyyL81 for <ietf@ietfa.amsl.com>; Wed, 3 Jul 2019 15:27:24 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4A1120671 for <ietf@ietf.org>; Wed, 3 Jul 2019 15:27:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45fG240gnBz17JYn; Wed, 3 Jul 2019 15:27:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1562192844; bh=PYlr/y4YHF8pI4Q/nMmkXjKaAwMUH45AJ56HCgzMsjE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Vh64HMnIwZUzS9PQwFhrAfEuKhs9+CYVRjUzgmtSLV4DcgeLVKwMW3whAyqm050Tx 6RTph99o3P8UknPX9sXgRWgZRr8+03SyGNx+lo1cH0zPgmXTTCyV76NQpY8eH11vyi ApGRcPURv98AQXntuP5X6FtTpHQiwNUgeTWnehjE=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45fG233DTdz17JYc; Wed, 3 Jul 2019 15:27:23 -0700 (PDT)
Subject: Re: "Early rebid" (was Re: letters from Ted & Alissa)
To: Andrew Sullivan <ajs@anvilwalrusden.com>, ietf@ietf.org
References: <CA+9kkMCi=h1W15T-rt3MAu3NHBYdEaycUPw4XhRDBVNL4k_Xrg@mail.gmail.com> <BB4BA38F-B384-46A3-866C-4A61F4C7C681@sobco.com> <20190703221444.fvweit2qwmo5u4jp@mx4.yitter.info>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <af4ec42e-6da5-cc58-2c53-2d0674a39c97@joelhalpern.com>
Date: Wed, 03 Jul 2019 18:27:22 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <20190703221444.fvweit2qwmo5u4jp@mx4.yitter.info>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/xOFHPxco8ykHREoO9yhHDH4roco>
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, 03 Jul 2019 22:27:34 -0000

The aspect of this that I found confusing, and that I suspect others 
found even worse, is the claim that the RSOC decided to recommend a 
rebid two years early as a means to address the low response to the last 
bid.

I am sorry, but having been involved in the bidding processes,that 
response seems a very confusing response to the problem.

When presented with an explanation that one is not able to understand, 
it seems fairly natural for all parties receiving the message to 
speculate that something different was meant.

Yours,
Joel

On 7/3/19 6:14 PM, Andrew Sullivan wrote:
> Hi,
> 
> As usual, I'm employed by ISOC but not speaking for it.
> 
> On Wed, Jul 03, 2019 at 03:32:44PM -0400, Scott O. Bradner wrote:
>>
>> 1/ why did the RSOC decide to a/ rebid the RSE contract 2 years early & b/ decide to tell the world about it a further
>>      2 years earlier
> 
> Of all the things that I have found puzzling in this discussion, the
> persistence of this description is the one I find strangest.
> 
> First, as I understand it, the RSOC is not in a position to "decide"
> anything.  In any case, the discussion around IASA 2 made it pretty
> clear that there were many moving parts in the RSE relationship, and
> that it was going to need to get straightened out.  In such a context,
> it is not surprising that we'd expect a revised structure and,
> therefore, a revised basis for the contractual arrangement once that
> revision was developed.  Yet it is not developed _yet_.
> 
> Now, speaking as someone who has a contract that might or might not be
> renewed in 2 years' time, I find it _extremely helpful_ to know about
> that possibility.  It's an elementary part of good planning to know
> when contract events are likely to happen.
> 
> So, without any special knowledge and just relying on what is public
> and what I know of other discussions around the IETF (again, from
> public lists), it seems to me that the RSOC made the only plausible
> recommendation under the circumstances: renew the contract now, for a
> 2 year term.  But moreover, in the interests of transparency, make
> sure that everyone understands that there probably will be some new
> working basis in a couple years, and that a re-bid would be
> appropriate then.  That doesn't make this "early" or a "termination"
> or anything like that.  It's just standard good-will practice.  (Also,
> given all the accusations of lack of transparency, I find it somewhat
> ironic that one main problem was a surfeit of transparency.)
> 
> Now, of course, I don't know what was on the mind of the RSOC, and I
> think it would be an exceptionally bad precedent for us to start
> discussing these sorts of issues on a public list or with anyone not
> involved in the contractual chain.  But it seems to me the entire story
> is possibly explained in an utterly ordinary way, and that one main
> lesson is that complex supervisory arrangements lead to convoluted
> communications paths that increase the chances of misunderstanding.
> 
> Best regards,
> 
> A
>