I think this is a good idea, for all the reasons Tommy cited. I would not want to make this change just because getting good AD candidates is difficult, but I do think there are other good reasons, including the relative sizes of the areas.
Ian
On Fri, Sep 8, 2023 at 11:35 AM Tommy Pauly <tpauly=40apple.com@xxxxxxxxxxxxxx> wrote:
I think the arrangement you suggest (go down to one TSV AD) is a viable option here — if we don’t do the rearrangement, I hope we do that instead. I would still want to see groups like IPPM and ALTO move out of TSV in that case.
However, I think the rebalancing is still more useful. Two main reasons here:
- ART has a ton of groups, many of which don’t need to overlap for scheduling — it already has many different tracks. TSV would be quite small, but a number of the groups that are left (QUIC, MASQUE) do overlap with one of those subsets from ART, specifically the HTTP-centric groups.
- We already have groups that straddle the boundary (MASQUE and WEBTRANS specifically come to mind), and I expect that will continue. The new area definition gives those groups and future similar groups a clear home, rather than being in the liminal space between two unbalanced areas.
Thanks,
Tommy
> On Sep 8, 2023, at 8:21 AM, Mark Nottingham <mnot@xxxxxxxx> wrote:
>
> Perhaps that could work. I'm still not seeing why it's preferable to the arrangement I described: one dedicated TSV AD, who relies upon multiple ADs for backup when needed.
>
> Cheers,
>
>
>> On 8 Sep 2023, at 5:18 pm, Tommy Pauly <tpauly@xxxxxxxxx> wrote:
>>
>>
>>
>>> On Sep 8, 2023, at 8:14 AM, Mark Nottingham <mnot@xxxxxxxx> wrote:
>>>
>>> (trying to correct the CC: line)
>>>
>>>> On 8 Sep 2023, at 5:10 pm, Tommy Pauly <tpauly@xxxxxxxxx> wrote:
>>>>
>>>> to Mark’s point, this does make the coverage/failover story a bit awkward, and I’m not sure we benefit by a having a sharp line. Since there is so much overlap in participants here, I think we could be well-served by two ADs who both work on both QUIC and HTTP/3 for example. The NomCom could be given guidance to try to make sure the AD pair isn’t too lopsided, but I think it would be cleaner to just have a unified new area.
>>>
>>> I'm concerned this would be limiting -- HTTP is more than transport, despite recent focus on that in /2 and /3. Having an AD who understands things primarily from an application protocol standpoint is something I'd be reluctant to lose.
>>
>> I certainly agree that HTTP is more than transport, but given the difficulty we’ve found in finding transport ADs over the past several years, I was imagining more that we’d end up with the two ADs for this new area potentially both leaning to be more application-focused in the lopsided case.
>>
>> Best,
>> Tommy
>>
>>>
>>> Cheers,
>>>
>>> --
>>> Mark Nottingham https://www.mnot.net/
>
>
> --
> Mark Nottingham https://www.mnot.net/
>
