Original text:
When a PRIORITY frame claims to reference a request, the associated ID MUST identify a client-initiated bidirectional stream.  A server <del> MUST treat receipt of PRIORITY frame with a Stream ID of any other type as a connection error of type HTTP_MALFORMED_FRAME. </del>  <del> A PRIORITY frame that references a non-existent Push ID or a Placeholder ID greater than the server's limit MUST be treated as an HTTP_MALFORMED_FRAME error. </del>  A PRIORITY frame received on any stream other than a request or control stream MUST be treated as a connection error of type server can promise.  A server SHOULD use Push IDs sequentially, starting at 0.  A client MUST treat receipt of a push stream with a Push ID that is greater than the maximum Push ID as a connection <del> error of type HTTP_PUSH_LIMIT_EXCEEDED. </del>  The header of the request message is carried by a PUSH_PROMISE frame (see frame-push-promise) on the request stream which generated the A frame was received on a stream where it is not permitted. <del> A Push ID greater than the current maximum Push ID was referenced. </del>  A Push ID was referenced in two different stream headers.

Reviewer comments:
Generalizes HTTPPUSHLIMITEXCEEDED to HTTPLIMIT_EXCEEDED and mandates use of that error code where a PRIORITY frame attempts to prioritize a stream the client isn't permitted to open yet. This has the effect of bounding priority tree state to requests the client could initiate (though might not have yet).
RFC 7540 at some length, especially what to do with priority information after a stream is closed. In addition to this, in HTTP/3, we have to deal with priority information before a stream is opened. That is: just how large is the tree allowed to grow before the referenced streams' frames begin to come in? The draft should provide some recommendations. I can think of two ways to do limit this "front-loaded" state: Open the stream when a PRIORITY frame referencing it arrives on the control stream. This will invoke the stream limit checks. Limit number of priority entries to number -- perhaps a function of the total number of maximum unidirectional and bidirectional streams.
Just clarifying: this would be advice to implementations, nothing normative, right?
I don't know. I think I will be happy as long as something is put into the draft.
Assuming that PRIORITY can only reference a stream that already "exists" client-side, the maximum number would be the number of permitted client-initiated bidirectional streams. Perhaps the requirements should simply be that PRIORITY cannot reference a stream that the client isn't permitted to open? I don't really want to "actually open" the stream when the PRIORITY frame arrives, but checking that it's less than the MAXSTREAMID on receipt seems like a reasonable server-side check.

Revised text:
When a PRIORITY frame claims to reference a request, the associated ID MUST identify a client-initiated bidirectional stream.  A server  <ins> MUST treat receipt of a PRIORITY frame identifying a stream of any other type as a connection error of type HTTP_MALFORMED_FRAME. </ins>  <ins> A PRIORITY frame that references a non-existent Push ID, a Placeholder ID greater than the server's limit, or a Stream ID the client is not yet permitted to open MUST be treated as an HTTP_LIMIT_EXCEEDED error. </ins> A PRIORITY frame received on any stream other than a request or control stream MUST be treated as a connection error of type server can promise.  A server SHOULD use Push IDs sequentially, starting at 0.  A client MUST treat receipt of a push stream with a Push ID that is greater than the maximum Push ID as a connection  <ins> error of type HTTP_LIMIT_EXCEEDED. </ins> The header of the request message is carried by a PUSH_PROMISE frame (see frame-push-promise) on the request stream which generated the A frame was received on a stream where it is not permitted.  <ins> A Stream ID, Push ID, or Placeholder ID greater than the current maximum for that identifier was referenced. </ins> A Push ID was referenced in two different stream headers.