[gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean

Fri Dec 9 17:30:55 UTC 2016

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

On 2016-12-09 10:50, James Galvin wrote:
>
>
> On 8 Dec 2016, at 17:28, DANIEL NANGHAKA wrote:
>
>> I look at sensitive data as data that exposes a threat to the 
>> registrant -
>> this is also contact information.
>
> 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.
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.
>
> I don’t have a suggestion just yet for how to restrict this but it is 
> otherwise a possible starting point for discussions.
>
> Jim
>
>
>
>
>>
>> Other records like the NS records may not be sensitive data.
>>
>> Third parties pick this data and use it for spam. This is the point 
>> where I
>> think restricted Access is important. Where there is need for the 
>> data the
>> registrant should be asked for consent that the data be shared.
>>
>> Daniel
>>
>>
>> Regards
>> Nanghaka Daniel K.
>> Executive Director - ILICIT Africa / Council Member - FOSSFA / Community
>> Lead - ISOC Uganda Chapter
>> Mobile +256 772 898298 (Uganda)
>> Skype: daniel.nanghaka
>>
>> ----------------------------------------- *"Working for Africa" *
>> -----------------------------------------
>>
>>
>>
>> On Thu, Dec 8, 2016 at 10:11 PM, James Galvin <jgalvin at afilias.info> 
>> wrote:
>>
>>>
>>>
>>> On 7 Dec 2016, at 9:55, Greg Aaron wrote:
>>>
>>> In the coming discussions, one approach could be: There are good 
>>> reasons
>>>> to publish the thin data … is there any compelling reason _not_ to 
>>>> publish
>>>> it?   If we can take care of this low-hanging fruit, we will solve 
>>>> part of
>>>> the puzzle and we can concentrate on the issues around contact 
>>>> data.  This
>>>> is not a proposal to publish thin data only.  It’s an attempt to
>>>> disentangle concepts and find a way forward.  Not all data is the 
>>>> same, so
>>>> let’s stop treating all data the same.  We may not have to iterate
>>>> repeatedly about thin data.
>>>>
>>>
>>> I agree with the principle that we should tease apart “registration 
>>> data”
>>> into a few different categories.  The discussion in the rest of this 
>>> thread
>>> has been focused on that and I’ll state I support it.  My current 
>>> view is
>>> that there are at least three categories of data: PII (e.g., contact
>>> information), operational and explicitly not-PII (e.g., registrar ID 
>>> and NS
>>> records), and other (e.g., registries with specific requirements).
>>>
>>> I have two concerns with this discussion though.  First, we keep 
>>> talking
>>> about “publishing” data.  Greg is careful to point out he’s not talking
>>> about publishing, per se, but he doesn’t mention what we are talking 
>>> about.
>>>
>>> Second, given we understand our data (which is a reason to 
>>> categorize it)
>>> there are at least three topics to talk about with respect to that 
>>> data.
>>>
>>> 1. Why do we care about this data, or perhaps, what is the purpose 
>>> of the
>>> data?  The answer to these questions is both critical and 
>>> essential.  They
>>> will drive the answer to the next two questions.  In my opinion, 
>>> without an
>>> answer to these questions (eventually, if not first or early in our
>>> process), discussions about the next two topics will never come to a
>>> conclusion.  By the way, also my opinion, any answer that somehow 
>>> embodies
>>> a reference to the existing system and service is irrelevant.
>>>
>>> 2. What are the data collection requirements?  This includes who, what,
>>> where, why, and how, including storage.
>>>
>>> 3. What are the publication requirements?  Might be zero. Greg suggests
>>> above that we could approach the problem of publication in some 
>>> cases by
>>> answering the following question, “Is there any compelling reason 
>>> not to
>>> publish it?”  I will object to this.  This is never the right question.
>>> The right question is always, “Why publish it?”  You can’t publish 
>>> it if
>>> you don’t collect it and you don’t collect it if you don’t have a 
>>> need for
>>> it.
>>>
>>> All questions must be answered in the positive.  Otherwise what’s the
>>> point of our discussion?  The answer will always default to be collect
>>> everything and publish everything, and then let the lawyers fight about
>>> what’s public.
>>>
>>> Jim
>>>
>>> _______________________________________________
>>> gnso-rds-pdp-wg mailing list
>>> gnso-rds-pdp-wg at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20161209/95e6ae84/attachment.html>