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

["Murray S. Kucherawy" <[e-mail]>]

Hi STIR,

This document is approved, but please consider at least adding the
suggested additional references Ben mentioned here.  Let me know if you
concur and would like to post a revision before we send it for publication.

-MSK

On Tue, Feb 23, 2021 at 2:20 PM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> 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.
>
>
>
>