Ballot for draft-ietf-stir-rph-emergency-services
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Thank you to Kyle Rose for the SECDIR review. As Ben already noted, those additional references that the review pointed would be helpful.
Thanks to Tianran for the OpsDir review. I agree with him that the document is clear and an easy read.
The references to rfc2119/rfc8174 should be Normative.
Just a couple of minor comments that I hope will help: — Section 1 — Compromise of the SIP "Resource-Priority" or "Priority" header fields could lead to misuse of network resources (i.e., during congestion scenarios), Only during congestion scenarios (“i.e.”), or is that meant to be an example of when misuse might happen? If truly the former, why is congestion the only time compromise of these fields could lead to misuse of resources? And could their compromise lead to other kinds of misuse? — Section 3 — The "dest" claim MUST either be a country or region specific dial string A nit, but I had minor trouble reading it at first without the hyphens: it should say “a country- or region-specific dial string”. Or if you don’t like “country-“, you could say “country-specific or region-specific”.
Section 3 Similar to the values allowed by [RFC8443] for the "auth" JSON object key inside the "rph" claim, the string "esnet.x" with the appropriate (nit) I suggest s/allowed/defined/, since RFC 8443 assumes the auth array will be extensible. Section 4 The following is an example of an "sph" claim for SIP 'Priority' header field with the value "psap-callback": { "orig":{"tn":"12155551213"}, "dest":{"tn":["12155551212"]}, "iat":1443208345, "rph":{"auth":["esnet.0"]}, "sph":"psap-callback" (nit) the listed "iat" value corresponds to a date in 2015. Should something more current be used? Section 5 The order of the claim keys MUST follow the rules of [RFC8225] Section 9; the claim keys MUST appear in lexicographic order. We probably want to clarify that this requirement is in force for the deterministic JSON serialization used for signature generation (and validation). Especially so since the immediately preceding example has the claims in a different order... Section 9 Thanks to Kyle Rose for the secdir review! Kyle called out the considerations from RFCs 8225 and 8443 as also being relevant (and I agree); please reference those as well as RFC 8224.
Hi, thanks for this document. Only one minor comment: Similar to Ben's comment, I was surprised to see the claims listed in a different order than the canonical order in 5.