Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Thanks for this work. I plan to ballot "yes", but I have a couple of points I think need to be discussed first. §4.2: " If the signature validation fails, the verification service should infer that the calling party is not authorized for ’Resource-Priority’ as indicated in the claim. In such cases, the priority treatment for the associated communication service is handled as per the local policy." I suspect there will be deployments where the node making these local policy decisions is downstream from the verifier. How do they know RPH verification failed? Should the verifier strip resource priority header fields for which validation failed? §7.2: o The verification of the signature MUST include means of verifying that the signer is authoritative for the signed content of the resource priority namespace in the PASSporT." I gather the intent is to leave that means to local policy, or to be specified elsewhere. I think that's a problem from an interoperability standpoint. The verifier needs a way to know whether the authorizer is authoritative for the RPH. If we want authorizers and verifiers from different vendors to be able to interoperate, it seems like at least some mechanism needs to be standardized and possibly MTI.
General: It's probably worth updating the references to 4474bis and passport to their respective RFCs. §3, 4th paragraph: The imbedding of ABNF in the middle of a paragraph is difficult to read. It would be helpful to separate that from the surrounding text in the conventional fashion. §3, 5th paragraph and throughout: The repeated use of "r-value ="namespace "." priority value" is hard to read. Please consider giving that parameter construct a name, and using the name throughout. §3, 7th paragraph: "The authority MUST use its credentials (i.e., CERT)" Does "CERT" mean "Certificate"? I assume it's not "Computer Emergency Response Team". §4.1 : A SIP authentication service typically will derive the value of "rph" from the ’Resource-Priority’ header field based on policy associated with service specific use of the "namespace "." priority value" for r-values based on [RFC4412].: "Typically" usually implies "Most but not all of the time". Is that the intent? §4.2, last paragraph: Am I correct to guess that this is talking about valid claims?
I support Ben's discuss. Thank you for working with the secdir reviewer to address those comments; I think it will really improve the document. In a similar vein, I wonder if this document would be easier to read if it used less formal description terms for protocol elements that are currently referred to by using the actual protocol element (with quotes around the name). For example, "SIP resource priority header" instead of "'Resource-Priority' header field", or "priority indicator" instead of "'namespace"."priority value"'. I'm a little confused why the new registry created in Section 6.2 is tied to the "resource priority header" (rph) name, when the discussion in Section 5 has some potential envisioned use cases that are broader than resource priority. As Ben notes, there are some stale references. Please double-check the referred section numbers as well; in particular "Section 10.1 of [4474bis]" does not exist in the only February-2017 verions of that draft. Section 7.2 uses "authority" in a couple of different senses; it might be easier on the reader to refer to the authority (protocol participant) as being "authoritative for the content of [stuff] that it signs".
NO RECORD, ran out of time for reviewing this document.