Original text:
provides a join point for subscriptions, so a subscriber that does not want to receive the entire track can opt to receive only the latest group(s).  The publisher then selectively transmits objects <del> based on their group membership. </del>  Groups are ordered numerically by their Group ID.

Reviewer comments:
How big can a group be? I know we (probably) won't be able to set a fixed limit, but I feel like we need to answer this in order to know what kind of design assumptions to make. Is a single group expected to be small enough to fit in the cache? Will the protocol work if a media track is just a single group that is being appended to for hours if not days? I was thinking about stream mapping and the resource-use-at-relays problem earlier today, and realized we might not currently have a conclusive answer for those.
As it stands today, the group ID is merely an annotation used by SUBSCRIBE hints. It's a sync point only by convention; in actuality the relay has no idea if objects within a group depend on each other. The relay is expected to cache/serve/evict objects independently so the group size is irrelevant. For example, a valid use-case is a single audio group with an object per frame. Each OBJECT would have an expires field of 30s, effectively dropping the head of the group as time progresses. The total number of objects per group is unbounded but the cache size is bounded. I strongly disagree with this. I want groups to actually be sync points, in which a relay knows that it should not evict OBJECT N without also evicting OBJECT N+1. Then the maximum size of the group actually matters.
IMO the size of a group (in bytes, or object count, or wallclock duration) should not be defined by the moq-transport spec. Limits such as these are driven by the physical characteristics of the caches and therefore should be provided by the relay (cache) provider. A streaming format (such as WARP) may choose to define a minimum object size to be supported for interop reasons between relays, but this should probably stay outside of moq-transport.
+1 to will's point. Group Size vary depending on the application - video, audio, chat, something new If any application needs to be aware of this, we can do the following Have catalog specify the group size per track Have a MOQT message updated where the Publisher can specify it per track in Subscribe OK. This might help as hint to caches if need be.
Individual Comment: There may be something interesting for moqt here in expressing more information that's useful to a cache. Maybe an explicit expiry time would be more useful than a TTL, or a TTL at the group rather than the object level? Caches will evict stuff and can go fetch it if someone asks for it later. Maybe what needs to be specified is what happens when a cache receives Objects 0-10, evicts 0-3, then gets a SUBSCRIBE for Absolute/0-10?
Yeah, the cache needs some dependency information if it has any hope of evicting objects before the maximum TTL. That should be the purpose of group in my opinion.
I think we should allow it to be pretty much any size and as we use a VarInt for the object id so it does not matter. I guese I am not seeing a problem here from what we have today with pretty much no limit on number of of objects or number of groups. So I guess I am saying whatever max of VarInt is which I assume will be at least 2^60.
NAME are you fine with NAME point? If so, please close the issue.
I think we should add a note that groups can be in practice arbitrarily big.

Revised text:
provides a join point for subscriptions, so a subscriber that does not want to receive the entire track can opt to receive only the latest group(s).  The publisher then selectively transmits objects  <ins> based on their group membership.  Groups can contain any number of objects. </ins> Groups are ordered numerically by their Group ID.