Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-sip-push-20 - Ben's technical comments

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Nov 2018 15:50:52 +0000

Hi,

Thanks for the comments! Please see inline.
    
>    §1, paragraph 5: "Note that this mechanism necessarily adds delay to
>    responding to non-INVITE requests requiring push notification."
>    
>    Technically, it adds delay for any transaction. Non-INVITE transactions are just more delay sensitive.

I suggest to say: "adds delay to responding to requests".

---
    
> §3,
>    - first paragraph:
>    Please state this in terms of a scope assumption, not a global statement. That is, limit the scope of this 
>    document is limited to PNSs that work this way, rather than state that all PNSs work this way.
    
I suggest to say: "The mechanism defined in this document assumes that, when a SIP UA registers with a PNS, it..."

>    - 2nd paragraph: I think it's safe to say "The format of the PRID varies..." rather than "... may vary...".

I will fix as suggested.

---
    
> §4.1
>    
>    - General: When we speak of multiple bindings, and doing something to all of those bindings (e.g. refreshing 
> them on a push-notification), is it allowable for a UA to have some bindings that use a PNS and some that do not? 
> Or perhaps some that use different PNSs? I realize that may not make sense for the mobile device use case that 
> seems centric to this draft, but I can imagine a situation where a complex UA might have different PNS configurations f
> or different network paths and/or different SIP services.
>   
> If you want to assume that the PNS configuration is the same for all contacts, please say so explicitly. If not, does it 
> make sense to scope PNS-triggered refreshes to just those bindings that use the same PNS configuration?
   
I don't think there is any technical reason to mandate usage of the same PNS (or using PNS to begin with) for all contacts, so I don't think we need to forbid it.

We could say something like: "The procedures in this section apply to bindings associated with a given PNS."

I don't think we need to say more than that.
 
>    -2nd paragraph:
>    I don't think we can assume that all UAs will always learn all the bindings they need to to setup at the same time. 
>   For example, a UA might have changes in network configuration that require them to add or remove bindings. This 
>   makes it impractical to register them at the same time and always use the same expirations, unless we ask them to 
>   refresh all existing bindings whenever they add a new one. (Or perhaps ask them to set the expiration of any new 
>  binding to match the remaining time for existing ones, but that seems like a more difficult approach.)
    
I don't think the text assumes that the UA is aware of all bindings at the same time - it only says that it should use the same 'expires' value for each binding.

>-6th paragraph: "REGISTER request will create NAT bindings..."
>    
>    If we talk about creating NAT bindings as one of the purposes of the push-triggered REGISTER, we may also need to 
>    think about the lifetime of those nat bindings, and how that interacts with the REGISTER expires value. I'm not sure we 
>   want to go there; would it make sense to remove the mention?
    
I am not sure that is needed in the context of PUSH, since the NAT bindings only need to be alive in time for the request that triggered the push notification to reach the UA. Next time there is an inbound SIP request, the REGISTER triggered by the push notification associated with the request will create a NAT binding (if the previous one has expired) for that request.

>    - 7th paragraph:
>    --  The first sentence seems to still assume the REGISTER has as single contact. Should it say to insert the tag into each 
> contact header field? (but see general §4.1 comment above.)
   
What sentence are you referring to?

 >   -- "if the response to the REGISTER request contains a ’sip.pnsreg’
 >   feature-capability indicator with an indicator value, the UA MUST
 >   send REGISTER requests prior to the registration expires."
 >   
 >   This seems to duplicate a MUST from normal SIP. Would it make sense to just say "... the UA refreshes the binding 
>    according to normal SIP procedures".
    
I will fix as suggested.

---

>    §5.3.1:
>    - 4th paragraph: Section 4.1 talks about the UA paying attention to sip.pns in a 2XX response. It does not mention 
>   it for other result codes. If the UA needs to pay attention to it in 423 (or in any other response), it should be mentioned there.
   
There are no push-specific UA actions for non-2xx responses.

If the UA receives a 423, it follows normal SIP procedures. Even if the proxy has inserted 'sip.pns' feature-capability indicator in the 423 response it only provides information about the PNS(s) supported by the proxy. It does not mandate push-specific UA actions.

>    -7th paragraph, "the proxy SHOULD insert a Feature-Caps header
>    field with a ’sip.pns’ feature-capability indicator": What if the response already contains it?

The text covers the case where the proxy generates the 423 response.
  
---

