Dispatch
charter-ietf-dispatch-04

[Ballot comment]
Just a few non-blocking comments:

Why is future tense used rather than present tense in statements such as `The WG chairs will maintain a list on the DISPATCH WG Wiki`, i.e., is this a one-shot or a continuous effort ? I would really prefer to use present tense even if these Wiki pages do not exist yet (AFAIK).

About `The chairs are empowered to create operational procedures` how will these procedures be documented / published ?

`The feedback given by the DISPATCH working group may include, but is not limited to, the following` is rather broad, i.e., does not have a real scope, which is unusual for a WG.

[Ballot comment]
** Per “New work relating to the
way the IETF transport protocols interact with network elements should be
directed to TSVWG if a relevant working group cannot be found.”

Is this text needed?  This means that if another WG gets this scope or some other process is defined, this charter must be updated.

** Per “Participants requesting to present a topic at a DISPATCH working group
meeting must have: …”

Keying in on the “must” in this text and that charters typically are not so prescriptive about agenda slot requests, would it be a charter violation (appealable?) if a time slot is given to a topic which does not meet all 6 requirements?  Would it be better to afford some flexibility?  Other topics are already delegated to the WG wiki, why not some of these requirements?  It also would allow future refinement.

** Per “
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.”

How does a participant requesting a slot demonstrate #3 and #4?  Is there some roster to share?  Is it literally people’s names?

** Per “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…”

Is this text really needed?  This is true for EVERY WG chair in the IETF.

[Ballot 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?

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

[Ballot comment]
Thanks for putting this together and I support the idea of introducing some flexibility for alternate work flows besides dispatching only during the IETF plenary meeting week sessions.

Now I know that DISPATCH did process some documents, but I wonder if that is something that should be done away with going forward so the WG focus is purely on guiding and dispatching new work.

"The DISPATCH working group may, with the agreement of the relevant
ART, SEC, or WIT ADs, process and have as work items simple administrative
documents for media-type specifications and other IANA actions. Otherwise,
the DISPATCH working group does not process documents."

Why not remove this? Can't it be done elsewhere?

This was discussed on the DISPATCH and SECDISPATCH lists. Originally the idea was create an entirely new group called SAWDISPATCH (or WASDISPATCH), but the consensus was to simply stick with DISPATCH.

[Ballot comment]
I received the necessary clarifications from both Barry and Ben during the IESG telechat. Thanks, Benoit
=============================================================================


(*)  Disclaimer: I've not been following RAI/ART work in the IETF and I don't know whether the DISPATCH process has been efficient or not. So I'll mainly make observations.

I understand Harald's point, https://mailarchive.ietf.org/arch/msg/ietf/-kiAbvZDTCLets4szoXmaCIgrs4,
When I read the charter, it's like an extra procedure, specific to ART. For example, if I want a BoF, I must first go to DISPATCH to get their approval? Same thing for AD-sponsored document?

    The Dispatch working group is chartered to consider proposals for new
    work in the ART area and identify, or help create, an appropriate venue
    for the work.

Btw, no change here: this sentence is basically unchanged compared to the previous charter.

In the past, I was told that DISPATCH was similar to the OPSAWG WG.
Let me observe it's not. "The DISPATCH WG will not do any protocol work", while OPSAWG might.
From the OPSAWG charter:

    The Operations and Management Area receives occasional proposals for
    the development and publication of RFCs dealing with operational and
    management topics that are not in scope of an existing working group
    and do not justify the formation of a new working group. The OPSAWG
    will serve as the forum for developing such work items in the IETF.

Obviously, redirecting work to existing WGs is also an OPSAWG task.
And when the work is substantial, a new WG can even be created. Ex: EMAN  in the past

I prefer the OPSAWG approach (*).

[Ballot comment]

A friendly amendment, if you're up for accepting it: I think a
change along these lines would better reflect what we hope
folks will be doing:

OLD:

5. Ensuring that the new work considers security and privacy.

NEW:

5. Ensuring that the new work considers and aims to improve
security and privacy.

My reason is that while we definitely do want to consider
security and privacy, I think we do have consensus to try to
make those better whenever we can, and to never just say
"yeah, we thought about it, but we're doing nothing." I think
it may be better if we can say that the DISPATCH charter
calls for improvement to handle cases where folks are a
bit reluctant to change a piece of work they bring to the
IETF that hasn't done such a good job on security or
privacy.

[Ballot comment]
(*)  Disclaimer: I've not been following RAI/ART work in the IETF and I don't know whether the DISPATCH process has been efficient or not. So I'll mainly make observations.

I understand Harald's point, https://mailarchive.ietf.org/arch/msg/ietf/-kiAbvZDTCLets4szoXmaCIgrs4,
When I read the charter, it's like an extra procedure, specific to ART. For example, if I want a BoF, I must first go to DISPATCH to get their approval? Same thing for AD-sponsored document?

    The Dispatch working group is chartered to consider proposals for new
    work in the ART area and identify, or help create, an appropriate venue
    for the work.

Btw, no change here: this sentence is basically unchanged compared to the previous charter.

In the past, I was told that DISPATCH was similar to the OPSAWG WG.
Let me observe it's not. "The DISPATCH WG will not do any protocol work", while OPSAWG might.
From the OPSAWG charter:

    The Operations and Management Area receives occasional proposals for
    the development and publication of RFCs dealing with operational and
    management topics that are not in scope of an existing working group
    and do not justify the formation of a new working group. The OPSAWG
    will serve as the forum for developing such work items in the IETF.

Obviously, redirecting work to existing WGs is also an OPSAWG task.
And when the work is substantial, a new WG can even be created. Ex: EMAN  in the past

I prefer the OPSAWG approach (*).

[Ballot comment]
Given this,

"Options for handling new work include:

"- By agreement with ART ADs, processing simple documents."

and this:

"The DISPATCH WG will not do any
protocol work. Specifically, DISPATCH will always opt to find a location
for technical work; the only work that DISPATCH is not required to
delegate (or defer, or reject) is administrative work such as IANA
actions."

If these are describing the same thing, I'd suggest replacing "simple" with "administrative", which I'm reading as more restrictive. Having "simple" being undefined in this context seems vulnerable to mischief ("of course, my document is simple, so it's within charter, right?").

If they aren't describing the same thing, I'd suggest defining "simple".

[Ballot comment]
I think this is ready to progress to external review. However, I invite people to pay attention to the thread that Harald started on the dispatch process in general:

https://mailarchive.ietf.org/arch/msg/ietf/-kiAbvZDTCLets4szoXmaCIgrs4