Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted

[Andrew Allen <[e-mail]>]

Cullen et all

Below is to the best of my ability my attempt to dredge up all the comments, questions and issues you have raised on the DISPATCH list regarding draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid and our responses to address those concerns.

In summary the concerns you have raised I think fall basically into 3 categories:

1.	Privacy

-	We have addressed this. The IMEI should be of no greater privacy concern than the UUID as an instance ID. RFC 5626 does not seem overly concerned about this privacy issue as it has a very weak statement - prefer to omit is a far lower strength than MUST NOT or SHOULD NOT. There is no good reason why 3GPP should be held to a  much higher standard than RFC 5626 requires but in any case draft-allen-dispatch-imei-urn-as-instanceid and 3GPP specifications go a lot further in protecting the Instance ID than RFC 5626 requires.

2.	Interoperability

-	We fail to see any interoperability concerns as according to draft-allen the IMEI is only used as an Instance ID by 3GPP IMS compliant terminals when registering with a 3GPP IMS network. Only 3GPP devices have an IMEI so these are the only ones that can use an IMEI as an instance ID.  3GPP specifications allow for devices without IMEIs to register with a UUID as an instance ID. The IMEI is not sent end to end except when required for Emergency Calls per regulatory requirements - i.e when the PSAP expects to receive it. RFC 5626 anticipates that instance ID might in the future contain other URNs other than a UUID so in any case a UA (e.g B2BUA) or proxy should not have a problem receiving a non UUID in an Instance ID

3.	IPR

-	Research In Motion (now known as BlackBerry) has made a declaration on this draft over 3 years ago and the IPR situation and terms seems quite clear. I think Dale explained a long time ago why this should not be a showstopper concern.


With regard to finding 3GPP specifications I think we have addressed this with links provided in the references to where the 3GPP specifications are located. 


>From this Cullen can you please indicate what specifics we have not addressed in the drafts?

Andrew




OK HERE GOES: - A RECORD OF 4 YEARS OF EMAIL PING PONG!




Cullen, Dale

> From: "Cullen Jennings (fluffy)" <fluffy at cisco.com>
> 
> But the instance ID is in a register sent to trusted providers that 
> know the users name, credentials etc and can be send in an encrypted 
> channel. This is a bit different it that it goes to other users. The 
> analysis is not at the same.

This is a bit awkward to read, but I believe that your intention is:

    When the instance ID is in a REGISTER, it is sent to trusted
    providers that know the user's name, credentials, etc. already,
    and it can be sent in an encrypted channel.  This proposal (i.e.,
    draft-allen-dispatch-imei-urn-as-instanceid) is different in that
    the the GRUU containing the IMEI is sent to other users.  The
    analysis is not the same.

Please correct me if I'm wrong.

But assuming that I'm correct:  Yes,
draft-allen-dispatch-imei-urn-as-instanceid results in the IMEI being sent to other users, embedded in the Contact GRUU.  And the privacy analysis of that is different from that of a REGISTER.

The user that receives the IMEI-containing URI does not have a database mapping the IMEI to the user's name or other data.  (Or at least, I don't expect the service providers to make their database available to subscribers.)

So the IMEI-containing URI is reduced from a personal identifier to a "constant user fingerprint", an identifier that is associated with just one person, but anyone who wants to make use of that fact has to figure out themselves which person it is.

And that is the same as any with other GRUU.  If one's phone is using a GRUU, any conversant can record the GRUU and one's name, and use it to identify further calls from one's self.

Of course, if the user intends anonymity, the user can cause the UA to obtain a temporary GRUU which is not a constant user fingerprint, as is implied by section 8 of the draft.  We've already worked through this problem.

[AA] response:

draft-allen  addresses this. The gr parameter is generated from the IME in the instance ID but is not the IMEI URN:

7.  3GPP Registrar Procedures

   In 3GPP IMS when the Registrar receives in the Contact header field a
   "sip.instance" media feature tag containing the GSMA IMEI URN
   according to the syntax defined in draft-montemurro-gsma-imei-urn-13
   [3] the registrar follows the procedures defined in RFC 5626 [1] and
   RFC 5627 [2] if those extensions are supported and indicated as
   supported by the UA.  If the Registrar allocates a public GRUU
   according to the procedures defined in RFC 5627 [2] the instance-id
   MUST be obfuscated when creating the "gr" parameter in order not to
   reveal the IMEI to other UAs when the public GRUU is included in non-
   register requests. 3GPP TS 24.229 [6] subclause 5.4.7A.2 defines the
   mechanism for obfuscating the IMEI when creating the "gr" parameter.


3GPP TS 24.229 ] subclause 5.4.7A.2 states:

If the "+sip.instance" header field parameter from the Contact address contains an IMEI URN, as specified in draft-montemurro-gsma-imei-urn [153], then the value of the "gr" SIP URI parameter is generated by the S-CSCF using the name-based UUID algorithm defined in RFC 4122 [154]. The following applies to the algorithm:
-              the namespace shall be a UUID generated for use across the administrative domain and shall use the algorithm for creating a UUID from truly random numbers specified in RFC 4122 [154];
NOTE:   If the generated UUID is changed, then newly created GRUUs will not match those that were created with the previous UUID. Therefore, the UUID needs to remain the same in order to create consistent GRUUs.
-              SHA-1 shall be used as the hash algorithm; and
-              the "name" is made up of a concatenation of the TAC and SNR portions of the IMEI from the "+sip.instance" header field parameter.



Andrew



Cullen

I don't fully understand your comment maybe because there are several grammatical or typing errors in the first two sentences.

Are you saying that in your view the instance ID being sent in a register request to a cellular service provider is an issue?

The IMEI is already transmitted to the cellular carriers from every GSM, UMTS and LTE mobile phone using the existing technology and this has been the case since the beginning of GSM (since about 1992). Also in CDMA the MEID (mobile Equipment ID) is sent to the CDMA network carriers in every CDMA network.

OR are you suggesting that we are sending the instance ID to other users - this we are NOT doing.

Andrew

