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

Michael StJohns <mstjohns@comcast.net> Thu, 05 September 2019 15:08 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 7643D1208C4 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Thu, 5 Sep 2019 08:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level:
X-Spam-Status: No, score=-4.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, MIME_HTML_MOSTLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=comcast.net
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 QeeZEXAfCGcl for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Thu, 5 Sep 2019 08:08:53 -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 B616E1200F6 for <rfc-interest-archive-eekabaiReiB1@ietf.org>; Thu, 5 Sep 2019 08:08:53 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 3ECFBB81940; Thu, 5 Sep 2019 08:08:31 -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 E6BD1B81903 for <rfc-interest@rfc-editor.org>; Thu, 5 Sep 2019 07:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 fJ986Vuf5oks for <rfc-interest@rfc-editor.org>; Thu, 5 Sep 2019 07:59:29 -0700 (PDT)
Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) by rfc-editor.org (Postfix) with ESMTPS id 17816B81901 for <rfc-interest@rfc-editor.org>; Thu, 5 Sep 2019 07:59:28 -0700 (PDT)
Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id 5t6Kii2gx1Oci5tEhilylv; Thu, 05 Sep 2019 14:59:47 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1567695587; bh=TYztHQsNahzoCM63X8ETRTYwd50kNLUf/u23heaxU8c=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Gba6wMnLLYnPKu14fAkGpdKDK3M/Ahs6ShRZlcbKSekRmDprutAJcyAGsEEdomTx/ /V63fTBeAy37kLtolRtvTxiqQRH5o1WCYARohUmSCUVtOD9uyjiTxBPLPMGzJMoF03 9oFJs90tENmHtFuCmMIBR214ictUIRmUl/KDzzLTGa9A3yi/b/3a+aO96XABoqCM6x RNocWIPS7+qNHwr2vI03Qb+zG1IOIvetFni7pgyiS/xK14hpMVF1wNtK+2jHgPCy4C LTNj86jmAAOpa6lc0VNZTTtscoisyjJTJMDEYWbcs+OZ+u2xLzCA5ompb/GcI5tSyr RgJlB/mp8eMQw==
Received: from [IPv6:2601:152:4400:437c:ed88:5732:4488:cfe8] ([IPv6:2601:152:4400:437c:ed88:5732:4488:cfe8]) by resomta-ch2-05v.sys.comcast.net with ESMTPSA id 5tEdix6fSNCEq5tEei2H0V; Thu, 05 Sep 2019 14:59:46 +0000
X-Xfinity-VMeta: sc=0;st=legit
To: ietf@ietf.org, rfc-interest@rfc-editor.org
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> <00237fc1-e378-322d-87d7-8e6f27907f2a@nthpermutation.com> <887FE348-A7EF-413C-B5F4-5A7910CAE762@encrypted.net>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <68c20034-b6d1-fe3f-ccab-d0be7c5c50c2@comcast.net>
Date: Thu, 05 Sep 2019 10:59:42 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <887FE348-A7EF-413C-B5F4-5A7910CAE762@encrypted.net>
Content-Language: en-US
X-Mailman-Approved-At: Thu, 05 Sep 2019 08:08:29 -0700
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>
Content-Type: multipart/mixed; boundary="===============6551456902753254760=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

Pruning

On 9/3/2019 11:26 PM, Sarah Banks wrote:
> Hi Mike,
> Please see inline.
>
>> On Sep 2, 2019, at 12:24 PM, Michael StJohns <msj@nthpermutation.com 
>> <mailto:msj@nthpermutation.com>> wrote:
>>
>> On 8/30/2019 3:39 PM, Sarah Banks wrote:
>>>

