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/
