Re: New proposal/New SOW comment period

John C Klensin <john-ietf@jck.com> Fri, 13 September 2019 14:44 UTC

Return-Path: <john-ietf@jck.com>
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 1FE8312088C; Fri, 13 Sep 2019 07:44:57 -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_HELO_NONE=0.001, SPF_NONE=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 JJS7FJG3ms8G; Fri, 13 Sep 2019 07:44:54 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9823D120868; Fri, 13 Sep 2019 07:44:54 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1i8mod-0006av-Tq; Fri, 13 Sep 2019 10:44:51 -0400
Date: Fri, 13 Sep 2019 10:44:46 -0400
From: John C Klensin <john-ietf@jck.com>
To: Sarah Banks <sbanks@encrypted.net>, IETF <ietf@ietf.org>, iab@iab.org
cc: rfc-interest@rfc-editor.org
Subject: Re: New proposal/New SOW comment period
Message-ID: <394203C8F4EF044AA616736F@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/bBVsQtV_jS4Ag06DoOBszua4oWE>
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 14:44:57 -0000

Sarah,

I have tried, not completely successfully, to follow the
discussion since this note was posted, probably not completely
successfully. I've tried several times to draft notes analyzing
the situation, but the have all come out long enough that I was
concerned that few people would read them and few of those who
did would pay attention.  Because I've not run out of time, I
want to summarize what I believe are key points, most of which
appear to have received almost no discussion, and then make a
suggestion.  It is longer than I'd like but, with apologies to
Niklaus Wirth, I don't have time to make it much shorter.

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.

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.

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.

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.

Then this round of discussions and proposals started.  It
started with the decision to temporarily split the RSE role into
two separate jobs and and job descriptions and then to assign
the planning, discussion, and selection processes to different
bodies.   Those both may be reasonable things to do, but they
has downsides as well up advantages, especially if members of
the community are concerned that the process is being selected
to control outcomes.  But those splitting and assignment
decisions -- decisions that may be the most important of the lot
in terms of long-term effects -- were, AFAICT, made without an
serious and well-publicized attempt to consult the community.
At least for some those who were even a little bit skeptical in
July, suspicion goes up and IAB and RSOC credibility goes down.


At least one short-term consequence is that members of the
community who should be participating in the discussion wonder
if it is all a charade, note the volume of traffic and such
things as the dispute about the list on which the discussions
are held, and tune out.  And others wonder whether that was by
design (whether effective or not).

For the IETF community, the one problem that may be more serious
than the looming deadline of Heather's stepping down in 3 1/2
months is whether the processes to move forward and those
running them are perceived as legitimate and credible.  I think
we are in serious trouble.

So, a suggestion: let's take this as far out of the current
IAB/RSOC structure as we can and put it, at least for a while,
in the hands of someone (or a group of people) for whom the
community has a high degree of trust, trust both to behave
fairly and to focus on the well-being and future of the RFC
Series and the RFC Editor function (rather than being
contaminated by how we got here or suspected of trying to push
other agendas).  There is one obvious person for that role who,
based on community reactions in Montreal at IETF 105 and, for
that matter, at IETF 102, and that is Heather.   So I suggest
that you ask (and, if necessary, plead and beg) Heather to
extend her commitment to the IETF and the RFC Editor function
for an extra six months (or whatever other period she and you
think appropriate).  That should be done with the clear
understanding that her role (at least after December) is to lead
and manage the process of figuring out what we do next and
getting people in place to do the job.  In particular, she
should not be responsible for, or actively involved in, either
the v3 transition or management of the RFC Production Center.  I
wouldn't want that role to include selecting her successor(s)
either, but I would expect her to manage the process of figuring
out how that should be done in consultation with the community.
If she needs an advisory committee, let her select and appoint
whomever she decides she wants -- there are processes I'd prefer
but they all have credibility problems at this stage.

The suggestion above deliberately does not include the word
"contract".  The whole idea behind IASA (carried forward into
IASA2) was that their job was to get things like this that the
community wants done without dragging the community into the
details or, if that is impossible, to explain the problem to the
community.  In particular, I don't care whether the existing
contract is extended with an annex that reflects the paragraph
above (and maybe bits of your original languages or suggestions
from this thread as needed) or a new contract -- I leave that
for Heather (if she is willing to do this at all), the acting
IETF LLC ExedDir, and the LLC Board to sort out.  Were Heather
to come back to the community and suggest that she was willing
to do this but the IETF LLC was unwilling to work in good faith,
I would expect calls for resignations or worse.

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.

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.

best,
   john 



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