Hi Ekr,
On Sep 28, 2019, at 4:24 PM, Eric Rescorla < ekr@xxxxxxxx> wrote:
First, let me say that I am broadly in favor of this proposal. IMO, DISPATCH-style WGs have been very successful in both SEC and ART. I have a couple of small comments. 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. I think you could read this two ways: 1. This WG won't do any standards 2. This WG won't do any technical work So as a concrete example, suppose I had a standards track proposal to require that WG chairs all wear powdered wigs, that would not be technical, but I take from the list of options below that it would not be able to actually advance the work itself, but only recommend a next step. Is that correct?
Yes.
In that case, perhaps:
"The Working Group will not directly progress any standards
work itself”.
I’m not sure what problem that change would solve. There is another meaning that the current text conveys that would be lost if that change were made. If someone tries to bring a specification for a new audio codec to GENDISPATCH, it will not even be considered. This is different from the proposal to require chairs to wear wigs, which could be considered and then dispatched.
If you mean the latter, maybe just remove the word “standardization”
The problem with that is that there have occasionally been IETF tools-related things that have been documented in I-Ds and RFCs (e.g., https://datatracker.ietf.org/doc/rfc6778/). Although to my eye an RFC is not a great mechanism for publishing these kinds of things, if the community wanted to do that then considering such documents in GENDISPATCH seems warranted. And these could arguably be considered “technical work.”
Thanks, Alissa
> 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.
We have found this to be a key clause for other DISPATCH-style WGs
so glad to see it here.
-Ekr
Hi all,
The review period for this charter is a little longer than usual since this is a proposal for a process-oriented WG that did not go through the BOF process. As the charter text indicates, the idea of this WG is to help streamline the consideration of process proposals and leverage the WG chairs to help guide process discussions. Feedback is welcome.
Thanks,
Alissa Cooper
General Area AD
> On Sep 26, 2019, at 11: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
|
