Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm
draft-holmberg-dispatch-received-realm-12

This is a well written document, but I have a few minor comments I would like to discuss:

In 5.1:

   The procedures for encoding the JWS and calculating the signature are
   defined in [RFC7515].  As the JWS Payload information is found in
   other SIP information elements, the JWS Payload is not attached to
   the serialized JWS conveyed in the header field parameter, as
   described in Appendix F of [RFC7515].  The operator identifier and
   the serialized JWS are separated using a colon character.

I read this several times and I am still not sure what the second sentence is trying to say.
If you are saying that you are using detached signature, I think it is better to say so.

In 5.6.2:

   jws            = header ".." signature
   header         = *base64-char
   signature      = *base64-char

If neither "header" nor "signature" can be empty, you should use "1*" when defining them.

In 9:

   A SIP entity MUST use different key values for each parameter value
   that it recognizes and use to trigger actions.

I am not sure what this is trying to say. Are you advising against key reuse between this document and keys used for other purposes?

I agree with Alexey's clarification request, it would be helpful to be more explicit in that text.

IESG question: Do we need to point the 3GPPP liaison to the publication of this doc?

Three high level questions:
- Is this actually a SIP specific problem/use case or would you also need a 'received-realm' value for other protocols?
- Actions that would be done based on this value are still quite unclear. Can you give more concrete examples?
- How is the 'received-realm' assigned to  a network? How does a transit network know which value belongs to which network?

Thanks for engaging with the secdir review. [1] I think the
two changes (or equivalents) that ended up with are needed
but since those seem to be agreed there's no need for this
to be a DISCUSS.

[1] waiting the mail I fwd'd to show up in the archive