Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-29

[Ballot comment]
Thanks for addressing my discuss points. Although I find the solution
for SUBSCRIBE dialogs particularly unsatisifying, I'm not going to get
in the way of working group consensus here. The original discuss points
(and original comments) are detailed below.

---------------------------------------------------------------------------

Thanks to everyone who is put work into defining this mechanism. I think it will
be very useful to have a solution for integrating push mechanisms into SIP
networks. I've identified three issues that I think need to be addressed in the
current document before it can move forward, and a fourth serious flaw that I
call out in my comments below.

---------------------------------------------------------------------------

It's nice that this document has considered the impact of inbound mid-dialog
messages in long-lived dialogs. However, it appears to have a major hole in it:
handing of outbound messages for the purpose of maintaining soft-state in those
dialogs isn't handled correctly.

In particular: networks that deploy this mechanism will cause SUBSCRIBE
dialogs to time out and be destroyed while they are still in use.
Additionally, if RFC 4028 (session timers) is negotiated, then INVITE dialogs
will suffer the same fate.

I can think of a couple of ways for these situations to be handled, but they
need explicit text in the document.

One approach would be to specify that the User Agent selects its requested
"Expires" value in its registration to be the smallest value before its set of
subscriptions and session timers needs to be refreshed. This would cause a push
notification to happen to prevent registration timeout, and the client could
refresh the other soft state at that time. Complications arise if the registrar
responds with a 483 (Interval too Brief), and we'd need to find a solution for
that.

Another approach would be for the clients to refresh all soft state whenever
they send a registration, and set the timeout for that soft state to be equal to
or greater than the registration timeout. A complication could arise if the
notifier or the peer in an invite dialog shortens the requested time, and we'd
need to find a solution for that.

A third approach would be getting the proxy involved in some way -- either by
requiring it to observe subscription and session timer timeouts and requiring it
to send push notifications prior to their expiration, or by an explicit
communication between the UA and the proxy that indicates when the next push
notification should be scheduled. If the latter approach is taken, I would
suggest that it needs to be taken for REGISTER messages as well.

I really don't think this mechanism is feasibly deployable without a solution to
this problem.

---------------------------------------------------------------------------

§4.1:

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

This seems to ignore the availability of Contact URI parameters via RFC 3680
subscriptions. This would seem to impose a requirement on Registrars to strip
this information before making it available to any other party (which, in
turn, requires that the system have explicit Registrar *and* Proxy support).
As far as I can tell, the system so far has not required explicit proxy support
(and there's certainly no mechanism built-in that ensures that a proxy has any
special handling regarding this mechanism).

If the PNS information is sensitive, and cannot be allowed to leak out to
other users, then we need some way to ensure the registrar has provided
positive confirmation that it will not do so before allowing it to come into
possession of them.

---------------------------------------------------------------------------

§4.2:

>  The UA can do so by only including the pn-provider
>  SIP URI parameter in the SIP Contact header field URI of the REGISTER
>  request, but without including the pn-prid SIP URI parameter.

Unless I'm mistaken, this is a barrier to interoperation.

