[stir] Benjamin Kaduk's No Objection on draft-ietf-stir-rph-emergency-services-06: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-stir-rph-emergency-services-06: No Objection

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-emergency-services/



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

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.