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

[James Galvin]

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.

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
>>