[stir] Ben Campbell's Discuss on draft-ietf-stir-rph-03: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-stir-rph-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-rph/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?