<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">Dear All,</span><o:p></o:p></p>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);">&nbsp;</span><o:p></o:p></p>
<div style="font-family: -webkit-standard;">
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">Please find the attendance of&nbsp;the call attached to this email and the&nbsp;MP3 recording below for the Next-Gen RDS PDP Working group call held on Tuesday, 09 May 2017 at 16:00 UTC.</span><o:p></o:p></p>
<p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman'; line-height: 15.6pt;">
<span style="font-size: 11pt; font-family: Calibri;"><b>MP3:</b></span><span style="font-family: Calibri;"><b>&nbsp;</b></span><a href="https://audio.icann.org/gnso/gnso-nextgen-rds-pdp-09may17-en.mp3 
" style="font-family: -webkit-standard; font-size: 14px;">https://audio.icann.org/gnso/gnso-nextgen-rds-pdp-09may17-en.mp3&nbsp;</a></p>
<a href="http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-11apr17-en.mp3"><br>
</a>
<p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman'; line-height: 15.6pt;">
<span style="font-size: 11pt; font-family: Calibri;"><b>AC recording:</b></span>&nbsp;<a href="https://participate.icann.org/p7cfnzbdipw/" style="font-family: -webkit-standard; font-size: 14px;">https://participate.icann.org/p7cfnzbdipw/</a></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group-2Dactivities_calendar-23nov&amp;d=DwMF-g&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=PDd_FX3f4MVgkEIi9GHvVoUhbecsvLhgsyXrxgtbL10DTBs0i1jYiBM_uTSDzgqG&amp;m=GJMkY4Fbi9sry9Z53DaSWJm-mHxMfFxg7MEVDf2JU90&amp;s=FI3QJYH6DWWCDQir6NDMSjPkzdqfTTUmf9Ua-AYpc14&amp;e=" style="color: purple;">http://gnso.icann.org/en/group-activities/calendar</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">&nbsp;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">&nbsp;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">** Please let me know if your name has been left off the list **</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">&nbsp;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">Mailing list archives:<a href="http://mm.icann.org/pipermail/gnso-rds-pdp-wg/" style="color: purple;">http://mm.icann.org/pipermail/gnso-rds-pdp-wg/</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">&nbsp;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;"><b>Wiki page: &nbsp;</b></span><a href="https://community.icann.org/x/EsPRAw" style="font-family: -webkit-standard; font-size: 14px;">https://community.icann.org/x/EsPRAw</a></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">&nbsp;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">Thank you.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">Kind regards,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-family: Calibri;">Michelle&nbsp;</span><span style="font-family: -webkit-standard, serif;"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11pt; font-family: Calibri;">&nbsp;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<span style="font-size: 11.5pt; font-family: Calibri;">———————————————</span><o:p></o:p></p>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<o:p>&nbsp;</o:p></p>
<p class="MsoNoSpacing" style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';">
<b><u><span style="font-family: Calibri;">AC Chat Next-Gen RDS PDP WG Tuesday</span></u></b><b><u><span style="font-family: Calibri;">, 09 May 2017</span></u></b></p>
<div>Michelle DeSmyter:Dear all, Welcome to the GNSO Next-Gen RDS PDP Working Group call on Tuesday 09 May 2017 at 16:00 UTC.</div>
<div>&nbsp;&nbsp;Michelle DeSmyter:Meeting agenda page:&nbsp;<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_EsPRAw&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=m5BDCwOsnoXbuUY5nyWPqgN7jyUjwZTa3Xh98YGERKE&amp;e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_EsPRAw&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=m5BDCwOsnoXbuUY5nyWPqgN7jyUjwZTa3Xh98YGERKE&amp;e=</a></div>
<div>&nbsp;&nbsp;Chuck Gomes:Hello all</div>
<div>&nbsp;&nbsp;Lisa Phifer:RDS PDP WG Newcomers, if you may be interested in a one-hour tutorial, please complete this survey:&nbsp;<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.surveymonkey.com_r_3GG6CRR&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=NxVZzqFhoi2iNXgmAMwAg2eIhRilRPcHqfmikoFODPo&amp;e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__www.surveymonkey.com_r_3GG6CRR&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=NxVZzqFhoi2iNXgmAMwAg2eIhRilRPcHqfmikoFODPo&amp;e=</a></div>
<div>&nbsp;&nbsp;Fabricio Vayra:hello, all!</div>
<div>&nbsp;&nbsp;Venkata Atluri:Hello Everyone</div>
<div>&nbsp;&nbsp;Maxim Alzoba (FAITID):Hello All</div>
<div>&nbsp;&nbsp;Maxim Alzoba (FAITID):I will have to drop after 60 minutes</div>
<div>&nbsp;&nbsp;Michael Hammer:Greetings</div>
<div>&nbsp;&nbsp;Chuck Gomes:How's the GDD Summit Maxim?</div>
<div>&nbsp;&nbsp;Maxim Alzoba (FAITID):good so far&nbsp;</div>
<div>&nbsp;&nbsp;Lisa Phifer:Displayed on-screen:&nbsp;<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078610_AnnotatedResultsV2-2DPoll-2Don-2DPurpose-2Dfrom-2D2MayCall.pdf&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=uxzZv_WYEACCDWawcFdOyygM8IQyAkLYf3SSYkxzBno&amp;e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078610_AnnotatedResultsV2-2DPoll-2Don-2DPurpose-2Dfrom-2D2MayCall.pdf&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=uxzZv_WYEACCDWawcFdOyygM8IQyAkLYf3SSYkxzBno&amp;e=</a></div>
<div>&nbsp;&nbsp;Michelle DeSmyter:Remmy</div>
<div>&nbsp;&nbsp;Lisa Phifer:Q2 results are on page 3</div>
<div>&nbsp;&nbsp;Lisa Phifer:WG Agreement to be recorded in our deliberation working draft: gTLD registration &quot;thin data&quot; should be accessible without requiring inquirers to identify themselves or state their purpose.</div>
<div>&nbsp;&nbsp;Marika Konings:Please note that the charter outlines the process for determining consensus and level of consensus.&nbsp;</div>
<div>&nbsp;&nbsp;Lisa Phifer:All points of rough consensus are captured in our working document; the latest draft is&nbsp;<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_56986791_KeyConceptsDeliberation-2DWorkingDraft-2D21April2017.pdf&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=d3L9zG4ZV6dKQ9-xxsdLhIP4o_fjo1gh7cFpyqLWUm8&amp;e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_56986791_KeyConceptsDeliberation-2DWorkingDraft-2D21April2017.pdf&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=d3L9zG4ZV6dKQ9-xxsdLhIP4o_fjo1gh7cFpyqLWUm8&amp;e=</a></div>
<div>&nbsp;&nbsp;Lisa Phifer:The most recent version of our working document is always posted at the top of this wiki page:&nbsp;<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_gTLDRDS_Phase-2B1-2BDocuments&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=y3BdD9LZAUMiQNbxybTHxTP2v0NCVw43dbEGec1qvOo&amp;e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_gTLDRDS_Phase-2B1-2BDocuments&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=y3BdD9LZAUMiQNbxybTHxTP2v0NCVw43dbEGec1qvOo&amp;e=</a></div>
<div>&nbsp;&nbsp;Lisa Phifer:Agreements on data element requirements (thin and otherwise) will also be recorded in that working draft, under the Data Elements charter question</div>
<div>&nbsp;&nbsp;Lisa Phifer:Q3 results start on page 5</div>
<div>&nbsp;&nbsp;Lisa Phifer:We will be displaying this handout for futher deliberation momentarily:&nbsp;<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078610_Charter-2520Question-25205-2520-2D-2520Handout-2520-2D-2520For9MayCall.pdf&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=QVV8--1EIFOLrguivnaSSqAftjK81HmBa2VpZ8MvcxQ&amp;e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078610_Charter-2520Question-25205-2520-2D-2520Handout-2520-2D-2520For9MayCall.pdf&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=QVV8--1EIFOLrguivnaSSqAftjK81HmBa2VpZ8MvcxQ&amp;e=</a></div>
<div>&nbsp;&nbsp;andrew sullivan:Apparently I am incompetent and failed somehow to save my answers, but in any case, I have no idea how (2) is supposed to work</div>
<div>&nbsp;&nbsp;Lisa Phifer:What we conclude from Q3 is that there is interest in deliberating these - this poll question did not seek agreement or disagreement to each possible requirement</div>
<div>&nbsp;&nbsp;Lisa Phifer:Displayed on-screen:&nbsp;<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078610_AnnotatedResultsV2-2DPoll-2Don-2DPurpose-2Dfrom-2D2MayCall.pdf&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=uxzZv_WYEACCDWawcFdOyygM8IQyAkLYf3SSYkxzBno&amp;e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078610_AnnotatedResultsV2-2DPoll-2Don-2DPurpose-2Dfrom-2D2MayCall.pdf&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=uxzZv_WYEACCDWawcFdOyygM8IQyAkLYf3SSYkxzBno&amp;e=</a></div>
<div>&nbsp;&nbsp;andrew sullivan:I sort of feel like a number of people imagine all access to this data is by a human looking at it</div>
<div>&nbsp;&nbsp;Rod Rasmussen:@Andrew - by (2) did you mean 3b?</div>
<div>&nbsp;&nbsp;andrew sullivan:yes, 3b</div>
<div>&nbsp;&nbsp;Lisa Phifer:If you wish to be able to refer offline to your own comments, once we move on to deliberation</div>
<div>&nbsp;&nbsp;Rod Rasmussen:See my comment - what's even the point?</div>
<div>&nbsp;&nbsp;andrew sullivan:Indeed</div>
<div>&nbsp;&nbsp;Lisa Phifer:Handout now displayed on-screen:&nbsp;<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078610_Charter-2520Question-25205-2520-2D-2520Handout-2520-2D-2520For9MayCall.pdf&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=QVV8--1EIFOLrguivnaSSqAftjK81HmBa2VpZ8MvcxQ&amp;e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078610_Charter-2520Question-25205-2520-2D-2520Handout-2520-2D-2520For9MayCall.pdf&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=QVV8--1EIFOLrguivnaSSqAftjK81HmBa2VpZ8MvcxQ&amp;e=</a></div>
<div>&nbsp;&nbsp;Lisa Phifer:Page 2 gives WG Agreement from last week as foundation for further deliberation on possible requirements for controlling access to &quot;thin data&quot;</div>
<div>&nbsp;&nbsp;Lisa Phifer:Page 3 uses results from poll question 3 to just lay out several different possible requirements for deliberation in this call</div>
<div>&nbsp;&nbsp;Alan Greenberg:Sorry to be late.</div>
<div>&nbsp;&nbsp;Lisa Phifer:Current RAA WHOIS specification allows rate limiting</div>
<div>&nbsp;&nbsp;Lisa Phifer:someone has an open mic</div>
<div>&nbsp;&nbsp;Rod Rasmussen:3rd item may have a technical aspect but is driven by policy.</div>
<div>&nbsp;&nbsp;Michael Hammer:&#43;1 to Rod's comment.</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Rod, mute your speakers when talking</div>
<div>&nbsp;&nbsp;Marika Konings:Jim, it looks like your microphone is still open</div>
<div>&nbsp;&nbsp;Greg Shatan:Someone needs to mute or be muted.</div>
<div>&nbsp;&nbsp;Michael Hammer:For example, rate limiting to a very low rate might be used to drive people to a pay offering - that is policy, not technical.</div>
<div>&nbsp;&nbsp;Rod Rasmussen:Not my speakers.</div>
<div>&nbsp;&nbsp;Amr Elsadr:@Rod: We're on slide 3 now.</div>
<div>&nbsp;&nbsp;Lisa Phifer:We are discussing possible requirements on page 3 of displayed document</div>
<div>&nbsp;&nbsp;Alan Greenberg:Please, WHISH SLIDE?? We all have scrolling</div>
<div>&nbsp;&nbsp;Greg Aaron:So for the purposes of the current discussion, are we talking about thin data only?</div>
<div>&nbsp;&nbsp;Rod Rasmussen:Thanks - explains the disconnect</div>
<div>&nbsp;&nbsp;Lisa Phifer:Yes, we are deliberating &quot;What steps should be taken to control thin data access&quot; - thin data only</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Scott, when querying a gTLD domain name to retrieve &quot;Thin Data&quot; elements... might be better?</div>
<div>&nbsp;&nbsp;andrew sullivan:Friendly amendment, then: &quot;_Requestor identification_ for access to thin data elements should be…&quot; and so on</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Andrew, for example: 1) Requestor identification for access to &quot;thin data&quot; elements should be a) Disallowed, b) Allowed but not required, or c) Required</div>
<div>&nbsp;&nbsp;Scott Hollenbeck (Verisign):@Lisa: maybe, if we assume that peopls explicitly submit queries for access to subsets of the available data</div>
<div>&nbsp;&nbsp;Vicky Sheckler:apologies but I've been called away unexpectedly</div>
<div>&nbsp;&nbsp;Vicky Sheckler:will catch up later</div>
<div>&nbsp;&nbsp;Greg Aaron:No, Stephanie, you are not correct.</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Scott, if there are multiple requirements that apply to a particular scenario, they must all be taken into account, but for right now we focus on requirements for any scenario that involves access to &quot;tihin data&quot;</div>
<div>&nbsp;&nbsp;andrew sullivan:@Lisa, Scott: I think the point is that if you put it in terms of &quot;elements&quot; then the response to an unauthenticated (or whatever) query isn't allowed to get non-thin data</div>
<div>&nbsp;&nbsp;Scott Hollenbeck (Verisign):@Andrew: yes</div>
<div>&nbsp;&nbsp;andrew sullivan:I agree that the phrasing is a little infelicitous, in that it suggests that people query for particular data</div>
<div>&nbsp;&nbsp;andrew sullivan:I don't think I understood Rod's point about mutliple interfaces</div>
<div>&nbsp;&nbsp;andrew sullivan:it seems to me that if we have an RDAP system, and unauthenticated access is permitted to some subset of data, then if you send a query without authentication you get the small subset</div>
<div>&nbsp;&nbsp;andrew sullivan:and if you send a query while authenticated you get the answer you're supposed to</div>
<div>&nbsp;&nbsp;Scott Hollenbeck (Verisign):@Lisa: then I think we should be discussing the conditions under which you have access to only thin data</div>
<div>&nbsp;&nbsp;steve metalitz:Isn't the status quo on #1 and 2 (a) (disallowed); and if so, what would be gained by moving to (b) (requestor ID required or some form of authentication required in some cases but not others)?&nbsp;&nbsp;&nbsp;</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Andrew, what you describe is what the EWG recommended - with the exception that authentication was not the only criteria applied to determine what data elements you are authorized to receive in your reply</div>
<div>&nbsp;&nbsp;andrew sullivan:no, the status quo on all of it is completely unauthenticated and unidentified permission.</div>
<div>&nbsp;&nbsp;andrew sullivan:@Lisa: I know</div>
<div>&nbsp;&nbsp;Scott Hollenbeck (Verisign):@steve: access control decisions can be made if the server knows something about the client asking the question.</div>
<div>&nbsp;&nbsp;Greg Shatan:The Velvet Hammer.</div>
<div>&nbsp;&nbsp;Michael Hammer:Apologies, dropped audio connection</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Scott, Andrew - How in WHOIS today can a requestor identify or authenticate themselves?&nbsp;</div>
<div>&nbsp;&nbsp;Scott Hollenbeck (Verisign):@Lisa: no can do</div>
<div>&nbsp;&nbsp;andrew sullivan:@Lisa some registries at some point ran a VPN with authentication to connect and a whois behind it</div>
<div>&nbsp;&nbsp;Scott Hollenbeck (Verisign):(except for web-nased interfaces that accept server-assigned user names and passwords)</div>
<div>&nbsp;&nbsp;andrew sullivan:but that's pretty weak broth</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Michael - not requiring identification is different than disallowing identification, thus we are probing further with 1)</div>
<div>&nbsp;&nbsp;Rod Rasmussen:My point on different &quot;interfaces&quot; can also be thought of as needing to make different types of queries depending upon the type of request you're making.&nbsp;&nbsp;I would argue that you should get &quot;thin&quot; data for &quot;free&quot; when you're making a gated
 data element(s) query.&nbsp;&nbsp;If you you have to make two different queries</div>
