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

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
charter-ietf-dispatch-03-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-dispatch/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Hi all,

Thank you for the effort put to prepare this proposed charter.

Please find below some points for discussion:

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

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

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

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


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

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