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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 04 September 2019 09:44 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 836C0120154 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Wed, 4 Sep 2019 02:44:30 -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 e2OaSc5mTdCA for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Wed, 4 Sep 2019 02:44:27 -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 59ABC12012E for <rfc-interest-archive-eekabaiReiB1@ietf.org>; Wed, 4 Sep 2019 02:44:27 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id D5BB2B81628; Wed, 4 Sep 2019 02:44:05 -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 07F93B81628 for <rfc-interest@rfc-editor.org>; Wed, 4 Sep 2019 02:44:05 -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 TYBMmIY3rff6 for <rfc-interest@rfc-editor.org>; Wed, 4 Sep 2019 02:44:03 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) by rfc-editor.org (Postfix) with ESMTPS id AE8DBB81622 for <rfc-interest@rfc-editor.org>; Wed, 4 Sep 2019 02:44:01 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x849iDo9005352; Wed, 4 Sep 2019 10:44:13 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 228222203A; Wed, 4 Sep 2019 10:44:13 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 0CC7C2203C; Wed, 4 Sep 2019 10:44:13 +0100 (BST)
Received: from LAPTOPK7AS653V ([87.112.72.158]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x849iB9s028113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Sep 2019 10:44:12 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Sarah Banks' <sbanks@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> <B14DFF42-329F-4C28-AEAC-4341FC5F017B@encrypted.net>
In-Reply-To: <B14DFF42-329F-4C28-AEAC-4341FC5F017B@encrypted.net>
Date: Wed, 04 Sep 2019 10:44:11 +0100
Organization: Old Dog Consulting
Message-ID: <022e01d56305$4ef541e0$ecdfc5a0$@olddog.co.uk>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGsushDW8gItDub86UsVZI7yC67IQE4O6sDAmBqyoACUpD9PwFlrbMDAZfbD8anJUc3AA==
Content-Language: en-gb
X-Originating-IP: 87.112.72.158
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24888.004
X-TM-AS-Result: No--25.509-10.0-31-10
X-imss-scan-details: No--25.509-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24888.004
X-TMASE-Result: 10--25.508900-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbPVY7U3NX8JgUb4EdIZGxuBOXU0CDd0Z2zNJ 2Fm2+AZY+W2Elaj143M9I8d2kuBzgAFNY6wiZ1ytzniFfjFXqM59iuvWn3J8Kmer6T5jkOGAC9N uajObRozaag0AZVfuYn1Ytz+8MLs4yd8NxrYcZrotMfCdg6KRDThmPJtp4dD4WQebWE0X5fe9BL +PM5ENQYHliHKudQixVTIYInsIf6ePFdCcbjpd4rIGMNfiwa5NWhHxYAqJnY8KfrbmG+DbUJWPo qpksMPkbvIwdXXymn0bF43Mnf7jg4xx6d6X8tJ6IAjxomarSPDmFBK+rKfiis1YMD+2TGH/tvXm w3PKzzUi1A633Jwmhu5K44vj1mdyjGnLhQ6Goqv0VCHd+VQiHsnlJe2gk8vIFujNgNeS9UDiUzz eiDbY2MI/FhxPhkNxlc3H6Y3cojU+oSWIq9TCHFkxnoxnQfVSgKPajiZ8Y8B7W0KiNth4nhCyTC gSkaG3plIsrmSq4cyyTCgaD8JxPE6GAy2sNm/CPi8EpSRPxOpc1jwHBugxQKdYwGmPHf2WOx0Jl WGEpNcwSJCWRFBkHf6rZvx7wgsjOqtHDb5JdoqwWQIt56582xiDIOPlOJG1ZM8mRTAYb3sCZ1jW tmbQSB1WigGIlA+QjYApe+rzzWQEaNToh7sIavHZUkQO7eCAbeKZ3oUEnvnwbz6yTEjhRwrT8FV iqKl5ZC9jj0mvYvetfav2HJYxBhNvZFqzbongxuvd33/I/WSMeFePU0tuMDT4nNGHFYDrMMfGev mkG3AIXnco/OJf/h5Qg6f5t0Ot1Tgjmrrd06GeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1d934/rDAK3zUc1+O1X9AzE=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
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>
Reply-To: adrian@olddog.co.uk
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>

Thanks for your reply, Sarah, and I appreciate you can't commit to any changes without first chatting with the rest of the RSOC.

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

I believe that would be very helpful, yes.  Even if it as vague as:
The RSOC imagines that this job will average at around xx hours per week between IETF meetings, and be nearly full time during IETF meetings. We expect, however, that the contractor will be flexible in their use of time to handle peeks and troughs in the work load.

However, I do also think that some assistance in describing the tasks is needed. Either you must give more detail in the SoW or you must offer to provide more details on request. Recall that people bidding for this work may not have immediate and in-depth knowledge of the day-to-day work of the RSE.

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

No, I understand that at the moment the best you can say is "added to the list of things RSOC needs to discuss."

You (collective, RSOC) may still want to highlight that the objective is to fill the tactical not strategic parts of the total RSE roll, and I understand that. But be clear that not everyone has the same view of tactics and strategy, and that could result in confusion or even conflict down the road. Better just to set out what tasks you want done and (by omission) what tasks you don't want done.

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

😊 But SoWs lead to contracts. I have seen a few in my time, and it is interesting what customers expect.

> We would mutually adjust, if need be. We can certainly discuss the language you've
> proposed, thank you for providing an alternative.

You're welcome. Words are cheap.

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

OK

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

Sure, details of termination go in the contract.
But if surely changes how a contractor quotes if they know it is for a guaranteed block of 18 months, or that it can be terminated, without cause, on 30 day notice.
So something should be written unless you want to attract higher and more cautious bids.

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

I understand the motivation, but am concerned about the impact of a transfer of management relationship since the manager and point of contact has a significant impact on the work that has to be done and the working environment. It's a relatively short term contract, so perhaps that is not too bad. But viewed from the other side, there are some concerns expressed in the community that having the RSE (or part of the function) report to different parts of the IETF would be problematic.

I think you can do one of two things depending on how likely you think such a change is.
- If you think it is likely to change, replace "RSOC" in the SoW with some term such as
  "Work Manager", and state that the initial Work Manager will be RSOC, but that the 
  LLC reserves the right to change this. But I would probably expect "mutual agreement"
  in this case.
- If you think it is not very likely to change, just don't even talk about it in the SoW because it
  falls into the usual contract "special cases" clauses.

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

OK. Will be interesting to see how that pans out.

Best,
Adrian

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