Hi David,
Thanks for the review. See responses below.
On Wed, Jul 17, 2013 at 7:54 PM, Black, David wrote:
> Document: draft-ietf-trill-directory-framework-05
> Reviewer: David L. Black
> Review Date: July 17, 2013
> IETF LC End Date: July 18, 2013
>
> Summary:
> This draft is on the right track
Just wanted to point out that both Apple (for iOS) and Google (for Android)
have strongly discouraged the use of IMEI to identify devices for the
purposes of application software. There are privacy, quality, and
availability issues with their use. Apple has removed the ability of
developers to wo
Hi Donald,
All of your responses are fine with me.
Thanks,
--David
> -Original Message-
> From: Donald Eastlake [mailto:d3e...@gmail.com]
> Sent: Friday, July 19, 2013 7:56 AM
> To: Black, David
> Cc: ldun...@huawei.com; ra...@alum.mit.edu; i...@yahoo-inc.com; General Area
> Review Team;
Tim
I suggest you also read
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
That will explain the primary application of this URN which is intended for use
in the 3GPP cellular standards.
Andrew
From: Tim Bray [mailto:tb...@textuality.com]
Sent: Friday, July 19, 2
On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen wrote:
> I suggest you also read
>
> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
>
Quoting from that document: “If a URN scheme other than UUID is used, the
UA MUST only use URNs for which an RFC (from the IETF strea
On 19 July 2013 08:38, Andrew Allen wrote:
>
> I suggest you also read
> http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
I read that document. The placement of IMEI in the instance id is a
little bit of a non-sequitur to my thinking.
There are three cases identified
At 08:02 19-07-2013, Tim Bray wrote:
I'm not sure from reading the draft what the goal of having this URN
namespace is, but if it involves encouraging its use by application
developers, I'm pretty sure it's a bad idea.
I agree that it sounds like a bad idea to encourage application
developers
On Fri, Jul 19, 2013 at 9:52 AM, S Moonesamy wrote:
>
> It would be easier to have the draft discuss the GSMA URN only. The
> alternative is to have the draft discuss the privacy considerations of
> using IMEI and IMEISV.
>
Good catch. Assuming this is a good idea (I’m dubious) it would be
com
Tim
Do you not think that the text in the security considerations section::
"because IMEIs can be loosely correlated to a user, they need to be treated as
any other personally identifiable information. In particular, the IMEI URN MUST
NOT be included in messages intended to convey any level of
Hm, I confess that I searched the text of the draft for the word “privacy”
and jumped to conclusions upon seeing no matches. Probably a good idea to
work it in for impatient folk like me.
I would expand that section to point out that since the IMEI survives
device wipes and changes of possession,
On 07/19/2013 11:53 PM, Andrew Allen wrote:
> the IMEI URN MUST NOT be included in messages intended to convey any level of
> anonymity
That seems both perfect RFC 6919 fodder and disingenuous at
the same time (how can a message convey a level of anonymity?).
I need to read the draft but this
> IMEIs are very pervasive, carried around by 100's of millions
> of people and generally not intended to be shared with the
> Internet.
my american social security card, which admittedly is a bit old, has
"Not to be used for identification" emblazoned on it in red.
for me, a seminal document was
Resent on different list …
I would like to raise an issue interoperability with this payload specification
that we are currently having with WebRTC implementations. In WebRTC, and many
other places, you want SDP to be able to control the resolution of the image
(or at least the outer limits o
13 matches
Mail list logo
