Subject: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sun, 06 Jan 2019 15:28:57 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-sipcore-sip-push-21: Discuss

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-sipcore-sip-push/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5114

DETAIL
S 5.3.2.
>      request) addressed towards a SIP UA, if the Request-URI of the
>      request contains a pn-provider, a pn-prid and a pn-param (if required
>      for the specific PNS provider) SIP URI parameter, the proxy requests
>      a push notification towards the UA, using the PRID included in the
>      pn-prid SIP URI parameter and the PNS identified by the pn-provider
>      SIP URI parameter.

Maybe I'm missing something, but this seems like it leaves open the
possibility for the PRID to not match the rest of the URI. E.g.,
suppose that [email-masked] and [email-masked] both register with the
same proxy/registrar pair with PRIDa and PRIDb respectively. What
stops the registrar from generating (or forwarding) a call to
[email-masked], PRIDb? And what happens if that happens?

S 5.3.2.
>      also present (and has not expired) in the REGISTER response, the
>      proxy can forward the SIP request towards the UA, using normal SIP
>      procedures.  If the contact of the REGISTER request does not match
>      the Request-URI of the SIP request to be forwarded, or if the contact
>      was not present in the REGISTER response, the proxy MUST reject the
>      SIP request with a 404 (Not Found) response.  This can happen if the

How does this happen? I.e., how does the the REGISTER get correlated
with the SIP request to be forwarded in order to execute this
requirement?

S 6.1.
>      and be able to find and retrieve that information when it receives a
>      mid-dialog request.  This section defines such mechanism.  The UA and
>      proxy procedures in this section are applied in addition to the
>      generic procedures defined in this specification.
>   
>   6.1.  SIP UA Behavior

This section needs some kind of diagram that explains what the
mechanism is. I've read it a bunch of times, and I still don't
understand it.

S 6.2.1.
>      generated key as the value to the associated 2xx REGISTER response.
>   
>      The PURR value MUST be generated in such a way so that it cannot be
>      used to retrieve information about the user or associate it with
>      registrations.  It can be generated e.g., by utilizing a
>      cryptographically secure random function.

This seems to weak. I assume you also don't want it to be possible to
determine that two PURRs correspond to the same user. Also who must be
able to use it in this way. Presumably the proxy can?

Why is this not a requirement for say PRID?

S 13.
>      specification.  Web push permits the sending of a push message
>      without a payload without encryption.
>   
>   13.  Security Considerations
>   
>      Different mechanisms exist for authenticating and authorizing devices

You need to discuss the security implications of knowledge of the push
parameters (principally PRID). What happens if an attacker learns
htem?

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

This document is very badly in need of editorial work for readability.
I would urge the responsible AD to make one.

S 1.
>      used to wake such applications, nor will incoming network traffic
>      wake the application.  Instead, one way to wake the application is by
>      using a Push Notification Service (PNS).  Typically each operating
>      system uses a dedicated PNS.  For example, Apple iOS devices use the
>      Apple Push Notification service (APNs) while Android devices use the
>      Firebase Cloud Messaging (FCM) service.

What is a Push Notification Service? I mean, I know, but you need to
say.

S 1.
>      will request push notifications towards the UA.
>   
>      When the proxy receives a SIP request for a new dialog or a stand-
>      alone SIP request addressed towards a UA, or when the proxy
>      determines that the UA needs to send a binding-refresh REGISTER
>      request, the proxy will request a push notification towards the UA,

"request ... towards" is ungrammatical

S 1.
>            |<---------------------|                         |
>            |                      |                         |
>            |          SIP REGISTER (Push Resource ID)       |
>            |===============================================>|
>            |                      |                         | SIP REGISTER
>            |                      |                         |============>

These arrows don't seem to go anywhere. I think you need to label the
registrar.

S 4.1.
>   
>      NOTE: The VAPID specific procedures of the SIP UA are outside the
>      scope of this document.
>   
>      When the UA receives a push notification, it MUST send a binding-
>      refresh REGISTER request, using normal SIP procedures.  If there are

