Re: New proposal/New SOW comment period

Sarah Banks <sbanks@encrypted.net> Fri, 13 September 2019 16:34 UTC

Return-Path: <sbanks@encrypted.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 D5CC9120041 for <ietf@ietfa.amsl.com>; Fri, 13 Sep 2019 09:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=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 EGnOpERDzp3b for <ietf@ietfa.amsl.com>; Fri, 13 Sep 2019 09:34:41 -0700 (PDT)
Received: from aws.hosed.org (aws.hosed.org [50.16.104.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9504120106 for <ietf@ietf.org>; Fri, 13 Sep 2019 09:34:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by aws.hosed.org (Postfix) with ESMTP id 1115F803A6; Fri, 13 Sep 2019 12:34:39 -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 QNfQn26CAH_M; Fri, 13 Sep 2019 12:34:38 -0400 (EDT)
Received: from [10.0.0.69] (c-73-71-250-98.hsd1.ca.comcast.net [73.71.250.98]) by aws.hosed.org (Postfix) with ESMTPSA id 8D608803A3; Fri, 13 Sep 2019 12:34:37 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: New proposal/New SOW comment period
From: Sarah Banks <sbanks@encrypted.net>
In-Reply-To: <394203C8F4EF044AA616736F@PSB>
Date: Fri, 13 Sep 2019 09:34:35 -0700
Cc: IETF <ietf@ietf.org>, iab@iab.org, rfc-interest@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E0AA9720-A0BF-486C-AFD6-0675FDF1D0A3@encrypted.net>
References: <394203C8F4EF044AA616736F@PSB>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4Fg8PCdLnklVeWBEewjXnKHDmYM>
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: Fri, 13 Sep 2019 16:34:48 -0000

Hi John,
	Let me answer inline. SB// with <snips>

> On Sep 13, 2019, at 7:44 AM, John C Klensin <john-ietf@jck.com> wrote:

<snip>

> 
> First I think Mike's "try this" effort to recast the SOW is a
> step in the right direction but skips over, probably wisely, a
> key point.  If the comments and suggestion in this note go
> nowhere, I think his draft is a better starting point than your/
> the RSOC's original proposal.


Speaking for myself, I do not think the SOW as written by Mike holds true for me. You can't beat up the IAB and RSOC for steering the process in some (potential) nefarious way, then effectively do the exact same and ask the community to bless it in the week left of a comment period. The community did not agree at the mic about what to do, or even what we disagreed on as a whole, and so the IAB outlined a plan for giving the community time to do it's thing, but keep docs flowing is something I believe firmly in. With my own community hat on, I WANT that. IMO we clearly need that. And while I haven't yet shared my opinions on what should happen next, cramming it into a weeks review of the SOW is wrong. Sorry. It's very important to me that we agree, or get rough consensus called, and I just don't see how that can happen in a week. I'd argue it already hasn't. We've had a few folks +1 Mike's SOW, but that's hardly indicative of the community as a whole. 


> However,...
> 
> 
> A mistake (or more than one) was made that led to the current
> situation.  You and the RSOC have apologized for your role in
> that mistake and I, and I hope most others, have accepted that
> apology.  The difficulty, which several people tried to get a
> focus on (before IETF 105, at the plenary, and thereafter), was
> the question of whether the RSOC (and, to some extent, the IAB)
> understood (generally and consistent with community
> understanding) the role and function of the RFC Series, the
> relationship of the RSE to that function, the appropriate
> interpretation of "oversight", some important management and
> procurement differences between hiring and management of
> high-level professional and, procurement of easily-substitutable
> commodity items.  One thing that, AFAICT, we haven't seen is an
> analysis by the RSOC and IAB about your assumptions.   Without
> that and especially with a draft SOW that you have described as
> being very close to the ones you've used before, it might be
> reasonable to expect that regardless of what the SOW says, the
> result will be more of the same in terms of issues with
> management, oversight, etc., only with selection of candidates
> who will put up with it.

I accept that this is part of the conversation we need to have. I'm not entirely sure that the RSOC or the IAB has to draft an assessment of our assumptions. I'd have to think about that. I think the community has made assumptions about our assumptions, but either way, I don't know what comes from looking backwards; at first glance, it seems to me that deciding what we want to change, listing those items out, and discussing, seems prudent. Either way, the SOW IMO isn't the place to have that discussion, or make those changes. Keeping things as is, in the process we currently have (roughly), to keep tactical things moving, and then affect change seems to me the fairest way to treat our existing contractors, and address the community's desire for a conversation. That's my personal opinion, I am not speaking for the RSOC.

> 
> To make things more complicated, I think there is a periodic
> lingering suspicion in parts of the community that, after the
> RFC++ BOF in July 2018 and the fairly clear message that any
> such changes were in the province of the RSE, the people who had
> advocated those changes hoped that Heather would swiftly address
> and make them and that, when she didn't, they were happy to see
> her announce her resignation, possibly tried to set up
> circumstances under which should would do so,  and perhaps hoped
> that she could be replaced by someone who would put compliance
> to IAB/IESG wishes ahead of the well-being of the series or
> broader community needs and consensus.   If one starts from that
> rather paranoid view and the explanation about what was
> misunderstood and how the misunderstandings are being corrected
> suggested above is absent, then it is easy to see the current
> proposals as steps in the direction of bringing strategy and
> details for the series under firm IESG/IAB control and a little
> bit short of sincere.
> 

I totally understand where you're coming from, you're not the first person to bring that up. I'll point out that the RSOC did NOT approve that BOF; we were made aware of it pretty much on the eve on it, and the RSOC did not agree to it. I personally did not agree, and perhaps I should have got to the mic and stated so. However, at the time, Heather got to the mic before I even stood up and said a lot of what I would have, far more elegantly. The vast majority of the room agreed, and it was clear the effect was squashed from a community perspective, to me. 

Separately, though, I also understand that part of the issue here is that there's a vein of thought that "she would be replaced by someone who would put compliance to IAB/IESG wishes ahead of the well being of the series..." To me, that's exactly what the community conversations need to cover, as an item on that list I described. If we decide we want fervent independence, then we should say so and agree. But again, the SOW is NOT the place for that conversation today. Being paranoid about it or not, I think we've been incredibly clear in stating that this SOW was about getting someone in to help keep things moving while the larger conversation happened. It's not about some Body at the IETF/IAB/IESG/whatever "stealing" power from the RSE, or diminishing the role, or making it compliant to some group's wishes. I get that we're afraid of that, but frankly, given the hyper sensitive nature of this conversation right now, I don't see how that could happen, short of an outright declaration of a "king", in that one of those bodies TELLS the community that it's going that way. even then, I can't imagine that would be pretty. ;) So i get the fear, I worry about it as an item on the list to discuss in the community discussion, but I'm less worried in the SOW because I feel the community is clearly stating it won't stand for that. For what it's worth, I agree. I personally wouldn't want the SOW being used to cede anything from the RSE role, until the community states it's wishes.

> One of the key results of the above is that, coming out of
> Montreal the IAB and RSOC had a serious credibility problem with
> some portion of the community, I believe a large portion.  Many
> of those who did not agree there was a problem understood that
> others did.   Whether that perception is fair or not is almost
> irrelevant.  It is the perception and the perception is a
> problem for processes involving the RFC Editor function and the
> IETF community generally.

Yup, I hear you, and I agree, I see that too. it's incredibly frustrating, and while I haven't been in the IETF as long as (well, Mike, for example! :)) I've never experienced such a distrust before now. But for me, this is why I'm leaning into the notion of the community discussion. It's the most powerful tool we have to figure out the change, and we've said we want it. So let's have it.

<snip>
> 
> If Heather is not willing or able to do this, then I suggest we
> go the blue ribbon panel route.  I can't think of a better
> mechanism [1] than having the RSOC and IAB appoint that panel,
> but you/they should see the selection of the membership of that
> panel and its balance as an opportunity to restore some
> credibility and no one who has been on either the IAB, IESG,
> IAOC or LLC Board in the last two or three years should be
> allowed to be appointed.   Given his persistent and constructive
> efforts to sort this situation out, I'd be very disappointed if
> Mike St. Johns were not part of it.  That panel would have the
> same responsibilities I'd like to assign to Heather above --
> primarily to manage the process of figuring out how we get out
> of this mess and to fill in on strategy issues if absolutely
> necessary.  To that end, it would be good to have a few people
> on it with a deep understanding of professional publication
> strategy (not to be confused with writing a few documents that
> grew up to be RFCs) and/or long-term intimate involvement with
> RFC Editor strategies and policies.  The RSOC that searched for
> an selected Heather the first time would be a reasonable place
> to start looking for those people.

This sounds like the kind of feedback that should come into the calls that Heather is currently leading. :) Don't get me wrong; I'm not trying to dismiss it or blow it off, but I am trying to be respectful of the process that was outlined and that I believe in, and I don't want to undermine or short circuit the calls that Heather is leading.

> 
> Finally, I strongly suggest that the community not hear that we
> can't do this because the procedures won't allow it.  We need to
> figure out how to make things happen with a maximum of
> credibility and trust from the community.  We have precedent for
> this sort of thing (and of bringing in outsiders to recent
> development who are well-known and trusted in the community in
> the way the POISSON process that led to the current IETF
> procedure stack and in other situations where we would otherwise
> basically be stuck with neither side of an issue trusting the
> other side.   Being told that the procedures prevent us from
> using a creative and credible approach would, in the current
> climate, certainly cause many members of the community that all
> of this is about maintaining or expanding leadership body (or
> personal) control, power, and/or authority.
> 

OK... I hear you, but I'll point out that the RSOC hasn't made any such statements that I can find; we're not saying because of the rules or not. Kick me if I've got that wrong. 

> best,
>   john 
> 
> 
> 
> [1] Well, I can, but I'm not aware of a reliable process for
> consulting Jon Postel, Joyce Reynolds, or Bob Braden.
>