Subject: [dispatch] draft-allen-dispatch-poc-instanceid-usage-02

From: "Monnes, Peter" <[email-masked]>
Date: Wed, 22 Apr 2015 17:22:37 +0000

I've reviewed and support the publication of the Internet draft: "Session Initiation Protocol (SIP) Instance ID usage by the Open Mobile Alliance Push-to-talk over Cellular draft-allen-dispatch-poc-instanceid-usage-02".

This draft is important for the completion of 3GPP Mission Critical Push to Talk work and so progressing this draft is a priority.

Peter Monnes
Harris  Corporation

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 23 Apr 2015 22:32:00 -0400

"Monnes, Peter" <[email-masked]> writes:
> I've reviewed and support the publication of the Internet draft:
> "Session Initiation Protocol (SIP) Instance ID usage by the Open
> Mobile Alliance Push-to-talk over Cellular
> draft-allen-dispatch-poc-instanceid-usage-02".

The issues this draft addresses should be resolved.  (I haven't studied
the issues enough myself to know if this draft covers them properly, but
it appears to do so to the extent of my knowledge.)

The draft could use some editing.  In particular, section 2 references a
things that should be properly footnoted.  For example:

OMA PoC 1.0
OMA PoC 2.0
OMA PoC 3.0
Open Mobile Alliance [the URL is given inline, whereas a footnote would
be better]
"another update of the OMA PoC enabler for Push-To-Talk over 3GPP Long
Term Evolution (LTE) networks"
"OMA has defined an architecture..."

Also, the word "enabler" is used (also in the abstract), but not in a
standard way, so needs defining.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Apr 2015 12:30:42 -0400

I just looked at this draft.

Thank you for adding clear explanation of the problem you are trying to 
solve!

Just to clarify. This IMEI instance id is included in requests by the 
device:
- REGISTER
- the PUBLISH to the participting PoC function
- each PoC request. (What messages are used for this???)

ISTM that the device is well aware that the REGISTER and the PUBLISH are 
being directed to a device that is presumably trusted, and will end there.

But how does the device ensure that the other requests containing this 
also go to a trusted device that will remove the IMEI?

ISTM that you don't really need to use the IMEI for this. Some other 
unique id would do. It only needs to correlate the *concurrent* use of 
multiple addresses. For instance, each time the device turns on and 
registers it could use a different id, so that there would not be 
correlation over long periods of time.

Also, I think this draft should be reviewed by ECRIT people. Presumably 
some are on this list too, but it might be good to send a heads-up to 
the ecrit list.

	Thanks,
	Paul

On 4/23/15 10:32 PM, Dale R. Worley wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>