Original text:
OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track <del> and find the active subscribers for that track.  Relays MUST NOT depend on OBJECT payload content for making forwarding decisions and MUST only depend on the fields, such as priority order and other metadata properties in the OBJECT message header.  Unless determined by congestion response, Relays MUST forward the OBJECT message to the matching subscribers. </del>  5.3.

Reviewer comments:
I removed this sentence: Relays MUST NOT depend on OBJECT payload content for making forwarding decisions and MUST only depend on the fields, such as priority order and other metadata properties in the OBJECT message header. We already have text explaining that the object payload content can be encrypted (section 2.1). I think that makes it clear that a relay can't do anything with the object payload unless it has the encryption keys or a priori knowledge they are cleartext. The sentence itself was overly restrictive (relays could use other inputs, for example out of band information from configuration or business relationships). The preceding sentence explains how to find subscribers to this track, the subsequent one says "MUST forward", and we have an entire section explaining what to do with priority order now.
Line 572. “[Relays] MUST only depend on the fields [for making forwarding decisions]”. I am not sure to understand why we would like to restrict here the behavior of Relays to forward the Objects to subscribers. We can imagine edge processing for the implementation of forwarding decisions based on third-party validation (possibly based on payload). Furthermore, this restriction is not necessary for the norm to be implemented.
The intent of the language here was that relays should only depend on being able to access the headers and not the body of the objects, as the body may be encrypted. However someone may want to build a relay that uses 3rd party logic , or that inspects the payload, in order to make forwarding decisions. I agree that this should not be prohibited by the protocol. We should relax the language to indicate that payloads MAY be encrypted and that relays MUST implement any prioritization instructions carried in the headers. The spec should make no normative statements about how relays make forwarding decisions.
I agree that this is too restrictive and yet unenforceable. The intent is to say something like "a router MUST only forward packets based on the IP header". But what about the UDP/TCP header? What about the TLS header? What about the HTTP header? It's perfectly valid to use those iff a router supports those layers (aka a load balancer). I mentioned in the other issue, but we should treat moq-transport as just a layer. There may be other layers stacked on top and which should not be restricted. It's L3/L4/L7 all over again.
I am always confused when we use the term Relay to mean more than one thing. My thinking so far is, these are the middleboxes who have no role with payload of the MOQ objects. Yes, it cannot be enforced and a implementation can do whatever it wants. However, when we define security properties, we need to be clear on Relay's role. OTOH middleboxes like SFUs, transcoders are more flexible to access payload and may be payload headers based on the architecture and they fall into different category when defining the security of the system.
This is marked not-transport, but the issue was filed against text in moqt, so maybe that's not correct.

Revised text:
OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track  <ins> and find the active subscribers for that track.  Relays MUST forward OBJECT messages to matching subscribers in accordance to each subscription's priority, group order, and delivery timeout. </ins> 5.3.