Original text:
2.  2.1. <del> The basic element of MoQTransport is an </del>  .  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and <del> potential dependencies. model-group Objects carry associated metadata such as priority, TTL, or other information usable by a relay, but relays MUST treat the object payload as opaque. The application is solely responsible for the contents of objects. 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. A <del> is collection of objects, part of a larger track (model-track). A group behaves as a join point for subscriptions.  A new subscriber may not want to receive the entire track, and will instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. The application is responsible for how objects are placed into groups.  In general, objects within a group SHOULD NOT depend on objects in other groups. </del>  2.3. A <del> is a sequence of objects (model-object) organized into groups (model- group).  A subscriber can request individual tracks at group boundaries, including any new objects while the track is active. </del>  2.3.1.

Reviewer comments:
NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.

Revised text:
2. <ins> MoQT has a hierarchical object model for data, comprised of objects, groups and tracks. </ins> 2.1.  <ins> The basic data element of MoQTransport is an </ins> .  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and  <ins> 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. A  <ins> 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 instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. </ins> 2.3. A  <ins> 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.