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

From: Tim Bray <[email-masked]>
Date: Fri, 19 Jul 2013 08:02:35 -0700

Just wanted to point out that both Apple (for iOS) and Google (for Android)
have strongly discouraged the use of IMEI to identify devices for the
purposes of application software.  There are privacy, quality, and
availability issues with their use.  Apple has removed the ability of
developers to work with the (often IMEI-derived) “Universal Device ID” (see
http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and
Google has officially deprecated their use:
http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html

I’m not sure from reading the draft what the goal of having this URN
namespace is, but if it involves encouraging its use by application
developers, I’m pretty sure it’s a bad idea.

 -Tim

---

From: Andrew Allen <[email-masked]>
Date: Fri, 19 Jul 2013 15:38:20 +0000

Tim

I suggest you also read
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/

That will explain the primary application of this URN which is intended for use in the 3GPP cellular standards.

Andrew

From: Tim Bray [mailto:[email-masked]]
Sent: Friday, July 19, 2013 10:02 AM Central Standard Time
To: IETF-Discussion Discussion <[email-masked]>
Subject: Last call: draft-montemurro-gsma-imei-urn-16.txt

Just wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software.  There are privacy, quality, and availability issues with their use.  Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html

I’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea.

 -Tim

---------------------------------------------------------------------
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.

---

From: Tim Bray <[email-masked]>
Date: Fri, 19 Jul 2013 08:58:37 -0700

> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/

Quoting from that document: “If a URN scheme other than UUID is used, the
UA MUST only use URNs for which an RFC (from the IETF stream) defines how
the specific URN needs to be constructed...”

Now, I’m not an expert in the 3GPP world; but the suggestion in that
extract that UUIDs are a better choice than a (shaky, unreliable,
privacy-problematic) device identifier certainly rings true for those of us
who think at the apps level.  -T

>  *From*: Tim Bray [mailto:[email-masked]]
> *Sent*: Friday, July 19, 2013 10:02 AM Central Standard Time
> *To*: IETF-Discussion Discussion <[email-masked]>
> *Subject*: Last call: draft-montemurro-gsma-imei-urn-16.txt
>
>   Just wanted to point out that both Apple (for iOS) and Google (for
> Android) have strongly discouraged the use of IMEI to identify devices for
> the purposes of application software.  There are privacy, quality, and
> 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.
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Jul 2013 09:25:06 -0700

> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/

I read that document.  The placement of IMEI in the instance id is a
little bit of a non-sequitur to my thinking.

There are three cases identified where it might be necessary to convey
an IMEI, but no real motivation is provided for why it has to be
included, specifically, in the instance ID.  Nor is it the case that
all of these cases necessarily require that IMEI is conveyed in the
clear.  I can imagine solutions to the real problems that do not
require that an IMEI transit the network.

However, I'll concede that the relationship between a network provider
and the devices that use the network does not necessarily grant those
devices any right protections of the form in which Tim seems to be
assuming to be necessary.  The real risk here is with scope of use.

I'd have thought that a P- header would have been more appropriate for
these use cases.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 19 Jul 2013 09:52:40 -0700

At 08:02 19-07-2013, Tim Bray wrote:
>I'm not sure from reading the draft what the goal of having this URN 
>developers, I'm pretty sure it's a bad idea.

I agree that it sounds like a bad idea to encourage application 
developers to use this URN namespace.  There was a documented 
vulnerability which demonstrated how the IMEI could be captured.

In 2006 Leslie Daigle mentioned that the sub-NID namespace does not 
belong in the version of the draft which was reviewed.

I'll quote some comments posted by Scott Brim in September 2010 to 
Apps Area Review.

   'First, this feels like a layering mixup.  When would -- or should -- a
    communicating peer outside a mobile network need to know the IMEI or
    IMEISV of a device inside a mobile network?  An IMEI is used for initial
    identification on a mobile network or for SIM-less emergency calls.
    Under what conditions would an Internet-based peer have an IMEI in hand
    and want to use it in a gsma: URN?  If as you say an "Internet device"
    is "interoperating" with a mobile device, it will do so using IP-based
    protocols and will (should) never learn the mobile device's IMEI.  I can
    see cases where an outsourced management entity might want to speak to a
    mobile network's administration regarding records for a particular IMEI,
    but it would do so in a very secure way, not using this particular URN.'

    If there is an assumption that we are going to start passing around
    IMEIs as general identifiers, then I'm concerned that you are
    engineering a world in which one must reveal permanent identifiers in
    order to communicate.

    Please enlighten me as to the intent.  Right now it feels to me like it
    enables us to do the wrong thing with IMEIs.'

The http://gsmworld.com/newsroom/document%2Dlibrary/ normative 
reference is a 404.

It would be easier to have the draft discuss the GSMA URN only.  The 
alternative is to have the draft discuss the privacy considerations 
of using IMEI and IMEISV.

Regards,
S. Moonesamy

---

From: Tim Bray <[email-masked]>
Date: Fri, 19 Jul 2013 10:07:18 -0700

On Fri, Jul 19, 2013 at 9:52 AM, S Moonesamy <[email-masked]> wrote:

> alternative is to have the draft discuss the privacy considerations of
> using IMEI and IMEISV.
>

Good catch.  Assuming this is a good idea (I’m dubious) it would be
completely unacceptable to register it without a discussion of privacy
implications. -T

---

From: Andrew Allen <[email-masked]>
Date: Fri, 19 Jul 2013 22:53:14 +0000

Tim

Do you not think that the text in the security considerations section::

"because IMEIs can be loosely correlated to a user, they need to be treated as any other personally identifiable information. In particular, the IMEI URN MUST NOT be included in messages intended to convey any level of anonymity"

covers the privacy issue?

If not what is the additional privacy concern?

Andrew

From: Tim Bray [mailto:[email-masked]]
Sent: Friday, July 19, 2013 12:07 PM Central Standard Time
To: S Moonesamy <[email-masked]>
Cc: IETF-Discussion Discussion <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

On Fri, Jul 19, 2013 at 9:52 AM, S Moonesamy <[email-masked]<mailto:[email-masked]>> wrote:

It would be easier to have the draft discuss the GSMA URN only.  The alternative is to have the draft discuss the privacy considerations of using IMEI and IMEISV.

Good catch.  Assuming this is a good idea (I’m dubious) it would be completely unacceptable to register it without a discussion of privacy implications. -T

Regards,
S. Moonesamy

---

From: Tim Bray <[email-masked]>
Date: Fri, 19 Jul 2013 16:03:27 -0700

Hm, I confess that I searched the text of the draft for the word “privacy”
and jumped to conclusions upon seeing no matches.  Probably a good idea to
work it in for impatient folk like me.

I would expand that section to point out that since the IMEI survives
device wipes and changes of possession, it shouldn’t be assumed to identify
a person.

And I really wouldn’t ever expose an IMEI at the application level, but
maybe it’s appropriate at the level this draft is addressing.  We had
endless nightmares, not only because of the wipe-survival, but because app
code would try to run on a device that didn't have an IMEI and crash, and
so on.  -T

On Fri, Jul 19, 2013 at 3:53 PM, Andrew Allen <[email-masked]> wrote:

> "because IMEIs can be loosely correlated to a user, they need to be
> treated as any other personally identifiable information. In particular,
> the IMEI URN MUST NOT be included in messages intended to convey any level
> of anonymity"
>
> *Sent*: Friday, July 19, 2013 12:07 PM Central Standard Time
> *To*: S Moonesamy <[email-masked]>
> *Cc*: IETF-Discussion Discussion <[email-masked]>
> *Subject*: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
>
>  On Fri, Jul 19, 2013 at 9:52 AM, S Moonesamy <[email-masked]>wrote:
>
>>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 20 Jul 2013 00:15:08 +0100

On 07/19/2013 11:53 PM, Andrew Allen wrote:
> the IMEI URN MUST NOT be included in messages intended to convey any level of anonymity

That seems both perfect RFC 6919 fodder and disingenuous at
the same time (how can a message convey a level of anonymity?).

I need to read the draft but this seems like it only has
downsides from a privacy perspective. So I'd hope there
are compelling functional reasons to want it that outweigh
the privacy downside.

IMEIs are very pervasive, carried around by 100's of millions
of people and generally not intended to be shared with the
Internet.

S.

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Jul 2013 16:48:09 -0700

> of people and generally not intended to be shared with the

my american social security card, which admittedly is a bit old, has
"Not to be used for identification" emblazoned on it in red.

for me, a seminal document was the 1973 "Records, Computers, and the
Rights Of Citizens," a report of the secretary's advisory committee on
automated personal data systems of the us department of health,
education, and welfare, chaired by willis ware.  it spawned the privacy
act of 1974, and i still have my copy.  see [0].  it warned of the use
the social seurity number as an identifier.  [interestingly, mitre (also
chaired by ware) did a report for the air force in '68 which reccomended
the ssn as an id]

today, in the states, the ssn is the ubiquitous identifier, and a major
target of identity thieves and may be second only to cross site cookies
as the identity target of marketeers.

in the mobile society, the ids of our devices are becoming identy gold,
and should be transmitted with extreme caution and only under compelling
circumstances.

randy

--

[0] http://itlaw.wikia.com/wiki/Records,_Computers_and_the_Rights_of_Citizens

---

From: Scott Brim <[email-masked]>
Date: Sat, 20 Jul 2013 07:23:25 -0400

Thanks, SM, for finding what I said back in 2010.  I still think this
is architected wrong, conflating devices with communication endpoints
higher up the stack, and steers us toward a path toward eventually
"needing" to reduce privacy even more.  However, 3GPP has apparently
already already started marching down that path.  Could our liaison
explain the situation there?  Is anyone actually going to use it?  Is
this a done deal - do we have to support it because otherwise 3 years
of 3GPP work get undone?

Scott

---

From: GARBA KORA TAMSIRD BELLO <[email-masked]>
Date: Sat, 20 Jul 2013 13:53:18 +0200

Hi

Yes it true , but more argumentations are welcome

Sinverely yours

---

From: S Moonesamy <[email-masked]>
Date: Sat, 20 Jul 2013 06:17:59 -0700

At 15:53 19-07-2013, Andrew Allen wrote:
>treated as any other personally identifiable information. In 
>particular, the IMEI URN MUST NOT be included in messages intended 
>to convey any level of anonymity"
>

There is a difference between privacy concerns and privacy 
considerations.  It has been mentioned that "the view in 3GPP was 
that the IMEI should not be of any greater concern when used as an 
instance ID than using a UUID".  draft-montemurro-gsma-imei-urn-16 states that:

   "Specifically the IMEI is to be incorporated in a module which is
    contained within the terminal.  The IMEI SHALL NOT be changed
    after the terminal's production process.  It SHALL resist tampering,
    i.e. manipulation and change, by any means  (e.g. physical,
    electrical and software)."

The pervasive use of UUID in computing does not make it a good 
idea.  I doubt that there has been any privacy analysis of how UUID 
will be used or misused prior to the publication of the RFC.  The 
IMEI is built into the device.  The scope for misuse would be clear 
enough for a person designing identifiers.

 From draft-montemurro-gsma-imei-urn-16:

   "Therefore the IMEISV (that is, the IMEI URN with svn parameter)
    MUST NOT be delivered to devices that are not trusted.  Further,
    because IMEIs can be loosely correlated to a user, they need to
    be treated as any other personally identifiable information.  In
    particular, the IMEI URN MUST NOT be included in messages intended
    to convey any level of anonymity."

The IMEI is considered as personal data in some jurisdictions.  There 
is a strong correlation between the IMEI and a user.

I read draft-montemurro-gsma-imei-urn-16 and I see that the four 
authors have listed their phone numbers as "unlisted".  Is there a 
reason for that?  The question may sound unrelated to the draft and 
it can be argued that it is unrelated to the draft.  I asked it as it 
may help the casual reader understand what privacy is 
about.  draft-moonesamy-privacy-identifiers-00 (expired) argues that 
there is an implicit assumption that the underlying protocols are 
transmitting the right amount of information needed for the protocols 
to work.  Is for example, urn:gsma:imei:90420156-025763-0, required 
for SIP to work?  I do not think so.

The world was somewhat naive about privacy in 2006.  Privacy is a hot 
topic nowadays.  The metadata debacle is one of the contributing 
factors.  There seems to be an assumption that the IMEISV is usually 
sent over trusted channels to trusted parties.

The second sentence containing "must not" written in capital letters 
takes a position where anonymity of messages is opt-in.  The GSM 
Association has published a set of principles which mentions "privacy 
by design".  It is up to the reader to read the two sentences quoted 
above and determine whether "privacy by design" is just another 
buzzword or a principle which the GSM Association considers as important.

>this a done deal - do we have to support it because otherwise 3 years

As a responding to Scott's comment about the three years of work I 
would say that this has the signs of an inevitable decision.  I'll 
describe the IETF angle as follows:

   Is it okay to assign a Uniform Resource Name namespace for GSMA?

The namespace assignment is not a problem.  Have an assignment 
request sitting in the IETF queue for seven years is a problem.  It 
would be good if someone explained why this happened unless the IETF 
considers it as acceptable to be asked to take inevitable decisions.

I agree with Scott's comment.  Tim Bray already pointed out that this 
is a bad idea.

>Yes it true , but more argumentations are welcome

The duck won't fly. :-)

Regards,
S. Moonesamy

---

From: John C Klensin <[email-masked]>
Date: Sat, 20 Jul 2013 09:56:36 -0400

Hi.

Borrowing from several other notes and comments, it seems to me
that we have three interlocking issues that keep recurring and
producing long discussions.  They are by no means independent of
this particular draft, but seem to be becoming generic.

(1) Are we willing to publish (or even standardize) specs whose
nature is to provide a vehicle for making privacy-sensitive
information public?  The arguments against doing so seem
obvious.  The arguments for doing so include "those who claim
they need this will do it anyway so we are better off publishing
a spec that will at least reduce interoperability side-effects
and permit spelling out the issues as "privacy considerations"
or security ones.

(2) Is turning hardware identifiers (physical-layer objects)
into applications or user level identifiers an acceptable idea?
Are DNS RRTYPEs that map application-level identifiers into
other identifiers that can loop back through the DNS without
guarantees that the process will terminate part of the same
problem or a different one?

(3) Do either of the above answers change if the proposal comes
from another SDO or a major industry group?

I don't know the answers, but I'm pretty sure that trying to
address each of these issues separately every time a new
protocol, RRTYPE, or URN (or URI) type comes along that
interacts with one of them is not the way.  It seems to me that
we ought to have something along the lines of RFC 1984 in our
future and that a plenary discussion might be a useful first
step.  I don't suppose the IAB or IESG would be willing to
postpone or push something out of the announced agendas to allow
for that discussion, which, given this Last Call and the recent
one over RRTYPs would seem to be critical path.   Any volunteers
to get in front of the mic lines?

    john

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 20 Jul 2013 15:51:18 +0100

Wrt privacy in general...

On 07/20/2013 02:56 PM, John C Klensin wrote:
>  Any volunteers

I'd welcome that discussion. I'd love to see us have a
BCP61-like [1] RFC on the topic of privacy and I also
reckon that that'd help short-cut a number of IETF LCs
and IESG DISCUSSes. (For example the Forwarded HTTP
header and WebFinger both caused extensive discussions.)

FWIW, my personal preference would be that such a BCP
would attempt to make our work be more privacy friendly
and by default though I'm not quite how how best to try
achieve that though.

But, even if the outcome wasn't a BCP along the lines
I'd prefer, I think such a beast would still be worth
having if it meant we could avoid a whole lot of these
kinds of similar discussions on individual drafts.

S.

[1] http://tools.ietf.org/html/bcp61

---

From: Scott Brim <[email-masked]>
Date: Sat, 20 Jul 2013 11:06:38 -0400

> [1] http://tools.ietf.org/html/bcp61

I agree completely.  Doesn't draft-iab-privacy-considerations do what
you want?  (And no matter what gets agreed to at a general level, we
will still have these discussions about specifics.)

---

From: John C Klensin <[email-masked]>
Date: Sat, 20 Jul 2013 11:31:36 -0400

--On Saturday, July 20, 2013 15:51 +0100 Stephen Farrell
<[email-masked]> wrote:

>...

That was exactly what I was thinking.

I think the security analogy is a combination of BCP 61 (RFC
3365) and RFC 1984.  That is a quibble but relates to the
question of whether draft-iab-privacy-considerations is
sufficient.  I think it is necessary, but not sufficient. The
other piece would be a fairly clear and ideally consensus,
statement about what we do and do not intend to do and why.
IMO, the only want to make progress on avoiding these similar
discussions on individual drafts would be to develop such a
consensus and focus the discussions on it.

   john

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 20 Jul 2013 19:10:08 +0100

On 07/20/2013 04:06 PM, Scott Brim wrote:
> you want?  

As John said, that sets out considerations but what I'm
talking about here would be a BCP, so no that's a useful
input but doesn't represent an IETF consensus position
the way a BCP would.

S.

> (And no matter what gets agreed to at a general level, we

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 20 Jul 2013 19:13:52 +0100

> statement about what we do and do not intend to do and why.

Fully agree. I do hope we get this discussion at the mic in
Berlin. (Or if some folks are already interested in working
on this just send me a mail.)

If someone felt this whole thing was a bad plan, now'd also
be a good time to hear about that (and why). Though of course
there'd be loads more opportunities for that too.

S.

---

From: Andrew Allen <[email-masked]>
Date: Sat, 20 Jul 2013 18:28:11 +0000

The URN containing the IMEI is used by all mobile phones that support voice over LTE. It is a dependency for 3GPP release 8 (which was completed about end of 2008). So yes it is going to be used and its more than 3 years of 3GPP work invested and is already incorporated into many devices. 

In the pre-existing circuit switched systems the IMEI is delivered to the network as the device identifier and it is also necessary to deliver the same device identifier to the network when using SIP so that when handover takes place between packet switched and circuit switched the network can correlate the communication as being with the same device. 

Regulations also require the IMEI to be delivered to the network. 
This associated draft describes how 3GPP uses the IMEI as a SIP instance ID and the reasons why:
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/

----- Original Message -----
From: Scott Brim [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 06:23 AM Central Standard Time
To: S Moonesamy <[email-masked]>
Cc: Tim Bray <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

Scott

---

From: Tim Bray <[email-masked]>
Date: Sat, 20 Jul 2013 11:36:30 -0700

So if it’s going to be used, exactly as specified, whatever we do, then
what value is added by the IETF process?  -T

On Sat, Jul 20, 2013 at 11:28 AM, Andrew Allen <[email-masked]>wrote:

>
> The URN containing the IMEI is used by all mobile phones that support
> voice over LTE. It is a dependency for 3GPP release 8 (which was completed
> about end of 2008). So yes it is going to be used and its more than 3 years
> of 3GPP work invested and is already incorporated into many devices.
>
> In the pre-existing circuit switched systems the IMEI is delivered to the
> network as the device identifier and it is also necessary to deliver the
> same device identifier to the network when using SIP so that when handover
> takes place between packet switched and circuit switched the network can
> correlate the communication as being with the same device.
>
> transmission by unintended recipients is not authorized and may be unlawful.
>

---

From: Andrew Allen <[email-masked]>
Date: Sat, 20 Jul 2013 20:08:28 +0000

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?

Andrew

From: Tim Bray [mailto:[email-masked]]
Sent: Friday, July 19, 2013 10:58 AM Central Standard Time
To: Andrew Allen
Cc: [email-masked] <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen <[email-masked]<mailto:[email-masked]>> wrote:
I suggest you also read
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/

Quoting from that document: “If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed...”

Now, I’m not an expert in the 3GPP world; but the suggestion in that extract that UUIDs are a better choice than a (shaky, unreliable, privacy-problematic) device identifier certainly rings true for those of us who think at the apps level.  -T

Andrew

From: Tim Bray [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, July 19, 2013 10:02 AM Central Standard Time
To: IETF-Discussion Discussion <[email-masked]<mailto:[email-masked]>>
Subject: Last call: draft-montemurro-gsma-imei-urn-16.txt

 -Tim

---

From: Tim Bray <[email-masked]>
Date: Sat, 20 Jul 2013 13:31:18 -0700

On Sat, Jul 20, 2013 at 1:08 PM, Andrew Allen <[email-masked]> wrote:

> 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?
>

The difference is that the UUID (properly) vanishes when the device is
factory-reset (“wiped”), as is common when a device is passed on to a new
owner.  The IMEI persists, however.  -T

> *Sent*: Friday, July 19, 2013 10:58 AM Central Standard Time
> *To*: Andrew Allen
> *Cc*: [email-masked] <[email-masked]>
>  On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen <[email-masked]>wrote:
>
>> I suggest you also read
>>
>  Quoting from that document: “If a URN scheme other than UUID is used,
> the UA MUST only use URNs for which an RFC (from the IETF stream) defines
> how the specific URN needs to be constructed...”
>

---

From: Andrew Allen <[email-masked]>
Date: Sat, 20 Jul 2013 20:47:33 +0000

Tim

Mobile phones are not usually completely "factory reset" if resold and even if they were a UUID may still have been stored in non volatile as it may have been generated during final test.

In any case if the IMEI was to persist after a resale how would that be a privacy problem given the restrictions placed on the usage in
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/?

The intention is that the IMEI is not passed to the remote party except when required by regulations for an Emergency call.

Andrew

From: Tim Bray [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 03:31 PM Central Standard Time
To: Andrew Allen
Cc: [email-masked] <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

On Sat, Jul 20, 2013 at 1:08 PM, Andrew Allen <[email-masked]<mailto:[email-masked]>> wrote:

The difference is that the UUID (properly) vanishes when the device is factory-reset (“wiped”), as is common when a device is passed on to a new owner.  The IMEI persists, however.  -T

Andrew

From: Tim Bray [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, July 19, 2013 10:58 AM Central Standard Time
To: Andrew Allen
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

Andrew

 -Tim

---

From: Andrew Allen <[email-masked]>
Date: Sat, 20 Jul 2013 20:48:17 +0000

I think IANA registration of namespaces has a lot of value.

From: Tim Bray [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 01:36 PM Central Standard Time
To: Andrew Allen
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

So if it’s going to be used, exactly as specified, whatever we do, then what value is added by the IETF process?  -T

On Sat, Jul 20, 2013 at 11:28 AM, Andrew Allen <[email-masked]<mailto:[email-masked]>> wrote:

----- Original Message -----
From: Scott Brim [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, July 20, 2013 06:23 AM Central Standard Time
To: S Moonesamy <[email-masked]<mailto:[email-masked]>>
Cc: Tim Bray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

Scott

---

From: Scott Brim <[email-masked]>
Date: Sat, 20 Jul 2013 16:55:27 -0400

> different in terms of privacy concerns from the IMEI being used as an

You're not demonstrating that an IMEI is just as good, you're
demonstrating that a UUID is just as bad.

---

From: Tim Bray <[email-masked]>
Date: Sat, 20 Jul 2013 14:07:21 -0700

Except that for normal usages at the application level, the UUID is
generated by the app and placed in its private per-app storage, which is
always erased on a factory-reset.  To Andrew Allen: I strongly recommend
factory-resetting your phone before you sell it, and also factory-resetting
any phones you buy second-hand, just to be sure.  Most people do this, for
good reason. -T

On Sat, Jul 20, 2013 at 1:55 PM, Scott Brim <[email-masked]> wrote:

> > Each UA has a unique instance-id that stays the same for this UA even if
> the
> > UA reboots or is power cycled."
> >

---

From: Doug Barton <[email-masked]>
Date: Sat, 20 Jul 2013 15:19:57 -0700

> I think IANA registration of namespaces has a lot of value.

I think backfilling registrations for poached identifiers sets a 
bad/dangerous example.

Doug (not necessarily speaking with any hats, current or former)

---

From: Andrew Allen <[email-masked]>
Date: Sat, 20 Jul 2013 22:20:21 +0000

Equivalence is equivalence the rest seems subjective to me - is the glass half full or half empty.

The point is they are no more or less harmful.

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?

Andrew

---

From: Andrew Allen <[email-masked]>
Date: Sat, 20 Jul 2013 22:34:43 +0000

Martin

There are obviously always alternative design choices but why would you want to include both a pre assigned device ID and a generated device ID in the same message?

Andrew

---

From: Andrew Allen <[email-masked]>
Date: Sat, 20 Jul 2013 22:45:44 +0000

Tim

This is not the "normal" 3GPP IMS scenario. In IMS the device as a whole is considered as a single UA, multiple IMS applications will need to share a common registration procedure that is provided by the underlying OS.

Otherwise multiple IMS registrations from different applications on a 3GPP terminal will likely conflict with each other if they do not share a common registration mechanism that registers all IMS apps using a common registration procedure. In IMS, contacts from the same entity are overwritten by subsequent registrations. Which means that if each app were to register individually then any contact parameters such as feature tags from a previous registered app would be overwritten by the latest registering app.

Therefore the registration function and the instance ID will likely be part of the OS and not the application.

In any case RFC 5626 says nothing about requiring instance IDs to be wiped or regenerated when the UA is transferred to another user or that the UA cannot be embedded in non volative. It doesn't even barr the instance ID being delivered to other users.
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ goes a lot further than RFC 5626 in addressing privacy of the instance ID in that regard.

Andrew

From: Tim Bray [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 04:07 PM Central Standard Time
To: Scott Brim <[email-masked]>
Cc: Andrew Allen; [email-masked] <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

Except that for normal usages at the application level, the UUID is generated by the app and placed in its private per-app storage, which is always erased on a factory-reset.  To Andrew Allen: I strongly recommend factory-resetting your phone before you sell it, and also factory-resetting any phones you buy second-hand, just to be sure.  Most people do this, for good reason. -T

On Sat, Jul 20, 2013 at 1:55 PM, Scott Brim <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Jul 2013 15:48:33 -0700

> I think IANA registration of namespaces has a lot of value.

let me ask the other side of the coin, in this case, what harm will be
done by not making this an rfc and registering the imei uri?

and i am not a fan of the mrs goldberg argument.

randy

---

From: Doug Barton <[email-masked]>
Date: Sat, 20 Jul 2013 15:53:44 -0700

> done by not making this an rfc and registering the imei uri?

None, because we lost the battle over protocol parameter poaching years 
ago. Doesn't mean I have to like it. :)

Doug

---

From: Andrew Allen <[email-masked]>
Date: Sat, 20 Jul 2013 23:00:15 +0000

Randy

Are you suggesting its not a problem if everyone were to just go off and define namespaces and not have them registered with IANA?

I don't think that's a good precedence.

The GSMA is the authoritative organisation for some identifers that have been used in billions of mobile devices for 20 years. Why should IETF deny them a namespace and a listing in the  IANA registry for such identifers?

If there are concerns with the usage of these identifiers those concerns should be addressed in  the drafts that define the usage.

Andrew

----- Original Message -----
From: Randy Bush [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 05:48 PM Central Standard Time
To: Andrew Allen
Cc: IETF Disgust <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

randy

---

From: John C Klensin <[email-masked]>
Date: Sat, 20 Jul 2013 19:27:29 -0400

--On Saturday, July 20, 2013 15:19 -0700 Doug Barton
<[email-masked]> wrote:

> I think backfilling registrations for poached identifiers sets
> a bad/dangerous example.

Doug,

This is another of those arguments that I wish we could avoid
repeating for each individual document.

One of our oldest precedents and principles is that it is better
to have things registered than not, even when they are ugly.
Having such registrations gives us a fighting chance of avoiding
the interoperability problems associated with two different
parties accidentally using the same name for different purposes.
It also provides a centralized mechanism for mapping identifiers
onto documentation.  That is both a good thing in itself and, in
some cases, provides a place to include warnings about improper
uses, nasty side-effects, and security and/or privacy problems.

The Internet is not an operating system (or even the PSTN) in
which the arbiters of taste can keep something from being
incorporated in a release or used. If someone is determined to
use a particular capability under a particular name, we can try
to talk them out of it but, if they are still determined, the
only question is whether we are better off with registration and
documentation than without them.   And, generally, we are better
off with the first.

Discussions about poaching, squatting, and even stupidity or bad
taste are interesting but not generally helpful.

    john

---

From: S Moonesamy <[email-masked]>
Date: Sat, 20 Jul 2013 16:50:20 -0700

Hi Andrew,
>I think IANA registration of namespaces has a lot of value.

draft-montemurro-gsma-imei-urn-16 discusses about two namespaces:

  (i)  gsma

  (ii) imei

It is not possible to get a IANA registration for (ii) as according 
to draft-montemurro-gsma-imei-urn-16 (ii) is managed by (i).  In 
simple terms (ii) does not require IETF approval.

Regards,
S. Moonesamy

---

From: Tim Bray <[email-masked]>
Date: Sat, 20 Jul 2013 17:01:58 -0700

On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen <[email-masked]> wrote:

> Can it please be explained how the IMEI URN when used as stated in

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

---

From: John C Klensin <[email-masked]>
Date: Sat, 20 Jul 2013 21:23:56 -0400

--On Saturday, July 20, 2013 11:36 -0700 Tim Bray
<[email-masked]> wrote:

> So if it's going to be used, exactly as specified, whatever
> we do, then what value is added by the IETF process?  -T

See my earlier note, but mostly to aid in getting the
documentation right.  For example, to the extent that the recent
discussion results in a more complete treatment of privacy
and/or security considerations in the documentation, that is a
net improvement and added value.

  john

---

From: Tim Bray <[email-masked]>
Date: Sat, 20 Jul 2013 19:17:40 -0700

Fair enough.  I think it would be reasonable to ask that:

- the draft include the word “privacy”
- the draft discuss the issues around relying on an identifier that
persists across changes in device ownership

There may be an issue concerning a SIP-related identifier which is
unavailable on millions of mobile devices which do not have IMEIs, but it’s
quite possible that it’s non-applicable in the context of the draft.  -T

---

From: John C Klensin <[email-masked]>
Date: Sat, 20 Jul 2013 22:44:18 -0400

--On Saturday, July 20, 2013 19:17 -0700 Tim Bray
<[email-masked]> wrote:

> - the draft include the word "privacy"
> - the draft discuss the issues around relying on an identifier
> that persists across changes in device ownership
> 
> There may be an issue concerning a SIP-related identifier
> which is unavailable on millions of mobile devices which do
> not have IMEIs, but it's quite possible that it's
> non-applicable in the context of the draft.  -T

Personally, I'd consider getting all three of those issues
addressed in the document (including a discussion of the
applicability of the latter and a serious discussion of the
privacy issues) as adding value... and as requirements for RFC
publication in the IETF Stream.

   john

---

From: S Moonesamy <[email-masked]>
Date: Sat, 20 Jul 2013 20:48:02 -0700

Hi John,
>net improvement and added value.

There was a Last Call for draft-montemurro-gsma-imei-urn-01 in 
2007.  The draft was sponsored by an Apps 
AD.  draft-montemurro-gsma-imei-urn-04 was evaluated (I did not 
verify the details) in 2009.  An IPR disclosure, about a patent filed 
several years ago, was filed after that evaluation.  The DISCUSS got 
cleared automatically.  draft-montemurro-gsma-imei-urn-08  was 
dispatched to RAI in 2011.

3GPP was assigned a URN in 2008.  The shepherd write-up 
for  draft-montemurro-gsma-imei-urn-16 mentions that "this document 
is required for the 3GPP/IMS specification, thus any
vendor that implements the 3GPP specifications follows this 
specification".  The significant difference between the 3GPP URN and 
the requested GSMA URN is that there is an IPR disclosure on that latter.

One of the questions asked by Tim Bray was about the WiFi-only 
scenario.  That was raised previously through a DISCUSS as the softphone issue.

The privacy discussion might cause some discontent.  As for whether 
the draft will gain consensus, well, what can I say; if it is the 
consensus of the IETF to support state-sponsored surveillance there 
is nothing I can do about it. :-)

Regards,
S. Moonesamy

---

From: Andrew Allen <[email-masked]>
Date: Sun, 21 Jul 2013 04:48:37 +0000

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:[email-masked]]
Sent: Saturday, July 20, 2013 07:01 PM Central Standard Time
To: Andrew Allen
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen <[email-masked]<mailto:[email-masked]>> 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

---

From: Andrew Allen <[email-masked]>
Date: Sun, 21 Jul 2013 05:05:31 +0000

Certainly text can be added to the draft to address concerns. 

Could Tim please elaborate on what issues he sees when a device is transferred between owners and what potential uses of the URN he has a concern with? 

Certainly I can see that if it was used as address that had some permanence then that would be an issue however this is not the case as per http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/

Andrew

----- Original Message -----
From: John C Klensin [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 09:44 PM Central Standard Time
To: Tim Bray <[email-masked]>
Cc: IETF-Discussion Discussion <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

   john

---

From: Andrew Allen <[email-masked]>
Date: Sun, 21 Jul 2013 07:03:57 +0000

The reason why the IMEI namespace is being registered as a GSMA namespace and not as part of the 3GPP namespace is that the GSMA has the responsibility for IMEI assignment and hence in maintaining uniqueness of the namespace. It has nothing to do with IPR which was extensively discussed on the dispatch list.

The primary purpose of the IMEI is for preventing use of stolen mobile phones and enabling emergency calls to be made from mobiles that don't have a valid subscription. 

Andrew

----- Original Message -----
From: S Moonesamy [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 10:48 PM Central Standard Time
To: John C Klensin <[email-masked]>
Cc: Tim Bray <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

Hi John,

Regards,
S. Moonesamy

---

From: Andrew Allen <[email-masked]>
Date: Sun, 21 Jul 2013 07:12:34 +0000

http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid is also required in order to use the IMEI as a SIP instance ID. So just not registering the sub namespace doesn't avoid the IETF having to address the issue.

As John pointed out having the sub namespace reviewed by IETF provides the opportunity to add text to address privacy concerns with any inappropriate usage.

----- Original Message -----
From: S Moonesamy [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 06:50 PM Central Standard Time
To: Andrew Allen
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

Hi Andrew,

  (i)  gsma

  (ii) imei

Regards,
S. Moonesamy

---

From: Andrew Allen <[email-masked]>
Date: Sun, 21 Jul 2013 07:37:20 +0000

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.

Andrew

From: Andrew Allen [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 11:48 PM Central Standard Time
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

Tim

Firstly as stated in

Andrew

 -T

Andrew

---

From: Tim Bray <[email-masked]>
Date: Sun, 21 Jul 2013 10:42:29 -0700

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 <[email-masked]>wrote:

> 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.
>
>
> 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:[email-masked]]
> *Sent*: Saturday, July 20, 2013 11:48 PM Central Standard Time
> *To*: [email-masked] <[email-masked]>
> 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.
>
> 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
>
> *Sent*: Saturday, July 20, 2013 07:01 PM Central Standard Time
> *To*: Andrew Allen
> *Cc*: [email-masked] <[email-masked]>; [email-masked] <
> [email-masked]>
>  On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen <[email-masked]>wrote:
>
> 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
>>
>> > Each UA has a unique instance-id that stays the same for this UA even
>> if the

---

From: S Moonesamy <[email-masked]>
Date: Sun, 21 Jul 2013 09:38:24 -0700

At 00:03 21-07-2013, Andrew Allen wrote:
>The reason why the IMEI namespace is being registered as a GSMA 
>namespace and not as part of the 3GPP namespace is that the GSMA has 
>the responsibility for IMEI assignment and hence in maintaining 
>uniqueness of the namespace. It has nothing to do with IPR which was 
>extensively discussed on the dispatch list.

I read the dispatch mailing list.  I did not see the extensive 
discussion.  I saw the following comment "Surely that is just trying 
to turn the IETF into the policeman".

>The primary purpose of the IMEI is for preventing use of stolen 
>mobile phones and enabling emergency calls to be made from mobiles 
>that don't have a valid subscription.

 From what I read the main purpose of the IMEI is to be able to take 
measures against stolen phones and against equipment which the use 
cannot be accepted for technical or safety reasons.  The secondary 
purpose is the tracing of malicious calls.

There is an apps which sends the IMEI in a 
cryptographically-protected form over the network.  For what it is 
worth, it's MD5.

There has been some work in the IETF on emergency calls (see service URN).

At 00:12 21-07-2013, Andrew Allen wrote:
>As John pointed out having the sub namespace reviewed by IETF 
>provides the opportunity to add text to address privacy concerns 
>with any inappropriate usage.

I don't think that it is the role of the IETF to determine whether 
the usage of a sub-namespace is appropriate or not as it can cause 
namespace management issues.

I tried the explain the subtlety between privacy concerns and privacy 
considerations.  The IMEI can also be used as a customer identifier.

Regards,
S. Moonesamy

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Jul 2013 10:57:28 -0700

> There are obviously always alternative design choices but why would you want to include both a pre assigned device ID and a generated device ID in the same message?

I think that reading this thread should provide you with ample reasons.

The instance ID in outbound has certain stability requirements that do
not strictly correspond to the lifetime of the hardware in use.  The
other use cases answer very different questions, which include: is
this a stolen device, is this device authorized to use the networks,
etc...   I'm certain those questions can be answered without a device
identifier traversing the network.