[sipcore] Mirja Kühlewind's No Objection on draft-ietf-sipcore-sip-push-21: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-sipcore-sip-push-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/



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