Hi Kurt My comments are inline On Mon, Sep 3, 2018 at 8:42 PM Kurt Pritz <kurt@kjpritz.com> wrote:
Hi Everyone:
I am writing to discuss two items. Comments are very welcome. (I apologize for the length of the email.)
I. DISCUSSION OF DATA ELEMENTS / ORGANIZATION OF OUR DISCUSSION
I took on board the comments made during the last meeting regarding the need to discuss data elements and the apparent skipping from section to section of the Temporary Specification.
The project plan essentially follows the path described in the Charter: I.e.:
Data Process Purposes —> Data Processing —> Legitimate reasons for disclosure —> Data redaction —> some ancillary but important topics
*FB:* I wonder how data redaction comes after legitimate reasons for data disclosure. My interpretation is that first we have to decide on which data should be redacted and then under what circumstances the redacted data should be disclosed.
I can see that the examination of the data collected (and therefore available for subsequent types of processing, including disclosure) was not explicitly included. To a certain extent, I think this data set was presumed set (at least by me) to be part of the data redaction discussions. Nonetheless, we cannot describe which data is redacted without specifically describing which data is collected in the first place.
*FB*: Ok, I agree, then I think we can say: data process purposes, data collection, data redaction, data disclosure. I would also argue that data retention should be discussed after data redaction and before data disclosure.
With that in mind and the help of Thomas’ work, we will have that topic more explicitly in the agenda today.
For organization and jumping from topic to topic, I think we must, at the end of the day, cover each of the sections in the Temporary Specification and decide if and how each topic should be included in the policy. With that in mind we created a project plan that marched through the Temporary Specification in an order that (more-or-less) followed the charter or our common-sense dictates.
I included two topics per meeting with the idea that intercessional work would be required on each topic and, after 45 minutes on one topic, we would reach a point of diminishing returns.
*FB: *We had raised this point before but column 7-8-9 is not about purposes for access. The meetings you have in mind will be to discuss this topic will be finished tomorrow so not a critical point but just flagging it.
I think that is still a good approach but we always retain the ability to extend a discussion if we are close to resolution on an issue.
II. CONSENSUS POLICY ORGANIZATION REGARDING: PURPOSES FOR PROCESSING gTLD REGISTRATION DATA
In our last meeting, I believe we reached a joint understanding of the requirements to be considered a “Lawful Purpose for Processing gTLD Registration Data.”
We concluded that these would continue to be categorized under Lawfulness and Purposes of Processing gTLD Registration Data: 4.4.1. – Ability for Registered Name Holder to exercise its rights 4.4.3. – Enabling mechanism for identifying and contacting registered name holder 4.4.4. – Payment and invoicing 4.4.5. – Notification of technical issues 4.4.6. - Notification of commercial or technical changes 4.4.7. – Technical & administrative points of contact 4.4.11. – Safeguarding in case of failure 4.4.12. – Dispute resolution services 4.4.13. – ICANN Contractual Compliance
…and these would be memorialized under a different heading: 4.4.2. – Providing access based on legitimate interests not outweighed by the fundamental rights 4.4.8. – Supporting a framework to address consumer protection, investigation of cybercrime, DNS abuse, IP protection 4.4.9. – Framework to address LE needs 4.4.10. – Provision of zone files to Internet users
*FB:*I am not so sure about the headings of 4.4.2 to 4.4.10 but I think we can disciuss them with drafting team.
I think this was a great joint understanding of our team (that same understanding only occurred to me in the last several days) and will get us onto determining substance, i.e., the mechanisms for disclosure in the near term.
Ashley suggested the latter set be captured in an Appendix. I think that is a good recommendation. As GDPR interpretation evolves or different privacy regimes are adopted, the legitimate reasons (or reasons with a legal basis) for disclosing data to third parties and be changed with adoption of amendments to the Appendix. However, I think the third-party disclosure should be anchored in the Temporary Specification body and incorporate the Appendix by reference. This is similar to other sections of the Temporary Specification.
This could be done in one of the two ways in red below and add a new Appendix: 1. Scope 2. Definitions and Interpretation 3. Policy Effective Date 4. Lawfulness and Purposes of Processing gTLD Registration Data * Requirements for Data Disclosure to Third Parties (alternative A) 5. Requirements Applicable to Registry Operators and Registrars 6. Requirements Applicable to Registry Operators Only 7. Requirements Applicable to Registrars Only 7.5 Requirements for Data Disclosure to Third Parties (alternative B) 8. Miscellaneous Appendix A: Registration Data Directory Services Appendix B: Supplemental Data Escrow Requirements Appendix C: Data Processing Requirements Appendix D: Uniform Rapid Suspension Appendix E: Uniform Domain Name Dispute Resolution Policy Appendix F: Bulk Registration Data Access to ICANN Appendix G: Supplemental Procedures to the Transfer Policy Appendix H: Third Party Disclosure Annex: Important Issues for Further Community Action
*FB:* I support just having appendix H and remove the alternatives A and B.
Thanks for taking the time to read and consider this. It came out longer than I planned.
Best regards,
Kurt
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team