Subject: Re: [dispatch] Deriving URI from MAC-based URN ???

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Oct 2011 19:37:32 -0400

On 9/23/11 12:22 PM, Kevin P. Fleming wrote:
> On 09/23/2011 10:46 AM, Worley, Dale R (Dale) wrote:
>>> From: Paul Kyzivat [[email-masked]]
>>>
>>> You can just configure the phone as you say, IF:
>>>
>>> - the phone has a configurable light
>>> - the light can be configured with a URI
>>> - the phone determines the light status by using the URI
>>> in the way intended by the target of that URI
>>>
>>> AFAIK all of those are unusual properties, except for the specific
>>> equipment that currently supports it. If I have some "other" phone I am
>>> out of luck unless I am in a position to modify it in that way.
>>
>> I may be completely misunderstanding you, but I know of no SIP phone
>> which is claimed to "have BLF lights" that does *not* implement the
>> points you've listed.
>
> Yeah... I was going to post the same thing, but wasn't quite sure if I
> was missing something obvious :-)

I've been living in the sheltered world of Cisco phones.

AFAIK there aren't any real standards for this, so it will work for 
those things that happen to follow this defacto standard.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 3 Oct 2011 15:34:07 -0400

> I've been living in the sheltered world of Cisco phones.

And conversely, Cisco phones have never implemented enough of SIP to
be usable in our pure-proxy system.

What we see in the market is that a phone is configured with a single
URI for BLF.  The phone subscribes to the URI for dialog events with
the "resource list" extension (RFC 4662).  Each resource in the
resource list is mapped to one BLF light.  The state of the light is
driven by interpreting the status of the dialogs reported for the
resource in the resource list events.

Actually, the phones don't support RFC 4662 event values generally,
but rather the subset of it that Broadworks can generate:  Each
resource must have only one resource instance, and in full-state
events, each resource must have at least one dialog, whose local
display name is used to label the BLF button.  Or something like that;
it's a horror story that I've started to forget.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Oct 2011 01:05:45 -0400

> it's a horror story that I've started to forget.

OK. This has been a long digression from arguments about new URN 
formats. I guess the point is that some applications may utilize the URN 
in a sip.instance in unusual and proprietary ways, and changing the type 
of URN could break that usage. IMO that is not something we need be 
concerned with here.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 4 Oct 2011 11:18:12 -0400

> I guess the point is that some applications may utilize the URN in a
> sip.instance in unusual and proprietary ways, and changing the type of
> URN could break that usage. IMO that is not something we need be
> concerned with here.

The related point I was trying to make is that I've written code that
uses sip.instance URNs in non-trivial ways, and since the beginning,
the code was organized to be robust against non-UUID URNs, as there
was no assurance that UAs would not use such URNs.

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Oct 2011 07:36:38 -0600

Dale - sent in my role as an individual contributor. (all my emails are in my role as an individual contributor unless they are clearly signed as some other role)

In the past I have made the mistake of listing all my concerns with this draft then one or two would get discussed for a bit and rest ignored so this time I'm going to try and stick with a few high level ones and some minor ones. We can try to resolve theses a bit then we can move on the others. Lets start with the stuff from your email. 

Interoperability.

I've asked multiple people does this happen in INVITEs or just REGISTERs and got mixed answers. It makes a big difference - at some level this is a proposal to black list phones and / or part of a malware prevention systems. Or perhaps it is a proposal to white list phones and ones that don't have this won't work. You can say this going to be restricted to just the sets of people that want to use it but that is seldom how standards work out That might be true in the cases of if it only went from a phone to the domain for it's AOR. However, if this will also be used in INVITE cases, would it stop calls from any 3GPP phone to non 3GPP phone? Making sure that we did not have needless lack of interoperability between classic IETF SIP and 3GPP style SIP has always been a goal. Even if this is only only on IMS phones, theses are now used well outside the mobile environment - we see them used on wireline and enterprise environments so would there be a problem from other SIP devices to theses. Could a soft phone get the required IMEI identifier so it was not blacklisted? Could a small vendor get them? These are all things I wonder.

It's impossible to answer any of the above questions without knowing something about how this blacklisting stuff works and what this identifier is used for. This leads to my first issues. I want a description of how this works so we can decide if there are interoperability problems or not. I am constantly told this is important to 3GPP yet I can't find a 3GPP document that even has a reference to this draft or explains how it works. So this is my most important question to you -  Do you think this is unreasonable that we should ask how this works and if there are interoperability problems? If this is important to 3GPP, could they provide a pointer to a document that has reference to it and defines how it is used.

On a minor notes related to references - I'm not objecting based on process crap around the references but it would be really really nice if the drafts could be updated so that the reference pointed at a specific document - not a vague family of documents where I have no idea if I am reading the right one or not. I never know what to read when I see 3GPP 24.237 but if you gave me a date and version, or even a link, it would be easier. A reference should be something where we both know we are reading the same document. I realize the 3GPP documents  have some examples that have this identifier in them but I could not find a description of how it worked. I'd also like to point out that in 2007 I asked for the pointer to the document that explains the GSMA allocation policy as you will eventually need that for IESG approval but the link in the draft is still wrong. Yes, I can figure out how to find the right one but is really too much to ask that someone could have fixed this. Again, none of things in this paragraph matter to me on the big topic of how to proceed but it's hard to put this on top of ones priority list when no one can bother to fix stuff that is clearly wrong.  

So let me be very clear on what I am looking for to start the interoperability discussion. We need to understand the specification for this to decide what interoperability problems there may or may not be. My assumptions how how this works may be very wrong. Lets get the facts and make an informed decision. 

Privacy

So what's the position of everyone that has been sending opinions of this draft. Is the IMEI of my phone personal identifying information or now? Sort of hard to have a discussion without deciding that first. 

IPR

On the topic of IPR. I think we need to sort out some of the simpler issues first and in the end I will probably rather have the IPR discussion on the ietf list than here. To put it pretty bluntly, the IETF list is a more favorable environment for the arguments I will probably make around IPR. It always fascinates me me to see the proponents of this draft sending nasty grams to the chairs telling them do something that process wise they can't do but would effectively move the conversation from the dispatch list to the ietf list while at the same time the ADs and Chairs are trying to resolve the conversation in dispatch first which is typically much less concerned about IPR than the IETF is in general.  I will note that Gonzalo thinks my drafts runs into the Andrews's patents but I have been working on the assumption that it does not as Andrew commented on it and did not file any IPR disclosure or notify the WG. 

