Tim
Seems the text got munged with some copy pasting so here it is corrected:
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 without an IMEI then it will 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: Andrew Allen [mailto:aallen@xxxxxxxxxxxxxx]
Sent: Saturday, July 20, 2013 11:48 PM Central Standard Time
To: tbray@xxxxxxxxxxxxxx <tbray@xxxxxxxxxxxxxx>
Cc: ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Sent: Saturday, July 20, 2013 11:48 PM Central Standard Time
To: tbray@xxxxxxxxxxxxxx <tbray@xxxxxxxxxxxxxx>
Cc: ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
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@xxxxxxxxxxxxxx]
Sent: Saturday, July 20, 2013 07:01 PM Central Standard Time
To: Andrew Allen
Cc: scott.brim@xxxxxxxxx <scott.brim@xxxxxxxxx>; ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Sent: Saturday, July 20, 2013 07:01 PM Central Standard Time
To: Andrew Allen
Cc: scott.brim@xxxxxxxxx <scott.brim@xxxxxxxxx>; ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen <aallen@xxxxxxxxxxxxxx> 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?
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
Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time
To: Andrew Allen
Cc: tbray@xxxxxxxxxxxxxx <tbray@xxxxxxxxxxxxxx>; ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen <aallen@xxxxxxxxxxxxxx> 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. ---------------------------------------------------------------------
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.