Subject: Re: WG Review: General Area Dispatch (gendispatch)

From: Sean Turner <[email-masked]>
Date: Tue, 1 Oct 2019 18:47:26 +0100

apologies for the double send.

> On Oct 1, 2019, at 16:30, Sean Turner <[email-masked]> wrote:
> 
> I am in favor of this proposal.  One question below:
> 
>> On Sep 26, 2019, at 23:44, The IESG <[email-masked]> wrote:
>> 
>> f 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.
> 
> Is the AD in this case always the IETF Chair?  I am somewhat concerned about increasing the workload of the IETF Chair when the I-D might doing something so minor (and possibly noncontroversial) that any AD could sponsor the I-D.
> 
> 
> spt

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 4 Oct 2019 13:14:24 -0400

Hi Ekr,

> On Sep 28, 2019, at 4:24 PM, Eric Rescorla <[email-masked]> 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/ <https://datatracker.ietf.org/group/gendispatch/>
> >
> > Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ <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
> 
> On Thu, Sep 26, 2019 at 3:48 PM Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
> 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 <[email-masked] <mailto:[email-masked]>> 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 ([email-masked] <mailto:[email-masked]>) by 2019-10-11.
> > 
> > General Area Dispatch (gendispatch)
> > -----------------------------------------------------------------------
> > Current status: Proposed WG
> > 
> > Chairs:
> >  Francesca Palombini <[email-masked] <mailto:[email-masked]>>
> >  Pete Resnick <[email-masked] <mailto:[email-masked]>>
> > 
> > Assigned Area Director:
> >  Alissa Cooper <[email-masked] <mailto:[email-masked]>>
> > 
> > General Area Directors:
> >  Alissa Cooper <[email-masked] <mailto:[email-masked]>>
> > 
> > Mailing list:
> >  Address: [email-masked] <mailto:[email-masked]>
> >  To subscribe:
> >  Archive:
> > 
> > Group page: https://datatracker.ietf.org/group/gendispatch/ <https://datatracker.ietf.org/group/gendispatch/>
> > 
> > Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ <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
> > 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 [email-masked] <mailto:[email-masked]>, 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
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>
>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 4 Oct 2019 13:22:30 -0400

Hi Sean,

> On Oct 1, 2019, at 1:47 PM, Sean Turner <[email-masked]> wrote:
> 

It need not be. To take a recent example, RFC 8318 was a process doc that was AD-sponsored by an ART AD.

Thanks,
Alissa

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 6 Oct 2019 06:34:13 +0000

Hi,
I think this is a good idea. 
I hope it will help with better convergence on some of the topic discussed on the discuss mailing list by having this WG chairs shepherding the discussion.
I am wondering if this dispatch WG will require a draft in order to start a discussion on a new topic. It will probably require the WG chairs to be more active with bringing new relevant items to the WG

Roni Even

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Friday, September 27, 2019 1:48 AM
To: IETF
Cc: [email-masked]
Subject: Re: WG Review: General Area Dispatch (gendispatch)

Hi all,

Thanks,
Alissa Cooper
General Area AD

> On Sep 26, 2019, at 11:44 PM, The IESG <[email-masked]> 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 ([email-masked]) by 2019-10-11.
> 
>  Francesca Palombini <[email-masked]>
>  Pete Resnick <[email-masked]>
> 
> Assigned Area Director:
>  Alissa Cooper <[email-masked]>
> 
> General Area Directors:
>  Alissa Cooper <[email-masked]>
> 
> Mailing list:
>  Address: [email-masked]
>  To subscribe:
>  Archive:
> 
> Group page: https://datatracker.ietf.org/group/gendispatch/
> 
> Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/
> 
> 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.
> 
> 1. Providing a clear problem statement, historical context, 
> motivation, and deliverables for the proposed new work.
> 
> 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.
> 
> - Making recommendations that documents be AD-sponsored (which ADs may 
> or may not choose to follow).
> 
> 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.
> 
> 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 
> [email-masked], 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.
> 
> responsibilities as described in RFC 3710. Work related to the IAB, 
> IRTF, and RFC Editor processes is out of scope.
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2019 12:28:56 -0400