> §5.3.2, 2nd paragraph: Please mention that the R-URI will only contain these parameters after it is retargeted. This mostly 
> matters if the push-proxy is colocated with a retargeting proxy; retargeting must happen before this procedure.

Section 1 says:

   "The proxy MUST be in the signalling path of REGISTER requests sent by
   the UA towards the registrar, and of SIP requests (for a new dialog
   or a stand-alone) forwarded by the proxy responsible for the UA's
   domain (sometimes referred to as home proxy, S-CSCF, etc) towards the
   UA."

> Along those lines, what is the PUSH proxy expected to do with inbound SIP requests that do not contain the parameters 
> in the R-URI? Route them normally? Reject them?

I think that is an implementation issue. If the proxy also handles non-PNS calls, it would forward the request using normal procedures.

---

>    §6: Is support for push-notifications on mid-dialog requests optional? If so, please state that up front.

If one wants to support longlived SIP dialogs, one obviously will have to implement section 6. I am not sure we need to say something.
    
---

>    §6.1.1: Does the UA indicate support on a per-dialog basis? That is, it can support the mechanism for some dialogs but not others?

It could be per-dialog basis. The text says: "if the UA is willing to receive push notifications triggered by incoming mid-dialog requests".
    
---

>    §8.1, 2nd paragraph: Should that say "only defined for ... responses", or "... and is not defined for use in request messages."?
 
I suggest to say "only defined for".

---
   
>    §9, 1st paragraph: We are talking about a specification that defines the parameter usage for the given PNS, not the PNS in it's entirety, right?

Yes. I suggest to say: "defines the usage of the associated PNS". Because, the parameter itself only identifies the PNS.

---

>    §13, 3rd paragraph: The paragraph as written basically says "Operators must ensure SIP signaling is secured unless they are 
>    sure it's secured", which is circular logic. Would it make sense to say they must use TLS (or SIPS) unless they are sure that 
>    it is protected by other mechanisms?

Sounds good. I will fix as suggested.    

---

> §16.2: I think the reference to RFC 3891 should be normative.

I will make it normative.

I will address the editorial comments in a separate e-mail.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 30 Nov 2018 10:50:18 -0600

Thanks for the quick response! More inline. I removed sections that seem to be resolved.

Ben.

> On Nov 30, 2018, at 9:50 AM, Christer Holmberg <[email-masked]> wrote:
> 

[...]

> I don't think we need to say more than that.

That works for me.

> I don't think the text assumes that the UA is aware of all bindings at the same time - it only says that it should use the same 'expires' value for each binding.

That depends on whether you consider “Expires” to be the time remaining until expiration, or the Expires header (or parameter) on a specific Register request. For example, if I register contact “A” with an expiration of 2 hours, and then register contact “B” an hour later, it would need to have a 1 hour expires value in order to expire at roughly the same time.

> I am not sure that is needed in the context of PUSH, since the NAT bindings only need to be alive in time for the request that triggered the push notification to reach the UA. Next time there is an…

A one line comment to that effect would be helpful.

> What sentence are you referring to?

Sorry, it’s the 8th paragraph: "If the UA is able to send binding refresh REGISTER requests using a
non-push mechanism (e.g., using an internal timer that periodically
wakes the UA), the UA MUST insert a ’sip.pnsreg’ media feature tag
[RFC3840] in the Contact header field URI of each REGISTER request"

[...]

> If the UA receives a 423, it follows normal SIP procedures. Even if the proxy has inserted 'sip.pns' feature-capability indicator in the 423 response it only provides information about the PNS(s) s…

You are right, or course. Nevermind :-)

[...]

>   UA.”

Okay

> I think that is an implementation issue. If the proxy also handles non-PNS calls, it would forward the request using normal procedures.

A brief mention of that would be helpful.

> If one wants to support longlived SIP dialogs, one obviously will have to implement section 6. I am not sure we need to say something.

I’m more concerned about whether an implementation can choose _not_ to support long-lived dialogs. I assume so since there’s a separate negotiation. All I’m looking for is the word “optional” somewhere early in the section :-)

> It could be per-dialog basis. The text says: "if the UA is willing to receive push notifications triggered by incoming mid-dialog requests”.

I assume that if the UA indicates support in one dialog-initiating transaction but not another, that the proxy should not assume that it supports mid-dialog push in both transactions. If that’s a correct assumption, it would be helpful to explicitly state it.

