jiebi/TextFlow huggingface dataset:
Original text:
security is "sender-to-receiver", but some "ends" may not be either senders or ultimate receivers, from a certain point of view.  5. This document makes no requests of IANA.

Reviewer comments:
NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.

Revised text:
security is "sender-to-receiver", but some "ends" may not be either senders or ultimate receivers, from a certain point of view. <ins> 4.8.1. </ins> 5. This document makes no requests of IANA.
Original text:
Our goal in this section is to understand the requirements that result from the use cases described in overallusecases.  *Note: the initial high-level organization for this section is taken from Suhas Nandakumar's presentation, "Progressing MOQ" Prog-MOQ, at the October 2022 MOQ virtual interim meeting, which was in turn taken

Reviewer comments:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Revised text:
Our goal in this section is to understand the requirements that result from the use cases described in overallusecases. <ins> 4.1. Note: the intention for the requirements in this document is that they are useful for MOQ working group participants, to recognize constraints, and useful for readers outside the MOQ working group to understand the high-level functionality of the MOQ protocol, as they consider implementation and deployment of systems that rely on the MOQ protocol. </ins> *Note: the initial high-level organization for this section is taken from Suhas Nandakumar's presentation, "Progressing MOQ" Prog-MOQ, at the October 2022 MOQ virtual interim meeting, which was in turn taken
Original text:
TODO: Describe overall, high level requirements that we previously stated in earlier versions of this document. <del> 4.1. </del>  Many of the use cases have bi-directional flows of media, with clients both sending and receiving media concurrently, thus the

Reviewer comments:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Revised text:
TODO: Describe overall, high level requirements that we previously stated in earlier versions of this document.  <ins> 4.2. </ins> Many of the use cases have bi-directional flows of media, with clients both sending and receiving media concurrently, thus the
Original text:
is unsupported (e.g. a live media server signalling it does not support receiving from a given client). <del> 4.2. </del>  In the initiation of a session both client and server must perform negotiation in order to agree upon a variety of details before media

Reviewer comments:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Revised text:
is unsupported (e.g. a live media server signalling it does not support receiving from a given client).  <ins> 4.3. </ins> In the initiation of a session both client and server must perform negotiation in order to agree upon a variety of details before media
Original text:
Re-negotiation in an existing protocol should be supported to allow changes in what is being sent of received. <del> 4.3. </del>  As multiple streams of media may be available for concurrent sending such as multiple camera views or audio tracks, a means of both

Reviewer comments:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Revised text:
Re-negotiation in an existing protocol should be supported to allow changes in what is being sent of received.  <ins> 4.4. </ins> As multiple streams of media may be available for concurrent sending such as multiple camera views or audio tracks, a means of both
Original text:
should be supported, but further extended metadata of the contents of the media or its ontology should not be supported. <del> 4.4. </del>  Packaging of media describes how encapsulation of media to carry the raw media will work.  There are at a high level two approaches to

Reviewer comments:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Revised text:
should be supported, but further extended metadata of the contents of the media or its ontology should not be supported.  <ins> 4.5. </ins> Packaging of media describes how encapsulation of media to carry the raw media will work.  There are at a high level two approaches to
Original text:
packaging of media, taking into consideration the various technical trade offs that each provide. <del> 4.5. </del>  End-to-end security describes the use of encryption of the media stream(s) to provide confidentiality in the presence of unauthorized

Reviewer comments:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Revised text:
packaging of media, taking into consideration the various technical trade offs that each provide.  <ins> 4.6. </ins> End-to-end security describes the use of encryption of the media stream(s) to provide confidentiality in the presence of unauthorized
Original text:
5. <del> This document makes no requests of IANA. </del>  6.  As this document is intended to create discussion and consensus and introduces no security considerations of its own. <del> 7.  References </del>  <del> 7.1.  URIs </del>  [1] https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing- moq-requirements