This seems unnecessarily restrictive. Are we never going to want any
other kind of push notification?

S 4.1.
>      protocol is used, the SIP request might reach the UA before the
>      REGISTER response.
>   
>      NOTE: The lifetime of any NAT binding created by the REGISTER request
>      only needs to be long enough in order for the SIP request that
>      triggered the push notification to reach the UA.

This general architectural point should be made further up.

S 4.1.
>      [RFC3840] in each Contact header field URI of each REGISTER request.
>      Then, if the response to the REGISTER request contains a 'sip.pnsreg'
>      feature-capability indicator with an indicator value, the UA
>      refreshes the binding prior to the binding expires.  The indicator
>      value indicates a minimum time (given in seconds), prior to the
>      binding expires when the UA MUST send the REGISTER request.  Even if

This sentence needs a rewrite.

S 4.1.
>      Then, if the response to the REGISTER request contains a 'sip.pnsreg'
>      feature-capability indicator with an indicator value, the UA
>      refreshes the binding prior to the binding expires.  The indicator
>      value indicates a minimum time (given in seconds), prior to the
>      binding expires when the UA MUST send the REGISTER request.  Even if
>      the UA is able to to send REGISTER requests using a non-push

"to to"

Also, all UAs that are conformant to this specification are able to
send REGISTERS via a non-push as the first register is sent that way.

S 4.1.
>      capability indicator, the UA SHOULD only send a re-registration
>      REGISTER request when it receives a push notification (even if the UA
>      is able to use a non-push mechanism for sending re-registration
>      REGISTER requests), or when there are circumstances (e.g., if the UA
>      is assigned new contact parameters due to a network configuration
>      change) that require an immediate REGISTER request to be sent.

This text doesn't seem correct. If the initial response doesn't
contain "sip.pns" then you probably would still want to send regular
REGISTERs

S 4.1.
>      change) that require an immediate REGISTER request to be sent.
>   
>      NOTE: If the UA uses a non-push mechanism to wake and send a binding
>      refresh REGISTER request, such REGISTER request will update the
>      binding expiration timer, and the proxy does not need to request a
>      push notification towards the UA in order to wake the UA.  The proxy

This doesn't seem obviously correct. Why is this so?

S 4.1.
>      REGISTER request.
>   
>      If the UA no longer wants to receive push notifications (requested by
>      the proxy), the UA MUST send a binding-refresh REGISTER request
>      without including the SIP URI parameters described above, or the UA
>      MUST remove the registration.

This seems pretty hard to conform with, given that mobile applications
are often just shut down with no warning.

S 4.1.
>      document.
>   
>      For privacy and security reasons, the UA MUST NOT include the SIP URI
>      parameters defined in this document in non-REGISTER request, to
>      prevent the PNS information associated with the UA from reaching the
>      remote peer.  For example, the UA MUST NOT include the SIP URI

For non-SIP experts, why is this not an issue with REGISTER?

S 5.2.
>      the registrar using some mechanism.  Such mechanisms are outside the
>      scope of this document, but could be implemented e.g., using the
>      SIPregistration event package mechanism [RFC3680].
>   
>      When the proxy receives an indication that the UA needs to send a
>      binding-refresh REGISTER request, the proxy requests a push

You need to define what such an indication is.

S 5.2.
>      scope of this document, but could be implemented e.g., using the
>      SIPregistration event package mechanism [RFC3680].
>   
>      When the proxy receives an indication that the UA needs to send a
>      binding-refresh REGISTER request, the proxy requests a push
>      notification towards the UA.

"requests...towards" again

S 5.2.
>      If the UA has indicated, using the 'sip.pnsreg' media feature tag,
>      that it is able to wake using a non-push mechanism for sending
>      binding-refresh REGISTER requests, if the proxy does not receive a
>      REGISTER request prior to 120 seconds before the registration
>      expires, the proxy MAY request a push notification towards the UA, to
>      trigger the UA to send a REGISTER request.

This paragraph needs to be rewritten in some way that is not so
conditional dense.

S 5.2.
>      UA expects to receive push notifications from the network.  A proxy
>      will not request push notifications towards a UA that has not
>      provided a pn-prid SIP URI parameter.
>   
>      If the proxy receives information that a registration has expired,
>      the proxy MUST NOT request further push notifications towards the UA.

Again, how would it receive such information?

S 5.3.1.
>   
>   5.3.  SIP Requests
>   
>   5.3.1.  REGISTER
>   
>      The procedures in this section apply when the SIP proxy receives a

This section is incredibly hard to follow. Can you rewrite it with
some sort of structure that reflects the logic of the proxy?

S 5.3.1.
>      registrar too short, the proxy MUST NOT insert a Feature-Caps header
>      field with a 'sip.pns' feature-capability indicator in the response,
>      and the proxy MUST NOT request push notifications associated with the
>      registration.  A registration expiration interval MUST be considered
>      too short if the interval is smaller than the time prior to
>      expiration that the proxy would request a push notification.  The

What does this text mean?

S 5.3.2.
>   
>      If the proxy has knowledge that the UA is awake, and that the UA is
>      able to receive the SIP request without first sending a REGISTER
>      request, the proxy MAY choose to not request a push notification
>      towards the UA (and wait for the associated REGISTER request and 2xx
>      response) before it tries to forward the SIP request towards the UA.

Why not race these?

S 6.1.1.
>   
>   6.1.  SIP UA Behavior
>   
>   6.1.1.  Initial Request for Dialog
>   
>      When the UA sends in initial request for a dialog, or a 2xx response

"an initial request"

S 6.1.1.
>      triggered by incoming mid-dialog requests is done based on local
>      policy.  Such policy might be based on the type of SIP dialog, the
>      type of media (if any) negotiated for the dialog [RFC3264], etc.
>   
>      NOTE: As the 'pn-purr' SIP URI parameter only applies to a give
>      dialog, the UA needs to include a 'pn-purr' parameter in the Contact

"to a given" dialog?

S 6.2.1.
>   6.2.1.  REGISTER
>   
>      When the proxy receives an initial REGISTER request for a
>      registration from the UA, if the proxy supports requesting push
>      notifications, triggered by mid-dialog requests, towards the
>      registered UA, the proxy MUST store the information (the pn- SIP URI

Too many commas here to make sense of this requirement

S 10.
>      by two values, separated by a period (.): Team ID and Topic.  The
>      Team ID is provided by Apple and is unique to a development team.
>      The Topic consists of the Bundle ID, which uniquelly identifies an
>      appliciation, and a service value that identifies a service
>      associated with the application, separated by a period (.).  For VoIP
>      applications the service value is "voip".

What is the syntax of these params?

S 11.
>      The value of the pn-provider URI parameter is "fcm".
>   
>      The value of the pn-param URI parameter is the Project ID.
>   
>      The value of the pn-prid URI parameter is the Registration token,
>      which is generated by the FCM SDK for each client app instance.

Again, what is the syntax of this?

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Jan 2019 10:11:47 +0000

Hi,

Thank You for the review! In this reply I'll try to address the DISCUSS issues. The COMMENT issues will be addressed in a separate reply.

DETAIL
S 5.3.2.
>[email-masked], PRIDb? And what happens if that happens?

Since no [email-masked]:PRIDb binding has been registered, the registrar will not generate such URI.

---

S 5.3.2.
>with the SIP request to be forwarded in order to execute this

There could be cases where e.g. the PRID values match, but the rest of the contact don't.

But, I don't think that is relevant. What matters is that the contacts DO match, AND that the contact is present in the REGISTER response. The rest will be handled by the timeout procedures.

So, I think something like the following would be enough:

   "If the contact of the REGISTER request was not present in the
     REGISTER response, the proxy MUST reject the SIP request with a
     404 (Not Found) response."

In addition, we could add a note below the timeout paragraph:

   "If the proxy does not receive the REGISTER request from the UA within
   a given time after the proxy has requested the push notification, the
   proxy MUST reject the request with a 480 (Temporarily Unavailable)
   response.  The time value is set based on local policy.

   NOTE: In case a UA sends a binding-refresh REGISTER request that does not contain the
   previously registered contact at the same time the registrar forwards a SIP request
   towards a UA using the previously registered contact in the Request-URI, the proxy
   will not be able to match the contact with the Request-URI. This will trigger a timeout
   response.

---

S 6.1.
>mechanism is. I've read it a bunch of times, and I still don't

I think it would more or less be a copy of the diagram in Section 1. I could either reference, or copy/paste that diagram.

---

S 6.2.1.
>Why is this not a requirement for say PRID?

The PURR value will reach the remote user. The PRID will only reach the registrar.

---

S 13.
>them?

Based on the sec-dir review, I did some modifications/additions to the security considerations. They can be seen in the following pull request:

https://github.com/cdh4u/draft-sip-push/pull/31

Regarding your comment, I have tried to address that with the following suggested text:

            "Typically, the PNS requires the SIP proxy requesting push notifications to be
            authenticated and authorized by the PNS. In some cases the PNS also require
            the SIP application (or the SIP application developer) to be identified in order for the
            application to request push notifications. Unless the PNS authenticates and authorizes the PNS,
            a malicious middleman that managed to get access to the parameters transported in the SIP signalling
            might be able to request push notifications towards a UA. Which such push notifications will not
            have any security related impacts, they will impact the battery life of the UA and trigger
            unnecessary SIP traffic."

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Jan 2019 13:09:04 +0000

Hi,

>I would urge the responsible AD to make one.

I have done quite a bit of editorial work based on WGLC/AD comments etc. I am happy to improve it even further, but someone needs to guide me what to do.

S 1.
>What is a Push Notification Service? I mean, I know, but you need to

I will add some text/reference about that.

---

S 1.
> "request ... towards" is ungrammatical

Is "request a push notification to be sent towards the UA" better?

---

S 1.
>These arrows don't seem to go anywhere. I think you need to label the

Ok, I will label the "registrar/home proxy" (I don't think we need to separate them).

---

S 4.1.
>other kind of push notification?

Well, in order for this mechanism to work, it has to be a MUST, and the procedures obviously only applies to UAs that use the SIP push mechanism.

If there will be additional usages of push notifications for such UAs, I think they will have to deal with making sure the UA is able to determine what usage the push notifications are associated with.

---

S 4.1.
>This general architectural point should be made further up.

Ok, I will move it.

---

S 4.1.
>This sentence needs a rewrite.

I'll see what I can do.

---

S 4.1.
>>      the UA is able to to send REGISTER requests using a non-push

Will fix.

>send REGISTERS via a non-push as the first register is sent that way.

Correct. I will clarify that.

---

S 4.1.
>contain "sip.pns" then you probably would still want to send regular

The text is about "sip.pnsreq".

---

S 4.1.
>This doesn't seem obviously correct. Why is this so?

As the UA will use other (non-push) mechanisms to wake up for updating the binding expiration timer, there is no need to use push notifications for that.

---

S 4.1.
>are often just shut down with no warning.

On shut down, I believe mobile applications are typically moved in to a state where they are still able to perform some actions.

Anyway, the text applies to situations where the UA is able to perform actions.

So, perhaps clarifying that with:

"the UA MUST (unless it is no longer able to perform SIP procedures, e.g., due to a forced shutdown) send a"

---

S 4.1.
>For non-SIP experts, why is this not an issue with REGISTER?

The REGISTER will only reach your registrar, it will not be forwarded to the remote peer.

---

S 5.2.
>You need to define what such an indication is.

As described in the paragraph above, the indication mechanism is outside the scope of the document. RFC 3680 can be used (and is given as an example), but there could also be other mechanisms.

---

S 5.2.
> "requests...towards" again

Will fix.

---

S 5.2.
>This paragraph needs to be rewritten in some way that is not so

There are only two conditions, aren't there?

---

S 5.2.
> Again, how would it receive such information?

E.g., using RFC 3680 - or some other mechanism. As different networks and architectures might use different mechanisms for updating its nodes about the registration status, we don't want to mandate a specific mechanism.

---

S 5.3.1.
>some sort of structure that reflects the logic of the proxy?

I'll see what I can do.

---

S 5.3.1.
>What does this text mean?

If the registration interval is considered too short, a proxy will not enable SIP push.

For example, assume a proxy would send a push notification 30 seconds prior to registration expirations.

Now, if the registration expiration interval is only 20 seconds, it would not work.

I don't think this will ever happen in real life, but people wanted this text.

---

S 5.3.2.
>>      response) before it tries to forward the SIP request towards the UA.

One could do that, but I don't think it should be mandated.

---

S 6.1.1.
>>      When the UA sends in initial request for a dialog, or a 2xx response

Will fix.

---

S 6.1.1.
>>      dialog, the UA needs to include a 'pn-purr' parameter in the Contact

Correct. Will fix.

---

S 6.2.1.
> Too many commas here to make sense of this requirement

I'll see what I can do to fix that.

---

S 10.
> What is the syntax of these params?

The details can be found in the PNS specific documentation.

---

S 11.
> Again, what is the syntax of this?

Same as above.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Jan 2019 06:06:11 -0800

On Mon, Jan 7, 2019 at 2:11 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
> Thank You for the review! In this reply I'll try to address the DISCUSS
> issues. The COMMENT issues will be addressed in a separate reply.
>
> DETAIL
> S 5.3.2.

No conformant registrar will. But what about a nonconformant one? Or
another endpoint.

---
> There could be cases where e.g. the PRID values match, but the rest of the

Such as?

But, I don't think that is relevant. What matters is that the contacts DO
> match, AND that the contact is present in the REGISTER response. The rest
> will be handled by the timeout procedures.
>

But *this* text requires you to behave in a certain way in case of
mismatch. When will this be executed?

> I think it would more or less be a copy of the diagram in Section 1. I
> could either reference, or copy/paste that diagram.
>
> ---
>
> S 6.2.1.

You need to say that.

S 13.

>
> Based on the sec-dir review, I did some modifications/additions to the
> security considerations. They can be seen in the following pull request:
>
>             a malicious middleman that managed to get access to the
> parameters transported in the SIP signalling

Why "middleman" as opposed to any endpoint.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Jan 2019 06:08:23 -0800

On Mon, Jan 7, 2019 at 5:09 AM Christer Holmberg <
[email-masked]> wrote:

> I have done quite a bit of editorial work based on WGLC/AD comments etc. I
> am happy to improve it even further, but someone needs to guide me what to
> do.
>

Ben?

> Is "request a push notification to be sent towards the UA" better?

I would say "request that a push notification be sent to"

> >>            |                      |                         | SIP
> REGISTER
> >>            |                      |
> |============>

Sure.

> Well, in order for this mechanism to work, it has to be a MUST, and the
> procedures obviously only applies to UAs that use the SIP push mechanism.
>

Yeah, this seems like a pretty major architectural flaw in this design,
tbh, one that is remedied by just using RFC 8030-style notifications that
contain content.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Jan 2019 06:15:13 -0800

> The text is about "sip.pnsreq".

Yes, but it's not phrased as being conditional on that other condition (see
previous comments about writing style).

