Tim
Firstly as stated in
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
the use of the IMEI as a SIP Instance ID only pertains to usage of SIP with the
3GPP IMS and if a device is not using IMS sing IMS without an IMEI uses IMS
then it will still use a UUID as the SIP instance ID as per RFC 5626. If a
device without an IMEI uses IMS then it will also still use a UUID as the SIP
instance ID as per RFC 5626. This is specified also in the 3GPP IMS
specification TS 24.229 as well as the above draft.
So applications running on devices that don't have an IMEI can still use SIP
for sessions.
The IMEI which has been used in mobile devices for 20 years also survives
device wipes for the circuit switched calling capability as used by billions of
mobiles today with 2G and 3G networks. So again how is this more harmful for 4G
than the current situation with 2G and 3G if a mobile device is transferred to
a new owner?
Andrew
From: Tim Bray [mailto:tbray(_at_)textuality(_dot_)com]
Sent: Saturday, July 20, 2013 07:01 PM Central Standard Time
To: Andrew Allen
Cc: scott(_dot_)brim(_at_)gmail(_dot_)com
<scott(_dot_)brim(_at_)gmail(_dot_)com>; ietf(_at_)ietf(_dot_)org
<ietf(_at_)ietf(_dot_)org>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen
<aallen(_at_)blackberry(_dot_)com<mailto:aallen(_at_)blackberry(_dot_)com>>
wrote:
Can it please be explained how the IMEI URN when used as stated in
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
Is any more harmful than as the IMEI is used today by over 90% of mobile phones
in use today worldwide?
It survives device wipes, which usually happen upon change of device ownership.
I’m not an expert in your application domain, so pardon me if this question is
hopelessly naive: It seems that this identifier is related in some way to SIP
sessions. It seems that it would be a common operation to launch a SIP session
on a device such as a WiFi-only tablet, or an iPod touch, that doesn’t have an
IMEI. Is this a problem?
-T
Andrew
----- Original Message -----
From: Scott Brim
[mailto:scott(_dot_)brim(_at_)gmail(_dot_)com<mailto:scott(_dot_)brim(_at_)gmail(_dot_)com>]
Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time
To: Andrew Allen
Cc: tbray(_at_)textuality(_dot_)com<mailto:tbray(_at_)textuality(_dot_)com>
<tbray(_at_)textuality(_dot_)com<mailto:tbray(_at_)textuality(_dot_)com>>;
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>
<ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen
<aallen(_at_)blackberry(_dot_)com<mailto:aallen(_at_)blackberry(_dot_)com>>
wrote:
Tim
The quote is from RFC 5626 which also states:
"3.1. Summary of Mechanism
Each UA has a unique instance-id that stays the same for this UA even if the
UA reboots or is power cycled."
Since the UUID in the instance ID is also static how is this significantly
different in terms of privacy concerns from the IMEI being used as an
instance ID?
You're not demonstrating that an IMEI is just as good, you're
demonstrating that a UUID is just as bad.
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.