[gnso-rds-pdp-wg] key concepts: say "contact data" when that is what we mean
James Galvin
jgalvin at afilias.info
Fri Dec 9 15:50:46 UTC 2016
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
>>
More information about the gnso-rds-pdp-wg
mailing list