<div>&nbsp;&nbsp;steve metalitz:@Greg, isn;t another way of saying that that 1 and 2 should be answered (a)?&nbsp;&nbsp;</div>
<div>&nbsp;&nbsp;Rod Rasmussen:My point on different &quot;interfaces&quot; can also be thought of as needing to make different types of queries depending upon the type of request you're making.&nbsp;&nbsp;I would argue that you should get &quot;thin&quot; data for &quot;free&quot; when you're making a gated
 data element(s) query.&nbsp;&nbsp;If you &quot;disallow&quot; requestor identification for thin data, then you have to make two different queries to get the data you need - one with your ID and one without.</div>
<div>&nbsp;&nbsp;Lisa Phifer:From a policy perspective, rate limiting and CAPTCHA can be allowed or required as anti-abuse measures - or they can be allowed purely to meet operational needs. The latter is the situation in today's WHOIS?</div>
<div>&nbsp;&nbsp;Greg Aaron:Yes, Steve; in order for us to be consistent with ourselves then 1 and 2 should be answered (a).</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Greg, for 1 and 2, how is b) Allowed but not required, inconsistent with last week's agreement?</div>
<div>&nbsp;&nbsp;Maxim Alzoba (FAITID):We should not forget that real infrastructure (CPUs, Memory, storage) add costs , so the issue is to make real &quot;bandwidth&quot; balanced (there is no such thing as truly limitless perfomance)</div>
<div>&nbsp;&nbsp;Rod Rasmussen:OK, we have a wording issue here that's creating a bit of a problem in 1 &amp; 2 - disallowed for *only* thin access but *allowed* when you're making a more complex query to catch my concern.</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Rod, &#43;1</div>
<div>&nbsp;&nbsp;Maxim Alzoba (FAITID):need to drop the call, bye all</div>
<div>&nbsp;&nbsp;Greg Aaron:Lisa: are you saying 'give the requestor the option of identifying himdelf/herself?&quot;&nbsp;&nbsp;But in all cases, give the thin data to requestors whether ort not they have identified themselves?</div>
<div>&nbsp;&nbsp;andrew sullivan:have to step away for a moment</div>
<div>&nbsp;&nbsp;Lisa Phifer:Suggest that we try to derive possible statements from 1/2, separately from 3/4, to describe what policy requirements may apply to thin data access</div>
<div>&nbsp;&nbsp;Rod Rasmussen:That's the gist of it @Greg</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Greg, yes</div>
<div>&nbsp;&nbsp;Greg Shatan:Agree, thick data should &quot;embrace&quot; thin data.</div>
<div>&nbsp;&nbsp;Greg Shatan:in terms of a query response.</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Rod, Requestor Authentication should be allowed but not required for access to any data elements (including thin data elements)?</div>
<div>&nbsp;&nbsp;Daniel K. Nanghaka:I think Requester Identification should be allowed because it helps in enhancement the legitimacy of the Requester</div>
<div>&nbsp;&nbsp;Lisa Phifer:Actually that's probably not it... but is that going in the direction you meant?</div>
<div>&nbsp;&nbsp;Greg Aaron:So my questions are 1) doesn't that create inefficienes as Rod says, 2) if you collect requestor info then do thpose people a right to opt out and remove their info from the database later, 3) are registries going to sell data about who queries
 WHOIS?&nbsp;&nbsp;ICANN might need policy around that....</div>
