Original text:
The result of the gZIP compression is then base64url-encoded, as defined in Section 2 of RFC7515.  5. This document defines potential statuses of Referenced Tokens as

Reviewer comments:
reorder section on Referenced Token and Status List Token URL
I did a first review of this draft. As a newbie to the topic, I found the following issues: I miss a description of the fundamental concept, i.e. the status list itself is a JWT (issued by the same issuer issuing the JWTs), the status list JWT is obtained from a URL hosted by that issuer or another party, the link between the JWT and its status list is provided through data in the JWT. I suggest to add this in the Introduction (or an Overview) section. When reading Section 3.1. for the first time I was confused whether it describes the status list JWT or the JWT referring to the status list. I think it is the latter and it should be clear to the reader on first sight. I think the order of definition should be changed. Right now, I'm supposed to understand how a status list JWT is used in a JWT without even knowing what that status list JWT is. I suggest to change order: 1) Overview of the concepts, 2) specify status list JWT (structure and where/how to obtain), 3) embedding in a JWT (syntax, processing rules, ...).
Agree on 1+2. As mentioned in we need a better word describing the "Token" that is being described by the status List. I will make a PR using "Subject Token" as this comprises both JSON and CBOR formats. Agree on 3 as well.
For reordering it would make sense to get forward with the existing PRs first and do it afterwards..
Addressing some of these issues in
What's left to do: reorder Status List Token first and Referenced Token afterwards

Revised text:
The result of the gZIP compression is then base64url-encoded, as defined in Section 2 of RFC7515. <ins> 4.2. The following rules apply to validating a Referenced Token in JWT representation, which references a Status List Token.  Application of additional restrictions and policy are at the discretion of the verifying party. The JWT MUST contain an "iss" (issuer) claim that contains a unique string identifier for the entity that issued the JWT.  In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within the referenced Status List Token. The JWT MUST contain an "status" (status) claim conforming to the rules outlined in The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. 4.2.1. The following rules apply to validating the "status" (status) claim The claim value MUST be a valid JSON object. The claim value object MUST contain an "idx" (index) member with a numeric value that represents the index to check for status information in the Status List for the current JWT.  The value of this member MUST be a non-negative number, containing a value of zero or greater. The claim value object MUST contain a "uri" member with a string value that identifies the Status List containing the status information for the JWT.  The value of this member MUST be a uri conforming to RFC3986. </ins> 5. This document defines potential statuses of Referenced Tokens as