[Moq] Re: Draftification

[Ian Swett <[e-mail]>]

I agree with Alan in general and prefer separate drafts, particularly in
the case of Top-N and SSTS.

QUIC was 4 RFCs plus 2 for HTTP/3, and there are many HTTP/3
implementations. I don't believe that people will only read the core draft,
and I don't understand the basis for that claim.

For Top-N and SSTS, the way they work together is apparently workable, but
I think using a single algorithm to do both would be more optimal.  But I
don't have an immediate suggestion.  Maybe if we finish MOQT, we'll get
more people working in this space?

The recent PR#1982 <https://github.com/moq-wg/moq-transport/pull/1982>
demonstrates
thinking about Track Selection is evolving and that's an important reason
not to add it to the core draft.  It puts us in the situation of either
rushing a feature that isn't as mature as we'd like or greatly delaying
publication of MOQT.  There are a number of usecases that have no need for
SSTS or Top-N, so delaying those use cases has cost.

Clearly MOQT needs to have the extensibility to support these extensions,
but I believe it does.

From a practical perspective, PRs that are outstanding for a long time
accumulate large merge conflicts, so unless we have consensus to merge it
into the main draft soon, a PR is unhelpful.  Range Filters had issues
filed in a separate repo, which was very helpful for tracking and working
through issues before we merged it.  That being said, we're still resolving
editorial issues with Range Filters.  When large changes are made to the
draft, it takes a long time for the change to stabilize.

Ian

On Wed, Oct 14, 2026 at 7:59 PM Alan Frindell <afrind=
[e-mail]> wrote:

> In general, I prefer more, smaller drafts rather than one mega draft.
> Smaller drafts are easier to understand, review and revise later, and
> spread the editorial and design load.
>
> I think the number of drafts our group produces is not relevant to
> implementation.  Implementers will implement the features that the
> marketplace demands, regardless of what draft they appear in.  There are
> plenty of protocol extensions that are widely implemented - DATAGRAM is an
> extension to QUIC, Priorities and WebTransport are extensions of HTTP.
> Both features in question already have multiple implementations as well.
>
> No one has articulated a concrete problem with the existing MOQT extension
> model that prevents Top-N or SSTS from being extension drafts.  SSTS is
> already written as an extension draft, and Top-N could easily be.  I’ve
> said many times that getting extensibility right in the core draft is
> critical: please file issues for specific aspects that need to be
> addressed. As others have said, writing these drafts as extensions is an
> excellent pressure test of the extensibility model.
>
> I want to reiterate that I feel both Top-N and SSTS are valuable pieces of
> the MOQ ecosystem and the working group should deliver standards for these
> features. I think continuing to progress these features in their own
> working-group-adopted drafts makes the most sense for now.  I’m also
> comfortable holding parked issues for revisiting the draftification
> decisions at or before WGLC.
>
> The best use of our time now is resolving technical issues in the core
> draft and these proposals, not arguing about which document holds the final
> text.
>
> Thanks
>
> -Alan
>
>
> On Mon, Sep 28, 2026 at 9:33 AM Martin Duke <[e-mail]>
> wrote:
>
>> The chairs are going to initiate a consensus call about the status of
>> various proposed MOQT features – should they be in a separate expansion
>> draft, or should they be in the core MOQT draft? We would like to avoid
>> using meeting time on this
>>
>> The chairs are going to initiate a consensus call about the status of
>> various proposed MOQT features – should they be in a separate expansion
>> draft, or should they be in the core MOQT draft? We would like to avoid
>> using meeting time on this discussion, to the maximum extent possible.
>>
>> The features are top-N: https://github.com/moq-wg/moq-transport/pull/1830
>>
>> and SSTS: https://github.com/wilaw/moqt-ssts
>>
>> We strongly encourage you to read the proposals before participating.
>>
>> There are multiple possibilities for the trajectory that these proposals
>> will take, so it is unlikely that any single trajectory is likely to
>> achieve rough consensus. However, the working group already has rough
>> consensus that it will complete the work in some form.
>>
>> Furthermore, we believe that everyone agrees that both features are, in
>> principle, optional to implement because they are controlled by a Setup
>> option that can be set to zero.
>>
>> For the first phase of the discussion, we would like to set aside
>> short-term document processing, issue management questions, and delivery
>> timelines, and think about these standards far into the future. Would
>> this be better as one RFC or as multiple RFCs? Here are some
>> considerations that the chairs believe you should consider:
>>
>>
>>    -
>>
>>    Does inclusion in the core draft increase the probability a feature
>>    is implemented, and does that matter?
>>    -
>>
>>    Is the feature (and core MOQT) easier or harder to understand with
>>    separate RFCs? Within the working group, people have asserted both
>>    viewpoints.
>>    -
>>
>>    Will the IETF have to revise the feature in the future? If the design
>>    relies on some assumptions that turn out to be false, it would be easier to
>>    revise the feature if it’s specified in a smaller RFC, rather than having
>>    to reopen the entire MOQT RFC.
>>
>>
>> This email does not begin any consensus call, but you are invited to read
>> the proposals, file issues, and start thinking and debating these concerns.
>> It would be great if people read the proposals, thought about the issues,
>> and discussed their concerns on the list by the 13th of October (Tuesday of
>> the Seattle meeting). In fact, interop time would be a lovely time to have
>> high-bandwidth discussions. The chairs will initiate a consensus call soon
>> afterwards, assuming there is adequate discussion on the list.
>>
>>
>> Regards,
>>
>> Magnus and Martin
>>
>> _______________________________________________
>> Moq mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> Moq mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>