Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch)

John C Klensin <john-ietf@jck.com> Thu, 10 October 2019 05:21 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA275120043; Wed, 9 Oct 2019 22:21:36 -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 cDXQvdkZIEEI; Wed, 9 Oct 2019 22:21:34 -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 514FA120044; Wed, 9 Oct 2019 22:21:34 -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 1iIQtH-000HxA-TV; Thu, 10 Oct 2019 01:21:31 -0400
Date: Thu, 10 Oct 2019 01:21:23 -0400
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>, Ben Campbell <ben@nostrum.com>
cc: gendispatch@ietf.org, IETF discussion list <ietf@ietf.org>, The IESG <iesg@ietf.org>
Message-ID: <246B8C1AAC97E005097CAF12@PSB>
In-Reply-To: <CALaySJL0-=Jn0Wk8GR+xrGcZ6Vyv4QO+p=LgkKt5srdVu+Zh_g@mail.gmail.com>
References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <CALaySJL0-=Jn0Wk8GR+xrGcZ6Vyv4QO+p=LgkKt5srdVu+Zh_g@mail.gmail.com>
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/gendispatch/uTSZFG0fQhLi-7f1iu-OmCLEEcQ>
Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch)
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Oct 2019 05:21:37 -0000


--On Tuesday, October 8, 2019 21:18 +0200 Barry Leiba
<barryleiba@computer.org> wrote:

>...
>> Another difference is that while DISPATCH is mainly
>> interesting to people in the ART Area, we can expect
>> GENDISPATCH to draw from all areas. We try not to let
>> DISPATCH conflict with other ART meetings. How do you
>> deconflict GENDISPATCH without it turning into another plenary
>> or a standing BoF?
> 
> This is always an issue with Gen Area BoFs and WGs, and this
> will be no different.  I think the bottom line is that
> there'll be a set of people who will want to participate
> regularly, and we'll try to accommodate that... there'll be
> people who want to parachute in for certain topics, and we'll
> do what we can to accommodate that, realizing that it's
> harder... and there'll be a lot of people who won't want to
> have anything to do with it until a proposal is at a stage
> where they strongly support it or object to it, and there's
> little we can do to accommodate that.  It is what it is, but
> it's no different than if we just charter Gen Area WGs without
> a DISPATCH-like start.  No?

Barry,

I see one risk with this that I think should be considered and
watched for even if the IESG decides to move forward.

The IETF has a rather long and difficult history, with only a
few exceptions since the POISED and POISSON WGs, of there being
two types of process change proposals.  One type is
enthusiastically welcomed by the IESG.  A large fraction  of
proposals of that type originated within the IESG (or
occasionally the IAB) and were pushed at the community rather
than being in any sense bottom-up.  That is not necessarily bad
-- your work (and Thomas's and Harald's) on IANA Considerations
is, IMO, one of the more positive examples.   Others are not.
They, and especially ones that members of the IESG see as a
threat to their authority or the way they do things and
sometimes as adding work, have tended to vanish.  Often they
vanish without a trace, with no opportunity for the community to
take positions on Last Call, sometimes inconsistent with WG
consensus, and usually with very little accountability for
individual ADs or the IESG in general.  I (and some others)
routinely cite NEWTRK as an example but there are others.  In
many of them, the IESG has insisted that a working group is
needed and then refused to create such a working group (or has
created one with a charter so narrow or broad as to make
progress impossible) as a means of killing the effort.  In
others, ADs have managed to erect sufficient obstacles and
induce enough delays that people simply lose interest.
Sometimes that is A Good Thing; often it is a control mechanism
that keep particular people or points of view in power and
prevent the IETF from evolving and making progress.

So, the question about this proposed WG for me is whether it
will make those tendencies better and thereby prevent good ideas
from getting lost or suppressed.   If so, I think it is a great
idea.   But I also see the risk of its being used to bury work
that it out of favor with "the leadership" and doing so in a way
that preserves the status quo except when the IESG wishes things
to be different) and enables even less transparency and
accountability than we have seen in the past.  I'd like to see
ideas and controls about how to prevent the latter or how to
detect it and push back if it starts to occur, and I don't see
those in the current draft specification.

best,
     john