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

[[e-mail]]

Hi Andy, 

Thank you for these inputs.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Andy Newton <[e-mail]>
> Envoyé : mercredi 3 juin 2026 16:58
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail]
> Objet : Re: [iesg] Mohamed Boucadair's Block on charter-ietf-
> dispatch-03-00: (with BLOCK and COMMENT)
> 
> 
> 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.

[Med] I went through that thread, but I'm not sure that the participants are aware of the other various groups with dispatch functions out there.

 It is the
> original, after-all.

[Med] This a fair one. Some effort will be needed to explain the (new) scope, though.

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

[Med] :-)

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

[Med] Works for me. I would also like to see the sentence be tweaked to reflect that there are also cross-area technology specific groups with dispatch function.

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

[Med] How this "must have" need to be interpreted for someone who want to solicit this group? I'm afraid that the current text was drawn from the perspective of those who will "attend" a dispatch session, not those who will propose new work.

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

[Med] ACK

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

[Med] Interesting as there wasn't a natural link in my mind between the two. A major differentiator I see is that a dispatch group should arrange for DISCUSSION to happen. That discussion may be sometimes distracted by candidate solutions while the problem to be solved at the first place is a solid one that is worth to be encouraged to be explored.

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

[Med] Thanks.

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

[Med] ACK

 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.

[Med] Fully agree. The other excerpts I shared provides that already. 

> 
> -andy
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.