Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Martin's comments

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Feb 2018 06:32:25 +0000

Hi,

> This document addresses a serious shortcoming.  For a long time, we have had SIP UAs on mobile devices that are privileged 
> by virtue of being developed and installed by the device vendor, but the nature of these platforms makes developing an alternative UA impossible.
>
> But it swaps one type of vendor lock-in for another.  This is a rare case of a (intended for) proposed standard document enshrining proprietary 
> protocols into the RFC >series.  And only proprietary protocols.  No definition is added for RFC 8030, despite that having a well-documented (and deployed) protocol.

If you can provide pointers to RFC 8030-based services, I would love to include them. I assume the Mozilla Push Service is one of them?

>The two proprietary protocols (for APNS and FCM) are not documented here, nor does the document normatively reference specifications for those protocols.  Given that >there are only two registered values for pn-provider, I don't see how this specification could be implemented by a proxy without information that is not normatively >referenced.

The purpose of the document is not to define a push service, but to allow usage of existing ones with SIP. And, the documentation on how to use those services is available.

>This document should discuss its relationship with RFC 5626 (outbound) and the existing mechanisms used to keep connections and NAT bindings between UA and proxy >alive.  My expectation is that if the parameters were supported connections would be allowed to drop and the push notification channel would be preferred.

Outbound uses periodic keep-alives, and the whole reason for this document is applications that cannot wake up (using timers) in order to e.g., send such keep-alives. 

> I don't understand why the terminology established in RFC 8030 wasn't used.  It's well-defined and clear.

> The discussion about what is sent in the push notification message isn't actionable.  It says that the payload is undefined.  I think that is unwise. 
> Either say that the payload is empty (which is possible) or it isn't.  

This SIP push does not mandate any payload - in addition to what the push mechanism itself may include.

The reason it talks about payload was because you requested a reference to RFC 8291 for allowing end-to-end encryption of possible payload. 

> That raises the question of whether you care about authentication of the message.
>
> I don't think that it is as simple as saying that authentication isn't important - you need to explain why.  
> RFC 8030 talks about the measures that it puts in place to ensure that user agents don't receive unwanted 
> push messages, but now you have a whole spectrum of potential proprietary protocols and systems that 
> could be used here, with unknown properties.

I am not saying that authentication is not important. The push services I am aware of do provide authentication.

But, I see your point, and I will add some text about authentication.

> Section 12.4 doesn't define the registration policy for the new registry.

I'll look into that.

Regards,

Christer