<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="+1"><font face="Lucida Grande">If I might offer a
comment on this from the data protection perspective...the
concept of "sensitive" data is difficult. It appears in the 95
EU Directive, applying to health data, religious data etc....but
some data that is in those categories is not sensitive (eg the
fact that I got a flu shot, like 49% of Canadians). Other data
that is not considered sensitive or is protected (eg the fact
that a woman purchases a maternity vitamin at a pharmacy) could
be harvested in our world of big data, and cause her employer to
cease her employment. So I dislike the term, although the
concept of risk in disclosure of data elements is a good one.
The next problem one has to face is that end users usually have
a very poor perception of the potential risk of data disclosure,
so our policies have to reflect that risk from the perspective
of the experts here assembled. I understand only a couple of
aspects of that risk....data and security and some regulatory
issues. I have a really hard time figuring out the data map,
how far this stuff is travelling, who is harvesting it, what the
secondary value-added service market looks like, who purchases
those products.....etc. I depend on you folks in the business
to tell us that, or point me to some tutorial that will help be
do the research. <br>
cheers Stephanie<br>
<br>
</font></font>
<div class="moz-cite-prefix">On 2016-12-09 10:50, James Galvin
wrote:<br>
</div>
<blockquote
cite="mid:1FE97CFE-6B3B-4BA4-B8A0-D235FC2A7BA3@afilias.info"
type="cite">
<br>
<br>
On 8 Dec 2016, at 17:28, DANIEL NANGHAKA wrote:
<br>
<br>
<blockquote type="cite">I look at sensitive data as data that
exposes a threat to the registrant -
<br>
this is also contact information.
<br>
</blockquote>
<br>
This is probably too broad a definition. I suspect a case could
be made that most if not all data is a potential threat to a
registrant because in our world of big data aggregation and
correlation are always a threat.
<br>
</blockquote>
This is a serious problem with data protection law these days,
regulatory overreach. While it is true that big data is a
significant threat, nobody has come up with a satisfactory solution
that I have seen.<br>
<blockquote
cite="mid:1FE97CFE-6B3B-4BA4-B8A0-D235FC2A7BA3@afilias.info"
type="cite">
<br>
I don’t have a suggestion just yet for how to restrict this but it
is otherwise a possible starting point for discussions.
<br>
<br>
Jim
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<br>
Other records like the NS records may not be sensitive data.
<br>
<br>
Third parties pick this data and use it for spam. This is the
point where I
<br>
think restricted Access is important. Where there is need for
the data the
<br>
registrant should be asked for consent that the data be shared.
<br>
<br>
Daniel
<br>
<br>
<br>
Regards
<br>
Nanghaka Daniel K.
<br>
Executive Director - ILICIT Africa / Council Member - FOSSFA /
Community
<br>
Lead - ISOC Uganda Chapter
<br>
Mobile +256 772 898298 (Uganda)
<br>
Skype: daniel.nanghaka
<br>
<br>
----------------------------------------- *"Working for Africa"
*
<br>
-----------------------------------------
<br>
<br>
<br>
<br>
On Thu, Dec 8, 2016 at 10:11 PM, James Galvin
<a class="moz-txt-link-rfc2396E" href="mailto:jgalvin@afilias.info"><jgalvin@afilias.info></a> wrote:
<br>
<br>
<blockquote type="cite">
<br>
<br>
On 7 Dec 2016, at 9:55, Greg Aaron wrote:
<br>
<br>
In the coming discussions, one approach could be: There are
good reasons
<br>
<blockquote type="cite">to publish the thin data … is there
any compelling reason _not_ to publish
<br>
it? If we can take care of this low-hanging fruit, we will
solve part of
<br>
the puzzle and we can concentrate on the issues around
contact data. This
<br>
is not a proposal to publish thin data only. It’s an
attempt to
<br>
disentangle concepts and find a way forward. Not all data
is the same, so
<br>
let’s stop treating all data the same. We may not have to
iterate
<br>
repeatedly about thin data.
<br>
<br>
</blockquote>
<br>
I agree with the principle that we should tease apart
“registration data”
<br>
into a few different categories. The discussion in the rest
of this thread
<br>
has been focused on that and I’ll state I support it. My
current view is
<br>
that there are at least three categories of data: PII (e.g.,
contact
<br>
information), operational and explicitly not-PII (e.g.,
registrar ID and NS
<br>
records), and other (e.g., registries with specific
requirements).
<br>
<br>
I have two concerns with this discussion though. First, we
keep talking
<br>
about “publishing” data. Greg is careful to point out he’s
not talking
<br>
about publishing, per se, but he doesn’t mention what we are
talking about.
<br>
<br>
Second, given we understand our data (which is a reason to
categorize it)
<br>
there are at least three topics to talk about with respect to
that data.
<br>
<br>
1. Why do we care about this data, or perhaps, what is the
purpose of the
<br>
data? The answer to these questions is both critical and
essential. They
<br>
will drive the answer to the next two questions. In my
opinion, without an
<br>
answer to these questions (eventually, if not first or early
in our
<br>
process), discussions about the next two topics will never
come to a
<br>
conclusion. By the way, also my opinion, any answer that
somehow embodies
<br>
a reference to the existing system and service is irrelevant.
<br>
<br>
2. What are the data collection requirements? This includes
who, what,
<br>
where, why, and how, including storage.
<br>
<br>
3. What are the publication requirements? Might be zero.
Greg suggests
<br>
above that we could approach the problem of publication in
some cases by
<br>
answering the following question, “Is there any compelling
reason not to
<br>
publish it?” I will object to this. This is never the right
question.
<br>
The right question is always, “Why publish it?” You can’t
publish it if
<br>
you don’t collect it and you don’t collect it if you don’t
have a need for
<br>
it.
<br>
<br>
All questions must be answered in the positive. Otherwise
what’s the
<br>
point of our discussion? The answer will always default to be
collect
<br>
everything and publish everything, and then let the lawyers
fight about
<br>
what’s public.
<br>
<br>
Jim
<br>
<br>
_______________________________________________
<br>
gnso-rds-pdp-wg mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a>
<br>
<br>
</blockquote>
</blockquote>
<br>
<br>
_______________________________________________
<br>
gnso-rds-pdp-wg mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br>
</blockquote>
<br>
</body>
</html>