Reviewer comments:
NAME I could also include some other non-requirements into the section if you have some to mind.
A similar section seemed helpful during discussion of URL My first nominee (and I'll put that in the corresponding PR) is that we're assuming that we're working with existing media transport protocols like RTP and SRP, rather than inventing a new media transport protocol in the IETF, but we can talk when I have text.
We have this in place, and I think we have enough non-requirements to start with, let's keep adding as appropriate.

Revised text:
5.  <ins> This section covers topics that are explicitly out of scope for the time being. 5.1. The creation of new media transport protocols should be avoided, and instead we should make use of RTP RFC3550 and the existing ecosystem of payload formats and methods of signalling where possible.  It may transpire a need to extend these specificiations; in which case we should work with the relevant working groups and present our use- cases. </ins> 6. <ins> This document makes no requests of IANA. 7. </ins> As this document is intended to create discussion and consensus and introduces no security considerations of its own.  <ins> 8.  References </ins>  <ins> 8.1.  URIs </ins> [1] https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing- moq-requirements
Original text:
This document defines the core behavior for Warp, a live media transport protocol over QUIC.  Media is split into objects based on the underlying media encoding and transmitted independently over QUIC <del> streams.  QUIC streams are prioritized based on the delivery order, </del>  allowing less important objects to be starved or dropped during congestion.

Reviewer comments:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Revised text:
This document defines the core behavior for Warp, a live media transport protocol over QUIC.  Media is split into objects based on the underlying media encoding and transmitted independently over QUIC  <ins> streams.  QUIC streams are prioritized based on the send order, </ins> allowing less important objects to be starved or dropped during congestion.
Original text:
The encoder determines how to fragment the encoded bitstream into objects (media). <del> Objects are assigned an intended delivery order that should be obeyed during congestion (delivery-order) </del>  The decoder receives each objects and skips any objects that do not arrive in time (decoder).

Reviewer comments:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Revised text:
The encoder determines how to fragment the encoded bitstream into objects (media).  <ins> Objects are assigned an intended send order that should be obeyed during congestion (send-order) </ins> The decoder receives each objects and skips any objects that do not arrive in time (decoder).
Original text:
this ordering during congestion without increasing latency. The encoder determines how to behave during congestion by assigning <del> each object a numeric delivery order.  The delivery order SHOULD be followed when possible to ensure that the most important media is delivered when throughput is limited.  Note that the contents within each object are still delivered in order; this delivery order only applies to the ordering between objects. </del>  A sender MUST send each object over a dedicated QUIC stream.  The QUIC library should support prioritization (prioritization) such that <del> streams are transmitted in delivery order. </del>  <del> A receiver MUST NOT assume that objects will be received in delivery </del>  order for a number of reasons: <del> Newly encoded objects MAY have a smaller delivery order than </del>  outstanding objects. <del> Packet loss or flow control MAY delay the delivery of individual </del>  streams. The sender might not support QUIC stream prioritization.

Reviewer comments:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Revised text:
this ordering during congestion without increasing latency. The encoder determines how to behave during congestion by assigning  <ins> each object a numeric send order.  The send order SHOULD be followed when possible to ensure that the most important media is delivered when throughput is limited.  Note that the contents within each object are still delivered in order; this send order only applies to the ordering between objects. </ins> A sender MUST send each object over a dedicated QUIC stream.  The QUIC library should support prioritization (prioritization) such that  <ins> streams are transmitted in send order. </ins>  <ins> A receiver MUST NOT assume that objects will be received in send </ins> order for a number of reasons:  <ins> Newly encoded objects MAY have a smaller send order than </ins> outstanding objects.  <ins> Packet loss or flow control MAY delay the send of individual </ins> streams. The sender might not support QUIC stream prioritization.
Original text:
The decoder will receive multiple objects in parallel and out of order. <del> Objects arrive in delivery order, but media usually needs to be processed in decode order.  The decoder SHOULD use a buffer to reassmble objects into decode order and it SHOULD skip objects after a configurable duration.  The amount of time the decoder is willing to wait for an object (buffer duration) is what ultimately determines </del>  the end-to-end latency. Objects MUST synchronize frames within and between tracks using

Reviewer comments:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Revised text:
The decoder will receive multiple objects in parallel and out of order.  <ins> Objects arrive in send order, but media usually needs to be processed in decode order.  The decoder SHOULD use a buffer to reassmble objects into decode order and it SHOULD skip objects after a configurable duration.  The amount of time the decoder is willing to wait for an object (buffer duration) is what ultimately determines </ins> the end-to-end latency. Objects MUST synchronize frames within and between tracks using
Original text:
this to priority-congestion. The producer may assign a numeric delivery order to each object <del> (delivery-order) </del>  This is a strict prioritization scheme, such that any available bandwidth is allocated to streams in ascending priority order.  The <del> sender SHOULD prioritize streams based on the delivery order.  If two streams have the same delivery order, they SHOULD receive equal bandwidth (round-robin). </del>  QUIC supports stream prioritization but does not standardize any mechanisms; see Section 2.3 in QUIC.  In order to support

Reviewer comments:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Revised text:
this to priority-congestion. The producer may assign a numeric delivery order to each object  <ins> (send-order) </ins> This is a strict prioritization scheme, such that any available bandwidth is allocated to streams in ascending priority order.  The  <ins> sender SHOULD prioritize streams based on the send order.  If two streams have the same send order, they SHOULD receive equal bandwidth (round-robin). </ins> QUIC supports stream prioritization but does not standardize any mechanisms; see Section 2.3 in QUIC.  In order to support
Original text:
priority order. The sender MUST respect flow control even if means delivering streams <del> out of delivery order.  It is OPTIONAL to prioritize retransmissions. </del>  6.2.

Reviewer comments:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Revised text:
priority order. The sender MUST respect flow control even if means delivering streams  <ins> out of send order.  It is OPTIONAL to prioritize retransmissions. </ins> 6.2.
Original text:
Warp encodes the delivery information for a stream via OBJECT headers (message-object). <del> A relay SHOULD prioritize streams (prioritization) based on the delivery order.  A relay MAY change the delivery order, in which case it SHOULD update the value on the wire for future hops. </del>  A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.  Packet loss will cause stream data

Reviewer comments:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Revised text:
Warp encodes the delivery information for a stream via OBJECT headers (message-object).  <ins> A relay SHOULD prioritize streams (prioritization) based on the send order.  A relay MAY change the send order, in which case it SHOULD update the value on the wire for future hops. </ins> A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.  Packet loss will cause stream data
Original text:
Object Sequence: An integer always starts at 0 with in a Group and increases sequentially.  Object Sequences are scoped to a Group. <del> Object Delivery Order: An integer indicating the object delivery order (delivery-order). </del>  Object Payload: The format depends on the track container (containers).  This is a media bitstream intended for the decoder

Reviewer comments:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Revised text:
Object Sequence: An integer always starts at 0 with in a Group and increases sequentially.  Object Sequences are scoped to a Group.  <ins> Object Send Order: An integer indicating the object send order (send-order). </ins> Object Payload: The format depends on the track container (containers).  This is a media bitstream intended for the decoder