Summary: ready with nits.

The STIR specifications (RFC 8224, RFC 8225) define a mechanism in which the "Identity" in a 
SIP header points to an URI used to retrieve the JSON-encoded claims related to that identity. The
claims can be verifed by cryptographic mechanisms, allowing in principle called parties to make
informed decisions before accepting a call. The draft extends the syntax of the JSON tokens to
make claims about the "resource priority" levels that can be used in the call. The goal appears
to be better management of resource in SIP gateways, e.g., chosing which of many incoming
calls would get access to a scarce resource.

Or in any case that's what I understood after reading the draft. It would be helpful if the
introduction explained the problem that the extension is solving, maybe with a reference to
the problem statement in RFC 7340 or the threat model in RFC 7375.

The third paragraph of the introduction could be rearranged. As written,
it mentions an extension defined in RFC 7340, which had me puzzled for a time, as that RFC is a 
problem statement and a list of requirements. As far as I can tell, the extension
uses the mechanisms for "Extending PASSport" defined in section 8 or RFC 8825. Why not
say that, instead of a vague assertion that "The STIR architecture allows extensions". Or,
define what you actually mean by the STIR Architecture, arguably the combination of
RFC 8824 and RFC 8825.

Looking at security issue, it appears that the proposal reuses for resource priority the
mechanisms defined by RFC 8824 for generally verifying claims. That seems reasonable. My
main concern is with the levels of indirection. The security mechanisms will verify that
a claim is authentic by verifying that it is properly authorized by the specified
authority. But at that point, the gateway will have to verify that the authority
behind the claim is actually authorized to consume the resource as specified in
the resource priority header. This is potentially more complex than verifying an
identity claim. Section 7.2. of the security consideration explains that,
but I am curious to see whether that will work in practice. 

Please update the references. [I-D.ietf-stir-rfc4474bis] has been replaced by RFC 8224.
[I-D.ietf-stir-passport] has been replaced by RFC 8225.