Re: [Alldispatch] Results of the ALLDISPATCH Experiment (Was: Results and report of the IETF 121 post-meeting survey)

[Phillip Hallam-Baker <[e-mail]>]

The cases when dispatching is needed are probably limited to:

1) Possible conflict with other organizations

2) The answer is probably 'have a BOF'

3) There is possible conflict between existing WGs.

Why not go straight to a BOF? Well quite often the person bringing a
problem to IETF does not have the best solution and you want to hammer on
the solution space before the BOF. Case in point, I remember one WG where
at the very first meeting I said what we needed was to devise a way to do
lightweight sub-TLS over UDP. And everyone said 'oh no, we got to do this
fast, we are going to have to use this experimental quickstart TCP that
nobody actually supports today because changing all the O/S kernels will be
so much faster than making something TLS like work over UDP. And then ten
years later I was the SECDIR reviewer for doing it over QUIC...

I am always very suspicious of proposals of the form 'we just got to do it
this way because we don't have time'. And I am especially suspicious when
people are saying that we can only consider this experimental framework
protocol we developed and nobody is using it because deployment requires
multiple stakeholders to adopt it before it works.


The problem I am having with the last dispatch is one of followup. At the
last dispatch, someone said a problem is 'impossible'. Now I have running
code which provides three separate solutions with different limitations,
one of which could become a universal solution.

There was a proposal for a BOF. But surely we should have discussions
before a BOF? Surely there should be a mailing list where people with
proposals could discuss before we arrive? Maybe we can come to an agreement
on a common approach before the BOF in which case the BOF can be shorter.

Where can I find out what the followup is? I would be rather displeased if
the BOF ends up being an in-crowd with one particular view presenting their
proposal.


I think we are going to need a BOF in that case because the problem in
question cuts across multiple areas of existing IETF work and is going to
be constrained by each.


On Tue, Nov 26, 2024 at 5:10 PM Stephen Farrell <[e-mail]>
wrote:

>
>
> On 26/11/2024 21:58, Pete Resnick wrote:
> > Someone tell me why I'm wrong.
>
> Because dispatch sessions are being used to add more hoops through
> which people need jump.
>
> Person: "Hi WG, I have this idea..."
>
> Chair: "Not sure, goto dispatch"
>
> Dispatch: "Not sure, have a BoF"
>
> BoF: "You should goto WG"
>
> Person: "That's were I started but the chairs bottled it
> and pushed me to go all around the dispatch world just to
> get back here again."
>
> I've seen stuff like that happen. We're doing too much of
> this dispatching and making some obvious things harder and
> take longer. (Where the obvious answer might be yes/no/BoF/
> etc. or "This WG will take it on, if other-WG doesn't have
> a problem")
>
> The only times where dispatching is needed is in the rare
> case when it's not obvious how to get the answer referred
> to above. (That does not mean the actual answer is obvious
> but that how to get the answer is obvious.)
>
> Cheers,
> S.
>
>