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/ >
