Discussion of Temporary Specification §§4.1-4.3
Hello Amr (and everyone): I am writing in response to your proposal that the team considers Temporary Specification §§4.1-4.3 (with reference to the ICANN Bylaws and mission) prior to our discussion of data elements. I think understand the reasoning behind your request but still believe we should finish the “purposes” and “data elements” discussion before going into the reach of ICANN’s mission and Bylaws. Let me test out my reasons for this: With regard to the ICANN mission and Bylaws I believe there is a range of opinions among the stakeholder groups on our team as to the extent that the ICANN mission and Bylaws enable the collection, use and disclosure of personal data, In the best case, which I view as unlikely, we would develop a consensus opinion on this issue. Thus would be a helpful but not dispositive guide for identifying which data elements are collected and how they are used / disclosed. We’d still have to undertake that. More likely, I believe there would be a discussion without a consensus result. Even in that case, we would next take up the task of identifying data elements to be collected by registrars and their subsequent processing. Given that we have existing data collection and processing practices that were adequate pre-GDPR, it seems better to weigh those practices against GDPR and see what remains. Given the discussion at the end of the last meeting, it appears that the currently collected set of data is adequate for the currently identified needs of those seeking personal data disclosure. I can anticipate where there might be differences (we will see) but if an agreement is struck regarding the collection and disclosure od data elements, it seems accommodation on policy statements is more likely. Taking a slightly different approach to the same point: I think we should be discussing the section 4.4 elements, legitimate reasons for disclosure, and Appendix A against the GDPR and not against the ICANN Bylaws and mission. I understand that §§4.1 and 4.2 are elements in the Temporary Specification and must be discussed (I am not sticking my head in the ground here - I don’t think), but it is more efficient to discuss these paragraphs later — and especially if we don’t agree on data elements collected and processed. I think Alan G. was on to something in his earlier email where he said we should focus on what’s needed for our policy. Our goal is to identify (as a matter of policy): The legitimate purposes for processing registrant data the set of data to be collected by registrars and identifying the legitimate reasons (i.e., reasons with a legal basis) for disclosing that data to third parties. This, of course is an oversimplification but it is where we should focus. (I know others have made these comments before. I think Amr’s inquiry is a good time to restate what some others have said.) I hope this was clear and helpful to the discussion. Best regards, Kurt
Kurt, I think the point is that these processing practices were not adequate. The fact that ICANN got away with them should not be construed as an acceptance that they were legal. We need to examine ICANN's scope and bylaws to determine how far they overreach. Many actors on this EPDP are arguing that ICANN has a duty to support law enforcement access, for instance, and trademark enforcement. This is a matter that a court would examine rather closely, it would not simply take ICANN's word for it that producing a repository of personal information for informal access is a role that ICANN properly plays. I attach two letters from the former Chair of the Article 29 Working Party, sent at the time of the consultation of the 2013 RAA consultations. While they focus on the new data retention requirements, the reasoning still applies. Please note the penultimate paragraph on page 4 of the 2012 letter. Page two of the second letter specifically notes that law enforcement needs should be addressed through national law. Stephanie Perrin On 2018-09-06 02:31, Kurt Pritz wrote:
Given that we have existing data collection and processing practices that were adequate pre-GDPR, it seems better to weigh those practices against GDPR and see what remains.
Hi Kurt, Thanks for getting back to me on this. I appreciate your reasoning on the order of issues to be tackled, and agree that it is unlikely that this group reaches an easy consensus (if any at all) on the scope of ICANN’s mission and Bylaws concerning processing (collection, use and disclosure, as you put it) of gTLD Registration Data. For my part, I wasn’t suggesting we tackle sections 4.2 and 4.3 of the Temp Spec because I wanted you to lead us all into a hole we couldn’t crawl out of. Rather, I am concerned that the topic of ICANN’s remit will be spread out over multiple discussions concerning purposes of processing (again…, collection, use and disclosure) of gTLD Registration Data, basically with every single one of them. I suspect that this will delay progress on each and every one of these purposes, and a number of arguments on the scope of ICANN’s mission and Bylaws will need to be repeated at multiple points of the deliberations. In making my suggestion of tackling sections 4.2 and 4.3, I was hoping to avoid that in the same manner you are hoping to avoid a lack of consensus on nailing down an interpretation by this Team of ICANN’s remit. It’s a judgment call really, and absent support for a different direction among the EPDP Team members, it’s one that I will respect, whether I agree with it, or not. I suspect that most of us have already gone through most of the background documents relevant to this EPDP, but as a reminder, I’ve pasted a question sent by the GNSO Next Generation RDS PDP WG to EU Data Protection Experts, as well as the response received by the WG. The full set of questions and answers can be found on this [page](https://community.icann.org/display/gTLDRDS/Responses+to+RDS+PDP+WG+Question...). Question by GNSO RDS PDP WG:
Our working group is now deliberating upon the purpose of domain name registration data and the registration directory system that provides public access to that data. Can you please help us understand what the data protection supervisors have meant over the years when they have told ICANN to specify the purpose of WHOIS?
Response by EU Data Protection Experts:
Purpose has to be defined in advance of the data processing. Purposes have to have a legitimate aim and the processing has to be necessary and proportionate to the legitimate aim pursued. Translating this to ICANN means the WG would want to take a look into ICANN role and its mission statement and separate out the legitimate data processing purposes, and determine which data are necessary for which purpose. It is to be underlined that the compatibility of the processing to the original legitimate purpose should be also looked into at this point. You have also to bear in mind that according to all existing legal texts, the data controller has to be accountable for the data processing and that the purpose of the WHOIS directories cannot be extended to other purposes just because they are considered desirable by some potential users of the directories.
To illustrate it with an example if ICANN determines that it has a role in cyber-security,it will become accountable for these kinds of data processing (meaning accuracy of data, handling complaints, providing subject access etc…) but cannot give out data just because law enforcement authorities may find it useful.
I hope this helps. Thanks. Amr
On Sep 6, 2018, at 8:31 AM, Kurt Pritz <kurt@kjpritz.com> wrote:
Hello Amr (and everyone):
I am writing in response to your proposal that the team considers Temporary Specification §§4.1-4.3 (with reference to the ICANN Bylaws and mission) prior to our discussion of data elements.
I think understand the reasoning behind your request but still believe we should finish the “purposes” and “data elements” discussion before going into the reach of ICANN’s mission and Bylaws. Let me test out my reasons for this:
With regard to the ICANN mission and Bylaws I believe there is a range of opinions among the stakeholder groups on our team as to the extent that the ICANN mission and Bylaws enable the collection, use and disclosure of personal data,
In the best case, which I view as unlikely, we would develop a consensus opinion on this issue. Thus would be a helpful but not dispositive guide for identifying which data elements are collected and how they are used / disclosed. We’d still have to undertake that.
More likely, I believe there would be a discussion without a consensus result. Even in that case, we would next take up the task of identifying data elements to be collected by registrars and their subsequent processing.
Given that we have existing data collection and processing practices that were adequate pre-GDPR, it seems better to weigh those practices against GDPR and see what remains. Given the discussion at the end of the last meeting, it appears that the currently collected set of data is adequate for the currently identified needs of those seeking personal data disclosure. I can anticipate where there might be differences (we will see) but if an agreement is struck regarding the collection and disclosure od data elements, it seems accommodation on policy statements is more likely.
Taking a slightly different approach to the same point: I think we should be discussing the section 4.4 elements, legitimate reasons for disclosure, and Appendix A against the GDPR and not against the ICANN Bylaws and mission.
I understand that §§4.1 and 4.2 are elements in the Temporary Specification and must be discussed (I am not sticking my head in the ground here - I don’t think), but it is more efficient to discuss these paragraphs later — and especially if we don’t agree on data elements collected and processed.
I think Alan G. was on to something in his earlier email where he said we should focus on what’s needed for our policy. Our goal is to identify (as a matter of policy):
- The legitimate purposes for processing registrant data - the set of data to be collected by registrars and - identifying the legitimate reasons (i.e., reasons with a legal basis) for disclosing that data to third parties.
This, of course is an oversimplification but it is where we should focus. (I know others have made these comments before. I think Amr’s inquiry is a good time to restate what some others have said.)
I hope this was clear and helpful to the discussion.
Best regards,
Kurt
Kurt, I think Amr has responded to you but I just want to see if I understood what you were saying. As Amr said, it’s very clear from law that purpose dictates the nature and scope of data processing. So it makes no sense for you to say that we have to settle purpose before discussing what forms of data are mandated by ICANN’s mission. ICANN’s mission is what determines purpose. So you have to settle that first. On the other hand, if I understand your long message, you may be saying that it would be easier to reach agreement if we go through the list of data elements currently collected and find out if there is any disagreement about that. This is actually what I suggested some time ago, which is why I sent you the list of redacted data elements and have been asking other SGs and ACs to express their view on that for some time. We may indeed discover that there is not much disagreement about that. Is that what you were saying? I can’t tell from the message below. --MM From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Kurt Pritz Sent: Thursday, September 6, 2018 2:31 AM To: Amr Elsadr <aelsadr@icannpolicy.ninja>; GNSO EPDP <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Discussion of Temporary Specification §§4.1-4.3 Hello Amr (and everyone): I am writing in response to your proposal that the team considers Temporary Specification §§4.1-4.3 (with reference to the ICANN Bylaws and mission) prior to our discussion of data elements. I think understand the reasoning behind your request but still believe we should finish the “purposes” and “data elements” discussion before going into the reach of ICANN’s mission and Bylaws. Let me test out my reasons for this: With regard to the ICANN mission and Bylaws I believe there is a range of opinions among the stakeholder groups on our team as to the extent that the ICANN mission and Bylaws enable the collection, use and disclosure of personal data, In the best case, which I view as unlikely, we would develop a consensus opinion on this issue. Thus would be a helpful but not dispositive guide for identifying which data elements are collected and how they are used / disclosed. We’d still have to undertake that. More likely, I believe there would be a discussion without a consensus result. Even in that case, we would next take up the task of identifying data elements to be collected by registrars and their subsequent processing. Given that we have existing data collection and processing practices that were adequate pre-GDPR, it seems better to weigh those practices against GDPR and see what remains. Given the discussion at the end of the last meeting, it appears that the currently collected set of data is adequate for the currently identified needs of those seeking personal data disclosure. I can anticipate where there might be differences (we will see) but if an agreement is struck regarding the collection and disclosure od data elements, it seems accommodation on policy statements is more likely. Taking a slightly different approach to the same point: I think we should be discussing the section 4.4 elements, legitimate reasons for disclosure, and Appendix A against the GDPR and not against the ICANN Bylaws and mission. I understand that §§4.1 and 4.2 are elements in the Temporary Specification and must be discussed (I am not sticking my head in the ground here - I don’t think), but it is more efficient to discuss these paragraphs later — and especially if we don’t agree on data elements collected and processed. I think Alan G. was on to something in his earlier email where he said we should focus on what’s needed for our policy. Our goal is to identify (as a matter of policy): * The legitimate purposes for processing registrant data * the set of data to be collected by registrars and * identifying the legitimate reasons (i.e., reasons with a legal basis) for disclosing that data to third parties. This, of course is an oversimplification but it is where we should focus. (I know others have made these comments before. I think Amr’s inquiry is a good time to restate what some others have said.) I hope this was clear and helpful to the discussion. Best regards, Kurt
Dear Kurt, As I mentioned at two occasions, the draft temporary specification has been prepared by ICANN Any question on their validity, relevance, appropriateness should be raised with the Board Liaison first and allow them to explain why they have done so and on waht rationale Moreover, we should not continue to talk on the general scope of Section 4 rather we MUST discuss each sub paragraph and listen to the comments theron.Should any one is in a position to propose concrete amendment he or she could do so but turning around ourselves in repeating each individual's view does not help. Having reviewed comments made at previous meetings as well as contribution from 5 groups reveals that there are clear divergence view. Then how we could reconcile these divergence. I have noted that , Registrar replaced reference to GPDR which is a valid reference easily indefinable to other sources such as " Applicable Law" We have discussed the later terms for hours band hours in Jurisdiction Group for which no conclusive results was made. I am therefore against using vague and ambiguous terms such as Applicable Law , reasonable access, legitimate purpose, legitimate interest , limited dat and so so. There arae unclear , vague , which could be interpreted differently buy each user. At your meeting, some people ( two only) do not respect the ICANN Ethics and refers to other's statement in an inappropriate manner. It happened two time by two member which I categorically reject .They must respect other and not use unfaimiar and irelevant terms or sign like God finger or ahha or hihihi or similar. Pls establish a rule and ask people to respect pothers. t On Thu, Sep 6, 2018 at 2:45 PM Mueller, Milton L <milton@gatech.edu> wrote:
Kurt,
I think Amr has responded to you but I just want to see if I understood what you were saying.
As Amr said, it’s very clear from law that purpose dictates the nature and scope of data processing. So it makes no sense for you to say that we have to settle purpose before discussing what forms of data are mandated by ICANN’s mission. ICANN’s mission is what determines purpose. So you have to settle that first.
On the other hand, if I understand your long message, you may be saying that it would be easier to reach agreement if we go through the list of data elements currently collected and find out if there is any disagreement about that. This is actually what I suggested some time ago, which is why I sent you the list of redacted data elements and have been asking other SGs and ACs to express their view on that for some time. We may indeed discover that there is not much disagreement about that.
Is that what you were saying? I can’t tell from the message below.
--MM
*From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] *On Behalf Of *Kurt Pritz *Sent:* Thursday, September 6, 2018 2:31 AM *To:* Amr Elsadr <aelsadr@icannpolicy.ninja>; GNSO EPDP < gnso-epdp-team@icann.org> *Subject:* [Gnso-epdp-team] Discussion of Temporary Specification §§4.1-4.3
Hello Amr (and everyone):
I am writing in response to your proposal that the team considers Temporary Specification §§4.1-4.3 (with reference to the ICANN Bylaws and mission) prior to our discussion of data elements.
I think understand the reasoning behind your request but still believe we should finish the “purposes” and “data elements” discussion before going into the reach of ICANN’s mission and Bylaws. Let me test out my reasons for this:
With regard to the ICANN mission and Bylaws I believe there is a range of opinions among the stakeholder groups on our team as to the extent that the ICANN mission and Bylaws enable the collection, use and disclosure of personal data,
In the best case, which I view as unlikely, we would develop a consensus opinion on this issue. Thus would be a helpful but not dispositive guide for identifying which data elements are collected and how they are used / disclosed. We’d still have to undertake that.
More likely, I believe there would be a discussion without a consensus result. Even in that case, we would next take up the task of identifying data elements to be collected by registrars and their subsequent processing.
Given that we have existing data collection and processing practices that were adequate pre-GDPR, it seems better to weigh those practices against GDPR and see what remains. Given the discussion at the end of the last meeting, it appears that the currently collected set of data is adequate for the currently identified needs of those seeking personal data disclosure. I can anticipate where there might be differences (we will see) but if an agreement is struck regarding the collection and disclosure od data elements, it seems accommodation on policy statements is more likely.
Taking a slightly different approach to the same point: I think we should be discussing the section 4.4 elements, legitimate reasons for disclosure, and Appendix A against the GDPR and not against the ICANN Bylaws and mission.
I understand that §§4.1 and 4.2 are elements in the Temporary Specification and must be discussed (I am not sticking my head in the ground here - I don’t think), but it is more efficient to discuss these paragraphs later — and especially if we don’t agree on data elements collected and processed.
I think Alan G. was on to something in his earlier email where he said we should focus on what’s needed for our policy. Our goal is to identify (as a matter of policy):
- The legitimate purposes for processing registrant data - the set of data to be collected by registrars and - identifying the legitimate reasons (i.e., reasons with a legal basis) for disclosing that data to third parties.
This, of course is an oversimplification but it is where we should focus. (I know others have made these comments before. I think Amr’s inquiry is a good time to restate what some others have said.)
I hope this was clear and helpful to the discussion.
Best regards,
Kurt
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
participants (5)
-
Amr Elsadr -
Kavouss Arasteh -
Kurt Pritz -
Mueller, Milton L -
Stephanie Perrin