In article <[email-masked]> you write:
>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.

It seems like a reasonable idea.

Is there any plan or schedule for a review after a year or two to see
whether it's working as expected?

R's,
John

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 7 Oct 2019 08:50:38 -0400

Hi Roni,

> On Oct 6, 2019, at 2:34 AM, Roni Even (A) <[email-masked]> wrote:
> 
> Hi,
> I am wondering if this dispatch WG will require a draft in order to start a discussion on a new topic.

That seems like a good practice for the chairs to adopt at least for actual meeting presentation slots. Might be a bit of a high bar for mailing list discussion though.

Alissa

> It will probably require the WG chairs to be more active with bringing new relevant items to the WG
> 
> Roni Even
>

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 7 Oct 2019 08:51:13 -0400

Hi John,

> On Oct 6, 2019, at 12:28 PM, John Levine <[email-masked]> wrote:
> 

That seems like a good idea.
Alissa

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 7 Oct 2019 13:01:47 +0000

Hi Alissa

What I meant that since this WG is chartered to address "non-technical" topics,  where everyone has an opinion, my observation is that the discussions are not focused, multiple threads start to appear on the mailing list making it difficult to follow. 
I think that it will be good if this new WG chairs (or someone appointed by them) will try to bring such a discussion to be structured by summarizing the discussion points and the views and list the open discussion points to help with convergence (similar to meeting notes).

Roni

Alissa

>> 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 ([email-masked]) by 2019-10-11.
>> 
>> ---------------------------------------------------------------------
>> -
>> -
>> help create, an appropriate venue for the work. The working group 
>> will not consider any technical standardization 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.
>> 
>> - Making recommendations that documents be AD-sponsored (which ADs 
>> may or may not choose to follow).
>> 
>> 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 
>> 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 
>> 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 [email-masked], 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.
>>

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Oct 2019 09:06:41 -0400

> What I meant that since this WG is chartered to address "non-technical" topics,  where everyone has an opinion, my observation is that the discussions are not focused, multiple threads start to app…

Yes, that does happen.  But if a group gets prematurely focused on, or a 
discussion gets framed around, a Bad Idea, that can be a worse outcome, 
even if the idea is ultimately abandoned.   Early discussions should be 
fluid, especially on a topic of such importance.

Keith

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Oct 2019 13:57:22 -0500

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 <[email-masked]> wrote:
> 
> IESG mailing list ([email-masked]) by 2019-10-11.
> 
> suggestions that begin on other mailing lists, including [email-masked], will

---

From: Barry Leiba <[email-masked]>
Date: Tue, 8 Oct 2019 21:18:18 +0200

> 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".  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.

> 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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Oct 2019 14:48:29 -0500

> On Oct 8, 2019, at 2:18 PM, Barry Leiba <[email-masked]> wrote:
> 
> "eat the IETF list”.

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

>  And not in the sense that they monopolize the

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

> different than if we just charter Gen Area WGs without a DISPATCH-like

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.

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Oct 2019 16:15:46 -0400

On 10/8/19 3:18 PM, Barry Leiba wrote:

> to handle them is.

The flip side of this argument is that the IETF list might represent a 
broader spectrum of concerns, than a group that's specifically devoted 
to looking at process changes.   If the gendispatch WG doesn't enjoy a 
broad spectrum of representation from the IETF community as a whole, it 
could easily go off the rails.   And it also seems likely that such a 
group would be biased towards those who think that process changes are a 
Good Thing, and perhaps against those who think current processes are 
mostly ok.

I certainly don't think that process changes should be hashed out in 
detail on the IETF list, but it might still be better for initial 
discussion of new ideas than a separate WG.

