Re: [rfc-i] New proposal/New SOW comment period

Sarah Banks <sbanks@encrypted.net> Wed, 04 September 2019 03:43 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E948C1200CD for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Tue, 3 Sep 2019 20:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.951
X-Spam-Level:
X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ytQb_SYF8cXn for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Tue, 3 Sep 2019 20:43:48 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E38120072 for <rfc-interest-archive-eekabaiReiB1@ietf.org>; Tue, 3 Sep 2019 20:43:48 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 937A1B816A1; Tue, 3 Sep 2019 20:43:27 -0700 (PDT)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 9D121B816A1 for <rfc-interest@rfc-editor.org>; Tue, 3 Sep 2019 20:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B2ZLN_VaxlJ for <rfc-interest@rfc-editor.org>; Tue, 3 Sep 2019 20:43:25 -0700 (PDT)
Received: from aws.hosed.org (aws.hosed.org [50.16.104.137]) by rfc-editor.org (Postfix) with ESMTPS id 10E71B816A0 for <rfc-interest@rfc-editor.org>; Tue, 3 Sep 2019 20:43:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by aws.hosed.org (Postfix) with ESMTP id AEB4280094; Tue, 3 Sep 2019 23:43:44 -0400 (EDT)
X-Virus-Scanned: Debian amavisd-new at aws.hosed.org
Received: from aws.hosed.org ([127.0.0.1]) by localhost (aws.hosed.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1NnU0nE62hu; Tue, 3 Sep 2019 23:43:44 -0400 (EDT)
Received: from [172.16.12.109] (c-73-71-250-98.hsd1.ca.comcast.net [73.71.250.98]) by aws.hosed.org (Postfix) with ESMTPSA id 38BF68007D; Tue, 3 Sep 2019 23:43:44 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sarah Banks <sbanks@encrypted.net>
In-Reply-To: <04ce01d55fe7$6c428300$44c78900$@olddog.co.uk>
Date: Tue, 03 Sep 2019 20:43:42 -0700
Message-Id: <B14DFF42-329F-4C28-AEAC-4341FC5F017B@encrypted.net>
References: <061D2F46-71C3-4260-B203-73B07EB59418@encrypted.net> <5B276430-96A9-44EA-929B-B9C2325AFCA5@encrypted.net> <f9be9982-56f5-bdcc-3b09-13080532ffc5@comcast.net> <D7B6334A-A4EF-4386-905F-86C187E22899@encrypted.net> <04ce01d55fe7$6c428300$44c78900$@olddog.co.uk>
To: Adrian Farrel <adrian@olddog.co.uk>
X-Mailer: Apple Mail (2.3445.104.11)
Subject: Re: [rfc-i] New proposal/New SOW comment period
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Cc: rfc-interest@rfc-editor.org, IETF <ietf@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

Hi Adrian,
	Please see inline.

> On Aug 31, 2019, at 3:32 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 
> Hi Sarah,
> 
> [Deliberately continuing the discussion cross-posted despite the Sergeant At Arms’ entreaties]
> 
> Thanks for coordinating the construction of this draft and for putting it out for comment.
> 
> In the ensuing discussions…
> 
>>> 1) Is this a full time position?  If not, then describe the expected 
>>> workload.   From the description, it's a level of effort contract
>>> somewhat less than full time.  State that level.
>> 
>> SB// The RSOC in years past has specifically stayed out of the "how
>> long does it take to do the job" and the "this is a 32-hour-a-week"
>> job. I'd defer this to the LLC; if the person they're hiring is a contractor
>> I'm not sure this matters, since they're bidding on the total amount of
>> work (that's been the thought) versus the employee who clearly needs
>> to understand if this is a part time or full time job. 
> 
> When people bid fixed-pay fixed-deliverables on a contract, they usually have a pretty detailed description of the work, that way they can work out how much time they think it will take them, and bid accordingly. If such detail is not available, a wise contractor will make an estimate and add a lot of contingency. That puts up the price paid by the customer, potentially unnecessarily. OTOH, an unwise or "keen" contractor may under-bid risking that a poor job will be delivered. Frankly, the more detail supplied, the more accurate the bid and the better the work.
> 
> Alternatively, the customer may give better guidance as to the expected amount of work. The draft says that RFC 6635 section 2.15 is not applicable, and (of course) that is true because this SoW does not cover all of the job described in the RFC. But at the same time, it should be clear to everyone that if 6635 considered that the job was 20 hours per week and nearly full time during IETF week, then the work covered by this SoW is bounded by that as an upper limit.
> 
> Anyway, I don't think the current draft has enough detail of what the job is to enable a meaningful bid. Maybe this is fixed by simply adding something to say that during the process of preparing bids and on request, the RSOC will make available to bidders additional information to help them scope and understand the nature of the tasks.
> 

I think what I'm hearing you say is that providing some sort of time bound would help here. Point taken, thank you.

> 
> Further to the tactical/strategic discussions on the list, I don't think it is helpful to show your thought processes in the SoW. I would suggest:
> - Strike "The RSE’s job functions can be logically split into 2 functional areas: strategic and tactical." 
> - Replace "is being created to fill the tactical functions of the RSE role" with "is being created to fill certain functions of the RSE role as listed below"
> - Strike "These “tactical” responsibilities of the RSE are not defined explicitly in RFC6635; the expected nature of the work is explained below."
> Doing this would allow you to make the list of tasks you want done, without getting into discussion of whether they are 73% tactical and 27% strategic.
> 
> 

Thank you for your feedback, we will discuss. I realize that sounds canned, but it's so true. :)

> I struggle with the following paragraph:
>   Some of the functions described below may not be possible within that timeframe
>  (for example, chairing the search committee when the RPC contract goes out to bid
>  again). It is expected that this position and the person filling it will work with the
>  RSOC to identify new or changing work items as they arise.
> 
> To me this reads as though you want the contractor to be very flexible on deliverables. Firstly you are giving permission for the contractor to not deliver some things: I guess that's OK, no one will object to being paid for not delivering 😊 Second, you might be saying that new/changed deliverables may arise, but you are not making it clear whether you expect them to be delivered under the contract or not. The usual way to handle both of these points is "variations by mutual agreement in writing."
> 

Yup, that's exactly what we're saying. Some of what we know we want we've clearly stated; some of the rest we don't know, so we're giving a heads up. Any changes to deliverables would happen the same way we do it today with Heather; we discuss as a team, and agree or disagree as a team. We cannot simply add something to the list without the contractors buy in; that's crazy talk. We would mutually adjust, if need be. We can certainly discuss the language you've proposed, thank you for providing an alternative.

> 
> Why "Scope of work - primary"? Is there a secondary scope of work somewhere?
> 
> 

You know, I can't really answer that, other than to say "this is the SOW we've used for 2 bidding processes, and to minimize churn, my thought was specifically to keep things as status quo as we could." If the major concern here is calling it "scope of work - primary" we can certainly refine this :)

> I would expect to see a termination clause.
> 

The SOW is NOT the contract. I would expect the termination clause there for all the regular HR-ish reasons that lawyers put in there. I'll defer this to the LLC and confirm that's there; if not, then I agree, we'll have to agree on where to put it and if it's the SOW, then so be it, and draft the language. 

> 
> The line "This relationship is subject to later reorganization" should be business as usual in a contract like this, but the history suggests that it might be better to be a bit clearer. Just as a point of note, the previous paragraph names the RSOC as the body with whom scope changes might be identified, but (presumably) if the reporting changed, that wouldn't be true.
> 

Feel free to suggest text that might make it clearer. I'm not sure I can do better than this. We don't know what we don't know and to your point, they might not report to the RSOC (although I expect this interim contractor probably would, and the new RSE would be where the change starts, but that's for us to all discuss). Even if it did though, I'd argue that "the relationship is subject to later reorg" covers this. If not, what do you propose to say instead?

> 
> Finally (you'll be glad to hear), what is the purpose of item 3 on the Affidavit? Is the intention here that you propose that only entities registered in the US for tax purposes may win this contract?

Nope, that's never been the case before, I'd expect it to not be now, either. We'll review. 

> 
> Good luck!
> Adrian

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest