--On Wednesday, November 27, 2024 10:10 +0000 "Rob Wilton (rwilton)"
<rwilton=40cisco.com@xxxxxxxxxxxxxx> wrote:
> +1 to this and Mark's previous one about a combined dispatch for
> ART/SEC/WIT being helpful.
+1
> One proviso is that the charter for GENAREA needs to be very clear
> about what small things it can take on, and what things really need
> wider community consensus first. And I don't really mean on the
> size of the work, but the potential impact of the work on the
> community or the standards process.
Yes, but I think that, if we were to try to pin that down in a
procedure, the process of defining it might make mod-discuss look
like a quiet, smooth, walk in the park. Instead, it seems to me that
we have to rely on the IETF Chair to make those decisions. Because
they can push an effort into a WG without DISPATChing it, they have
most of that responsibility anyway, and whatever extra time it would
take would likely be less irritating than sitting through YAPM (Yet
Another Pointless Meeting). If we cannot trust them to make that
call, we have, IMO, far greater problems that we should be
addressing. In any event, the usual appeals rules would presumably
apply.
john
> From: Mark Nottingham <mnot=40mnot.net@xxxxxxxxxxxxxx>
> Date: Wednesday, 27 November 2024 at 04:32
> To: Joel Halpern <jmh@xxxxxxxxxxxxxxx>
> Cc: Rich Salz <rsalz@xxxxxxxxxx>, ietf@xxxxxxxx <ietf@xxxxxxxx>,
> alldispatch@xxxxxxxx <alldispatch@xxxxxxxx>, 121attendees@xxxxxxxx
> <121attendees@xxxxxxxx> Subject: [Alldispatch] Re: [121attendees]
> Results of the ALLDISPATCH Experiment (Was: Results and report of
> the IETF 121 post-meeting survey) GENDISPATCH never had a
> conflict-free slot before, and it was fine. I'd actually suggest
> moving away from the DISPATCH model for process/administrative
> things, and just have a standing GENAREA WG that can take on small
> things and request the AD to create WGs for bigger things.
>
>
>
>> On 27 Nov 2024, at 3:28 PM, Joel Halpern <jmh@xxxxxxxxxxxxxxx>
>> wrote:
>>
>> That (two dispatch, one for technical work, and one for process
>> work) would seem to make some sense. Except that it appears to
>> have two major problems.
>>
>> First, that would require two slots that didn't conflict with any
>> other working group.
>>
>> Second, the loading for GenDispatch has seemed quite uneven,
>> meaning that some of the time we would need a session, but nowhere
>> near a full slot. Which seems a waste.
>>
>> I want to second Pete's point that get folks to pay attention
>> across areas is important to the IETF functioning well. I think
>> that encouraging folks to at least be aware of the process
>> activities is also helpful to the health of the organization.
>>
>> I do think it wouldn't hurt to remind chairs, etc. that most stuff
>> doesn't need to be dispatched. It can be sent directly to the
>> proper working group, or sent to a BoF. Dispatching is for things
>> where the path is not clear. (Unfortunately, a lack of clarity in
>> how to handle them seems to be the only common property of process
>> work.)
>>
>> Yours,
>>
>> Joel
>>
>> On 11/26/2024 10:44 PM, Salz, Rich wrote:
>>>> Personally - I think that combining DISPATCH (what used to be
>>>> Applications I mean ART I mean WIT) and SECDISPATCH makes sense,
>>>> because there's a lot of overlap.
>>> I agree with this, maybe it doesn't go far enough.
>>>
>>>> GETDISPATCH, however, is a somewhat different beast. Discussions
>>>> about how to change our process and similar things need more
>>>> iteration, and are more > appropriate (IMO) in something like a
>>>> GENAREA WG. Lumping them in with technical proposals leads to a
>>>> lack of consideration in discussion.
>>> Yes, this is the key thing. GENDISPATCH is not like the others.
>>> And perhaps merging *all other dispatch* together is a worthwhile
>>> experiment, leaving GENDISPATCH off on its own.
>>>
>>>
>
> --
> Mark Nottingham https://www.mnot.net/
>
> --
> Alldispatch mailing list -- alldispatch@xxxxxxxx
> To unsubscribe send an email to alldispatch-leave@xxxxxxxx
