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

[Gomes, Chuck]

Please see my thoughts below.

Chuck

-----Original Message-----
From: gnso-rds-pdp-wg-bounces at icann.org
[mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Greg Aaron
Sent: Wednesday, December 07, 2016 5:24 PM
To: Andrew Sullivan <ajs at anvilwalrusden.com>; gnso-rds-pdp-wg at icann.org
Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] key concepts: say "contact data"
when that is what we mean

Dear Mike:

Thanks.  And I think Andrew gets what I'm saying.  

"Should gTLD registration data be accessible for any purpose or only for
specific purposes?"  The question assumes we're talking about contact data.
With thin data, I suggest that the question doesn't matter much -- none of
that data's sensitive.  The question only really matters when we're talking
about contact data (PII).  

[Gomes, Chuck] I don't think I agree that the question assumes we are talking about contact data or that thin data is never sensitive.  I believe that Andrew suggested the same thing.  For example, is it possible for IP numbers to be sensitive?  I also think that we may have to examine 'Other Data' (Data that is not thin or contact data).  I would like to think that thin data and other data may be easier but we may still have to work on them.
  

Note what I said: "This is not a proposal to publish thin data only."  I'm
simply wondering if everyone can agree that having an RDS is essential, and
that publishing at least the thin data via it is essential for many valid
and public purposes.  Thin data may not satisfy all valid purposes, but
requiring the world to get along without thin data seems untenable.
Agreeing to this would be a step forward for the WG.   Progress has been
hard to find here, nearly a year in....

[Gomes, Chuck] I suspect that making the decision that having an RDS is essential may have to happen later.  Don't get me wrong, it would be nice if we could agree on that now, but it may be premature to do that.  We should certainly agree on what the valid and public purposes are first.  I wouldn't be surprised if we came to conclusion that getting 'along without thin data seems untenable' but I believe we will have to specifically come to that conclusion in our deliberation.  I do like Andrew's suggestion that we should start by focusing on think data.

Then would  come the more difficult discussion about contact data.  Your
observations do not invalidate my approach.    I don't think my idea favors
or endangers anyone's ability to argue their positions about the collection
and publication of contact data (PII), nor does it endangers future
innovation as far as I am aware.    FWIW, I agree with you that the legal
construct upon which the domain name system is based recognizes the
Registrant and the Registrant Data that it provides.  

Let's not get too hung up on trademark, nexus, reseller, etc. data.  These
miscellaneous fields exist and we should be aware of them, and that future
innovation (like inventing more)  is possible.  But also 99.5% of gTLD
domains don't employ those extra fields at this time, and they're not a
reason to torpedo anything at this stage.  The general categories are
useful.  If we want to think of it as PII data versus not-PII data, that's a
way to think of it too.   Anyway, we are good engineers, and good engineers
are aware of the corner cases while also keeping the big picture in mind.

 [Gomes, Chuck]  The more immediate focus should be on the 99.5% but I think we will still have to cover the corner cases at least in a general sense. 

All best,
--Greg  

**********************************

-----Original Message-----
From: gnso-rds-pdp-wg-bounces at icann.org
[mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Andrew Sullivan
Sent: Wednesday, December 7, 2016 4:35 PM
To: gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] key concepts: say "contact data" when that is
what we mean

Hi Michael,

On Wed, Dec 07, 2016 at 04:13:01PM -0500, Michael D. Palage wrote:

> I appreciate Greg's historical context of Whois data primarily being 
> for purposes of "contacting" the registrant of a domain name using 
> those data fields with personally identifying information. However, I 
> think introducing/relying upon the concept of "CONTACT DATA" as 
> proposed by Greg while well intentioned will only lead to greater
confusion.

If instead of "contact data" we want to call it "the flying monkey
all-singing-and-dancing circus data", I don't care.  I think Greg's point is
that there are several different kinds of data here, and we could start with
the little set that is unambiguously related to the domain _qua_ domain, and
hammer out some agreement there.  That would have the salubrious effects
that we would have found some common ground, it would allow us to close
coversations on some parts of the data, and it would allow us to acknowledge
that there are at least two classes of data here.  For that reason,

> First Greg acknowledges that not ALL data other than the thin 
> technical data falls within his CONTACT DATA definition

we might well acknowledge that there are at least two kinds of data we're
talking about, and start with the first class.  Then we could work on a
second class.  At some point, we'll run out of classes that people will be
able to mention; we don't need to know in advance exactly how many there
are.  They're surely fewer than 30.

> Second, the use of this terminology ignores the reality in the 
> marketplace that Registrant data is widely relied upon to make legal 
> determinations

What these different classes of data are used _for_ is an entirely different
problem from what kinds of data they are.  Those potential uses, indeed, are
something we need to consider when asking under what circumstances a given
datum may be disclosed, and to whom.  But the use is not part of the
definition of the kind of data.

> "ICANN's WHOIS Lookup gives you the ability to lookup any generic 
> domains, such as "icann.org" to find out the registered domain owner."

I do not believe one can argue from the premise that this is how things have
always been done to the conclusion that it is how things _should_ be done.

> So I think we stick to one of the first things I learned as a young 
> engineer. Keep It Simple Stupid (KISS)

Agreed.  And for that reason, we should start with the simple cases and
forge some consensus there before we start with the hard cases.

Best regards,

A


--
Andrew Sullivan
ajs at anvilwalrusden.com
_______________________________________________
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