Look, I don’t remotely understand the 3gpp universe, and I acknowledge John Klensin’s point about the advantages of registering things, in general.
Having said that, I worry a little bit that URNs are URIs and there are lots of specs out there that say “use any URI” and I sure wouldn’t want to see these things used anywhere near any application-level protocol. If this were an Apps-Area thing and I thought that registering it would increase the risk that these patent-encumbered, privacy-compromising, operationally-fragile constructs had any chance of creeping into general use by app developers, I’d be lying in the road screaming. As it is, I think the issues with this draft have been raised sufficiently, so I’ll shut up and leave further discussion to those who understand domain-specific technical issues. -Tim On Sun, Jul 21, 2013 at 12:37 AM, Andrew Allen <aal...@blackberry.com>wrote: > > 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:aal...@blackberry.com] > *Sent*: Saturday, July 20, 2013 11:48 PM Central Standard Time > *To*: tb...@textuality.com <tb...@textuality.com> > *Cc*: ietf@ietf.org <ietf@ietf.org> > *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:tb...@textuality.com] > *Sent*: Saturday, July 20, 2013 07:01 PM Central Standard Time > *To*: Andrew Allen > *Cc*: scott.b...@gmail.com <scott.b...@gmail.com>; ietf@ietf.org < > ietf@ietf.org> > *Subject*: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt > > On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen <aal...@blackberry.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.b...@gmail.com] >> Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time >> To: Andrew Allen >> Cc: tb...@textuality.com <tb...@textuality.com>; ietf@ietf.org < >> ietf@ietf.org> >> Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt >> >> On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen <aal...@blackberry.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. > --------------------------------------------------------------------- > 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. >