>>>> On Aug 30, 2019, at 10:30 AM, Michael StJohns <mstjohns@comcast.net 
>>>> <mailto:mstjohns@comcast.net>> wrote:
>>>>
>>>> Five immediate large items:
>>>>
>>>>
>>>> 0) The requirements for this position are pretty much 
>>>> indistinguishable from that of the RSE as stated in previous 
>>>> versions of the SOW.   I don't think that makes sense.  If this is 
>>>> simply a "we want to hire some short time to do the RSE position", 
>>>> then state that rather than using the figleaf of strategic and 
>>>> tactical.  I'm not saying you'll get community buy-in for that, but 
>>>> at least it would be less obfuscated.
>>>
>>> SB// The thought here was as intended; specifically on tactical, and 
>>> nothing more. It IS focused on what the current RSE does tactically 
>>> - I'm not sure how we change that until the community has a 
>>> conversation about the role. I'm all ears and open to suggestions, 
>>> though!
>>
>> I don't think you've actually thought through the tactical items well 
>> enough for the community to give you a thumbs up or down.
>>
>> So some additional questions:
>>
>>     a) Does this contract end with the RSE contract is let?
>>
>>
>
> The SOW clearly calls for a firm initial term. I believe I've also 
> followed up since stating there might be overlap. Help me understand 
> where the confusion is here? Have I overlooked something?

If this contract runs concurrently with the RSE, and they are separate 
awards, then either there's duplication of effort, or the RSE role is 
greatly reduced.   If the overlap is only in the form of handover, 
that's useful guidance.


>>     b) Does the RSE regain most of the tactical stuff?
>>
>>
>
> Your question assumes outcome of the community process. I have no idea 
> what that outcome is. This is a TEMPORARY role. There's nothing to 
> "take" away from the next RSE, should we the community choose to 
> continue to have one. I'm being somewhat obtuse on purpose - the SOW 
> is NOT a comment on what happens with the next RSE or the process or 
> any of that - the SOW covers the specific work items laid out, with 
> the ability to adjust them by mutual consent should something arise, 
> and allow RFCs to continue flowing while we, the community, figure out 
> what we want to do.

Fair enough.   But I would hope that the RSOC at least have some idea - 
as the current group of responsible people - as to what outcome makes 
sense for the RSE.  The issues I (and I think others) have had is not so 
much with what the RSE has been doing/is going to be doing, but in the 
management regime to come.   Mostly that won't be reflected in the SOW 
except as side effects for the process changes that happen if a 
temporary position is created (and possibly maintained).


>
>>     c) If so, there's an end product that needs to be requested - the 
>> hand-over documentation.
>>
>>
>
> This might be a reasonable addition to add to the SOW. Let's see what 
> others think.
>
>>     d) Does acting as the tactical person prevent you from bidding on 
>> the RSE?  If not, why not?   [E.g. insider knowledge vs fairness of 
>> the bid process]
>>
> The SOW doesn't take a position on this, and IMHO, that's a good 
> thing. We want the best person for the job. Any incumbent would have 
> "insider knowledge", in that they know how the process works, and are 
> already sitting in the job. I don't think this is our biggest problem 
> to solve, or a huge problem in and of itself. That's my opinion. If 
> the rest of the community feels differently they can say so and we'll 
> discuss.
>
>>     e) Can you think of any of these items to eliminate as "can wait 
>> for an RSE"?  If not, then see my original question (0).
>>
>
> I don't understand what the "items to eliminate" are? The SOW is 
> specific in it's 2 goals, which I've already stated again in this 
> email. They cannot wait, hence the SOW.


Take a look at the deliverables for the RSE SOW that hired Heather, 
compare them to the SOW deliverables in this document. Besides items 
already removed if any, are there any that could absolutely wait for an 
RSE and don't need to provided for before we get a "real" RSE post this 
contract?


>
>>>
>>>> 1) Is this a full time position?  If not, then describe the 
>>>> expected workload.   From the description, its 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.
>>
>>
>> I can't see how this could be let as a firm fixed price contract or 
>> even a piece work or deliverable task contract.  I think this is an 
>> LOE contract with meta deliverables.  You're going to want some of 
>> this persons time to be committed, and you're going to want to tell 
>> them up front what that time commitment is.   I think figuring out 
>> what that LOE is is squarely in the wheelhouse of the SOW authors.
>>
>>
> Your opinion is noted, thank you.

That unfortunately isn't really a useful response.  But let me try this:

You have basically three classes of deliverables:   One-time (or 
one-time with phases - finish the V3 transition for example); recurring 
(e.g. quarterly project reports), and continuous (technical expertise as 
needed, RPC oversight etc).  Only the first two allow for a reasonable 
fixed price bid.  The last one is going to need something like "For 
approx 10 hours a week, plus full time 3 weeks out of each year commit 
to provide technical expertise in the following areas to the extent 
possible for the allotted hours; increases or reductions in negotiated 
time commitments may be made by mutual written consent".


>
> <snip>
>>>
>>> SB// The goal is to have the conversation as a group, and figure out 
>>> what to do. if we don't want a managed RFC Editor, but the 
>>> independent model that folks believe we should have, then as a 
>>> community we should say that, and figure out how to instrument what 
>>> we want. Personally, I like the spirit of what was described to me 
>>> starting with Postel, and having some independence from being told 
>>> what to do blindly with the ability to push back doesn't seem to be 
>>> a bad thing. But that's my personal thought, and as an RSOC it's not 
>>> our current purview to tell the community what to do.
>>
>> I agree, however, the RSOC seems to have taken it as a purview to 
>> diminish the independence of the RSE from previous levels.  If the 
>> RSOC (and for that matter) would take a look at what it was fall of 
>> 2016 vs how its been behaving vis a vis the RSE since that point in 
>> time, I'd be much happier with your statement that you don't tell the 
>> community what to do.
>>
>>
> Mike, what exactly do you want? Honestly, what is it? I believe the 
> RSOC made a mistake. We publicly and very specifically said that we 
> made the mistake, owned it, and apologized. I am incapable of undoing 
> that mistake, it is what it is. That said, I believe the RSOC has been 
> very thoughtful in it's actions since, starting with the feedback 
> we've received, drafting a new SOW, and IMO clearly stating that the 
> SOW is specifically a temporary position that allows us to keep RFC's 
> flowing while the community figures out "what's next". I'm at a loss 
> to understand how we're telling the community what to do.
>
>
What I'm trying to get to is fixing or at least placing a temporary 
patch on the issues with the current oversight model without having to 
wait 2.5 or so years.  I'm mostly ok with the discussions about what the 
RSE is going to be doing, but I'm less sanguine about what the RSOC and 
IAB will be allowed to do without some proposed changes in that 
model.    I don't want to be back here in a year or so with the 
possibility of having the same things go wrong again.   That maybe hard 
for the RSOC to hear, but it is what it is.  What's hard for me to hear 
is the lack of thought about how to mend the current oversight model.



>>> We're trying to strike a balance between the process we have, which 
>>> keeps our contractors moving and documents flowing, and allowing the 
>>> community to do its thing. This position "reporting" to the LLC 
>>> makes little sense to me - 1. that's not the current process we have 
>>> (and if you don't like it, speak up and change it, Ted's outlined 
>>> how we might proceed to doing that) and 2. The LLC really isn't 
>>> equipped to handle it either.
>>
>> See my note to Stephen.  Basically, I think it may be OK to have the 
>> RSOC operate as a COTR under the purview of the LLC with no ability 
>> to tell the RSE what to do, but instead acts as an advisor to the LLC 
>> for contract issues.  That gives whoever gets hired one and only one 
>> point of control to deal with.   I'd also suggest that the RSOC no 
>> longer do the "we're talking about contracts in executive session" 
>> stuff and instead call for community input every couple of years or 
>> so and write a public report detailing pros and cons based on that 
>> input (and specifically no anonymous input) as the basis for the LLC 
>> to make its decisions.  6635 is not controlling on the LLC as they 
>> are the fiduciaries - but the community might not like that 
>> interpretation.  They could adopt 6635 as an operating instruction by 
>> vote of the board, but I don't see that as having taken place.
>>
>>
>
> That's your point of view, *a* point of view, and I think it's 
> reasonable for this to be a part of the conversation that we have as a 
> community to decide how we want things to change. If we agree as a 
> community on it then I suppose bigger changes are coming. But I'll 
> point out that it's outside the purview of this SOW.

And a large part of the problem I'm concerned about.