On a finally note, I get the feeling that you think the chairs on not doing something they should. Obviously if there was anything that required making a call where the consensus was not obvious or anything I would leave that type of decision to Mary. I am participating in this conversation as one of the individuals in the WG and would leave any complex judgment call to Mary. If you think there is something where my individual opinions are causing the chairs not to do the right things, please, grab a phone and call me about it and we will figure out a way where everyone agrees the chairs are doing the right thing. I'm not a fan of the current passive aggressive approach. 

On Sep 20, 2011, at 1:51 PM, Worley, Dale R (Dale) wrote:

> Given that the decision to be made in this working group is whether to
> assign these I-Ds for further work to be done on them, there are a
> small number of questions in play (with assorted other issues to be
> addressed during the technical refinement of the proposal):
> 
> 1.  Does this proposal introduce any interoperability problems?
> 2.  Does this proposal present any privacy concerns?
> 3.  Does this proposal allow anyone to extract an unconscionable
>    "tax" (through the use of IPR)?
> 
> Here are my assessments of these issues:
> 
> 1.  Does this proposal introduce any interoperability problems?
> 
> I don't see what interoperability problems can result from the
> introduction of an additional format of URN, as long as the format
> adheres to the generic URN syntax.  RFC 5626 section 4.1 makes it
> clear that a SIP element may receive a +sip.instance value which is in
> a URN namespace that it does not recognize, so any properly
> constructed SIP element should be able to handle +sip.instance values
> in namespaces that it does not have prior knowledge of.
> 
> (Certainly, the one product/project that I have detailed knowledge of
> has always treated +sip.instance as a string.  Thereon hangs a tale:
> If the +sip.instance is a UUID-based URN, and if the UUID is based on
> a MAC address, the registrar extracts the MAC address so that the UA
> can be addressed through a special URI that encodes its MAC address.
> But it turns out that a popular make of UA formats its UUIDs
> incorrectly, so that it was not recognized as a MAC-based UUID.  We've
> had to add special code to the registrar to recognize this defective
> URN format!)
> 
> 2.  Does this proposal present any privacy concerns?
> 
> There would be general privacy concerns if this or any other
> +sip.instance value was present in dialog-forming requests or
> responses, and so could be seen by the other end of phone calls.  But
> as far as I can tell, no UA uses +sip.instance in INVITEs;
> +sip.instance values are presented only in REGISTER messages.
> 
> On the other hand, generated GRUU values are given in INVITEs, and the
> GRUU can give information about the UA's +sip.instance and the AOR,
> even if the GRUU is generated using a secret key.  However, the
> problems resulting from this seem to be essentially the same when the
> +sip.instance is derived from an IMEI as when it is derived from a MAC
> address.
> 
> In regard to registrations, given that the intended scope of
> application of the proposal is entirely within paid wireless networks,
> there can be no privacy between the UA and its registrar.
> 
> 3.  Does this proposal allow anyone to extract an unconscionable
>    "tax" (through the use of IPR)?
> 
> Though this proposal may be encumbered by IPR claims, the only users
> who would be *required* to use this URN format are products within the
> GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts this
> as mandatory-to-implement.  Those users might be subjected to an
> unconscionable tax, but the GSM/3GPP/IMS universe has its own
> political/economic structure for deciding what licensed technology is
> mandatory to implement and what licensing terms are considered
> acceptable.  It seems to me that we can justly leave these questions
> to GSM/3GPP/IMS.
> 
> There is some concern that the IPR disclosures were filed "late".
> However, as the latest IPR disclosure was filed in January 2011, the
> working group is now even later, and the objection has expired.
> 
> In summary, I don't see any of these issues as being particularly
> problematic.  If I've overlooked an important aspect of this, I would
> like to see some detailed information about it.
> 
> Dale
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Oct 2011 08:05:52 -0600

> which is claimed to "have BLF lights" that does *not* implement the

Huh ... I'm pretty confused Dale. I seem to recall  IETF has a RFC for using sub/nof for this that is widely implements and does not work that way. ( I do understand that Cisco implementations of it is a bit broken in that the NOTIFY are un solicited but it's still roughly the same ).

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Oct 2011 08:05:54 -0600

> be usable in our pure-proxy system.

Dale - they work fine for most people using proxy based systems. I do note in fact that pingtell claimed they worked with their system at one point.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Oct 2011 10:24:49 -0400

> Huh ... I'm pretty confused Dale. I seem to recall  IETF has a RFC for using sub/nof for this that is widely implements and does not work that way. ( I do understand that Cisco implementations of i…

I was questioning the assumption that any phone possessing a BLF "light" 
(or other indication) will have an end-user configuration option that 
associates an arbitrary URI with the light, and that then does a 
subscription to the dialog event package and derives a status for the 
light from the resulting notifications.

That gets well into areas of configuration that we don't standardize.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Oct 2011 08:36:41 -0600

> That gets well into areas of configuration that we don't standardize.

agree on that's config but even so, typically you want the BLF subscribed to AOR that is the same as the phones registers for. Hard to see how a MAC gets involved with BLF unless you have a really broken confusion between users and devices.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Oct 2011 11:46:58 -0400

> agree on that's config but even so, typically you want the BLF subscribed to AOR that is the same as the phones registers for. Hard to see how a MAC gets involved with BLF unless you have a really…

It makes some sense to derive BLF info by subscribing to the AOR being 
registered. And that doesn't require any manual configuration of the BLF 
at all.

But Dale was describing a technique his system uses that assigns a 
special AOR, based on MAC, that is used as the target of this subscription.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 25 Oct 2011 00:07:50 +0200

Responding on the blacklisting / whitelisting issue.