-----Original Message-----
From: Cullen Jennings (fluffy) [mailto:[e-mail]] 
Sent: Saturday, March 02, 2013 6:34 PM
To: Andrew Allen
Cc: Tom Taylor; Gonzalo Camarillo; [e-mail] list
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted


But the instance ID is in a register sent to trusted providers that know the users name, credentials etc and can be send in an encrypted channel. This is a bit different it that it goes to other users. The analysis is not at the same. 


On Jan 19, 2013, at 11:31 AM, Andrew Allen <[e-mail]> wrote:

> Cullen
> 
> To clarify these comments I think are your comments not Tom Taylor's (Tom simply forwarded my original post as it was rejected due to attached diff files).
> 
> Where does it state in RFC 5626 or anywhere else that an instance ID can be changed by the user?
> 
> In fact RFC 5626 states the opposite:
> 
>             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.  
> 
> And
> 
>             4.1.  Instance ID Creation
> 
>                             Each UA MUST have an Instance Identifier Uniform Resource Name (URN) [RFC2141] that uniquely identifies the device.  Usage of a URN
>               provides a persistent and unique name for the UA instance.  It also provides an easy way to guarantee uniqueness within the AOR.  This
>               URN MUST be persistent across power cycles of the device.  
> 
> So the instance ID is persistent (RFC 5626 wording) and does not change and is not changeable by the user. Whether the instance ID is a UUID or IMEI this does not change.
> 
> If an Instance ID containing a UUID is provided in a SIP request or response to another party then it can be stored as the instance ID of a device belonging to that user if their identity is known. Then if the same instance ID is provided again in a SIP request when the originating user requests anonymity then that user can potentially be identified by correlation with the stored instance ID.  
> 
> If I call you and your device rings and in the response I receive the instance ID I can potentially learn the Instance ID of the specific device even if it is a UUID.
> 
> This is the same regardless of whether the instance ID is a UUID or IMEI. In 3GPP usage the instance ID is never supplied to the far end party except for the case of emergency calls where the far end is a PSAP.
> 
> RFC 5626 does not seem overly concerned about this privacy issue as it has a very weak statement - prefer to omit is a far lower strength than MUST NOT or SHOULD NOT.
> 
> The only thing it states about it is:
> 
>             4.1.  Instance ID Creation
> 
>                             One case where a UA could prefer to omit the "sip.instance" media feature  tag is when it is making an anonymous request or some other privacy concern 
>             requires that the UA not reveal its identity.
> 
> 3GPP procedures and draft-allen-dispatch-imei-urn-as-instanceid protect revelation of the Instance ID far more than is required by RFC 5626.
> 
> Andrew
> 
> -----Original Messsage-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Cullen Jennings (fluffy)
> Sent: Saturday, January 19, 2013 11:49 AM
> To: Tom Taylor; Gonzalo Camarillo
> Cc: [e-mail]
> Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted
> 
> 
> On Nov 20, 2012, at 10:16 AM, Tom Taylor <[e-mail]> wrote:
> 
>> Those that think privacy issues are insufficiently addressed need to explain why the IMEI is of significantly greater concern in terms of revealing privacy than the UUID when used as an instance ID.
> 
> That has been explained in detail multiple times. For one thing, the user can't change the IMEI. For a second thing, it can be directly mapped to a specific user in many cases. 
> 
>> 
>> In our view the security concerns raised have now been sufficiently addressed in the drafts and to a much higher bar than that of UUID in RFC 5626.
> 
> I strongly disagree.
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> ---------------------------------------------------------------------
> 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.
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch


---------------------------------------------------------------------
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.
_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch



Cullen

An IPR declaration on these drafts was made over 3 years ago so I think the IPR situation and terms are well known.

I think Dale Worley  in some much earlier thread also explained why in his view this should not be an issue preventing progress of the draft. I concur with Dale on that.

Andrew

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Cullen Jennings (fluffy)
Sent: Saturday, January 19, 2013 11:50 AM
To: Tom Taylor
Cc: [e-mail]
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted


I would like to point out that several of my comments, including the one about IPR, had never been addressed. 

On Nov 20, 2012, at 10:16 AM, Tom Taylor <[e-mail]> wrote:

> Andrew's original note appeared to me at least as a brief message: "WARNING: contains banned part", with attachments. As a public service, I have extracted and reproduced the text of his message. Hope this isn't a duplicate from others' point of view.
> 
> Tom Taylor
> 
> Andrew's message:
> ==========================
> New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid were submitted at the beginning of October.
> 
> http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as-instanceid-06.txt
> 
> http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-11.txt
> 
> There are not many major changes since the previous versions which were submitted in March and July which themselves were submitted after the conference call held between 3GPP and IETF interested parties in early January on the topic. Basically editorial updates and some strengthening of the normative language.
> 
> The main change in draft-montemurro-gsma-imei-urn since the previous version is to address the ABNF comment from Dale and it was decided we do not need parameters to have multiple values so Dale's proposed resolution has been adopted. The January version of draft-montemurro-gsma-imei-urn (09 version) added the following to the Security Considerations section to address the privacy concerns:
> 
>   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 SHOULD NOT be included in
>   messages intended to convey any level of anonymity.
> 
> In the latest (11 version) this has been strengthened from a SHOULD NOT to a MUST NOT.
> 
> The draft-allen-dispatch-imei-urn-as-instanceid 05 version that was submitted in March incorporated a number of significant changes including:
> 
> 1.    Additional text was added to the abstract stating:
> 
> [The purpose of the draft] is to fulfil the requirements in RFC 5626 [1] that state "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 and used in the "+sip.instance" Contact header field parameter for outbound behavior."
> 
> 2.    A new section was added describing the three 3GPP use cases
> 
> 3.    A new section was added for 3GPP Registrar Procedures with the following text:
> 
> In 3GPP IMS when the Registrar receives in the Contact header field a "sip.instance" media feature tag containing the GSMA IMEI URN according to the syntax defined in draft-montemurro-gsma-imei-urn-09[3] the registrar follows the procedures defined in RFC 5626 [1] and RFC 5627 [2] if those extensions are supported and indicated as supported by the UA.  If the Registrar allocates a public GRUU according to the procedures defined in RFC 5627 [2] the the instance-id MUST be obfuscated when creating the "gr" parameter in order not to reveal the IMEI to other UAs when the public GRUU is included in non register requests. 3GPP TS 24.229 [6] subcluase 5.4.7A.2 defines the mechanism for obfuscating the IMEI when creating the "gr" parameter.
> 
> 4.    The security section was beefed up as follows:
> 
> Because IMEIs like other formats of instance IDs can be loosely correlated to a user, they need to be treated as any other personally identifiable information.  In particular, the "sip.instance" media feature tag containing the GSMA IMEI URN MUST NOT be included in requests or responses intended to convey any level of anonymity.  RFC 5626 [1] states "One case where a UA could prefer to omit the "sip.instance" media feature tag is when it is making an anonymous request or some other privacy concern requires that the UA not reveal its identity".  The same concerns apply when using the GSMA IMEI URN as an instance ID.  Publication of the GSMA IMEI URN to networks that the UA is not attached to or the UA does not have a service relationship with is a security breach and the "sip.instance" media feature tag MUST NOT be forwarded by the service provider's network elements when forwarding requests or responses towards the destination UA.
> 
> In order to protect from tampering the REGISTER requests containing the GSMA IMEI URN MUST be sent using a security mechanism such as TLS [12] (or another security mechanism that provides equivalent levels of protection).
> 
> There do not seem to be any comments made against the draft-allen-dispatch-imei-urn-as-instanceid-05 version that was submitted in March. Not sure if this was because everyone was Ok with it or because it was overlooked.
> 
> At the conference call held between 3GPP and IETF interested participants in January at which privacy concerns about the use of the IMEI as an instance ID by 3GPP were raised. It was proposed during the conference call that the authors submit a new revision of the draft clarifying the use of the mechanism and explaining how the 3GPP architecture addresses the privacy issues that were discussed.
> 
> There was a further discussion at a following 3GPP meeting on these privacy concerns. During the 3GPP discussion it was pointed out that RFC 5626 already previously considered and addressed privacy concerns  with instance ID in section 4.1 which only states the "UA could prefer to omit the "sip.instance" media feature tag":
> 
> 4.1.  Instance ID Creation
> 



Cullen

To clarify these comments I think are your comments not Tom Taylor's (Tom simply forwarded my original post as it was rejected due to attached diff files).

Where does it state in RFC 5626 or anywhere else that an instance ID can be changed by the user?

In fact RFC 5626 states the opposite:

                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.  

And

                4.1.  Instance ID Creation

                                Each UA MUST have an Instance Identifier Uniform Resource Name (URN) [RFC2141] that uniquely identifies the device.  Usage of a URN
                  provides a persistent and unique name for the UA instance.  It also provides an easy way to guarantee uniqueness within the AOR.  This
                  URN MUST be persistent across power cycles of the device.  

So the instance ID is persistent (RFC 5626 wording) and does not change and is not changeable by the user. Whether the instance ID is a UUID or IMEI this does not change.

If an Instance ID containing a UUID is provided in a SIP request or response to another party then it can be stored as the instance ID of a device belonging to that user if their identity is known. Then if the same instance ID is provided again in a SIP request when the originating user requests anonymity then that user can potentially be identified by correlation with the stored instance ID.  

If I call you and your device rings and in the response I receive the instance ID I can potentially learn the Instance ID of the specific device even if it is a UUID.

This is the same regardless of whether the instance ID is a UUID or IMEI. In 3GPP usage the instance ID is never supplied to the far end party except for the case of emergency calls where the far end is a PSAP.

RFC 5626 does not seem overly concerned about this privacy issue as it has a very weak statement - prefer to omit is a far lower strength than MUST NOT or SHOULD NOT.

The only thing it states about it is:

                4.1.  Instance ID Creation

                                One case where a UA could prefer to omit the "sip.instance" media feature  tag is when it is making an anonymous request or some other privacy concern 
                requires that the UA not reveal its identity.

3GPP procedures and draft-allen-dispatch-imei-urn-as-instanceid protect revelation of the Instance ID far more than is required by RFC 5626.

Andrew

-----Original Messsage-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Cullen Jennings (fluffy)
Sent: Saturday, January 19, 2013 11:49 AM
To: Tom Taylor; Gonzalo Camarillo
Cc: [e-mail]
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted


On Nov 20, 2012, at 10:16 AM, Tom Taylor <[e-mail]> wrote:

> Those that think privacy issues are insufficiently addressed need to explain why the IMEI is of significantly greater concern in terms of revealing privacy than the UUID when used as an instance ID.

That has been explained in detail multiple times. For one thing, the user can't change the IMEI. For a second thing, it can be directly mapped to a specific user in many cases. 

> 
> In our view the security concerns raised have now been sufficiently addressed in the drafts and to a much higher bar than that of UUID in RFC 5626.

I strongly disagree.

_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
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.
_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch





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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: Monday, October 24, 2011 5:08 PM
> To: Cullen Jennings; Worley, Dale R (Dale)
> Cc: [e-mail] list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and 
> draft-allen- dispatch-imei-urn-as-instanceid
> 
> 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: [e-mail] [mailto:[e-mail]] 
> > On Behalf Of Cullen Jennings
> > Sent: 24 October 2011 14:37
> > To: Worley, Dale R (Dale)
> > Cc: [e-mail] 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.
> >
> >
> >
> > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dispatch
> >
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
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.
_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch




Cullen

I think my email prior to Dale's that Dale replied to  responded to all your points

Andrew

----- Original Message -----
From: Cullen Jennings [mailto:[e-mail]]
Sent: Friday, September 16, 2011 07:21 AM
To: Worley, Dale R (Dale) <[e-mail]>
Cc: Mary Barnes <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn            anddraft-allen-dispatch-imei-urn-as-instanceid



On Sep 15, 2011, at 9:46 AM, Worley, Dale R (Dale) wrote:

