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

Ben Campbell <ben@nostrum.com> Tue, 08 October 2019 18:57 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 2DE3A1200D6; Tue, 8 Oct 2019 11:57:32 -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 PiVG7zI0YYR6; Tue, 8 Oct 2019 11:57:29 -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 CC4991200B9; Tue, 8 Oct 2019 11:57:29 -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 x98IvRSr076865 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 Oct 2019 13:57:28 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1570561049; bh=EEQbjGYsOx/E7nUk8kLKK5O7d/Zn2IantxOkYlGavMw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZQZ4EDkrhS8GsYZWgeHJJgmhO2QTaQ66IEWSnarKavSdGBF75IEd1SlGp0xxfboE4 8+5UYEhOKsVfNLimkQ1JGpDpFti+/+zIccZ0u5+EWYofcO2oiN9Rols3D8HFf+5mCl usYsx33WcOvxV2rHDBxsn7UBP8kOdI/M2fOp/Nlg=
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: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com>
Date: Tue, 08 Oct 2019 13:57:22 -0500
Cc: gendispatch@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com>
References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com>
To: ietf@ietf.org, The IESG <iesg@ietf.org>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/sBP9lGTsE6as8brByjoh9dlyAOM>
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 18:57:32 -0000

I’m trying to think about GENDISPATCH from the perspective of DISPATCH in the ART Area. I’m sort of on the fence about whether this is a good idea. So,  I have questions:

DISPATCH was originally formed because the RAI (now ART) area had a firehose of new proposals, mostly related to SIP and the surrounding protocol halo. Many of these proposals were not of general interest, or came in the form of a solution rather than a problem. DISPATCH was formed to try to make sense of that. DISPATCH seems to work best when there are a steady stream of new work proposals; when that stream slows down we sometimes have trouble getting people to pay attention. Note that “steady stream of new work” is not the same as “a steady stream of discussion about a few topics”.

Do we have that same problem for GEN proposals? I think there are issues, but they are probably different issues. What is the problem to be solved?

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.

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?

Thanks,

Ben.

> On Sep 26, 2019, at 5:44 PM, The IESG <iesg-secretary@ietf.org> wrote:
> 
> A new IETF WG has been proposed in the General Area. The IESG has not made
> any determination yet. The following draft charter was submitted, and is
> provided for informational purposes only. Please send your comments to the
> IESG mailing list (iesg@ietf.org) by 2019-10-11.
> 
> General Area Dispatch (gendispatch)
> -----------------------------------------------------------------------
> Current status: Proposed WG
> 
> Chairs:
>  Francesca Palombini <francesca.palombini@ericsson.com>
>  Pete Resnick <resnick@episteme.net>
> 
> Assigned Area Director:
>  Alissa Cooper <alissa@cooperw.in>
> 
> General Area Directors:
>  Alissa Cooper <alissa@cooperw.in>
> 
> Mailing list:
>  Address: gendispatch@ietf.org
>  To subscribe:
>  Archive:
> 
> Group page: https://datatracker.ietf.org/group/gendispatch/
> 
> Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/
> 
> The GENDISPATCH working group is a DISPATCH-style working group (see RFC
> 7957) chartered to consider proposals for new work in the GEN area, including
> proposals for changes or improvements to the IETF process and process
> documents. The working group is chartered to identify, or help create, an
> appropriate venue for the work. The working group will not consider any
> technical standardization work.
> 
> Guiding principles for the proposed new work include:
> 
> 1. Providing a clear problem statement, historical context, motivation, and
> deliverables for the proposed new work.
> 
> 2. Ensuring there has been adequate mailing list discussion reflecting
> sufficient interest, individuals have expressed a willingness to contribute
> (if appropriate given the subject matter of the proposal) and there is WG
> consensus before new work is dispatched.
> 
> 3. Looking for and identifying commonalities and overlap amongst published or
> ongoing work in the GEN area, within the IESG, or within the IETF LLC.
> 
> Options for handling new work include:
> 
> - Directing the work to an existing WG.
> 
> - Developing a proposal for a BOF.
> 
> - Developing a charter for a new WG.
> 
> - Making recommendations that documents be AD-sponsored (which ADs may or may
> not choose to follow).
> 
> - Requesting that the the IESG or the IETF LLC consider taking up the work.
> 
> - Deferring the decision for the new work.
> 
> - Rejecting the new work.
> 
> If the group decides that a particular topic needs to be addressed by a new
> WG, the normal IETF chartering process will be followed, including, for
> instance, IETF-wide review of the proposed charter. Proposals for large work
> efforts SHOULD lead to a BOF where the topic can be discussed in front of the
> entire IETF community. Documents progressed as AD-sponsored would typically
> include those that are extremely simple or make minor updates to existing
> process documents.
> 
> Proposed new work may be deferred in cases where the WG does not have enough
> information for the chairs to determine consensus. New work may be rejected
> in cases where there is not sufficient WG interest or the proposal has been
> considered and rejected in the past, unless a substantially revised proposal
> is put forth, including compelling new reasons for accepting the work.
> 
> A major objective of the GENDISPATCH WG is to provide timely, clear
> dispositions of new efforts. Thus, where there is consensus to take on new
> work, the WG will strive to quickly find a home for it. While most new work
> in the GEN area is expected to be considered in the GENDISPATCH working
> group, there may be times where that is not appropriate. At the discretion of
> the GEN AD, new efforts may follow other paths. For example, work may go
> directly to a BOF, may be initiated in other working groups when it clearly
> belongs in that group, or may be directly AD-sponsored.
> 
> Another major objective of the GENDISPATCH WG is to streamline how the IETF
> community considers process improvements. Community discussions about process
> suggestions that begin on other mailing lists, including ietf@ietf.org, will
> be redirected to the GENDISPATCH mailing list where they will be facilitated
> by the WG chairs. Proponents of process improvements will be encouraged to
> craft concrete proposals for discussion on the GENDISPATCH mailing list, with
> the goal of producing a concrete outcome in bounded time. Direct requests to
> the IESG may also, after proper consideration, be redirected to the WG. For
> proposals to be considered by the WG they will be expected to meet guiding
> principle #1 above.
> 
> The existence of this working group does not change the IESG's
> responsibilities as described in RFC 3710. Work related to the IAB, IRTF, and
> RFC Editor processes is out of scope.
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce