[gnso-rds-pdp-wg] IMPORTANT: Reminder - Poll from 28 June Meeting

Sun Jul 16 06:29:13 UTC 2017

First - I agree with Kathy and Sara’s comments - we are losing sight of the basic question - what data must be collected to provide the services of domain name registration.  That is the place that basic data retention principles start and it is most certainly where the GDPR conversations will start.  Asking what all of the uses are is starting in the wrong place.

And, because Andrew has far more knowledge and experience than I do - and generally manages to clarify the issues, I am including text from one of the many emails he has sent just to keep us on the right track.

Holly

I feel like maybe some of us are talking at cross purposes because we
seem not to be talking in a common language.  I suspect that I have
some pretty dark corners in my understanding of the legal and policy
language here.  Equally, it seems to me that some others have a very
different understanding of some of these terms than the one I have.
Mine is informed by data theory and many years of experience with
these kinds of systems.  I thought maybe it'd be useful for me to lay
out what I understand, in the hopes that maybe others can spot ways in
which my understanding does not match their model.

In my view of the world, the fundamental purpose of the entire
registration system is to create name spaces on the Internet using the
DNS.  There are certain data that are absolutely necessary for that:
the name itself, a record of who is in control of it, the NS records
that create the delegation, and so on.  These things carve out a name
space from the global Internet name space (which is founded in the
root zone, which is why ICANN is involved in this at all).  People
might want to create domain names for reasons _other_ than making them
work via the DNS, but those are derivative and secondary purposes that
supervene on the basic purpose of the registration system.

When you create an entry in the domain name space (anywhere in it --
immediately beneath the root, beneath a TLD, or at
very.deep.delegation.crankycanuck.ca), you are performing a
"registration", and the authority who has the ability to create that
entry is called the "registry".  Over time, in the part of the name
space near the root, we created some formalisms about this, including
a model that looks a little like "wholesale" vs "retail" markets.  The
result of this is the R/R/R model that governs the contracted-party
world at ICANN.  The result of this is that we have a distributed
database, operated by multiple parties along the lines of separation
implied by the business model and the authority distributions.

Modern registries contain additional associated data about domain
names created in the bailiwick of the registry.  That is "registration
data", and the RDS we are talking about is the generic access protocol
by which that data may be accessed.

From my point of view, the data "in the registry", "in the whois", and
(when relevant) "in the DNS" is _the same_ data.  It might be
instantiated in different databases -- that is, there might be
different servers where it lives.  But it's the same data.
Distinctions between what is "in the registry", "in the registrar",
and "in the whois" are meaningless to me for that reason.

Some additional data about the registrations are a result of the act
of registration itself.  Some of that data is held by the operator of
the registry, and some by the agents that perform registrations (the
registrars).  These are things like the creation and update dates --
in effect, metadata about state transformations and so on.  My
understanding is that, when we talk about "thin data", it is either
this sort of action-generated metadata, or else it is data that is
intrinsically necessary for using the data (e.g. to make names work or
else to make the RDS itself work).  It is that basic fact of what the
data is for that makes me think thin data cannot be subject to
controls for privacy and other such reasons.

Some additional data about the registrations are data that need to be
provided by someone.  This additional data is what I think we are
talking about generically when we refer to "thick data".  Thick data
has many species, and probably we are going to need to discuss in
depth the different kinds of data in there.

I hope this makes at least one perspective a little clearer.

On 15 Jul 2017, at 6:01 am, Kathy Kleiman <kathy at kathykleiman.com> wrote:

> +1 to Sara's comment. 
> 
> Question: I thought the question on the table in Johannesburg was what data needed to be collected in order to provide the service of domain name registration and maintenance?  How does that lead to a referendum on the data elements of the EWG report?
> 
> By way of background, the EWG report changed considerably from its "draft" to its "final" form - adding dozens of pages to the final report never reviewed or even seen by the ICANN Community. These included many funky new registration data elements, some which were optional, some which were not, some which were clearly defined, and many which were not. Questions raised about many of these registration data elements at the ICANN Meeting in London with the EWG were never answered.  To this day, I still don't understand the definition of many of these data elements.
> 
> A referendum on these fields now seems like a very odd place to be right now. 
> 
> Best, Kathy
> 
> On 7/14/2017 2:12 PM, Sara Bockey wrote:
>> I believe these polling questions are premature.  Given GDPR and outstanding legal reviews, I don’t see how I can answer these questions outside of a “wish list” response.
>>  
>> Sara
>>  
>>  
>> From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Lisa Phifer <lisa at corecom.com>
>> Date: Wednesday, July 12, 2017 at 10:08 AM
>> To: "gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>
>> Subject: [gnso-rds-pdp-wg] IMPORTANT: Reminder - Poll from 28 June Meeting
>>  
>> Dear all,
>> 
>> Many thanks to the 14 WG members who have already completed this week's poll and provided thoughtful rationale for and against data elements beyond the minimum public data set (MPDS).
>> 
>> For those who have not yet done so, please be sure to leave yourself extra time to review the handout before taking this week's longer-than-usual poll.
>> 
>> Link to the poll:
>> https://www.surveymonkey.com/r/P5MBXZ2
>> 
>> Link to the handout, for info about each data elements beyond the MPDS:
>> https://community.icann.org/download/attachments/66086729/28JunePoll-DataElements-ExpandedHandout.pdf 
>> 
>> Link to the last meeting's recording and transcript where this approach was discussed:
>> https://community.icann.org/x/lATfAw
>> 
>> This poll will close at COB this Saturday 15 July.
>> 
>> Best, Lisa
>> 
>> 
>> At 04:05 PM 7/8/2017, Lisa Phifer wrote:
>> 
>> Dear all,
>>  
>> In follow-up to our ICANN59 F2F WG meeting, all RDS PDP WG Members are encouraged to participate in the following poll:
>>  
>> https://www.surveymonkey.com/r/P5MBXZ2
>>  
>> Also attached is an extended version of the Data Elements handout used for deliberation in our F2F meeting. This handout provides information about each data element in this poll, extracted from the EWG Final Report.Please use time previously set aside for our cancelled 11 July meeting to review this handout and then complete this week?s longer-than-usual poll.
>>  
>> Responses should be submitted through the above URL. For offline reference, a PDF of poll questions can also be found at:
>>  
>> https://community.icann.org/download/attachments/64947348/Poll-from-28JuneCall.pdf 
>>  
>> This poll will close at COB Saturday 15 July.  Poll results and the attached handout will be discussed in our 18 July 16.00 UTC WG meeting.
>>  
>> Please note that you must be a WG Member to participate in polls. If you are a WG Observer wishing to participate in polls, you must first contact gnso-secs at icann.org to upgrade to WG Member.
>>  
>> Regards,
>> Lisa
>> 
>> 
>> _______________________________________________
>> 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/20170716/cce4d8a5/attachment-0001.html>