---
> As the UA will use other (non-push) mechanisms to wake up for updating the
> binding expiration timer, there is no need to use push notifications for
> that.
>

All right.

> On shut down, I believe mobile applications are typically moved in to a
> state where they are still able to perform some actions.
>

It's not reliable. Sometimes you get that, sometimes you don't.

Anyway, the text applies to situations where the UA is able to perform
> actions.

This doesn't seem much like a MUST.

---
> The REGISTER will only reach your registrar, it will not be forwarded to

Please say so.

> There are only two conditions, aren't there?

No.

When a proxy receives:
   If the proxy considers
   If the proxy considers
   Similarly, when the proxy receives [not sure about the indent on this
one...]

> E.g., using RFC 3680 - or some other mechanism. As different networks and
> architectures might use different mechanisms for updating its nodes about
> the registration status, we don't want to mandate a specific mechanism.
>

You need to say something here about how that's out of scope. Otherwise,
people just go hunting through the text for it.

> I don't think this will ever happen in real life, but people wanted this

OK, but it should be rewritten so it's clear.

> One could do that, but I don't think it should be mandated.

The current text prohibits racing if you *don't* know that the UA is awake.

> The details can be found in the PNS specific documentation.

These do not appear to be normative references. I at least need to know
enough about the structure to know what to expect.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Jan 2019 19:04:12 +0000

