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

Michael StJohns <msj@nthpermutation.com> Mon, 02 September 2019 19:24 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 9122B1201AA for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Mon, 2 Sep 2019 12:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.651
X-Spam-Level:
X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=nthpermutation-com.20150623.gappssmtp.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 jqXrfBhMMUiF for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Mon, 2 Sep 2019 12:24:42 -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 A9017120096 for <rfc-interest-archive-eekabaiReiB1@ietf.org>; Mon, 2 Sep 2019 12:24:42 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 869A5B80C77; Mon, 2 Sep 2019 12:24:22 -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 837DCB80C77 for <rfc-interest@rfc-editor.org>; Mon, 2 Sep 2019 12:24:21 -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=nthpermutation-com.20150623.gappssmtp.com
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 RzW8XECDm8nr for <rfc-interest@rfc-editor.org>; Mon, 2 Sep 2019 12:24:18 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by rfc-editor.org (Postfix) with ESMTPS id 8EBFAB80C76 for <rfc-interest@rfc-editor.org>; Mon, 2 Sep 2019 12:24:18 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id g17so13381899qkk.8 for <rfc-interest@rfc-editor.org>; Mon, 02 Sep 2019 12:24:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=0Mu+uk8wMpCJxZwlaV70Es7DvZkvhOmvjjrRmpAhIlI=; b=ATjl/zvmwUe8WznEwdjHU2A6bRlrpCf8HIwrO/DemZXjQGLmXqU/pkcGUNe3jCjmXC zf360OUAYC+raE6BzC1Nd6gInEHaw53WuMxX/ozjBvXjg/SOlVVUb4AC2H3j3TIbfdAG Bj343n9YDdNylVAQQytOQPw2dsa6s9rSGpmB+TvFJwkpSeElNo20kRcanfeW3IuTzXR2 3dJryIctNQZjtluwntd4+j4pIP8sgqw203BhdKIISat4hyRPgyHK4MtbPd3sGBE31q9B zb5SAVJKYfy+uxd2B/SH9uzhNsCzPqkXByQNwI2agwxaj0EQjOR1S/2gi1i6aSiCI/U8 8kEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=0Mu+uk8wMpCJxZwlaV70Es7DvZkvhOmvjjrRmpAhIlI=; b=GkLvnNqcEGrktRDmKYJZba8Z757nDG2rAxt4lxxXfDpS6/LB72DoxLhj0eCdhFfEQj +7arHYPKJ4Eb5cEfqFeN10RoopDArlpY7R8Ew4JwaFamUabXHpCaAUEM4ldOneOAb/dN 1q5gll4isgUTzJd6UtG1FuMqzBnRR72MPUxvAztlaeVJKEpacyCK83EUtU2T3wjqlV5u 1XZv9+VtYA49RcwcKZYTP2go11ucWDuM7xm+HKKdh9+dqGBgX4/Xu6PLkJjWBsn8CT0m +EoBTq7cdn0yHY2MoICbA65jctY8HJZFKYjO2RVWmCs78ukyXpTcdiFVI8K3gvquCBLS lWpQ==
X-Gm-Message-State: APjAAAXXAdVLaIpcHHUTHJjKG3ls3c1IUi2R5LGPtAaknaYjV6zB8Oue 2q5NrOZV5XX+qbCMnArArcA0VA==
X-Google-Smtp-Source: APXvYqwygSxDvFWhgvfvomTnVCvqYcnWmFA1Gwd+HQY9Zmsadbr5Wd030D/3f0qZXQkinDC58QrKRQ==
X-Received: by 2002:ae9:ee1a:: with SMTP id i26mr3362350qkg.112.1567452276528; Mon, 02 Sep 2019 12:24:36 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:437c:208d:2fda:9bb0:ed54? ([2601:152:4400:437c:208d:2fda:9bb0:ed54]) by smtp.gmail.com with ESMTPSA id i20sm6828850qkk.67.2019.09.02.12.24.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Sep 2019 12:24:35 -0700 (PDT)
To: rfc-interest@rfc-editor.org, ietf@ietf.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>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <00237fc1-e378-322d-87d7-8e6f27907f2a@nthpermutation.com>
Date: Mon, 02 Sep 2019 15:24:34 -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: <D7B6334A-A4EF-4386-905F-86C187E22899@encrypted.net>
Content-Language: en-US
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="===============8635581256093564229=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

On 8/30/2019 3:39 PM, Sarah Banks wrote:
> Hi Mike,
> Some thoughts, inline. Speaking for myself. SB//


Not really.  Seriously - you're the author of the SOW with the RSOC so 
this is direct commentary on your work product.

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

     b) Does the RSE regain most of the tactical stuff?

     c) If so, there's an end product that needs to be requested - the 
hand-over documentation.

     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]

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

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


>
>> 2) The style manual (last bullet) is a strategic item, not a tactical 
>> item. Delete it.
>
> SB// I could live with this, thanks.
>
>> 3)  Matrix management - seriously?   That's how we got to this 
>> situation in the first place.
>
> SB// We understand that's a concern, and it should probably be one of 
> the items we discuss as a community. We're not looking to force the 
> process though, and to that end, using the process we have (this 
> language came from the previous SOW we used, in fact) seemed prudent. 
> Given that they're focused on the RPC and the new format work and 
> reporting to the RSOC, how else would you propose we address your concern?
>
>> 4) Term - for a tactical contract, this is pretty long - 1.5 years 
>> with the possibility of a year extension.
>
> SB// As I previously explained, we as a community don't tend to have 
> short conversations. The process will take time. If we conclude in 
> less than 1.5 years then fantastic, we'll have some overlap with 
> whatever outcome we get from that discussion and the current/temporary 
> RFC Series Project Manager. That seems like an acceptable thing to me.
>
>>
>> Small items:
>> 1) Drop the "Experience as an RFC editor" bullet in favor of 
>> "Familiarity with the RFC series is desired but not required".
>> 2) The "culture and process" bullet is also strategic and not 
>> tactical.   Drop this to just the RFC process.
>> 3) Travel internationally - state if this is in addition to the IETF 
>> meetings.
>>
>
> SB// These seem reasonable.
>
>> Overall comment:
>>
>> This has the feel to me of a push towards a more "managed" RFC Editor 
>> vs the independent model we've had over the lifetime of the series - 
>> and doing it by small nibbles and by delay.  The RFC++ bof indicated 
>> community displeasure with that direction, and I'm not sure this SOW 
>> is representative of community desires. I'd be happier with this if 
>> the sole and only contract reporting link is from this contractor to 
>> the LLC.  The LLC MAY appoint the RSOC for day to day things, but any 
>> contractual discussions OF ANY KIND should be with the actual 
>> organization that holds the contract.   From a community point of 
>> view, we have oversight and a direct line of responsibility from the 
>> LLC to the community (with the concomitant ability of the community 
>> to recall or otherwise fail to reappoint LLC board members) . That is 
>> not the case with the RSOC.
>>
>> With respect to the evolution of the RFC Series - I haven't seen any 
>> clear statement from anyone of the changes they believe need to be 
>> made.  So, prior to putting us in the penalty box for a year and a 
>> half, perhaps we could actually get a statement of interests which 
>> would indicate that we need such a delay in the RFC SE selection 
>> process.    E.g. a full formal ID/RFC not random musings in email 
>> with enough initial support that we have the possibility of getting 
>> to some sort of consensus for change if we invest the time.
>>
>
> 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.


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


> 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



> 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