<div dir="ltr">I am compelled to point out that making sure ICANN is compliant with privacy laws is not "the purpose of this WG". And I believe statements like that, which I hope and believe was made in brevity and not in fact, contribute to the belief shared by some here that others have distressingly myopic viewpoints as to what the outcome of all this work is meant to be. We are trying to solve a complex equation [sidebar, this thin whois piece should not be the hard part] not simply protect ICANN from the broad category of 'privacy laws' despite that being an important consideration.<div><br></div><div>Marika has been very clear in repeatedly pointing all of us to the original charter docs. This is how she (not me) summarized it weeks ago:</div><div><br></div><div><p class="gmail-m_-3078164885463148225MsoListParagraph" style="margin:0in 0in 0.0001pt 0.5in;font-size:12pt;font-family:"Times New Roman""><span style="font-size:11pt;font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times New Roman""> </span></span><u></u><span style="font-size:11pt;font-family:Calibri">What are the fundamental requirements for gTLD registration data? When addressing this question, the PDP WG should consider, at a minimum, users and purposes and associated access, accuracy, data element, and privacy requirements.<u></u><u></u></span></p><p class="gmail-m_-3078164885463148225MsoListParagraph" style="margin:0in 0in 0.0001pt 0.5in;font-size:12pt;font-family:"Times New Roman""><u></u><span style="font-size:11pt;font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times New Roman""> </span></span><u></u><span style="font-size:11pt;font-family:Calibri">Is a new policy framework and next-generation RDS needed to address these requirements?<u></u><u></u></span></p><p class="gmail-m_-3078164885463148225MsoListParagraph" style="margin:0in 0in 0.0001pt 1in;font-size:12pt;font-family:"Times New Roman""><u></u><span style="font-size:11pt;font-family:"Courier New"">o<span style="font-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times New Roman""> </span></span><u></u><span style="font-size:11pt;font-family:Calibri">If yes, what cross-cutting requirements must a next-generation RDS address, including coexistence, compliance, system model, and cost, benefit, and risk analysis requirements?<u></u><u></u></span></p><p class="gmail-m_-3078164885463148225MsoListParagraph" style="margin:0in 0in 0.0001pt 1in;font-size:12pt;font-family:"Times New Roman""><u></u><span style="font-size:11pt;font-family:"Courier New"">o<span style="font-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times New Roman""> </span></span><u></u><span style="font-size:11pt;font-family:Calibri">If no, does the current WHOIS policy framework sufficiently address these requirements? If not, what revisions are recommended to the current WHOIS policy framework to do so?</span></p></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 31, 2017 at 12:01 PM, nathalie coupet via gnso-rds-pdp-wg <span dir="ltr"><<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:13px"><div id="m_-4668158133892165091yui_3_16_0_ym19_1_1496232851554_414957" dir="ltr"><span id="m_-4668158133892165091yui_3_16_0_ym19_1_1496232851554_414982">Benefits: making sure ICANN is in compliance with privacy laws. Isn't it the purpose of this WG? Issues pertaining to cost and protection of IP address I will leave other to answer. But it seems to me that pseudonimization, randomization and encryption could be candidate solutions. </span></div><div id="m_-4668158133892165091yui_3_16_0_ym19_1_1496232851554_414955"><br></div><div></div><div id="m_-4668158133892165091yui_3_16_0_ym19_1_1496232851554_414953"> </div><div class="m_-4668158133892165091signature" id="m_-4668158133892165091yui_3_16_0_ym19_1_1496232851554_414926">Nathalie </div> <div class="m_-4668158133892165091qtdSeparateBR"><br><br></div><div class="m_-4668158133892165091yahoo_quoted" style="display:block"> <div style="font-family:Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:13px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div dir="ltr"><font size="2" face="Arial"> On Wednesday, May 31, 2017 2:48 PM, John Bambenek via gnso-rds-pdp-wg <<a href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a>> wrote:<br></font></div> <br><br> <div class="m_-4668158133892165091y_msg_container"><div id="m_-4668158133892165091yiv7219839472"><div>
<div>This applies a web interface... would an API be exposed for those
of us who use the command-line? Would there be a central point of
query or would a consumer have to google it? Who pays for
constructing such a system and what is the commensurate return on
the investment for them paying to make all this? If you are asking
for this information, surely you are also getting source data (for
instance consumer IP, which can be PII), how will all that be
protected?</div>
<div>There is a whole lot of complexity, in general, and costs for
registries/registrars, specifically. What problem does this solve
that it makes sense to engineer a solution for it?<br clear="none">
</div>
<br clear="none">
<div class="m_-4668158133892165091yiv7219839472yqt6697870565" id="m_-4668158133892165091yiv7219839472yqtfd98173"><div class="m_-4668158133892165091yiv7219839472moz-cite-prefix">On 5/31/2017 1:40 PM, nathalie coupet
via gnso-rds-pdp-wg wrote:<br clear="none">
</div>
<blockquote type="cite">
</blockquote></div></div><div class="m_-4668158133892165091yiv7219839472yqt6697870565" id="m_-4668158133892165091yiv7219839472yqtfd07002"><div><div>Hi Chuck,</div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature"><br clear="none">
</div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature">My position was and is to secure
unauthenticated access to thin data for all. </div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature">I envisioned access to RDS through 3
chock points to weed out bad actors as much as possible: </div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature">An end-user would need to check the
first box for authenticated/unauthenticated access, then another
box for consumer and a third would be to select the purpose or a
default purpose would be selected for him (maybe no purpose
could also be possible). </div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature">Consumers don't need all the thin
data to be published for their simple queries, since - in my
mind - they want to make sure the website is legitimate or they
want to identify the author in case of abuse (such as
defamation, abuse or threats). </div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature">If the principle of proportionality
doesn't apply to most other cases, that's fine. But I think it
does apply for simple consumer queries. </div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature">This is an interesting debate, but I
never thought it would lead to people actually proposing to drop
vital data for the functioning of the Internet.</div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature">I had in mind the other principle
that you do not volunteer data when it is not required. It
should be useful. Not because it is PPI, but out of caution.</div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature"><br clear="none">
</div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature"><br clear="none">
</div>
<div id="m_-4668158133892165091yiv7219839472AppleMailSignature"><br clear="none">
Sent from my iPhone</div>
<div><br clear="none">
On May 31, 2017, at 2:21 PM, Gomes, Chuck <<a rel="nofollow" shape="rect" href="mailto:cgomes@verisign.com" target="_blank">cgomes@verisign.com</a>>
wrote:<br clear="none">
<br clear="none">
</div>
<blockquote type="cite">
<div>
</div></blockquote></div><div><div class="m_-4668158133892165091yiv7219839472WordSection1">
<div class="m_-4668158133892165091yiv7219839472MsoNormal">Nathalie,</div>
<div class="m_-4668158133892165091yiv7219839472MsoNormal"> </div>
<div class="m_-4668158133892165091yiv7219839472MsoNormal">Thank you for your suggestion that the
principle of proportionality be added. That has generated
a very lively discussion.</div>
<div class="m_-4668158133892165091yiv7219839472MsoNormal"> </div>
<div class="m_-4668158133892165091yiv7219839472MsoNormal">As I am sure you have seen, a lot of WG
members have stated that they do not believe that the
principle of proportionality applies to thin data and have
provided what I think is pretty good rationale in support
of their position. As the originator of the suggestion,
do you still maintain that the principle applies to thin
data? If so, how would you counter the arguments that
have been made to the contrary?</div>
<div class="m_-4668158133892165091yiv7219839472MsoNormal"> </div>
<div class="m_-4668158133892165091yiv7219839472MsoNormal">All – If anyone else thinks that the
principle of proportionality applies to think data, please
speak up and provide your counters to the arguments that
have been made to the contrary.</div>
<div class="m_-4668158133892165091yiv7219839472MsoNormal"> </div>
<div class="m_-4668158133892165091yiv7219839472MsoNormal">Chuck</div>
</div>
<br clear="none">
<fieldset class="m_-4668158133892165091yiv7219839472mimeAttachmentHeader"></fieldset>
<br clear="none">
<pre>______________________________<wbr>_________________
gnso-rds-pdp-wg mailing list
<a rel="nofollow" shape="rect" class="m_-4668158133892165091yiv7219839472moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a>
<a rel="nofollow" shape="rect" class="m_-4668158133892165091yiv7219839472moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a></pre>
<br clear="none">
</div></div></div><div class="m_-4668158133892165091yqt6697870565" id="m_-4668158133892165091yqtfd49125">______________________________<wbr>_________________<br clear="none">gnso-rds-pdp-wg mailing list<br clear="none"><a shape="rect" href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank">gnso-rds-pdp-wg@icann.org</a><br clear="none"><a shape="rect" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a></div><br><br></div> </div> </div> </div></div></div><br>______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org">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/<wbr>listinfo/gnso-rds-pdp-wg</a><br></blockquote></div><br></div>