Page History
...
Info |
---|
PROPOSED AGENDA
5. Wrap and confirm next meeting to be scheduled for Tuesday 14 August at 13.00 UTC. (Part 2 Survey results due Friday, 10 August by close of business.) BACKGROUND DOCUMENTS Updated - EPDP Team - Temp Spec Input - Part 1 - 8 August 2018.xlsx AUDIO CAST INFORMATION FOR ALTERNATES AND OBSERVERS To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u |
Info | ||
---|---|---|
| ||
GNSO transcripts are located on the GNSO Calendar |
Tip | ||
---|---|---|
| ||
Dial outs: Kurt Pritz, Kavouss Arasteh, Ayden Férdeline, Rafik Dammak Apologies: Georgios Tselentis (GAC), Farzaneh Badiei(NCSG), Thomas Rickert (ISPCP), Milton Mueller (NCSG) Alternates: Christopher Lewis-Evans (GAC), Collin Kurre (NCSG), Tatiana Tropina (NCSG) |
Note |
---|
Notes/ Action Items These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ. High-level Notes/Actions:
Questions for ICANN Org from the EPDP team:
All Action items:
1. Roll Call & SOI Updates
2. Welcome and Updates from EPDP Team Chair
3. Summary of responses to EPDP Input Survey Part 1 - Results for Appendix A – Registration Data Directory Services
4. Substantive Discussion of Temporary Specification (beginning with Section 4.4.7 – 4.4.13, 4.5 and Appendix A - Registration Data Directory Services) – see updated spreadsheet attached. Part 1 of the Survey can be found at https://www.surveymonkey.com/r/CC6F9F8 4.4.7. Enabling the publication of technical and administrative points of contact administering the domain names at the request of the Registered Name Holder; Issue summary: Opinions not in favor of this section question the utility of this voluntary data submission and whether voluntary data submissions should be included in the temporary specification.
4.4.8. Supporting a framework to address issues involving domain name registrations, including but not limited to: consumer protection, investigation of cybercrime, DNS abuse, and intellectual property protection; Issue summary: Explanation opposed to this section is not sufficiently detailed to adequately describe the issue. For example, what is the distinction among DNS Abuse, cybercrime and intellectual property theft? 4.4.9. Providing a framework to address appropriate law enforcement needs; Issue summary: There is a suggestion that LEA access to personal data needn't pass the balancing that data can be disclosed when legitimate and not overridden by fundamental rights. The preamble should refer to Art.6 of the GDPR. Must LEAs demonstrate the right to access data?
4.4.10. Facilitating the provision of zone files of gTLDs to Internet users; Issue summary: Given the distinction between zone file data and registration data, whether zone file contains personal data, and the fact that zone file data is currently available - can this section remain?
4.4.11. Providing mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure, or other unavailability of a Registrar or Registry Operator; Issue summary: Is it accurate to say there is general approval of this data use so long as ICANN does not have access to the registration data (which is thought to be the case)?
4.4.12. Coordinating dispute resolution services for certain disputes concerning domain names; and Issue summary: Except for the standard registry response, there appears to be consensus support for this section. Recommendations for enhancement can occur in the next step. 4.4.13. Handling contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users. Issue summary: Where there is disagreement with this section, the disagreement focuses on those specific data needs, without which the compliance task would be impossible to accomplish.
4.5. In considering whether Processing of Personal Data contained in Registration Data is consistent with Article 6(1)(f) of the GDPR, the GDPR requires ICANN to balance the legitimate interests described above with the interests, rights, and freedoms of the affected data subject. ICANN finds that the Processing is proportionate for the following reasons: see 4.5.1., 4.5.2. 4.5.3, 4.5.4, 4.5.5. Issue summary: Those not supporting this provision found the rationale in sections 4.5.1 et.seq. unconvincing. The alternative approach might be, as discussed earlier, to discuss the data collection and disclosure purposes recommended in 4.1.1 et.seq. and develop this section, if needed, after that.
APPENDIX A 1. Registration Data Directory Services 1.2 RDDS Search Capabilities 1.2. RDDS Search Capabilities 1.2.1. Where search capabilities are permitted and offered, Registry Operator and Registrar MUST: (1) ensure such search capability is in compliance with applicable privacy laws or policies; (2) only permit searches on data otherwise available to the querying user, based on whether the user only has access to data publicly available in RDDS or whether the user has access to non-public Registration Data; (3) only provide results otherwise available to the querying user based on whether the user only has access to data publicly available in RDDS or whether the user has access to non-public Registration Data; and (4) ensure such search capability is otherwise consistent with the requirements of this Temporary Specification regarding access to public and non-public Registration Data. 1.2.2. Where search capabilities are permitted and offered, Registry Operator and Registrar MUST offer search capabilities on the web-based Directory Service and the RDAP service (when implemented). Issue Summary: All parties agree that RDAP will be implemented regardless of the date provided in Section 1.1 (which should be removed). There is some uncertainty as to whether a search capability should be a contractual requirement, and whether such a provision such as Section 1 is required at all given the current contract, and also that the risks associated with the aggregation of data must be addressed.
2.1 - 2.3 (when data is restricted) Requirements for Processing Personal Data in Public RDDS Where Processing is Subject to the GDPR 2.1. Registry Operator (except where Registry Operator operates a "thin" registry) and Registrar MUST apply the requirements in Sections 2 and 4 of this Appendix to Personal Data included in Registration Data where:
2.2. For fields that Sections 2.3 and 2.4 of this Appendix requires to be "redacted", Registrar and Registry Operator MUST provide in the value section of the redacted field text substantially similar to the following: "REDACTED FOR PRIVACY". Prior to the required date of implementation of RDAP, Registrar and Registry Operator MAY: (i) provide no information in the value section of the redacted field; or (ii) not publish the redacted field. 2.3. In responses to domain name queries, Registrar and Registry Operator MUST treat the following Registrant fields as "redacted" unless the Registered Name Holder has provided Consent to publish the Registered Name Holder's data:
Issue Summary: Some parties believe that section 2.1 (coupled with sec. 3) is overly broad in that: GDPR data restrictions can be applied globally and include entities (registrars, registries, registrant) located outside the EEA, and data restrictions need not be applied to Legal persons where personal data is not included in the record. Others say that the legal/natural distinction cannot be made a priori and such a distinction is not implementable. Also, the privacy language prescribed (sec. 2.2) could be required prior to RDAP implementation. Some urge additional data be redacted as personal information can be gained from them: e.g., organization name, city, postal code. The Temporary Specification mentions "consent" without a requirement or specification for such. This group may take that up. Should thin registries should be required to move to thick as part of this Temporary Specification? Consider remaining sections at next meeting.
5. Wrap and confirm next meeting to be scheduled for Tuesday 14 August at 13.00 UTC. (Part 2 Survey results due Friday, 10 August by close of business.) |