> Based on responses that have been sent to my original rant,
> 
> (1) I formally request the chairs to recognize that rough consensus 
> has been reached that the work described in 
> draft-montemurro-gsma-imei-urn and 
> draft-allen-dispatch-imei-urn-as-instanceid should progress, and those 
> proposals be dispatched to an appropriate working group.

Did any the emails sent since your rant discuss any of the issues raised? Of course no one has ever objected some organization such ad GSM having a URN they can use.

> 
> (2) I ask any person who believes that the current methods of 
> constructing SIP instance ids can be significantly improved upon 
> (along any dimension), and who wishes to work on improving them, 
> present proposals for research and/or implementation to Dispatch or 
> another working group, so that the state of SIP can be improved.

I have.

> 
> Dale
> 

_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch



Cullen

Apologies for the delay in responding. With some vacation time, a 3GPP meeting to prepare for and attend and being sick for the past week this is the first chance I have had to respond.

Responses included below:

Andrew

> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]]
> Sent: Tuesday, July 26, 2011 5:23 PM
> To: Andrew Allen
> Cc: DISPATCH list
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen- 
> dispatch-imei-urn-as-instanceid
> 
> 
> On May 27, 2011, at 23:07 , Andrew Allen wrote:
> 
> > Cullen
> >
> > Responses to your technical points below:
> >
> > regards
> > Andrew
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] 
> >> On Behalf Of Cullen Jennings
> >> Sent: Wednesday, May 18, 2011 1:11 PM
> >> To: DISPATCH list
> >> Subject: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen- 
> >> dispatch-imei-urn-as-instanceid
> >>
> >>
> >> I have said in the past, I have several concerns around the 
> >> combined proposal in these two drafts. In this email, I've tried to 
> >> focus on
> > the
> >> high level problems and ignore small problems in the drafts that 
> >> can
> > be
> >> fixed by change a bit of text in the drat.
> >>
> >> The biggest issues is that this is going to reduce interoperability
> > with
> >> systems that don't use this type of instance id yet this does not
> > provide
> >> features that could not be done in away that did not reduce 
> >> interoperability.
> >
> > Can you please elaborate on what your interoperability concerns are? 
> > I don't see any issue with end to end interoperability since with 
> > public GRUU the gr parameter is opaque. Devices that contain an IMEI 
> > are only those devices specified by 3GPP. Only 3GPP mandates that 
> > the IMEI is included in the instance ID, non 3GPP devices or devices 
> > not operating in an IMS network do not need to use an IMEI (indeed a 
> > non 3PP device would not even have an IMEI to use). RFC 5626 allows 
> > the possibility for URNs other than UUID to be used as an instance 
> > ID and RFC 5627 does not mandate an algorithm for the generation of 
> > GRUUs based on the instance ID. If the 3GPP determines that its 
> > devices that already contain an IMEI for their device ID need to use 
> > that as an Instance ID and defines a GRUU generation algorithm that 
> > satisfies its requirements when receiving an Instance ID that 
> > contains the IMEI URN then that seems fine to me. Is your concern 
> > regarding a 3GPP IMS terminal registering in a non IMS domain? I 
> > think that in reality a device acting as an IMS terminal registering in a non IMS compliant network isn't a practical scenario.
> > There are so many 3GPP and IMS compliant things that would need to 
> > happen in the network for the device (acting as an IMS terminal) to 
> > register and obtain service that basically the network would need to 
> > be an IMS compliant network. Of course there is nothing preventing a 
> > device that is IMS capable being configured to either act as an IMS 
> > compliant device or a basic SIP compliant device (quite a few 
> > devices have such dual mode capabilities). The use of the IMEI as 
> > the instance ID should not in itself prevent the successful 
> > registration of the device in a non IMS network (since as Dale 
> > points out the registrar is likely to treat the instance ID opaquely if it doesn't understand it).
> 
> What happens in 3GPP tends to leak out into other standard and into 
> other systems.

[AA] I don't see how this can happen as only GSM/3GPP devices can have an IMEI (GSMA allocates the IMEI namespace). Devices that are not compliant with the 3GPP specifications and are not part of a 3GPP system will not have an IMEI so I don't see how it is possible for the IMEI URN to "leak out" into other standards.
> 
> >
> >> To be concrete, let me offer an alternative solution that would be 
> >> interoperable, would not have any IPR that I am aware
> > of,
> >> and would provide the same functionality as the goals of these 
> >> drafts
> > - or
> >> at least the goals that have been stated at the IETF.
> >>
> >> To indicate the version of the software, I would suggest using the 
> >> SIP User Agent header. If a more structured form is required to
> > specifically
> >> line up with existing mobile systems, I would suggest defining an 
> >> well structured format to use inside the User Agent header field. 
> >> The
> > advantage
> >> is that this is what most sip systems do today and many management
> > systems
> >> already can look at this header and use it. A more structured form
> > would
> >> be useful by systems outside the GSMA space and would also be
> > backwards
> >> compatible with existing systems that treat it as an unstructured
> > string.
> >
> > I am not against the proposal of including the software version in 
> > the User Agent header but don't see it as an alternative to the 
> > representation of the IMEI-SV as part of the IMEI URN. One of the 
> > main objectives of the use of the IMEI and IMEI-SV in SIP signaling 
> > is to maintain compatibility with the IMEI and IMEI-SV use in 
> > Circuit Switched signaling. In some case in circuit switched 
> > signaling the device will return the IMEI and in other cases the device will return the IMEI-SV.
> > It needs to be possible that devices registered in circuit switched 
> > domain and in the IMS domain can use whichever is returned IMEI or 
> > IMEI-SV in the same identifier.
> 
> I understand both are used in circuit switched but I don't see that 
> that would require a design like this.
> 
[AA] We are just trying to define a namespace to represent the IMEI and IMEI-SV as already defined by GSMA. The latest version of draft-allen-dispatch-imei-urn-as-instanceid states: "The UAC SHOULD NOT include the optional "svn" parameter in the GSMA IMEI URN in the "sip.instance" media feature tag, since the software version can change as a result of upgrades to the device firmware which would create a new instance ID.". 3GPP do not use the IMEI-SVN as an instance ID in their specifications.

> >>
> >> For the issue of identifying stolen handsets and correlating 
> >> devices between SIP and non SIP calls, I would propose that you use 
> >> a UUID as
> > the
> >> URN but that the UUID be created using IMEI or a hash of the IMEI
> > instead
> >> of the MAC. This would involve an extension to RFC 4122 but would
> > result
> >> in a system that meets the needs. Even if a hash is used, the 
> >> server
> > side
> >> can do the same hash to match.
> >
> > I don't fully understand the details of your proposal but a clear 
> > requirement is that the IMEI in the instance ID be recoverable and 
> > understandable by the registrar as the IMEI value of the terminal. 
> > Does this proposal allow the IMEI value to be obtained and 
> > understood by the registrar?
> 
> The requirement was that they be matchable not recoverable which this 
> meets

[AA] The requirement is that the IMEI be identifiable so that registration of barred devices (e.g stolen devices) can be prevented and also so that for emergency calls the device used can be identified.

> 
> 
> >
> > If an extension to RFC 4122 is required isn't this more overhead and 
> > has more impact than simply defining and using a URN that represents 
> > the namespace that you wish to include? UUID itself is also heavier 
> > in computational resources and less efficient in size than the IMEI URN.
> 
> This extension to 4122 is pretty easy and has no IPR I am aware of.
> 
[AA] As above it seems this solution doesn't meet the above requirement that the IMEI be recoverable.
> >
> >>
> >> If the WG is interest in such an idea, I am glad to write up an ID 
> >> for each of these and submit it to the group so that it can be 
> >> properly considered in contrast to draft-allen-dispatch-imei-urn-as-instanceid.
> >>
> >> As the draft-allen-dispatch-imei-urn-as-instanceid stands today, I 
> >> am
> > not
> >> in favor of publishing it as is because  I believe it will result 
> >> in interoperability failures with the many SIP devices that don't 
> >> support
> > it,
> >
> > This needs justification. 3GPP specifications also support handling 
> > devices that use UUID and not IMEI as many IMS compatible devices do 
> > not actually have an IMEI (only GSM mobile devices have an IMEI).
> 
> I think I have provided this on more than one occasion.
> 
[AA] As I understand from a very brief discussion with you on this in Quebec City your concern is that GSM mobile devices may try and register using the IMEI as an Instance ID on non IMS networks. I don't think this is a practical scenario. There are so many IMS specific things that 3GPP devices that contain IMEIs do and expect the network to do that a device acting as a compliant 3GPP IMS device would not successfully register with a non 3GPP IMS compliant network. Firstly 3GPP IMS mobile devices that contain an IMEI either obtain or derive their registered public user identity (which becomes the address of record), the domain name to register in and their security parameters for authentication from the SIM card or UICC. Only GSM network operators supply SIM cards and UICCs that contain other GSMA allocated identities such as mobile country code (MCC) and mobile network code (MNC) so a 3GPP IMS device (with an IMEI) cannot register (according to IMS procedures) with any network that is not a network operated by a GSM operator. Additionally lower layer security mechanisms upon which SIP signaling relies are also dependent on the SIM card or UICC based security mechanisms so a 3GPP IMS device (with an IMEI) could not even establish the necessary security contexts. Also the 3GPP IMS device depends on the support and usage of certain mechanisms such as Service-Route header field, P-Associated-URI header field and use of security agreement (Security-Client, Security-Server and Security-Verify header fields in an IMS specific manner. Without these IMS specific procedures being followed the 3GPP IMS device (with an IMEI) would not be able to successfully register and establish sessions. Therefore I don't see how this is a real issue. This concern could be addressed in draft-allen-dispatch-imei-urn-as-instanceid by adding a statement that an IMEI is MUST only be used as an Instance ID by a device registering with a 3GPP IMS network.

> >
> >> and it has IPR that we can easily avoid and provide the same 
> >> functionality. I also have issues with some of the technical 
> >> details
> > in it
> >> but theses could all be fairly easily resolved with a few back and
> > forth
> >> of suggested text. RIM is offering awful licensing terms for 
> >> something that I believe you would have to implement to be workable 
> >> in the bulk mobile SIP deployments. Give this is easily avoidable, 
> >> I think we
> > should
> >> avoid it. It's not really a topic for this WG but if this draft
> > proceeded,
> >> it was very late IPR disclosure. When it came to IETF LC, I would 
> >> also want to point out that the only teeth IETF has to enforce very 
> >> late
> > IPR
> >> disclosures is to say no. I'm not particularly interested in 
> >> talking
> > about
> >> this here as I don't think it will help solve the proble m but I 
> >> have brought this up in the past in context of this draft and
> > I
> >> don't want anyone to be surprised if I brought it up in an IETF LC.
> >>
> >> There are also significant privacy concerns around this proposal. A
> > key
> >> design of GRUU is being able to meet people goals of privacy while 
> >> not revealing private information.
> >
> > Privacy in GRUU is achieved through temporary GRUUs. Properties of 
> > temporary GRUUs are unaffected by using the IMEI as an instance ID.
> >
> >> The IMEI is sometimes used as a security identifier between a user 
> >> and SP as a shared secret. This proposal
> > would
> >> break theses systems.
> >
> > The IMEI is easily readable from the UI of mobile phones and is 
> > quite often printed on the case under the battery. Mobile phone 
> > stores sometimes keep lists (sometimes on paper) of IMEIs and the 
> > customers who have been allocated them (warranty reasons etc).
> 
> agree with what you are saying but you do agree it is used as a secret 
> often used to show proof of possession of the phone?

[AA] This is handled with the design and usage of the IMEI. The IMEI has a spare digit. This digit has a spare digit. This digit is always set to zero when transmitted but one the mobile device has a non zero value. Thus intercepting the transmitted IMEI value does not provide you the entire IMEI.

> 
> > It is hardly a super
> > secret security identifier. I am not aware of the security usage you 
> > describe and if it does exist it seems pretty flawed.
> >
> >> The privacy and security aspects of this would need to be addressed.
> >
> > 3GPP has addressed aspects of revealing the IMEI when generating 
> > GRUUs in their specifications.
> 
> right, send them on over

[AA] Here is the link:
http://www.3gpp.org/ftp/Specs/latest/Rel-8/24_series/24229-8g0.zip

> 
> >
> >> It's conceivable that in many cases IMEI is Personal Identifiable 
> >> Information.
> >
> > IMEI is not really anymore personal information than IP address
> 
> <..snip..>
> 
> I'll note I think you are just wrong on this. First of all, IMEI are 
> more revealing than IP because they tend to be tighter bound to a 
> single suer instead of multiple and exist over longer time and second 
> of all many people, myself included, consider IP as PII in many cases.
>

[AA] Whether one is worse than the other is debatable but as indicated above there isn't a issue with revealing this information since 3GPP specifications address this issue and having 3GPP IMS devices with IMEIs register on non IMS networks isn't a practical scenario.

> 
> >
> >> The idea that every call would have to have PII information in it 
> >> or my call would be blocked as coming form a stolen phone seems 
> >> like a pretty serious flaw in this proposal.
> >
> > In general the IMEI is not placed in an IMS call. The blocking would 
> > be achieved via the registration. Blocked mobiles simply would be 
> > unable to register in IMS (which in IMS means they are unable to 
> > make calls). If an IMEI check is needed during a call the mobile can 
> > be requested by the network to re-register. The only use in 3GPP of 
> > the IMEI during an IMS call is for emergency calls.
> 
> again, I think there are much better designs for this without IPR 
> issues

[AA] I don't think there has been such a proposal and in any case this was the proposal that was agreed in 3GPP. This proposal is informational not standards track and is 3GPP informing the internet community of its usage. This is applicable for 3GPP IMS deployments only so what is the basis for these concerns?

> 
> >
> >> I'll note I brought up the privacy issues in 2007 and have yet to 
> >> get
> > a reply on it.
> 
> 
> >
> > I don't recall your previous comment (but it was 4 years ago). If we 
> > have failed to respond adequately to a previous comment then please 
> > restate it if the above responses do not cover it.
> >>
> >> On the topic of draft-montemurro-gsma-imei-urn, I of course think 
> >> it
> > is
> >> fine for the GSMA to be able to allocate a namespace where they 
> >> need
> > it.
> >> However, there are bunch of changes that would be needed to make 
> >> this draft fit all the URN rules. They are all small actionable 
> >> things like defining how comparison of things such as svn is 
> >> defined and how allocation of new things works.
> >
> > Of course all technical issues and concerns can be fixed. Please 
> > supply details on those so they can be addressed.
> >
> >> As I have also brought up many times in the past, what the 
> >> relationship between GSMA and 3GPP on this is very weird and I 
> >> would want clarity on that before proceeding. In the time
> > we
> >> have been discussing this draft, people constantly tell me that 
> >> GSMA
> > is
> >> the group that will handle the namespace allocation for the 3GPP 
> >> deployments yet at the same time we have approved RFC 5279 which 
> >> oddly looks like a better namespace for this than the GSMA one. I 
> >> would want
> > to
> >> have a clear understanding of how these different spaces interact. 
> >> The more we splinter this namespace, the less interoperability we have.
> >
> > My understanding is that in order to be allocated a URN namespace 
> > the registrant of the namespace has to guarantee uniqueness of the 
> > namespace. GSMA provides for the allocation of IMEIs and ensures 
> > adherence to the guidelines for IMEI allocation "GSMA Association, 
> > "IMEI Allocation and Approval Guidelines", PRD DG.06". Thus for the 
> > IMEI the GSMA is the appropriate registrant for that namespace. 3GPP 
> > has no responsibility for allocation of IMEIs so should not be the 
> > responsible registrant. 3GPP namespace would seem appropriate for 
> > items which are completely specified (including all their values) in 
> > 3GPP specifications. It should be noted that 3GPP is not a legal 
> > entity and might not exist for the entire period of time that IMEIs 
> > are being allocated and used.
> >>
> >> On the topic of including the software version as part of the 
> >> device identifier, given the software is upgraded, I think this is 
> >> a mistake
> > and
> >> it is better to consider the software version as a separate thing 
> >> from
> > the
> >> unique device identifier. It does not seem consistent with the 
> >> goals
> > and
> >> requirements of a device id URN.
> >
> > As stated above the software version is included for backward 
> > compatibility with the IMEI-SV usage in circuit switched signaling. 
> > The SVN is a parameter and so the original IMEI which does not 
> > change can be easily obtained. Registrars and other devices that 
> > understand the IMEI URN with the SVN parameter can ignore the 
> > parameter when generating GRUUs for instance. If a book has a 2nd 
> > edition with different content doesn't that warrant being assigned a 
> > new value within the ISBN URN namespace? Similarly if the software 
> > is upgraded the nature and capabilities of the device may change so 
> > doesn't this warrant a new value? Note that RFC 5626 and RFC 5627 do 
> > not require that the instance IDs or GRUUs be forever persistent 
> > (RFC 5626 only requires that it MUST be persistent through a power 
> > cycle). I doubt very much that most embedded SIP endpoints will 
> > after a complete software upgrade (such as involving completely 
> > rewriting flash memory) still use the same UUID as previously used either.
> >>
> >> I will also note that as far as process is concerned, I would 
> >> prefer
> > the
> >> problem, not the solution was brought to dispatch and we could 
> >> figure
> > out
> >> how to solve it. I do think the problem here is well worth solving, 
> >> I
> > just
> >> think there are solutions that will work better that this when
> > considering
> >> the whole eco systems of SIP endpoints and not just the GSM ones.
> >
> > When this was first proposed in 2006 all that was being done was 
> > registering a namespace.
> 
> I doubt that is true. Please look at the drafts from 2006. I have 
> never objected to the idea that some other SDO might want a URN 
> namespace. If that was all that was requested, this would have been 
> done long ago and the current draft would not be requesting anything more than that.
> 
[AA] There is nothing in the early versions (around 2006) about using the IMEI URN as an instance ID although this was added in later versions but then removed and then specified separately in draft-allen-dispatch-imei-urn-as-instanceid

> > I don't think that 3GPP needs to bring requirements to the dispatch 
> > WG, propose a charter etc for every problem that can be solved by 
> > registering a namespace or a parameter. In fact the SIP change 
> > process has moved away from that with only specification required 
> > and expert review needed for defining "proprietary" SIP header 
> > fields. As stated above the IMEI only applies to the GSM family of 
> > technology mobiles not all SIP endpoints and I fail to see the 
> > impact of the use of the IMEI URN by the GSM family of technology 
> > mobiles when registering with IMS on any other SIP endpoints. This 
> > proposal does not mandate the use of the IMEI URN as an Instance ID 
> > by non 3GPP terminals and is not being proposed to become part of an 
> > IETF standard. This is just trying to follow the process whereby 
> > external users of IETF protocols register their identifiers with 
> > IANA and provide informational documentation to the internet 
> > community about such usage. It seems to me that some of the issues 
> > of principle being raised are those considerations that more 
> > appropriately apply to standards track submissions and not to these informational submissions.
> 
> > If the same
> > level of consideration and debate about different solutions takes 
> > place for informational submissions as would take place for 
> > standards track submissions then I fear this will become a big 
> > deterrent to outside users of IETF protocol submitting their 
> > proprietary usages as informational RFCs for the benefit of the 
> > internet community and in ensuring that are no conflicts with the IANA registry.
> 
> 
> You are asking for something that can not be approved as an 
> information draft by the ISE because it impacts interoperability of 
> SIP devices. The bar here is somewhat higher than some information 
> drafts. If what you needed to be approved could be done by the ISE, I 
> would suggest you take it there but it can't.
> 
[AA] As above I do not agree that there are any interoperability concerns with this proposal and this is only proposed for 3GPP IMS usage of SIP not for general internet usage.
> 
> >>
> >> Cullen in my individual contributor role
> >>
> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >
> > --------------------------------------------------------------------
> > - 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.
> 
> 
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 



Cullen

We had a very brief discussion regarding these drafts Friday lunchtime in Prague as I had to leave Friday afternoon and so I wasn't able ti address this point then. 

Basically the reason for defining a new namespace is that the URN registrant requirements require that the registrant guarantee the uniqueness of the namespace. Since the GSMA and not 3GPP defines the IMEI allocation procedures and ensures that the namespace uniquely identifies a GSM system device they are the appropriate registrant of the namespace that represents the IMEI.

Please look into the details of the latest drafts with regard to the resolution of the technical comments from Paul Kyzivat and Dale Worley and the related declaration as we discussed.

If we need a phone discussion on this then please let me know.

Thanks
Andrew

----- Original Message -----
From: Cullen Jennings [mailto:[e-mail]]
Sent: Wednesday, March 23, 2011 06:51 PM
To: Gonzalo Camarillo <[e-mail]>
Cc: Mary Barnes <[e-mail]>; Andrew Allen; Robert Sparks <[e-mail]>
Subject: Re: Status of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid


3gpp already has a URN space which they can trivial use to get URNs. I don't think the URN has anything to with what people did not like about this. If this was just a URN registration, no one would have any problems with it. 

On Mar 23, 2011, at 6:05 , Gonzalo Camarillo wrote:

> Hi,
> 
> [adding Robert to the cc:]
> 
>> No problem with me but I am noting as Dispatch co-chair that these 
>> drafts clearly did not reach consensus in the dispatch WG. If the AD 
>> chooses to sponsor them or not is the ADs decision.
> 
> yes, I guess that is what Andrew has in mind: to have Robert or I AD 
> sponsor the documents. As usual, we will only AD sponsor documents 
> that are not controversial.
> 
> I agree the discussions on the DISPATCH list have not been very useful 
> since they did not really focus on the technical contents of the drafts.
> I have just read both drafts. The process for registering a URN 
> namespace is described in RFC 3406, which is being revised:
> 
> http://tools.ietf.org/html/rfc3406
> http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-00
> 
> In short, the apps guys would need to review the registration and we 
> would need to produce an RFC. So, what we need to ask DISPATCH is 
> whether people have technical objections to such a URN space being 
> created. The formal requirements for the registration will be checked 
> by the apps reviewers.
> 
> Also, we would need to ask if people have any objections with mobiles 
> using their IMEIs as instance IDs in order to decide how to progress 
> the other draft.
> 
> Cullen, Mary, could one of you ask the DISPATCH list about the issues above?
> 
> Thanks,
> 
> Gonzalo
> 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html



Cullen

>> Am I really understanding you right that you are now saying that 3GPP 
>> now need to draft requirements and propose a working group charter 
>> simply to register a URN namespace with IANA and use that URN in a 
>> way already anticipated by existing RFCs?

>No, of course not. If all you were doing was registering a URN you would not need any of this. However, >registering a URN  is not really what you are doing here, is it?

As I stated on the list all these drafts do is register a URN namespace and define its usage as an Instance ID as required by RFC 5626. What more are we doing than that?

If 3GPP and GSMA determine that they want to use their existing device identifier as an Instance ID what is the problem with that? No one seems to have identified a technical issue with this. I fail to understand why this is controversial.

Andrew

-----Original Message-----
From: Cullen Jennings [mailto:[e-mail]]
Sent: Monday, March 21, 2011 6:30 PM
To: Andrew Allen
Cc: Mary Barnes; Gonzalo Camarillo
Subject: Re: Status of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid


On Mar 21, 2011, at 11:17 AM, Andrew Allen wrote:

> Cullen
> 
> Am I really understanding you right that you are now saying that 3GPP
> now need to draft requirements and propose a working group charter
> simply to register a URN namespace with IANA and use that URN in a way
> already anticipated by existing RFCs?

No, of course not. If all you were doing was registering a URN you would not need any of this. However, registering a URN  is not really what you are doing here, is it?

> 
> This is not the process as I understood it and is clearly not going to
> happen.

Ok, we can probably stop this thread now then. No worry. 

> 
> I understood that the SIP change process had in fact evolved in the
> opposite direction so that IETF spends less time working on issues of
> less importance to core SIP and of primary importance to other users of
> SIP. With the prime focus being ensuring that identifiers (such as new
> proprietary SIP headers) are appropriately documented and then
> registered with IANA without requiring lots of discussion in IETF WGs.
> 
> This position will completely undermine those of us in 3GPP who have put
> our credibility on the line and fought long and hard that 3GPP and other
> standards defining organizations should do things the right way by
> registering identifiers used in IETF protocols with IANA and follow the
> IETF process for doing that. 3GPP has recently started (unfortunately)
> defining in their specifications alone some parameters that according to
> the process ought also to be registered with IANA and published in RFCs
> because they couldn't achieve progress on those issues in IETF. Such a
> position will make such things common place as it undermines the Andrew
> Allen's of the world and strengthens the position of the Martin Dolly's.
> If those of us who have been friends of IETF in 3GPP cannot get the most
> simple things that have no outstanding technical objections progressed
> then how can we possibly advocate the position that more complex and
> controversial things should be worked through IETF? Does IETF still wish
> to continue to cooperate with 3GPP or not?

>From everything I can see that the IETF is doing, I would say the answer is clearly "yes", the IETF does wish to continue cooperating with 3GPP and I view it has highly likely that it will continue to do so. If they can reach IETF consensus or not in an IETF Last Call would be interesting to watch. 

> 
> The only philosophical discussions on the list on these drafts came from
> Henry who acknowledged he doesn't have technical comments. Paul and Dale
> both reviewed the drafts in detail, and contributed to the technical
> improvement of the drafts. All their technical comments have been
> addressed to their satisfaction in the latest versions. The drafts have
> received support on the dispatch list including from significant players
> in the 3GPP and GSMA community as well as more primary IETF players and
> are already referenced in 3GPP and GSMA specifications.
> 
> I request (as Dale Worley recommended on the list) that these drafts be
> progressed as AD sponsored drafts. I see no need for further discussion
> in dispatch.

No problem with me but I am noting as Dispatch co-chair that these drafts clearly did not reach consensus in the dispatch WG. If the AD chooses to sponsor them or not is the ADs decision. 

> 
> Andrew
> 
> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]]
> Sent: Monday, March 21, 2011 10:27 AM
> To: Andrew Allen
> Cc: Mary Barnes; Gonzalo Camarillo
> Subject: Re: Status of draft-montemurro-gsma-imei-urn and
> draft-allen-dispatch-imei-urn-as-instanceid
> 
> 
> My advice would be propose some requirements of what is needed here
> along with a proposed charter and bring them to dispatch. We can deal
> with things like that quickly. The current thread on dispatch quickly
> turned in to philosophy more than discussions of this draft or the
> problem it solved.
> 
> Cullen <with my dispatch co-chair hat on>
> 
> On Mar 21, 2011, at 3:14 AM, Gonzalo Camarillo wrote:
> 
>> Cullen, Mary,
>> 
>> could you please let Andrew (in the cc:) know how to proceed with the
>> following two drafts?
>> 
>> o draft-montemurro-gsma-imei-urn
>> o draft-allen-dispatch-imei-urn-as-instanceid.
>> 
>> There have been some discussions on the DISPATCH list in the last
> weeks
>> and he would like to know what the next steps are.
>> 
>> Thanks,
>> 
>> Gonzalo
>> 
> 
> 
> ---------------------------------------------------------------------
> 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.



