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