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

Sarah Banks <sbanks@encrypted.net> Wed, 11 September 2019 00:34 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 46D8D12007A for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Tue, 10 Sep 2019 17:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.199
X-Spam-Level:
X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 Ifqog03tPOY8 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Tue, 10 Sep 2019 17:34:28 -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 349A2120013 for <rfc-interest-archive-eekabaiReiB1@ietf.org>; Tue, 10 Sep 2019 17:34:28 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 46EC0B800B4; Tue, 10 Sep 2019 17:34:25 -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 D82DAB800B4 for <rfc-interest@rfc-editor.org>; Tue, 10 Sep 2019 17:34:23 -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 g0_p3p7OHq2R for <rfc-interest@rfc-editor.org>; Tue, 10 Sep 2019 17:34:22 -0700 (PDT)
Received: from aws.hosed.org (aws.hosed.org [50.16.104.137]) by rfc-editor.org (Postfix) with ESMTPS id 0D659B800AE for <rfc-interest@rfc-editor.org>; Tue, 10 Sep 2019 17:34:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by aws.hosed.org (Postfix) with ESMTP id 3B79980093 for <rfc-interest@rfc-editor.org>; Tue, 10 Sep 2019 20:34:23 -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 bvOH2R89pOsx for <rfc-interest@rfc-editor.org>; Tue, 10 Sep 2019 20:34:23 -0400 (EDT)
Received: from [192.168.1.81] (corelight.static.monkeybrains.net [208.90.215.182]) by aws.hosed.org (Postfix) with ESMTPSA id E52FB8007D for <rfc-interest@rfc-editor.org>; Tue, 10 Sep 2019 20:34:22 -0400 (EDT)
From: Sarah Banks <sbanks@encrypted.net>
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 10 Sep 2019 17:34:21 -0700
References: <ec715385-93ca-ddf0-f9b1-d0e4ae1666fe@nthpermutation.com> <CAL02cgTqDTXgG1bU1DGBkdQ7XwV=2ryJzQU1QD8yNba-7ngk3A@mail.gmail.com> <74d83952-940b-6c3d-4f73-482ec31083c9@comcast.net>
To: RFC Interest <rfc-interest@rfc-editor.org>
In-Reply-To: <74d83952-940b-6c3d-4f73-482ec31083c9@comcast.net>
Message-Id: <BDB4FF6F-C8D4-450D-BC33-8F11E06ADAE0@encrypted.net>
X-Mailer: Apple Mail (2.3445.104.11)
Subject: Re: [rfc-i] Try this: was Re: 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

Folks,
	Rather than reply to each thread, let me try to clarify.

What we were trying to do:
====================
	The new SOW was proposed as a way to "keep the RFCs flowing", during a time where we have another contractor (2, actually, for the RPC functions) who today, rely on the ability to lean on the RSE (Heather) for any issues that arise. We pay for that function. Separately, we also seem to loosely agree that the new format work and tools need to be seen through delivery. The SOW was written with those 2 goals in mind, and an attempt to add language to say "look, something small might arise here or there and we want the process of "discussing it and mutually agreeing to take it on or not" to apply". 


What we were trying expressly to avoid doing:
====================
	We wanted to avoid any text that would lead folks to think the RSOC was steering the conversation. We do not want to do that, and we were extra sensitive to the feedback coming in.
	We also wanted to reuse the previous SOW, since the community had already seen it, thinking that it would be easier for us to use an SOW that the community had already approved, and this too would lessen the concern that "the RSOC is steering the conversation". It's slightly ironic that this is exactly what it seems to HAVE done, for some folks. Let me be clear; that is NOT the intent here. Roughly speaking, I don't think anyone on the RSOC is married to the "the candidate must have previous draft authoring experience" or some such. It's easy enough to add or remove from the qualifications list. I believe we should do that, still.
	We used the term "temporary RFC Series Project Manager" specifically so the words "RSE" or "interim RSE" or some variation of that would be avoided. This was expressly done to again, avoid the notion that the RSOC was steering the RSE role in some way, adding or removing some sort of "power" or authority to the role, etc etc. Again, I'm not sure the RSOC Is married to WHAT the role is called, but more so that if we agree with what Heather proposed on stage, that we need someone to help with the tactical aspects of her role while the rest is figured out, then the SOW should cover those tactical items, provide some sanity to the insanity so that we get bids, and we move on.
	Last, I think the RSOC believes in the approach that was laid out; we wanted to keep documents moving while the community chats. The SOW was NOT intended to be the "and here's what we think stunk about RFC6635, so we'll change the text in this SOW!". That approach specifically steers the conversation into a POV that I believe we don't have consensus on. Should we discuss it? Absolutely! Is the SOW the appropriate place, given the approach the RSOC was attempting to conform to? Absolutely not. (Speaking for myself, with the community member hat on). 

---

Speaking mostly for myself here:
	I look forward to the meetings that Heather has set up, and I look forward to hearing what folks want and don't want. I do not support cramming that discussion into an SOW that has a 2 week comment period on it (well, with new text, I don't know, does that mean a new period started? I think it's moot - I'm happy to be proven wrong, but i've not seen us move as a community on something so contentious in a short period of time). i DO support having the meetings that Heather, the current RSE (not the RSOC, not the IAB, not anyone else we've had a problem with) is leading - and I  sincerely hope we find a constructive way to communicate. 

	RFC6635: I think we are wildly out of process; there's no RFC that covers the scenario where "the RSE isn't renewing, but the community doesn't want to go through the process described in RFC6635 again". So what do you do? The proposal at hand was to take Heather's proposal from the plenary at IETF105 and implement that via the second SOW the RSOC shared, and then begin the community discussion and answer some of the harder questions in those first sets of meetings, or figure out how we would get to an answer, at least. The first is based on the proposal from the RSE herself (although she's free to let the RSOC know if we misunderstood her). The second is wholly centered on community conversation and discussion. yes, we're out of process, but in that sense I feel the spirit of the IETF is to, when we disagree or want to evolve, then we talk, figure it out, come to (rough) consensus (or running code!) and evolve. So for the most part, RFC6635 doesn't apply here in the evolution sense
 , but in the short term, keeping the "reporting structure" and the process for amending goals on a list to me, make sense to keep as is, since we understand them. those constructs from RFC6635 do make sense to me. We may not like them, but we (as a community) understand them. The RSOC and IAB are bodies in place to help with that, and there's been a huge effort to be very transparent with the community in light of the mistakes we've made. Is it the end of the world if the interim project manager (or whatever we call them) "reports" to the RSOC, particularly given the limited scope of work and the contract that allows for 1 extension in an extraordinary case? It seems to me that this is on the low end of the list of things we should be spending our time on, in light of the larger evolution discussion. 

	I hope this helps. 

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