2.2. <del> 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 instead opt to receive only the latest group(s).  The publisher then selectively transmits objects based on their group membership. </del> <ins> A peep is a collection of one or more objects and is a sub-unit of a group (model-group).  A peep consists of a set of objects within a Group that have a dependency and priority relationship consistent with sharing a QUIC stream.  In some cases, a Group will be most effectively delivered using more than one stream. When a Track's forwarding preference (see object-fields) is "Track" or "Datagram", Groups do not contain Peeps, no Peep IDs are assigned, and the description in the remainder of this section does not apply. QUIC streams offer in-order reliable delivery and the ability to cancel sending and retransmission of data.  Furthermore, many implementations offer the ability to control the relative priority of streams, which allows control over the scheduling of sending data on active streams. Every object within a Group belongs to exactly one Peep. Original publishers assign each Peep a Peep ID, and do so as they see fit.  The scope of a Peep ID is a Group, so Peeps from different Groups MAY share a Peep ID without implying any relationship between them. However, the following strategy is RECOMMENDED: Higher object IDs are dependent on lower object IDs in the same peep. If two objects are dependent on the same lower object ID, but are not dependent on each other, one ought to assigned the same peep as the lower ID, but the other ought to be in a different peep. The second peep would ideally have a lower priority than the one with two objects. There often multiple assignment schemes that meet these conditions.  Original publishers ought to choose an assignment that minimizes the number of peeps (and therefore QUIC streams) in the group. For example, imagine that Object 3 and Object 2 are both dependent on Object 1, but are have no depedency relationship with each other.  It would therefore be appropriate for Objects 1 and 3 to be in one peep and Object 2 in another, with lower priority.  The separate stream prevents delivery of Object 3 from being blocked by the loss of Object 2. Alternatively, objects 1 and 2 could be in one peep and 3 in another. The optimal choice would depend on the dependencies of later objects. An original publisher might not follow these guidelines.  Reasons would include implementation complexity, lack of foreknowledge of the dependencies of further objects, the knowledge that the transport is WebTransport over HTTP/2 (thus introducing head-of-line blocking across streams), or knowledge of low session stream limits that require aggregation of independent objects into the same stream. For the purposes of peep assignment, the dependencies of objects with non- normal status are described in object-status. </ins> 2.3. <ins> A group is a collection of one or more peeps 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 publisher then selectively transmits objects based on their group membership. 2.4. </ins> A track is a sequence of groups (model-group).  It is the entity against which a subscriber issues a subscription request.  A subscriber can request to receive individual tracks starting at a group boundary, including any new objects pushed by the publisher while the track is active. <del> 2.3.1. </del> <ins> 2.4.1. </ins> In MOQT, every track has a track name and a track namespace associated with it.  A track name identifies an individual track