Hi,

S 1.

>I would say "request that a push notification be sent to"

Ok.

...

S 4.1.

>Yeah, this seems like a pretty major architectural flaw in this design, tbh, one that is
>remedied by just using RFC 8030-style notifications that contain content.

Other push notification services support content too, but we decided that we are not going to specify that for SIP push.

IF there comes a future case, where multiple SIP usages of push notifications have to co-exist, we can define usage of content (and e.g., define that SIP push is default).

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Jan 2019 19:43:48 +0000

Hi,

S 4.1.

>Yes, but it's not phrased as being conditional on that other condition (see previous comments
>about writing style).

Ok.

---

S 4.1.

>This doesn't seem much like a MUST.

SHOULD?

---

S 4.1.

Ok.

---

S 5.2.

>No.
>
>When a proxy receives:
>   If the proxy considers
>   If the proxy considers
>   Similarly, when the proxy receives [not sure about the indent on this one...]

Ok, I will have a look.

---

S 5.2.

>You need to say something here about how that's out of scope. Otherwise, people just
>go hunting through the text for it.

The first paragraph of section 5.2 does say it is out of scope.

---

S 5.3.1.

>OK, but it should be rewritten so it's clear.

I will see what I can do.

---

S 5.3.2.

---

S 10.

>These do not appear to be normative references. I at least need to know enough about
>the structure to know what to expect.

There was another sec-dir/gen-art comment asking to add the web links to the reference section.

I will to that, but I have not yet found the XML way of doing it.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Jan 2019 19:47:32 +0000

Seems like I skipped one issue in my previous reply.

S 5.3.2.

>The current text prohibits racing if you *don't* know that the UA is awake.

The basic assumption of the mechanism is that a UA cannot receive SIP requests before it has received the push notification, sent the REGISTER etc.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Jan 2019 14:07:43 -0800

On Mon, Jan 7, 2019 at 11:47 AM Christer Holmberg <
[email-masked]> wrote:

> The basic assumption of the mechanism is that a UA cannot receive SIP
> requests before it has received the push notification, sent the REGISTER
> etc.
>

But that may or may not be true, depending on whether the device has gone
to sleep

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Jan 2019 12:50:17 +0000

Hi,

S 5.3.2.

>But that may or may not be true, depending on whether the device has gone to sleep

Implementations can of course do whatever they want, but I think it is bad design to specify such behavior. Unless the request will reach the UA, some re-transmissions will be "wasted", and once the proxy receives the REGISTER the re-transmission timer might have become rather big.

But, perhaps we could say something like:

"if the proxy has knowledge, or strong reasons to believe, that the UA is awake"

An example of such strong reason is that the proxy received the previous REGISTER just a few seconds ago.

Regards,

