Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks
draft-ietf-stir-rph-emergency-services-07

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.