Cullen

Sorry for the delay in responding due to Thanksgiving holiday last week.

Currently 3GPP mobile devices all use the IMEI as their unique device identifier. The IMEI is the only device identifier that can be transported in 3GPP circuit switched signaling without further enhancement of the circuit switched signaling protocol. 3GPP has specified handover of calls between direct access via IMS and indirect access via the Circuit switched domain while providing all services via servers hosted in the IMS. To do this a mobile switching center server (MSC server) enhanced for ICS (IMS centralized services) SIP registers on behalf of the IMS terminal when that terminal is attached via the circuit switched domain. In order that the IMS terminal be reachable using the same GRUU regardless of whether it is connected directly via IMS or indirectly via the MSC server enhanced for ICS, the MSC server enhanced for ICS needs to use the same Instance ID when it registers with the IMS as the IMS terminal does when it registers directly with IMS. Since the only device identifier that is transportable via the CS domain signaling to the MSC server enhanced for ICS is the IMEI the Instance ID needs to contain the IMEI of the terminal when the terminal registers directly with IMS or when the MSC server enhanced for ICS registers on the terminal's behalf.

Additionally provision is made in 3GPP systems for checking of the IMEI (on black lists or white lists) in order that mobiles which have for example been reported as stolen can be blocked from access to the systems (in some countries such as Belgium (I understand) this is a regulatory requirement and in some other countries such as the UK mobile operators have voluntary provided this capability to address this societal concern). 3GPP TS 22.016 states:

"It shall be possible to perform the IMEI check at any access attempt, except IMSI detach, and during an established call at any time when a dedicated radio resource is available, in accordance with the security policy of the PLMN operator. It shall also be possible to perform the IMEI check when a UE is IMS registered."

Thus it needs to be possible to perform the IMEI check during the IMS/SIP registration of the terminal. Note that IMS procedures using reg-events can also force an IMS terminal to re-register during a call thus allowing the IMEI check to also be performed during an IMS call (using the same registration procedure check).

I hope this explains the underlying reasons why 3GPP has chosen to use IMEI for the Instance ID for IMS terminals.

Andrew

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Cullen Jennings
Sent: Friday, November 19, 2010 10:27 AM
To: DISPATCH list
Subject: Re: [dispatch] Revised draftdraft-allen-dispatch-imei-urn-as-instanceid



With my WG hat chair on ... This draft has IPR declared on it which makes me need to ask the questions of what is this draft does that we could not do some different way. So what is this draft provides that GRUU does not?


On Oct 29, 2010, at 11:00 AM, Andrew Allen wrote:

> A revised version of draft-allen-dispatch-imei-urn-as-instanceid was uploaded earlier this week and can be found at
>  
> http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-01.txt
>  
> Please provide any feedback.
>  
> Thanks
> Andrew Allen
> --------------------------------------------------------------------- 
> 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. _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch




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