As far as I understand, the use of the IMEI to do this (blacklisting / whitelisting) happens on every cellphone already (be it according to 3GPP or 3GPP standards (where the IMEI is the MEID). 

The degree to which it occurs is as a result of regulatory pressure. Essentially the prime requirement is from law enforcement agencies who want to identify the use of stolen phones, and prevent those stolen phones having value, and from operators who want to prevent stolen phones incurring network costs for which they will never be reimbursed. For the existing non-IMS cellphones you will find the IMEI or MEID populating many messages including those that establish new calls.

For IMS phones the same IMEI / MEID is present in messages when you obtain the data channel, but as far as I understand operators want it in messages that get exchanged more frequently, and that means putting it in INVITE messages at the SIP layer.

So in conclusion, the usage in this respect is to lessen the incidence of someone coming up behind you, putting a knife in your ribs, and making off with your latest model of fancy cellphone. And for non-IMS usage its probably been doing that for the last 10 years (depending on when operators were pressured by law enforcement agencies to implement the EIR (the online database against which EIRs are checked).

Yes it will stop calls. Does someone whos stolen your phone have the right to make calls?

As regards IMEIs, it is associated with the hardware, not the software. The hardware manufacturer applies for them from some designated authority ultimately supervised by a joint group of GSMA and TIA/TTA. So you do not have the ability to craft your own. I believe the same applies to MAC addresses.

I believe the way it is used in 3GPP the IMEI is not visible to any other than the end user who owns the phone and the network. I do not believe it is seen by any other user (barring someone of course deliberately revealing it).

While there are various databases around that attempt to correlate IMEI values to a particular type of phone, these have all been reverse engineered by people plugging in the values in phones they have. You will need a sight more privileges to find the equivalent information from the official allocation database, and there is no intention to make it any more public.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings
> Sent: 24 October 2011 14:37
> To: Worley, Dale R (Dale)
> Cc: [email-masked] list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-
> dispatch-imei-urn-as-instanceid
> 
> 
> Dale - sent in my role as an individual contributor. (all my emails are in
> my role as an individual contributor unless they are clearly signed as
> some other role)
> 
> In the past I have made the mistake of listing all my concerns with this
> draft then one or two would get discussed for a bit and rest ignored so
> this time I'm going to try and stick with a few high level ones and some
> minor ones. We can try to resolve theses a bit then we can move on the
> others. Lets start with the stuff from your email.
> 
> Interoperability.
> 
> I've asked multiple people does this happen in INVITEs or just REGISTERs
> and got mixed answers. It makes a big difference - at some level this is a
> proposal to black list phones and / or part of a malware prevention
> systems. Or perhaps it is a proposal to white list phones and ones that
> don't have this won't work. You can say this going to be restricted to
> just the sets of people that want to use it but that is seldom how
> standards work out That might be true in the cases of if it only went from
> a phone to the domain for it's AOR. However, if this will also be used in
> INVITE cases, would it stop calls from any 3GPP phone to non 3GPP phone?
> Making sure that we did not have needless lack of interoperability between
> classic IETF SIP and 3GPP style SIP has always been a goal. Even if this
> is only only on IMS phones, theses are now used well outside the mobile
> environment - we see them used on wireline and enterprise environments so
> would there be a problem from other SIP devices
>  to theses. Could a soft phone get the required IMEI identifier so it was
> not blacklisted? Could a small vendor get them? These are all things I
> wonder.
> 
> It's impossible to answer any of the above questions without knowing
> something about how this blacklisting stuff works and what this identifier
> is used for. This leads to my first issues. I want a description of how
> this works so we can decide if there are interoperability problems or not.
> I am constantly told this is important to 3GPP yet I can't find a 3GPP
> document that even has a reference to this draft or explains how it works.
> So this is my most important question to you -  Do you think this is
> unreasonable that we should ask how this works and if there are
> interoperability problems? If this is important to 3GPP, could they
> provide a pointer to a document that has reference to it and defines how
> it is used.
> 
> On a minor notes related to references - I'm not objecting based on
> process crap around the references but it would be really really nice if
> the drafts could be updated so that the reference pointed at a specific
> document - not a vague family of documents where I have no idea if I am
> reading the right one or not. I never know what to read when I see 3GPP
> 24.237 but if you gave me a date and version, or even a link, it would be
> easier. A reference should be something where we both know we are reading
> the same document. I realize the 3GPP documents  have some examples that
> have this identifier in them but I could not find a description of how it
> worked. I'd also like to point out that in 2007 I asked for the pointer to
> the document that explains the GSMA allocation policy as you will
> eventually need that for IESG approval but the link in the draft is still
> wrong. Yes, I can figure out how to find the right one but is really too
> much to ask that someone could have fixed this. Ag
>  ain, none of things in this paragraph matter to me on the big topic of
> how to proceed but it's hard to put this on top of ones priority list when
> no one can bother to fix stuff that is clearly wrong.
> 
> So let me be very clear on what I am looking for to start the
> interoperability discussion. We need to understand the specification for
> this to decide what interoperability problems there may or may not be. My
> assumptions how how this works may be very wrong. Lets get the facts and
> make an informed decision.
> 
> 
> Privacy
> 
> So what's the position of everyone that has been sending opinions of this
> draft. Is the IMEI of my phone personal identifying information or now?
> Sort of hard to have a discussion without deciding that first.
> 
> 
> IPR
> 
> On the topic of IPR. I think we need to sort out some of the simpler
> issues first and in the end I will probably rather have the IPR discussion
> on the ietf list than here. To put it pretty bluntly, the IETF list is a
> more favorable environment for the arguments I will probably make around
> IPR. It always fascinates me me to see the proponents of this draft
> sending nasty grams to the chairs telling them do something that process
> wise they can't do but would effectively move the conversation from the
> dispatch list to the ietf list while at the same time the ADs and Chairs
> are trying to resolve the conversation in dispatch first which is
> typically much less concerned about IPR than the IETF is in general.  I
> will note that Gonzalo thinks my drafts runs into the Andrews's patents
> but I have been working on the assumption that it does not as Andrew
> commented on it and did not file any IPR disclosure or notify the WG.
> 
> 
> On a finally note, I get the feeling that you think the chairs on not
> doing something they should. Obviously if there was anything that required
> making a call where the consensus was not obvious or anything I would
> leave that type of decision to Mary. I am participating in this
> conversation as one of the individuals in the WG and would leave any
> complex judgment call to Mary. If you think there is something where my
> individual opinions are causing the chairs not to do the right things,
> please, grab a phone and call me about it and we will figure out a way
> where everyone agrees the chairs are doing the right thing. I'm not a fan
> of the current passive aggressive approach.
> 
> 
>

---

From: Andrew Allen <[email-masked]>
Date: Mon, 24 Oct 2011 22:59:11 +0000

Just to add to and correct some of Keith's comments.

> As far as I understand, the use of the IMEI to do this (blacklisting /
> whitelisting) happens on every cellphone already (be it according to 3GPP
> or 3GPP standards (where the IMEI is the MEID).

Should be "according to 3GPP or 3GPP2 standards"

One other correction/clarification is that:

According to 3GPP TS 24.229 the Instance ID is not normally placed in SIP INVITE requests or responses to INVITE for the purposes of telephony calls. The exception to this is Emergency calls when the Instance ID containing the IMEI is placed in the Contact header field of the SIP INVITE request. Other bodies (such as OMA for push to talk) may have specified including the instance ID in SIP INVITE request but (as specified in 3GPP specifications that if this is included this is to be done) the Instance ID is removed by an intermediate server (e.g the PoC Server).

Whitelist/Blacklist checking can be done based on the Instance ID containing the IMEI being included in the SIP REGISTER request (as I have indicated in a previous email)

But basically I agree with the rest of Keith's comments

Andrew

> Behalf Of DRAGE, Keith (Keith)
> Sent: Monday, October 24, 2011 5:08 PM
> To: Cullen Jennings; Worley, Dale R (Dale)
> As far as I understand, the use of the IMEI to do this (blacklisting /
> whitelisting) happens on every cellphone already (be it according to 3GPP
> or 3GPP standards (where the IMEI is the MEID).
> 
> The degree to which it occurs is as a result of regulatory pressure.
> Essentially the prime requirement is from law enforcement agencies who
> want to identify the use of stolen phones, and prevent those stolen phones
> having value, and from operators who want to prevent stolen phones
> incurring network costs for which they will never be reimbursed. For the
> existing non-IMS cellphones you will find the IMEI or MEID populating many
> messages including those that establish new calls.
> 
> For IMS phones the same IMEI / MEID is present in messages when you obtain
> the data channel, but as far as I understand operators want it in messages
> that get exchanged more frequently, and that means putting it in INVITE
> messages at the SIP layer.
> 
> So in conclusion, the usage in this respect is to lessen the incidence of
> someone coming up behind you, putting a knife in your ribs, and making off
> with your latest model of fancy cellphone. And for non-IMS usage its
> probably been doing that for the last 10 years (depending on when
> operators were pressured by law enforcement agencies to implement the EIR
> (the online database against which EIRs are checked).
> 
> As regards IMEIs, it is associated with the hardware, not the software.
> The hardware manufacturer applies for them from some designated authority
> ultimately supervised by a joint group of GSMA and TIA/TTA. So you do not
> have the ability to craft your own. I believe the same applies to MAC
> addresses.
> 
> I believe the way it is used in 3GPP the IMEI is not visible to any other
> than the end user who owns the phone and the network. I do not believe it
> is seen by any other user (barring someone of course deliberately
> revealing it).
> 
> While there are various databases around that attempt to correlate IMEI
> values to a particular type of phone, these have all been reverse
> engineered by people plugging in the values in phones they have. You will
> need a sight more privileges to find the equivalent information from the
> official allocation database, and there is no intention to make it any
> more public.
> 
> Regards
> 
> Keith
> 

---------------------------------------------------------------------
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: Cullen Jennings <[email-masked]>
Date: Mon, 24 Oct 2011 20:59:12 -0600

On Oct 24, 2011, at 4:59 PM, Andrew Allen wrote:

> According to 3GPP TS 24.229 the Instance ID is not normally placed in SIP INVITE requests or responses to INVITE for the purposes of telephony calls.

So I looked at lasted version I could find of this and it actually does talk about IMEI. Which version of this is the right one to be reading?

> The exception to this is Emergency calls when the Instance ID containing the IMEI is placed in the Contact header field of the SIP INVITE request.

I assume it is in emergency call because un registered phones can make emergency call ? 

> Other bodies (such as OMA for push to talk) may have specified including the instance ID in SIP INVITE request but (as specified in 3GPP specifications that if this is included this is to be done) the Instance ID is removed by an intermediate server (e.g the PoC Server).
> 

Writing up the draft to talk about using this in a contact header to say when a UA puts it in or not, and when B2BUA & Proxies remove it, would really help people understand what the implications are.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Oct 2011 21:24:57 -0600

Thanks Keith - that is good information.

> So in conclusion, the usage in this respect is to lessen the incidence of someone coming up behind you, putting a knife in your ribs, and making off with your latest model of fancy cellphone. And f…

So for phones that are an expensive mobile + a cheap sim card, it seems like an identifier attached to the expensive part not the cheap part would work best. Thoughts?

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Oct 2011 07:36:04 +0000

> So for phones that are an expensive mobile + a cheap sim card, it seems like an identifier attached to the expensive part not the cheap part would work best. Thoughts?

The IMEI *is* attached to the expensive part.  It's not in the SIM - it's in the phone.  If you have a GSM phone, you can probably see it on a sticker under the battery, and its stuck to your phone not SIM.  Some have more than one I think, because it's technically tied to the wireless transceiver so I think dual-band phones have two.  But either way it represents your phone hardware, not your user identity, afaik.  It's a lot like a MAC address, except you're not supposed to be able to change the IMEI.

And yes it really was created to detect stolen phones.  I don't know if stolen phones are allowed to make emergency calls (and that would be nationally-specific regulation anyway); but in many countries un-registered phones are allowed to make emergency calls, so in that case they won't get a SIP REGISTER to indicate the IMEI, ergo they need it in an INVITE.

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 25 Oct 2011 11:59:52 +0200

There still seems to be some confusion here so just to clarify.

The IMEI (or MEID) is an integral part of the hardware of a cellphone. You cannot buy one without at least the encoding for it, and in many, if not most, jurisdictions, you will not be able to use phone without one. There are still phones being sold in some countries that have fraudulent IMEIs. The main example is India, where such phones are increasingly being rendered inoperable by the operators based on regulatory and peer operator pressure. EI in both acronyms stands for equipment identifier. The phone is manufactured with its own unique value, and the phone manufacturer goes to the administration body and gets a set of unique values for the phones it is manufacturing.

This is the identifier we are talking about being used in an instance ID generated by a cellphone.

When you go to an operator and buy a subscription to cellphone service, you will get a UICC (in earlier 3GPP releases known as a SIM card, and in 3GPP2 known as a R-UIM, and in many earlier 3GPP2 phones some logical space in the phone memory with only the operator has access to).

There is an identity associated with this subscription, but that is called an IMSI. That identity may also be mapped into identities used at IMS (SIP) level, where it is known as the private user identity and public user identity, or the operator can assign other unique values to represent these. This is the value(s) that is stored on the UICC. These values appear in various header fields such as the From, P-Preferred, and as a parameter in Authorization.

An IMEI is not stored on the UICC.

So in conclusion, the IMEI is tied to the expensive part, i.e. the cellphone, not to the cheap part, the UICC.

Regards

Keith

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: 25 October 2011 04:25
> To: DRAGE, Keith (Keith)
> Cc: Worley, Dale R (Dale); [email-masked] list
> > For IMS phones the same IMEI / MEID is present in messages when you
> obtain the data channel, but as far as I understand operators want it in
> messages that get exchanged more frequently, and that means putting it in
> INVITE messages at the SIP layer.
> >
> > So in conclusion, the usage in this respect is to lessen the incidence
> of someone coming up behind you, putting a knife in your ribs, and making
> off with your latest model of fancy cellphone. And for non-IMS usage its
> So for phones that are an expensive mobile + a cheap sim card, it seems
> like an identifier attached to the expensive part not the cheap part would
> work best. Thoughts?
>
> >
> > I believe the way it is used in 3GPP the IMEI is not visible to any
> other than the end user who owns the phone and the network. I do not
> believe it is seen by any other user (barring someone of course
> deliberately revealing it).
> >

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 25 Oct 2011 12:08:40 +0200

Hadriel wrote:

> sticker under the battery, and its stuck to your phone not SIM.  Some have
> more than one I think, because it's technically tied to the wireless
> transceiver so I think dual-band phones have two.  But either way it

Phones supporting 3GPP and 3GPP2 standards have only one. The IMEI / MEID is 15 characters of either decimal or hexadecimal numbers that do not overlap. The first two characters represent the allocation authority, and for 3GPP2 only phones the allocation authority (primarily TIA in this case) the first characters will be hexadecimal and the remainder the characters are read as if they were hexadecimal.

3GPP only phones use only decimal characters, with the first two digits being decimal. 

Dual mode phones covering both standards have an IMEI for 3GPP use, which same value is also used as an MEID in 3GPP2 usage.

Note that this is specifically cell phone technology. Where one of the modes is wireless LAN (where the WLAN is not tied to a specific cellphone operator as in I-WLAN) the IMEI / MEID does not apply.

Regards

Keith

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: 25 October 2011 08:36
> To: Cullen Jennings
> Cc: DRAGE, Keith (Keith); [email-masked] list
> The IMEI *is* attached to the expensive part.  It's not in the SIM - it's
> in the phone.  If you have a GSM phone, you can probably see it on a
> sticker under the battery, and its stuck to your phone not SIM.  Some have
> more than one I think, because it's technically tied to the wireless
> transceiver so I think dual-band phones have two.  But either way it
> represents your phone hardware, not your user identity, afaik.  It's a lot
> like a MAC address, except you're not supposed to be able to change the
> IMEI.
> 
> And yes it really was created to detect stolen phones.  I don't know if
> stolen phones are allowed to make emergency calls (and that would be
> nationally-specific regulation anyway); but in many countries un-
> registered phones are allowed to make emergency calls, so in that case
> they won't get a SIP REGISTER to indicate the IMEI, ergo they need it in
> an INVITE.
> 
> -hadriel

---

From: Atle Monrad <[email-masked]>
Date: Tue, 25 Oct 2011 12:55:44 +0200

Cullen, Adam, all

Keith has already given some good information on how the IMEI is used within 3GPP. Some few additions though

This functionality has been part of GSM since GSM phase_1 in the early 90s. Archeologists can find such information at http://www.3gpp.org/ftp/Specs/html-info/0216.htm while more up-to-date people interested in 3GPP may find the (more or less) same service requirements at http://www.3gpp.org/ftp/Specs/html-info/22016.htm. As the equipment identity register and its functionality is from the early days of the specification of mobile systems, it is not described as extensive as some recently added features. I hope that the discussions can continue based on this. To discuss and question these old and long-time-existing requirements from persons outside of 3GPP seems unnecessary and will not be too productive. I add Dan Warren who might clarify the requirements from the GSMA point of view.

On referencing, I assume that people interested in a feature will need to read the documentation in its context. If the context is 3GPP, the way 3GPP reference its specifications in its releases needs to be known by these persons. It might of course be useful for external reviewers to understand this, but I see this to be more of an exercise for the reviewers and cannot really be held against the draft itself. Mistakes must obviously be fixed and some additions might be needed in the draft though. Note also that TS 24.229 and TS 23.003 reference the montemurro-draft since 3GPP Release 8.

I would also like to add that as I see it, a number of people with 3GPP-knowledge would like to progress the draft with their +1, while Cullen raise a number of questions admitting that he don't know the background and the functionality of the feature. Based on this I am not really sure who give the most relevant technical comments... People without concerns shouldn't need to invent issues? Having said that, if there are some concerns over specific (or lack of) existing text, I am sure that this can be clarified.

At last, whether the UICC or the handset is cheapest is also a side-track. There are procedures to block/bar the subscription (the complete subscription or particular identified SIMs/UICCs of the subscriber) and there are other procedures to block/bar the equipment (identified by the IMEI). This draft is for the latter. That operators heavily subsidising handsets need to justify the need for such a functionality is a surprise to me.

/atle

________________________________

Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: 25. oktober 2011 00:08
To: Cullen Jennings; Worley, Dale R (Dale)
Cc: [email-masked] list
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid

Regards

Keith

> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and
> draft-allen- dispatch-imei-urn-as-instanceid
>
>
> Dale - sent in my role as an individual contributor. (all my emails
> are in my role as an individual contributor unless they are clearly
> signed as some other role)
>
> In the past I have made the mistake of listing all my concerns with
> this draft then one or two would get discussed for a bit and rest
> ignored so this time I'm going to try and stick with a few high level
> ones and some minor ones. We can try to resolve theses a bit then we
> can move on the others. Lets start with the stuff from your email.
>
> Interoperability.
>
> I've asked multiple people does this happen in INVITEs or just
> REGISTERs and got mixed answers. It makes a big difference - at some
> level this is a proposal to black list phones and / or part of a
> malware prevention systems. Or perhaps it is a proposal to white list
> phones and ones that don't have this won't work. You can say this
> going to be restricted to just the sets of people that want to use it
> but that is seldom how standards work out That might be true in the
> cases of if it only went from a phone to the domain for it's AOR.
> However, if this will also be used in INVITE cases, would it stop calls from any 3GPP phone to non 3GPP phone?
> Making sure that we did not have needless lack of interoperability
> between classic IETF SIP and 3GPP style SIP has always been a goal.
> Even if this is only only on IMS phones, theses are now used well
> outside the mobile environment - we see them used on wireline and
> enterprise environments so would there be a problem from other SIP
> devices  to theses. Could a soft phone get the required IMEI
> identifier so it was not blacklisted? Could a small vendor get them?
> These are all things I wonder.
>
> something about how this blacklisting stuff works and what this
> identifier is used for. This leads to my first issues. I want a
> description of how this works so we can decide if there are interoperability problems or not.
> provide a pointer to a document that has reference to it and defines
> how it is used.
>
> process crap around the references but it would be really really nice
> if the drafts could be updated so that the reference pointed at a
> specific document - not a vague family of documents where I have no
> idea if I am reading the right one or not. I never know what to read
> when I see 3GPP
> 24.237 but if you gave me a date and version, or even a link, it would
> be easier. A reference should be something where we both know we are
> reading the same document. I realize the 3GPP documents  have some
> examples that have this identifier in them but I could not find a
> description of how it worked. I'd also like to point out that in 2007
> I asked for the pointer to the document that explains the GSMA
> allocation policy as you will eventually need that for IESG approval
> but the link in the draft is still wrong. Yes, I can figure out how to
> find the right one but is really too much to ask that someone could
> have fixed this. Ag  ain, none of things in this paragraph matter to
> me on the big topic of how to proceed but it's hard to put this on top
> of ones priority list when no one can bother to fix stuff that is clearly wrong.
>
> interoperability discussion. We need to understand the specification
> for this to decide what interoperability problems there may or may not
> be. My assumptions how how this works may be very wrong. Lets get the
> facts and make an informed decision.
>
>
> Privacy
>
> So what's the position of everyone that has been sending opinions of
> this draft. Is the IMEI of my phone personal identifying information or now?
> issues first and in the end I will probably rather have the IPR
> discussion on the ietf list than here. To put it pretty bluntly, the
> IETF list is a more favorable environment for the arguments I will
> probably make around IPR. It always fascinates me me to see the
> proponents of this draft sending nasty grams to the chairs telling
> them do something that process wise they can't do but would
> effectively move the conversation from the dispatch list to the ietf
> list while at the same time the ADs and Chairs are trying to resolve
> the conversation in dispatch first which is typically much less
> concerned about IPR than the IETF is in general.  I will note that
> Gonzalo thinks my drafts runs into the Andrews's patents but I have
> been working on the assumption that it does not as Andrew commented on it and did not file any IPR disclosure or notify the WG.
>
>
> doing something they should. Obviously if there was anything that
> required making a call where the consensus was not obvious or anything
> I would leave that type of decision to Mary. I am participating in
> this conversation as one of the individuals in the WG and would leave
> any complex judgment call to Mary. If you think there is something
> where my individual opinions are causing the chairs not to do the
> right things, please, grab a phone and call me about it and we will
> figure out a way where everyone agrees the chairs are doing the right
> thing. I'm not a fan of the current passive aggressive approach.
>
>
>
> > Given that the decision to be made in this working group is whether
> > to assign these I-Ds for further work to be done on them, there are
> > a small number of questions in play (with assorted other issues to
> > be addressed during the technical refinement of the proposal):
> >
> > clear that a SIP element may receive a +sip.instance value which is
> > in a URN namespace that it does not recognize, so any properly
> > constructed SIP element should be able to handle +sip.instance
> > values in namespaces that it does not have prior knowledge of.
> >
> > (Certainly, the one product/project that I have detailed knowledge
> > of has always treated +sip.instance as a string.  Thereon hangs a tale:
> > If the +sip.instance is a UUID-based URN, and if the UUID is based
> > on a MAC address, the registrar extracts the MAC address so that the
> > UA can be addressed through a special URI that encodes its MAC address.
> > incorrectly, so that it was not recognized as a MAC-based UUID.
> > We've had to add special code to the registrar to recognize this
> > defective URN format!)
> >
> > responses, and so could be seen by the other end of phone calls.
> > But as far as I can tell, no UA uses +sip.instance in INVITEs;
> > On the other hand, generated GRUU values are given in INVITEs, and
> > the GRUU can give information about the UA's +sip.instance and the
> > AOR, even if the GRUU is generated using a secret key.  However, the
> > +sip.instance is derived from an IMEI as when it is derived from a
> > +MAC
> > address.
> >
> > application of the proposal is entirely within paid wireless
> > networks, there can be no privacy between the UA and its registrar.
> >
> > who would be *required* to use this URN format are products within
> > the GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS
> > adopts this as mandatory-to-implement.  Those users might be
> > subjected to an unconscionable tax, but the GSM/3GPP/IMS universe
> > has its own political/economic structure for deciding what licensed
> > technology is mandatory to implement and what licensing terms are
> > considered acceptable.  It seems to me that we can justly leave
> > these questions to GSM/3GPP/IMS.
> >
> > problematic.  If I've overlooked an important aspect of this, I
> > would like to see some detailed information about it.
> >
> > Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 25 Oct 2011 15:39:39 +0200

> So I looked at lasted version I could find of this and it actually does
> talk about IMEI. Which version of this is the right one to be reading?
>
3GPP is divided into releases, each of which supposedly encompasses a valid set of features. In general features introduced in release x are also included in release x+1.

Within releases, specs are updated, not to add new functionality, but to correct errors that may result in some catastrophic failure of a feature.

So the answer to the question above is the latest version of all releases from which the feature was introduced, where the release is identified by the first digit of the triple x.y.z.

I believe this particular capability was introduced from release 8.

The text should be compatible in all releases, so looking at the latest version of the latest release (11.1.0) should be sufficient.

Regards

Keith

> Sent: 25 October 2011 03:59
> To: Andrew Allen
> Cc: DRAGE, Keith (Keith); Worley, Dale R (Dale); [email-masked]
> > According to 3GPP TS 24.229 the Instance ID is not normally placed in
> SIP INVITE requests or responses to INVITE for the purposes of telephony
> calls.
>
> So I looked at lasted version I could find of this and it actually does
> talk about IMEI. Which version of this is the right one to be reading?
>
>
> > The exception to this is Emergency calls when the Instance ID containing
> the IMEI is placed in the Contact header field of the SIP INVITE request.
>
> > Other bodies (such as OMA for push to talk) may have specified including
> the instance ID in SIP INVITE request but (as specified in 3GPP
> specifications that if this is included this is to be done) the Instance
> ID is removed by an intermediate server (e.g the PoC Server).
> >
> > Whitelist/Blacklist checking can be done based on the Instance ID
> containing the IMEI being included in the SIP REGISTER request (as I have
> indicated in a previous email)
>
>
> Writing up the draft to talk about using this in a contact header to say
> when a UA puts it in or not, and when B2BUA & Proxies remove it, would
> really help people understand what the implications are.
>
> >
> obtain
> of
> > > Yes it will stop calls. Does someone whos stolen your phone have the
> right
> > > to make calls?
> > >
> other
> are
> > > in
> this
> REGISTERs
> > > > and got mixed answers. It makes a big difference - at some level
> this is
> > > a
> > > > standards work out That might be true in the cases of if it only
> went
> > > from
> > > > a phone to the domain for it's AOR. However, if this will also be
> used
> > > in
> > > between
> > > > environment - we see them used on wireline and enterprise
> environments
> > > so
> > > >  to theses. Could a soft phone get the required IMEI identifier so
> it
> > > was
> > > identifier
> > > > this works so we can decide if there are interoperability problems
> or
> > > not.
> how
> > > be
> > > > have this identifier in them but I could not find a description of
> how
> > > it
> > > > worked. I'd also like to point out that in 2007 I asked for the
> pointer
> > > to
> > > > how to proceed but it's hard to put this on top of ones priority
> list
> > > when
> for
> > > > this to decide what interoperability problems there may or may not
> be.
> > > My
> > > this
> > > discussion
> > > required
> > > > where everyone agrees the chairs are doing the right thing. I'm not
> a
> > > fan
> values
> of
> on
> We've
> But
> the
> MAC
> networks,
> the
> would
> > 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: Adam Roach <[email-masked]>
Date: Tue, 25 Oct 2011 10:10:52 -0500

> I believe the way it is used in 3GPP the IMEI is not visible to any other than the end user who owns the phone and the network. I do not believe it is seen by any other user (barring someone of cou…

That's the real concern. If what you say is true, then I agree that 
there is no problem. Also, if what you say is true, there is certainly 
no harm in including that fact as an important security property in the 
document itself.

In the spirit of "send text," I would propose extending the first 
paragraph of the "Security Considerations" section in 
draft-montemurro-gsma-imei-uri by adding:

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

The other major outstanding issue is interoperability. The main issue, I 
believe, is whether you will end up with systems that only accept IMEI 
URNs when use of the protocol in a broader context requires the use of 
general URNs or even URIs.

The "Community considerations" section of draft-montemurro-gsma-imei-uri 
currently deals exclusively with the ability for general-purpose 
Internet implementations to deal with 3GPP-specific identifiers. We need 
text that addresses the complementary issue of 3GPP implementations 
dealing with general-purpose Internet identifiers.

I would propose adding text to the end of this section, along the lines of:

     Conversely, Internet implementations will not generally posses
     IMEI identifiers. The identifiers generated by such implementations
     will typically be URNs within namespaces other than "gsma," and
     may, depending on context, even be non-URN URIs. Implementations
     are advised to correctly process URIs other than "gsma"-namespaced
     URNs, so as to aid in interoperability.

/a

---

From: Andrew Allen <[email-masked]>
Date: Tue, 25 Oct 2011 15:20:41 +0000

Adam

We are quite happy to add the text you propose. I think this text is perfectly aligned with the current 3GPP usage. 

Do you however agree that this text would be better in the draft-allen-dispatch-imei-urn-as-instanceid which specified the usage of the IMEI URN in SIP rather than in the draft-montemurro-gsma-imei-urn which only defines the URN.

Andrew

> Behalf Of Adam Roach
> Sent: Tuesday, October 25, 2011 10:11 AM
> To: DRAGE, Keith (Keith)

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 Oct 2011 14:15:51 -0500

> Do you however agree that this text would be better in the draft-allen-dispatch-imei-urn-as-instanceid which specified the usage of the IMEI URN in SIP rather than in the draft-montemurro-gsma-imei…

As far as my memory goes, instance IDs in normal usage only go between a 
UE and its registrar. The privacy issue doesn't arise in this case. So 
the note about not transmitting IMEIs in purportedly anonymous messages 
wouldn't make much sense there. Right? Or am I forgetting about some use 
of instance IDs that can make it to another user?

As far as interop goes, this does apply to the instance ID case, but it 
*also* applies to every other situation in which one might think of 
using an IMEI URN. It would seem to address the situation more broadly 
to put the interop discussion in the URN draft, then.

Is there some reason you would prefer one document over the other?

/a

---

From: Atle Monrad <[email-masked]>
Date: Wed, 26 Oct 2011 11:44:19 +0200

Adam

Thanks for concrete and constructive proposals.

I have no strong preference for in which draft to place the added text.

You proposed text start off with "IMEIs can generally be correlated to a user" ... IMEI SHOULD NOT ...   "IMEIs can loosely be correlated to a user" ... IMEI SHOULD NOT ...

I think I would have used the same phrase throughout, and IMHO, the "loosely correlated" is the better of the two. As the subscription is decoupled from the physical handset in 3GPP, it is just a educated assumption that the handset will be used by the same subscriber all the time ;-)

my 2 cents for now
cheers
/atle

Atle Monrad
3GPP CT Chairman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 25. oktober 2011 17:21
To: Adam Roach; DRAGE, Keith (Keith)
Cc: [email-masked] list; Michael Montemurro
Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and draft-allen-dispatch-imei-urn-as-instanceid

Adam

Andrew

> no harm in including that fact as an important security property in 
> the document itself.
> 
> The other major outstanding issue is interoperability. The main issue, 
> I believe, is whether you will end up with systems that only accept 
> IMEI URNs when use of the protocol in a broader context requires the 
> use of general URNs or even URIs.
> 
> The "Community considerations" section of 
> draft-montemurro-gsma-imei-uri currently deals exclusively with the 
> ability for general-purpose Internet implementations to deal with 
> 3GPP-specific identifiers. We need text that addresses the 
> complementary issue of 3GPP implementations dealing with general-purpose Internet identifiers.
> 
> I would propose adding text to the end of this section, along the 
> lines
> of:
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 26 Oct 2011 13:05:42 +0200

>      URNs, so as to aid in interoperability.

And what "correctly process" means.

Generally in IMS all instance IDs in all forms will be correctly processed - all that is required for operation is that it is a unique identifier. However if you have an IMEI you are supposed to use it, and if you have accessed over a 3GPP access technology where you would have been required to provide one and the same IMEI, you should not change horses in midstream and decide at the SIP level that the equipment has a different identifier.

The end result is that if you use IMEI at the access transport level, and then fail to use IMEI at the SIP level, the instance ID may have been correctly processed, but you may be denied service at some point from then on based on EIR checks.

Keith

> From: Adam Roach [mailto:[email-masked]]
> Sent: 25 October 2011 16:11
> To: DRAGE, Keith (Keith)
> Cc: Cullen Jennings; Worley, Dale R (Dale); [email-masked] list

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Oct 2011 06:44:20 -0500

On Oct 26, 2011, at 4:44, Atle Monrad <[email-masked]> wrote:

> I think I would have used the same phrase throughout, and IMHO, the "loosely correlated" is the better of the two.

Whoops... I had edited the text several times, and somehow managed to paste in the final and second-to-final versions right next to each other. "Loosely" was the version I meant to include. 

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2011 10:04:01 -0400

> The end result is that if you use IMEI at the access transport level, and then fail to use IMEI at the SIP level, the instance ID may have been correctly processed, but you may be denied service at…

IIUC, you are saying:

- when connected over an IMS transport (which is tied to an IMEI)
   a device clearly *has* an IMEI, and is expected to use an
   instance id containing it.

- when connected over a non-IMS transport (which is the only
   option for a non-IMS device), another form of instance id will
   be ok.

Do I have that right?

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 26 Oct 2011 14:41:55 -0400

> From: Cullen Jennings [[email-masked]]

[Cullen's paragraphs re-ordered]

> [...]   I get the feeling that you think the chairs on not
> doing something they should.  [...]
> If you think there is something where my individual opinions
> are causing the chairs not to do the right things, please, grab a
> phone and call me about it and we will figure out a way where everyone
> agrees the chairs are doing the right thing. I'm not a fan of the
> current passive aggressive approach.

I've been trying to be as un-passive as possible, though my day job
has gotten in the way.  (Somehow my boss thinks I shouldn't devote
100% of my time to the IETF!)  I've sent two messages "formally
requesting" action (msg03768.html, msg03833.html).  I do feel that the
chairs have not been taking action in the face of a solid consensus.
If I am correct, it's a matter for the entire WG to consider.

Though, I may be entirely mistaken as to whether the chairs are in a
position to do anything at all, which would be rather ironic.  I've
got to check that out.

> REGISTERs and got mixed answers.

It looks like (msg03902.html), in the 3GPP world, phones have to
present a sip.instance URN in some INVITEs, but that's a constraint on
life in 3GPP, not a general constraint on SIP.  It also appears that
the sip.instance is stripped from the INVITEs before it reaches any
other UA.

In addition, as long as a sip.instance URN is unique to the phone, it
presents essentially the same privacy considerations -- excepting if a
"receiver" of the URN has a database providing more owner information
about URNs.  So replacing an IMEI-based URN with a MAC-based URN does
not improve privacy at all.  (Presumably any 3GPP database containing
IMEIs of phones could easily include their MACs as well.)

*If* a network enforces a restriction that a UA present a sip.instance
URN in INVITEs, that has interesting privacy considerations, and
should be documented for the edification of the masses, *but* I can
see no reason that defining a new URN scheme will increase or decrease
any privacy concern.

To repeat from my message of 20 Sept. (msg03779.html):
- However, the problems resulting from this seem to be essentially the
- same when the +sip.instance is derived from an IMEI as when it is
- derived from a MAC address.

> It makes a big difference - at some
> cases of if it only went from a phone to the domain for it's
> AOR. However, if this will also be used in INVITE cases, would it stop
> calls from any 3GPP phone to non 3GPP phone? Making sure that we did
> not have needless lack of interoperability between classic IETF SIP
> and 3GPP style SIP has always been a goal. Even if this is only only
> on IMS phones, theses are now used well outside the mobile environment
> - we see them used on wireline and enterprise environments so would
> there be a problem from other SIP devices to theses. Could a soft
> phone get the required IMEI identifier so it was not blacklisted?
> Could a small vendor get them? These are all things I wonder.

I'm having trouble following you here.  But it seems to me that if a
*any* service provider wants to whitelist or blacklist phones based on
any particular characteristic or for any particular type of service,
it won't be hard for them to do so.  And anyone who wants to
whitelist/blacklist will do so by maintaining a database of
identifiers.  Preventing any particular *type* of identifier from
being used isn't going to stop anyone.

To repeat from my message of 20 Sept. (msg03779.html):
- However, the problems resulting from this seem to be essentially the
- same when the +sip.instance is derived from an IMEI as when it is
- derived from a MAC address.

> identifier is used for.  [...]

It doesn't seem to me that any of those questions need answering by us
at this time:  In practice, any service provider can be as restrictive
about usage as it is willing to expend the effort to enforce.

> So this is my most
> important question to you - Do you think this is unreasonable that we
> should ask how this works and if there are interoperability problems?

Well, I'm not exactly sure what you mean by the "this" that works, but
I haven't seen any reason to believe that we need to know how "this"
works, in that "this" and its potential problems are essentially
independent of the sip.instance *scheme*, and is probably confined
entirely to particular walled-gardens.

> when I see 3GPP 24.237 but if you gave me a date and version, or even
> a link, it would be easier.

A valid point, although I find that if I feed "3GPP 24.237" into
Google, the top hit is
http://www.3gpp.org/ftp/Specs/html-info/24237.htm, which leads to a
page titled "IP Multimedia (IM) Core Network (CN) subsystem IP
Multimedia Subsystem (IMS) service continuity; Stage 3" with a bunch
of download links.  It looks like the documents require registration
to download, but are free-of-charge.  So I think the references can be
cleaned up at the editorial stage.

> facts and make an informed decision.

I can't imagine how the URN *scheme* that 3GPP prefers to use is going
to make any significant difference in interoperability with UAs
outside the 3GPP access network.

> this draft. Is the IMEI of my phone personal identifying information
> or now? Sort of hard to have a discussion without deciding that first.

The IMEI is undoubtedly personal identifying information to the same
degree that the MAC address is.  Indeed, any sip.instance URN is
supposed to be unique to a particular UA, and so constitutes personal
identifying information.  Creating a new URN scheme for IMEIs isn't
going to change the privacy situation.

To repeat from my message of 20 Sept. (msg03779.html):
- However, the problems resulting from this seem to be essentially the
- same when the +sip.instance is derived from an IMEI as when it is
- derived from a MAC address.

> been working on the assumption that it does not as Andrew commented on
> it and did not file any IPR disclosure or notify the WG.

When you get around to formulating an objection, we can talk about it.

But as far as I can tell, any URI problems will be confined to the
3GPP walled garden, and they already have a system for dealing with
it.

To repeat from my message of 20 Sept. (msg03779.html):
- Though this proposal may be encumbered by IPR claims, the only users
- who would be *required* to use this URN format are products within the
- GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts this
- as mandatory-to-implement.  Those users might be subjected to an
- unconscionable tax, but the GSM/3GPP/IMS universe has its own
- political/economic structure for deciding what licensed technology is
- mandatory to implement and what licensing terms are considered
- acceptable.  It seems to me that we can justly leave these questions
- to GSM/3GPP/IMS.

So, at this point, I don't think we've identified any serious problems
that need to be investigated realtive to advancing the definition of
an IMEI-based URN.

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 26 Oct 2011 21:10:21 +0200

Not quite.

IMS supports a number of access technologies, some of them 3GPP specific and some not (e.g. TISPAN, Cablelabs)

When using a 3GPP access technology, you will have had to use an IMEI, and you are expected to continue to use to in IMS SIP when accessing over that 3GPP access technology.

For a non-3GPP access technology, you will probably not have an IMEI, and the general rules specified by IETF for instance IDs apply, i.e. use some appropriate unique identifier.

Keith

> Behalf Of Paul Kyzivat
> Sent: 26 October 2011 15:04
> To: [email-masked]
> > Generally in IMS all instance IDs in all forms will be correctly
> processed - all that is required for operation is that it is a unique
> identifier. However if you have an IMEI you are supposed to use it, and if
> you have accessed over a 3GPP access technology where you would have been
> required to provide one and the same IMEI, you should not change horses in
> midstream and decide at the SIP level that the equipment has a different
> identifier.
> >
> > The end result is that if you use IMEI at the access transport level,
> and then fail to use IMEI at the SIP level, the instance ID may have been
> correctly processed, but you may be denied service at some point from then
> on based on EIR checks.
> 
> IIUC, you are saying:
> 
> I

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2011 15:22:37 -0400

Thanks Keith.