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

Ben Campbell <ben@nostrum.com> Thu, 10 October 2019 15:52 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 0372112001A; Thu, 10 Oct 2019 08:52:59 -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 1827ccoaX6Al; Thu, 10 Oct 2019 08:52:57 -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 711E212011E; Thu, 10 Oct 2019 08:52:57 -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 x9AFqnDb032233 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Oct 2019 10:52:51 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1570722772; bh=Zd/WNqGfWRWUHQv86vksRF2mPJ6/kk4MwirTHAVmbOQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZcyTqE96no+zMbrPbkUQKH9uT9RITZNeQ5CGCPLv6vnr+uzsBMuYcLMtP9vZuN1aS BU8B+rWqRiJmJwoLiPIWtUEv4F+WheBkR1uRYadUxbu5ngRQv3YaaR46FrSH5CpWst FAbnF2dAGECnlMA+13FOcqcd/+4M4pRhzObzQrLQ=
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="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <246B8C1AAC97E005097CAF12@PSB>
Date: Thu, 10 Oct 2019 10:52:43 -0500
Cc: Barry Leiba <barryleiba@computer.org>, gendispatch@ietf.org, IETF discussion list <ietf@ietf.org>, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <48E33F75-6458-4CF2-AD3D-7201E7A86EF8@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> <246B8C1AAC97E005097CAF12@PSB>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/z-X1DnqV2KYSg1W3Vjj-yRTFfyE>
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 15:53:00 -0000


> On Oct 10, 2019, at 12:21 AM, John C Klensin <john-ietf@jck.com> wrote:
> 
> 
> 
> --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.

Hi John,

This brings up another question in my mind. The ART ADs typically treat DISPATCH decisions as non-binding recommendations. Likewise, the ADs may skip DISPATCH and take proposals straight to BoF or even WG formation if they think it appropriate.

Would GENDISPATCH decisions be treated the same, or would they be binding on the IESG? I had assumed the former, in the sense that AD discretion applies to pretty much any working group. Whichever case is the answer, I think the charter needs to be explicit about it.

Thanks!

Ben.