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@xxxxxxxx> 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@xxxxxxxx) by 2019-10-11. > > General Area Dispatch (gendispatch) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > Francesca Palombini <francesca.palombini@xxxxxxxxxxxx> > Pete Resnick <resnick@xxxxxxxxxxxx> > > Assigned Area Director: > Alissa Cooper <alissa@xxxxxxxxxx> > > General Area Directors: > Alissa Cooper <alissa@xxxxxxxxxx> > > Mailing list: > Address: gendispatch@xxxxxxxx > 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@xxxxxxxx, 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce
