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 scott.b...@gmail.com:
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
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
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
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
On Sat, Jul 20, 2013 at 10:51 AM, Stephen Farrell
stephen.farr...@cs.tcd.ie 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
--On Saturday, July 20, 2013 15:51 +0100 Stephen Farrell
stephen.farr...@cs.tcd.ie 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
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
On 07/20/2013 04:06 PM, Scott Brim wrote:
On Sat, Jul 20, 2013 at 10:51 AM, Stephen Farrell
stephen.farr...@cs.tcd.ie 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
On 07/20/2013 04:31 PM, John C Klensin wrote:
--On Saturday, July 20, 2013 15:51 +0100 Stephen Farrell
stephen.farr...@cs.tcd.ie 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
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
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 aal...@blackberry.comwrote:
The URN containing the IMEI is used by all mobile phones that support
voice over LTE. It is a
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
On Sat, Jul 20, 2013 at 1:08 PM, Andrew Allen aal...@blackberry.com 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
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
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 scott.b...@gmail.com; sm+i...@elandsys.com
sm+i...@elandsys.com; ietf@ietf.org
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
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
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
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
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
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
--On Saturday, July 20, 2013 15:19 -0700 Doug Barton
do...@dougbarton.us 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
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
On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen aal...@blackberry.com wrote:
Can it please be explained how the IMEI URN when used as stated in
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
Is any more harmful than as the IMEI is used today by over 90% of mobile
--On Saturday, July 20, 2013 11:36 -0700 Tim Bray
tb...@textuality.com 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
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
--On Saturday, July 20, 2013 19:17 -0700 Tim Bray
tb...@textuality.com 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
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
33 matches
Mail list logo
