Skip to main content

Dispatch
charter-ietf-dispatch-04

Yes

(Alissa Cooper)
(Barry Leiba)
(Jari Arkko)

No Objection

(Alvaro Retana)
(Brian Haberman)
(Deborah Brungard)
(Joel Jaeggli)
(Martin Stiemerling)
(Terry Manderson)

Note: This ballot was opened for revision 02-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

Alissa Cooper Former IESG member
Yes
Yes (for -02-00) Unknown

                            
Barry Leiba Former IESG member
Yes
Yes (for -02-00) Unknown

                            
Ben Campbell Former IESG member
Yes
Yes (2016-01-28 for -02-00) Unknown
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
Jari Arkko Former IESG member
Yes
Yes (for -02-00) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2016-02-01 for -02-00) Unknown
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".
Alvaro Retana Former IESG member
No Objection
No Objection (for -02-00) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2016-02-04 for -02-01) Unknown
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 (*).
Brian Haberman Former IESG member
No Objection
No Objection (for -02-00) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -02-00) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -02-00) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -02-00) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2016-02-04 for -02-00) Unknown
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.
Terry Manderson Former IESG member
No Objection
No Objection (for -02-00) Unknown