Reviewer: Christian Huitema Review result: Has Nits 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.
