Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

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 
<aallen(_at_)blackberry(_dot_)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:aallen(_at_)blackberry(_dot_)com]
> *Sent*: Saturday, July 20, 2013 11:48 PM Central Standard Time
> *To*: tbray(_at_)textuality(_dot_)com <tbray(_at_)textuality(_dot_)com>
> *Cc*: ietf(_at_)ietf(_dot_)org <ietf(_at_)ietf(_dot_)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: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>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]
> >  Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time
> > To: Andrew Allen
> >  Cc: tbray(_at_)textuality(_dot_)com <tbray(_at_)textuality(_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 4:08 PM, Andrew Allen 
> > <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.
> ---------------------------------------------------------------------
> 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.