[Gnso-epdp-team] Project Plan Adjustments and Policy Organization

[Marika Konings]

Kurt, in relation to “Ashley suggested the latter set be captured in an Appendix”, I believe she specifically suggested Appendix A, section 4 (access to non-public registration data), but Ashley can correct me if I am wrong.

Best regards,

Marika

From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> on behalf of Kurt Pritz <kurt at kjpritz.com>
Date: Monday, September 3, 2018 at 18:42
To: GNSO EPDP <gnso-epdp-team at icann.org>
Subject: [Gnso-epdp-team] Project Plan Adjustments and Policy Organization

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

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.

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.

PastedGraphic-2.tiff<cid:52AEA82B-1C1F-4237-B11B-EF1A793B4630 at gateway>

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.

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

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

Thanks for taking the time to read and consider this. It came out longer than I planned.

Best regards,

Kurt



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20180904/e9bfa69c/attachment.html>