<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font size="+1"><font face="Lucida Grande">The answer is yes, and
thanks for the question. I was going to jump in earlier and challenge
the same assertion, but figured I had said enough recently. <span
class="moz-smiley-s1"><span>:-)</span></span><br>
</font></font></p>
<p><font size="+1"><font face="Lucida Grande">Furthermore, even the
datestamp and registrar-generated data may reveal association
of domains that leads you to the registrant. Let's say I
register ten names one day, with the same registrar, one of
which is Stephanieperrin.com, another is canadianconvertstoterrorism.com,
is it not possible to find that cluster of registrations, and
associate all domains with me? The data commissioners pointed
out many years ago (2003 I think, I can check) that they had a
problem with the reverse directory capability of the WHOIS,
because it was not at all necessary for the functioning of the
domain system, or at least ICANN had never made the argument.
They did not think WHOIS should offer the capability of
searching by registrant name. I would argue further, these
days, that publication of other data should not make registrant
identity reasonably retrievable.</font></font></p>
<p><font size="+1"><font face="Lucida Grande">There is a question
that I have in return. I presume that much of the current configuration
and policy of WHOIS and its data elements is based on simply
building on a flimsy foundation. A primary drive has been to
keep the costs to the registrars/registries down, since human
intervention is too expensive, and the appetite for data is
proving to be insatiable. I don't think either of those
parties were keen on publishing the personal data of their
customers, but the alternatives were not at all attractive. I
realize costs are to be dealt with later, but to what extent
has the technical capability increased to the point where we
can stop caring about whether the registrar/registry actually
publishes the data, or merely allows (for instance) a duly
authorized law enforcement agent in the appropriate
jurisdiction (ie one with a valid warrant or other judicial
authorization) to have access to the data in their files? I
realize we talked about this concept of tiered access
extensively in the EWG, but at least one member of that group
(me) never understood whether the tiered access we were
specing is something that is technically possible but financially,
legally and operationally infeasible. [Shortly before I
retired, I had to deal with a lot of breathless enthusiasm
about what "big data" was going to do to transform our risk
management in benefits programs. Totally infeasible, in my
view, given the state of our data systems, the accuracy rate,
the available budget, and the availability of investigators to
act on findings (a critical factor; once you know you have
fraud you have to do something about it if you are a government).
We won't even talk about whether such risk assessment is constitutionally
acceptable.] <br>
</font></font></p>
<p><font size="+1"><font face="Lucida Grande">We have a similar situation
here in my view. Much of what is going on now violates data
protection law, we have plenty of input from the DPAs pointing
that out. A new system ought to be attentive to that point.
In the example I cited, the relevant law enforcement authority
would have no legal trouble getting access to all data related
to the registrant of canadianconvertstoterrorism.com in my
view, the operative question is how fast can they do it, what
authority do they have to show and how, and what mechanisms
does the registrar/registry have to build in order to permit
this access securely (from all three perspectives, registrar,
registrant, and LEA) and at reasonable cost. The same
applies to others with less compelling interests (ie domain
speculators, IP and trademark owners, etc) and here we run
into complex cost and authorities issues, in my view.</font></font></p>
<p><font size="+1"><font face="Lucida Grande">Cheers Stephanie</font></font><br>
</p>
<br>
<div class="moz-cite-prefix">On 2016-12-08 06:17, Michael D. Palage
wrote:<br>
</div>
<blockquote cite="mid:033c01d25144$bab70bf0$302523d0$@palage.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Calibri\,Bold";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle29
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle30
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:808012982;
mso-list-type:hybrid;
mso-list-template-ids:1888375036 1855611294 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1328971313;
mso-list-type:hybrid;
mso-list-template-ids:2088126430 520373430 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Greg,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Again I am not trying to be confrontation,
but I would respectfully disagree with you on Thin Data never
containing PII.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Take for example the very domain name that
I am using on this email, PALAGE.COM. I believe it is
possible for PII to be contained in the very domain name
itself. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Take for example the following three domain
name examples <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">FirstName_SurName.CHRISTIAN<o:p></o:p></p>
<p class="MsoNormal">FirstName_SurName.HIV<o:p></o:p></p>
<p class="MsoNormal">FirstName_SurName.LGBT<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I believe that any information that
discloses a person’s religious affiliation, sexual orientation
or medical condition, could be deemed PII in certain
jurisdictions. I will to defer to Stephanie on this question,
however, I believe the answer is yes.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="_MailEndCompose">So NOW lets come to a point where I
think “we” can find some agreement.<o:p></o:p></a></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">I
believe that all Thin Data ( as I previously defined as all
data elements necessary for the minimum operation of a gTLD
SRS – including status) should be made available even if it
does contain PII in the domain name itself of the domain
name of the name servers.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Domain
Name: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Registrar:
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Sponsoring
Registrar IANA ID: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Whois
Server: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Referral
URL: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Name
Server: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Name
Server: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Status:
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Updated
Date: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Creation
Date: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Expiration
Date: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Notwithstanding
the fact that PII may be contained in the domain name or the
name server domain, I believe that this “thin” data is so
necessary that it MUST be disclosed and there is no
situation that I can foresee where this “thin” data can be
withheld. Again however, I will let Stephanie answer this
question. If we can all agree on this “thin” data question
that could be an important first building block toward
consensus. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Best
regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">Michael<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Greg Aaron
[<a class="moz-txt-link-freetext" href="mailto:gca@icginc.com">mailto:gca@icginc.com</a>] <br>
<b>Sent:</b> Wednesday, December 7, 2016 7:30 PM<br>
<b>To:</b> Michael D. Palage <a class="moz-txt-link-rfc2396E" href="mailto:michael@palage.com"><michael@palage.com></a>;
'Gomes, Chuck' <a class="moz-txt-link-rfc2396E" href="mailto:cgomes@verisign.com"><cgomes@verisign.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> RE: [gnso-rds-pdp-wg] key concepts: say
"contact data" when that is what we mean<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoPlainText">BTW, much of the thin data in WHOIS is
not even “collected” from or provided by the registrant.
Much of it is generated automatically at the registry, as a
key registry function/responsibility. When you register a
domain:<o:p></o:p></p>
<p class="MsoPlainText"
style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1
lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]-->the
registry knows what registrar is creating the domain, and
records that and associates the registrar’s IANA ID. The
registry then displays those in WHOIS.<o:p></o:p></p>
<p class="MsoPlainText"
style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1
lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]-->policy
dictates what initial domain statuses there are. <o:p></o:p></p>
<p class="MsoPlainText"
style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1
lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]-->the
registrar indicates how many years the registrant wants, but
the create/updated/expiration timestamps are generated and
maintained by the registry. <o:p></o:p></p>
<p class="MsoPlainText"
style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1
lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]-->Nameserver
data is provided by the registrant. (Unless he or she didn’t
specify any, in which case the registrar often provides
defaults.)<o:p></o:p></p>
<p class="MsoPlainText"
style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1
lfo2"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]-->Domain
statuses can be manipulated after the domain’s out of AGP.
Depending on the status type and the situation, they can be
added and deleted by the registrant, the registrar, and/or by
the registry. <o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">None of these thin data fields are
sensitive info AFAIK.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">All best,<o:p></o:p></p>
<p class="MsoPlainText">--Greg <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Michael D. Palage [<a
moz-do-not-send="true" href="mailto:michael@palage.com">mailto:michael@palage.com</a>]
<br>
<b>Sent:</b> Wednesday, December 7, 2016 5:04 PM<br>
<b>To:</b> 'Gomes, Chuck' <<a moz-do-not-send="true"
href="mailto:cgomes@verisign.com">cgomes@verisign.com</a>>;
Greg Aaron <<a moz-do-not-send="true"
href="mailto:gca@icginc.com">gca@icginc.com</a>>; <a
moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> RE: [gnso-rds-pdp-wg] key concepts: say
"contact data" when that is what we mean<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Chuck,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is where a choice/orientation of words
may have significant legal distinction.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">(My text) - All data associated with a
domain name registration<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">(WG Text) – Registration Data<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I am taking a much more expansive view of
data associated with a domain name registration to include
data potentially NOT originally provided by a registrant at
the time of registration. Versus the potentially more
restrictive definition of only data provided by Registrant to
Registrar at the time of registration.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Take for example a .BRAND registry where
licensees of that trademark owner are permitted to register in
that .BRAND TLD. As part of promoting awareness to consumers,
the registry operator (trademark owner) may desire to
include/append authoritative data associated with each
licensees consumer ranking (e.g. rating 1 thru 5 stars) so
that consumers can better choose which licensee to conduct
business. Because this ranking may change over time, the
Registrant/Licensee is NOT in a position to provide this data
as it appears in the RDS/WHOIS output. Only the Registry
Operator (trademark owner) would be best positioned to include
this authoritative data in the RDS/Whois output.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The point I am trying to make is that
innovation has only just begun in connection with the new gTLD
expansion. While I respect the rights of privacy advocates to
safeguard registrant PII, I do not want broad policy
statements to have unintended consequences in impeding future
innovation.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Michael<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Gomes, Chuck [<a
moz-do-not-send="true" href="mailto:cgomes@verisign.com">mailto:cgomes@verisign.com</a>]
<br>
<b>Sent:</b> Wednesday, December 7, 2016 4:34 PM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:michael@palage.com">michael@palage.com</a>;
<a moz-do-not-send="true" href="mailto:gca@icginc.com">gca@icginc.com</a>;
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> RE: [gnso-rds-pdp-wg] key concepts: say
"contact data" when that is what we mean<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks Mike. I am glad to see this
discussion going on in advance of considering the first
users/purposes question: “<b><span
style="font-family:"Calibri\,Bold"">Should gTLD
<span style="background:yellow;mso-highlight:yellow">registration
data</span> be accessible for any purpose or only for
specific purposes?</span></b>”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Chuck<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Michael D. Palage [<a
moz-do-not-send="true" href="mailto:michael@palage.com">mailto:michael@palage.com</a>]
<br>
<b>Sent:</b> Wednesday, December 07, 2016 4:13 PM<br>
<b>To:</b> Gomes, Chuck <<a moz-do-not-send="true"
href="mailto:cgomes@verisign.com">cgomes@verisign.com</a>>;
<a moz-do-not-send="true" href="mailto:gca@icginc.com">gca@icginc.com</a>;
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] RE: [gnso-rds-pdp-wg] key
concepts: say "contact data" when that is what we mean<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Chuck,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">First Greg acknowledges that not ALL data
other than the thin technical data falls within his CONTACT
DATA definition (trademark, nexus, reseller, etc). So we begin
today with a model that is less than 100% inclusive and will
likely become less inclusive as more innovative uses of the
RDS and Whois data are created. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Second, the use of this terminology ignores
the reality in the marketplace that Registrant data is widely
relied upon to make legal determinations (i.e. ownership,
authority to transfer a domain name, infringement, etc.).
When law enforcement is trying to shut down a counterfeit
operation, they are not looking to use this data to ‘contact”
the registrant, but instead ‘arrest” him/her.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I understand how the term “contact data”
provides a certain comfort level to Stephanie and the valid
concerns she has. However, as someone that is involved in
making legal determinations regarding the ownership rights
(property/service contract) concerning domain name
registrations on a regular basis, this concept of “Contact
Data” will just lead to a lot of confusion.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The whole legal construct (private
contractual rights) upon which the domain name system is based
recognizes the Registrant and the Registrant Data that it
provides. In fact ICANN’s Whois web page makes the following
statement: “ICANN's WHOIS Lookup gives you the ability to
lookup any generic domains, such as "icann.org" <u>to find
out the registered domain owner</u>.” (emphasis added)
Again this data by ICANN’s own admission is relied upon to
make “ownership” decisions NOT mere “contact” information.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So I think we stick to one of the first
things I learned as a young engineer. Keep It Simple Stupid
(KISS)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thin Data – the minimum technical data
necessary for a registry to perform its function as a registry
operator in a shared registry system.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thick Data – All data associated with a
domain name registration made available via Whois/RDS, which
may include Personal Identifying Information (PII)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Again I appreciate the constructive efforts
of Greg, Stephanie and others, but I just do not see this
concept scaling meaningfully. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Michael<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a>
[<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org">mailto:gnso-rds-pdp-wg-bounces@icann.org</a>]
<b>On Behalf Of </b>Gomes, Chuck<br>
<b>Sent:</b> Wednesday, December 7, 2016 10:20 AM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:gca@icginc.com">gca@icginc.com</a>; <a
moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> Re: [gnso-rds-pdp-wg] key concepts: say
"contact data" when that is what we mean<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks Greg for the helpful suggestion. I
have one question for you and others: If we exclude THIN DATA,
is there any data we will need to consider that could not be
accurately classified as CONTACT DATA. If not, then dividing
data into these two categories should suffice.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Chuck<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a>
[<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org">mailto:gnso-rds-pdp-wg-bounces@icann.org</a>]
<b>On Behalf Of </b>Greg Aaron<br>
<b>Sent:</b> Wednesday, December 07, 2016 9:55 AM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] [gnso-rds-pdp-wg] key concepts:
say "contact data" when that is what we mean<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Speaking of key concepts… people often say
“registration data” when they really mean “contact data.”
Being plain and specific here can help discussion in our
group. The concept will come up in next week’s discussion. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There are basically two kinds of
“registration data”. The first is called the<b> THIN DATA</b>.
This is the basic data about a domain name registration: the
domain name, the sponsoring registrar name and ID, the
domain’s status(es) , created-updated-expiration dates, and
nameservers. (<a moz-do-not-send="true"
href="https://whois.icann.org/en/what-are-thick-and-thin-entries">https://whois.icann.org/en/what-are-thick-and-thin-entries</a>
) This data is factual, accurate, is not personally
identifiable, and I think is completely noncontroversial. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The second kind of registration data is <b>CONTACT
DATA</b> – contact names, postal and email addresses, phone
numbers. Contact data raises issues of privacy and data
protection. Contact data can be (and regularly is)
inaccurate because it’s ultimately supplied by the
registrants. When people talk about “registration data
accuracy” and “registration data validation” they are really
talking about the accuracy of <b>CONTACT DATA</b>, not all
“registration data.”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In the coming discussions, one approach
could be: There are good reasons to publish the thin data … is
there any compelling reason <i>not</i> 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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Even the EWG’s language wasn’t always clear
and specific in this area. Here’s the question we will begin
with next week:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><i>Should gTLD registration data be
accessible for any purpose or only for specific purposes?<o:p></o:p></i></p>
<p class="MsoNormal"><i>“The EWG unanimously recommends
abandoning today’s WHOIS model of giving every user the same
entirely anonymous public access to (often inaccurate) gTLD
registration data. Instead, the EWG recommends a paradigm
shift to a next-generation RDS that collects, validates and
discloses gTLD registration data for permissible purposes
only.<o:p></o:p></i></p>
<p class="MsoNormal"><i>While basic data would remain publicly
available, the rest would be accessible only to accredited
requestors who identify themselves, state their purpose, and
agree to be held accountable for appropriate use.”<o:p></o:p></i></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What the EWG really meant was: <o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l1 level1 lfo4"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]-->Give
public, anonymous access to the THIN data. (“Basic data” as
the EWG called it.) <o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l1 level1 lfo4"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]-->Don’t
give every user the same anonymous public access to (“often
inaccurate”) gTLD CONTACT DATA. <o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l1 level1 lfo4"><!--[if !supportLists]--><span
style="font-family:Symbol"><span style="mso-list:Ignore">·<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]-->Shift
to an RDS that collects, validates and discloses gTLD CONTACT
DATA for permissible purposes only. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">All best,<o:p></o:p></p>
<p class="MsoNormal">--Greg<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt">**********************************<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Greg Aaron<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Vice-President,
Product Management<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">iThreat
Cyber Group / Cybertoolbelt.com<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">mobile:
+1.215.858.2257<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">**********************************<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">The
information contained in this message is privileged and
confidential and protected from disclosure. If the reader of
this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any
dissemination, distribution or copying of this communication
is strictly prohibited. If you have received this
communication in error, please notify us immediately by
replying to the message and deleting it from your computer.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
</body>
</html>