Original text:
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>  2.3.  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>  In MOQT, every track has a track name and a track namespace associated with it.  A track name identifies an individual track

Reviewer comments:
I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments

Revised text:
2.2.  <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.  <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