[...]

> Yes. I suggest to say: "defines the usage of the associated PNS". Because, the parameter itself only identifies the PNS.

You said “Yes”, which I take to agree that we don’t require a spec for the PNS itself, but then you said “defines the usage of the associated PNS”, which does sound like a requirement for a spec of the PNS itself. So I’m confused :-)

[...]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Nov 2018 12:36:10 -0500

On 11/30/18 11:50 AM, Ben Campbell wrote:

>>>   -2nd paragraph:
>>>   I don't think we can assume that all UAs will always learn all the 
>>> bindings they need to to setup at the same time.
>>>  For example, a UA might have changes in network configuration that 
>>> require them to add or remove bindings. This
>>>  makes it impractical to register them at the same time and always 
>>> use the same expirations, unless we ask them to
>>>  refresh all existing bindings whenever they add a new one. (Or 
>>> perhaps ask them to set the expiration of any new
>> I don't think the text assumes that the UA is aware of all bindings at 
>> the same time - it only says that it should use the same 'expires' 
>> value for each binding.
> 
> That depends on whether you consider “Expires” to be the time remaining 
> until expiration, or the Expires header (or parameter) on a specific 
> Register request. For example, if I register contact “A” with an 
> expiration of 2 hours, and then register contact “B” an hour later, it 
> would need to have a 1 hour expires value in order to expire at roughly 
> the same time.

The time in the expiration time in the request is only a preference. The 
registrar may reduce this value. So, if the registrar wants the 
expiration time for one binding to match that of some other binding then 
it has some power to make that happen as long as the requested 
expiration is big enough.

(This can be confusing because while the values negotiated are encoded 
as intervals what is actually being negotiated is a particular point in 
time when the expiration occurs. Each end sets the point in time as its 
notion of the current time plus the expiration time (interval). Due to 
propagation delay the times at the two ends are only approximately 
equal. For the UAC this needs to be done based on the value in the 
response.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Nov 2018 21:04:50 +0000

Hi,

I saw that Paul replied on the “Expires” issue, so I will reply to his e-mail on that issue.

---

> A one line comment to that effect would be helpful.

I suggest adding the following:

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

---

> non-push mechanism (e.g., using an internal timer that periodically wakes the UA), the UA MUST 
> insert a ’sip.pnsreg’ media feature tag [RFC3840] in the Contact header field URI of each REGISTER request"

I will fix as suggested (“insert a tag in each Contact header field”).

---

> A brief mention of that would be helpful.

I suggest the following:

"NOTE: If the SIP request does not contain the pn- parameters, the proxy processing of the request is based on local policy, e.g., depending on whether the proxy servers requests towards UAs that do not use the SIP push mechanism, in which case the proxy will forward the request using normal SIP procedures. Otherwise the proxy might reject the request."
 
---

> I’m more concerned about whether an implementation can choose _not_ to support long-lived dialogs. I assume 
> so since there’s a separate negotiation. All I’m looking for is the word “optional” somewhere early in the section :-)

An implementation can choose not to support a feature no matter what the spec says :)

What about adding the following to the end of the first paragraph:

"The procedures in this section are optional to support, but MUST be supported by proxies that will deployed in SIP networks where the type SIP dialogs described above might occur."

---

> I assume that if the UA indicates support in one dialog-initiating transaction but not another, that the proxy should not assume 
> that it supports mid-dialog push in both transactions. If that’s a correct assumption, it would be helpful to explicitly state it.

I suggest the following:

"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 header of the request or response for each dialog in which the UA is willing to receive push notifications triggered by incoming 
  mid-dialog requests."

(Related to that, I noted that the purr parameters are missing from the grammar, IANA section etc. I will fix that.)

---

> You said “Yes”, which I take to agree that we don’t require a spec for the PNS itself, but then you said “defines the usage of the 
> associated PNS”, which does sound like a requirement for a spec of the PNS itself. So I’m confused :-)

You do need a spec that defines how to use the PNS, but you don't need to details on how the PNS is implemented etc.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 30 Nov 2018 15:15:39 -0600

I also replied to the other thread on expiration syncing.

Otherwise, this all looks good. I have one remaining comment, below.

> On Nov 30, 2018, at 3:04 PM, Christer Holmberg <[email-masked]> wrote:
> 
f
That tells me it really intended as an optional feature, in which case I’m fine leaving it as is.

Thanks!

Ben.