Re: New proposal/New SOW comment period

Michael StJohns <mstjohns@comcast.net> Mon, 02 September 2019 19:07 UTC

Return-Path: <mstjohns@comcast.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E79120077 for <ietf@ietfa.amsl.com>; Mon, 2 Sep 2019 12:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) 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 AClhtW-fVkvB for <ietf@ietfa.amsl.com>; Mon, 2 Sep 2019 12:07:10 -0700 (PDT)
Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9265B120044 for <ietf@ietf.org>; Mon, 2 Sep 2019 12:07:10 -0700 (PDT)
Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-05v.sys.comcast.net with ESMTP id 4rRciWj14kiHz4rfRiCPiR; Mon, 02 Sep 2019 19:07:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1567451229; bh=c3XyHZ84jwDjAGVjuXjKg57BGbNrTZr/kotUWvz3e9s=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=TCwDn/bbxdwfClV/O45CidAbwpRv2tTs0Iy7xNuCKVj+2HkyUIqSoYOn5MxyknRtN 3usXe39Phgj6PMzw6b9nZbxnjryoAcPcmqGufo5a9wIyXT1/NJ7+E+TadqwE9MfxjM sYIOUxbPpAk4Mji3U3mBp2cxVm3P2olDB2kT91gBZOhHlh+9bximbbqI9D0wJ1qm/o ToUpOfao5S/g7XJfL4Gzce+FodLuT/w1NNtwyxlxNJPR/lAd7IhJ6pRR9lY7JwKYOv xbyJEdGBu6zc1wcF4TzfosNTK9CcQO1XnskHZxVehv4FbfQqMPIkvLn0yiaWrnSBfd kTJzmKFkDw8rQ==
Received: from [IPv6:2601:152:4400:437c:208d:2fda:9bb0:ed54] ([IPv6:2601:152:4400:437c:208d:2fda:9bb0:ed54]) by resomta-po-04v.sys.comcast.net with ESMTPSA id 4rfOitgGN89lp4rfPiNjVc; Mon, 02 Sep 2019 19:07:08 +0000
X-Xfinity-VMeta: sc=-100;st=legit
Subject: Re: New proposal/New SOW comment period
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, 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> <af77339d-6fe2-f08f-10a3-f576729d5921@cs.tcd.ie>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <31b36227-f2e7-dbe9-4010-adf576385227@comcast.net>
Date: Mon, 02 Sep 2019 15:07:06 -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: <af77339d-6fe2-f08f-10a3-f576729d5921@cs.tcd.ie>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/mK5Kx9HP6n-AvwhXvNIMN9vUkLk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 19:07:12 -0000

Hi Stephen -

Sorry for the delay in responding - I've mostly been off line or only 
with an iPad.  Comments in line

On 8/30/2019 2:00 PM, Stephen Farrell wrote:
> Hiya,
>
> Just on two of the more general points; (I'm sure Sarah or
> someone else from RSOC will reply to the SOW specifics)...
>
> On 30/08/2019 18:30, Michael StJohns wrote:
>> 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.
> We had a joint IAB/RSOC call before these mails went out and
> my estimation of that was there everyone who was on that call
> really wanted the community to determine whether or not we
> end up with a more "managed" RSE or a more independent one as
> we have now. From what I've seen and heard, there are people
> with varying opinions on that managed vs. independent continuum
> both within and outside the IETF leadership. So, no, I don't
> think it'd be fair to describe this as "a push towards" more
> managed. (Given the history, I can understand if some people
> have that impression though.)


There's two things going on here - the language of the document 
specifically "matrixed environment with divided authority" and other 
phrases and the specific effect of maintaining a status quo with the 
current oversight regime for another 1.5 to 2.5 years.      I'll 
probably touch upon the first in my response to Sarah's response to me.

I would suggest that we've mostly come to an agreement that the current 
de facto oversight model substantially contributed to the current 
crisis.  Strangely, the words that describe that model haven't changed 
substantively for quite a while - but the people implementing the 
"oversight" portion of the model have.   If I could turn back time, I'd 
move back to the status quo ante just prior to the award of Heather's 
current contract and use that hands-off light touch going forward until 
the community comes to some agreement about changing the 30+ year 
traditions of the RFC Editor independence.  I'm concerned that if we 
just let the current structure stand, that the status quo will be a 
managed RSE and that it will be difficult or impossible to change back.  
I haven't seen any acknowledgement from the IAB as a whole that this is 
even a problem they're considering.

>
>> 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.
> I don't believe we have a clear statement of changes that may
> be desired. Partly, that's I guess because people have different
> opinions as to where it's best to end up. But from chatting
> with people, I do think there seems to be a fairly widespread
> opinion that having the RSE be supposedly responsible for
> day-to-day supervision of the RPC (as is called for in RFC6635)
> isn't a good plan today.

Sure.   And that's yet another thing that's being conflated as being 
tied into the notion of editorial independence when it isn't.  
Strangely, this appeared to work fine for 6+ years with the occasional 
bobble and with understanding on both sides.  I haven't actually seen 
even the beginnings of a proposal as to who should manage this if its 
not the RSE with the possible exception of mumblings that it should fall 
under the IAD.


>   And that opinion seems to be held by
> people from all parts of the managed vs. independent continuum
> mentioned above. So while there isn't afaik anything like a
> complete list of proposed changes, there do seem to be some
> changes that may be uncontroversial and useful. (I'm fairly
> sure there will also be some ideas in this space that will
> be controversial:-)

If you can find me a path to editorial independence, I'll help you find 
a path on fixing what you think might be broken with the RSE/RPC 
relationship.

In fact, the US Government's Contracting Officer vs Contracting 
Officer's Technical Representative (CO vs COTR) may be a decent way to 
structure this.  The contracting entity maintains responsibility for the 
contract as CO, the RSE (as COTR) isn't responsible for the RPC 
contract  day to day performance, but only providing information to the 
CO on how the RPC is doing.   Or better yet co-COTRs in the form of the 
RSE and the ISE.

Later, Mike



>
> Cheers,
> S.