Christer

-Ekr

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Jan 2019 13:07:51 +0000

Hi,

For some strange reason most of the text got cut from my previous reply. Trying again.

S 5.3.2.

Implementations can of course do whatever they want, but I think it is bad design to specify such behavior. If the request will not reach the UA, some retransmissions will be wasted, and the retransmission interval will increase.

I would also assume that it could trigger unnecessary discarded message error logging etc.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Jan 2019 13:44:31 +0000

Again the text is cut off... Don't know what is going on...

-----Original Message-----
From: Christer Holmberg <[email-masked]> 
Sent: Tuesday, January 08, 2019 3:08 PM
To: Eric Rescorla <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Eric Rescorla's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT) - the COMMENT issues - part 3

Hi,

S 5.3.2.
>>      response) before it tries to forward the SIP request towards the UA

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Jan 2019 05:47:18 -0800

On Tue, Jan 8, 2019 at 4:50 AM Christer Holmberg <
[email-masked]> wrote:

> Implementations can of course do whatever they want, but I think it is bad
> design to specify such behavior. Unless the request will reach the UA, some
> re-transmissions will be "wasted",
>

We trade off "wasted" transmissions for performance all the time. For
instance: RFC 6555.

and once the proxy receives the REGISTER the re-transmission timer might
> have become rather big.

Well, that's easy to fix by not incrementing the timer on these
transmissions.

> REGISTER just a few seconds ago.

This text still seems to discourage this behavior, and I'm not in agreement
with you that we should do so.

-Ekr

Regards,

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Jan 2019 14:23:11 +0000

Hi,

S 5.3.2.
> The basic assumption of the mechanism is that a UA cannot receive SIP requests before it has 
> received the push notification, sent the REGISTER etc.
>
>> Implementations can of course do whatever they want, but I think it is bad design to specify such 
>> behavior. Unless the request will reach the UA, some re-transmissions will be "wasted", 
>
> We trade off "wasted" transmissions for performance all the time. For instance: RFC 6555.
>
>> and once the proxy receives the REGISTER the re-transmission timer might have become rather big.
>
> Well, that's easy to fix by not incrementing the timer on these transmissions.

That would modify the core SIP re-transmission procedures (and impact the SIP stack). I don't want to do that.

> This text still seems to discourage this behavior, and I'm not in agreement with you that we should do so.

The reason the default behavior is waiting for the REGISTER request, and the corresponding response, it to make sure that the R-URI is still valid etc. Saying that the proxy can skip those rules whenever it wants, and just forward the request before it has received the REGSTER response, breaks that whole mechanism.

As an optimization, the WG agreed to allow forwarding the request prior to receiving the REGISTER response if the proxy has "knowledge" that the UA is alive. Such knowledge could e.g., be an active security association, an active SIP session, or something else that the proxy keeps track of. If the UA does not have such knowledge, it needs to wait for the REGISTER response. Nothing is broken, so I don't want to change that.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Jan 2019 14:36:42 +0000

Hi,

DETAIL
S 5.3.2.
>suppose that [email-masked]<mailto:[email-masked]> and [email-masked]<mailto:[email-masked]> both register with the
>[email-masked]<mailto:[email-masked]>, PRIDb? And what happens if that happens?

>No conformant registrar will. But what about a nonconformant one? Or another endpoint.

Such registrar/endpoint would not even be SIP compliant.

But, IF it happens, the UA associated with PRIDb will receive a push notification and send a REGISTER. But, since the REGISTER contact will not match the R-URI of the SIP request to be forwarded, the SIP request will not be forwarded by the proxy (eventually there will be a timeout)

---

S 5.3.2.

>Such as?

E.g., if the UA has changed its IP address and/or port.

>But *this* text requires you to behave in a certain way in case of mismatch. When will
>this be executed?

I suggested modified text, that only talks about the case when there is a match. In other cases, when there is no match, there will be a timeout.

---

S 6.2.1.

