Thanks, SM, for finding what I said back in 2010. I still think this
is architected wrong, conflating devices with communication endpoints
higher up the stack, and steers us toward a path toward eventually
"needing" to reduce privacy even more. However, 3GPP has apparently
already already started
Hi
Yes it true , but more argumentations are welcome
Sinverely yours
2013/7/20, Scott Brim :
> Thanks, SM, for finding what I said back in 2010. I still think this
> is architected wrong, conflating devices with communication endpoints
> higher up the stack, and steers us toward a path toward e
At 15:53 19-07-2013, Andrew Allen wrote:
Do you not think that the text in the security considerations section::
"because IMEIs can be loosely correlated to a user, they need to be
treated as any other personally identifiable information. In
particular, the IMEI URN MUST NOT be included in mes
Hi.
Borrowing from several other notes and comments, it seems to me
that we have three interlocking issues that keep recurring and
producing long discussions. They are by no means independent of
this particular draft, but seem to be becoming generic.
(1) Are we willing to publish (or even standa
Wrt privacy in general...
On 07/20/2013 02:56 PM, John C Klensin wrote:
> Any volunteers
> to get in front of the mic lines?
I'd welcome that discussion. I'd love to see us have a
BCP61-like [1] RFC on the topic of privacy and I also
reckon that that'd help short-cut a number of IETF LCs
and IE
On Sat, Jul 20, 2013 at 10:51 AM, Stephen Farrell
wrote:
>
> Wrt privacy in general...
>
> On 07/20/2013 02:56 PM, John C Klensin wrote:
>> Any volunteers
>> to get in front of the mic lines?
>
> I'd welcome that discussion. I'd love to see us have a
> BCP61-like [1] RFC on the topic of privacy a
--On Saturday, July 20, 2013 15:51 +0100 Stephen Farrell
wrote:
>...
> But, even if the outcome wasn't a BCP along the lines
> I'd prefer, I think such a beast would still be worth
> having if it meant we could avoid a whole lot of these
> kinds of similar discussions on individual drafts.
Tha
Overall, I think the IETF has a marketing problem addressing its #1
customer base - electronic participants.
I was somewhat hoping to see more done in the mentor area of assisting
electronic participants. Of coarse, this sort of electronic mentoring it
could include an end goal to get folks mo
On 07/20/2013 04:06 PM, Scott Brim wrote:
> On Sat, Jul 20, 2013 at 10:51 AM, Stephen Farrell
> wrote:
>>
>> Wrt privacy in general...
>>
>> On 07/20/2013 02:56 PM, John C Klensin wrote:
>>> Any volunteers
>>> to get in front of the mic lines?
>>
>> I'd welcome that discussion. I'd love to see
On 07/20/2013 04:31 PM, John C Klensin wrote:
>
>
> --On Saturday, July 20, 2013 15:51 +0100 Stephen Farrell
> wrote:
>
>> ...
>> But, even if the outcome wasn't a BCP along the lines
>> I'd prefer, I think such a beast would still be worth
>> having if it meant we could avoid a whole lot of
The URN containing the IMEI is used by all mobile phones that support voice
over LTE. It is a dependency for 3GPP release 8 (which was completed about end
of 2008). So yes it is going to be used and its more than 3 years of 3GPP work
invested and is already incorporated into many devices.
In t
So if it’s going to be used, exactly as specified, whatever we do, then
what value is added by the IETF process? -T
On Sat, Jul 20, 2013 at 11:28 AM, Andrew Allen wrote:
>
> The URN containing the IMEI is used by all mobile phones that support
> voice over LTE. It is a dependency for 3GPP relea
Tim
The quote is from RFC 5626 which also states:
"3.1. Summary of Mechanism
Each UA has a unique instance-id that stays the same for this UA even if the UA
reboots or is power cycled."
Since the UUID in the instance ID is also static how is this significantly
different in terms of privacy c
On Sat, Jul 20, 2013 at 1:08 PM, Andrew Allen wrote:
>
> The quote is from RFC 5626 which also states:
>
> "3.1. Summary of Mechanism
>
> Each UA has a unique instance-id that stays the same for this UA even if
> the UA reboots or is power cycled."
>
> Since the UUID in the instance ID is also st
Tim
Mobile phones are not usually completely "factory reset" if resold and even if
they were a UUID may still have been stored in non volatile as it may have been
generated during final test.
In any case if the IMEI was to persist after a resale how would that be a
privacy problem given the re
I think IANA registration of namespaces has a lot of value.
From: Tim Bray [mailto:tb...@textuality.com]
Sent: Saturday, July 20, 2013 01:36 PM Central Standard Time
To: Andrew Allen
Cc: scott.b...@gmail.com ; sm+i...@elandsys.com
; ietf@ietf.org
Subject: Re: Last call: draft-montemurro-gsma-i
On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen wrote:
> Tim
>
> The quote is from RFC 5626 which also states:
>
> "3.1. Summary of Mechanism
>
> Each UA has a unique instance-id that stays the same for this UA even if the
> UA reboots or is power cycled."
>
> Since the UUID in the instance ID is al
Except that for normal usages at the application level, the UUID is
generated by the app and placed in its private per-app storage, which is
always erased on a factory-reset. To Andrew Allen: I strongly recommend
factory-resetting your phone before you sell it, and also factory-resetting
any phone
On 07/20/2013 01:48 PM, Andrew Allen wrote:
I think IANA registration of namespaces has a lot of value.
I think backfilling registrations for poached identifiers sets a
bad/dangerous example.
Doug (not necessarily speaking with any hats, current or former)
Equivalence is equivalence the rest seems subjective to me - is the glass half
full or half empty.
The point is they are no more or less harmful.
Can it please be explained how the IMEI URN when used as stated in
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
Is a
Martin
There are obviously always alternative design choices but why would you want to
include both a pre assigned device ID and a generated device ID in the same
message?
Andrew
- Original Message -
From: Martin Thomson [mailto:martin.thom...@gmail.com]
Sent: Friday, July 19, 2013 11
Tim
This is not the "normal" 3GPP IMS scenario. In IMS the device as a whole is
considered as a single UA, multiple IMS applications will need to share a
common registration procedure that is provided by the underlying OS.
Otherwise multiple IMS registrations from different applications on a 3G
> I think IANA registration of namespaces has a lot of value.
let me ask the other side of the coin, in this case, what harm will be
done by not making this an rfc and registering the imei uri?
and i am not a fan of the mrs goldberg argument.
randy
On 07/20/2013 03:48 PM, Randy Bush wrote:
I think IANA registration of namespaces has a lot of value.
let me ask the other side of the coin, in this case, what harm will be
done by not making this an rfc and registering the imei uri?
None, because we lost the battle over protocol parameter po
Randy
Are you suggesting its not a problem if everyone were to just go off and define
namespaces and not have them registered with IANA?
I don't think that's a good precedence.
The GSMA is the authoritative organisation for some identifers that have been
used in billions of mobile devices for
--On Saturday, July 20, 2013 15:19 -0700 Doug Barton
wrote:
> On 07/20/2013 01:48 PM, Andrew Allen wrote:
>> I think IANA registration of namespaces has a lot of value.
>
> I think backfilling registrations for poached identifiers sets
> a bad/dangerous example.
Doug,
This is another of thos
Hi Andrew,
At 13:48 20-07-2013, Andrew Allen wrote:
I think IANA registration of namespaces has a lot of value.
draft-montemurro-gsma-imei-urn-16 discusses about two namespaces:
(i) gsma
(ii) imei
It is not possible to get a IANA registration for (ii) as according
to draft-montemurro-gsm
On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen wrote:
> Can it please be explained how the IMEI URN when used as stated in
> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
> Is any more harmful than as the IMEI is used today by over 90% of mobile
> phones in use today
--On Saturday, July 20, 2013 11:36 -0700 Tim Bray
wrote:
> So if it's going to be used, exactly as specified, whatever
> we do, then what value is added by the IETF process? -T
See my earlier note, but mostly to aid in getting the
documentation right. For example, to the extent that the rece
Fair enough. I think it would be reasonable to ask that:
- the draft include the word “privacy”
- the draft discuss the issues around relying on an identifier that
persists across changes in device ownership
There may be an issue concerning a SIP-related identifier which is
unavailable on millio
--On Saturday, July 20, 2013 19:17 -0700 Tim Bray
wrote:
> Fair enough. I think it would be reasonable to ask that:
>
> - the draft include the word "privacy"
> - the draft discuss the issues around relying on an identifier
> that persists across changes in device ownership
>
> There may be
Hi John,
At 18:23 20-07-2013, John C Klensin wrote:
See my earlier note, but mostly to aid in getting the
documentation right. For example, to the extent that the recent
discussion results in a more complete treatment of privacy
and/or security considerations in the documentation, that is a
net
Tim
Firstly as stated in
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
the use of the IMEI as a SIP Instance ID only pertains to usage of SIP with the
3GPP IMS and if a device is not using IMS sing IMS without an IMEI uses IMS
then it will still use a UUID as the
Certainly text can be added to the draft to address concerns.
Could Tim please elaborate on what issues he sees when a device is transferred
between owners and what potential uses of the URN he has a concern with?
Certainly I can see that if it was used as address that had some permanence
then
34 matches
Mail list logo