[Moq] Summary from Call for Adoption: Use Cases and Requirements for Media Transport Protocol Design

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

Dear MOQ,

The MOQ chairs polled the working group on adoption of
draft-gruessing-moq-requirements-04
<https://datatracker.ietf.org/doc/draft-gruessing-moq-requirements/> on
March 25, asking for feedback by April 16 (extended due to overlap with
IETF 116 meeting dates).

TL;DR: So far, the chairs and I have seen two responses to the poll, and
James and I know what to do with draft-gruessing-moq-requirements-04
<https://datatracker.ietf.org/doc/draft-gruessing-moq-requirements/>, based
on the comments we've received, before submitting a working group -00
version as a basis for further work.

But it is fair to note that we haven't gotten a lot of feedback.

   -

   If you think our responses to the comments summarized below will lead
   MOQ to a draft revision that's suitable for adoption, it would be great to
   say that, even if it's just saying +1 on the mailing list.
   -

   If you think other changes are required before you could support
   adoption of this draft, please tell us - ideally by May 1, so that we
   can provide a draft revision before the next MOQ meeting (which is likely
   to be an interim, based on discussions at IETF 116).


The details follow.

Best,

Spencer

Bernard Aboba replied on April 4
<https://mailarchive.ietf.org/arch/msg/moq/CfdP-_fIhgV2nME-w0GaKc8_2Tw/>,
with a "not suitable for adoption" and comments. After trading email with
Bernard, here's what I think is needed before adoption.

   -

   Bernard was concerned with the structure of the document, providing RFC
   7478 <https://www.rfc-editor.org/rfc/rfc7478> as an example of a better
   structure.
   -

   After discussion with Bernard, it seems that the real problem is that
   the use cases in draft-gruessing-moq-requirements-04
   <https://datatracker.ietf.org/doc/draft-gruessing-moq-requirements/> are
   not described in enough detail to analyze for requirements, or even to
   spell out what the differences are between (say) remote desktop and gaming.
   I'm sympathetic to that point of view, since we haven't discussed MOQ use
   cases in detail since the charter discussions nearly a year ago.
   -

   Bernard suggested that we focus on describing specific use cases in more
   detail, focusing on use cases that are most likely to benefit from adoption
   of MOQ (so, do they need ingest, do they need relays, etc.) His suggestion
   is to focus on live sporting events first, because it combines
   requirements for high production values, low latency and high scale. Live
   sports has also included features such as “rewind”, audience feedback,
   co-watching and  “together mode”, and I agree with that.
   -

   We've had an open issue to Agree on attributes for each use case that we
   need to drive requirements for protocol engineering
   <https://github.com/fiestajetsam/draft-gruessing-moq-requirements/issues/74>
   for a while.
   -

   My suggestion is that we work through live sporting events*, and use the
   resulting set of attributes as a template for further use cases*.


Lucas Pardue replied on April 12
<https://mailarchive.ietf.org/arch/msg/moq/qOjHbWpGyhRsIiaUgZHgB3EWGRk/>,
with a "suitable candidate for adoption" response, and comments.

   -

   It's not perfect and needs further development but that is sort of the
   point of adopting it.
   -

      I agree with this point, especially given Bernard's comments above.
      -

   If we don't adopt this document now, when and how would we expect that
   milestone to be achieved?
   -

      That's an excellent question, of course.
      -

   As a point of administration, I don't see a corresponding milestone for
   submission of a document to the IESG. Can I ask the chairs to clarify if
   the intention is to adopt and develop a draft but not seek taking it
   through to an RFC*?
   -

      I replied to this one, not as a MOQ chair, saying that the omission
      was intentional (if I remember correctly) and is consistent with the
      IESG statement on support documents
      <https://www.ietf.org/about/groups/iesg/statements/support-documents/>
      (a reasonable summary is "don't publish informational working group
      documents in archival series unless they have archival value").
      -

      Unless the chairs see this differently, *it's worth us adding a
      statement about that in the draft itself, because we've been asked about
      this on at least three occasions. *