[dispatch] Re: [iesg] Mohamed Boucadair's Block on charter-ietf-dispatch-03-00: (with BLOCK and COMMENT)

[Andy Newton <[e-mail]>]

Hi Med

On 6/3/26 10:21 AM, Mohamed Boucadair via Datatracker wrote:
> # Misleading Group Name
> 
> I’m listing this as a DISCUSS because of the special nature of this group.
> 
> I do find the name misleading and problematic. This group is for dispatch
> matters covering 2.5 areas if we will (“ART, SEC and non-transport aspects of
> the WIT areas”), while it can be perceived as the default entry of new work for
> all areas and topics. There are several others WGs/Areas that have chartered
> dispatch function with a specific scope (either area or technology). All of
> these have names that are specific enough.
> 
> Would it be possible to consider a name that would not have that pattern?

This was discussed and we lost the argument:
https://mailarchive.ietf.org/arch/msg/dispatch/ZtKrXd0ku1w6gNr6T06ANGwdU9I/

The community insists that this wg stay DISPATCH. It is the original, after-all.

I do agree with you that this is difficult for people unfamiliar with the IETF. I think the IESG will need to convince the community of this, and should they agree we'll then see about a name change (I still like WASNEW).

> 
> # Conflict with other groups
> 
> CURRENT:
>   Other areas may have their own process for considering new work. Support
>   for other IETF areas is out of scope for DISPATCH.
> 
> ## This text covers only areas, but there are other groups with dispatch
> function and technology-oriented (+ cross area): dnsop, for example.
> 
> ## Should we consider some guidance to avoid dispatching when there is already
> a more specific dispatch home?

Good idea. I think the solution is to have the charter reference the wg wiki which will contain a list of the other DISPATCH-esque groups.

> 
> # Pre-requisites to present
> 
> CURRENT:
> Participants requesting to present a topic at a DISPATCH working group
> meeting ** must have **:
> 1.      A clear problem statement, motivation and deliverables.
> 2.      Identified commonalities and overlap amongst published or ongoing
> protocol work. 3.      People with interest and expertise to work on this
> problem. 4.      People interested in an interoperable solution and capable of
> implementing and deploying it. 5.      Documentation in the form of one or more
> Internet-Drafts. 6.      A slide presentation to be given at the DISPATCH
> meeting.
> 
> I’m having troubles about how to interpret that “must have” to request a prez
> slot. Should requesters show evidence about all of these? Why not presenting
> this list as suggestions to have successful dispatch slot? Also:
> 
> ## Is it reasonable to ask new work (that is being nurtured) to have a clear
> list of deliverables? is that about key expected deliverables?
> 
> ## Should the second item be updated to mention “(if any)” as there might be no
> overlap/commonalities at all.
> 
> ## How to assess there is interest before even presenting? or the assumption is
> that there must be mail discussion before?
> 
> ## Item 4 assumes the new work is always protocol work (i.e., no profiling,
> BCP, recommendations work, etc.). Is that intended?

That is a good point. Perhaps we prepend "If the proposal is intended for Proposed Standard, ..."

> 
> ## Likewise, do we assume that participants will always come with a solution,
> not only a problem to be solved? Would that work be rejected because of that
> “must have” list?

Yes. We need to differentiate DISPATCH from HOTRFC.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # I like this part:
> 
> CURRENT:
>   The DISPATCH chairs may institute a workflow for the working group's mailing
>   list for the purposes of processing work without a meeting using inputs from
>   participants similar to the above and with processing steps equivalent to the
>   steps used for processing work in a meeting.
> 
> However, this text seems like a patch to the prez-centric mode of operation. I
> think that having a preamble that defines dispatch function independent of the
> format before focusing on prez and mailing list formats would be helpful.

Ok. Sounds good.

> 
> # (Duplicate) Operational procedures
> 
> CURRENT:
>   The chairs are empowered to create operational procedures within the bounds
>   of established IETF processes to meet the goals of this working group,
>   including but not limited to, mandating presentation templates, instituting
>   mailing list workflows, etc…
> 
> ## The proposed charter already includes operational procedures (must have
> list, prioritization, etc.). For example, “instituting mailing list workflows”
> duplicates what is already stated here:
> 
> “The DISPATCH chairs may institute a workflow for the working group's mailing
> list for the purposes of processing work without a meeting using inputs from
> participants similar to the above and with processing steps equivalent to the
> steps used for processing work in a meeting. “
> 
> ## I would change to:
> 
> NEW:
>   The chairs are empowered to create additional operational procedures within
>   the bounds of established IETF processes to meet the goals of this working
>   group.

Let me think about this. We do want the charter to explicitly allow the chairs to figure out how to dispatch on the list if the wg wants to do that.

-andy