Original text:
2.1. <del> The basic data element of MOQT is an .  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and potential dependencies. model-group Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </del>  2.2. <del> A is a collection of objects and is a sub-unit of a track (model- track).  Objects within a group SHOULD NOT depend on objects in other groups.  A group behaves as a join point for subscriptions.  A new subscriber might not want to receive the entire track, and may </del>  instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. 2.3. <del> A is a sequence of groups (model-group).  It is the entity against which a consumer issues a subscription request.  A subscriber can request to receive individual tracks starting at a group boundary, including any new objects pushed by the producer while the track is active. </del>  2.3.1. <del> In MOQT, every track has a and a </del>  associated with it.  A track name identifies an individual track within the namespace. <del> A tuple of a track name and a track namespace together is known as </del>  <del> : A is a set of servers (as identified by their connection URIs) for which full track names are guaranteed to be unique.  This implies that within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.  It is up to the application using MOQT to define how broad or narrow the scope has to be.  An application that deals with </del>  connections between devices on a local network may limit the scope to a single connection; by contrast, an application that uses multiple CDNs to serve media may require the scope to include all of those

Reviewer comments:
The stuff we had to italicize the stuff in html is inserting underscores in the .txt file so I just want to remove this until for now until we figure this out. Did not change anything other than making the words not italicized
Thanks for catching this , the rendered TXT file looks different for these things. Merging it for now and we can work on figuring out the right markdown syntax.

Revised text:
2.1.  <ins> The basic data element of MOQT is an object.  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and potential dependencies. model-group Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </ins> 2.2.  <ins> A group is a collection of objects and is a sub-unit of a track (model-track).  Objects within a group SHOULD NOT depend on objects in other groups.  A group behaves as a join point for subscriptions. A new subscriber might not want to receive the entire track, and may </ins> instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. 2.3.  <ins> A track is a sequence of groups (model-group).  It is the entity against which a consumer issues a subscription request.  A subscriber can request to receive individual tracks starting at a group boundary, including any new objects pushed by the producer while the track is active. </ins> 2.3.1.  <ins> In MOQT, every track has a track name and a track namespace </ins> associated with it.  A track name identifies an individual track within the namespace.  <ins> A tuple of a track name and a track namespace together is known as a full track name: </ins>  <ins> A MOQT scope is a set of servers (as identified by their connection URIs) for which full track names are guaranteed to be unique.  This implies that within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.  It is up to the application using MOQT to define how broad or narrow the scope has to be.  An application that deals with </ins> connections between devices on a local network may limit the scope to a single connection; by contrast, an application that uses multiple CDNs to serve media may require the scope to include all of those