Re: Planned experiment: A new mailing list for last-call discussions

John C Klensin <john-ietf@jck.com> Fri, 13 September 2019 02:13 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 4139C1201A3 for <ietf@ietfa.amsl.com>; Thu, 12 Sep 2019 19:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 ROdhY5DEsmRR for <ietf@ietfa.amsl.com>; Thu, 12 Sep 2019 19:13:38 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 7B9D5120090 for <ietf@ietf.org>; Thu, 12 Sep 2019 19:13:38 -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 1i8b5c-0002s3-Jg; Thu, 12 Sep 2019 22:13:36 -0400
Date: Thu, 12 Sep 2019 22:13:30 -0400
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>
cc: IETF discussion list <ietf@ietf.org>
Subject: Re: Planned experiment: A new mailing list for last-call discussions
Message-ID: <EDBBBD9628A18755F4366D0B@PSB>
In-Reply-To: <CALaySJKvdoy9MtzHMwq-Ew-EJoUs0V8t+y01FL-E5r3xdyRemQ@mail.gmail.com>
References: <CALaySJKvdoy9MtzHMwq-Ew-EJoUs0V8t+y01FL-E5r3xdyRemQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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/fOz9QusI5ub-lmwBwmR5sSi_51s>
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 02:13:41 -0000

Barry, 

I want to suggest a slightly dissenting view, but only slightly.
I have two quite separate concerns

(1) I believe that part of what has prompted the discussion of a
separate list and, I believe, the moves that led in the
direction of this experiment, is that the IETF list has, in the
several months, been more active and perhaps noisier than at any
time since I first started watching the IETF ("perhaps" because
one person's noise may be another person's really interesting
discussion).  That appears to me to have been stimulated by a
number of largely non-technical issues arising within a short
time of each other and stimulating very active discussions and
spin-offs of those discussions.  The RSE situation and Heather's
announcement that she was making and earlier-than-expected exit,
some actions by the SAAs that various people found concerning
including questions of whether the SAA function was being
weaponized to suppress unpopular questions and discussions,
questions that have been discussed as "tone" but that ultimately
may be about how we maximize form and content at the same time,
and issues about whether people who do not attend most f2f
meetings are really full members of the community (with the
recall topic in particular), come to mind immediately, but I
think the list is probably longer.   In normal times (whatever
that means), we might see one of those issues and the subsequent
long threads and branches once every six months or a year and
then they die down for a while.  

I hope the situation of the last months, one that has given many
of us a choice between trying to follow the discussion threads
and getting any substantive IETF work done at all, is not our
"new normal" and will settle down soon.   I assume the IESG
shares that wish since the traffic level has to be hitting most
or all of you as hard or harder than those of us who are just
participants and who have much more flexibility about what to
ignore.  So I would like to see the experiment initiated and run
in "normal" times.  If you start it while the IETF list is this
active and then it settles down, it will be impossible to
evaluate whether the experiment had any useful effect.

So, I think the experiment is worthwhile but that, if we expect
to learn anything from it, I think it would be much wiser to
initiate it only after the IETF list settles down (or the IESG
makes an informed decision that we are in a new steady state and
"settled down" is not going to happen).  If things settle down
before the 1st of September (and I devoutly hope they will)
then, by all means go for it (especially if you don't think the
concern below is a problem) but, if not, I suggest thinking very
carefully about start dates.

(2) As I have talked with people in other standards bodies,
people in procurement roles, regulators, and so on over the last
many years, I've become convinced that the IETF's main source of
strength and credibility has been effective cross-area review
(as well as interoperability testing in years gone by).  It is
not that we are so much smarter than everyone else, it is that
we've been able to look at a specification that is proposed for
the standards track from many different perspectives and do so
in depth.  As you know, I'm concerned that the quality of those
reviews has been deteriorating as am increasing fraction of the
reviews outside the WG or Area of the document are by people
with insufficient in-depth knowledge to understand the subject
matter and comment on it in detail.  I may be atypical, but
there have been many times I've ignored a Last Call announcement
of a document that is within my area of competence but not of
special interest, only to be lured in later by a Last Call
discussion on the IETF list.   Now, if everyone who is
interested in technical reviews of LC documents subscribes to
the new list and stays on it, there will be no difference.  But
I can easily imagine some number of IETF participants
subscribing to the new list only when a Last Call of interest
shows up on IETF-Announce and then unsubscribing when that Last
Call is over.  If the number of such people, perhaps weighted by
their depth and breath of technical knowledge, is trivial, then
there is no concern.  But, if it isn't and that [further]
weakens our ability to obtain in-depth cross-area reviews, it
won't be doing the IETF and its future any favors.   If the
experiment is run, I'm not sure that effect can be measured, but
the possibility may be worth a little thoughts.

best,
   john




--On Thursday, September 12, 2019 12:14 -0400 Barry Leiba
<barryleiba@computer.org> wrote:

> As we discussed in the plenary session at IETF 105 in
> Montréal, some community members have suggested moving
> document last-call discussions onto a dedicated "last-call"
> mailing list, and off of the general <ietf@ietf.org> list.
> The latter is a high-volume list with a lot of varied
> discussion, and some think that it would be useful to separate
> the general discussion from the last-call discussion, to allow
> people to choose which discussions (or both) to follow.  In
> the IETF 105 plenary, support was expressed for that
> separation.
> 
> The IESG agrees, and wants to try an experiment to that end.
> We propose to create <last-call@ietf.org> and to direct
> last-call comments and discussions there (the last-call
> announcements would still go to <ietf-announce@ietf.org>, with
> "reply-to" set to the new list).  That list would be monitored
> by volunteers recruited by the IETF Chair, and digressions
> would be nudged back to <ietf@ietf.org>, while we would ask
> people having last-call discussions on this list to please
> move them to the new list.  We would get the tools team
> involved so that the distribution lists for directorate and
> review-team reviews would be updated appropriately.
> 
> Our plan is to create the new list and pre-subscribe everyone
> who is subscribed to <ietf@ietf.org> at that time.  Of course,
> anyone could unsubscribe to either or both lists immediately
> or later, but we think that doing it this way would minimize
> the likelihood that people would miss important stuff because
> of the move, and folks can choose what they prefer from there.
> 
> After six months, we would do an initial evaluation, including
> getting feedback from the community, to see how the experiment
> is working.  If it seems worth continuing we would do so, and
> at a point that the community decides that the experiment is a
> success (should it so decide), we would start an update to BCP
> 45 to formally move the location for last-call discussions,
> and we would update the 2007 IESG Statement on Last Call
> Guidance.
> 
> We invite comments, here, on this plan, by the end of
> September. As I say above, we've heard support from the
> community for the general idea, and we'd like to make sure
> this direction is what the community wants.
> 
> Barry, for the IESG
>