Original text:
priority for the Object priorities. Object Forwarding Preference: An enumeration indicating how a <del> publisher sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object Forwarding Preference", described below. </del>  Object Status: As enumeration used to indicate missing objects or mark the end of a group or track.  See object-status below.

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:
priority for the Object priorities. Object Forwarding Preference: An enumeration indicating how a  <ins> publisher sends an object.  The preferences are Track, Peep, and Datagram.  An Object MUST be sent according to its "Object Forwarding Preference", described below. Peep ID: The object is a member of the indicated peep ID (model- peep) within the group.  This field is omitted if the Object Forwarding Preference is Track or Datagram. </ins> Object Status: As enumeration used to indicate missing objects or mark the end of a group or track.  See object-status below.