[Moq] Spencer's thoughts on Next Steps and Adoption Polls (was: Re: [MoQ] Next Steps)

[Spencer Dawkins at IETF <[e-mail]>]

I'm just catching up with the previous thread (something about a blizzard
of I-Ds dropping just before the I-D cutoff, as Luke mentioned at the start
of that thread). 😎

I want to start by echoing Will's kind and accurate words. Luke, you've
been awesome. I wish you the very best, and the first thing I did when I
read that you were leaving Twitch was to make sure you weren't using a
Twitch-related email address, so that we can all stay in touch with you.
And I'm glad you plan to continue to contribute to MOQ.

Back to the other things Luke said in his highly accurate email that
started the earlier thread ...

   - I would expect a chair's poll on adoption to be something like "is
   this draft a reasonable start on a chartered deliverable for the working
   group to adopt, and use as a basis for its work?"
   - As Luke noted, adopting a draft as a basis for our work means that the
   chairs would assign one or two people (editors) to figure out what the
   working group thinks, as a working group, on any particular point, and
   capture what the working group thinks in the draft.

Is that close to what the chairs think "adoption" means?

I see in https://notes.ietf.org/notes-ietf-interim-2023-moq-05-moq  "[Alan
to Draft owners] Publish a new version (revision) of draft with some
learnings we had, and perhaps ask that for adoption in the next IETF
meetings as starting point"

*Luke asked for adoption of draft-lcurley-warp-04
<https://datatracker.ietf.org/doc/draft-lcurley-warp/> earlier in this
thread.*

*I'll ask the chairs to poll for adoption
on draft-gruessing-moq-requirements-04
<https://datatracker.ietf.org/doc/draft-gruessing-moq-requirements/> now.*

*Do we need to wait until we're in Yokohama to start the polls?*

As Luke also noted, we have many awesome drafts (and more this week than we
had last week!), but we haven't adopted any drafts yet.

   - Our chartered milestones (reading bottom to top) are
   - Protocol specification (one presumes "over QUIC streams") (Luke
      requested a poll for adoption for WARP)
      - Protocol specification using datagram extension
      - Architecture
      - Use cases and Requirements (Spencer requestat a poll for adoption)
   - I just checked with James, and we both agree that a minimal
   architecture description - which I think working group participants have,
   scattered in bits and pieces - would be a huge help in describing
   requirements. James and I had both started PRs on this, but we didn't
   submit them in -04, because we hope we'll be able to reference an
   architecture draft, rather than creating our own architecture.
   - I'd support the working group spend some time on architecture, so that
   we won't be cycling on what functional elements do, or don't do, in our
   conversations
   - I know that Luke had started, but then stopped work on, a terminology
   draft, and Ali said he would be working on that.
   - James and I would also find agreed terminology very helpful.
   - I'd support us spending time on agreeing terminology as well.

Perhaps others have thoughts?

Best,

Spencer

On Sun, Mar 19, 2023 at 11:56 PM Law, Will <wilaw=
[e-mail]> wrote:

> @Luke  - confirming that I (now) appreciate that adoption of a draft is
> not an immutable codification of its current state. The list came alive
> this weekend with good questions being asked around Webtransport vs Quic/
> Bundles/ Objects.. I had sent a reply to this thread last week in which I
> had listed five “primary differences” as a response to your question ‘What
> are the blockers to adoption?”. I still believe they deserve (and in fact
> are receiving) debate, however I’ll rescind the term ‘blocker’ in favor of
> ‘items-deserving-strong-debate-post-adoption’.
>
>
>
> Your mic-drop on leaving Twitch (and the double entendre of this thread
> title)  got buried in all this activity. That’s unfortunate, as you have
> been the cheerleader and a public face of MoQ well before the BoF. I speak
> for many when I say that I look forward to close cooperation over the next
> 6 months, am excited about your open source projects and demos and hope
> that you remain near and central to MoQ in the years ahead.
>
>
>
> Cheers
>
> Will
>
>
>
>
>
> *From: *Luke Curley <[e-mail]>
> *Date: *Sunday, March 19, 2023 at 2:39 PM
> *To: *"Law, Will" <[e-mail]>
> *Cc: *Victor Vasiliev <vasilvv=[e-mail]>, MOQ Mailing
> List <[e-mail]>
> *Subject: *Re: [Moq] [MoQ] Next Steps
>
>
>
> I talked to Will via Slack. He wasn't aware of the difference between
> adoption and an RFC.
>
>
>
> Adoption basically just means transferring ownership from the draft
> authors to the working group. The working group would be responsible for
> the modification process going forward. Any published standard would still
> be years away and might not even resemble Warp.
>
>
>
> Will said if that's the case, he's not a blocker to adoption. He should
> confirm of course.
>
>
>
> ---
>
>
>
> Oh yeah, and I'm leaving my job at Twitch. My plan is to work on MoQ for a
> few months mostly building open source libraries and demos (moq.js
> first). I'll have too much time on my hands, which is also why I don't feel
> comfortable owning the draft because I'll be tempted to make changes
> without consensus. I'll still contribute PRs, but I don't feel comfortable
> being the impartial gatekeeper.
>
>
>
> On Thu, Mar 16, 2023, 5:21 PM Law, Will <[e-mail]> wrote:
>
> Hi Victor,
>
>
>
> “*Regarding issue number 5, I believe we all agree that MoQ base protocol
> should treat the payloads as opaque, meaning the contents of objects are
> defined by whatever format you're using.  We're chartered to support "one
> or more media formats"; the WARP draft currently defines a binding for
> fMP4, but it's only one section, and it can be split into its own draft if
> needed*.”
>
> Agreed. I would comment that WARP is a challenging name for a common base
> draft, when Twitch has been using that name to describe one particular
> variant of it, namely a fMP4-based GOP-per-stream solution. I think it
> would be clearer if we renamed it as bikeshed(“MoQ Base Protocol”) and then
> as you suggested, broke out the fmp4 binding, required inits and catalog
> definition into a separate draft called WARP that normatively referenced
> MoQBP. Then we present a clearer picture of how the building blocks go
> together and how adjacent formats, optimized for different use-cases, would
> coexist and operate on the same base protocol.
>
>
>
> “*Could you elaborate (or link a GitHub issue, if one already exists)
> what you mean by 2?”*
>
> Yes – I think its best illustrated by this email thread
> https://mailarchive.ietf.org/arch/msg/moq/UqG0nPGOB3lZVzBaKox2MK9TeZY/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/moq/UqG0nPGOB3lZVzBaKox2MK9TeZY/__;!!GjvTz_vk!U6IpeRuvRDgr-7Yz30h3XK2eUVt6QI_RHqb7Yo63LdQbWN0t1Va8Ug07vBz-Ta9nkRq0Y96A1w6ErS0$>
> . There are a lot of comments to parse, but within that I believe lies the
> unresolved question as to whether tracks should be “crafted to guarantee
> appropriate uniqueness” across distribution networks, or , as is the case
> with current WARP-04 draft, given a track ID that is unique only within the
> track bundle.
>
>
>
> Cheers
>
> Will
>
>
>
>
>
>
>
>
>
> *From: *Victor Vasiliev <vasilvv=[e-mail]>
> *Date: *Thursday, March 16, 2023 at 3:46 PM
> *To: *"Law, Will" <[e-mail]>
> *Cc: *Luke Curley <[e-mail]>, MOQ Mailing List <[e-mail]>
> *Subject: *Re: [Moq] [MoQ] Next Steps
>
>
>
> Hi Will,
>
>
>
> Regarding issue number 5, I believe we all agree that MoQ base protocol
> should treat the payloads as opaque, meaning the contents of objects are
> defined by whatever format you're using.  We're chartered to support "one
> or more media formats"; the WARP draft currently defines a binding for
> fMP4, but it's only one section, and it can be split into its own draft if
> needed.
>
>
>
> Could you elaborate (or link a GitHub issue, if one already exists) what
> you mean by 2?
>
>
>
> Thanks,
>
>   Victor.
>
>
>
> On Thu, Mar 16, 2023 at 5:58 PM Law, Will <wilaw=
> [e-mail]> wrote:
>
> Re “*What are the blockers to adoption?”*
>
>
>
> I’d say the primary differences remain around
>
>
>
>    1. Object and group properties
>    2. Where does uniqueness lie – at the track or collections-of-tracks
>    (broadcast/emission) level?
>    3. Prioritization schemes and how each transmitting node should react
>    to congestion
>    4. Binding of WebTransport sessions (and Quic connections) to content
>    identification
>    5. Should the MoQ spec define the payloads of objects, or should that
>    be done by other specs which extend a MoQ base protocol?
>
>
>
> These are all nuanced subjects with many opinions already expressed on
> issue threads and the mailing list. IETF#116 would be an excellent time to
> seek consensus on these issues.
>
>
>
> -Will
>
>
>
>
>
> *From: *Luke Curley <[e-mail]>
> *Date: *Thursday, March 16, 2023 at 10:59 AM
> *To: *MOQ Mailing List <[e-mail]>
> *Subject: *[Moq] [MoQ] Next Steps
>
>
>
> Hey MoQ,
>
>
>
> It was exciting to see the drafts flood in on the last hour before the
> deadline. There's a lot of good ideas in there and a lot of things that
> this working group should tackle.
>
>
>
> However, as a working group, we have no adopted drafts. There's no base to
> build on. There's a lot of avenues to explore but we're at a standstill
> until we can agree on a starting point.
>
>
>
> I propose we adopt the Warp draft. The authors are having trouble building
> any more consensus with an ID, and it's time the IETF process takes over.
>
>
>
> What are the blockers to adoption? The chairs and authors identified and
> annotated two issues in the lastest draft: the properties of an object
> <https://urldefense.com/v3/__https:/github.com/kixelated/warp-draft/pull/99/files__;!!GjvTz_vk!WVUayR8H4_M3XSpCTeg-1CLTGaZIWTNsN-vYd3kiOLbPqoC-HTU_RgW_LGIay0oBXkKC2W4LbSJXb7A$>
> and a group
> <https://urldefense.com/v3/__https:/github.com/kixelated/warp-draft/pull/100/files__;!!GjvTz_vk!WVUayR8H4_M3XSpCTeg-1CLTGaZIWTNsN-vYd3kiOLbPqoC-HTU_RgW_LGIay0oBXkKC2W4LMLaE0xs$>.
> Are there other, specific issues that would block adoption? Could you
> please raise them now so we can get them onto the agenda.
>
>
>
> I propose we spend the first part of the upcoming IETF meeting discussing
> these blockers. I think it's the most productive usage of our time, as it's
> difficult to have meaningful discussions about how media/catalog is
> encoded, or about the interactions in the MoQ ecosystem, if we can't nail
> down the base properties of the transport.
>
>
>
> Also, I'd like to find another editor as part of the adoption process. I
> don't have enough experience with IETF best practices... and I'm not the
> most diplomatic. It's also quite difficult to divest myself after spending
> the last 3 years implementing Warp and all of the baggage that entails.
>
>
>
>
>
> -- Luke
>
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/moq__;!!GjvTz_vk!UVLknm4TOhmlOVcSxGRK9NkMU4weXM5HJNepAu598zFRif_R2OWloYNgcsJk1GvfqrI87CrawZ1LC6uWJcHdIdMYCUvx$>
>
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
>