Subject: [sipcore] 2nd WGLC: draft-ietf-sipcore-sip-push-18

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 8 Oct 2018 08:16:46 -0500

Hi all,

Since there have been substantive changes made to the sip-push draft 
since the conclusion of its first WGLC (the feedback of which was 
incorporated into version -11), this is a second WGLC.

Please provide feedback on the changes and features added since version 
-11 by Friday, October 12. For those who have provided input since -11, 
please let us know if your feedback has been addressed.

https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/

Thanks!

Jean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Oct 2018 15:45:26 -0400

> please let us know if your feedback has been addressed.

I haven't reviewed this doc in a long time, so this query prompted me to 
do so. Generally looks good. Here are things I noted:

* Section 8

Could you please define abnf names referenced from other documents using 
the NAME = <...> syntax to ease verification?

* Section 10

The example is wrong:

   Example: pn-provider = apns

should be:

   Example: pn-provider = "apns"

* Section 5.3.1 (and elsewhere)

There seems to be an assumption baked in that all the contacts in the 
register request are for the device sending the request. While that is 
the common case, it isn't necessarily the case.

IIUC it isn't necessary to make any such assumption. Rather, all the 
state that is being managed should be associated to each contact in the 
register request. (In principle those contacts can even have different 
expiration times.) It then becomes an optimization to send one 
notification for multiple contacts that happen to expire at the same 
time and have the same PRID.

(Note that when there are multiple contacts in a register request the 
registrar doesn't know if those contacts identify multiple paths to a 
single UA or to distinct UAs.)

ISTM that there needs to be some text addressing this. Either sorting 
out how it works, or limiting usage of this mechanism to cases where all 
the contacts being registered are paths to a single UA and have a single 
expiration time.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Oct 2018 07:31:13 +0000

Hi Paul,

Please see inline.

>* Section 8
>
>Could you please define abnf names referenced from other documents >using

I will fix as suggested.

(I assume this is the same comment you had in BFCPbis)

-----

>   Example: pn-provider = "apns"

The syntax for pn-provider is:

          pn-provider     = "pn-provider" EQUAL pvalue

...and the syntax for pvalue is:

         pvalue            =  1*paramchar

-----

>the contacts being registered are paths to a single UA and have a single

My suggestion is to limit the usage to cases where all the contacts are associated with a single UA, as multiple UAs won't share the same PRID.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Oct 2018 09:33:09 +0000

Hi,

...

> My suggestion is to limit the usage to cases where all the contacts are associated with a single UA, as multiple UAs won't share the same PRID.

I was looking at the draft, and I am not sure whether we need to add anything. The proxy text already talks about requesting push notifications for bindings.

Also, as far as the push mechanism is concerned, I don't think we need for forbid registering bindings for other UAs. In reality I don't think it will be used, though.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Oct 2018 10:13:30 +0000

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

________________________________
From: sipcore <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Sent: Tuesday, October 9, 2018 12:33 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] 2nd WGLC: draft-ietf-sipcore-sip-push-18

Hi,

...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Oct 2018 11:42:52 -0400

> (I assume this is the same comment you had in BFCPbis)

Yup!

> ...and the syntax for pvalue is:

Sorry, my mistake. I mixed it up with pns-list.

> My suggestion is to limit the usage to cases where all the contacts are 
> associated with a single UA, as multiple UAs won't share the same PRID.

I'd be happy with this. What about the case where there are multiple 
contacts for the same UA but with different expiration times? (I'm 
stretching here - I can't think of a reason why.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Oct 2018 06:49:04 +0000

Hi,

...
    
    > stretching here - I can't think of a reason why.)
    
As I wrote in a follow-up reply yesterday, I am not sure whether we would need such restrictions. The proxy will check all bindings, and request a push notification if one or more is about to expires. Obviously, as stated in the document, when the UA receives the push notification it will also refresh bindings that are not about to expire. But, that won't break anything.

However, in my experience, if a UA registers multiple contacts to begin with, it will use the same expiration time for all of them.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Oct 2018 10:25:46 +0000

Hi,

I have updated the pull request, adding text saying that a UA SHOULD use the same 'expires' value for each binding, and that the UA MUST NOT create bindings for other UAs.

Regards,

Christer

On 10/10/2018, 9.50, "sipcore on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,
    
    ....

    
    
    Regards,
    
    Christer

    _______________________________________________
    sipcore mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2018 12:44:57 -0400

> As I wrote in a follow-up reply yesterday, I am not sure whether we would need such restrictions. The proxy will check all bindings, and request a push notification if one or more is about to expir…

I guess you are right - that the proxy will need to generate the notify 
for the earliest expiring binding, and the UA can refresh them all at 
the same time. There is of course no requirement for the UA to refresh 
them all. It might decide to simply refresh the one about to expire and 
not mention the others, in the expectation that they will be unchanged. 
(This is odd behavior, but not forbidden.)

If that were to happen, the proxy would need to generate a new 
notification when the next of the contacts is about to expire.

I don't think we need to make any special requirements on the UA for 
this. And I guess maybe the required behavior of the proxy in such a 
case is implied.

> However, in my experience, if a UA registers multiple contacts to begin with, it will use the same expiration time for all of them.

Yes, I would expect this to be typical. I don't know why an 
implementation would do otherwise, but you never know.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Oct 2018 19:44:35 +0000

Hi,

…

>> As I wrote in a follow-up reply yesterday, I am not sure whether we would need such restrictions.

>> The proxy will check all bindings, and request a push notification if one or more is about to expires.

>> Obviously, as stated in the document, when the UA receives the push notification it will also refresh

>> bindings that are not about to expire. But, that won't break anything.

> (This is odd behavior, but not forbidden.)

The UA needs to refresh all bindings, because the reason for the push notification might be an incoming request.

 (In future we might consider carrying information in the push notification whether it's sent just to trigger a binding refresh, or whether there is also an incoming request, and for which binding(s) the push notification is sent).

So, for that reason I think it is good to say that the UA SHOULD use the same expiration for all bindings.

Regards,

Christer