Re: WG Review: Dispatch (dispatch)

S Moonesamy <[email protected]> Sun, 07 Jun 2026 02:23:44 -0700
Newsgroups gmane.ietf.general
Message-ID <[email protected]>
Hi John,
At 03:42 PM 06-06-2026, John C Klensin wrote:
>Given history, I don't see it that way.  First, and most important,
>it is a forum for giving relevant ADs advice about what should be
>done with a particular proposal ("next steps for..."), with "create a
>mailing list" being only one of a collection of options.  If the
>"move to a dedicated mailing list" terminology appears to constrain
>that range of choices and/or to prohibit either a "this does not
>belong in the IETF" or a "assign to a particular existing WG"
>recommendation, then the text is probably in need of tweaking.
>
>Along the same lines, "topics in the ... areas" can be read as making
>it appropriate for the WG to take up a "topic", rather than, as has
>generally been the case, considering only I-Ds with more or less
>specific proposals.  Some clarification about that might save trouble
>in the future.

A mailing list is a group of email recipients.  Sending an email to 
the list address is a way to reach that group of email 
recipients.  One or more recipients may respond to the email.  I 
assume that a few (or more) of the subscribers of IETF mailing lists 
have experienced not receiving any reply when they sought comments 
about their drafts.  The lack of reaction could be viewed as lack of 
interest in those drafts.  It may happen that there is significant 
reaction; it's generally opposition to those drafts.

Artificial Intelligence (AI) is a topic which has been in the news 
recently.  There were several drafts related to that topic (Eliot 
mentioned that already: 
https://mailarchive.ietf.org/arch/msg/dispatch/kFBietE1FqIE3p8-ZKZb49voV-w 
).  Let's assume that the path taken is to create a mailing 
list.  The point of having the mailing list is to discuss and decide 
what to do about some of those drafts.  I view that as two 
decisions.  Why would two decisions be needed to decide about one outcome?

If I am not mistaken, there used to be an Area meeting.  One of the 
two Area Directors could ask for feedback if he/she wanted to know 
what to do about a draft.

> > The proposed charter allows for great flexibility; it doesn't
> > constrain the working group chair or the relevant area director to
> > do anything.  As an example, the proposed working group may make a
> > recommendation to an area director.  The area director is not
> > required to follow that recommendation though.
>
>I think that is intentional and certainly has been the intent in the
>past.  Do you see that as a problem and, if so, why?

It's not a problem which affects me as I don't have any draft on that track.

>See above.  However, I agree with you that the DISPATCH mailing list
>itself has not proven to be a particularly good place to develop
>ideas.  On the other hand, creating a specialized, topic-specific,
>mailing list too early has had a tendency to confine discussions to
>people with very specific interest in the particular topic of that
>list, rather than encouraging an understanding of the relationship
>among the topic, any proposed solutions deriving from it, and overall
>impact on the Internet.   I have no idea about that other than hoping
>that good judgment is exercised on a case-by-case basis _and_ the
>community in general, and relevant ADs in particular, being aware of
>the risks and tensions.  I don't believe that trying to be more
>specific in the charter document would help much with that.

One of the ways to develop an idea is to get a group of (friendly) 
people together.  The rest is a matter of figuring out how to sweeten the deal.

>No opinion other than to wonder if proposals handled in other ways,
>at least unless they are significantly implemented and deployed
>before getting near the IETF, have a much better success rate.  Do
>you have better ideas?

Significantly implemented is not much of a hurdle these days as there 
are new software development methods, e.g. "vibe coding".   I'll comment below.

>While I (at least mostly) agree, isn't part of the DISPATCH role to
>take the temperature of the community and advise on whether there is
>likely to be sufficient energy to move the work forward?  Again, if
>the charter text appears to discourage efforts to make that
>determination and give advice about it, that text should probably be
>tuned.  I'd consider that part of "provide feedback on... next steps"
>but, if it isn't clear and/or advice about the likely success of a WG
>or list is considered critical, perhaps more words belong in the
>charter.

There are different ways to take the temperature of a 
community.  Using the current request for "review" as an example, it 
can be based on secret feedback.  I am currently indifferent to that approach.

The questions, from my perspective, is which mechanism to used to 
give airtime to AI proposals and picking something which is efficient.

>Yes, often.  But it seems to me that part of the role of a Dispatch
>process is to provide a forum for starting such a discussion.  If
>that fails, it is up to the chairs and relevant ADs to determine that
>actual or potential damage level and what to do about it... and to
>the WG to advise on whether work should move forward if there is
>limited evidence of interest in such a discussion.  It isn't clear to
>me that further charter-tweaking would be likely to help with that.

It's not required to have that in a charter.

>Finally, a more general issue: the charter, as written, makes this
>appear to be an ART WG with responsibility for considering topics
>that may be more relevant to SEC and WIT and advising those ADs.
>Having the charter identify a single AD as responsible for the WG and
>then list only the ADs from the ART Area, seems inconsistent with
>what I had understood from earlier discussions to be shared
>responsibility for the WG with advice given to any or all of the
>three Areas as appropriate.

The topics are an intersection of "crypto" and web-based 
protocols.  The only explanation I could find for ART to be involved 
is that the dispatch mechanism was historically associated with that 
area.  As you mentioned, making an ART WG responsible for work which 
is more relevant to the other two Areas seems inconsistent.

Regards,
S. Moonesamy