<div>Seems like an inescapably rational position to me.</div><div><br></div><div>Greg</div><div><br><div class="gmail_quote"><div>On Wed, May 31, 2017 at 2:03 PM Andrew Sullivan <<a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Wed, May 31, 2017 at 10:09:46AM -0700, Michael Peddemors wrote:<br>
><br>
> We aren't discussing DNS or any other places that data is available as part<br>
> of this working group. Only the informed consent of data held in whois thin<br>
> data.<br>
<br>
I feel like maybe some of us are talking at cross purposes because we<br>
seem not to be talking in a common language. I suspect that I have<br>
some pretty dark corners in my understanding of the legal and policy<br>
language here. Equally, it seems to me that some others have a very<br>
different understanding of some of these terms than the one I have.<br>
Mine is informed by data theory and many years of experience with<br>
these kinds of systems. I thought maybe it'd be useful for me to lay<br>
out what I understand, in the hopes that maybe others can spot ways in<br>
which my understanding does not match their model.<br>
<br>
In my view of the world, the fundamental purpose of the entire<br>
registration system is to create name spaces on the Internet using the<br>
DNS. There are certain data that are absolutely necessary for that:<br>
the name itself, a record of who is in control of it, the NS records<br>
that create the delegation, and so on. These things carve out a name<br>
space from the global Internet name space (which is founded in the<br>
root zone, which is why ICANN is involved in this at all). People<br>
might want to create domain names for reasons _other_ than making them<br>
work via the DNS, but those are derivative and secondary purposes that<br>
supervene on the basic purpose of the registration system.<br>
<br>
When you create an entry in the domain name space (anywhere in it --<br>
immediately beneath the root, beneath a TLD, or at<br>
<a href="http://very.deep.delegation.crankycanuck.ca" rel="noreferrer" target="_blank">very.deep.delegation.crankycanuck.ca</a>), you are performing a<br>
"registration", and the authority who has the ability to create that<br>
entry is called the "registry". Over time, in the part of the name<br>
space near the root, we created some formalisms about this, including<br>
a model that looks a little like "wholesale" vs "retail" markets. The<br>
result of this is the R/R/R model that governs the contracted-party<br>
world at ICANN. The result of this is that we have a distributed<br>
database, operated by multiple parties along the lines of separation<br>
implied by the business model and the authority distributions.<br>
<br>
Modern registries contain additional associated data about domain<br>
names created in the bailiwick of the registry. That is "registration<br>
data", and the RDS we are talking about is the generic access protocol<br>
by which that data may be accessed.<br>
<br>
>From my point of view, the data "in the registry", "in the whois", and<br>
(when relevant) "in the DNS" is _the same_ data. It might be<br>
instantiated in different databases -- that is, there might be<br>
different servers where it lives. But it's the same data.<br>
Distinctions between what is "in the registry", "in the registrar",<br>
and "in the whois" are meaningless to me for that reason.<br>
<br>
Some additional data about the registrations are a result of the act<br>
of registration itself. Some of that data is held by the operator of<br>
the registry, and some by the agents that perform registrations (the<br>
registrars). These are things like the creation and update dates --<br>
in effect, metadata about state transformations and so on. My<br>
understanding is that, when we talk about "thin data", it is either<br>
this sort of action-generated metadata, or else it is data that is<br>
intrinsically necessary for using the data (e.g. to make names work or<br>
else to make the RDS itself work). It is that basic fact of what the<br>
data is for that makes me think thin data cannot be subject to<br>
controls for privacy and other such reasons.<br>
<br>
Some additional data about the registrations are data that need to be<br>
provided by someone. This additional data is what I think we are<br>
talking about generically when we refer to "thick data". Thick data<br>
has many species, and probably we are going to need to discuss in<br>
depth the different kinds of data in there.<br>
<br>
I hope this makes at least one perspective a little clearer.<br>
<br>
Best regards,<br>
<br>
A<br>
<br>
--<br>
Andrew Sullivan<br>
<a href="mailto:ajs@anvilwalrusden.com" target="_blank">ajs@anvilwalrusden.com</a><br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br>
</blockquote></div></div>