<div>&nbsp;&nbsp;andrew sullivan:back</div>
<div>&nbsp;&nbsp;Daniel K. Nanghaka:@Greg, then they should have the consent to to opt out - but if you are going to query the data again then I do not see the reason to remove your info from the database&nbsp;</div>
<div>&nbsp;&nbsp;Michael Hammer:If the answer to #1 is a) then question #2 becomes meaningless.</div>
<div>&nbsp;&nbsp;Lisa Phifer:Would it be helpful to divvy deliberation on access methods: web, bulk, protocol queries - and look at access requirements for each?</div>
<div>&nbsp;&nbsp;Daniel K. Nanghaka:And yes, ICANN will need a policy towards user data and authentication of the Requester&nbsp;</div>
<div>&nbsp;&nbsp;andrew sullivan:I think it is obvious that if someone gets a superset of thin data by authentication, then it is ok that they get the thin data along with it</div>
<div>&nbsp;&nbsp;andrew sullivan:but I do not want a registr[y|ar] to be able to decide unilaterally to require authentication</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Andrew, not if authentication is disallowed by policy</div>
<div>&nbsp;&nbsp;andrew sullivan:@Lisa: that's the reason that Scott's worried about how this is phrased</div>
<div>&nbsp;&nbsp;andrew sullivan:because you get that effect if only because of how it's phrased</div>
<div>&nbsp;&nbsp;Rod Rasmussen:@Andrew - yep, it's obvious, so that's why I'm sayin' it - too many times I've seen &quot;obvious&quot; missed in creation of policy. :-)</div>
<div>&nbsp;&nbsp;andrew sullivan:@Rod: oh yes, strongly agree</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Andrew, can you suggest a possible requirement that allows authentication but does not require authentication for access to thin data elements?</div>
<div>&nbsp;&nbsp;Michelle DeSmyter:one moment</div>
<div>&nbsp;&nbsp;andrew sullivan:The point is that an unauthenticated requestor MUST have access to thin data elements, within the required operational bounds of the service (so rate limiting for anti-DoS is acceptable)</div>
<div>&nbsp;&nbsp;andrew sullivan:But authenticated users might have access to other data elements</div>
<div>&nbsp;&nbsp;steve metalitz:Could this be resolved by changing the beginning of each statement to &quot;To the extent querying gTLD 'thin data' elements only,&quot; .....?</div>
<div>&nbsp;&nbsp;Greg Aaron:&#43;1 Andrew</div>
<div>&nbsp;&nbsp;Fabricio Vayra:&#43;1 Andrew</div>
<div>&nbsp;&nbsp;Scott Hollenbeck (Verisign):@Andrew! YES!</div>
<div>&nbsp;&nbsp;Lisa Phifer:This is why EWG differentiated between the minimum public data set and gated data elements. Public data is accessible with or without authentication. Gated data requires authentication.</div>
<div>&nbsp;&nbsp;Lisa Phifer:Possible requirement: &quot;Thin data&quot; elements must be accessible with or without authentication.</div>
<div>&nbsp;&nbsp;andrew sullivan:Not a complication, but not part of this protocol.&nbsp;&nbsp;As Scott has already pointed out, you get those permissions out of band using your authentication and authorization mechanism</div>
<div>&nbsp;&nbsp;Lisa Phifer:This would be in addition to last week's agreement: &quot;Thin data&quot; should be accessible without requiring inquirers to identify themselves or state their purpose.</div>
<div>&nbsp;&nbsp;Lisa Phifer:Possible requirement: &quot;Thin data&quot; elements must be accessible with or without authentication.</div>
<div>&nbsp;&nbsp;andrew sullivan:Last week's agreement was for &quot;accessibility&quot;.&nbsp;&nbsp;It didn't say that was the _only_ way thin elements were accessible</div>
<div>&nbsp;&nbsp;steve metalitz:@Lisa that would change the answer to 2 to (b).&nbsp;&nbsp;Still don't understand rationale for that&nbsp;</div>
<div>&nbsp;&nbsp;Lisa Phifer:@STeve, it allows a single authenticated query to return both thin and thick data elements</div>
<div>&nbsp;&nbsp;Greg Aaron:&quot;Thin data&quot;elements must be accessible with or without authentication&quot; can be interpreted TWO differnt ways, and one of those ways is not what we want.&nbsp;&nbsp;</div>
<div>&nbsp;&nbsp;andrew sullivan:@Greg: what's the second way?</div>
<div>&nbsp;&nbsp;Greg Shatan:My concern is that it can be read to _allow_ authentication to be required when only thin data elements are being requested.</div>
<div>&nbsp;&nbsp;Greg Shatan:I'm the other Greg but that's my thought on the second way.</div>
<div>&nbsp;&nbsp;steve metalitz:&quot;Thin data elements must be accessible with authenticatoin&quot;&nbsp;&nbsp;implies that that they need not be accessible without authentication.&nbsp;&nbsp;</div>
<div>&nbsp;&nbsp;Greg Shatan:Lawyers are never evil, they are only carrying out the desires of clients, who may be evil.</div>
<div>&nbsp;&nbsp;Stephanie Perrin:We use a disjunctive comma to imply the second interpretation, do we not?</div>
<div>&nbsp;&nbsp;Lisa Phifer:Possible alternative: &quot;Thin data&quot; elements must not require authentication, but must allow for optional authentication of the inquirer</div>
<div>&nbsp;&nbsp;andrew sullivan:@Stephanie: this is what happens when people don't follow Oxford on commas :-D</div>
<div>&nbsp;&nbsp;steve metalitz:@Lisa we are getting way ahead of ourselves to torture this lanaguage to accommodate a gated access structure for &quot;non-thin&quot; data which we have not even begun to discuss.&nbsp;&nbsp;</div>
<div>&nbsp;&nbsp;Stephanie Perrin:I know, so much confusion when you forget the importance of commas.....</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Steve, we are trying to be clear that we are not precluding authentication by policy</div>
<div>&nbsp;&nbsp;Daniel K. Nanghaka:Accessibility is open and authentication can be be an option with multiple access of the data&nbsp;</div>
<div>&nbsp;&nbsp;andrew sullivan:@Lisa: how about Thin data elements are to be accessble regardless of the level of authentication of the requestor?</div>
<div>&nbsp;&nbsp;Greg Aaron:Agree with Greg S.</div>
<div>&nbsp;&nbsp;steve metalitz:&#43;1 to Andrew's last formulation.&nbsp;&nbsp;</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Andrew, I think that works</div>
<div>&nbsp;&nbsp;steve metalitz:my coments are in chat, thanks. .&nbsp;&nbsp;</div>
<div>&nbsp;&nbsp;Lisa Phifer:Possible alternative (from Andrew): Thin data elements are to be accessble regardless of the level of authentication of the requestor</div>
<div>&nbsp;&nbsp;Michael Hammer:how about Thin data elements are to be accessble regardless of the level of authentication, or lack thereof, of the requestor?</div>
<div>&nbsp;&nbsp;Nathalie Coupet:@Chuck: Quesion: What would consumers need to do to be able to identify the author of a website besides going to court and getting an injunction?&nbsp;&nbsp;</div>
<div>&nbsp;&nbsp;Nathalie Coupet:Question</div>
<div>&nbsp;&nbsp;Stephanie Perrin:The simpler the better.</div>
<div>&nbsp;&nbsp;Nathalie Coupet:From thin data</div>
<div>&nbsp;&nbsp;Greg Shatan:The question of how and whether our policies cover third-partying data stores of RDS information (e.g., a service provider).</div>
<div>&nbsp;&nbsp;Greg Aaron:Have we defined &quot;authentication&quot;?&nbsp;&nbsp;The dictionary defines authentication as: &quot;the process or action of proving or showing something to be true, genuine, or valid.&quot;So if you require a requestor's email address, that is not authentication.&nbsp;&nbsp;And
 under the language being discussed, registries[rars) could request all kinds of info, such as email addresses.</div>
