[Gnso-epdp-team] Pro-forma Triage Report

Tue Aug 21 01:36:55 UTC 2018

I agree.  Alan

At 20/08/2018 09:22 PM, Margie Milam wrote:

>Hi Kurt-
>
>I think itâ€™s a mistake to take this approach 
>with regard to redaction.   In our view, the 
>appropriate standard needs to be rooted in 
>GDPR.  If GDPR does not require redaction, this 
>is something that should be on the table for 
>discussion in the EPDP (as in data elements for legal persons).
>
>I propose we talk about this tomorrow.
>
>All the best,
>Margie
>
>From: Gnso-epdp-team 
><gnso-epdp-team-bounces at icann.org> on behalf of Kurt Pritz <kurt at kjpritz.com>
>Date: Monday, August 20, 2018 at 4:15 PM
>To: "Mueller, Milton L" <milton at gatech.edu>
>Cc: "gnso-epdp-team at icann.org" <gnso-epdp-team at icann.org>
>Subject: Re: [Gnso-epdp-team] Pro-forma Triage Report
>
>Hi Everyone:
>
>Here is where I am on this.
>
>
>1) Milton made a recommendation that we indicate 
>in the Triage report that, despite the red ink 
>and multiple comments, there are several areas 
>of general agreement on basic principles and in 
>detail. I think this would be helpful for the 
>reader to understand. He included data redaction 
>details as an example of this.
>
>Alex pointed out that IPC does not agree with 
>data redaction details; that IPC will seek to 
>have certain data, currently redacted in the 
>temporary specification, to be made publicly 
>available in the successor specification.
>
>So weâ€™ll include the sentiment of Miltonâ€™s 
>statement but not make a specific reference to 
>data redaction details. The Triage document is 
>to indicate areas of full consensus and not 
>intended to reflect compromise or substantive 
>discussion so, I donâ€™t think inclusion or 
>exclusion of a reference to data redaction will 
>affect the future outcome of our work one way or another..
>
>
>2) For our future discussion, I think the 
>argument to take a datum off the redaction list 
>must be carefully made. The reason for taking 
>data off of the redaction list and making it 
>publicly available is that such a publication 
>must be useful in some way. Otherwise, why make 
>the argument? But if it is useful, must it not 
>lead to personal information, i.e., must it not 
>be the very data sought to be barred from publication by GDRP?
>
>I think the argument to make data publicly 
>available that is currently redacted in the 
>Temporary Specification must be that: 1) it  is 
>useful but 2) will not lead to personal 
>information. If the availability does lead to 
>personal information, discussion of it should be 
>left for the â€œaccessâ€ discussion.
>
>
>I hope this is helpful and this is not intended to cut off discussion.
>
>Best regards,
>
>Kurt
>
>
>
>
>
>
>On Aug 20, 2018, at 11:42 AM, Mueller, Milton L 
><<mailto:milton at gatech.edu>milton at gatech.edu> wrote:
>
>Alex
>If you group the redactions with 5 or 6 other 
>things you will see some opposition, but if you 
>actually read the comments there was little 
>opposition to the redactions. As I said in the comment I made on 8/14:
>
>Registrars support redaction â€œbut questions 
>whether this data should continue to be 
>collected as they are not necessary, and do not 
>comply with data minimization principle.â€ So 
>the registrars are conflating the collection 
>issue with the public display issue here. They 
>do support redaction of the data elements listed in the temp spec.
>
>So do the Registries. Ry SG comments call 
>attention to the litigation around collection of 
>the redacted data and has some other comments 
>unrelated to the question whether the temp 
>specâ€™s redaction requirements are acceptable. 
>So again we have a debate about collection rather than display.
>
>Even the GAC comments do not dispute that the 
>data should be redacted. They call for changing 
>â€œredacted for privacyâ€ to â€œredacted for 
>data protectionâ€ in the display, and call for 
>additional text with instructions about how to get access to redacted data.
>
>Both SSAC and IPC also do not question that 
>redaction is required for GDPR compliance but 
>question the scope of the redaction, saying that 
>it may not be necessary in cases where GDPR does 
>not apply (however they overlook or ignore the 
>existence of similar data protection laws in other jurisdictions).
>
>[end quote]
>
>IPCâ€™s initial comments did call for publishing 
>the email address, but it was a lone voice, 
>clearly in the rough, and its position is 
>subject to serious legal challenge. An email 
>address is perhaps the most sensitive data from 
>a security and privacy standpoint. If you 
>donâ€™t redact that, what would you redact, 
>since an email address could be easily used as a 
>search term to gather all the other missing information?
>
>You say, â€œthe Temp Spec has over-redacted a 
>number of data elementsâ€ but your comments 
>only specify the email address. Please tell us 
>what information you DO support redacting. I am 
>curious to know where we can find agreement.
>
>--MM
>
>From: Alex Deacon 
>[<mailto:alex at colevalleyconsulting.com>mailto:alex at colevalleyconsulting.com]
>Sent: Sunday, August 19, 2018 12:42 PM
>To: 
><mailto:gnso-epdp-team at icann.org>gnso-epdp-team at icann.org; 
>Kurt Pritz 
><<mailto:kurt at kjpritz.com>kurt at kjpritz.com>; 
>Mueller, Milton L <<mailto:milton at gatech.edu>milton at gatech.edu>
>Subject: Re: [Gnso-epdp-team] Pro-forma Triage Report
>
>Hi Kurt, All,
>
>Just catching up on this topic. Its not clear to 
>me how one can come to the conclusion that there 
>was no opposition to redacting the data elements the Temp Spec designates.
>
>In Part 2 of the triage, support for Section 
>5.1, which specifies compliance to Appendix A 
>(where redaction is discussed) resulted in a 
>66.67% "no" response. ,  In part 1 of the 
>triage, support for Appendix A 2.1-2.3 resulted 
>in 89.98% "no" response,.  Finally, Appendix A 
>2.4-2.5 received a "no" response rate of 
>77.78%.    Even if you put aside the response 
>count and look at the responses themselves you 
>will see there is significant disagreement--at 
>least with respect to the IPC (and even BC and 
>GAC although I won't speak for them.)
>
>As has been our position since the beginning of 
>the these temp spec discussions we believe the 
>Temp Spec has over-redacted a number of data 
>elements. You can read the details for our 
>rational in our response to Question 22 of Part 
>1 of the triage. However, to summarize:
>
>First, we believe that it is a misapplication of 
>the GDPR for the Temp Spec to make no 
>distinction between registrants that are legal 
>persons versus natural persons for purposes of 
>data element/field redactions. Second, even for 
>natural person registrants we believe that 
>certain data elements that are designated for 
>redaction should not be redacted. We think at 
>minimum that the registrant's e-mail address, as 
>supplied to and verified by the registrar, 
>should not be redacted. These views have been 
>expressed repeatedly by the IPC, (BC, the GAC 
>and others) over the past months both before and 
>after the Temp Spec was issued.
>
>Bottom line I respectfully do not agree with 
>this particular takeaway or Milton's suggested 
>modification. We have significant objection to 
>and disagreement with the data elements/fields 
>that the Temp Spec has designated for redaction.
>
>For the avoidance of doubt while we do not 
>oppose (and even accept) that some data will be 
>placed "behind a gate" to ensure GDPR compliance 
>we feel continued discussion about which data 
>should be redacted (and when/why) is necessary.
>
>Thanks.
>
>Alex
>
>
>
>On Thu, Aug 16, 2018 at 5:58 AM Kurt Pritz 
><<mailto:kurt at kjpritz.com>kurt at kjpritz.com> wrote:
>Good amendment, Thanks Milton.
>
>Kurt
>
>
>
>
>On Aug 16, 2018, at 5:56 AM, Mueller, Milton L 
><<mailto:milton at gatech.edu>milton at gatech.edu> wrote:
>
>Thanks for the draft of the Triage Report, Kurt. 
>Having read only the Exec Summary, I think staff 
>did a very good job of summarizing the 
>"takeaways." I would like for one small 
>amendment to be made, however. In the second paragraph you write:
>
>"There were several areas of agreement with the 
>underlying principles in several sections of the 
>Temporary Specification (e.g., data redaction)."
>
>NCSG would like this to be amended to clarify:
>
>"There were several areas of agreement with the 
>underlying principles in several sections of the 
>Temporary Specification; in particular, there 
>was no opposition to redacting the data elements the temp spec designates."
>
>Dr. Milton L Mueller
>Professor School of Public Policy
>Georgia Institute of Technology
><https://urldefense.proofpoint.com/v2/url?u=http-3A__internetgovernance.org_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=5Jj-xpKIHrr7kRx2har48F_kRqbQNTYDbIQJ5L-yK_c&s=Wd1XAokYAut_3fD8o-XiZqyP-KMQ5sWTzn4mq7gya8g&e=><image001.jpg>
>
>
>
>
>From: Gnso-epdp-team 
>[<mailto:gnso-epdp-team-bounces at icann.org>mailto:gnso-epdp-team-bounces at icann.org] 
>On Behalf Of Kurt Pritz
>Sent: Wednesday, August 15, 2018 8:48 PM
>To: GNSO EPDP <<mailto:gnso-epdp-team at icann.org>gnso-epdp-team at icann.org>
>Subject: [Gnso-epdp-team] Pro-forma Triage Report
>
>Hi Everyone:
>
>It was requested that we prepare a â€œpro 
>formaâ€ Triage Report for review and discussion 
>- a version of the Triage report that might be 
>submitted to the Council when the surveys are completed.
>
>This represents the work from the first survey, 
>about 30% of the Temporary Specification. So you 
>can see, it will be a fairly long report.
>
>The report includes an executive summary, our 
>operating methodology, the summary table of 
>inputs, the issue summaries that were created 
>for each section and an appendix with all written comments.
>
>This report hasnâ€™t had sufficient vetting on 
>the leadership-support side yet but I wanted you 
>to see the formatting and level of content as soon as possible.
>
>I apologize for the font size in the appendix. 
>We will reorganize the table of all comments in 
>some way that is readable in time for the actual publication.
>
>We will continue building this report and 
>amending it in accordance with comments and 
>discussion as we go along. Remember that this 
>report is designed to help but not limit, 
>prejudice or restrict our future work. So 
>letâ€™s spend time to make this good, but not perfect.
>
>I hope you find this helpful.
>
>Best regards,
>
>Kurt
>_______________________________________________
>Gnso-epdp-team mailing list
><mailto:Gnso-epdp-team at icann.org>Gnso-epdp-team at icann.org
>https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
>
>_______________________________________________
>Gnso-epdp-team mailing list
><mailto:Gnso-epdp-team at icann.org>Gnso-epdp-team at icann.org
>https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
>
>
>--
>___________
>Alex Deacon
>Cole Valley Consulting
><mailto:alex at colevalleyconsulting.com>alex at colevalleyconsulting.com
>+1.415.488.6009
>
>
>_______________________________________________
>Gnso-epdp-team mailing list
>Gnso-epdp-team at icann.org
>https://mm.icann.org/mailman/listinfo/gnso-epdp-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20180820/427de21d/attachment-0001.html>