It's not 100% clear, but I suspect the intended implication is that the
pn-provider parameter here will contain a single value? The syntax of the
parameter certainly seems to imply that. This seems to be a pretty big
problem, since it presupposes that the client will know which PNSes the Proxy
supports.  Consider, for example, an iOS client that can use any of RFC 8030,
FCM, and APN (cf https://firebase.google.com/docs/cloud-messaging/ios/client).
If the client doesn't know a priori what the proxy supports (and this entire
section only makes sense if that's true), then it won't know which of those
three services to indicate in its REGISTER request. If it guesses wrong, this
mechanism simply fails.

I think you need a different discovery mechanism here -- either have one that
has the client offering multiple PNS protocols and the proxy responding with
one, or have one in which the proxy indicates all of its supported services in
a response, and the client chooses one to use in its next REGISTER message.

---------------------------------------------------------------------------

Figure 1:

This diagram includes both a ladder diagram and an example REGISTER message.
While both of these are useful at this point in the document, neither of them is
an "Architecture," and they're really two different things. I suggest breaking
this into two Figures, entitled "Typical Information Flow" and "Example REGISTER
Message" (or similar), respectively.

---------------------------------------------------------------------------

§4.1:

>  As long as the UA wants to receive push notifications (requested by
>  the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param
>  (if required for the specific PNS provider) SIP URI parameter in each
>  binding-refresh REGISTER request.

Please be clear that these parameters appear in the Contact URI.

---------------------------------------------------------------------------

§5.2:

>  In order to request push notifications towards a SIP UA that will
>  trigger the UA to send binding-refresh SIP REGISTER requests, the SIP
>  proxy needs to have information about when a registration will
>  expire.  The proxy needs to be able to retrieve the information from
>  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].

Nit: "SIP registration"

This mechanism seems to be predicated on an architecture in which the proxy must
be on the traffic path. Although it's problematic from a "what proxies are
expected to do" perspective, it seems like the proxy could glean this
information from the 200 response to the REGISTER request. (I mean, the proxy is
already reading parameters out of the contact header field, so the behavior of
acting on registration information is already assumed). The proxy would, of
course, need to run its own timers, but that seems to be a pretty minor
requirement, given everything else involved here.

---------------------------------------------------------------------------

§5.3.1:

This is a major comment, and one that has a sufficient impact on interop that I
had a long debate with myself about whether it should be a DISCUSS. Please take
it very seriously.

>  Otherwise, if the pn-provider SIP URI parameter identifies a type of
>  PNS that the proxy does not support, or if the REGISTER request does
>  not contain all additional information required for the specific type
>  of PNS, the proxy MUST either forward the request (e.g., if the proxy
>  knows that another proxy that will receive the REGISTER request
>  supports the type of PNS)...

How would the proxy know this?

Features like suppressing PNS behavior when a "sip.pns" feature capability is
present in the REGISTER imply that the various nodes in the network discover
capabilities of their neighbors automatically (which is consistent with the way
SIP does features), while this provision seems to require provisioned knowledge.
This is going to be operationally very confusing.

At the very least, the document needs to call out how this "knowledge" is
obtained. In the more general sense, since a client cannot rely on the proxy
supporting *any* kind of PNS, the use of 555 in the way specified here is at
best an optimization -- and, since the configured information can conflict with
actual reality, it's an optimization that can actually break things unless
extreme care is exercised. (e.g., if the proxy is configured to "know" that the
next proxy cannot provide push service, but this knowledge is wrong, then the
network is unnecessarily broken.)

My rather strong recommendation is to remove this code, and let the client rely
on the lack of indication of support in the response indicate that the feature
is not supported.

---------------------------------------------------------------------------

§5.3.1:

>  o  if the proxy received a 'sip.pnsreg' media feature tag in the
>    REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature-
>    capability indicator with an indicator value bigger than 120 in
>    the response, unless the proxy always want to request push

Nit: "...wants..."

---------------------------------------------------------------------------

§5.3.2:

>  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 seems to be a very strong requirement ("MUST") when, e.g., many or most
networks may want to return a 480 instead of a 404. I think what you want to say
is something like "...MUST reject the SIP request. Response codes of either
404 (Not Found) or 480 (Temporarily Unavailable) are RECOMMENDED, but other
appropriate codes may be used as well."

---------------------------------------------------------------------------

§5.3.2:

>  The reason the proxy needs to wait for the REGISTER response before
>  forwarding the SIP request is to make sure that the REGISTER request
>  has been accepted by the registrar, and that the UA which initiated

Nit: "...the UA that initiated..."

---------------------------------------------------------------------------

§5.3.2:

>  In case of non-2xx response to the REGISTER request, the proxy MUST
>  reject the SIP request with a 404 (Not Found) response.
>
>  If the push notification request fails (see PNS-specific
>  documentation for details), the proxy MUST reject the SIP request
>  with a 480 (Temporarily Unavailable) response.
>
>  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.

As above, this seems way too restrictive in terms of mandating specific error
codes. It may well be the case that a network would want to treat these
situations identically from the perspective of the calling party.

---------------------------------------------------------------------------

§5.3.2:

>  Otherwise the
>  proxy MUST reject the SIP request with a 480 (Temporarily
>  Unavailable) response.

Same comment as above.

---------------------------------------------------------------------------

§6.1.1:

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

Nit: "...sends an initial request..."

>  purr' SIP URI parameter in the Contact header of the request or

Nit: "...Contact header field..."

>  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

Nit: "...given dialog..."

>  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

Nit: "...Contact header field..."

---------------------------------------------------------------------------

§6.1.1:

>  The UA MUST include a parameter value identical to the the
>  last 'sip.pnspurr' feature-capability indicator that it received in a
>  REGISTER response.

This is incredibly confusing, as the "sip.pnspurr" indicator has not been
mentioned in the document so far. Please revise as something along the lines of:

>  The UA MUST include a parameter value identical to the the last
>  'sip.pnspurr' feature-capability indicator (see Section 6.2.1) that it
>  received in a REGISTER response.

Alternately, reverse the order of sections 6.1 and 6.2 so that the PURR
concept is properly introduced before protocol procedures are defined for it.

---------------------------------------------------------------------------


§6.1.1:

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

Similar to the above, this is a very confusing introduction of the "pn-purr" URI
parameter.

---------------------------------------------------------------------------

§6.2.2:

>  Contact header field with a PURR value that the proxy has generated
>  Section 6.2.2, the proxy MUST add a Record-Route header to the
>  request, to insert itself in the dialog route [RFC3261].

This "Section 6.2.2" makes the sentence impossible to read. Is it intended to be
in parentheses?

---------------------------------------------------------------------------

§6.2.3:

>  As described in Section 5.3.2, while waiting for the push
>  notification request to succeed, and the associated REGISTER request
>  to arrive from the SIP UA, the proxy needs to take into consideration
>  that the transaction associated with the NOTIFY request will
>  eventually time out at the sender of the request (UAC), and the
>  sender will consider the transaction a failure.

I think this needs some discussion about the impact of the error codes selected
by the proxy on the dialog and its usages. For example:

* If the proxy sends a 404 to prevent a transaction timeout, it will destroy the
  dialog and all of its usages

* If the proxy sends a 480 to prevent a transaction timeout, it will destroy the
  usage, but not other usages in the dialog (if any)

* If the proxy sends a 504 to prevent a transaction timeout, it will keep the
  dialog and the usage alive, and allow the client to re-try at a later time.
  Simply allowing the transaction to time out will have the same effect, albeit
  with more message retransmissions.

Pointing to RFC 5057 might be useful here.

---------------------------------------------------------------------------

§8.7:

>    Parameter value characters that are not part of pvalue needs to be
>    escaped, as defined in RFC 3261.

Nit: "...need to be escaped..."

---------------------------------------------------------------------------

§9:

>  When a new value is registered to the PNS Sub-registry, a reference
>  to a specification which describes the usage of the PNS associated

Nit: "...specification that describes..."

---------------------------------------------------------------------------

§§10-12:

Nit: It seems like these should all be subsections of section 9.

---------------------------------------------------------------------------

§10:

>  The Topic consists of the Bundle ID, which uniquelly identifies an
>  appliciation, and a service value that identifies a service

Nit: "uniquely"
Nit: "application"

---------------------------------------------------------------------------

§10:

>  Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp.voip

Please use an RFC 2026 domain for this example; e.g.:

>  Example: pn-param = DEF123GHIJ.com.example.yourexampleapp.voip

---------------------------------------------------------------------------

§11:

>  [RFC8292] defines a mechanism which allows a proxy to identity itself

Nit: "...mechanism that allows..."

[Ballot comment]
One question on the new PNS registry:
I don't quite understand why the policy is "Specification Required". I guess you need some description of the values for pn-provider, pn-param and pn-prid. However, you could just add these fields to the registry directly (with the option to just provide a reference in at least the param and prid fields if the description is rather extensive). However, for e.g. RFC8030 is would easily be possible to describe everyhing you need within the registry. For apns and fcm you can simply add a pointer to this new RFC if you think the description is too long to be included in the registry directly. But this could make registration for new simple services easier.

And one minor comment on some language:
Should these sentence in 3.1  and 5.2 maybe be normative as well:
"If a SIP UA
  receives a push notification that contains a payload the UA can
  discard the payload, but the UA will still send a binding-refresh
  REGISTER request."
e.g NEW
"If a SIP UA
  receives a push notification that contains a payload the UA can
  discard the payload, but the UA MUST still send a binding-refresh
  REGISTER request."

"A proxy
  will not request push notifications towards a UA that has not
  provided a pn-prid SIP URI parameter."
e.g. NEW
"A proxy
  MUST NOT request push notifications towards a UA that has not
  provided a pn-prid SIP URI parameter."

It seems like these sentences are on purpose not normative (maybe because as they are part of a note...?), however, I think it would be more clear to state those requirements normatively as well. Otherwise if you think these requirement are described normatively somewhere else in the doc, I think a forward reference would be good (I didn't double-check myself).

nits:
- maybe s/consider the interval too small/consider the interval too short/
- maybe s/response Section 8.1/response (see Section 8.1)/
- s/proxy receives a receives a SIP/proxy receives a SIP/

[Ballot comment]
On question on the new PNS registry:
I don't quite understand why the policy is "Specification Required". I guess you need some description of the values for pn-provider, pn-param and pn-prid. However, you could just add these fields to the registry directly (with the option to just provide a reference in at least the param and prid fields if the description is rather extensive). However, for e.g. RFC8030 is would easily be possible to describe everyhing you need within the registry. For apns and fcm you can simply add a pointer to this new RFC if you think the description is too long to be included in the registry directly. But this could make registration for new simple services easier.

And one minor comment on some language:
Should these sentence in 3.1  and 5.2 maybe be normative as well:
"If a SIP UA
  receives a push notification that contains a payload the UA can
  discard the payload, but the UA will still send a binding-refresh
  REGISTER request."
e.g NEW
"If a SIP UA
  receives a push notification that contains a payload the UA can
  discard the payload, but the UA MUST still send a binding-refresh
  REGISTER request."

"A proxy
  will not request push notifications towards a UA that has not
  provided a pn-prid SIP URI parameter."
e.g. NEW
"A proxy
  MUST NOT request push notifications towards a UA that has not
  provided a pn-prid SIP URI parameter."

It seems like these sentences are on purpose not normative (maybe because as they are part of a note...?), however, I think it would be more clear to state those requirements normatively as well. Otherwise if you think these requirement are described normatively somewhere else in the doc, I think a forward reference would be good (I didn't double-check myself).

nits:
- maybe s/consider the interval too small/consider the interval too short/
- maybe s/response Section 8.1/response (see Section 8.1)/
- s/proxy receives a receives a SIP/proxy receives a SIP/

[Ballot discuss]
I am generally excited about addition of push notifications to SIP.
I have a couple of comments (and a few less serious ones) that I would like to discuss before recommending approval of this document:

10.  pn-provider, pn-param and pn-prid URI Parameters for Apple Push
    Notification service

  When the Apple Push Notification service (APNs) is used, the PNS-
  related SIP URI parameters are set as described below.

  The value of the pn-provider URI parameter is "apns".

  Example: pn-provider = apns

Spaces are not allowed in URIs unencoded, so your example is misleading. I suggest you change it to "pn-provider=apns" (i.e. delete space before and after "=").

Similar comment about 2 other parameter examples defined in this section.


10.  pn-provider, pn-param and pn-prid URI Parameters for Apple Push
    Notification service

  The value of the pn-param URI parameter is a string that is composed
  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.

I assume it doesn't contain any periods?

  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".

How many periods are used in the value? If your example below is correct, can you clarify that Bundle ID itself contains periods?

  Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp.voip

[Ballot comment]
I am agreeing with Adam's DISCUSS.

In 8.2:

    pns-list        = pns *(COMMA pns)

My understanding is that COMMA (defined in RFC 3261) allows folding whitespace, in particular CRLF. Do you really want this in values? It is Ok if you do, I just wanted to double check.

8.7.  SIP URI Parameters

    COLON =

COLON is not used in this section or anywhere else in the document.

14.4.1.  sip.pnsreg

      Security considerations: This media feature tag does not introduce
        new security considerations, as it simply indicates support for
        a basic SIP feature. If an attacker manages to remove the media
        feature tag, push notifications towards the client will be

Is "not" missing before "be"?

        requested.

[Ballot discuss]
Thanks to everyone who is put work into defining this mechanism. I think it will
be very useful to have a solution for integrating push mechanisms into SIP
networks. I've identified three issues that I think need to be addressed in the
current document before it can move forward, and a fourth serious flaw that I
call out in my comments below.

---------------------------------------------------------------------------

It's nice that this document has considered the impact of inbound mid-dialog
messages in long-lived dialogs. However, it appears to have a major hole in it:
handing of outbound messages for the purpose of maintaining soft-state in those
dialogs isn't handled correctly.

In particular: networks that deploy this mechanism will cause SUBSCRIBE
dialogs to time out and be destroyed while they are still in use.
Additionally, if RFC 4028 (session timers) is negotiated, then INVITE dialogs
will suffer the same fate.

I can think of a couple of ways for these situations to be handled, but they
need explicit text in the document.

One approach would be to specify that the User Agent selects its requested
"Expires" value in its registration to be the smallest value before its set of
subscriptions and session timers needs to be refreshed. This would cause a push
notification to happen to prevent registration timeout, and the client could
refresh the other soft state at that time. Complications arise if the registrar
responds with a 483 (Interval too Brief), and we'd need to find a solution for
that.

Another approach would be for the clients to refresh all soft state whenever
they send a registration, and set the timeout for that soft state to be equal to
or greater than the registration timeout. A complication could arise if the
notifier or the peer in an invite dialog shortens the requested time, and we'd
need to find a solution for that.

A third approach would be getting the proxy involved in some way -- either by
requiring it to observe subscription and session timer timeouts and requiring it
to send push notifications prior to their expiration, or by an explicit
communication between the UA and the proxy that indicates when the next push
notification should be scheduled. If the latter approach is taken, I would
suggest that it needs to be taken for REGISTER messages as well.

I really don't think this mechanism is feasibly deployable without a solution to
this problem.

---------------------------------------------------------------------------

§4.1:

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

This seems to ignore the availability of Contact URI parameters via RFC 3680
subscriptions. This would seem to impose a requirement on Registrars to strip
this information before making it available to any other party (which, in
turn, requires that the system have explicit Registrar *and* Proxy support).
As far as I can tell, the system so far has not required explicit proxy support
(and there's certainly no mechanism built-in that ensures that a proxy has any
special handling regarding this mechanism).

If the PNS information is sensitive, and cannot be allowed to leak out to
other users, then we need some way to ensure the registrar has provided
positive confirmation that it will not do so before allowing it to come into
possession of them.

---------------------------------------------------------------------------

§4.2:

>  The UA can do so by only including the pn-provider
>  SIP URI parameter in the SIP Contact header field URI of the REGISTER
>  request, but without including the pn-prid SIP URI parameter.

Unless I'm mistaken, this is a barrier to interoperation.

It's not 100% clear, but I suspect the intended implication is that the
pn-provider parameter here will contain a single value? The syntax of the
parameter certainly seems to imply that. This seems to be a pretty big
problem, since it presupposes that the client will know which PNSes the Proxy
supports.  Consider, for example, an iOS client that can use any of RFC 8030,
FCM, and APN (cf https://firebase.google.com/docs/cloud-messaging/ios/client).
If the client doesn't know a priori what the proxy supports (and this entire
section only makes sense if that's true), then it won't know which of those
three services to indicate in its REGISTER request. If it guesses wrong, this
mechanism simply fails.

I think you need a different discovery mechanism here -- either have one that
has the client offering multiple PNS protocols and the proxy responding with
one, or have one in which the proxy indicates all of its supported services in
a response, and the client chooses one to use in its next REGISTER message.

[Ballot discuss]
Thanks to everyone who is put work into defining this mechanism. I think it will
be very useful to have a solution for integrating push mechanisms into SIP
networks. I've identified three issues that I think need to be addressed in the
current document before it can move forward, and a fourth serious flaw that I
call out in my comments below.

---------------------------------------------------------------------------

It's nice that this document has considered the impact of inbound mid-dialog
messages in long-lived dialogs. However, it appears to have a major hole in it:
handing of outbound messages for the purpose of maintaining soft-state in those
dialogs isn't handled correctly.

In particular: networks that deploy this mechanism will cause SUBSCRIBE
dialogs to time out and be destroyed while they are a still in use.
Additionally, if RFC 4028 (session timers) is negotiated, then INVITE dialogs
will suffer the same fate.

I can think of a couple of ways for these situations to be handled, but they
need explicit text in the document.

One approach would be to specify that the User Agent selects its requested
"Expires" value in its registration to be the smallest value before its set of
subscriptions and session timers needs to be refreshed. This would cause a push
notification to happen to prevent registration timeout, and the client could
refresh the other soft state at that time. Complications arise if the registrar
responds with a 483 (Interval too Brief), and we'd need to find a solution for
that.

Another approach would be for the clients to refresh all soft state whenever
they send a registration, and set the timeout for that soft state to be equal to
or greater than the registration timeout. A complication could arise if the
notifier or the peer in an invite dialog shortens the requested time, and we'd
need to find a solution for that.

A third approach would be getting the proxy involved in some way -- either by
requiring it to observe subscription and session timer timeouts and requiring it
to send push notifications prior to their expiration, or by an explicit
communication between the UA and the proxy that indicates when the next push
notification should be scheduled. If the latter approach is taken, I would
suggest that it needs to be taken for REGISTER messages as well.

I really don't think this mechanism is feasibly deployable without a solution to
this problem.

---------------------------------------------------------------------------

§4.1:

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

This seems to ignore the availability of Contact URI parameters via RFC 3680
subscriptions. This would seem to impose a requirement on Registrars to strip
this information before making it available to any other party (which, in
turn, requires that the system have explicit Registrar *and* Proxy support).
As far as I can tell, the system so far has not required explicit proxy support
(and there's certainly no mechanism built-in that ensures that a proxy has any
special handling regarding this mechanism).

If the PNS information is sensitive, and cannot be allowed to leak out to
other users, then we need some way to ensure the registrar has provided
positive confirmation that it will not do so before allowing it to come into
possession of them.

---------------------------------------------------------------------------

§4.2:

>  The UA can do so by only including the pn-provider
>  SIP URI parameter in the SIP Contact header field URI of the REGISTER
>  request, but without including the pn-prid SIP URI parameter.

Unless I'm mistaken, this is a barrier to interoperation.

It's not 100% clear, but I suspect the intended implication is that the
pn-provider parameter here will contain a single value? The syntax of the
parameter certainly seems to imply that. This seems to be a pretty big
problem, since it presupposes that the client will know which PNSes the Proxy
supports.  Consider, for example, an iOS client that can use any of RFC 8030,
FCM, and APN (cf https://firebase.google.com/docs/cloud-messaging/ios/client).
If the client doesn't know a priori what the proxy supports (and this entire
section only makes sense if that's true), then it won't know which of those
three services to indicate in its REGISTER request. If it guesses wrong, this
mechanism simply fails.

I think you need a different discovery mechanism here -- either have one that
has the client offering multiple PNS protocols and the proxy responding with
one, or have one in which the proxy indicates all of its supported services in
a response, and the client chooses one to use in its next REGISTER message.

[Ballot comment]
Figure 1:

This diagram includes both a ladder diagram and an example REGISTER message.
While both of these are useful at this point in the document, neither of them is
an "Architecture," and they're really two different things. I suggest breaking
this into two Figures, entitled "Typical Information Flow" and "Example REGISTER
Message" (or similar), respectively.

---------------------------------------------------------------------------

§4.1:

>  As long as the UA wants to receive push notifications (requested by
>  the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param
>  (if required for the specific PNS provider) SIP URI parameter in each
>  binding-refresh REGISTER request.

Please be clear that these parameters appear in the Contact URI.

---------------------------------------------------------------------------

§5.2:

>  In order to request push notifications towards a SIP UA that will
>  trigger the UA to send binding-refresh SIP REGISTER requests, the SIP
>  proxy needs to have information about when a registration will
>  expire.  The proxy needs to be able to retrieve the information from
>  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].

Nit: "SIP registration"

This mechanism seems to be predicated on an architecture in which the proxy must
be on the traffic path. Although it's problematic from a "what proxies are
expected to do" perspective, it seems like the proxy could glean this
information from the 200 response to the REGISTER request. (I mean, the proxy is
already reading parameters out of the contact header field, so the behavior of
acting on registration information is already assumed). The proxy would, of
course, need to run its own timers, but that seems to be a pretty minor
requirement, given everything else involved here.

---------------------------------------------------------------------------

§5.3.1:

This is a major comment, and one that has a sufficient impact on interop that I
had a long debate with myself about whether it should be a DISCUSS. Please take
it very seriously.

>  Otherwise, if the pn-provider SIP URI parameter identifies a type of
>  PNS that the proxy does not support, or if the REGISTER request does
>  not contain all additional information required for the specific type
>  of PNS, the proxy MUST either forward the request (e.g., if the proxy
>  knows that another proxy that will receive the REGISTER request
>  supports the type of PNS)...

How would the proxy know this?

Features like suppressing PNS behavior when a "sip.pns" feature capability is
present in the REGISTER imply that the various nodes in the network discover
capabilities of their neighbors automatically (which is consistent with the way
SIP does features), while this provision seems to require provisioned knowledge.
This is going to be operationally very confusing.

At the very least, the document needs to call out how this "knowledge" is
obtained. In the more general sense, since a client cannot rely on the proxy
supporting *any* kind of PNS, the use of 555 in the way specified here is at
best an optimization -- and, since the configured information can conflict with
actual reality, it's an optimization that can actually break things unless
extreme care is exercised. (e.g., if the proxy is configured to "know" that the
next proxy cannot provide push service, but this knowledge is wrong, then the
network is unnecessarily broken.)

My rather strong recommendation is to remove this code, and let the client rely
on the lack of indication of support in the response indicate that the feature
is not supported.

---------------------------------------------------------------------------

§5.3.1:

>  o  if the proxy received a 'sip.pnsreg' media feature tag in the
>    REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature-
>    capability indicator with an indicator value bigger than 120 in
>    the response, unless the proxy always want to request push

Nit: "...wants..."

---------------------------------------------------------------------------

§5.3.2:

>  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 seems to be a very strong requirement ("MUST") when, e.g., many or most
networks may want to return a 480 instead of a 404. I think what you want to say
is something like "...MUST reject the SIP request. Response codes of either
404 (Not Found) or 480 (Temporarily Unavailable) are RECOMMENDED, but other
appropriate codes may be used as well."

---------------------------------------------------------------------------

§5.3.2:

>  The reason the proxy needs to wait for the REGISTER response before
>  forwarding the SIP request is to make sure that the REGISTER request
>  has been accepted by the registrar, and that the UA which initiated

Nit: "...the UA that initiated..."

---------------------------------------------------------------------------

§5.3.2:

>  In case of non-2xx response to the REGISTER request, the proxy MUST
>  reject the SIP request with a 404 (Not Found) response.
>
>  If the push notification request fails (see PNS-specific
>  documentation for details), the proxy MUST reject the SIP request
>  with a 480 (Temporarily Unavailable) response.
>
>  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.

As above, this seems way too restrictive in terms of mandating specific error
codes. It may well be the case that a network would want to treat these
situations identically from the perspective of the calling party.

---------------------------------------------------------------------------

§5.3.2:

>  Otherwise the
>  proxy MUST reject the SIP request with a 480 (Temporarily
>  Unavailable) response.

Same comment as above.

---------------------------------------------------------------------------

§6.1.1:

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

Nit: "...sends an initial request..."

>  purr' SIP URI parameter in the Contact header of the request or

Nit: "...Contact header field..."

>  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

Nit: "...given dialog..."

>  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

Nit: "...Contact header field..."

---------------------------------------------------------------------------

§6.1.1:

>  The UA MUST include a parameter value identical to the the
>  last 'sip.pnspurr' feature-capability indicator that it received in a
>  REGISTER response.

This is incredibly confusing, as the "sip.pnspurr" indicator has not been
mentioned in the document so far. Please revise as something along the lines of:

>  The UA MUST include a parameter value identical to the the last
>  'sip.pnspurr' feature-capability indicator (see Section 6.2.1) that it
>  received in a REGISTER response.

Alternately, reverse the order of sections 6.1 and 6.2 so that the PURR
concept is properly introduced before protocol procedures are defined for it.

---------------------------------------------------------------------------


§6.1.1:

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

Similar to the above, this is a very confusing introduction of the "pn-purr" URI
parameter.

---------------------------------------------------------------------------

§6.2.2:

>  Contact header field with a PURR value that the proxy has generated
>  Section 6.2.2, the proxy MUST add a Record-Route header to the
>  request, to insert itself in the dialog route [RFC3261].

This "Section 6.2.2" makes the sentence impossible to read. Is it intended to be
in parentheses?

---------------------------------------------------------------------------

§6.2.3:

>  As described in Section 5.3.2, while waiting for the push
>  notification request to succeed, and the associated REGISTER request
>  to arrive from the SIP UA, the proxy needs to take into consideration
>  that the transaction associated with the NOTIFY request will
>  eventually time out at the sender of the request (UAC), and the
>  sender will consider the transaction a failure.

I think this needs some discussion about the impact of the error codes selected
by the proxy on the dialog and its usages. For example:

* If the proxy sends a 404 to prevent a transaction timeout, it will destroy the
  dialog and all of its usages

* If the proxy sends a 480 to prevent a transaction timeout, it will destroy the
  usage, but not other usages in the dialog (if any)

* If the proxy sends a 504 to prevent a transaction timeout, it will keep the
  dialog and the usage alive, and allow the client to re-try at a later time.
  Simply allowing the transaction to time out will have the same effect, albeit
  with more message retransmissions.

Pointing to RFC 5057 might be useful here.

---------------------------------------------------------------------------

§8.7:

>    Parameter value characters that are not part of pvalue needs to be
>    escaped, as defined in RFC 3261.

Nit: "...need to be escaped..."

---------------------------------------------------------------------------

§9:

>  When a new value is registered to the PNS Sub-registry, a reference
>  to a specification which describes the usage of the PNS associated

Nit: "...specification that describes..."

---------------------------------------------------------------------------

§§10-12:

Nit: It seems like these should all be subsections of section 9.

---------------------------------------------------------------------------

§10:

>  The Topic consists of the Bundle ID, which uniquelly identifies an
>  appliciation, and a service value that identifies a service

Nit: "uniquely"
Nit: "application"

---------------------------------------------------------------------------

§10:

>  Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp.voip

Please use an RFC 2026 domain for this example; e.g.:

>  Example: pn-param = DEF123GHIJ.com.example.yourexampleapp.voip

---------------------------------------------------------------------------

§11:

>  [RFC8292] defines a mechanism which allows a proxy to identity itself

Nit: "...mechanism that allows..."

[Ballot 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 a@example.com and b@example.com both register with the
same proxy/registrar pair with PRIDa and PRIDb respectively. What
stops the registrar from generating (or forwarding) a call to
a@example.com, 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?

[Ballot 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?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-sipcore-sip-push-21. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the SIP/SIPS URI Parameters registry on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

four, new registrations are to be made as follows:

Parameter Name: pn-provider
Predefined Values: No
Reference: [ RFC-to-be ]

Parameter Name: pn-param
Predefined Values: No
Reference: [ RFC-to-be ]

Parameter Name: pn-prid
Predefined Values: No
Reference: [ RFC-to-be ]

Parameter Name: pn-purr
Predefined Values: No
Reference: [ RFC-to-be ]

Second, in the Response Codes registry also on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a single, new registration is to be made as follows:

Response Code: 555
Description: Push Notification Service Not Supported
Reference: [ RFC-to-be ]

Third, in the Global Feature-Capability Indicator Registration Tree registry also on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

four, new registrations are to be made as follows:

Name: sip.pns
Description: This feature-capability indicator, when included in a Feature-Caps header field of a SIP REGISTER request or a SIP 2xx response to a REGISTER request, indicates that the entity associated with the indicator supports, and will use, the SIP push mechanism and the push notification service identified by the indicator value. When included in a 555 (Push Notification Service Not Supported) response to a REGISTER request, the indicator indicates that the entity associated with the indicator supports the SIP push mechanism, and the push notification service(s) identified by the indicator value.
Reference: [ RFC-to-be ]

Name: sip.vapid
Description: This feature-capability indicator, when included in a SIP 2xx response to a SIP REGISTER request, indicates that the entity associated with the indicator supports, and will use, the Voluntary Application Server Identification (VAPID) mechanism when requesting push notifications towards the SIP UA associated with the SIP registration. The indicator value is a public key identifying the entity, that can be used by a SIP UA to restrict subscriptions to that entity.
Reference: [ RFC-to-be ]

Name: sip.pnsreg
Description: This feature-capability indicator, when included in a SIP 2xx response to a SIP REGISTER request, indicates that the entity associated with the indicator expects to receive binding-refresh REGISTER requests from the SIP UA associated
with the registration before the registration expires, without the entity having to request push notifications towards the SIP UA in order to trigger the REGISTER requests. The indicator value is the minimum value (given in seconds) before the registration expireation when the entity expects to receive the REGISTER request.
Reference: [ RFC-to-be ]

Name: sip.pnspurr
Description: This feature-capability indicator, when included in a SIP 2xx response to a SIP REGISTER request, indicates that the entity associated with the indicator will store information that can be used to associate a mid-dialog SIP request with the binding information in the REGISTER request. The indicator value is an identifier that can be used a key to retrieve the binding information.
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the iso.org.dod.internet.features.sip-tree (1.3.6.1.8.4) registry on the Media Feature Tags - iso.org.dod.internet.features (1.3.6.1.8) registry page located at:

https://www.iana.org/assignments/media-feature-tags/

a single, new registration is to be made as follows:

Decimal: [ TBD-at-Registration ]
Name: sip.pnsreg
Description: This media feature tag, when included in the SIP Contact header field of a SIP REGISTER request, indicates that the SIP UA associated with the tag is able to send binding-refresh REGISTER requests associated with the registration without being awaken by push notifications.
Reference: [ RFC-to-be ]

Fifth, a new registry is to be created called the PNS registry. The new registry will be on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

The new registry will be managed using Specification Required as defined in RFC 8126. There are initial registrations in the new registry as follows:

Value Description Reference
-------------+---------------------------------------+--------------
apns Apple Push Notification service [ RFC-to-be ]
fcm Firebase Cloud Messaging [ RFC-to-be ]
webpush Generic Event Delivery Using HTTP Push [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-12-21):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, sipcore-chairs@ietf.org, sipcore@ietf.org, br@brianrosen.net, Brian Rosen , draft-ietf-sipcore-sip-push@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Push Notification with the Session Initiation Protocol (SIP)) to Proposed Standard


The IESG has received a request from the Session Initiation Protocol Core WG
(sipcore) to consider the following document: - 'Push Notification with the
Session Initiation Protocol (SIP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-12-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes how a Push Notification Service (PNS) can be
  used to wake suspended Session Initiation Protocol (SIP) User Agents
  (UAs), using push notifications, for the UA to be able to send
  binding-refresh REGISTER requests and to receive receive incoming SIP
  requests.  The document defines new SIP URI parameters and new
  feature-capability indicators that can be used in SIP messages to
  indicate support of the mechanism defined in this document, to
  exchange PNS information between the SIP User Agent (UA) and the SIP
  entity that will request push notifications towards the UA, and to
  trigger such push notification requests.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my AD Evaluation of draft-ietf-sipcore-sip-push-20. I reviewed a previous version, but since there have been substantial changes since that version, I treated this as a “from scratch” review.

This version is in much better shape than the previous. I think it’s almost ready for IETF LC, but I want to resolve at least the substantive comments first.

*** Substantive Comments ***

§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.

§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.

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

§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 for 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?

-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.)

-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?

- 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.)

-- "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".

§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.

-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?

§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.

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?

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

§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?

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

§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?

§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?

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


*** Editorial Comments ***

- All instances of "binding refresh REGISTER" should be "binding-refresh REGISTER". (This is true anywhere binding-refresh is used as an adjective.)

- There is still a lot of incorrect comma usage, especially commas where they don't belong. I will call out the ones I noticed.

- The phrases "request for a new dialog" and  "standalone
SIP request" are used heavily and repeatedly, often in combination. The common terminology has historically been "dialog-initiating request" and "out-of-dialog request". These are, at least in combination, a bit shorter.

§1
- paragraph 5: Missing word in "awaken other means". I suggest "awakened by other means".
- Paragraph 6: "... SIP request for a new dialog, or a standalone
SIP request, addressed towards a UA...": Both commas should be removed.

- Figure 1: The "SIP 200 Okay" label is separated from the line it labels by a page break. (Other text changes may change the pagination, so this is probably one for the RFC editor if it's still an issue in the final version.)

§4.1, 7th paragraph ("Note"): The first sentence seems odd in the context of the previous paragraph, which talked extensively about UAs using non-push mechanisms.

§4.2,
- first paragraph:

-- first sentence: s/"network"/"SIP Network".
-- "... UA has received a response to the REGISTER request, with the
push notification information ...": improper comma.

- 3rd paragraph, "... early enough, in order for...": I suggest "... early enough for..."

§5.3.1
- 1st paragraph, "... towards the UA associated with the
REGISTER request, or perform any other procedures...": improper comma.

- 5th paragraph:
-- "... proxy that is not between the push proxy and the UA...". Doesn't this really mean a proxy that is between the push proxy and the registrar? If so, saying where the proxy _is_ would be clearer than saying where it is _not_.

-- "... (if the Contact header field URI of the REGISTER request
contains a pn-prid SIP URI parameter) ..." Could we have gotten this far if that were not true? The sentence would be easier to read without it. (I think this repeats a few times.)

- 6th paragraph: "MUST only" constructions can be ambiguous. It is better to state them in terms of "MUST NOT unless..."

- 2nd to last paragraph, "The proxy MUST be able..." It would be better to state this in terms of what the proxy _does_, not what it is _able_ to do. For example, "... MUST NOT ... unless it has determined that the PNS supports the VAPID mechanism."

§5.3.2
-  3rd paragraph: "This can happen if the
UA sends a binding refresh REGISTER request with a new contact...": This seems to ignore the potential of multiple contacts. I think the real condition is when the previous binding is _removed_.

-6th paragraph: I don't understand the meaning of this paragraph. (Also, both commas are incorrect.)

-11th paragraph: s/"losing race that results"/ "losing the race, which results"  ; or "... a race..."

§6.2.3: Parts of this section seem specific to SIP-Events dialogs. I assume that's not the intent?

1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Proposed Standard.  This document describes new SIP protocol mechanisms and thus is properly Standards Track.  Standards Track is indicated in the document header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
  This document describes how a Push Notification Service (PNS) can be
  used to wake suspended Session Initiation Protocol (SIP) User Agents
  (UAs), using push notifications, for the UA to be able to send
  binding refresh REGISTER requests and to receive receive incoming SIP
  requests.  The document defines new SIP URI parameters and new
  feature-capability indicators that can be used in SIP messages to
  indicate support of the mechanism defined in this document, to
  exchange PNS information between the SIP User Agent (UA) and the SIP
  entity that will request push notifications towards the UA, and to
  trigger such push notification requests.
Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
This document has had extensive discussion and review by a significant number of sip experts.  The mechanism has been revised several times in response to substantive comments.  There was controversy on the wisdom of providing mechanisms for proprietary push notification protocols to use, but the work group has a solid rough consensus that this document solves a real problem in an appropriate way and does not favor any proprietary push notification system over a standard one (RFC8030)

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
There are many reports of implementations of proprietary solutions to the problem this document addresses, and discussion indicates this mechanism will replace those mechanisms in many cases.  We expect quite a few implementations, but there have not been reports of actual implementations at this time.  Many sipcore "regulars" have reviewed drafts of this document and made substantive comments which has resulted in many versions of the document. All comments have been addressed. 

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Brian Rosen is the Document Shepherd, Ben Campbell is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has reviewed the current version of the document as well as several (but not all) of the many versions.  The shepherd believes the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
There have been many detailed reviews of this document with many substantive comments, all of which have been addressed.  Two WGLCs have been held because of the extend of changes made subsequent to the first WGLC.  Commenters have been satisfied that their comments have been taken into account.  One commenter is still unhappy with some of the mechanism but no other members have voiced support for his point of view.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No special reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
The shepherd and chairs believe this document has decent consensus.  There have been NO negative voices, not even a "do we have to do this?" negative.  It is yet one more piece of ISUP that apparently needs a SIP transport to adequately handle calls originating from legacy systems. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
No nits are present

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
None needed

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
None

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
This document will not change the status of any existing RFCs

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
This document has many simple IANA requests.  Each is well documented and the shepherd is confident IANA will have no problems understanding what is needed.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No expert reviewers are needed

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
The document contains a few lines of ABNF which have been reviewed.

1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Proposed Standard.  This document describes new SIP protocol mechanisms and thus is properly Standards Track.  Standards Track is indicated in the document header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
  This document describes how a Push Notification Service (PNS) can be
  used to wake suspended Session Initiation Protocol (SIP) User Agents
  (UAs), using push notifications, for the UA to be able to send
  binding refresh REGISTER requests and to receive receive incoming SIP
  requests.  The document defines new SIP URI parameters and new
  feature-capability indicators that can be used in SIP messages to
  indicate support of the mechanism defined in this document, to
  exchange PNS information between the SIP User Agent (UA) and the SIP
  entity that will request push notifications towards the UA, and to
  trigger such push notification requests.
Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
This document has had extensive discussion and review by a significant number of sip experts.  The mechanism has been revised several times in response to substantive comments.  There was controversy on the wisdom of providing mechanisms for proprietary push notification protocols to use, but the work group has a solid rough consensus that this document solves a real problem in an appropriate way and does not favor any proprietary push notification system over a standard one (RFC8030)

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
There are many reports of implementations of proprietary solutions to the problem this document addresses, and discussion indicates this mechanism will replace those mechanisms in many cases.  We expect quite a few implementations, but there have not been reports of actual implementations at this time.  Many sipcore "regulars" have reviewed drafts of this document and made substantive comments which has resulted in many versions of the document. All comments have been addressed. 

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Brian Rosen is the Document Shepherd, Ben Campbell is the Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has reviewed the current version of the document as well as several (but not all) of the many versions.  The shepherd believes the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
There have been many detailed reviews of this document with many substantive comments, all of which have been addressed.  Two WGLCs have been held because of the extend of changes made subsequent to the first WGLC.  Commenters have been satisfied that their comments have been taken into account.  One commenter is still unhappy with some of the mechanism but no other members have voiced support for his point of view.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
No special reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
The shepherd and chairs believe this document has decent consensus.  There have been NO negative voices, not even a "do we have to do this?" negative.  It is yet one more piece of ISUP that apparently needs a SIP transport to adequately handle calls originating from legacy systems. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
No nits are present

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
None needed

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
None

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
This document will not change the status of any existing RFCs

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
This document has many simple IANA requests.  Each is well documented and the shepherd is confident IANA will have no problems understanding what is needed.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No expert reviewers are needed

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
The document contains a few lines of ABNF which have been reviewed.

This is my AD evaluation of  draft-ietf-sipcore-sip-push-11.

In summary, I don’t think this draft is ready for IETF last call. There are significant issues that I think need further attention from the working group before this can progress. I am returning the draft to the working group, and will change the state to “AD is Watching”.

Major Issues:

1. The mechanism makes SIP transactions pend for an indeterminate period of time while the push notification is processed, the recipient wakes up and sends a REGISTER request, and the registrar processes that request. This is a problem for non-INVITE transactions, and is not optimal for any transaction. (The issues with doing this to a non-INVITE transaction are best described in RFC 4321.)

At least for the non-INVITE case, has the working group considered a model where the transaction completes and the UAC resends it at some point in the future? (For example, a 4XX response with retry-after)

2. The architectural assumptions are unclear. In particular, the role of the proxy in the SIP network is unclear. In some parts of the draft, it appears the proxy must be co-located with the registrar, but others talk about a proxy that is on the path between the UA and the registrar. Along the same lines, the draft needs to clarify assumptions  about proxy’s role for inbound SIP requests. (For example, the R-URI in an inbound request may or may not match the registered contact depending on whether the request has been retargeted—the R-URI could be an AoR rather than a registered contact.)

3. The mechanism seems to assume a single contact binding exists at any one time, and that any given REGISTER request relates to that binding. How is this expected to work if multiple bindings exist at the same time, perhaps with different expiration times? What if the user has multiple clients that are creating bindings, some supporting this mechanism and others not supporting it?


Other Substantive Comments:

§1
-  Does this draft claim compatibility with APNS and FCM? Can you offer citations for those?

- " When the proxy receives (or, if the proxy is the SIP registrar[RFC3261], initiates) a SIP request for a new dialog”
I don’t understand the intent here; registrars do not normally initiate SIP requests for new dialogs.

“Different PNSs exist today.  Some are based on the standardized mechanism defined in [ RFC8030 ], while others are proprietary (e.g., the Apple Push Notification service).”

Is there an assumption that they are all similar enough that this mechanism can work with all of them? If so, please say that explicitly.

§2: Please use the new boilerplate from RFC 8174.

§4.1:
- Please cite RFC 6809 on the first mention of feature-caps.

- Please elaborate on the practical effect of supporting VAPID.

- " If the REGISTER response does not contain a a ’sip.pnsreg’ feature- 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).”

Why? That’s normal SIP behavior for UAs that do not support this mechanism, so the registrar must be able to handle it. (If there’s a good reason, please explain it in the draft.)

- “ NOTE: If the SIP UA application wants to use push notifications for
  other purposes than to trigger re-registration 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."

I can see keeping how you distinguish between SIP related notifications and other kinds of notifications. But what if the UA uses more than one SIP services that supports push notifications?

§5.2: “ It is RECOMMENDED that the proxy requests the push notification at least 120 seconds before the registration expires.” - We usually recommend refreshing bindings at when half of the expiration time has passed. Is there a reason to do this differently? If so, why 120 seconds in particular; has there been analysis of push notification latency?

§5.3.1:
-  “ If the proxy considers the requested registration expiration interval
  [RFC3261] to be too short, the proxy MUST either send a 423 (Interval
  Too Brief) response to the REGISTER request, or skip the rest of the
  procedures in this section and process the REGISTER request using
  normal SIP procedures. "

That _is_ normal SIP procedure. What do you mean to be different?

- " if the proxy received a ’sip.pnsreg’ media feature tag in theREGISTER request, the proxy SHOULD include a ’sip.pnsreg’ feature-capability indicator with an indicator value bigger than 120 inthe response, unless the proxy always want to request push notifications to trigger the UA to send a REGISTER request.”

It’s not clear to me why the proxy should be able to override the UAs choice.

§5.3.2:
-"When the proxy receives (or, in case the proxy is the registrar, creates) a SIP request for a new dialog…”
Why would a registrar create a SIP request for a new dialog?

- “ If the contact of the most recent REGISTER
  2xx response and Request-URI do not match, the proxy MUST reject the
  SIP request with a 404 (Not Found) response.  This can happen if the
  UA sends a re-registration REGISTER request with a new contact at the
  same time the registrar forwards a SIP request towards a UA using the
  previously registered contact in the Request-URI.”

Why doesn’t the proxy forward using normal SIP procedures? It’s entirely possible that an UAS address changes during an inbound transaction in normal SIP. Why is that different with push notifications? (this section seems to replace normal SIP request routing. That shouldn’t happen without a really good reason. If normal SIP procedures are inadequate, please explain why.

§6.2: Why does the UAC need to know the failure was due to push notification? What would it do differently than for other kinds of failures? (This seems like a privacy leak; does the recipient want the sender to know he or she is on a mobile
device?)

§11: “ If the push notification related information carried in SIP could be
  used by a malicious middleman to trigger push notifications towards a
  device, operators MUST ensure that the SIP signalling is properly
  secured from malicious middlemen, e.g., using encryption.”

This could use some elaboration. I think the sense of this is backwards. That is, the signaling MUST be secured unless there are factors that make it impossible for an active attacker to use the informaiton.

§12.5: The template contains a “document” field, but the registration policy is “expert review”. Should this be “specification required”?


Editorial Comments:

- General:
— The draft has some readability issues. In particular, it pervasively uses long, convoluted sentences, lots of imbedded parenthetical phrases, improper comma placement, etc.
— The draft pervasively mixes registration procedures with the handling of inbound SIP requests. Please consider separating those into different sections. I realize there are interdependencies, but it’s hard to follow as is.

- Abstract: s/awake/wake ; (or awaken)  (“awake” is not a verb. This repeats elsewhere in the draft. .)

§1,
- first paragraph:
-- Saying push notification is the only way to solve these issues seems overstated. It’s one way; there might be others.
-- when you talk about “each operating” system, you are talking about popular mobile operating system vendors, right? The assertion seems less true for operating systems in general.
- 4th paragraph: The usual term for re-registration is “binding refresh”.
-4th paragraph: “battery life etc”? What else?

- figure 1: The page break is unfortunate; can the ladder diagram be kept all on the same page?

§5.1, heading: Should “PNS Identifier” be “PNS Provider” (since that is what the section talks about.)

§5.2:
- “...the SIP proxy MUST have information” - the MUST seems like a statement of fact, not a normative requirements.
- “ If the proxy receives information that a registration has expired,…” - Bindings expire, not registrations. (Much of the draft uses the word “registration” when the common term is “binding"

§5.3, heading: s/Request/Requests

§5.3.1: “ If the proxy sends a SIP 555 (Push Notification Service Not Supported) response”
It would be helpful to describe 555 before this.

§5.3.2: “ The proxy MUST NOT include the SIP request as payload in the
  requested push message.”
Wasn’t there already text forbidding payloads in general?

§6.7: "  Parameter value chapters that are not part of pvalue needs to be escaped, as defined in RFC 3261.”

What is a parameter value chapter? Should “chapters” be “characters”?

§7: This information belongs in the IANA considerations section.

§11: “ [RFC8292] defines a mechanism which allows a proxy to create a
  identity itself to a PNS, by signing a JWT sent to the PNS using a
  key pair."
I can’t parse the first clause. Are there missing words?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Proposed Standard, which is indicated in the header. This
  draft defines a new mechanism in sip.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes how a Push Notification Service (PNS) can be
  used to awake suspended Session Initiation Protocol (SIP) User Agents
  (UAs), using push notifications, for the UA to be able to send re-
  registration REGISTER requests and to receive receive incoming SIP
  requests.  The document defines new SIP URI parameters and new
  feature-capability indicators that can be used in SIP messages to
  indicate support of the mechanism defined in this document, to
  exchange PNS information between the SIP User Agent (UA) and the SIP
  entity that will request push notifications towards the UA, and to
  trigger such push notification requests.


Working Group Summary

  The document solves an existing problem of waking up a client when
  the underlying platform only supports some form of push notification. 
  Typically, this issue arises in a smart phone app, or similar battery
  operated device, where the platform only supports a push notification
  mechanism for wake-up.  Several proprietary implementations have
  been noted, and the work group desired a standardized mechanism

Document Quality

  This short document received detailed review from a several 
  of working group participants. The authors incorporated received
  feedback. One commenter wanted an open standard push mechanism,
  despite the actual problem being primarily proprietary push. 
  The authors attempted to satisfy the lone commenter but
  did not totally satisfy his request.

  The mechanism is quite simple and several implementations are
  planned.


Personnel

  Brian Rosen is the document shepherd. Ben Campbell is the
  responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The shepherd thoroughly reviewed the last versions of the draft.
  The document is ready to be forwarded to the IESG. 


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document requires no specialized expertise beyond that
  possessed by regular participants in the SIPCORE working group.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Each author has confirmed conformance with BCPs 78 and 79.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No disclosure has been filed.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  There was a great deal of discussion on this relatively simple draft.
  All comments were resolved to the commenter’s satisfaction except one.
  Martin Thomson is still not satisfied.  He raised a series of comments,
  most of which were dealt with satisfactorily.  He had one remaining
  comment on the text that deals with getting text notifications when
  the UA is able to maintain registrations.  He did not propose a change
  and was slow in responding to the author.  The chairs judge that we
  have rough consensus to move the document forward now. 


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  idnits 2.14.01 was run, the only nits noted are XXXX references
  to the documents eventual RFC number in IANA actions.
  The Shepherd checked the draft against
  http://www.ietf.org/id-info/checklist.html.
  No issues were found with the draft.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review requirements are triggered by this document,
  aside from any required by IANA process.


(13) Have all references within this document been identified as
either normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The IANA Considerations section adds new SIP URI parameters.  The
  registry is clearly and correctly identified and the new parameters
  are completely and correctly defined.  It adds two SIP Response
  codes.  The registry is clearly and correctly identified, and the
  new response codes are completely and correctly defined.  It adds
  new feature-capability indicators.  The registry is clearly and
  correctly identified and the new indicators are completely and
  correctly defined.  Finally, the document defines a new sub-
  Registry in sip-parameters.  The registry definition has a complete
  Description of initial values, the management mechanism is
  appropriate and well specified, and the registry has a reasonable
  name.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  This document adds a new sub registry in sip-parameters,
  Pn-provider, which requires Expert Review for future allocations.
  The registry lists push providers, so the expert should be generally
  aware of operating systems and environments for battery operated
  sip devices that may provide push services to be used by this
  mechanism.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The shepherd carefully checked the ABNF, which makes extensive
  use of productions found in RFC3261 and other RFCs and would be
  hard to check with available tools.