<div>&nbsp;&nbsp;Daniel K. Nanghaka:I think the levels of Authentication are needed&nbsp;</div>
<div>&nbsp;&nbsp;Greg Shatan:I don't have a problem with the concept that Lisa just. stated.</div>
<div>&nbsp;&nbsp;Daniel K. Nanghaka:because if the data is beyond thin data then there is a need for authentication</div>
<div>&nbsp;&nbsp;Greg Shatan:It's just the &quot;doctrine of unintended consequences&quot; at play here in the current formulation.</div>
<div>&nbsp;&nbsp;Greg Shatan:Daniel, we are just discussing thin data at the moment.</div>
<div>&nbsp;&nbsp;Michael Hammer:need? or desire for authentication?</div>
<div>&nbsp;&nbsp;Lisa Phifer:@Daniel, if the WG should agree that authentication is allowed or required, then it would define level(s) of authentication. But if authentication is disallowed, there are no levels to define.</div>
<div>&nbsp;&nbsp;andrew sullivan:@Greg A: if the server operator asks for an email address but doesn't check that it works, then it's not authentication.&nbsp;&nbsp;If there is an email-send-use-this-URL loop, then it's weak authentication</div>
<div>&nbsp;&nbsp;Nick Shorey:re ccTLDs - if sharing with ccNSO just bear in mind that not all ccTLDs are members of ccNSO</div>
<div>&nbsp;&nbsp;andrew sullivan:For whatever it's worth, I think I'm on the record in favour of the Data of Record approach</div>
<div>&nbsp;&nbsp;Lisa Phifer:Newcomer tutorial survey:&nbsp;<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.surveymonkey.com_r_3GG6CRR&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=NxVZzqFhoi2iNXgmAMwAg2eIhRilRPcHqfmikoFODPo&amp;e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__www.surveymonkey.com_r_3GG6CRR&amp;d=DwIFaQ&amp;c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&amp;r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&amp;m=1QvZPa0jqhCG5cB2idF0ww4YIt2OReibUHXLKJymI34&amp;s=NxVZzqFhoi2iNXgmAMwAg2eIhRilRPcHqfmikoFODPo&amp;e=</a></div>
<div>&nbsp;&nbsp;Venkata Atluri:Thank you all</div>
<div>&nbsp;&nbsp;andrew sullivan:bye all</div>
<div>&nbsp;&nbsp;Nathalie Coupet:Bye</div>
<div>&nbsp;&nbsp;Daniel K. Nanghaka:bye all</div>
<div>&nbsp;&nbsp;Nick Shorey:Ciao</div>
</div>
<div><br>
</div>
</div>
</div>
</body>
</html>