>
>>> The RSOC seems to be the reasonable choice given the situation we 
>>> find ourselves in, and again, this is a 1.5 year contract with 
>>> clearly described goals.
>>
>> "clearly described goals" is overstating it I would say.  Sorry.
>>
>> Mike
>>
>>
> There's a saying I have on my team - don't come to me with problems, 
> come with solutions. It's perfectly acceptable to not agree with what 
> I said, If you feel it's not "clearly described goals" then please, 
> propose text for the rest of us to review and agree upon that leaves 
> you comfortable with the goals being clearly stated. I'm happy to help 
> review.

I actually have proposed an approach to fix the oversight problem.  The 
rest of this - well - the SOW is only part of what you need here, the 
other is the plan and contingencies.  I think we're getting some of 
those edges discussed, but the SOW shouldn't be what drives the plan, 
but the plan being what drives the SOW. I think the current SOW has too 
much in it for the stated purpose of "temporary and tactical" and I 
alluded to that above.  It's difficult to provide text if I don't 
understand the hard edges of what you want to accomplish - hence the 
various questions above.

Later, Mike





>
> Thanks,
> Sarah
>
>>
>>> We'll have the conversation to change (or not) - in the grand scheme 
>>> of things, this doesn't seem to be an issue to me. The alternatives 
>>> concern me more - do we just not have an RSE-like function at all, 
>>> in any capacity, being executed, while we chat as a group? No 
>>> documents are published? We're paying for the RPC function by 
>>> contract now; I'd like to see our money well spent, personally. I'm 
>>> not sure I understand the analogy to a penalty box, but if you mean 
>>> we're in a holding pattern until we figure out what we want then 
>>> yes, I totally agree, we are, and I don't see a better alternative. 
>>> I'm happy to discuss any alternatives you might have.
>>>
>>> /S
>>>
>>>
>>>> Later, Mike
>>>>
>>>>
>>>>
>>>> On 8/30/2019 12:38 PM, Sarah Banks wrote:
>>>>> (Cross-post with rfc-interest@ietf.org <mailto:rfc-interest@ietf.org>)
>>>>>
>>>>> Hello,
>>>>> The RSOC has received a lot of feedback regarding the current SOW, 
>>>>> in addition to the feedback received generally around the RSE 
>>>>> role, both on and off list, and at the microphone at the plenary 
>>>>> session in Montreal. We've listened, discussed, and come up with a 
>>>>> proposal that you'll find attached here.
>>>>> Broadly speaking, the RSE role contains 2  functions, a strategic 
>>>>> function and a tactical function. We believe that we, as a 
>>>>> community, still want RFCs published while we discuss the RSE role 
>>>>> evolution. We also have a contract in place with the RPC (both 
>>>>> Production Center and Publisher), both of whom are accustomed to a 
>>>>> day to day contact to lean on for assistance (the current RSE).
>>>>> With that in mind, we are proposing a temporary position that 
>>>>> focuses on the tactical components of the current RSE role, with 2 
>>>>> large work items in mind.
>>>>>
>>>>> First, this temporary position (called the Temporary RFC Series 
>>>>> Project Manager) would serve as the day to day contact for the 
>>>>> RPC, assisting with tactical items.
>>>>>
>>>>> Second, this role would focus on the v3 format work, assisting 
>>>>> with the delivery of the new tools for the format work, and 
>>>>> bringing the new format work to a close.
>>>>>
>>>>> Details are included within the SOW, attached with this email.
>>>>>
>>>>> The IAB plans on sharing a follow up email shortly, that covers 
>>>>> possible next steps for the strategic portions of the RSE role and 
>>>>> the evolution discussion.
>>>>>
>>>>> We'd like to open a 2 week comment period on the SOW, starting on 
>>>>> August 30, 2019, closing ons on September 14, 2019. Please send 
>>>>> your comments and feedback to the RSOC (rsoc@iab.org 
>>>>> <mailto:rsoc@iab.org>).
>>>>>
>>>>> Kind regards,
>>>>> Sarah Banks
>>>>> For the RSOC
>>>>>
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> rfc-interest mailing list
>>> rfc-interest@rfc-editor.org
>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>>
>>
>

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