Code change:
One small normative change: I relaxed a SHOULD to a MAY when discussing relays writing data out of order. No one is implementing this right now.
Here are some editorial notes on the document Line 72. “MOQT is a generic protocol is designed to work” Line 91-93. “The development of MOQT is driven by goals in a number of areas - specifically latency, the robustness of QUIC, workflow efficiency and relay support.” This sentence is intriguing. What does the robustness of QUIC mean? Latency, workflow efficiency, relay support are not “areas” or maybe area should be defined. (side note on the missing Oxford comma in this sentence) The Section 1.1.1. Latency as a whole is very confusing. HTTP-based streaming is not designed for low latency mostly due to the essential request-response paradigm. Queuing on the path has a insignificant impact on the end-to-end latency for HAS. The “speed at which a protocol can detect queuing” is not related to the relatively high latency issues of HAS. Overall, I see a mix of unrelated subjects here, which makes the paragraph overall meaningless. I would recommend starting the paragraph with a topic sentence (which may be the last one of the current paragraph). Line 120. “Applying QUIC to HAS …” (and the following sentences) is not necessary. The reasons for which QUIC does not bring advantages to HAS are still debatable on many points. This QUIC-on-HAS remark could raise unnecessary questions although the beginning of Section 1.1.2 is clear and sufficient to convey the message. Line 125. “Universal” has a too broad sense. Do you mean “Unicity of protocol in the whole pipeline” (or something like this)? Line 127. “Internet delivered media today has protocols optimized for ingest…” I don’t understand this sentence. Line 127. Some examples of protocols could be good to support these claims. Note that WHIP is an attempt to unify the protocol. Line 146. “to treat relays as first-class citizens of the protocol” is an excellent marketing message but it does not mean anything in a technical norm. Furthermore, see my two reserves above. I’d claim that the current draft is not making relay first-class, on the contrary. Line 179. “a join point” joint? Line 231. “The application is solely responsible for the content of the object payload.” What is the application? It is a bit confusing. It has not been defined. Line 269 .“within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.” I am not sure to understand this sentence. Is a single MOQT scope a scope with only one server or do you mean “within a MOQT scope”? the two “same” adjectives are confusing too. Line 273. It would be better to stick to “servers” or to “connection URIs” to refer to the elements of the scope. Line 339. “The portion MUST NOT contain a non-empty portion.” Is it a double negation to say that the ‘authority’ MUST contain an empty ‘host’ portion? Line 357. This sentence may require a MUST. Line 359. “for exchanging …” and following sentences are not related to session initialization. They are rather remarks that would be a fit with the draft Section 4. +1 to the TODO remarks on line 381. This should be in Section 4. Line 654. “it allows the peers…” The term “peer” is used 7 times. It is supposed to be an “endpoint” (as defined Line 173), unless peer and endpoint have different meaning (in which case peer must be defined) Line 693. “A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.” I don’t understand this claim.
Thanks for the feedback. I'm going to mark this as Editorial, but there are a number of points here. If you believe any of them are not editorial (ie: "Line 357. This sentence may require a MUST."), please split into a separate issue.
Will assign to Mo.
NAME Please go through these and fix any that still apply.

Related discussion:
text: 3.3. The first stream opened is a client-initiated bidirectional control <del> stream where the peers exchange Setup messages (message-setup).  All messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the Setup message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </del> <ins> stream where the endpoints exchange Setup messages (message-setup). All messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the Setup message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </ins> This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no