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

Ben Campbell <ben@nostrum.com> Tue, 08 October 2019 19:48 UTC

Return-Path: <ben@nostrum.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 68ADE120033; Tue, 8 Oct 2019 12:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.279
X-Spam-Level:
X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 qLc-nJWIs95e; Tue, 8 Oct 2019 12:48:38 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14957120013; Tue, 8 Oct 2019 12:48:38 -0700 (PDT)
Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x98JmYGB086103 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 Oct 2019 14:48:35 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1570564116; bh=ucTZodvX/mYbVPNMZmkvuXIwukPwkz33Ktx+zGBZRk8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=B1kgfkTpQfrGxw09RNlqeVupTKgtJjGkhnCAFgDZhaesxF+fCcBJJl0mNhwBkJxZC pCwpNzdOWJYxGk2sqj51TqXyYXAOWuMRg1eP7yqIfeZk0G6JaTkZggYgpTHoXf5ZhA h+jgjfY4CwBjG845iY5kYtrrQmqCwjheNMS6gPKM=
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <CALaySJL0-=Jn0Wk8GR+xrGcZ6Vyv4QO+p=LgkKt5srdVu+Zh_g@mail.gmail.com>
Date: Tue, 08 Oct 2019 14:48:29 -0500
Cc: IETF discussion list <ietf@ietf.org>, The IESG <iesg@ietf.org>, gendispatch@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.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>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/l_R4Y_GPQtlSw_BjgTPeU6D1J_I>
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: Tue, 08 Oct 2019 19:48:40 -0000


> On Oct 8, 2019, at 2:18 PM, Barry Leiba <barryleiba@computer.org> wrote:
> 
>> At the risk of strawman-ing: If the problem is mainly that GEN issues
>> tend to eat the IESG list, then a separate mailing list could be
>> enough. Maybe the idea is mainly to have chairs responsible for
>> discussion wrangling? If so, then a more conventional “GenArea” working
>> group might do the trick.
> 
> I don't think it's that they "eat the IESG list" so much as that they
> "eat the IETF list”.

Oops, typo on my part. I meant the IETF list.

>  And not in the sense that they monopolize the
> list, but that that particular list isn't sufficiently focused to give
> process issues proper consideration and determine what the right way
> to handle them is.  From my PoV, the advantage of a DISPATCH-like
> group, rather than an unfocused area group, is that the former is
> assigned the task of considering what's being discussed/proposed and
> figuring out how best to address it... rather than to just keep
> discussing it to no conclusion.

Do you think writing a charter will really change people’s behavior on that matter? I imagine most people on the IETF list would like to come to a conclusion as it is.

But as I think about this, it seems to me the main advantage of the wg would be to have a home for discussion and some experienced chairs to try to wrangle it.

The original promise of DISPATCH was the ability to say “No, this is not something appropriate for the IETF to work on right now due to (reasons).” My experience is that mainly happens when there is insufficient interest in a proposal. Even then the proponents are often unhappy with the result. It’s rare  for DISPATCH[ to conclude “There are so many opinions we are unlikely to reach consensus”. Unfortunately for GENDISPATCH, I think that will be the most common show-stopper—and a GENDISPATCH conclusion to that effect will not, by itself, stop such a discussion from continuing to eat mailing lists.

I suppose it’s possible that GENDISPATCH could say “We probably can’t reach consensus on problem A, but maybe we can on B an C;  can people please put their energy into those now and fight about A later?”.


>> 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?


I agree that deconflicting a GenArea wg and a GenDispatch wg would be essentially the same problem. In either case, both the “regular set” and the “paratrooper” participants are equally likely to participate in any other working group. Since gendispatch would cover (I assume) more topics than a either a GEN bof or “normal" GEN wg, the deconflicting problem will be harder. Plenary meetings would be a better comparison.

Again, I’m not completely opposed, just on the fence.

Ben.