>You need to say that.

Ok. I suggest to add:

"Since the PURR value will be transported to the remote peer, the value MUST be generated..."

---

S 13.

>Why "middleman" as opposed to any endpoint.

I can change "middleman" to "endpoint".

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Jan 2019 15:19:04 -0600

> On Jan 7, 2019, at 8:08 AM, Eric Rescorla <[email-masked]> wrote:
> 

For the record, this has already undergone a number of revisions due to editorial review in the WG and during AD evaluation. I agree it’s not ideal, but I think most of it can be understood. I fear we’ve already reached the point of diminishing returns regarding to stylistic issues.

That being said, there are some areas that would still be worthwhile to improve before this goes to the RFC editor.  I think the places where Ekr pointed out readability issues mostly deal with nested conditional statements in prose. Those should generally be avoided whenever possible;. They take a lot of effort for humans to read and comprehend.

This is especially true for center-imbedded conditions, e.g. “When you receive a  FOO request, if the request contains BAR, do BAZ.”  That would be more readable constructed as  “When you receive a FOO request that contains BAR, do BAZ.”  It often helps to break more complex procedures into steps.

Long sentences with multiple commas are often clues for this sort of issue.

Thanks,

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Jan 2019 15:29:46 -0600

> On Jan 7, 2019, at 1:04 PM, Christer Holmberg <[email-masked]> wrote:
> 
> 
> Hi,
> 
> S 1.

Just a note: This came up in WG discussion and again during the AD evaluation. IIRC, the consensus was to not attempt to solve the issue in this draft.

That being said, I think it would be worth including a note that the potential exists and is being punted to the future.

Thanks,

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Jan 2019 15:56:52 +0000

Hi,

...

> That being said, I think it would be worth including a note that the potential exists and is being punted to the future.

Section 4.1 contains the following:

   "NOTE: If the SIP UA application wants to use push notifications for
   other purposes than to trigger binding-refresh requests, it needs to
   be able to distinguish between the different purposes when receiving
   push notifications.  Mechanisms for doing that are outside the scope
   of this specification."

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 9 Jan 2019 12:26:15 -0600

> On Jan 9, 2019, at 9:56 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> ...
> 
>   of this specification.”

Ah, right. It might be worth adding something to the effect of “If a different push notification application is defined in the future, its specification will need to define how to do so.” before the last sentence.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Jan 2019 18:50:29 +0000

Hi,

...

> Ah, right. It might be worth adding something to the effect of “If a different 
> push notification application is defined in the future, its specification will need 
> to define how to do so.” before the last sentence.

I can do that.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Jan 2019 21:47:49 +0000

Hi,

Based on Ekr's COMMENT issues, I have submitted a pull request commit with the suggested changes.

https://github.com/cdh4u/draft-sip-push/pull/31/commits/407786b56bc9b9cd96c80139b716228253ac1a4f

This commit does not contain any major re-writes, and I may have forgotten something else, but it's a start.

(Note that the APNS and FCM web links have been added to the normative references in another commit.)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Jan 2019 21:54:16 +0000

Hi,

S 4.1.

>>contain "sip.pns" then you probably would still want to send regular

If the response doesn't contain "sip.pns" then none of the procedures apply.

Earlier in the section the text says:

  "In other cases, the UA MUST NOT assume that the proxy will request that push notifications is
   sent to the UA,   and the actions taken by the UA might be dependent on implementation or
   deployment architecture, and are outside the scope of this document."

So, if the UA wants to fallback to "regular" mode it can do so, but it is outside the scope of the document.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Jan 2019 14:06:12 -0800

> If the response doesn't contain "sip.pns" then none of the procedures

As before, the writing in the document makes it very hard to determine this.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Jan 2019 13:09:07 +0000

Hi,

S 4.1.

>As before, the writing in the document makes it very hard to determine this.

It is stated earlier in the section, but I can try to make it clear.

Regards,

Christer