I'm also one of those asking "what are the problems to be solved?"   
Because the proposed charter for this WG seemed to indicate some sense 
of urgency, so presumably there are some problems that the group's 
proponents have in mind.

Keith

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 9 Oct 2019 09:06:45 +1100

Anecdata - 

I made a proposal at the plenary mic in Montreal for a separate last-call@ list. I'd made that proposal at least twice before to iesg@ in the past, but it never got traction, until it was suggested I bring it up at the mic. Once it got some support in the room, the IESG went away and came up with a fully-baked proposal for an experiment in the community.

Under GENDISPATCH, I would have taken the proposal there (I didn't take it to ietf@ because it was too focused on other issues, and I didn't see it as likely to gain traction there). It would have been discussed and presumably we would have developed a proposal in the open, guided by the chair(s).

I think that's a better outcome; certainly, as someone who wants to suggest a change to the process, GENDISPATCH is more straightforward and requires less "inside" knowledge.

I do think there are going to be some cases where process changes are only going to get rough consensus, and the chair(s) of GENDISPATCH need to be able to make that consensus stick -- but that's just as it is in every other working group. I suspect that developing the proposals and making those calls in a public process rather than (what some perceive to be) as proclamations from on high is a better way to promote what resembles harmony in our community.

Cheers,

> On 9 Oct 2019, at 6:48 am, Ben Campbell <[email-masked]> wrote:
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Oct 2019 17:19:50 -0500

> On Oct 8, 2019, at 5:06 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Anecdata - 
> 

I don’t disagree with any of your points. But keep in mind that, according the proposed charter, GENDISPATCH would develop a problem statement, context, and assess the level of interest, then pass the work on somewhere else for the developing a solution part. For some things that can help focus thinking. For others it can become yet another process speed bump. For relatively self-contained proposals like the one you suggest, I suspect it may be more of the latter.

> I think that's a better outcome; certainly, as someone who wants to suggest a change to the process, GENDISPATCH is more straightforward and requires less "inside" knowledge.

That’s a pretty good point—it’s possible that GENDISPATCH could become a well-known entry point, with less guessing about who one needs to talk to to promote an idea. DISPATCH has occasionally had complaints from people from areas that don’t use the dispatch process because it doesn’t match the processes they are familiar with. But that’s probably easier for something with more cross-area appeal.

> I do think there are going to be some cases where process changes are only going to get rough consensus, and the chair(s) of GENDISPATCH need to be able to make that consensus stick -- but that's j…

No disagreement there.

Thanks!

Ben.

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Oct 2019 01:21:23 -0400

--On Tuesday, October 8, 2019 21:18 +0200 Barry Leiba
<[email-masked]> 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.

best,
     john

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 Oct 2019 10:52:43 -0500

> On Oct 10, 2019, at 12:21 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

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.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 Oct 2019 11:05:14 -0500

Here’s an attempt to distill my concern a little better:

The “dispatch process” can reasonably be thought of as a triage process. Triage makes sense when you don’t have the time and resources to address every problem and have to pick and choose where you can have the most impact. If you do have time and resources to address everything, then triage is just a process bump. 

Do we believe that GEN area proposals will routinely exceed our capacity to discuss them? If so, do we think that will continue to be true for the foreseeable future? (I assume this is intended to be a long-lived wg).

Thanks!

Ben.

> On Oct 8, 2019, at 5:19 PM, Ben Campbell <[email-masked]> wrote:
> 
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 10 Oct 2019 20:13:17 +0200

Hi John,

Top-posting because I would like to make a meta comment on the text you wrote below. You seem to base our statements on an assumption that, excessively formulated,  IESG members in general act in bad faith and are mostly driven by the selfish interest of retaining their power. To be honest I’m not entirely sure which power you exactly talk about but in my case I’m more than happy to release any power I may or may not have in March after spending large portions of my time and work power on my AD tasks the last 3.5 years and simply have time to use my energy for something else again.

