My +1 goes to MT too. While I do not have a strong opinion (or knowledge) of the IETF process, I think it would be better to talk about what MT mentioned: supporting use cases, credible solutions, and interested participants.
Let's agree on where the goal is, before starting to discuss how we should reach the goal. 2020年10月7日(水) 12:15 David Schinazi <[email protected]>: > I agree with Martin here. I would personally attend the BoF > and commit to reviewing drafts, but I think that separating > multipath from other work items that are more critical to the > success of QUICv1 is the right thing to do. > > David > > On Tue, Oct 6, 2020 at 7:02 PM Martin Thomson <[email protected]> wrote: > >> I know that this subject line might be taken to be inflammatory, but no >> point in burying the lede. >> >> The original charter for QUIC included multipath, partial reliability, >> and FEC. Multipath was definitely firmer than the others, but it was still >> aspirational. As part of a larger package deal, it seemed OK at the time. >> >> What has become clear to me over time is that there are only a small >> number of people who want to pursue multipath. And I don't know whether >> those people have common use cases or even if a single solution is >> appropriate for all of those use cases. >> >> Right now, it is not clear to me that we have the right combination of >> problem statements (or use cases), plausible solutions, and participants to >> successfully drive toward a design. I've followed the discussion recently >> and this has become increasingly apparent. >> >> The IETF processes for deciding whether to take on new work are designed >> to prove that there is a need for a standard. That need depends on proof >> of three things: supporting use cases, credible solutions, and interested >> participants. That process, by which I mean BoFs, is imperfect, but they >> are the best we have. And it looks like this working group is on a path to >> avoid that process. That would be a mistake. By coasting into a decision >> here, we risk confusing enthusiasm for QUIC as a whole for interest in this >> one feature. >> >> I appreciate that some people believe that there was an understanding >> reached on this topic. I know we've talked about this a number of times. >> But discussion was always about deferral in the past. We're now talking >> about concretely committing time to this. >> >> If the group had nothing else to do, then I'd be less concerned about the >> time being spent on this. I have no real interest, but I could go >> elsewhere. But QUICv1 is hardly done. We have more deployment experience >> to learn from, version negotiation, datagrams, performance tuning, and >> enough stuff to keep this community busy. >> >> If this community is not committed to building multipath capabilities, >> then forcing that upon them would be counterproductive. If the community >> is indeed committed, then a demonstration of that commitment should not be >> difficult to muster. >> >> Deciding whether the IETF should design a multipath QUIC needs to go to a >> BoF. >> >> -- Kazuho Oku