Still it makes me sad to see that members of the community make these kind of very general, negative assumptions about a rather diverse group of others members of our community that have been (re-)selected by the community because, as I thought, the community trusts them to fill the respective position appropriately and act in a good faith. 

I'm pretty sure I also have been “delaying” things during my AD terms, either because I actually really just didn’t have time or because I wasn’t able to figure out if there is community interest or consensus in doing the work. I never took any action with the goal to "prevent the IETF from evolving and making progress”. And, call me naive, but I don’t even understand why I should have an interest in doing so.

Again, I’m just writing this email because reading you mail below does makes me sad and I’m also afraid that this kind of views about then IESG could actually stop other members of the our community to volunteer for a position on the IESG in future.

Mirja

> On 10. Oct 2019, at 07:21, John C Klensin <[email-masked]> wrote:
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Oct 2019 08:47:06 +1300

> Do we believe that GEN area proposals will routinely exceed our capacity to discuss them? If so, do we think that will continue to be true for the foreseeable future? (I assume this is intended to…

I think that we have never really had a problem handling minor process fixes. That's why we have so many process-related RFCs, in fact. For those, GENDISPATCH will clearly help us do the triage a bit more systematically, and that is a Good Thing. 

Where we've had a problem, for the last 20 years, is in achieving major process changes. Actually we haven't really had any, except RFC 6410. IMHO all the other updates to RFC 2026 were clarifications and tuning. (Of course opinions on this may vary.) And even that change was really a rather late recognition of reality.

For major change to occur, we need a strong community will and a flexible IESG. GENDISPATCH won't automatically achieve that, because there's a tendency to put proposals for major change on the "too hard" heap. But at least GENDISPATCH offers a mechanism for discussing proposals for major change, and that too is a Good Thing.

Regards
   Brian

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 11 Oct 2019 11:07:17 +0200

Hi Ben,

> On Oct 10, 2019, at 5:52 PM, Ben Campbell <[email-masked]> wrote:
> 
> 
> 

I changed the sentence about RFC 3710 so it now includes the word “discretion.” https://datatracker.ietf.org/doc/charter-ietf-gendispatch/

Best,
Alissa

> 
> Thanks!
> 
> Ben.
> 
> -- 
> Gendispatch mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/gendispatch <https://www.ietf.org/mailman/listinfo/gendispatch>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 11 Oct 2019 11:10:26 +0200

Hi Ben,

> On Oct 10, 2019, at 6:05 PM, Ben Campbell <[email-masked]> wrote:
> 

I guess I see the question differently. If there are people in the community who are willing to manage discussions about process proposals while they’re in formation (i.e., people willing to chair this WG), that seems like a better arrangement than the current one both from the perspective of being more community-led and from the perspective of the other time commitments that the IESG has. If the WG isn’t busy or meeting all the time, that’s fine — it will still be nice to have it there for times when process proposals do come up and inspire discussion.

Best,
Alissa 

> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Oct 2019 09:08:53 -0400

--On Thursday, October 10, 2019 10:52 -0500 Ben Campbell
<[email-masked]> wrote:

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

Ben,

I had assumed the former as well.  I think that taking that
discretion away from ADs would put us into a place where we
really do not want to go.  In particular, one can imagine
situations in which ADs would be forced to manage WGs they would
like to have fail and there are just too many ways in which
failures can be encouraged or the WG's work subverted.  At the
same time, we've occasionally seen that discretion used in a way
that is arguably abusive.  It is my impression that has occurred
more often with process proposals than anything else and that is
most of what prompted the note to which you responded.  

It had not occurred to me until now, but I think that concern
segues into your comments to Mark about a triage process.  If we
really mean triage, we mean something that is relatively quick
and decisive.  One of my concerns has been that the existence of
such a WG could be used to drag things out, as in "we can't
consider this until GENDISPATCH meets", then "interesting
discussion, let's postpone to the next meeting", then "this
really needs a WG for itself", then some delay in getting the WG
organized because no one on the IESG is enthused, then...   One
can easily imagine things being dragged out for close to a year,
or longer, until people lose interest or accept the status quo
as fated.  Perhaps a few guidelines and timelines would help
alleviate that concern.  For example, that the WG gets only one
shot (no postponements to the next IETF) and that, if
GENDISPATCH concludes that a WG is needed, it starts a clock
ticking by which the WG has to be either organized, formed, and
in operation or the IESG is required to explain the delay to the
community.

Probably mechanisms like that would be a net improvement over
the current situation although my concern that the IESG and the
community should watch this very carefully remains.  That
concern is especially strong if the leadership of the WG is
different from the relevant AD(s): on the one hand, that can
improve efficiency because ADs are overworked.  On the other,
because that chair or those co-chairs are not nomcom-appointed
or subject to recall, there is less direct accountability to the
community and more ability for the IESG (or a particular AD) to
throw the co-chairs under an approaching bus and therefore avoid
accountability (or course, we've never seen things like that
happen in other areas of the IETF/IAB's work).

best,
   john

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 Oct 2019 11:21:46 -0400

On 10/11/19 9:08 AM, John C Klensin wrote:

> One of my concerns has been that the existence of
> as fated.

Interesting.   My concern is somewhat the opposite: that such a WG 
(especially if not many people join or few people pay attention) can be 
used to "bury" process changes that the IESG wants to see, and cement 
them, before the wider community provides significant input.  This would 
be consistent with a longstanding practice in IETF of having WGs that 
are so siloed that they mask tussles that a more widely-scoped WG would 
attempt to resolve.

Keith

---

From: Ben Campbell <[email-masked]>
Date: Fri, 11 Oct 2019 14:00:41 -0500

> On Oct 11, 2019, at 4:07 AM, Alissa Cooper <[email-masked]> wrote:
> 
> Hi Ben,
> 
>> On Oct 10, 2019, at 5:52 PM, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>>> On Oct 10, 2019, at 12:21 AM, John C Klensin <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> ...
> I changed the sentence about RFC 3710 so it now includes the word “discretion.” https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ <https://datatracker.ietf.org/doc/charter-ietf-gendispatch/>
Hi Alissa,

That helps. Also, the text about Gen AD discretion that was already there that I somehow completely failed to read also helps :-)

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 11 Oct 2019 14:12:59 -0500

> On Oct 11, 2019, at 4:10 AM, Alissa Cooper <[email-masked]> wrote:
> 
> Hi Ben,
> 

I think I’ve been unclear in my concern. I have no objection to having a working group for discussion of proposals to improve processes. I think that’s a good idea. My question is about whether such working group should be limited to the dispatch process.

Certainly there may be case where there it is appropriate dispatch work to some other venue, spin up a new wg for a proposal, etc. But I wonder why we need to decide in advance that work on a proposal will cannot be completed by this group. Especially when it seems likely that the people working on a proposal will often be the same whether the work happens in gendispatch or somewhere else.

Thanks!

Ben.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 12 Oct 2019 04:12:11 +0300

Brian, Alissa,

> I think that we have never really had a problem handling minor process fixes. That's why we have so many process-related RFCs, in fact. For those, GENDISPATCH will clearly help us do the triage a b…

For what it is worth, I’m in favour of setting up this new group. I agree with Brian’s assessment above; when it comes to non-technical work, we’ve certainly been able to do many small changes.  Actually, unlike Brian I think we’ve also been able to do some bigger things as well (IASA 2.0 comes to mind as a recent example) but maybe some of those are more under the topic of administration rather than process work.

Anyway, I think what this new working group will bring is a bit more structure and additional people and more eyes on topics that have traditionally too reliant on GEN AD sponsorship and IESG discussions. That’s great, and an improvement (even if we previously were able to produce process RFCs as well).

This new working group does not remove all problems from this space, of course, and one of the continuing challenges is to get the people who do normal IETF work to know and care about process issues. Bringing things up on plenaries etc will be useful, as well as on ietf@ietf (but clearly, the set of people on that != the set of people doing IETF work).

Also, +1 to what Mirja wrote.

Jari

---

From: Patrick McManus <[email-masked]>
Date: Sat, 12 Oct 2019 10:35:44 -0400

Alissa,

This is a good idea that I support. Specific GEN proposals will benefit
from a more focused space than the current mechanisms allow. Thanks for
putting this together.

-Patrick

On Thu, Sep 26, 2019 at 6:46 PM The IESG <[email-masked]> wrote:

> including
> enough

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Oct 2019 22:22:55 +0200

Not sure who wrote this:
    >> I think that we have never really had a problem handling minor process
    >> fixes. That's why we have so many process-related RFCs, in fact. For
    >> those, GENDISPATCH will clearly help us do the triage a bit more
    >> systematically, and that is a Good Thing.

Is the purpose of GENDISPATCH to deal with minor process exceptions, or
fixes?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 14 Oct 2019 08:17:52 -0400

Hi Ben,

> On Oct 11, 2019, at 3:12 PM, Ben Campbell <[email-masked]> wrote:
> 
> 
> 

Ah, got it. This is a good question. Perhaps we can try it in dispatch-style for awhile and see if we’re often arriving at an outcome where it seems like just processing a document in the WG would be the most logical thing to do. If so, a re-charter to allow that would be possible. I was a little hesitant to jump straight to having a General Area Working Group; the dispatch-style group seemed like it could be a useful intermediate step.

Alissa

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Oct 2019 22:01:34 -0500

Chiming in very late hear, but only to say something I hope is encouraging
...

On Mon, Oct 14, 2019 at 7:19 AM Alissa Cooper <[email-masked]> wrote:

> >>> The “dispatch process” can reasonably be thought of as a triage
> process. Triage makes sense when you don’t have the time and resources to
> address every problem and have to pick and choose where you can have the
> most impact. If you do have time and resources to address everything, then
> triage is just a process bump.
> >>>
> >>> Do we believe that GEN area proposals will routinely exceed our
> capacity to discuss them? If so, do we think that will continue to be true
> for the foreseeable future? (I assume this is intended to be a long-lived
> wg).
> >>
> >> I guess I see the question differently. If there are people in the
> community who are willing to manage discussions about process proposals
> while they’re in formation (i.e., people willing to chair this WG), that
> seems like a better arrangement than the current one both from the
> perspective of being more community-led and from the perspective of the
> other time commitments that the IESG has. If the WG isn’t busy or meeting
> all the time, that’s fine — it will still be nice to have it there for
> times when process proposals do come up and inspire discussion.
> >
> > I think I’ve been unclear in my concern. I have no objection to having a
> working group for discussion of proposals to improve processes. I think
> that’s a good idea. My question is about whether such working group should
> be limited to the dispatch process.
> >
> > Certainly there may be case where there it is appropriate dispatch work
> to some other venue, spin up a new wg for a proposal, etc. But I wonder why
> we need to decide in advance that work on a proposal will cannot be
> completed by this group. Especially when it seems likely that the people
> working on a proposal will often be the same whether the work happens in
> gendispatch or somewhere else.
>
> Ah, got it. This is a good question. Perhaps we can try it in
> dispatch-style for awhile and see if we’re often arriving at an outcome
> where it seems like just processing a document in the WG would be the most
> logical thing to do. If so, a re-charter to allow that would be possible. I
> was a little hesitant to jump straight to having a General Area Working
> Group; the dispatch-style group seemed like it could be a useful
> intermediate step.
>

I think trying something Dispatch-style will be helpful - it was helpful
for then-RAI to have a way to sort through proposals without having to spin
up full BOFs - and I'm reading Alissa's note here as "I want to try to do
something that could improve things, and if we need to change what we're
starting with in order to improve things, we can make changes, and keep
trying to Do The Right Thing".

That would be lovely.

Best of luck!

Spencer